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

OCA/OCP Oracle Database 11g All-in-One Exam Guide 57 6 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 Chapter 15: Back Up with RMAN 579 PART III • 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; Chapter 15: Back Up with RMAN 581 PART III 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 Chapter 15: Back Up with RMAN 583 PART III 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. Chapter 15: Back Up with RMAN 585 PART III 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. . 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. 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. 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.