CHAPTER 15. Back Up with RMAN. Exam Objectives

Transcription

1 CHAPTER 15 Back Up with RMAN Exam Objectives In this chapter you will learn to Create Consistent Database Backups Back Up Your Database Without Shutting It Down Create Incremental Backups Automate Database Backups Manage Backups, View Backup Reports, and Monitor the Flash Recovery Area Define, Apply, and Use a Retention Policy Create Image File Backups Create a Whole Database Backup Enable Fast Incremental Backup Create Duplex Backups and Back Up Backup Sets Create an Archival Backup for Long-Term Retention Create a Multisection, Compressed, and Encrypted Backup Report on and Maintain Backups Configure Backup Settings Allocate Channels to Use in Backing Up Configure Backup Optimization 1

2 OCA/OCP Oracle Database 11g All-in-One Exam Guide 2 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

3 Chapter 15: Back Up with RMAN 3 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. PART III 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.

4 OCA/OCP Oracle Database 11g All-in-One Exam Guide 4 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 selfexplanatory 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;

5 Chapter 15: Back Up with RMAN 5 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. PART III 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 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 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.

6 OCA/OCP Oracle Database 11g All-in-One Exam Guide 6 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

7 Chapter 15: Back Up with RMAN 7 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. PART III 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

8 OCA/OCP Oracle Database 11g All-in-One Exam Guide 8 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 usermanaged 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.

9 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. Chapter 15: Back Up with RMAN 9 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: PART III 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.

10 OCA/OCP Oracle Database 11g All-in-One Exam Guide 10 Exercise 15-2: Open Incremental Backup with RMAN In this exercise you will perform an open incremental backup of the database, using the RMAN executable. 1. From an operating system prompt, launch the RMAN executable and connect to the target database, identified by the ORACLE_SID environment variable, using operating system authentication. The program is $ORACLE_HOME/ bin/rman on Unix, %ORACLE_HOME%\bin\rman.exe on Windows: rman target / 2. Run the command to make a level 1 incremental backup: backup incremental level 1 database; 3. As the backup proceeds, observe the steps: A. A channel of type disk is launched. B. The datafiles are identified. C. The channel writes out a backup set of a single piece, containing the datafiles. D. The controlfile and spfile go into a second backup set, also of one piece. The illustration shows this operation, performed on Windows. 4. Still within RMAN, run this command to list your backups: list backup of database;

11 Chapter 15: Back Up with RMAN 11 You will see the first backup, made in Exercise 15-1, is incremental level 0 and will be over 1GB. The second backup is incremental level 1, and only a few megabytes. This is because very little data has been changed between the two backups. But note that the time taken did not drop proportionately. 5. Connect to the database as user SYS with SQL*Plus. 6. Enable block change tracking, nominating the tracking file to be created. For example: alter database enable block change tracking using file '/u01/app/oracle/product/11.1.0/oradata/orcl/change_tracking.dbf'; 7. Confirm that the file has been created, and check the size: select * from v$block_change_tracking; 8. Confirm that the change tracking writer process has started: select program from v$process where program like '%CTWR%'; The next illustration demonstrates Steps 6, 7, and 8 on a Windows system. PART III 9. Confirm that the file has been created, and check the size: select * from v$block_change_tracking; 10. Confirm that the change tracking writer process has started. 11. Connect to the database with the RMAN executable, and make new level 0 and level 1 incremental backups: backup incremental level 0 database; backup incremental level 1 database; If either backup fails with errors relating to space in the flash recovery area, increase its size with a command such as this, issued from SQL*Plus: alter system set db_recovery_file_dest_size=4g; 12. From your RMAN session, rerun the query from Step 4. Note that implementing block change tracking has reduced the time taken for the incremental level 1 backup substantially.

