Backup and Recovery - Expert Consolidation in Oracle Database 12c - page 409

The need for testing
With the basic steps of taking backups and restoring/recovering databases explained in the previous sections there
is one more item close to the author's heart. Some sites appear to be happy to only take a backup and never try
restoring it. Or not testing the backups rigorously enough. It is the author's firm belief that backup testing should be as
automated as possible, and performed as often as possible. Setting aside a small quad-core system will be enough to
restore random backups.
The benefit to this technique is that any faulty backups become apparent during a non-critical time. Many DBA
have anecdotes to tell of corrupted backups, or backups that failed silently without being noticed until the Big Day
when the backup was needed for recovery. Why not try and find out before the crisis if your backups do work? The
idea is simple: a small dedicated host has to be set aside, connected in a secure way to the backup storage location.
This setup permits that one random backup from the backup catalog can be restored on that host to attached SAN
storage every day to see if the restore and recover completes successfully. There should be a log of activity and any
failures should be escalated to the backup team straight away to allow them to take corrective measures before the
next scheduled backup. Urgent cases might even require them to trigger a manual backup.
If a complete recovery testing is not possible then you should at least consider running the RMAN validate
command against your backups to check for corruption. Although not the same as restoring the database from start to
finish, it gives you a little more confidence that the media manager can find the backup pieces and did not introduce
corruption.
Introduction to Querying RMAN metadata
Recovery Manager has a very useful set of commands allowing you to view metadata related to backups and the
target database itself. The primary commands for interrogating RMAN are list and report . For example, if you want
to know which file make up a database, you could use the following command, which should be known to Oracle
administrators. Connected to the CDB$ROOT you could expect output similar to this:
RMAN> report schema;
using target database control file instead of recovery catalog
Report of database schema for database with db_unique_name CDB1
List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1 790 SYSTEM *** +DATA/CDB1/DATAFILE/system.265.826666771
3 720 SYSAUX *** +DATA/CDB1/DATAFILE/sysaux.277.826623415
4 135 UNDOTBS1 *** +DATA/CDB1/DATAFILE/undotbs1.263.826623523
5 250 PDB$SEED:SYSTEM *** +DATA/CDB1/DD7[...]403C/DATAFILE/system.[...]6623565
6 5 USERS *** +DATA/CDB1/DATAFILE/users.264.826623523
7 590 PDB$SEED:SYSAUX *** +DATA/CDB1/DD7[...]403C/DATAFILE/sysaux.[...]623565
8 270 PDB1:SYSTEM *** +DATA/CDB1/DD7[...]F577/DATAFILE/system.[...].826617
9 630 PDB1:SYSAUX *** +DATA/CDB1/DD7[...]F577/DATAFILE/sysaux.261.8266215
10 16 PDB1:USERS *** +DATA/CDB1/DD7[...]F577/DATAFILE/users.258.826623817
11 358 PDB1:EXAMPLE *** +RECO/CDB1/E6C[...]DB6C/DATAFILE/example[...]826875289
13 20 PDB1:PDB1_TBS_1 *** +DATA/CDB1/E6C[...]DB6C/DATAFILE/pdb1_tbs_1.[...]32151
14 20 PDB1:PDB1_TBS_2 *** +DATA/CDB1/E6C[...]DB6C/DATAFILE/pdb1_tbs_2.[...].82089
15 20 PDB1:PDB1_TBS_3 *** +DATA/CDB1/E6C[...]DB6C/DATAFILE/pdb1_tbs_3.[...]75409