DcsSQLsnap Version 2.

0
Overview
DcsSQLsnap is a Windows 2000 application that allows for a temporary suspension and flush (quiesce) of SQL data to
the storage subsystem for single and multiple database instances. In addition, it will initiate the execution of a user
programmable script to command DataCore storage software to operate on Snapshot relationships or Asynchronous IP
Mirroring (AIM) sets.
DcsSQLsnap allows you to establish coherent snapshots of SQL databases by performing the snapshot operations
when the database is in a known state. When the snapshot source is synchronously connected to the application server,
the point-in-time snapshot occurs on the DataCore storage server.
The desired snapshot may also occur remotely at another site by using DataCore storage server AIM support. In this
case the snapshot operation is actually initiated by using the AIM marker command from the AIM source DataCore
storage server to signal the snapshot software on the AIM destination server to establish the point-in-time snapshot.
It is also possible for AIM to be used as a standalone on the application server running the SQL DB using the AIM Client
software option. In the AIM Client case the remote snapshot operation can also be initiated using an AIM marker
command; however, the AIM marker command must be issued on the local application server from within the
DcsSQLsnap script.
In all three cases the commands required to perform the snapshot and AIM operations are issued via a batch file that is
automatically executed by the DcsSQLsnap executable while the I/O is suspended and has been flushed from the
database.
DcsSQLsnap

Diagram 1 shows the layout of a SQL snapshot implementation without AIM .

Production
SQL Server

Primary Path Alternate

Storage Server Storage Server Secondary SQL Server

Primary Secondary For test, backup, etc.

Database Database
Mirror Snapshot
Database

Snapshot

Diagram 1
Notes about Diagram 1:
The left side of the diagram indicates a standard DataCore storage server using a Synchronous Network Mirror. On the
secondary storage server ( the middle of the diagram), the Snapshot software creates a point in time copy of the original
database. The Snapshot is triggered by issuing a batch command from within DcsSQLsnap.exe while the database is in
a quiesced state.
On the SQL 2000 Server from within DcsSQLsnap.exe process, an ancillary batch file called DcsSnapScript.bat is
included and gives an example of the command sequence. The Snapshot command must be executed on the
secondary storage server and therefore uses the DataCore DcsAppRcmd utility to remotely execute the desired
Snapshot command. See the DataCore Application Server Support Guide (ASSG) for the details on using the
DcsAppRcmd.
Snapshot is used both to isolate the destination volume from the application server, and to create a point-in-time image
that is in a known good state. For a database, this would mean taking the Snapshot when all transactions are
completed (quiesce State) , to prevent “torn pages” and other anomalies or errors.

NOTE: In this configuration if Snapshot groups are used (SANsymphony only) it is possible to replace the
AppRcmd/snapshot command with the snapshot SCSIgroup CLIs (command line interfaces). An ancillary batch file
called DcsSnapGScript.bat is included and gives an example of the command sequence.

APP-EGD-500-E06 2
DcsSQLsnap

Diagram 2 shows the layout of a SQL snapshot implementation with AIM.

Production
SQL Server

Primary Path Alternate

AIM

Remote
Storage Server Storage Server Secondary SQL Server
Primary Secondary Storage Server
For test, backup, etc.

Database AIM
Database
Mirror Destination
AIM Source Snapshot
Database
Database

Snapshot

Diagram 2
Notes about Diagram 2:
The left side of the diagram depicts a standard installation using a Synchronous Network Mirror. Once the database
has been quiesced on the SQL application server, then the AIM marker gets issued from the secondary storage server.
The database mirror volume on the secondary storage server is used as the AIM source volume and the AIM destination
volume is on the remote storage server (the right side of the diagram). Once the AIM marker is received on the remote
destination the Snapshot software creates a point-in-time copy of the original database on the remote storage sever.
On the SQL 2000 Server from within DcsSQLsnap.exe process, an ancillary batch file called DcsAIMScript.bat is
included and gives an example of the command sequence required to cause a Snapshot to automatically occur at the
remote site. The AIM Marker command must be executed from the secondary storage server and therefore utilizes the
DataCore DcsAppRcmd utility to remotely execute this command. See the DataCore Application Server Support Guide
(ASSG) for the details on using the DcsAppRcmd.

APP-EGD-500-E06 3
DcsSQLsnap

Diagram 3 shows the layout of a SQL snapshot implementation with AIM Client support.

Production
SQL Server

AIM Source
Database AIM

Secondary SQL Server

Remote Storage Server
For test, backup, etc.

AIM
Database
Destination
Snapshot
Database

Snapshot

Diagram 3
Notes about Diagram 3:
The diagram shows an installation with AIM Client on the SQL Application Server. On the remote storage server, the
database mirror resides on the AIM destination volume. The storage server Snapshot function creates a point-in-time
copy of the original SQL database in a quiesed state on the storage sever.
To create a Snapshot, the administrator issues an AIMsnapshot command at the application server.
On the SQL 2000 Server from within DcsSQLsnap.exe process, an ancillary batch file called DcsAIMCScript.bat is
included and gives an example of the command sequence required to cause a Snapshot to automatically occur at the
remote site. The AIM command must be executed on the AIM Client application server via the local AIM CLI.

DcsSQLsnap Syntax

APP-EGD-500-E06 4
DcsSQLsnap

The DcsSQLsnap command has two command line formats. One format is to snap only 1 database. The other is to
snap 1 or more databases. Below are examples for both formats.

Example for 1 database:

“DcsSQLsnap dbNameInst parameter”
where dbNameInst is the database name.
parameter is the parameter passed to the batch script.

Example for 1 or more databases:

“DcsSQLsnap –f dbFileName parameter”
where dbfileName is a file that contains a list of databases to snap, one per
line.
parameter is the parameter passed to the batch script.

The database name format inside dbFileName and on the command line follows:
[server\\]dbName[,instance]

DcsSQLsnap.exe suspends transaction processing for all specified databases. Once the databases are quiesced,
DcsSQLsnap.exe calls the batch file, DcsTrptScpt.bat and passes its last argument as the only argument to
DcsTrptScpt.bat. DcsTrptScpt.bat contains the Snapshot commands that are to be executed by the appropriate
storage server.
There are four scripts installed with the DcsSQLsnap package, these are examples and the user should copy the
appropriate script (based on their actual snapshot/AIM configuration) as DcsTrptScpt.bat, and then modify the script to
accommodate their database implementation (which specific disks should be affected).

NOTE: DcsSQLsnap.exe along with other DataCore software is supported on a Microsoft SQL 2000 SP3 (or greater)
server.

APP-EGD-500-E06 5
DcsSQLsnap

Implementation of DcsSQLsnap

Quiesce
Using DcsSQLsnap
SQL 2000 Server Quiesce Diagram 4 illustrates the three phases of execution for
DcsSQLsnap.exe DcsSQLsnap.
Database

Database 1. Running the DcsSQLsnap executable with correct database

DcsTrptScpt.bat parameters, suspends transactions, then calls
DcsTRspScpt.bat and waits.
IOs Logs
IOs Logs 2. DcsTrspScpt.bat issues Snapshot or AIM commands to the
storage server.

3. When the DcsTrptScpt.bat finishes, DcsSQLsnap releases

SDS
the databases to resume transactions.

Log Virtual Snapshot Log Volume

Volume PIT Image

IO Virtual Snapshot IO Volume

Volume PIT Image
Diagram 4

DcsSQLsnap.exe calls the batch file DcsTrptScpt.bat which must be in the system execute path. Within the batch file
are the site specific commands to enable a Snapshot relationship on the storage server. As mentioned before based on
the specific configuration enabling the snapshot may require remote execution of the appropriate commands. This can
be accomplished using any of a number of remote command processes such as:
• DcsAppRcmd from DataCore.
• Psexe from sysinternals.com
• Rcmd from Microsoft
• Rconsole from Microsoft
• Ssh using Cygwin

For example, the contents of DcsTrptScpt.bat might look like:

psexe.exe \\sds1 –u administrator –p password “groupstartiu.exe DatabaseGroup”
If there are different Snapshots required at different times then the script that calls DcsSQLsnap.exe could copy
different scripts into DcsTrptScpt.bat. It is also possible to use the parameter of DcsSQLsnap.exe as a method for
selecting which Snapshot to call.

APP-EGD-500-E06 6
DcsSQLsnap

Scripting
There are a variety of command line interfaces which are available for scripting that can used from within the
DcsSQLsnap script process. The type of installation (SANsymphony, SANmelody, AIM or AIM Client) and configuration
options affect how and which calls should be used in the DcsSQLsnap scripts. In addition not all interfaces are
supported in all configurations (i.e. Snapshot groups are only supported in SANsymphony). Some of the possible script
actions are:
• Disabling and Enabling Snapshots with mapstores.
• Disabling and Enabling Snapshots without mapstores.
• Freeing NMV blocks if a Snapshot destination is using NMVs.
• Disabling or Enabling Groups of Snapshots with mapstores.
• Disabling or Enabling Groups of Snapshots without mapstores.
• Updating the Image of a Snapshot
• Updating the Images of a Group of Snapshots.
• Completing a Snapshot Image
• Completing a Group of Snapshot Images.
• Flushing AIM buffers for AIM sets or groups
• Initiating a remote Snapshot to an AIM set or group with or without AIM client
• Inserting AIM custom markers to AIM sets or groups