12 OCA/OCP Oracle Database 11g All-in-One Exam Guide 12 Image Copies An image copy of a file is a byte-for-byte identical copy of an individual datafile, controlfile, or archive log file. The result is exactly as though the file had been copied with an operating system utility, though the mechanism is different: RMAN reads and writes in Oracle blocks, not operating system blocks. This means that many of the great features of backup sets (such as incremental backup, compression, writing directly to tape, or controlling the size of the output pieces) cannot be used. But it does mean that a restore can be very fast, because there is no need to extract the file from a backup set. The target database controlfile can be updated to address the image copy instead of the damaged file; in effect, no restore is actually needed if a recent image copy is available. Oracle Corporation s advice is to keep a whole image copy of the database, plus archive logs made since the backup was taken, available in the flash recovery area; this will mean that a full restore is virtually instantaneous, and recovery will be fast as well. However, the economics of disk storage may not make this possible. EXAM TIP An image copy can be used immediately, without a restore operation. Files backed up into backup sets must be restored from the backup set by RMAN before they can be used. Tape channels cannot be used for image copies, but if multiple files are to be copied, then parallelism can be considered. However, thought needs to be put into the degree of parallelism to be used. If all the copies are going to a single nonstriped disk, then there is little point in launching more than one disk channel. Also, the speed of backup to disk can have a negative impact on your users. A full-speed image copy will take up a significant amount of CPU and I/O capacity; this can be avoided by deliberately slowing down the backup process. Image copies can be made of datafiles, the controlfile, and archive logs. Image copies cannot be made of the spfile. Although image copies are made on a file-for-file basis, RMAN does let you copy many files with one command. To back up the entire database, RMAN> backup as copy database; If the configured defaults are unchanged, this command will launch one disk channel and copy all the datafiles and the controlfile to the flash recovery area. The follow-up command would be RMAN> backup as copy archivelog all delete all input; which will move all the archive log files to the flash recovery area. Protect Your Backups RMAN can back up your live database and its archive log files, and it can also back up its own backups. These can in any case be protected with backup duplexing. Consider this command: backup as backupset device type disk copies 2 database plus archivelog;

13 Chapter 15: Back Up with RMAN 13 This will back up the entire database and any archivelogs to the default disk destination (the flash recovery area) using the default number of channels (one). However, there will be two backup sets generated, each consisting (by default) of one piece, and each containing the entire database and its archivelogs. Multiplexing the backups on disk in this manner gives a degree of protection, but it will be essential to transfer the backups to tape eventually. This could be accomplished as follows: backup device type sbt_tape backupset all delete all input; TIP The keyword SBT is interchangeable with SBT_TAPE. It stands for System Backup to Tape, and refers to a nondisk backup device. This command will locate the pieces of all known backup sets on disk and copy them into another backup set in the tape library, removing them from disk as it does so. An alternative technique is to use one of these commands, which are only valid if a tape library is available: PART III backup recovery area; backup recovery files; The first command backs up the flash recovery area (both current and any previous locations) to tape, using defaults for the number of channels, sets, and pieces. The files included in the backup are full and incremental backup sets; controlfile autobackups; datafile and archive log image copies; and archive redo logs. The second command backs up all these recovery-related files, even if they are not in the flash recovery area. This structure lets you create a three-tiered backup strategy: Primary storage is the live database, on disk. Secondary storage is the flash recovery area, on disk. Tertiary storage is the tape library. A simple script to implement a backup strategy using three tiers of storage would be run {backup recovery files delete all input; backup database plus archivelog all delete all input;} The first command will move all existing backups to tape, and the second command will create a new backup of the database and any archive logs, while removing the logs from the LOG_ARCHIVE_DEST_n locations. TIP The DELETE ALL INPUT clause will not be applied to the live database; it only applies to archive logs and backups. The script relies on defaults for the number of channels and the size and naming of the backup sets and pieces.

