NetVault Plug-in for Oracle 12.2

The plug-in provides you with the option during the restore process to define the Restore Source or location that RMAN should use as the source for the restore. This option lets you speed up restores by ensuring that RMAN restores from the FRA or from the NetVault Backup media. With this option, you can:

•

Restore from the FRA even if the backup is also available on NetVault Backup media such as disk-based media, VTL, or tape.

•

Restore from the NetVault Backup media when the FRA is suspected to have a media failure or data corruption and you do not want to risk restarting the restore and recovery process due to RMAN’s inability to restore from the FRA.

Additionally, you can use these same Restore Source options when you have performed CLI-based backups to Disk by allocating a channel to Disk but you want to use the plug-in to perform the restore.

The following Restore Source options are available:

•

NetVault Backup Media Manager: When selected, RMAN opens an “SBT_TAPE” channel and reads the backup files from the backup media that is managed by NetVault Backup and specified in the Device options section of the Target tab. Select this option if an FRA-backup-destination strategy has not been implemented or the Backup Destination of NetVault Backup Media Manager was selected for all backups.

•

Disk (Restore from FRA or Disk): When selected, RMAN only opens a DISK device type and restores the backup files from the FRA or the OS-specific directory specified when configuring RMAN’s DISK device type. This option is the default.

•

Both NetVault Backup Media Manager and Disk (Restore from both NetVault Backup Media and (FRA or Disk)): When selected, RMAN opens an “SBT_TAPE” channel and a DISK channel, which allows RMAN the flexibility to choose the best source for the recovery files. Select this option if your backup destination strategy includes the Both NetVault Backup Media Manager and Disk option or you have chosen to store backup recovery files in the FRA while performing Flash Recovery Area Backups on a different, independent schedule.

Datafile media recovery

Datafile media recovery is the application of online logs, archived redo logs, or Incremental Backups to a restored datafile to update it to the current time or some other specified time. Datafile media recovery, often called Recovery, is either Complete Recovery or Point-in-Time (PIT) Recovery, also called Incomplete Recovery. PIT Recovery is one way to respond to a data loss caused by a user error, such as dropping a table, or logical corruption that goes unnoticed for some time.

Complete Recovery vs. Point-in-Time (PIT) Recovery

Complete Recovery recovers the database to the most recent time without the loss of any committed transactions. With PIT Recovery, you can recover the database to a specific point. The plug-in supports PIT Recovery based on time, log sequence number, or system change number. Currently, the plug-in supports only Database Point-in-Time Recovery (DBPITR).

•

System Change Number (SCN) Based Point-in-Time Recovery: When an SCN is specified during PIT Recovery, RMAN recovers up to, but not including, the specified SCN. For example, if SCN 1000 is specified, recovery up to SCN 999 is performed.

•

Log Sequence Number (LSN) Based Point-in-Time Recovery: When the exact time of the data corruption or failure is not known, specifying a Log Sequence Number that contains the target SCN is a viable option. RMAN recovers through the specified log. V$LOG_HISTORY can be queried to view the logs that have been archived to identify the appropriate log sequence number and thread.

•

Time Based Point-in-Time Recovery: Time-based PIT Recovery is useful when the time that the data corruption occurred is known. For example, if a developer dropped a table at 6:00 a.m., PIT Recovery can be performed with a stop time of 5:55 a.m. The plug-in recovers up to, but not including, the specified time.

For more information on PIT Recovery and database incarnations, see Performing Database Point-in-Time Recovery in the Oracle Database Backup and Recovery Basics guide.

Block Media Recovery

Block Media Recovery is only available in the Oracle Enterprise Edition. This feature reduces downtime by letting you recover only the blocks that were corrupted instead of restoring and recovering the entire datafile. Block Media Recovery is most useful for physical corruption problems that involve a small, well-known number of blocks. Block-level data loss usually results from intermittent, random I/O errors that do not cause widespread data loss, and memory corruptions that get written to disk. Block Media Recovery is not intended for cases where the extent of data loss or corruption is unknown and the entire datafile requires recovery. In such cases, Datafile Media Recovery is the best solution.

You can use Block Media Recovery to recover one or more corrupt data blocks within a datafile. Block Media Recovery provides the following advantages over Datafile Media Recovery:

•

It lowers the MTTR because only blocks needing recovery are restored and recovered.

•

It lets the affected datafiles remain online during recovery.

Without Block Media Recovery, if even a single block is corrupt, you must take the datafile offline and restore the datafile from a backup. You must apply all redo logs generated for the datafile after the backup was created. The entire file is unavailable until media recovery completes. With Block Media Recovery, only the blocks actually being recovered are unavailable during the recovery.

Prerequisites

In addition to running the Oracle Enterprise Edition, Oracle requires the following prerequisites for Block Media Recovery to be met as defined in Performing Block Media Recovery of the Oracle Database Backup and Recovery User’s Guide.

•

The target database must run in ARCHIVELOG mode and be open or mounted with a current Control File.

•

The target database must not be a standby database.

•

The backups of the datafiles containing the corrupt blocks must be Full or Incremental Level 0 backups and not proxy copies.

•

RMAN can use only archived redo logs for the recovery. RMAN cannot use Incremental Level 1 Incremental Backups. Block Media Recovery cannot survive a missing or inaccessible archived redo log, although it can sometimes survive missing redo records.

•

Flashback Database must be enabled on the target database for RMAN to search the flashback logs for good copies of corrupt blocks. When flashback logging is enabled and contains older, uncorrupted versions of the corrupt blocks, RMAN can use these blocks, possibly speeding up the recovery.

Identifying corrupted blocks

The V$DATABASE_BLOCK_CORRUPTION view displays blocks marked corrupt by database components such as RMAN commands, ANALYZE, and SQL queries. Physical corruption, sometimes called media corruption, results in rows being added to this view. For example, the database does not recognize the block: the checksum is invalid, the block contains all zeros, or the block header is fractured.

In addition to being reported in V$DATABASE_BLOCK_CORRUPTION, block corruption is also reported in the following locations:

•

Results of the LIST FAILURE, VALIDATE, or BACKUP … VALIDATE command

•

Error messages in standard output

•

Oracle Alert Log

•

User trace files

•

Results of the SQL commands ANALYZE TABLE and ANALYZE INDEX

•