SQL Server Magazine: feature article on using database repair

The September SQL Server Magazine articles are now available on the web and include my latest feature article on Using Database Repair for Disaster Recovery.

It includes a detailed walk-through of a disaster scenario where all backups include the corruption – showing you how to run repair and then try to recover some of the damaged data from an older backup.

You can get to the article HERE (no login required).


PS Note that the posting date on the article says 2010 – the online editors at SQLMag will fix it shortly.

SharePoint in a SQL Server environment

A few weeks back I kicked off a survey asking whether you have SharePoint in your SQL Server environment at all. Here are the results:


The "Other" responses were:

  • 3 x "Not now but I did in a previous role."
  • 3 x "Yes, but the dbas do not manage their servers."
  • 2 x "SharePoint 2007 and 2010."
  • 1 x "My environment no but it's included in an MES environment."

Almost 75% of respondents have some form of SharePoint in their environment. Although I don't think is a statistically valid representation of the installed SQL Server user base, I think it confirms what I've been thinking – there's a *lot* of SharePoint out there. Remember that this is just a survey of people who read my blog – primarily SQL Server professionals – there is a huge amount more SharePoint installations where there is *no* SQL Server professional involved.

The reason that it's interesting whether SharePoint is involved in your SQL Server environment is that it can have an impact on your regular maintenance and your HA/DR strategy. Ordinarily you'd want to treat a SQL Server instance that's running SharePoint just like any other back-end SQL Server for an application, but SharePoint imposes some restrictions on you.

  • It has it's own maintenance jobs which run regularly, which means you either need to exclude that instance from your standardized maintenance setup, or disable the SharePoint jobs completely and run your own, taking into account the SharePoint guidelines.
  • There's more than one database required for SharePoint to work properly, which means that database mirroring or log shipping as HA/DR providers becomes extremely tricky. I usually recommend failover clustering with SAN replication for HA/DR to avoid complicated failover logic. Backup and restore can become more complicated too – especially when using an off-database LOB storage layer like RBS.
  • You can't create additional filegroups in the large content databases and you can't use partitioning (except for the Web Analytics service), which means taking advantage of filegroup piecemeal restore and partial database availability is not possible.
  • Auto-create statistics needs to be disabled for SharePoint, whereas in most situations you want it enabled – a departure from your standardized setup.
  • MAXDOP=1 is strongly recommended – again a departure from your standardized setup.

Some of this guidance is unfortunate, and shows that SharePoint's use of SQL Server is not as optimal as it could be, but all of this means that you need to treat a SQL Server instance that underpins SharePoint differently from your other SQL Servers.

You can read more about SQL Server configuration and maintenance when using SharePoint at:


Photos: Illinois Railway Museum


Back in May when we were out in Chicago teaching one of our classes we had a spare day so we drove an hour west into the Illinois countryside to the absolutely excellent Illinois Railway Museum.

I've always been a big train fan, stemming from the days back in the early '80s when I used to take the train back and forth to Glasgow every day on the way to school. I think many people are really little boys at heart when it comes to trains – trains never lose their excitement.

We spent about 1/2 a day wandering around their huge collection and chatting with some of the volunteers responsible for maintaining the rolling stock and engines. Of course I took a whole bunch of photos and I'm sure many of you will enjoy them.

Click on the photos for a 1024×768 enlargement.