14 OCA/OCP Oracle Database 11g All-in-One Exam Guide 14 Parallelizing Backup Operations Every time RMAN is used, there will be at least two sessions launched against the target database: these are known as the default session and the polling session. The default session is the session that invokes the kernelized PL/SQL (kernelized PL/SQL is PL/SQL that is available to the instance before a database has been mounted or opened) that implements RMAN; the polling session monitors the progress of RMAN operations. Whenever RMAN reads or writes a disk or tape, it will need a third session: a channel. A database of many gigabytes will take a long time to back up, even if the backup is a fast incremental. To reduce the time taken, parallelize the backup by launching multiple channels. The degree of parallelism achieved will be constrained by the lowest of these factors: The number of channels The number of backup sets The number of input files Each channel reads one or more files and writes one or more backups; the number of channels is therefore a hard limit on parallelism. However, parallelism is applied within a backup command, not across several backup commands, so if the command itself limits the number of backup sets generated, this may limit the degree of parallelism. Finally, it is not possible for the degree of parallelism to exceed the number of input files unless the multisection backup capability is enabled. Consider this script: run {allocate channel t1 type sbt; allocate channel t2 type sbt; allocate channel t3 type sbt; allocate channel t4 type sbt; backup database files per set 8;} The first four lines launch four arbitrarily named channels. The backup command then forces RMAN to count the number of files in the database, and distribute them into backup sets containing no more than eight files each. If the database consists of 100 datafiles plus the controlfile, 13 backup sets will be generated: the first 12 will each contain 8 files, the thirteenth will have the remaining 5 files. The degree of parallelism will be 4: constrained by the number of channels. However, if the database had only 20 datafiles, there would be only 3 backup sets produced, and the degree of parallelism would be 3; one channel would be idle. If the database had only 4 datafiles, all would go into one backup set produced serially. If a file is many gigabytes (or terabytes), then it will be desirable to parallelize the backup of this one file. Normally, only one channel can read a file, but by using the multisection keyword this behavior can be changed: run {allocate channel t1 type sbt; allocate channel t2 type sbt;

15 Chapter 15: Back Up with RMAN 15 allocate channel t3 type sbt; allocate channel t4 type sbt; backup as compressed backupset datafile 16 section size 10g;} This script will launch four channels, each of which will read a series of 10GB sections of datafile 16. Each channel will generate pieces (separate physical files) containing the backup of a section. If the file is 200GB, there will be 20 such pieces, generated four at a time. Without the SECTION SIZE keywords, the degree of parallelism would have been one (i.e., serial) and one channel would have carried out the entire operation. Exercise 15-3: Back Up Using Multiple Channels In this exercise, you will use a command block to launch multiple channels and parallelize a backup operation. 1. Connect to the database with the RMAN executable, using operating system authentication: rman target / 2. In another window, connect to the database with SQL*Plus, using operating system authentication: sqlplus / as sysdba 3. With SQL*Plus, investigate the number of sessions against the instance: select username,program from v$session order by program; You will see that there are two sessions connected as user SYS using the RMAN executable as their user process: these are the default session and the polling session. 4. At the RMAN prompt, create a command block by entering RUN followed by a series of commands within braces: run { allocate channel d1 type disk; allocate channel d2 type disk; backup as compressed backupset database; } 5. While the backup is in progress, rerun the query from Step 3. You will see that there are now four RMAN sessions: the default session, the polling session, and two channel sessions. 6. In the RMAN window, observe the progress of the backup; note how the files are divided between the two channels, each of which generates its own backup set. PART III Encrypting Backups In some environments there is a requirement for data to be encrypted. This can be particularly important for backups, because they may be stored on removable media

