Storage Snapshot Optimized backups
Suggest changes
PDFs
Snapshot-based backup and recovery became even simpler back when Oracle 12c was released because there is no need to place a database in hot backup mode. The result is an ability to schedule snapshot-based backups directly on a storage system and still preserve the ability to perform complete or point-in-time recovery.
Although the hot backup recovery procedure is more familiar to DBAs, it has, for a long time, been possible to use snapshots that were not created while the database was in hot backup mode. Extra manual steps were required with Oracle 10g and 11g during recovery to make the database consistent. With Oracle 12c, sqlplus and rman contain the extra logic to replay archive logs on datafile backups that were not in hot backup mode.
As discussed previously, recovering a snapshot-based hot backup requires two sets of data:
-
A snapshot of the datafiles created while in backup mode
-
The archive logs generated while the datafiles were in hot backup mode
During recovery, the database reads metadata from the datafiles to select the required archive logs for recovery.
Storage snapshot-optimized recovery requires slightly different datasets to accomplish the same results:
-
A snapshot of the datafiles, plus a method to identify the time the snapshot was created
-
Archive logs from the time of the most recent datafile checkpoint through the exact time of the snapshot
During recovery, the database reads metadata from the datafiles to identify the earliest archive log required. Full or point-in-time recovery can be performed. When performing a point-in-time recovery, it is critical to know the time of the snapshot of the datafiles. The specified recovery point must be after the creation time of the snapshots. NetApp recommends adding at least a few minutes to the snapshot time to account for clock variation.
For complete details, see Oracle's documentation on the topic, "Recovery Using Storage Snapshot Optimization" available in various releases of the Oracle 12c documentation. Also, see Oracle Document ID Doc ID 604683.1 regarding Oracle third-party snapshot support.
Data layout
The simplest layout is to isolate the datafiles into one or more dedicated volumes. They must be uncontaminated by any other file type. This is to make sure that the datafile volumes can be rapidly restored with a SnapRestore operation without destroying an important redo log, controlfile, or archive log.
SAN has similar requirements for datafile isolation within dedicated volumes. With an operating system such as Microsoft Windows, a single volume might contain multiple datafile LUNs, each with an NTFS file system. With other operating systems, there is generally a logical volume manager as well. For example, with Oracle ASM, the simplest option would be to confine disk groups to a single volume that can be backed up and restored as a unit. If additional volumes are required for performance or capacity management reasons, creating an additional disk group on the new volume results in easier management.
If these guidelines are followed, snapshots can be scheduled directly on ONTAP with no requirement for performing a consistency group snapshot. The reason is that snapshot-optimized backups do not require that datafiles be backed up at the same time.
A complication arises in situations such as an ASM disk group that is distributed across volumes. In these cases, a cg-snapshot must be performed to make sure that the ASM metadata is consistent across all constituent volumes.
[Note]Verify that the ASM spfile and passwd files are not in the disk group hosting the datafiles. This interferes with the ability to selectively restore datafiles and only datafiles.
Local recovery procedure—NFS
This procedure can be driven manually or through an application such as SnapCenter. The basic procedure is as follows:
-
Shut down the database.
-
Recover the datafile volume(s) to the snapshot immediately prior to the desired restore point.
-
Replay archive logs to the desired point.
This procedure assumes that the desired archive logs are still present in the active file system. If they are not, the archive logs must be restored, or rman or sqlplus can be directed to the data in the .snapshot directory.
In addition, for smaller databases, datafiles can be recovered by an end user directly from the .snapshot directory without assistance from automation tools or a storage administrator to execute a SnapRestore command.
Local recovery procedure—SAN
This procedure can be driven manually or through an application such as SnapCenter. The basic procedure is as follows:
-
Shut down the database.
-
Quiesce the disk group(s) hosting the datafiles. The procedure varies depending on the logical volume manager chosen. With ASM, the process requires dismounting the disk group. With Linux, the file systems must be dismounted, and the logical volumes and volume groups are deactivated. The objective is to stop all updates on the target volume group to be restored.
-
Restore the datafile disk groups to the snapshot immediately prior to the desired restore point.
-
Reactivate the newly restored disk groups.
-
Replay archive logs to the desired point.
This procedure assumes that the desired archive logs are still present in the active file system. If they are not, the archive logs must be restored by taking the archive log LUNs offline and performing a restore. This is also an example in which dividing up archive logs into dedicated volumes is useful. If the archive logs share a volume group with redo logs, the redo logs must be copied elsewhere before restoration of the overall set of LUNs to avoid losing the final recorded transactions.
Full recovery example
Assume the datafiles have been corrupted or destroyed and full recovery is required. The procedure to do so is as follows:
[oracle@host1 ~]$ sqlplus / as sysdba Connected to an idle instance. SQL> startup mount; ORACLE instance started. Total System Global Area 1610612736 bytes Fixed Size 2924928 bytes Variable Size 1040191104 bytes Database Buffers 553648128 bytes Redo Buffers 13848576 bytes Database mounted. SQL> recover automatic; Media recovery complete. SQL> alter database open; Database altered. SQL>
Point-in-time recovery example
The entire recovery procedure is a single command: recover automatic.
If point-in-time recovery is required, the timestamp of the snapshot(s) must be known and can be identified as follows:
Cluster01::> snapshot show -vserver vserver1 -volume NTAP_oradata -fields create-time vserver volume snapshot create-time -------- ------------ --------- ------------------------ vserver1 NTAP_oradata my-backup Thu Mar 09 10:10:06 2017
The snapshot creation time is listed as March 9th and 10:10:06. To be safe, one minute is added to the snapshot time:
[oracle@host1 ~]$ sqlplus / as sysdba Connected to an idle instance. SQL> startup mount; ORACLE instance started. Total System Global Area 1610612736 bytes Fixed Size 2924928 bytes Variable Size 1040191104 bytes Database Buffers 553648128 bytes Redo Buffers 13848576 bytes Database mounted. SQL> recover database until time '09-MAR-2017 10:44:15' snapshot time '09-MAR-2017 10:11:00';
The recovery is now initiated. It specified a snapshot time of 10:11:00, one minute after the recorded time to account for possible clock variance, and a target recovery time of 10:44. Next, sqlplus requests the archive logs required to reach the desired recovery time of 10:44.
ORA-00279: change 551760 generated at 03/09/2017 05:06:07 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_31_930813377.dbf
ORA-00280: change 551760 for thread 1 is in sequence #31
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 552566 generated at 03/09/2017 05:08:09 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_32_930813377.dbf
ORA-00280: change 552566 for thread 1 is in sequence #32
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 553045 generated at 03/09/2017 05:10:12 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_33_930813377.dbf
ORA-00280: change 553045 for thread 1 is in sequence #33
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 753229 generated at 03/09/2017 05:15:58 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_34_930813377.dbf
ORA-00280: change 753229 for thread 1 is in sequence #34
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;
Database altered.
SQL>
|
Complete recovery of a database using snapshots using the recover automatic command does not require specific licensing, but point-in-time recovery using snapshot time requires the Oracle Advanced Compression license.
|