OCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P63 docx

Server-Managed Open Backups An absolutely reliable open backup can be made using RMAN with a two-word command issued at the RMAN prompt: BACKUP DATABASE.. This RMAN script performs a ful

OCA/OCP Oracle Database 11g All-in-One Exam Guide

576

8 þ A This is the correct sequence.

ý B, C, D, and E B, C, and D are wrong because enabling archiving is not necessary (it will occur automatically) E is wrong because a backup is a

necessary part of the procedure

9 þ A and C These are the two conditions.

ý B and D While these are certainly good practice, they are not

requirements

10 þ C Once all the online log files need archiving, DML commands will be

blocked

ý A, B, and D A is wrong because the instance will remain open B is wrong

because only sessions that attempt DML will hang; those running queries can

continue D is wrong because this cannot happen automatically.

CHAPTER 15

Back Up with RMAN

Exam Objectives

In this chapter you will learn to

• 051.15.1 Create Consistent Database Backups

• 052.15.2 Back Up Your Database Without Shutting It Down

• 052.15.3 Create Incremental Backups

• 052.15.4 Automate Database Backups

• 052.15.5 Manage Backups, View Backup Reports, and Monitor the Flash Recovery Area

• 053.2.2 Define, Apply, and Use a Retention Policy

• 053.5.1 Create Image File Backups

• 053.5.2 Create a Whole Database Backup

• 053.5.3 Enable Fast Incremental Backup

• 053.5.4 Create Duplex Backups and Back Up Backup Sets

• 053.5.5 Create an Archival Backup for Long-Term Retention

• 053.5.6 Create a Multisection, Compressed, and Encrypted Backup

• 053.5.7 Report on and Maintain Backups

• 053.4.1 Configure Backup Settings

• 053.4.2 Allocate Channels to Use in Backing Up

• 053.4.3 Configure Backup Optimization

577

OCA/OCP Oracle Database 11g All-in-One Exam Guide

578

Oracle’s recommended backup and recovery tool is RMAN, the Recovery Manager Using RMAN is not compulsory: Oracle Corporation still supports backups created with operating system utilities (as described in Chapter 18), but RMAN has functionality that is simply not available with other products It is possible to use RMAN out of the box, but most DBAs will need the more advanced facilities and will carry out a considerable amount of configuration to make these easier to use There is an RMAN interface in Database Control that can be used to generate simple RMAN jobs and to schedule their execution, and there is also a command-line interface that gives access

to all the facilities However, the most common technique for running RMAN is undoubtedly through scripts These and other advanced capabilities will be dealt with in Chapter 17

Backup Concepts and Terminology

A backup carried out with operating system commands is known as a user-managed

backup A backup carried out by RMAN is known as a server-managed backup There are

three decisions to make before carrying out a server-managed backup Should it be

• Closed or open?

• Whole or partial?

• Full or incremental?

A closed backup is carried out when the database is shut down; alternative terms for closed are cold, consistent, and offline An open backup is carried out while the database

is in use; alternative terms are hot, inconsistent, and online An open backup can only

be made if the database is in archivelog mode A whole backup is a backup of all the datafiles and the control files A partial backup is a backup of a subset of these In most

circumstances, partial backups can only be made if the database is in archivelog mode

A full backup includes all used blocks of the files backed up An incremental backup

includes only those blocks that have been changed since the last backup An

incremental backup can be cumulative (including all blocks changed since the last full backup) or differential (including all blocks changed since the last incremental backup)

EXAM TIP An open backup can only be made if the database is in archivelog

mode If the database is in noarchivelog mode, only closed backups are possible and (if using RMAN) the database must be in mount mode, following a clean shutdown

Any combination of these is possible Many sites perform closed, whole, full backups during weekly or monthly maintenance slots, and open, whole, incremental backups daily Partial backups are often carried out more frequently for particularly volatile files, or following direct load operations that do not generate redo

The file types that can be backed up by RMAN are

• Datafiles

• Controlfile

• Archive redo log files

• SPFILE

• Backup set pieces

Files that cannot be backed up by RMAN include

• Tempfiles

• Online redo log files

• Password file

• Static PFILE

• Oracle Net configuration files

RMAN can generate three types of backup:

• A backup set is a proprietary format that can contain several files and will not

include blocks of a datafile that are not currently part of a segment

• A compressed backup set has the same content as a backup set, but RMAN will

apply a compression algorithm as it writes out the backup set

• An image copy is a backup file that is identical to the input file An image copy

is immediately interchangeable with its source, whereas to extract a file from a

backup set requires an RMAN restore operation

Backup sets (compressed or not) can be full or incremental; an image copy, by its

very nature, can be only full A backup set is a logical structure containing one or more

input files; physically, it consists of one or more pieces, which are the output files of a