16 OCA/OCP Oracle Database 11g All-in-One Exam Guide 16 over which the DBA has little or no control. RMAN can encrypt backups, but there are two provisos: To create encrypted backups on disk, the Advanced Security Option must be enabled. This is a separately licensed option that must be purchased on top of the Enterprise Edition database license. To write encrypted backups directly to tape, the tape library must be accessed through the Oracle Secure Backup SBT interface, which is a separate product that must be licensed and configured for the tape library. Encryption can be transparent or password based. Transparent data encryption, which is the default, is based on the use of a wallet. This is a file containing the keys used to encrypt and decrypt data, and is itself protected with a password. However, the wallet can be configured to open automatically when needed. The wallet must be available to the RMAN channel processes when creating or restoring backups; it is therefore most useful when backups will always be created and restored on the database on the same machine. A password-encrypted backup can be restored anywhere, so long as the password is known. Each backup uses a different, randomly generated key. This key is itself encrypted with either the specified password, or the database master key stored in the wallet. The available encryption algorithms are AES with keys of length 128 (the default), 192, or 256 bits. To create a backup with password encryption, first set the algorithm and the password and then make the backup. For example, set encryption algorithm 'aes256' identified by pa55word; backup as compressed backupset database format '/u01/mnt/backups/orcl_enc.bkp'; Before attempting to restore using the backup, set the password again: set decryption identified by pa55word; If the restore operation might require many backups encrypted using different passwords, run a series of set decryption commands to specify them all. EXAM TIP The default encryption requires a wallet and will be AES128. Alternatively, a password or longer keys can be specified. Configuring RMAN Defaults The Recovery Manager is meant to be easy to use out of the box, but the defaults may well not be appropriate for any one site. By configuring the defaults, RMAN s operations can be customized to your environment. Figure 15-1 shows the use of the SHOW command, followed by three CONFIGURE commands.

17 Chapter 15: Back Up with RMAN 17 PART III Figure 15-1 Use of SHOW and CONFIGURE to set defaults The SHOW command displays RMAN s configured defaults. In the figure, they are all on their default values. These are hard-coded. To adjust these defaults, use the CONFIGURE command. The first CONFIGURE command instructs RMAN to always launch four channels when backing up to disk unless a different number of channels is specified, and to always write out compressed backup sets unless some other form of backup is specified. The second CONFIGURE command enables optimization. This allows RMAN not to back up certain files if it considers that it already has sufficient copies of the files. Optimization is related to the retention policy. The default retention policy is 1, meaning that RMAN will attempt to have at least one copy of everything. The third CONFIGURE command changes the retention policy to REDUNDANCY 3, meaning that RMAN will attempt to keep three copies of everything. The result of the configuration adjustments shown in Figure 15-1 could be seen by running SHOW ALL again. There are two possible retention policies that can be configured. A redundancy level specifies a number of copies of files that should be kept. If set to 3, then when RMAN makes a fourth backup of a file, it will consider the first backup to be redundant, and a candidate for deletion. The alternative strategy is to set a recovery window: RMAN> configure retention policy to recovery window of 90 days;

18 OCA/OCP Oracle Database 11g All-in-One Exam Guide 18 This command instructs RMAN always to keep backups of datafiles and archive logs such that it could do a point-in-time recovery to any time in the last 90 days. This requires at least one backup of every datafile that is at least 90 days old, plus all the archive logs generated since then. Backup optimization is really only applicable to archive logs and the datafiles of read-only or offline tablespaces. If optimization is enabled, RMAN will not create additional backups of files if it already has sufficient identical copies of the files to meet its retention policy. Since online read-write datafiles are always changing, RMAN will never consider that it has identical copies. To return a configured setting to its out-of-the-box default, use the CLEAR command, as in this example, which uses SHOW to check values, and CLEAR to return them to default: RMAN> show device type; RMAN configuration parameters for database with db_unique_name ORCL are: CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED BACKUPSET; RMAN> configure device type disk clear; old RMAN configuration parameters: CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED BACKUPSET; RMAN configuration parameters are successfully reset to default value RMAN> show device type; RMAN configuration parameters for database with db_unique_name ORCL are: CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default Managing and Monitoring RMAN Backups The RMAN executable provides commands for reporting on what backups have been made and what backups are required. The same information can also be obtained through the Database Control interface, or it is possible to query the RMAN repository directly by querying various views that are populated from it. If you are using a Recovery Catalog, this is another source of information. RMAN can also physically remove backups from tape and disk. The LIST, REPORT, and DELETE Commands As a general rule, LIST tells you about backups that have been made, whereas REPORT tells you what needs to be backed up. The following table shows some examples of LIST: Command RMAN> list backup; RMAN> list copy; RMAN> list backup of database; RMAN> list backup of datafile 1; RMAN> list backup of tablespace users; Function List all your backup sets. List all your image copies. List all your whole database backup sets, whether full or incremental. List the backup sets that include datafile 1 and the backups that include the USERS tablespace.

