KEY: 26:72057594819903488 (6b0068a71fb9).

I watched a bit longer, and every time that LCK_M_S waittype came up, it was associated with the same KEY value.  But what does that value represent?

Well, the 26 is the database ID.  But what about that big number?  According to the MS KB article (KB 224453) on “Understanding and resolving SQL Server blocking problems“, that is something called a hobt_id (or “hash value for index key”).  The good news is that it’s simple to find out what that refers to.  Simply run the following query:

SELECT * FROM sys.partitions
WHERE hobt_id = <<long number>>

Here we have the object ID and index ID that are causing issues.

DBCC doesn’t throw up any issues; the indexes are OK; the table itself is small(ish) – approx 30k rows. I think all that was happening was that that particular table was getting hammered during a bulk upload.

Here’s an excerpt:

A New York City subway train holds 1,200 people. This blog was viewed about 5,300 times in 2011. If it were a NYC subway train, it would take about 4 trips to carry that many people.

Click here to see the complete report.

This post is based on what I use on non-production (eg for QA, or UAT) replicas of production environments – the sort of thing where you need the data, but don’t need to maintain it or do backups.

If you have to set up this sort of environment regularly, then the chances are that you’re doing it by restoring database backups from production.  These databases will almost certainly be in “FULL” recovery so you are able to recover in the event of a disaster.  (You *are* remembering to backup your transaction logs, right?) If you leave a database in “FULL” recovery, but don’t schedule a regular transaction log backup, then you will find that the transaction log grows.  And grows.  And eats your hard disk (I’m assuming that you’ve kept the disk space tight on these environments, because your storage guys won’t give you enough storage to directly match production…  mine didn’t.)

If you build this environment by restoring databases from production, as well as restoring the data, you’re also restoring the database settings from within the database, and one of those is the recovery model. Which is most likely to be “FULL” recovery.

So what I do is implement a scheduled job on each of these servers to run the following little bit of SQL every night:

declare @SQL varchar(max)
SET @SQL=''
SELECT @SQL = @SQL + 'alter database [' + name + '] SET RECOVERY SIMPLE'
+ char(13) + char(10)
FROM sys.databases
WHERE recovery_model_desc <> 'SIMPLE'
EXEC (@SQL)

A few features worth mentioning:

(1) change the varchar(max) to varchar(8000) for SQL Server 2000 – this should be enough, unless you’ve got a *huge* number of databases to deal with. Anyway, why are you still running SQL Server 2000?

(2) Rather than looping through every database with a CURSOR or a WHILE loop, we’re using a single SELECT statement to build up a string containing the appropriate commands.

(3) we’re only looking at the databases that aren’t already in SIMPLE recovery, so we won’t get error messages for trying to set master or tempdb to SIMPLE.

(4) If you have strangely-named databases (eg anything with a “-” or a space), you’ll probably need the square brackets shown above

(5) Note also that the EXEC command has the @SQL parameter in parentheses. This is a classic “Gotcha” brought about by EXEC having two sets of syntaxes – without parentheses (for calling a stored procedure), or with parentheses (for passing a string to be executed). If you get that wrong and omit the parentheses from the Exec (@SQL) line, then you’ll see an error message such as this:

Msg 203, Level 16, State 2, Line 10
The name 'alter database [DBName1] SET RECOVERY SIMPLE
alter database [DBName2] SET RECOVERY SIMPLE
' is not a valid identifier.

Job done. One less thing to worry about (or should that be “one fewer thing (or things) to worry about”? Damn. Now I’m worrying about that instead…)

So, let’s download it and fire it up.

I’ve obscured the name of the server I’m connecting to…

Shortly after starting the tool, it has analyzed all the databases on that server to which I have access, and returns the results:

As you can see, there are two options for action – “Rebuild” or “Reorganize”.  Click on those problems that you would like to fix, and hit the “Fix Indexes” button.  This gives you the option to run the recommended actions immediately, or will give you the SQL script so you can run it as & when you want.  If you click “Fix Now”, it’ll take you to the results grid where you can see what’s going on.

And that’s it – nice and easy.

However…

As it stands, there are no options to change behaviour (eg by setting up your own thresholds, or just selecting one database to scan).  As such, this feels either like an early Beta, or a tool that is aimed more at the “accidental” or new DBA.

The thing that I find confusing is also the “Index fragmentation %” – I would (personally) have assumed that a higher number is indicative of a more fragmented index, but apparently this tool thinks otherwise.  Checking the TechNet documentation linked above indicates that MS seems to be on my side…

