Chances are if you’re experiencing one of these two lock wait types you have a very high transaction application. In our case it’s true to the extent that we have greater then 3x the amount of connection resets on our connection pool then any other application using SQL Server in the firm (on just one instance about 178k connections per minute).

In our few extremely high transaction tables we wind up running into an issue with disposing of stale data. To solve this we partition the tables by day of year (and in some cases hour of day). Every day (or hour) we swap out the partition to a blank table and truncate that swap table for a sub second data cleanup. And because of this we’ve both partitioned and sorted our cluster index by this field.

A PAGELATCH_EX or PAGELATCH_SH alert is actually not related to IO yet you’ll run into it with the scenario I explained above. What winds up happening is that while we have a pretty beefy data server, we have contention on the last page in the table only allowing us to process a few inserts at a time. This is because our clustered index is sorting on day of year ascending which creates a hot spot at the end of the table.

In order to solve this, all we had to do is force our inserts to hit multiple parts of the table at once to prevent a single page lock from slowing down the entire system. In this part of our application we were collecting metrics data from all workstations in the firm and we had a column MachineName for every row in the table. We decided to add MachineName to the clustered index which then forced each insert to each hit a unique page in our table.

From then on, you’re sitting on the speed of your disk IO. Provided you have a decent storage setup you’ll be leaning on your log volume. The rest is pretty well documented in Google, I just didn’t find anything that easy for PAGELATCH issues so I figured I would share.

I was asked this question a few months ago and liked it due to its simplicity, and how it can be done on paper which is how we’ve been administering our interview tests (this is currently not on my test).

Imagine you have a packaging system and there is a table that defines what packages a user can access. There are two columns uid (user id) and pid (package id). Every row in this table provides a specific user with access to a package, for example there may be rows [1,1] or [3,5] where as user 1 has access to package 1 or user 3 has access to package 5. A user can have access to multiple packages which would result in rows like [1,1], [1,2], [1,3], etc… However, a user will be considered a “Super User” if they have a pid of -1 assigned to their user id. Often times a user is given access to multiple packages only to later be given “Super User” access. Write a query for this table to display all user access however if a user is a “Super User”, only display the one row for them demonstrating that they are a “Super User”.

Now, more often then not people will come up with some hackish query involving “UNION” or “IN”. When they do, tell them both are horrible for performance if not for any reason other then there are multiple executions within one query. Ask them to try and rewrite it using joins and not “UNION” or “IN”. This brain teaser is simple and should demonstrate their confidence with joins and ability to think beyond “Step 1, Step2″ answers. There is no one right answer, I’ve included mine below:

This rap is straight dope yo’

Yea thats right, we finally get a good excuse for taking on less work. For the details, read on. By the way this is ripped off verbatim from Slashdot.

“Multitasking messes with the brain in several ways. At the most basic level, the mental balancing acts that it requires — the constant switching and pivoting — energize regions of the brain that specialize in visual processing and physical coordination and simultaneously appear to shortchange some of the higher areas related to memory and learning. We concentrate on the act of concentration at the expense of whatever it is that we’re supposed to be concentrating on… studies find that multitasking boosts the level of stress-related hormones such as cortisol and adrenaline and wears down our systems through biochemical friction, prematurely aging us. In the short term, the confusion, fatigue, and chaos merely hamper our ability to focus and analyze, but in the long term, they may cause it to atrophy.”