19 Chapter 15: Back Up with RMAN 19 Command RMAN> list backup of archivelog all; RMAN> list copy of archivelog from time='sysdate - 7'; RMAN> list backup of archivelog from sequence 1000 until sequence 1050; Function List all archive log backup set backups. Use this command or the next to investigate backups of archive logs. List all image copies of archive logs generated in the last seven days. List all backup sets containing archive logs of log switch sequence numbers To change the format of the dates and times in the output of LIST, set the environment variable NLS_DATE_FORMAT before launching the RMAN executable. For example, on Unix, $ export NLS_DATE_FORMAT=dd-mm-yy hh24:mi:ss or on Windows, PART III C:\> set NLS_DATE_FORMAT=dd-mm-yy hh24:mi:ss will change the date/time display to the European standard. The REPORT command interrogates the target database to determine what needs to be backed up. This requires contrasting the physical structure of the database and the archived logs that have been generated with the backup sets and copies as recorded in the repository, and applying a retention policy. The retention policy can be that configured as a default, or it can be specified as part of the REPORT command. This table shows some examples: Command RMAN> report schema; RMAN> report need backup; RMAN> report need backup days 3; RMAN> report need backup redundancy 3; Function List the datafiles (but not the controlfile or archived logs) that make up the database. Apply the configured retention policy and list all the datafiles and archive log files that need at least one backup to conform to the policy. List all objects that haven t been backed up for three days. Use this command or the next to ignore the configured retention policy. List all files of which there are not at least three backups. RMAN has a retention policy. This is a database-wide setting, which controls how many backups of each file RMAN will attempt to keep. The REPORT OBSOLETE command takes things a step further: it contrasts the RMAN backups that have been taken with the retention policy and lists all those that can be deleted because they are no longer required. This command works in conjunction

20 OCA/OCP Oracle Database 11g All-in-One Exam Guide 20 with DELETE OBSOLETE, which will remove the records of any such backups from the repository and physically remove the backup files from disk or tape. For example, RMAN> report obsolete; will apply the configured retention policy and list all copies and backup sets that are no longer required. Then, RMAN> delete obsolete; will remove the backups deemed surplus to requirements. RMAN> report obsolete redundancy 2; lists all backups that take the number of backups of an object to three or more. Then to remove the superfluous backups, RMAN> delete obsolete redundancy 2; The DELETE command can also be used to remove individual backups, by number or by tag: RMAN> delete backupset 4; RMAN> delete copy of datafile 6 tag file6_extra; Archival Backups In Oracle terminology, an archival backup is a backup that you want to keep long term, possibly forever. It will not usually be necessary to recover from an archival backup: it should be possible to restore it in order to recreate the database as it was at the time the backup was made, but you won t want to apply archived logs to it to bring it further forward in time. Often, archival backups are made purely to satisfy legislation regarding retention of records; they have little or no technical significance. An archival backup does not count toward compliance with the configured retention policy, and neither will it be deleted automatically by a DELETE OBSOLETE command. Even though it will not usually be necessary to keep the archive logs needed to recover an archival backup up to the present day, if the archival backup is an open backup then it will be necessary to keep all the archive logs generated while the backup was being taken. This is because they will be needed to make the open backup consistent, in the event of having to restore it. The syntax to create an archival backup is BACKUP... KEEP { FOREVER UNTIL TIME 'date_expr' } [ RESTORE POINT rsname ] ; The clause defining what to back up can be anything: a datafile, a tablespace, the whole database, incremental, compressed, encrypted, and so on. It can be directed to either tape or disk. However, usually, the only sensible backup target is a full backup of the whole database, and it will probably be directed through a tape channel to a tape library. The date expression can be an actual date or a calculation. An example is