There are a few other behavioural hiccups that need addressing, and I’ve sent a little list to send back to Red Gate.  You can help too – download the free beta, play with it, and use the “Give feedback” button to, erm, give feedback via email.

And now to see if it’ll play nicely with SQL Server 2000… I may be some time…Game over rather quickly. Heigh ho.

Bother.

That photo was taken six months ago - I've bought a few more books since then.

As you may be aware from elsewhere on these pages, I carry a large box of books from office to office; the collection has recently outgrown its box, and I’ve been wondering about Going Digital.

I’ve tried a couple of eReaders at conferences and in the office, without being convinced – the small screen size has just never seemed big enough for technical books. However, the Kindle DX did catch my eye as being a possible device. But, oh my, the price. US$360 + shipping + import taxes.

And then. Thanksgiving.

I was suckered by Amazon’s “Black Friday” sale, and got the Kindle DX at significant money off. Still not cheap, though. It arrived today (very quick – can’t imagine ParcelForce managing to ship anything fragile unharmed several thousand miles over a holiday weekend). I spent a few minutes downloading all the books I could get my hands on from the Red Gate bookstore, and I also dropped a few bucks in the Apress pot during their sale of eBooks, and picked up those books named in the SQL Server MCM reading list, as recommended by Gavin Payne (blog|twitter) and Mark Broadbent (blog|twitter).

First impressions: this is good. The DX arrived pre-registered to my Amazon account. Unfortunately, my Amazon.com account rather than the .co.uk one, but that took all of a minute to fix, and at that point, it picked up my Kindle archive (from when I had been trying out the software on my Android phone…)

Plugging the Kindle in to charge wasn’t quite so impressive – the cable feels a bit flimsy; it’s a standard USB cable, so don’t bother buying the separate charger. But that’s the only gripe from the quality / feel perspective. There is other weirdness when you change page, where there seems to be a couple of inversions – black becoming white, and vice versa – before the new page settles down. It only takes a moment, and isn’t limited to page changes in PDFs – it seems to happen whenever there’s a full-page refresh, such as moving between pages of the book index, or navigating the settings.

The Kindle appears on the PC as another external hard drive, with about 3.3GB free space. Should be enough for a few books…  And, while you can set up categories within your Kindle library, it doesn’t appear to be possible to drop new documents straight into the category.  (Note that I haven’t yet tried dropping documents into a separate directory within the documents directory, but the Kindle documentation isn’t encouraging – I guess that’s the flip side of being able to maintain collections across multiple devices.)

Very bad photo - I apologise - but all text is readable without difficulty - trust me!

So you can see a very bad comparison, check page 8 of Schmeling’s “SQL Server Statistics”, from the Red Gate bookstore. This is very easy to read on the DX’s screen (but the photo doesn’t do it justice – cheapo camera on the phone…). The only slight problems I have is reading all of the code samples, such as on p7, where the magenta & red colours don’t survive the translation to grey shades very well. It is readable, but you wouldn’t want to copy-type at speed.

In summary: The Kindle DX experience is almost all good – so far. Big screen makes for readable diagrams within the body of the text. Easy to use. Now all I have to do is keep it away from a certain small boy’s sticky fingers…

Previous Performance…

It’s relatively straightforward to see how long a scheduled task has taken in the past – take a look at the sysjobhistory table in the MSDB database. That is, after all, what the SQL Server Management Studio Job History section of the Log File Viewer GUI does. A simple query here would be:

SELECT
    step_id,
    step_name,
    run_status,
    run_date,
    run_time,
    run_duration
FROM
    sysjobhistory
WHERE
    job_id = (
                SELECT job_id
                FROM sysjobs
                WHERE name = 'User Databases - Full Backup') -- change this to match your job name
ORDER BY
    run_date,
    run_time,
    step_id

The above query brings back the following results (edited for brevity):

Note that the run_date, run_time and run_duration fields are integer representations of the actual date. The run_date field is giving us an eight digit number with the date the job step started as yyyymmdd; run_time field is a six digit number (you’ll have to imagine the leading zero(s) if it’s only showing fewer than six digits) with the time at which the job step started as hhmmss; run_duration is encoded similar to run_time. Not helpful for doing any meaningful maths on without slicing & dicing first. And I have no idea what the run_duration field looks like if a job runs for longer than a day, and the MSDN page referenced above likewise seems to think it’s not an option…

[Incidentally, Jonathan "FatherJack" Allen (blog|twitter) has raised a Connect item with Microsoft to try to get them to change this... Please vote for it!]