backup operation

RMAN backup and restore operations are carried out by server processes known as

channels A channel is either of type disk (meaning that it can read and write backups

on disk) or of type SBT_TAPE (meaning that it is capable of reading and writing

backups stored on a tape device)

The RMAN repository is metadata about backups: the names and locations of the

pieces that make up the backup sets, and the files contained within them, and the

names and locations of image copies The repository is the key to automating restore

and recovery operations: RMAN reads it to work out the most efficient way of restoring

and recovering damaged datafiles The repository is stored in the controlfile of the target

database, and optionally in a set of tables created in a catalog database Use of a catalog

substantially enhances RMAN’s capabilities

RMAN operations are launched, monitored, and controlled with the RMAN

executable This is a user process that can establish sessions against several databases

concurrently First, the RMAN executable will always connect to the target database The

target is the database that is going to be backed up, or restored and recovered Second,

the RMAN executable can connect to a repository in a catalog database—if this has

been configured Third, RMAN can connect to an auxiliary database An auxiliary

database is a database that will be created from a backup of a target database

OCA/OCP Oracle Database 11g All-in-One Exam Guide

580

Using the RMAN BACKUP Command

to Create Backups

All the types of backup that RMAN can create are launched with the BACKUP command Previous versions have a COPY command, used to create image copies, which is still supported for backward compatibility, but the functionality of this has now been subsumed into the BACKUP command Backups can be made interactively with the RMAN executable or Database Control, but generally speaking they will be automated,

by using an operating system scheduler to run jobs, or by using the Enterprise Manager job scheduling system, or by using the database job scheduler This last technique is described in Chapter 22

Server-Managed Consistent Backups

An offline backup is a backup taken while the database is closed You may hear offline backups referred to as closed, cold, or consistent backups The term “closed” is

self-explanatory and “cold” is just slang, but “consistent” requires an understanding of the Oracle architecture For a datafile to be consistent, every block in the datafile must have been checkpointed, and the file closed by the operating system In normal running, the datafiles are inconsistent: there will be a number of blocks that have been copied into the database buffer cache, updated, and not yet written back to disk The datafile itself,

on disk, is therefore not consistent with the real-time state of the database; some parts

of it will be out-of-date To make a datafile consistent, all changed blocks must be flushed to disk, and the datafile closed As a general rule, this only happens when the database is shut down cleanly—with the IMMEDIATE, TRANSACTIONAL, or NORMAL shutdown options

An RMAN-consistent backup can be accomplished only when the database is in mount mode This is because RMAN needs to read the controlfile in order to find the datafiles If a user-managed operating system backup were attempted in mount mode,

it would be invalid (though the DBA wouldn’t realize this until attempting to restore) because even in mount mode the controlfile might be written to while being copied The copy would then be inconsistent, and therefore useless RMAN avoids the problem

by taking a read-consistent snapshot of the controlfile and backing that up

An RMAN backup is launched from the RMAN executable The RMAN executable

is a tool supplied by Oracle and installed into the Oracle Home RMAN logs on to the database (like any other user process) and then launches additional server processes

to copy files In general, there are three techniques for using RMAN: an interactive interface, for performing ad hoc tasks; a script interface, for running jobs through the operating system’s scheduler; and an Enterprise Manager interface, for generating scripts and defining jobs to be scheduled by Enterprise Manager

This is an RMAN script for performing an offline whole full backup:

run {

shutdown immediate;

startup mount;

allocate channel d1 type disk;

backup as backupset database

format 'd:\backup\offline_full_whole.bus';

alter database open;

}

The first two commands within the run{} block perform a clean shutdown and

then bring the database back up in mount mode Then the script launches a server

process, known as a channel, to perform the backup In this case, the channel is a disk

channel because the backup is being directed to disk; the alternative channel type is

SBT_TAPE (or type SBT is also syntactically acceptable), which is used for backups

directed to a tape device The next command launches a backup operation This will

be of type BACKUPSET Backup sets are an RMAN-proprietary structure that can

combine many input files into one output file Backup sets have other advantages,

such as compression (not enabled in this example) and the ability to reduce the size

of the backup by ignoring blocks in the input datafiles that have never been used, or

are not in use at the moment The keyword DATABASE instructs RMAN to back up the

entire set of datafiles and the controlfile RMAN will never back up online redo log

file members or tempfiles The FORMAT keyword names the file that will contain the

backup set: the backup piece Finally, the script opens the database

EXAM TIP RMAN will never back up the online redo log files, or the

tempfiles It will back up datafiles, archivelog files, the controlfile, and the spfile

The script could be entered and executed interactively, from an RMAN prompt

Alternatively, if the script were written with an editor (such as vi on Unix or the

Windows Notepad) and saved to a file offline_full_whole.rman, an operating

