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

such as control files, data files, or online redo logs are called media failures. They can be caused by file malfunctioning
host bus adapters or problems with a file system. Failing disks causing SAN storage to become unavailable are less
common with enterprise storage arrays which use elaborate protection mechanisms internally. A media failure most
often requires the database administrator to move the affected files off that particular mount point to another one.
Bugs in applications or errors caused by application changes implemented during maintenance windows can
cause logical corruption. If that corruption cannot be corrected by rolling the changes back a restore operation is
also often unavoidable. Not every change comes with a rollback script, and many rollback scripts have received little
attention and testing.
Finally sometimes the Oracle database might discover corrupted blocks requiring block media recovery. In this
case instead of restoring and recovering the whole data file only parts need to be restored and recovered. Again, a
working backup strategy is required when you want to perform Block Media Recovery, or BMR for short. Block Media
Recovery has changed very little since the last major release and therefore will not be covered here.
RMAN backups
Recovery Manager stores backups in two formats: image copies of data files or so-called backup sets. An image copy,
as the name suggests, is a one-to-one copy of the source file. A backup set on the other hand is a RMAN specific
format containing one or multiple backup pieces. A backup set can contain all files needed to restore a database, such
as the server parameter file, control files, archived redo logs, and data files. Database administrators eyed the backup
sets suspiciously at first since RMAN is the only tool to access them. Over time this suspicion has subsided. However,
backup sets benefit from unused block compression and null block compression, potentially reducing the size of
backup set. Additionally, you have the option to apply binary compression of backup sets.
Incremental vs. full backups
Two different kinds of backups exist in RMAN: incremental and full backups, the latter being the default. A full
backup, as the name suggests, backs up every component of the database needed for restoring it. Since full backups
always include everything needed for a complete restore, they can become real space hogs. Incremental backups are
different: rather than backing up everything each time, they only back up what has changed since the last backup.
Since there has to be a starting point, the initial incremental backup will—like a full backup—include all the physical
structures required to restore the database. This backup is not called a full backup, it is referred to as an incremental
backup of level 0, or base backup. Unfortunately a full backup as described earlier cannot be used as a level 0 backup.
Subsequent backups will be of level 1, building on the foundation laid by the level 0 backup and include only what
has changed since the level 0 backup has been taken. Incremental backups can further be divided into cumulative
and differential backups, again with the latter as the default. The cumulative backup will back up all changes since
the last level 0 backup. A differential incremental backup will only back up changes since the last backup, regardless
whether it was level 0 or a previous level 1 backup. Cumulative backups are normally larger in size compared to a
differential backup.
Cumulative backups can offer an advantage over differential backups. If your backup strategy consisted of a level
0 backup on the weekend and cumulative incremental backups on the weekdays, then your restore only required the
application of the level 0 backup plus the latest cumulative backup. With differential backups you have to restore the
level 0 backup followed by a restore of each differential backup. In summary you are trading recovery time against disk
space. On the other hand, if a differential backup is small in size there is merit in using it instead.
The duration of incremental backup directly depends on the number of blocks that changed. Instead of reading
every data file to ascertain which blocks have changed since the last backup, Oracle can be instructed to use a change
tracking file instead. This so-called block-change tracking (BCT) file contains bitmaps that identify which blocks have
changed since the last backup. There are a maximum of eight bitmaps maintained to cover the last eight backups. You
should keep this in mind when designing your backup strategy; the eight bitmaps are usually sufficient for a week's
worth of backups. After the eighth bitmap has been used Oracle will wrap around and start at the beginning of the
change tracking file again, potentially degenerating the performance of the backup.