Results here indicate that the Backup Databases step takes anywhere between 38:54 and 40:02. The thing to bear in mind here is that your backup job may also include a step to verify the backup. Mine does. And that the backup step may be backing up multiple databases – in this case, I’m backing up 17 databases, only one of which is of any significant size.

If you’re only interested in the backup time, then you could also take a look at a previous backup file. (You can see that the database I’m looking at is pretty much static, given the size of the differential backups.)

Disclaimer: there is a regular backup job, honest! It’s just I’ve had to do a few extras recently…

Here, we can see that the difference between the file creation date and the file modified date (ie the time at which the backup was completed) is between 33 and 34 minutes.

…Is No Guarantee Of Future Performance

Of course, none of these “guesstimates” may be available to you. Or the dataset could have changed significantly since the last full backup. What do we do then?

We can query the sys.dm_exec_requests DMV. Go on – take a look. You’ll see a lot of useful information about what queries are running and the most recent query for a spid that’s not currently running anything. What I’m interested in, however, is running a query like this:

SELECT
    start_time,
    percent_complete,
    estimated_completion_time,
    DATEADD(ms, estimated_completion_time, GETDATE()) AS ETA,
    GETDATE() AS Current_DateTime,
    command,
    DB_NAME(database_id) AS Database_Name
FROM
    sys.dm_exec_requests
WHERE
    command LIKE 'BACKUP%'

Here, I’m getting information about all BACKUP statements currently running. Most of what I’m selecting is self-explanatory, except be aware that the estimated_completion_time field is a millisecond countdown of the time remaining, so I’m adding that to the current system date/time (which I’m also showing, in case you’re not in the same timezone as your server). The DMV also provides the database ID rather than the database name… but that’s easy to fix with that cal to the DB_NAME() function. I’m lucky in that the backup software (Quest – see below) I’m using does seem to switch to the database being backed up.

The query above gives us the following:

As you can see, the ETA does hunt around a bit

but is pretty accurate in the later stages

Background Information

If you think these figures are slower than they might be, then you’re right. I’m backing up a 240(ish)GB database using Quest Software’s LiteSpeed for SQL Server, with maximum compression and encryption. The backup is simultaneously being written out to another datacenter. The server is not new and the disk layout is, erm, “sub-optimal”.

The size of data being backed up? Well, the database’s MDF is around 240GB; there’s about 140GB of actual data and 100GB of slack space (the optimisation process does some weird things). And, as you can see in the screenshot from Windows Explorer earlier on in this post, that’s being backed up to a 10GB file.

Job done

…back to work.

Practice makes perfect. But even when you’ve practised DR until you’re blue in the face, there’s always something missing compared with reality – and that’s the disaster itself, and the psychological & physiological impacts of working under that kind of stress.

I’d seen that line before, somewhere – and, last night, I finally found it. It is from Terry Pratchett’s book “Thief of Time“, pp160-1 in the edition I have, and the text is as follows:

‘I really must respectfully protest, your reverence,’ said the acolyte. ‘We have practised for just such an emergency as—’

‘Yeah, I know all about practising procedures for emergencies,’ said Lu-Tze. ‘And there’s always something missing.’

‘Ricidulous! We take great pains to—’

‘You always leave out the damn emergency.’

And Lu-Tze is correct. The emergency itself causes all sorts of changes of behaviour – a DR exercise will typically be attended only by those involved in putting stuff back together, nice and quiet, and you can get on with it. A real DR situation, however, is a very different kettle of fish. You’ll have management breathing down your neck. You’ll have their management, the Ops management, probably Financial Directors, CEOs, all sorts of people with “Chief” or “Executive” or “Manager/Management” in their job titles, who don’t understand a damn thing about what’s going on, but they all want to know, like a bunch of six-year-olds in the back of the car, “are we there yet?”. And this is where the mark of a good boss is – can he keep them away from you so you can concentrate on getting things back together (good), or not (bad). And this is also partly down to how good *you* are – can you provide enough information back to the boss to say what’s going on, how long it’s going to be (approximately), and what else is to be done (again, with time estimates)?

In other words, when the solids are hitting the aircon, can you rapidly put together a project plan with sufficient level of detail to keep your boss and his management colleagues happy? And provide checkpoint reports?

A Quick Maintenance / Implementation Tip

A quick tip for something to do when building release scripts.

If you’re not sure about whether an object exists, and need to make sure that the right version is provided, then your release script might start out with a test to see if the object exists, and to drop it if it does, then create the replacement:

IF NOT (OBJECT_ID('dbo.foo') IS NULL) THEN DROP PROCEDURE foo END
CREATE PROCEDURE foo ...

This isn’t particularly friendly to running applications, may well cause issues with dependent objects, and you’ll have to be very careful to get the permissions right.

However, if you check to see if the object exists, and if it doesn’t then create a stub which can then be modified by your release script, these issues (mostly) go away.

IF OBJECT_ID('dbo.foo') IS NULL THEN
EXEC ('CREATE PROCEDURE dbo.foo AS RETURN 0')
GO
ALTER PROCEDURE dbo.foo ...

OK, so it’s a bit more effort, but it does mean that you won’t lose permissions information. And the headaches that fixing that sort of thing can cause makes it well worth the effort.

Of course, for bonus points, you should put the GRANT statement at the end of your release script anyway, just in case you are creating the object from scratch…

Should I?

I recently saw a Tweet on the #sqlhelp tag asking “What advantages do Stored Procedures have in MSSQL? Should I learn to use them?”

My answer – Yes. Hell yes.

Why Should I?

This is harder (for me) to articulate. Some reasons that come to my mind include:

Less network traffic

Consider a busy firm with a case management system. To build the case handlers’ views of what’s what involves a complex set of SQL queries. Now, should these be held at the client side, and sent to the server one at a time, or batched up and sent (and executed) all at once? And isn’t it easier for the programmer / maintainer of the codebase to see a call to exec GetUserCaseLoad @UserID=foo rather than the masses of code?

Maintainability

While we’re on the subject of maintenance, imagine that you’re working in an environment where the code is used in many applications. Would you find it easier to change the stored procedure, or to find all instances of that code in your application base?

Consistency of Operation

This is an important area – if you’ve got many applications accessing the same data, then it can be helpful to ensure that this is always accessed in the same way. This can significantly reduce the risk of deadlocks.

Yeah, but…

Look, I know I don’t make a particularly good argument here in favour of it. There’s loads of stuff out there, and I suggest you read it. There’s even some stuff advocating not to bother.

Have a look. If you want to know if it really will make a difference, there’s only one way to find out – benchmark performance of your ad-hoc SQL in its application, then replace with a SP and re-benchmark.

The #SQLFamily Twitter hashtag hasn’t got a long glorious history, but the SQL Server community has – and this is what the #SQLFamily is about.  It’s a very friendly group of people, eager to accept new members and mentor them, help out with their problems on the various Q&A sites such as http://Ask.SQLServerCentral.com, http://dba.stackexchange.com, and forum sites such as SQL Server Central.  And there’s always a bunch of us keeping half an eye on the Twitter #SQLHelp hashtag, and we’re trying that in Google+ too.

As well as the various electronic hang-outs, you’ll find branches of the family physically hanging out in different places – at conferences such as SQLBits in the UK, PASS in the US, and at various user groups across the world.  And everyone’s so friendly and helpful.

Like family members, we’re prepared to travel to help each other out – even to the point of interrupting a family holiday to go to a user group meeting.  Or is that just me?  In the UK, it’s not unknown for people to travel 100+ miles after work to get to a user group meeting – and I know that one’s not just me!

Like a real family, though, we don’t tolerate those who seek to attack us, or put us down.  We have recently seen one Twittish Twitterer try attacking one of Da Family, and he found he bit off more than he could chew.  Within a very short space of time, the #SQLFamily had circled the wagons and mounted a defence.  Jorge “SQLChicken” Segarra (blog|twitter) has a description of what went on.  (Yes, his post is about “SQL Community”, but the community does feel like a family to many of us.)  Unfortunately, there have been other incidents.

(Sorry, interrupted by a member of my #SQLFamily who wants career advice – from me!  I’ve not been in this part of the game as long as he has, so he should know what to do, but apparently this thing works both ways…  I hope things work out for him.)

Where was I?  Oh yes.

But #SQLFamily isn’t just about those out there.  It’s also about the guys you work with, your colleagues on a day-to-day project-by-project basis.  You do what you can to help them get better, to deliver the best projects you can, and hope that they do the same for you.  In this way, you gradually build up your own network of colleagues and associates, and you’ll know who to go to when you need help; similarly, they’ll come to you when they need help.  I’ve long been convinced that part of the way to get ahead is “who you know” rather than “what you know”, and this has been proved right.  (Cheers, J.  And N.  I’m sure we’ll be in touch again!)

In short, you look after the family, they’ll look after you.

And now I’ve managed to earworm myself with Mama Morton’s song from Chicago.  I need help.  Or curry.  Or both.