Hack-Attaching a SQL Server database with NORECOVERY

Let me just startthis post with a huge disclaimer/warning: what I'm about to show you in this post is NOT SUPPORTED by Microsoft at all. It's a hack , and it might not work whatsoever in your environment.

But I think it's pretty cool.

You might have probably heard about hack-attaching a database . It'sa verygood thing to know, and a powerful tool when you need it. That's not supported by Microsoft either (technically speaking), but I've seen folks use it. I may or may not have used it more than once :)

Whenever you attach a database to SQL Server, crash recovery is executed against it - and it is always brought online automatically. Requests from the community - and vendors, even - to Microsoft to implement a means to attach a database with NORECOVERY (such that you can later apply transaction log backups to it) have gone nowhere - closed as "Won't fix" in Connect . Some folks have blogged on their approach to how to do this, but I have found myself with mostly suspect or plain unusable databases while trying them.

In this post I will detail the steps that worked for me tomake this possible - and even initializing an AlwaysOn Availability Groups replica leveraging a hack-attached database with NORECOVERY.

In a Pure Storage-hosted post I used StackOverflow's publicly-accessible database to discuss dedupe and compression in our arrays - in this post I use that database again.

To get started, I logged on to CSLAB-SQL00, and I took a VSS snapshot of thevolume where the dataand logfiles for this database live. Please note that you don't really need VSS for certain storage arrays, like Pure Storage FlashArrays, which always generates crash-consistent snaps and copies. Since a Pure Storage array is all I have access to, this is what I will use for the purposes of this blog post, but I wanted to use VSS to keep the process generic and applicable to other storage arrays.

Please note that the failed COM call shown above can be safely ignored, per this Microsoft KB article .

Using theFlashArray GUI, I create a volume from the snapshot:

The GUI asksfor a name for the new volume, so I picked one:

Now let's present the new volume to CSLAB-SQL01,a different serverattached to the same array. In this case I could also leverage the array's replication capabilities to have a snapshot, possibly of a protection group if your data and log files live on a separate volume, replicated to another array.

Presenting a volume to a host using the GUI couldn't be easier. Click on the gear icon, choose Connect Hosts and select the host you want. Then click Confirm , and off you go.

I now log on to CSLAB-SQL01, and issue a Rescan Diskson Disk Management. Keep in mind thatall of this could bescripted using Pure's Powershell SDK . This guy pops up on the list:

And now I usesome DISKPART goodnessto bring the volume online, and with a new disk signature, which is needed here only because CSLAB-SQL00 and CSLAB-SQL01 are nodes of the same windows Server Failover Cluster (WSFC) , and clear out some attributes:

If you're wondering where I got that GUID from, I executed [GUID]::NewGuid() on another Powershell window. You could also execute SELECT NEWID() on any SQL Server instance to get a new GUID.

I mounted the new volume on X:\SqlData2 then grantedNT SERVICE\mssqlSERVER full control on the files.

To confirm that SQL Server can access the files, I issued a convenient DBCC CHECKPRIMARYFILE:

Much like in the traditional hack-attach approach, we create an empty database on the target instance. This is going to be on the X:\SqlData mount point/volume. You will need to make sure that file names and database file IDs match, otherwise you might not get things to work.

If you have Instant File Initialization (IFI) enabled, and you use a FlashArray volume to hostthis empty database,itwill take very little space -- and it will only take a few seconds tocreate. In my test machine, this took about 650Kb of actual disk space and less than 2 seconds to complete.

I then took a full backup of the empty database (to FILE='nul', of course) and a tail of the log backup, to bring the empty database to Restoring status:

Now, we stop SQL Server and replace the volume mounted on X:\SqlData with the one that was mounted on X:\SqlData2, and start SQL Server again.

If you try to bring the database to STANDBY/Read-only, you should get something similar to this:

But CONTINUE_AFTER_ERROR comes to the rescue:

Now pay attention to the message that got cropped on my screenshot above: if you use Service Broker with your original database, you will have to enable it later.

We now have a database in STANDBY. Could we possibly restore some transaction log backups on top of it? You bet! I went to the source database, and created a dummy table with 1000 rows, then took a transaction log backup:

I copiedthe transaction log backup file to the target host (CSLAB-SQL01). This is what I got when I tried to restore it -- same error as when I put the database in STANDBY, basically:

Yep, CONTINUE_AFTER_ERROR to the rescue, again:

The database is now in NORECOVERY! To confirm I have a good database, I put the database in STANDBY again, then proceed to query the dummy table:

1000 rows there, so it looks like all is well. But is my database COMPLETELY clean?