SQL Server 2008 allowed you to slipstream service packs and cumulative updates into the installation media. In 2012 an additional and better method was created called "Product Updates" and (later) "Servicing Updates". PSS wrote a decent blog post introducing the feature.

We love Ola Hallengren's Maintenance Solution but you should always always double-check either the msdb backup history or the master.dbo.CommandLog table to make sure any important backup was taken. This is especially important if you trigger it manually and are relying on human input to get the parameters right.

Here are three easy to miss cases where the scripts won't backup a database. These absolutely, definitely, aren't bugs, they're idiosyncrasies with the underlying backup command and (sometimes) how the script works. But they're also much easier to miss in the verbose output of the script.

Normally when you add a database to an Availability Group (AG) you need to start with the database on the primary node. You restore backups With Norecovery on the secondary (either manually or with the GUI), add the database to the AG on the primary, alter the database on the secondary to reference the AG, and your job is done.

Sometimes after all the preparation you discover the wrong node is the AG primary, and you can't justify failing everything over just to add one new database in. But if you can tolerate a short outage to the database you're adding, then you can add it to the AG "in reverse" using a tail-log backup!

Warning: Please read this thread first which indicates sys.fn_dump_dblog is an internal undocumented command which can cause serious issues due to a threading bug. It's "less buggy" as of SQL 2012 SP2 and SQL 2014.

Now on with the fun and possibly dangerous code you're totally going to run only in unimportant environments that you can restart afterwards!

When investigating an issue one of the first things you might check for is which agent jobs were running at the time. Assuming your job history retention period is long enough, here's one way to do it.

When SCOM installs its databases it also creates a bunch of sys.messages. This can cause trouble when you migrate SCOM to another server or when setting up an AlwaysOn Availability Group; because after failover the messages aren't available.

One of the downsides of AlwaysOn Availability Groups (AOAG) is how new databases are not automatically added to a group and protected; unlike traditional Failover Cluster Instances with shared disks where everything is automatically protected from outages and with no further setup required.

But it's not difficult to change this.

I'm in the process of converting from the HMFAYASAL Omega theme to Ren Yuan's Leonids theme which frankly looks amazing. It's at the point where I think it's stable and have gone live with it. I'm still going through doing comparisons from the old and new site but haven't found anything significant thus far.

When SCOM is showing multiple computer objects in a critical state it can be very time consuming to use the GUI to open Health Explorer for each computer and then drill down into what the individual problems are.

I came across a System Center Operations Manager (SCOM) database recently running on SQL 2012 SP1, which was known for data corruption issues.

Updated 2017-04-26: Removed "gpupdate /force" from the end of the sample script. This can overwrite the changes you just made with the group policy you were trying to avoid in the first place!

Updated 2016-01-06: Added an extra Job_Message check.

I've been experimenting with with the Management Data Warehouse (MDW) feature which is extremely important in SQL 2014 and above because it includes the "Analysis, Migrate, and Report" (AMR) tool. Here are some excellent examples of how it works: