There is a semi-hidden para at the end of the SnapVault Deployment and Configuration Tech Report TR-3240 addressing databases (quoted below). This addresses what to do after you have already created the initialized base 0 transfer. We are testing this now using Solaris/Oracle/R150.
Don
============================================================================ ==================== 4.5. Special Case: Databases and Application Server Backups Simply scheduling a Snapshot on a database volume may not create a safe, consistent image of the database. Most databases can be backed up while they continue to run and provide service, but must first be put into a special hot backup mode. Other databases need to be quiesced (which means that they momentarily stop providing service) and some need to be shut down completely, enabling a cold backup.
In any of these cases, you must take certain actions before and after the Snapshot is created on the database volume. Since these are the same steps you should take for any other backup method, your database administrators probably already have scripts that perform these functions.
While one could set up SnapVault Snapshot schedules on such a volume and simply coordinate the appropriate database actions by synchronizing the clocks on the filer and database server, it is easier to detect potential problems if the database backup script creates the Snapshots using the snapvault snap create command.
In this example, we want to take a consistent image of the database every four hours, keeping the most recent day's worth of Snapshots (six copies), and we want to retain one version per day for a week. On the SnapVault secondary, we will keep even more versions.
The first step is to tell SnapVault the names of the Snapshots to use and how many Snapshots to keep. No schedule should be specified because all Snapshot creations will be controlled by the database backup script.
* toaster> snapvault snap sched oracle sv_hourly 5@-
This schedule takes a Snapshot called sv_hourly, and retains the most recent six copies, but does not specify when to take the Snapshots.
* toaster> snapvault snap sched oracle sv_daily 1@-
This schedule takes a Snapshot called sv_daily, and retains only the most recent copy. It does not specify when to take the Snapshot.
* toaster> snapvault snap sched oracle sv_weekly 1@-
This schedule takes a Snapshot called sv_weekly, and retains only the most recent copy. It does not specify when to take the Snapshot.
Once this has been done, you must write the database backup script. In most cases, it will have the following structure:
[ first commands to put the database into backup mode ] rsh toaster snapvault snap create oracle sv_hourly [ end with commands to take the database out of backup mode ]
You would then use a scheduling application (such as cron on UNIX(r) systems or the Windows Task Scheduler program) to take an sv_hourly Snapshot each day at every hour other than at 11 p.m. A single sv_daily Snapshot would be taken each day at 11 p.m., except on Sunday evenings when an sv_weekly Snapshot would be taken instead.
In most cases, it is entirely practical to run such a database backup script every hour because the database only needs to be in backup mode for a few seconds while the script creates the Snapshot. ============================================================================ ======================
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Sto Rage(c) Sent: Wednesday, December 01, 2004 8:48 PM To: Alec Devroey Cc: toasters@mathworks.com Subject: Re: OSSV SnapVault
We have been using OSSV for a while for both Windows and Unix, but not for any Databases yet. AFAIK the current verison is yet to support database functions. It is expected in the next release Ver 3. But check out the version from SyncSort, they claim to have database support. But they have clients only for Windows for now. -G
On Wed, 1 Dec 2004 22:43:13 +0100, Alec Devroey alec.devroey@simac.be wrote:
prohibited.
and