21 backup database as compressed backup set keep until time 'sysdate + 90' restore point quarterly_backup ; Chapter 15: Back Up with RMAN 21 This command will write out a compressed backup, which will be considered obsolete (and therefore deletable) after 90 days. If the database is open at the time, the relevant archivelogs will be included. The Dynamic Performance Views A number of views populated from the target database controlfile can be used to report on RMAN s backups. By querying these, you can develop your own reports, rather than relying on RMAN s LIST command. View v$backup_files v$backup_set v$backup_piece v$backup_redolog v$backup_spfile v$backup_datafile v$backup_device v$rman_configuration Displays One row for each file that has been backed up, which may be a datafile, the spfile, the controlfile, or an archive log. Also, one row for each piece that RMAN has created. The column FILE_TYPE distinguishes which type of file the row refers to. One row per backup set One row per backup piece One row for each archived log that has been backed up One row for each backup that has been made of the spfile One row for backup of a datafile Names of SBT devices that have been linked to RMAN One row for every configuration setting, excluding all those on default PART III Join columns in the various views will let you construct comprehensive reports on what has been backed up, where the backups are located, and the size and type of each backup. Crosschecking Backups The information used by the RMAN commands REPORT and LIST, and the information displayed in the dynamic performance views, is drawn from the RMAN repository: data stored in the controlfile of the target database. It says nothing about reality whether the backup files actually still exist. To confirm that the backups do exist, use the CROSSCHECK command. For example: RMAN> crosscheck backup of database; using channel ORA_DISK_1 crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=/u01/app/oracle/flash_recovery_area/orcl/backupset/2008_10_20/ o1_mf_nnnd0_backup_orcl_000002_1_4hs9zcn8_.bkp RECID=5 STAMP= crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=/u01/app/oracle/flash_recovery_area/orcl/backupset/2008_10_21/ o1_mf_nnnd1_tag t165738_4hsbmv14_.bkp RECID=8 STAMP= Crosschecked 2 objects

22 OCA/OCP Oracle Database 11g All-in-One Exam Guide 22 This command queries the repository to find details of what whole backups have been made of the database, and then goes to the storage device(s) to see if the pieces do in fact exist. For pieces on disk, the disk directory is read and the file header validated; for pieces on tape, only the tape directory is read. Any pieces that no longer exist are flagged in the repository as EXPIRED. An expired backup will not be considered by RMAN when it works out how to carry out a restore and recover operation. In some circumstances (such as if a file system or a tape drive is taken offline), a crosscheck may mark many backups as expired; rerunning the crosscheck when the device is brought back into use will reset their status to AVAILABLE. A related command is RMAN> delete expired; This command will not delete any files from disk. It will, however, remove from the repository all references to backups previously marked EXPIRED by a crosscheck. At many installations, the tape library will automatically delete files according to their age: if this is happening, then a crosscheck followed by DELETE EXPIRED will update the RMAN repository to make it aware of what has happened. EXAM TIP A DELETE EXPIRED command does not delete any files, it only updates the RMAN repository. A DELETE OBSOLETE will delete files and update the repository accordingly. Exercise 15-4: Manage Backups After putting the RMAN configured settings back to defaults, use the BACKUP, LIST, REPORT, and DELETE commands to create and remove backups. 1. Connect to your database with SQL*Plus, and query the state of your flash recovery area: select * from v$flash_recovery_area_usage; 2. Connect to your database with RMAN using operating system authentication: rman target / 3. Ensure that your retention policy is set to the default, REDUNDANCY 1: RMAN> configure retention policy clear; 4. Delete all your backup sets and image copies: RMAN> delete backupset all; RMAN> delete copy all; If any backups are listed, enter YES to confirm deletion. 5. List the items that need backing up, according to the configured retention policy: RMAN> report need backup; This will list all your datafiles. 6. Choose a datafile, and back it up. In the example that follows, file 6 has been chosen: RMAN> backup datafile 6;