These commands are available on the storage server or from the application server utilities. You can find more
information on Snapshot and AIM scripting on the DataCore website.

APP-EGD-500-E06 7
DcsSQLsnap

Systemic Scripting
As with all Snapshots (point in time copies (PITs)), the real issue is making the destination server recognize that the PIT
volume, on the destination server, has changed data. SQL just adds a layer of complexity to the problem.

Before any Snapshot is executed, the destination server needs to detach all applicable databases and then dismount all
volumes on the disk or disks. Once dismounted, DcsSQLsnap.exe is called. When DcsSQLsnap.exe completes, the
volumes (partitions) are remounted and the database re-attached.
Most of the scripting work is done on the destination server, so this is the logical place to run the scripts.
Systemic scripting for Snapshot entails scripts within scripts within scripts. A general outline of a master script on the
destination server would have the following steps.
1. Demote databases on destination server to single user
2. Detach databases
3. Invalidate file cache (usually done by dismounting the volumes)
4. Send call to SQL 2000 source server to run the Snapshot batch which:
a. Run timedate stamp (Error Checking discussion to follow)
b. Run ntflush on all disks of this Snapshot.
c. Copy appropriate snapshot text to DcsTrptScpt.bat (or use the DcsSQLsnap.exe parameter)
d. Call DcsSQLsnap.exe with appropriate database parameters
i. DcsTrptScpt.bat executes the commands to create the snapshot on the appropriate storage
server.
5. DcsSQLsnap.exe completes and the script continues processing on the destination server.
6. Remount volumes.
7. Check timestamp and fork accordingly (Error Checking discussion to follow).
8. Attach Databases
9. Resume destination server database processing.

Systemic Snapshot error checking

As outlined earlier, the scripting of Snapshots can be fairly complex with any number of different errors being returned
on the destination server, the source server or the storage server. If there is an error, the Snapshot might not complete
and thus the destination database engine would be working with stale data.
There is a simple procedure for checking that the entire Snapshot script processed correctly. Insert a time/date stamp
on the source volume at the time of the Snapshot and then once the script has completed to check that the time and
date on the destination are current.

The following is an example of a VBscript for time-stamping the source disk by drive letter (drive E: in this example):
Set fso = CreateObject("Scripting.FileSystemObject")
Set MyFile = fso.CreateTextFile("e:\timedate.txt", True)
MyFile.Write(now)
MyFile.Close

APP-EGD-500-E06 8
DcsSQLsnap

This next example VBscript script runs on the destination server and checks that the script is within 5 minutes of the
server clock. If it isn’t, it sends a generic error message to the system event log:
Const ForReading = 1, ForWriting = 2, ForAppending = 8
Dim fso, f
Set fso = CreateObject("Scripting.FileSystemObject")
If (fso.FileExists("e:\timedate.txt")) Then
Set f = fso.OpenTextFile("e:\timedate.txt", ForReading)
scdate = f.ReadLine
f.Close
scnow = now
scdiff = DateDiff("n", scdate, scnow)
If (scdiff > 5) Then
'wscript.echo "problem"
Set evt = Wscript.CreateObject("Wscript.Shell")
evt.LogEvent 1, "Snapshot Date Out of Range"
Else
wscript.echo "Snapshot is valid"
End If
Else
Set evt = Wscript.CreateObject("Wscript.Shell")
evt.LogEvent 1, "Can't find timedate.txt"
End If

Both of these scripts can be modified as required to alert administrators and terminate the database processes on the
destination servers. The five-minute difference was used so servers without any time syncing would work. The value
can be tightened if the source and destination servers are time-synced.

Summary

DcsSQLsnap scripting provides easy access for SQL backups and/or data mining. We recommend that the
implementation be developed and tested in a simulated environment prior to production use. Enterprise Snapshot
scripts require extensive development, debugging, error checking and testing before going into production. This text is
intended as a guideline on creating these scripts. DataCore provides Professional Services to assist customers in
creating scripting templates for their business needs.

APP-EGD-500-E06 9