system command that could be scheduled to run this script is

rman target sys/oracle@orcl11g @offline_full_whole.rman

This command launches the RMAN executable, with the SYS login (necessary because

of the SHUTDOWN and STARTUP commands) to a target database identified by the

Oracle Net alias orcl11g, and then specifies the name of the script, which must be

preceded by an “@” symbol

Exercise 15-1: Automate a Consistent Backup In this exercise, use the

Database Control job scheduling system to perform an automated offline backup

1 Connect to the database with Database Control as user SYS

2 On the Availability tab, take the Schedule Backup link in the Manage section

3 In the Schedule Backup window, select the radio button for Whole Database

and enter an operating username and password for host credentials, if these

have not already been saved as Preferred Credentials The username should

have read and write permissions on the ORACLE_BASE directory structure

Click the SCHEDULE CUSTOMIZED BACKUP button

OCA/OCP Oracle Database 11g All-in-One Exam Guide

582

4 In the Schedule Customized Backup: Options window, select the radio

buttons and check boxes for Full Backup, “Use as the base of an incremental backup strategy,” Offline Backup, and “Also backup all archived logs on disk.” Click NEXT

5 In the Schedule Customized Backup: Settings window, note that the default destination is to the flash recovery area Click NEXT

6 In the Schedule Customized Backup: Schedule window, accept the default schedule, which will run the backup immediately Click NEXT

7 In the Schedule Customized Backup: Review window, observe the RMAN commands that will be run, and click SUBMIT JOB

8 The job will take a few minutes to run, during which the database will be shut down and restarted

9 To confirm the success of the operation, reconnect to Database Control and from the database home page on the Availability tab, take the Backup Reports link in the Manage section

10 In the View Backup Report window, click the links for the name of the job and

the status to see the full details of the job

Server-Managed Open Backups

An absolutely reliable open backup can be made using RMAN with a two-word command issued at the RMAN prompt: BACKUP DATABASE This command relies

on configured defaults for the destination of the backup (disk or tape library), the names of the backup files generated, the number of server channels to launch to carry out the backup, and the type of backup (image copies of the files, backup sets, or compressed backup sets)

This RMAN script performs a full whole online backup of the database and the archive log files:

run {

allocate channel t1 type sbt_tape;

allocate channel t2 type sbt_tape;

backup as compressed backupset filesperset 4 database;

backup as compressed backupset archivelog all delete all input;

}

The script launches two channels that will write to the tape library The device driver for the tape library (supplied by the hardware vendor) must have been installed The use of multiple channels (possibly related to the number of tape drives in the library) will parallelize the backup operation, which should make it run faster The first backup command backs up the complete database (all the databases and the controlfile) but rather than putting every file into one huge (even though compressed) backup set, it instructs RMAN to divide the database into multiple backup sets, each containing no more than four files; this can make restore operations faster than if all the files are in one backup set The second backup command will back up all the

archive log files (by default, into one backup set) removing them from disk as it does

so The commands do not specify how many pieces each backup set should consist of:

by default, only one

TIP Some RMAN commands can be run independently from the RMAN

prompt; others must be included within a run {} block of several

commands

When making an open backup, it is possible that RMAN could attempt to copy a

block of a file at the same time as the DBWn is writing to the block: this results in what is

called a fractured block A fractured block would be useless in a backup, because copying

it while it was being updated would make the copy internally inconsistent RMAN

detects fractured blocks if they occur, and will retry the block copy until it gets a

consistent version To obtain a read-consistent version of the controlfile, RMAN creates

a read-consistent snapshot copy of the controlfile, and that is what is actually backed up

EXAM TIP When creating backup sets, or compressed backup sets, RMAN

will never back up blocks that have not been allocated to a segment This

results in considerable space savings

An open or closed backup can be made of the entire database, one tablespace, or

an individual file, as in these examples:

backup as backupset format '/backup/orcl/df_%d_%s_%p' tablespace gl_tabs;

backup as compressed backupset datafile 4;

backup as backupset archivelog like '/u01/archive1/arch_1%';

The first example here will back up all the datafiles making up the GL_TABS

tablespace, and the backup set piece will be uniquely named using these format

specifiers:

• %d is the database ID

• %s is the backup set number, which increments with every set created

• %p is the piece number, starting at 1 for each set

The second example nominates one datafile, by number Datafiles can be

addressed by name or number

The third example uses a wildcard (the percentage character) to identify all

archivelogs in a certain directory whose names begin with a certain string

Incremental Backups

Why should you consider incremental backups? There are three major reasons: time,

space, and the impact on end users The time for a backup to complete may not be

important to the users, but it can be very important to the system administrators

