FAQ: SnapShot and SnapSync (KBA1014)
What is a Snapshot and how is it different to SnapSync?
A Snapshot is a "point in time" copy of a source database. The source database may be an external source or a Virtual Database created using the Delphix Engine. Snapsync is the process used by the Delphix Engine to create a Snapshot.
An initial SnapSync is performed to create a copy of data on the Delphix Engine. Incremental SnapSyncs are performed to update the copy of data on the Delphix Engine.
What is the difference between SnapSync and LogSync?
SnapSync allows multiple point in time snapshots of a linked source. In a practical sense the UI provides one or more points in time (SnapShots) from which you can provision.
LogSync enables you to select any time between two Snapshots. Collecting redo log data from the source and applying that to the dSource (backups) enables this functionality.
What is really stored in a Snapshot?
Each time a snapshot is initiated either manually or through a SnapSync the accumulated source database changes are captured in the resulting snapshot.
In the case of Oracle dSource, the initial Snapsync and snapshot captures a level 0 (full) RMAN backup of the source database inclusive archive logs. Subsequent Snapsync operations take incremental backups of the source database capturing only those Oracle data blocks which have changed since the previous Snapsync. The latest set of changed blocks are then ingested and recovered by Delphix to produce a read only file system level snapshot presenting a consistent view of the Oracle datafiles as of the snapshot time. Along with the incremental backup, Delphix will capture any archive logs generated during the backup interval. Each Snapsync will result in a new time card appearing in the GUI. Delphix also guarantees the engine has a complete set of archive logs including all sequences from all threads of redo that have been generated by the source from the oldest SnapYync through to the newest SnapSync through its log sync operations.
In the case of Microsoft SQL Server, the mechanism used to capture the initial backup and subsequent incremental backups is different. SQL Server dSources exist as a staging database on staging host referred to as a pre-provisioning target (PPT). Source data is ingested at the staging database through SQL Server transaction logs which are gathered by the engine from the source database via the Delphix Connector. After the initial backup of the source database is taken and restored to the staging host the initial time card is created. Transaction logs are then fed to the staging database which then recovers transactions as the logs arrive. Performing a SnapSync triggers a database backup. This backup can be a new full database backup taken by the Delphix Engine or some other full or differential database backup captured of the source database. Each time card associated with a SQL server dSource represents a read only file system level snapshot of the staging database within the Delphix Engine as at a specific point in time.
How are Snapshots used in the provision of a VDB?
At the time a virtual database (VDB) is created, the time card and the specific point in time selected within the GUI (or CLI) determines which of the read-only file system level snapshots will be cloned to create a new read write file system copy of the snapshot. This new copy at the file system level is then presented or pushed out to the target machine via NFS in the case of Oracle and iSCSI in the case of Windows and SQL Server. The read/write copy of the database can then be started and will exist in a state on the target as of the time selected for VDB creation. The VDB on the target host will be comprised of the file system snapshot blocks associated with the changes captured in SnapSyncs and the shared blocks that have not altered between this snapshot and the original snapshot taken at the dSources creation. To attain a specific point in time for VDB creation some recovery of redo or transaction logs would also be applied to the VDB.
What is the impact of taking a new SnapShot of a dSource?
The dSource is altered by the latest Snapsync operation. Any changes that have occurred in the source database would be captured through an incremental backup. This backup taken by the Delphix engine is used to establish a new file system level snapshot that can in turn be used as the starting point for a subsequent provision operation. This file system level snapshot then becomes a part of what Delphix considers to be the "dSource". In practical terms a new timeflow card will be visible against the dSource and available as a point in time from which to provision a new VDB.
Does the initial load of a database allow for normal operation on the database?
The initial load of a database does not interfere with other operations on the database.
How does SnapSync work with RMAN?
SnapSync links with production databases via standard RMAN APIs and requests all files and logs for the initial snapshot and compresses them in Delphix. Subsequent snapshots load only blocks changed since the last snapshot. Each snapshot generates full TimeFlow that can be instantly provisioned as a VDB.
Does Delphix work in environments that have other applications using RMAN?
Yes. Delphix does not interfere with other applications interacting with RMAN. It is advised to have SnapSync jobs be scheduled at different times from these applications to ensure mutual optimal performance.
Why are there are no RMAN incrementals (backup pieces)?
Where do they go on the Delphix Engine and why don't we see them (given that we are using RMAN on the source to push incrementals)?
A backup stream from the SBT device on the source is captured by java on the engine side (transported in more recent versions over DSP for SnapSync). When the stream comes in our DataFileBuilder implementation checks if the datafile (referenced in the header of the backup stream) resides on ZFS.
If the datafile does not exist on ZFS it means this must be the initial full backup. If the file does not exist we construct a new one (without holes) based on the stream.
If a datafile does exist on ZFS it means the stream from the source is going to be incremental.
So how do we construct a viable datafile using an incremental source ? - We use a ZFS snapshot of the previous full backup (in the initial snapsync) and then update on the changed blocks in the datafile from the incremental stream.
Should the customer force a full backup, our implementation will recognise a new file does not need to be created, we will size the new datafiles appropriately and push the stream.
How does retention affect the available Snapshots?
The number of of SnapShots available is subject to retention. Once a Snapshot is expired, it will be purged as a part of retention. Once removed, that SnapShot can not be recovered. The first snapshot taken during dSource creation is not subject to retention and will always be available.
What is the default retention policy for the snapshots and logs?
The default retention for snapshots and logs is a week. It can be changed using the Policy Management Screen. New Retention policies can be created and applied to dSources as well as VDBs.
What is the default SnapSync schedule?
By default, SnapSync runs at 3:30 AM (in the timezone used for the Delphix Engine) and has 4 hours to run. New SnapSync policies can be created and applied to dSources with different start times as well as durations.
What happens when the SnapSync does not complete within the allotted duration?
The SnapSync job is suspended and restarted during the next run SnapSync time slot. For initial loads, the job continues from where it was left off. For subsequent incremental SnapSyncs, the job will start from the beginning. Because SnapSyncs after the initial load are usually incremental, starting a suspended job from the beginning should not result in full scans of the database if BCT is enabled.
Can SnapSync be scheduled to run multiple times in a day?
Yes. Specify "By Hours or Minutes" Schedule type when creating or modifying a policy in order to schedule the SnapSync to run at a fixed interval.
Can we have multiple SnapSync policies to a dSource?
Yes. This has to be done from the CLI though. For information see the 'policy' subcommands in the "Delphix Engine Command Line Reference" document.
Can a snapshot be taken outside of a policy window?
Yes. A snapshot can be initiated outside of a policy window for a database. This can be done clicking the camera icon for the database:
How can we disable a SnapSync?
You can disable SnapSync from the Policy Management screen. Choose a None policy under SnapSync for the database of interest.
What does unlink (detach) of a dSource do?
Unlinking (detaching) disassociates a dSource from its source database, in effect it removes the link that ties the 2 objects together. You can leave a dSource unlinked indefinitely and the dSource will reflect the state of the source database as of the remaining snapshots and archive logs. An unlinked dSource is still subject to retention policies unless you explicitly remove them. You can relink (attach) to the same source database or to a different source database assuming that the new database is the same OS and Oracle version and has the same incarnation ID. So, for example, moving a dSource between primary and standby versions of the same database.
Does SnapSync use Block Change Tracking (BCT), an Oracle native feature?
BCT is an Oracle feature that tracks changed blocks in a small file on the linked database. Although it has no benefit for the initial SnapSync Snapshot, it may significantly improve performance of and reduce resource consumption on the linked database for subsequent snapshots.
SnapSync will work if BCT is not enabled also. Without BCT, RMAN will read all data files and logs to identify changed blocks, which can consume compute resources on the host. Only the changed blocks will be sent to the Delphix Engine over the network but a full scan of the database will be performed to identify these changed blocks. Hence, enabling BCT is recommended.
For more information on BCT refer to Block Change Tracking and Delphix.
My scheduled SnapSync(s) are running slowly, what should I do?
Network and database performance are the two most common areas to consider when SnapSync is thought to be running slowly.
SnapSync utilizes the Delphix Service Protocol (DSP). Testing DSP performance and paying attention to RECEIVE throughput is a good first step. Comparing the result of that test to any earlier runs may provide insight or at the very least allow this aspect to be ruled out.
Assess the source database performance in a general sense. A poorly performing source database will certainly hold back Snapsync throughput.
Understanding whether BCT is enabled on the source database is another reasonably important check when investigating SnapSync performance.
select * from v$block_change_tracking ; exit
Lastly, checking the CONTROL_FILE_RECORD_KEEP_TIME set on the source may hint at the underlying cause of a long running SnapSync.
show parameter control_file
A low value set forCONTROL_FILE_RECORD_KEEP_TIME would mean full backups of datafiles are aged out regularly. When the data files are aged out a full backup is forced even when an incremental is requested. In this sense a SnapSync job which normally runs for a few hours may run for much longer as the incremental backup is converted to a full backup, something which obviously takes more time.
Where does a VDB hook run in relation to the VDB operations - does a post-refresh hook run before or after?
VDB refresh is followed by SnapSync.
This hook will run after the virtual dataset has been started, after the Configure Clone hook. This hook will not run if the refresh or Pre-Refresh hook operations fail.
Note that these operations can restore cached data after the refresh completes.
The following image details the hook sequence:
While the above list is far from exhaustive, it does cover the more common scenarios relating to long running SnapSync jobs.
Related Articles
The following articles may provide more information or related information to this article:
- CLI Cookbook: Detaching and Attaching a dSource
- Block Change Tracking and Delphix
- Delphix Engine Command Line Reference