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

Additionally Oracle will back up the control file after lots of structural changes have occurred, such as adding
multiple tablespaces, online redo log groups, renaming files etc. In versions before Oracle 11.2 a line was added in
the alert.log each time such a change occurred, and you ended up with lots of automatic controlfile backups taken
immediately after the structural change happened. This proved to be inconvenient, especially if you consider massive
releases to the database where data is reorganized and life cycle management starts. As a mitigating effect one of
Oracle's MMON slave processes is responsible for the creation of the controlfile autobackups. Instead of creating
the controlfile autobackup immediately after each change of the database structure during an application release,
the creation of the backup is deferred by a few minutes after the event. You will not see entries about controlfile
autobackups in the alert.log anymore, you need to check the trace directory within the database's Automatic
Diagnostic Repository for files named ORACLE_SID _m000_ OSPID .trc containing the information shown here:

*** 2013-09-22 17:46:06.432
*** SESSION ID:(10.23) 2013-09-22 17:46:06.432
*** CLIENT ID:() 2013-09-22 17:46:06.432
*** SERVICE NAME:(SYS$BACKGROUND) 2013-09-22 17:46:06.432
*** MODULE NAME:(MMON_SLAVE) 2013-09-22 17:46:06.432
*** ACTION NAME:(Autobackup Control File) 2013-09-22 17:46:06.432

Starting control autobackup

*** 2013-09-22 17:46:07.082
Control autobackup written to DISK device
handle '/u01/fra/ORA12/autobackup/2013_09_22/o1_mf_n_826825566_93y7pgr3_.bkp'

In the above example lots of structural changes occurred in the time leading up to 17:46 but finished approximately
at 17:40. So do not worry if you do not see a trace file immediately after those structural changes.
The Oracle database accesses and modifies the controlfile constantly. Therefore, a way has to be found to get a
consistent copy of the controlfile. The simple solution is to create a read-consistent view of the controlfile, called a
snapshot controlfile. This process is completely transparent, and in most cases you do not need to modify the location
of the snapshot controlfile unless you use Real Application Clusters.

Not ■ the snapshot controlfile must be on shared storage for real application Clusters from 11.2.0.2 onwards.

If you are not on RAC and have to, use the “configure snapshot controlfile name to” command to define the
snapshot controlfile location.
In addition to changing the snapshot controlfile location you can also define a non-default controlfile autobackup
location. The implication of changing the controlfile autobackup location is that you need to specify the exact location
when you restore it later. If you use a FRA the default location for the controlfile autobackup is your Fast Recovery Area.
The restore of a controlfile autobackup is explained later in the chapter in the Restore and Recovery section.

Technical aspects around RMAN backups
Backing up the production database directly is a very common strategy. In quiet periods, usually over night for non 24
by 7 systems, a backup is initiated according to the backup schedule and internal Service Level Agreements. After the
completion or failure, a notification is sent out to a central control system informing the database administrator of the
outcome. In most cases the administrator is not interested in being paged about a successfully completed backup, a
failure is more important and requires attention.