IntelliSnap - Best Practices - Oracle
- Use separate LUNs and mount points for Oracle data and archive log files when using IntelliSnap backups. •
- Have a multiplexed control file and redo log location on a separate volume that is not included in the snap backups for data and logs. These files are not modified during snapshot revert operations, enabling full recovery of the database.
- Prior to modifying the physical schema, perform an inline backup copy operation. This will avoid any backup copy failures due to changes in the Oracle database schema.
- If you have enabled the block change tracking file, specify its location on a device that also contains the data files for the database.
- When using a cross-machine auxiliary instance for table level restores from a snapshot, make sure that the auxiliary machine does not have a database with the same name as the source database.
- Skip IntelliSnap Backup of archive logs in the following scenarios:
- The log-volume is located on a non snap-able device.
- The instance containing the archive logs in the RAC database is not shared.
- On Oracle databases with high transaction rates. The following errors may be encountered while restoring from those snaps or during the backup copy of those IntelliSnap jobs.
ORA-00283: recovery session canceled due to errors
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 86016 change 7963079914 time 01/28/2014 09:54:46
Instead back up the archive logs using RMAN. Select the Use Rman for Log Backup check box on the Logs Backup tab of the Subclient Properties dialog box.
- Do not use nested file system mounts for IntelliSnap
- The datafiles and archive log files for each database should be isolated on their own volume groups. If volumes are shared for multiple databases, use the ‘Multi Instance Snap Optimization’ feature, which snaps and reverts all the databases together. For more information, see Multi-Instance Snap Optimization.
- Find all the data file paths and make sure that the underlying logical and physical disks for these data file paths meet all the recommendations. You can run the following query to find the Oracle data file paths.
select file_name from dba_data_files;
- Make sure that the mount folders on proxy do not have any content.
- Consider the following for ASM-based IntelliSnap backups:
- The backup copy is always performed using RMAN.
- For ASM-based IntelliSnap backups or backup copy operations, when the IntelliSnap backup option is enabled for a RDBMS instance for a subclient, the Use RMAN for Tape Movement option is not selected by default. As a work around for this issue, refresh the Client properties, or select the Use RMAN for Tape Movement option before saving the subclient properties.
- Specify kfed in the path.
- When IntelliSnap is enabled for a subclient, the Use RMAN for Backup Copy option is not selected by default. As a workaround for this issue, refresh the Instance properties or select the Use RMAN for Backup Copy option before saving the subclient properties.
- Before executing the first ASM-based IntelliSnap backup or Backup Copy job, run the following commands to make the kfed utility and ensure that it is accessible in the path:
gmake -f ins_rdbms.mk ikfed;
- Avoid using first four drive letters (A: - D:) for Oracle databases.
- Disable the Automount option.
- If you use a proxy machine, the drive letters used by Oracle on the source machine must be available and not in use on the proxy machine.
Create an IntelliSnap subclient and select the Use Rman for Log Backup check box on the Logs Backup tab of the Subclient Properties dialog box. This will perform an IntelliSnap backup for the data volume and RMAN backups for the log volume.
By default, the snapshots are visible under the NetApp NFS mount points.
The archive log directory must be configured on a subdirectory on the NFS mount point.
You can hide the snapshot copy directory. For information on how to perform this procedure, see Hiding the snapshot copy directory.