Two small experiences using SQL Server Database Snapshots in a SAP...

http://blogs.msdn.com/b/saponsqlserver/archive/2008/03/06/two-small...

Two small experiences using SQL Server Database Snapshots in a SAP landscape
Juergen Thomas - MSFT 6 Mar 2008 5:40 AM

The usage of Database Snapshot of SQL Server 2005/2008 is documented to a good degree in Books Online of SQL Server 2005/2008. One also can find pretty good documentation and backgrounder on SQL Server Database Snapshots here: http://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-5bfcf076d9b9 /DBSnapshotPerf.docx In our own Microsoft IT landscape we are using Database Snapshot more and more often as kind of restore point for things like applying SAP Support Packages and other activities, which perform irreversible changes to the data. The aim behind using Database Snapshots is to be able to revert back to such a Database Snapshot in case something goes wrong instead of completely restoring the database. Sure one could perform a similar thing with different storage driven Technologies as well. However we are not using those storage driven technologies out of various reasons in our Microsoft SAP landscape This Blog will report about two issues which one has a hard time to find documented and which only can be experienced using this nice feature.

Creating a snapshot will roll back all open transaction in the snapshot
In one customer case we performed massive changes to our SAP ERP application. Between the different phases of this upgrade we decided to take SQL Server Database Snapshots to have a point to re-enter the upgrade procedure again in case something failed during the upgrade. One of the steps of the upgrade was to create multiple indexes on several large tables with more than 100GB volume in parallel. By human error, the creation of a snapshot got started while 3 of these larger indexes were still in the phase of creation. The result was that the creation of the snapshot seemed to hang. Means in the Query Window the query to create the snapshots seemed to run and even after 30min still was running. However the Database snapshot files did exist. Checking the DMV sys.dm_exec_requests the session_id of the Query Window did tell that the current activity was to perform a ROLLBACK. At this point in time SQL Server is recovering the database snapshot as if a database goes through a crash recovery phase. The solution of this scenario also points out a drastic difference between a storage driven technologies and SQL Server Database Snapshot. As opposed to the storage driven snapshot, SQL Server Database Snapshots will be transactional consistent. Means the snapshot will not include any open transactions, but will represent the state of all committed transactions at the point in time when the first step of the recovery of the database snapshot is starting. For the scenario described above it meant not only loading the system with 3 larger indexes to be created, but a the same time rolling back all the work done so far in creating those indexes on the database snapshot in one single thread. One can imagine that this took quite some time. In the actual case it took over 1h. What we learned by that is not to create snapshots at times where we know of transactions being open since long time or to avoid using creation of snapshots during times when the workload dictated large and long transactions.

Restoring from a Database Snapshot

As explained earlier, the purpose for using database Snapshots was to have a restore point. We once hit an issue which required us to restore back to the latest snapshot taken. The command to initiate the restore looks like: RESTORE DATABASE myDatabase FROM DATABASE_SNAPSHOT = snap_of_myDatabase The restore indeed was successful. It took substantially less time than getting the whole 5TBdatabase from a full backup plus multiple differential backups plus quite a number of transaction log backups. However starting the application upgrade again we saw a strange behavior of the upgrade which was not progressing in the speed as we were used to it in the test upgrades executed. Analyzing again in sys.dm_exec_requests, we found something like this (consolidated in Excel)

session_id blocking_session_id last_wait_type 331 24 132 139 189 229 0 331 331 331 331 331 PREEMPTIVE_OS_WRITEFILEGATHER LATCH_EX LATCH_EX LATCH_EX LATCH_EX LATCH_EX

wait_resource

LOG_MANAGER (0000000024960578) LOG_MANAGER (0000000024960578) LOG_MANAGER (0000000024960578) LOG_MANAGER (0000000024960578 LOG_MANAGER (0000000024960578

We saw similar situations several times. Since the wait resource was pointing to the LOG Manager the next step was to check the Transaction Log, which to our surprise was by far not the 35GB it originally had before the restore, but was close to 1GB and steadily was grown automatically. Analyzing the situation, it became clear, that the PREEMPTIVE_OS_WRITEFILEGATHER basically indicated that this thread was zeroing out the parts of the transaction log file which just got added by autogrowth. Autogrowth kicked in because the transaction log was full. As designed this process of extending a filled up transaction log was

1 of 2

14.3.2011 . 10:29

Two small experiences using SQL Server Database Snapshots in a SAP...

http://blogs.msdn.com/b/saponsqlserver/archive/2008/03/06/two-small...

blocking all other threads from writing into the transaction log. Drilling into the fact why the transaction log was not at its origin size of 35GB after the restore from the snapshot, it figured out that SQL Server 2005 and SQL Server 2008 are deleting the origin transaction log as part of the restore from snapshot and just create a 1MB sized transaction log independent of the volume of your database or the origin size of the transaction log. This certainly is an unexpected behavior which is contrary to any restore activity of a tape or other backup device. SQL Server 2008 will remain to behave this way. So keep it in mind and immediately after the restore from snapshot to manually grow the transaction log to the size needed.

Comments

MSDN Blog Postings Two small experiences using SQL Server Database Snapshots in a SAP landscape 6 Mar 2008 6:24 AM

PingBack from http://msdnrss.thecoderblogs.com/2008/03/06/two-small-experiences-using-sql-serverdatabase-snapshots-in-a-sap-landscape/

smqi 16 Aug 2008 2:02 AM

where can I find them in Spaish version about the article?

2 of 2

14.3.2011 . 10:29