OCA/OCP Oracle Database 11g All-in-One Exam Guide 586 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; Chapter 15: Back Up with RMAN 587 PART III 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. 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. OCA/OCP Oracle Database 11g All-in-One Exam Guide 588 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; Chapter 15: Back Up with RMAN 589 PART III 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: 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. OCA/OCP Oracle Database 11g All-in-One Exam Guide 590 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; Chapter 15: Back Up with RMAN 591 PART III 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. 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 OCA/OCP Oracle Database 11g All-in-One Exam Guide 592 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. Chapter 15: Back Up with RMAN 593 PART III 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; Figure 15-1 Use of SHOW and CONFIGURE to set defaults OCA/OCP Oracle Database 11g All-in-One Exam Guide 594 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 Function RMAN> list backup; List all your backup sets. RMAN> list copy; List all your image copies. RMAN> list backup of database; List all your whole database backup sets, whether full or incremental. RMAN> list backup of datafile 1; RMAN> list backup of tablespace users; List the backup sets that include datafile 1 and the backups that include the USERS tablespace. Chapter 15: Back Up with RMAN 595 PART III Command Function RMAN> list backup of archivelog all; List all archive log backup set backups. Use this command or the next to investigate backups of archive logs. RMAN> list copy of archivelog from time='sysdate - 7'; List all image copies of archive logs generated in the last seven days. RMAN> list backup of archivelog from sequence 1000 until sequence 1050; List all backup sets containing archive logs of log switch sequence numbers 1000–1050. 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, 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 Function RMAN> report schema; List the datafiles (but not the controlfile or archived logs) that make up the database. RMAN> report need backup; 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. RMAN> report need backup days 3; List all objects that haven’t been backed up for three days. Use this command or the next to ignore the configured retention policy. RMAN> report need backup redundancy 3; 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 . that implementing block change tracking has reduced the time taken for the incremental level 1 backup substantially. OCA/ OCP Oracle Database 11g All-in-One Exam Guide 588 Image Copies An image. channels and the size and naming of the backup sets and pieces. OCA/ OCP Oracle Database 11g All-in-One Exam Guide 590 Parallelizing Backup Operations Every time RMAN is used, there will be at. encrypted. This can be particularly important for backups, because they may be stored on removable media OCA/ OCP Oracle Database 11g All-in-One Exam Guide 592 over which the DBA has little or no