OCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P73 pot

OCA/OCP Oracle Database 11g All-in-One Exam Guide 67 6 9. þ A. You join the views V$PROCESS and V$SESSION on the ADDR and PADDR columns and select rows where the beginning of the column CLIENT_ INFO contains the string RMAN. ý B, C, D, and E. B is wrong because there is no such view as V$BACKUP_ SESSION. C, D, and E are wrong because you use V$BACKUP_ASYNC_IO and V$BACKUP_SYNC_IO to monitor performance of RMAN jobs for asynchronous and synchronous I/O, respectively. 10. þ D. If you set BACKUP_TAPE_IO_SLAVES to TRUE, then RMAN allocates tape buffers from the shared pool unless the initialization parameter LARGE_ POOL_SIZE is set, in which case RMAN allocates tape buffers from the large pool. ý A, B, and C. The parameters JAVA_POOL_SIZE and PGA_AGGREGATE_ TARGET have no effect on the location of the RMAN buffers. CHAPTER 18 User-Managed Backup, Restore, and Recovery Exam Objectives In this chapter you will learn to • 053.6.1 Recover from a Lost TEMP File • 053.6.2 Recover from a Lost Redo Log Group • 053.6.3 Recover from the Loss of a Password File • 053.6.4 Perform User-Managed Complete Database Recovery • 053.6.5 Perform User-Managed Incomplete Database Recovery • 053.6.6 Perform User-Managed Backups • 053.6.7 Identify the Need for Backup Mode • 053.6.8 Back Up and Recover a Controlfile 677 OCA/OCP Oracle Database 11g All-in-One Exam Guide 678 The backup tool recommended by Oracle Corporation is RMAN, the Recovery Manager. However, there may be circumstances where it is not the best solution. In some cases (such as damage to a controlfile copy or an online log file) it may be quicker to repair damage using manual techniques, and in some environments there may be hardware- and operating system–based backup facilities available that cannot easily be brought into the RMAN server-managed backup system. That having been said, always consider using RMAN and always question recommendations not to use it. There is often a political problem with backups: historically, backup and restore often fell within the system administration domain, not the database administration domain; using RMAN can involve a transfer of responsibilities that may not be welcome. This can mean that the decision is not informed solely by technical considerations and may not be made in the best interests of the database users. User-managed (as opposed to server-managed, meaning RMAN) backup, restore, and recovery techniques are fully supported by Oracle, and all database administrators must practice them diligently. They are tested in the OCP examinations. Backup and Recovery in One Page Figure 18-1 summarizes user-managed backup and recovery. Backup can be offline (meaning that the database is shut down) or online (meaning that it is available for use). Restore and recovery can be complete (meaning no loss of data) or incomplete (meaning that you do lose data). Most of this chapter is variations on the steps shown in Figure 18-1. User-Managed Database Backup User-managed backup is accomplished with whatever operating system facilities happen to be available and SQL*Plus commands. These may be as simple as the copy command on Windows, or cp on Unix. The significance of archivelog mode for the backup techniques available is the same for user-managed backup as for server-managed backup: in noarchivelog mode, backup must be closed and whole; in archivelog mode, it can be open and partial. In neither case is an incremental backup possible: operating system facilities are not Oracle aware and will not be capable of identifying blocks that have changed since the last backup, in the way that RMAN can. The granularity of any user-managed backup or restore operation is the datafile, not the individual blocks. Backup in Noarchivelog Mode Strictly speaking, there are two file types to consider: the datafiles and the controlfile. There is no necessity to back up tempfiles, because in the event of damage they can always be recreated with no loss of data, and there is no necessity to back up the online redo log files, because (provided the database is shut down cleanly before Chapter 18: User-Managed Backup, Restore, and Recovery 679 PART III a backup) they too can be re-created if necessary. However, most DBAs will include tempfiles and online log files in a backup, as this can make restore simpler. The technique is simply to shut down the database cleanly and copy it. These are examples of SQL commands that will generate a set of Unix commands to be executed from an operating system prompt to perform a whole backup: select 'cp ' || name || ' /u01/backups' from v$controlfile; select 'cp ' || name || ' /u01/backups' from v$datafile; select 'cp ' || name || ' /u01/backups' from v$tempfile; select 'cp ' || member || ' /u01/backups' from v$logfile; TIP It is important to use scripts to generate backup commands. If you rely on naming conventions and standard file locations (such as an assumption that all datafiles are suffixed lowercase “.dbf” and reside in a subdirectory of the ORACLE_BASE), then you will miss any files that happened to be created without following those rules. Figure 18-1 The one-page guide to backup and recovery OCA/OCP Oracle Database 11g All-in-One Exam Guide 680 EXAM TIP What files must be backed up when running in noarchivelog mode? The controlfile and the full set of datafiles. The database must be shut down cleanly first. TIP If the database is shut down cleanly, you will not need to back up the online redo log files. But if some error caused the instance to abort before the backup, then if you did not include the online redo log files in the backup you would not be able to open the database after a restore, because the necessary recovery would not be possible. Backup in Archivelog Mode In archivelog mode, it is possible to perform open database backups. The problem with open backups is consistency: it is quite possible that a file will be updated while it is being copied. In the case of online log files, this problem is avoided by never backing them up: they are archived instead. As on online log file can only be archived when it is no longer current, it will be consistent. To ensure consistency of the controlfile, rather than attempting to copy it use the SQL command ALTER DATABASE BACKUP CONTROLFILE. This command will take a read-consistent snapshot of the controlfile and generate the backup from this. There are two forms of the command: alter database backup controlfile to <filename> ; alter database backup controlfile to trace as <filename> ; The first form will generate a binary backup: the output file will be an exact, read- consistent copy of the current controlfile. The second form generates a logical backup: in the nominated file there will be a set of SQL commands that can be used to create a new controlfile that contains the same information on the physical structures of the database as the current controlfile. The CREATE CONTROLFILE command, which must be executed in nomount mode, will generate a new controlfile in the locations specified by the CONTROL_FILES parameter; to run this successfully, you must know the names of all the datafiles and the online redo log files. EXAM TIP Following a CREATE CONTROLFILE OPERATION, the new controlfile will contain only data regarding physical structures; data regarding, for example, RMAN backups will be lost. It is not possible to ensure consistency of the datafiles. The problem is the granularity of the operating system’s copying. Whatever copy utility is used, it will copy files one operating system block at a time. But when the DBWn process writes to a datafile, it will write an Oracle block. Typically, the operating system block will be different from the Oracle block, in size or in boundaries or both. Consider the case where the operating system block size is 1KB (the Linux default) and the Oracle block is 8KB (the DBCA default): when you launch an operating system copy command, the operating system will bring the command onto CPU, and it will start work. Perhaps Chapter 18: User-Managed Backup, Restore, and Recovery 681 PART III it has time to copy four operating system blocks (half an Oracle block) before the operating system’s preemptive multitasking algorithm takes the command off CPU. Then the operating system might give some CPU time to the DBWn process, which could overwrite the Oracle block with a new version from the database buffer cache. Then the operating system puts the copy command back onto CPU, and it continues to copy the remainder of the Oracle block—which will be from the new version. In the copied file, this block will be fractured—internally inconsistent, because it was updated while being copied. Fractured blocks are useless. Of course, you might be lucky: the copy could go through without encountering this problem. But you cannot rely on this. Note that RMAN, being aware of the Oracle block formatting, can detect if a block was changed while being copied, and will retry until it gets a consistent version. When making an open backup of a datafile, the tablespace must be put into backup mode. In backup mode, the datafile header is frozen, the datafiles are checkpointed, and the redo generation algorithm is adjusted. In normal running, redo is limited to the minimal change vector applied to a block; in backup mode, no matter how small the change vector is, the entire block is written out to the redo stream. This version of the block in the redo stream will be read consistent. This means that if the datafile copy has fractured blocks, they can be replaced with the read-consistent versions of the blocks in the redo stream, which will be available in the archived log files. So when making an open backup, you accept that the datafile copies may be damaged, but this doesn’t matter because the information necessary to repair them is available elsewhere. While a tablespace is in backup mode, the rate of redo generation for all DML against objects in the tablespace will increase substantially. A change that might normally generate only a hundred bytes of redo will generate a full block (perhaps 8KB) instead; you will find that the database is log-switching much more frequently— perhaps every couple of minutes instead of every half hour. For this reason it is good practice to place tablespaces in backup mode one at a time, for the shortest possible period. The commands to enable and disable backup mode for a tablespace are alter tablespace <tablespace_name> begin backup ; alter tablespace <tablespace_name> end backup ; A tablespace’s datafiles can be copied safely between the two commands. Or to enable backup mode for all tablespaces at once, alter database begin backup ; alter database end backup; Changes made to blocks of temporary tablespaces are not protected by redo, and it is therefore not possible to back them up safely while the database is open. EXAM TIP There is no difference between backing up tablespaces of user data, and backing up the SYSTEM, SYSAUX, or UNDO tablespaces: just copy the datafiles while the tablespace is in backup mode. But you cannot backup temporary tablespaces: you can’t even put them into backup mode. OCA/OCP Oracle Database 11g All-in-One Exam Guide 682 Exercise 18-1: Carry Out a User-Managed Backup In this exercise, you will first create a tablespace and a table within it, and then make a backup of the tablespace and of the controlfile. 1. Create a tablespace, with a command such as this for Unix: create tablespace ex181 datafile '/u01/app/oracle/oradata/orcl/ex181.dbf' size 10m extent management local segment space management auto; or this for Windows: create tablespace ex181 datafile 'c:\app\oracle\oradata\orcl\ex181.dbf' size 10m extent management local segment space management auto; 2. Create a table in the new tablespace: create table t1 (c11 date) tablespace ex181; 3. Put the tablespace into backup mode: alter tablespace ex181 begin backup; 4. Back up the datafile, using a command such as this for Unix: cp /u01/app/oracle/oradata/orcl/ex181.dbf /tmp/ex181.dbf.bak or this for Windows: ocopy c:\app\oracle\oradata\orcl\ex181.dbf c:\temp\ex181.dbf.bak Note the use of the ocopy.exe utility here: this is a program provided by Oracle (you will find it in %ORACLE_HOME%\bin) that can copy open files, unlike some of the standard Windows utilities. 5. Take the tablespace out of backup mode: alter tablespace ex181 end backup; 6. Make a binary backup of the controlfile, nominating any suitable destination, for example: alter database backup controlfile to '/tmp/cf.bin'; 7. Make a logical backup of the controlfile, nominating any suitable destination, for example: alter database backup controlfile to trace as 'c:\temp\cf.log'; 8. Inspect the file generated in Step 7. Study all the commands and read all the comments. Many of the commands will be investigated shortly. Backup of the Password and Parameter Files It is possible (though, it must be said, unlikely) that consistency issues could affect backup of the password file and of the dynamic parameter file; they could be updated by the instance while being copied. So to be certain, they too should be backed up in a way that will ensure that they can be restored with no problems: a simple copy of the files may not be adequate. Chapter 18: User-Managed Backup, Restore, and Recovery 683 PART III To back up the password file, keep a copy of the command used to create it. For example, on Unix, orapwd file=$ORACLE_HOME/dba/orapwd<SID> password=oracle users=5 or on Windows, orapwd file=%ORACLE_HOME%\database\PWD<SID>.ora password=oracle users=5 where <SID> is the instance name. If the password file should ever be damaged, simply run the script to recreate it. To back up the spfile, from a SQL*Plus prompt generate a text file. For example, create pfile='init<SID>.ora' from spfile; If the dynamic parameter file should ever be damaged, recreate it with this command, which can be executed even while the instance is shut down, before nomount mode: create spfile from pfile='init<SID>.ora' ; A static parameter file can be safely backed up with a simple operating system copy command, because by its nature it will be consistent; the instance cannot write to it. Media Failure That Does Not Affect Datafiles The technique to restore and recover following media failure resulting in damage to one or more files is dependent on the type of file or files damaged. In some cases, there will be no downtime—the end users may not even be aware that a problem ever occurred—and in most cases, provided the database is operating in archivelog mode, there will be no loss of data. Recovery from Loss of a Multiplexed Controlfile As long as a surviving multiplexed copy of the controlfile exists, recovery from loss of a controlfile is simple. Just replace it with a surviving copy of the controlfile. To restore the damaged or missing controlfile copy from a backup would be useless in these circumstances, because all copies of the controlfile must be identical; clearly, a restored copy would not be synchronized with the surviving copies, nor with the rest of the database. Virtually the moment the damage occurs, the instance will terminate. As ever, the DBA’s first reaction to a crashed instance should be to attempt a startup. This will fail, in NOMOUNT mode, with an appropriate error message. The alert log will state which controlfile copy is missing, and also—in the section listing the nondefault initialization parameters—how many controlfile copies there actually are, and where they are. At this point, you have three options. First, you could edit the parameter file to remove the reference to the missing or damaged controlfile copy, as shown in Figure 18-2. OCA/OCP Oracle Database 11g All-in-One Exam Guide 684 This is fine, but your database will now be running on one less multiplexed copy, which will presumably be in breach of your security guidelines. A better option is therefore to replace the damaged file with a copy made from a surviving copy or indeed to change the CONTROL_FILES initialization parameter to replace the reference to the damaged file with a reference to a brand new file, which is a copy of one of the surviving controlfiles made when the instance is completely shut down. EXAM TIP Recovering from loss of a controlfile will entail downtime. It cannot be done online. Figure 18-2 Removing the reference to a damaged controlfile Chapter 18: User-Managed Backup, Restore, and Recovery 685 PART III Exercise 18-2: Recover from Loss of a Controlfile In this exercise, you will simulate the loss of a multiplexed controlfile and replace it with a copy. 1. Connect to your database with SQL*Plus, and ensure that your controlfile is multiplexed with this query: SQL> select * from v$controlfile; This query must return at least two rows. If it does not, multiplex your controlfile by following the instructions given in Chapter 14, illustrated in Figure 14-4. 2. Simulate damage to a controlfile by crashing the database (shutdown abort) and renaming one of your controlfiles. Note that on Windows you may have to stop the Windows service before Windows will let you rename the file, and start it again afterward. 3. Issue a startup command. The startup will stop in nomount mode, with an “ORA-00205: error in identifying controlfile, check alert log for more info” error message. 4. Copy your surviving controlfile to the name and location of the file you renamed. 5. Issue another startup command, which will be successful. TIP Many DBAs do not like to copy a surviving controlfile over a damaged one, because it is all too easy to copy accidentally the damaged controlfile over the surviving one. Do not laugh at this. It is safer to copy the surviving controlfile to a new file, and edit the CONTROL_FILES parameter to change the reference to the damaged file to the new file. Recovery from Loss of a Multiplexed Online Redo Log File Provided that the online redo log files are multiplexed, loss of one member will not cause any downtime, but there will be messages in the alert log telling you that there is a problem. If you can tolerate the downtime, you can shut down the database and copy a surviving member of the group over the damaged or missing member, but clearly this is not an option if the database must remain open. For open recovery, use the ALTER DATABASE CLEAR LOGFILE command to delete the existing files (or at least, those that still exist) and create new ones. This can be done only if the log file is inactive. If you attempt to clear the current log file group, or the previous one that is still active, you will receive an error (as shown in Figure 18-3). Furthermore, if the database is in archivelog mode, the log file group must have been archived. TIP Recovery from loss of a multiplexed online redo log file can be done while the database is open, and therefore does not entail any downtime. . backup mode for a tablespace are alter tablespace <tablespace_name> begin backup ; alter tablespace <tablespace_name> end backup ; A tablespace’s datafiles can be copied safely between. the two commands. Or to enable backup mode for all tablespaces at once, alter database begin backup ; alter database end backup; Changes made to blocks of temporary tablespaces are not protected. Oracle Database 11g All-in-One Exam Guide 682 Exercise 18-1: Carry Out a User-Managed Backup In this exercise, you will first create a tablespace and a table within it, and then make a backup