Press "Enter" to skip to content

Month: April 2016

Temp Table Usage

Paul Randal discusses common temp table anti-patterns:

It’s quite common for there to be a latching bottleneck in tempdb that can be traced back to temporary table usage. If there are lots of concurrent connections running code that creates and drops temporary tables, access to the database’s allocation bitmaps in memory can become a significant bottleneck.

This is because only one thread at a time can be changing an allocation bitmap to mark pages (from the temp table) as allocated or deallocated, and so all the other threads have to wait, decreasing the workload throughput. Even though there has been a temporary table cache since SQL Server 2005, it’s not very large, and there are restrictions on when the temporary table can be cached (e.g. only when it’s less than 8MB in size).

This is great advice; read the whole post.

Comments closed

Using Dates And Times

Aaron Bertrand has an intro-level post on using dates and times in SQL Server:

I urge you to always use yyyymmdd (without the dashes) for a date without time – it will never fail, regardless of regional, language, or dateformat settings, and across any of the date/time data types. (And absolutely do not store it as a string data type in SQL Server – always store it as a proper date or time data type.)

This was a big one for me because I tend to use yyyy-mm-dd.

Comments closed

SSRS Improvements

Simon Sabin has thoughts on Reporting Services 2016:

I recently installed SQL Server 2016 on my surface to get all our SQLBits reports sorted. What I couldn’t figure out was why it was so quick. I thought it might be because it was a local install and running on an SSD based surface but that couldn’t account for the blazing difference with previous versions.

Well the answer is much better.

I am looking forward to Reporting Services 2016, even though I rarely use SSRS anymore.

Comments closed

Specify Schema

Kenneth Fisher warns that you should specify schemas in scripts:

But why? I mean the table gets created either way and since the default is dbothere is no real reason to name it.

Actually no. The default is not in fact dbo. It frequently is dbo but by no means always. The default schema is part of your USER information. Specifically theDEFAULT_SCHEMA option. Well, unless you are a sysadmin. Then it actually does always default to dbo.

Schemas are a very powerful grouping mechanism, and they’ve been around long enough that if you aren’t taking full advantage of them, you really should.

Comments closed

Adding Multiple Packages To A Project

Koen Verbeeck shows a quick way to add multiple existing packages to a project:

You select the package you want to import and you’re done. But the problem is, you can select only one single object? What if you want to import 20 packages to your project? Kind of annoying to repeat the same process 20 times, isn’t it?

Luckily there’s an easier way. Instead of going for the obvious Add Existing Package, right-click on the project itself. In the context-menu, choose Add, ignore Existing Package and click on Existing Item.

If you have a large number of packages to import, this will save you a few minutes of tedium (or hand-editing a project file).

Comments closed

Views Aren’t Tables

Grant Fritchey looks at how the query optimizer treats views:

The important point to note is that the optimizer is absolutely not treating the view like a table. The optimizer is treating the view like a query, which is all it is. This has both positive and negative impacts when it comes to query performance tuning and this view. You could spend all sorts of time “tuning” the view, only to find all that tuning you’ve done tossed out the window when the query doesn’t reference a column in the view and that causes the optimizer to rearrange the plan. I don’t want to convey that this is an issue. It’s not. I’m just trying to emphasize the point that a view is just a query.

In a subsequent post, Grant promises to talk about the potential perils of nested views.  That’s where people start running into trouble, when a nested view gets to be so complex that the query optimizer gives up and takes it literally.

Comments closed

Collapsing Lists In R

Steph Locke shows how to collapse a list of data frames into a single data table:

With my HIBPwned package, I consume the HaveIBeenPwned API and return back a list object with an element for each email address. Each element holds a data.frame of breach data or a stub response with a single column data.frame containing NA. Elements are named with the email addresses they relate to. I had a list of data.frames and I wanted a consolidated data.frame (well, I always want a data.table).

Enter data.table …

data.table has a very cool, and very fast function named rbindlist(). This takes a list of data.frames and consolidates them into one data.table, which can, of course, be handled as a data.frame if you didn’t want to use data.table for anything else.

Something that continuously amazes me with R is just how terse the language can be without collapsing into Perl.

Comments closed

Conditional Ordering

Kenneth Fisher shows various methods for conditional ordering:

Simple sorts are pretty easy. In the ORDER BY clause you can list out the columns by name or by position in the field list and determine if you want them sorted ascending or descending. But how about going beyond that?

Every now and again you need a fairly complex sort order. Say for example you want to order your data differently depending on the Status (say DueDate if theStatus is 1, 2 or 3 and ShipDate otherwise). But you also want anyone with aTotalDue greater than $5000 sorted separately from those with a TotalDue less than $5000.

Conditional sorting isn’t something you should be doing in every query, but it’s important enough to know about.

Comments closed

Service Broker Conversations

Colleen Morrow goes into conversations in the context of Service Broker:

Like real-life conversations, Service Broker conversations are a reliable-bidirectional stream of messages exchanged between two participating services.  A Service Broker conversation can be short-lived, a simple exchange of 2 messages, or it can span days, weeks, even years.  There are two key elements of a Service Broker conversation that are important to note, however.  The first is that messages are guaranteed to be delivered in order, and only once.  Service Broker uses sequencing and acknowledgement mechanisms to ensure this.  The second key is that conversations are persistent.  Persistent across network interruptions.  Across server restarts.  In fact, conversations persist until they are explicitly ended.

In the world of Service Broker, you’ll sometimes see the term “conversation” used.  Sometimes it’s “dialog”.  Sometimes it’s even “dialog conversation”.  Although “conversation” and “dialog” are distinct concepts in the greater world of messaging services, in the context of Service Broker they are interchangeable.

We’re getting close to seeing Service Broker in action here, so stay tuned.

Comments closed

Retrieving WMI Information

Dave Mason shows how to retrieve WMI information (perhaps the “wrong” way):

In another post I explored a way to run WMI queries from tsql (sort of). Let’s do it again. The script below enables xp_cmdshell, runs WMIC.exe (capturing the output to a temp table), shreds the XML, returns a result set of columns and rows, and disables xp_cmdshell. If you’re adventurous and daring, run the script in a test environment.

With Powershell, as Dave mentioned, this really isn’t the best way to do the job, but there are times when you aren’t able to use Powershell.

Comments closed