Automated tape libraries are very expensive pieces of equipment and may well be used

OCA/OCP Oracle Database 11g All-in-One Exam Guide

584

for backing up systems other than the Oracle databases If the time required for an RMAN backup can be reduced, there will be savings in the tape library resources needed Even though the default operation of RMAN is to scan the whole datafile when backing it up incrementally in order to identify which blocks have changed, there will still be time savings because in virtually all cases it is the writing to tape that is the bottleneck, not the reading of the files By enabling block change tracking (detailed later

in this section), which obviates the need to scan the whole file, the time for the backup can be reduced dramatically The volume of an incremental backup will usually be substantially less than the volume of a full backup As discussed previously, backup sets are always smaller than the source files, or image copies, because they never include empty blocks that have never been written to and can, optionally, be compressed But incremental backups may well be just a small fraction of the size of a full backup set This will reduce the impact on the tape library or the disk resources needed The impact

on users is largely dependent on the excessive disk I/O needed for a full backup When block change tracking is enabled, an incremental backup can directly access changed blocks, which will reduce the strain on disk I/O resources substantially

Incremental backups can be made with server-managed backups, but not with user-managed backups As far as an operating system utility is concerned, the granularity of the backup is the datafile: an operating system utility cannot look inside the datafile to extract changed blocks incrementally Incremental backups must always be as backup sets or compressed backup sets It is logically impossible to make an image copy incremental backup, because an incremental backup can never be identical to the source file If it were, it wouldn’t be incremental

An incremental backup relies on a starting point that contains all blocks: this is

known as the incremental level 0 backup Then an incremental level 1 backup will extract

all blocks that have changed since the last level 1 backup, or the last level 0 backup if

there have been no intervening level 1 backups A cumulative backup will extract all

blocks that have changed since the last level 0 backup, irrespective of whether there have been any level 1 backups in the meantime

An RMAN command to make a level 0 backup is

backup as backupset incremental level 0 database;

This command relies on configured defaults for launching channels, for the number

of files to place in each backup set, and to where the backup set will be written The backup set will contain all blocks that have ever been used Many sites will make an incremental level 0 backup every weekend Then a level 1 backup can be made with this command:

backup as backupset incremental level 1 database;

This command could be run daily, to extract all blocks changed since the last level 1 (or, the first time it is run, the level 0) backup A cumulative incremental backup might

be run midweek:

backup as backupset incremental level 1 cumulative database;

This will extract all blocks changed since the level 0 backup

EXAM TIP If there is no level 0 backup, then the first level 1 differential or

cumulative backup will in fact perform a level 0 backup

TIP You can specify incremental levels higher than 1, but they don’t have any

effect and are permitted only for backward compatibility Earlier releases of

RMAN made use of them

Incremental backups will always be smaller than full backups, but the time saving

may not be as great as you might expect This is because the default behavior of an

incremental backup is to scan the entire datafile being backed up in order to determine

which blocks need to be extracted There is an advantage to this: it allows RMAN to

check for block corruption But there are many occasions when you would prefer that

the incremental backup proceed much faster This can be done by enabling block

change tracking

Block change tracking relies on starting an additional background process: the Change

Tracking Writer, or CTWR This process records the address of each block that has

been changed in a file called the change tracking file If block change tracking has been

enabled, then RMAN will read the change tracking file when doing an incremental

backup to determine which blocks need to be backed up This is far faster than

scanning the whole file

The change tracking file will be created in a location specified by the DBA, or by

default it will go to the DB_CREATE_FILE_DEST directory if this has been defined It

is initially sized at 10MB and will grow in 10MB increments, but unless the database

is terabyte sized, 10MB will be adequate The change tracking file is in the form of a

bitmap, with each bit covering 32 blocks of the database There may be a minimal

performance overhead to enabling block change tracking, but experience shows that

this is not significant To enable block change tracking and nominate the name and

location of the tracking file, use a command such as this:

alter database enable block change tracking using file

'/u01/app/oracle/oradaa/orcl/change_tracking.dbf';

To monitor the effectiveness of block change tracking, query the view V$BACKUP_

DATAFILE This view is populated every time a datafile is backed up into a backup set:

the column DATAFILE_BLOCKS is the size of the datafile, and BLOCKS_READ is the

number of blocks read by the last backup The ratio of these will show that block

change tracking is reducing the number of blocks that must be read to carry out an

incremental backup:

select file#, datafile_blocks, (blocks_read / datafile_blocks) * 100

as pct_read_for backup from v$backup_datafile

where used_change_tracking-'YES' and incremental_level > 0;

Monitoring the results of a query such as this following level 0 and level 1

cumulative and differential backups will give an indication of how effective an

incremental strategy is: if the ratio increases, perhaps backups should be carried

out more frequently