OCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P71 potx

OCA/OCP Oracle Database 11g All-in-One Exam Guide 656 Verifying Tablespace Dependencies Other tablespaces may have objects with dependencies on objects in the tablespace to be recovered. The rules for TSPITR state that the tablespace(s) to be recovered must be self-contained, with no dependencies on objects in other tablespaces that are not to be recovered. For example, if a table has indexes they too must be recovered. Use the data dictionary view TS_PITR_CHECK to identify any dependencies, as in this example, which checks whether objects in the tablespace named INTERFACE have any dependent objects in other tablespaces, and whether objects in other tablespaces have dependent objects in the INTERFACE tablespace: SQL> select obj1_owner, obj1_name, ts1_name, 2 obj2_owner, obj2_name, ts2_name 3 from ts_pitr_check 4 where 5 ts1_name = 'INTERFACE' and ts2_name != 'INTERFACE') 6 or (ts1_name != 'INTERFACE' and ts2_name = 'INTERFACE') 7 ; no rows selected SQL> The view is populated with rows defining one-to-one relationships, where an object in the tablespace TS1_NAME has a dependent object in the tablespace TS2_NAME. The view also lists objects that cannot be included in a point-in-time recovery, such as advanced queue tables. This are indicated by the value ‘-1’ in the TS2_NAME column. To resolve any issues found, you can either temporarily remove the dependencies or add the tablespace containing objects with dependencies to the recovery set. You are better off with the latter, however, to ensure that your tables remain logically consistent with one another. Identifying Objects Lost after TSPITR In addition to resolving any dependencies with the tablespace to be recovered, you also need to identify any objects created after the target time that will be lost if you recover the tablespace. You can use the data dictionary view TS_PITR_OBJECTS_ TO_BE_DROPPED to determine which objects you will lose after your target recovery time, as in this example: SQL> select owner, name, 2 to_char(creation_time, 'yyyy-mm-dd:hh24:mi:ss') create_time 3 from ts_pitr_objects_to_be_dropped 4 where tablespace_name = 'INTERFACE' 5 and creation_time > 6 to_date('2008-07-19:21:55:00','yyyy-mm-dd:hh24:mi:ss') 7 ; OWNER NAME CREATE_TIME RJB SALES_RESULTS_2007_TEMP 2008-07-19:22:00:56 SQL> Chapter 17: Advanced RMAN Facilities 657 PART III To resolve these issues, you can export individual objects before the recovery operation and then import them after recovery is complete. Performing Automated TSPITR with RMAN The most straightforward method for running TSPITR is through RMAN, though it is also possible to carry out the eight steps listed previously manually. Connect to the target database (and to a catalog, if you have one) and run a command such as recover tablespace interface until time '18-12-08 09:01:00' auxiliary destination '/u01/app/oracle/oradata/auxdata' ; This will perform an incomplete recovery on the tablespace INTERFACE to the nominated time using the nominated auxiliary destination for the storage. The tablespace will be left offline, so to complete the procedure, bring the tablespace online. With SQL*Plus: alter tablespace interface online; Or with RMAN: sql 'alter tablespace interface online'; Exercise 17-2: Perform a Tablespace Point-in-Time Recovery In this exercise, you will set up a situation that requires a tablespace point-in-time recovery and perform this with RMAN. 1. Create a tablespace with a command such as create tablespace pitr datafile '/u01/app/oracle/oradata/orcl/pitr01.dbf' size 20m; 2. Create a table in the tablespace, and insert a row: create table t1 (c1 date) tablespace pitr; insert into t1 values (sysdate); commit; 3. From an operating system prompt, set the environment variable that will control the date format. Use this operating system session from now on, to ensure that dates are interpreted correctly. On Windows: C:\> set nls_date_format=dd-mm-yy hh24:mi:ss On Unix: $ export nls_date_format=dd-mm-yy hh24:mi:ss 4. Launch RMAN, and from the RMAN prompt back up the new tablespace: RMAN> backup tablespace pitr; 5. Using SQL*Plus, check the time and then drop the table: SQL> select sysdate from dual; SQL> drop table t1; OCA/OCP Oracle Database 11g All-in-One Exam Guide 658 6. From the RMAN prompt, perform TSPITR: RMAN> recover tablespace pitr until time '18-12-08 09:01:00' auxiliary destination '/u01/app/oracle/oradata/auxdata' ; Use the time retrieved in Step 5 as the UNTIL TIME. You can nominate any convenient directory as the auxiliary destination, but it must exist and the Oracle user must have read/write permissions on it. 7. Study the output of Step 6, relating this to the eight steps enumerated previously. 8. Using SQL*Plus, bring the tablespace online and then confirm that the table is now available again. RMAN Performance and Monitoring RMAN is implemented in PL/SQL. As a rule, PL/SQL is stored in the data dictionary and is therefore not available unless the database is open. If this were the case with the RMAN PL/SQL, it would be useless if the database were sufficiently damaged that it could not be opened; for that reason, the RMAN PL/SQL is kernelized, meaning that it is compiled and linked into the Oracle executable code, and so available even in NOMOUNT mode. All RMAN work is carried out by database sessions. Every RMAN operation will require at least two: the default session, which invokes the kernelized PL/SQL, and a polling session that reports back to the RMAN user process. The channels are further sessions that actually do the work. So tuning and monitoring RMAN becomes an exercise in tuning and monitoring the work being done by these various sessions. Monitoring RMAN Sessions and Jobs At any given point in time, you may have multiple backup jobs running, each with one or more channels. Each channel utilizes one operating system process. If you want to identify which channel is using the most CPU or I/O resources at the operating system level, you can join the dynamic performance views V$SESSION and V$PROCESS to identify the operating system processes associated with each RMAN channel. In addition to identifying the processes associated with each RMAN job, you can also determine the progress of a backup or restore operation. You can use the dynamic performance view V$SESSION_LONGOPS to identify how much work an RMAN session has completed and the estimated total amount of work. Finally, RMAN provides troubleshooting information in a number of ways, above and beyond the command output at the RMAN> prompt, when something goes wrong. You can also enable enhanced debugging to help you and Oracle Support identify the cause of a serious RMAN problem. In the following sections, you’ll be introduced to the dynamic performance views V$SESSION, V$PROCESS, and V$SESSION_LONGOPS that can help you identify and monitor RMAN backup and restore jobs. Also, you’ll learn where to look when a backup or restore job fails. Chapter 17: Advanced RMAN Facilities 659 PART III Using V$SESSION and V$PROCESS The dynamic performance view V$PROCESS contains a row for each operating system process connected to the database instance. V$SESSION contains additional information about each session connected to the database, such as the current SQL command and the Oracle username executing the command. These sessions include RMAN sessions. As a result, you can monitor RMAN sessions using these views as well. RMAN populates the column V$SESSION.CLIENT_INFO with the string rman and the name of the channel. Remember that each RMAN channel corresponds to a server process, and therefore V$SESSION will have one row for each channel. To retrieve information from V$SESSION and V$PROCESS about current RMAN sessions, join the views V$SESSION and V$PROCESS on the PADDR and ADDR columns, as you will see in the exercise. Exercise 17-3: Monitor RMAN Channels In this exercise, you will start an RMAN job that uses two or more channels and retrieve the channel names from V$SESSION and V$PROCESS. 1. Create an RMAN job that backs up the USERS tablespace using two disk channels: RMAN> run { 2> allocate channel ch1 type disk; 3> allocate channel ch2 type disk; 4> backup as compressed backupset tablespace users; 5> } starting full resync of recovery catalog full resync complete released channel: ORA_DISK_1 allocated channel: ch1 channel ch1: SID=130 device type=DISK starting full resync of recovery catalog full resync complete allocated channel: ch2 channel ch2: SID=126 device type=DISK . . . Finished Control File and SPFILE Autobackup at 27-JUL-08 released channel: ch1 released channel: ch2 RMAN> 2. While the RMAN job is running, join the views V$PROCESS and V$SESSION to retrieve the CLIENT_INFO column contents: SQL> select sid, spid, client_info 2 from v$process p join v$session s on (p.addr = s.paddr) 3 where client_info like '%rman%' 4 ; SID SPID CLIENT_INFO 126 25070 rman channel=ch2 130 7732 rman channel=ch1 SQL> OCA/OCP Oracle Database 11g All-in-One Exam Guide 660 Note that RMAN’s user processes will still exist in V$SESSION until you exit RMAN or start another backup operation. If you have multiple RMAN jobs running, some with two or more channels allocated, it might be difficult to identify which process corresponds to which RMAN backup or recovery operation. To facilitate the desired differentiation, you can use the SET COMMAND ID command within an RMAN RUN block, as in this example: run { set command id to 'bkup users'; backup tablespace users; } When this RMAN job runs, the CLIENT_INFO column in V$SESSION contains the string id=bkup users to help you identify the session for each RMAN job. Exercise 17-4: Monitor Multiple RMAN Jobs In this exercise, you’ll start two RMAN jobs and identify each job in V$SESSION and V$PROCESS using the SET COMMAND option in RMAN. 1. Create two RMAN jobs (in two different RMAN sessions) that back up the USERS and CHGTRK tablespaces and use the SET COMMAND option: /* session 1 */ RMAN> run { 2> set command id to 'bkup users'; 4> backup as compressed backupset tablespace users; 5> } . . . /* session 2 */ RMAN> run { 2> set command id to 'bkup chgtrk'; 4> backup as compressed backupset tablespace users; 5> } 2. While the RMAN job is running, join the views V$PROCESS and V$SESSION to retrieve the CLIENT_INFO column contents: SQL> select sid, spid, client_info 2 from v$process p join v$session s on (p.addr = s.paddr) 3 where client_info like '%id=%'; SID SPID CLIENT_INFO 141 19708 id=bkup users 94 19714 id=bkup chgtrk SQL> Using V$SESSION_LONGOPS The dynamic performance view V$SESSION_LONGOPS isn’t specific to RMAN either. Oracle records any operations that run for more than six seconds (in absolute time), including RMAN backup and recovery operations, statistics gathering, and long queries in V$SESSION_LONGOPS. RMAN populates two different types of rows in V$SESSION_LONGOPS: detail rows and aggregate rows. Detail rows contain information about a single RMAN job step, such as creating a single backup set. Aggregate rows apply to all files referenced Chapter 17: Advanced RMAN Facilities 661 PART III in a single RMAN command, such as BACKUP DATABASE. As you might expect, aggregate rows are updated less frequently than detail rows. EXAM TIP The initialization parameter STATISTICS_LEVEL must be set to TYPICAL or ALL before the view V$SESSION_LONGOPS will contain information about long-running RMAN jobs. The default value for STATISTICS_LEVEL is TYPICAL. This example initiates a full database backup, and while the backup is running, both detail and aggregate rows for active RMAN jobs are shown: SQL> select sid, serial#, opname, sofar, totalwork 2 from v$session_longops 3 where opname like 'RMAN%' 4 and sofar <> totalwork 5 ; SID SERIAL# OPNAME SOFAR TOTALWORK 130 39804 RMAN: aggregate output 97557 0 94 47546 RMAN: aggregate input 191692 331808 155 1196 RMAN: full datafile backup 219980 331808 155 1196 RMAN: full datafile backup 121172 0 SQL> The SID and SERIAL# are the same columns you see in V$SESSION. The OPNAME column is a text description of the operation monitored in the row, and for RMAN, it contains the prefix RMAN:. The column SOFAR is, as you might expect, a measure of the progress of a step. Its value differs depending on the type of operation: • For image copies, it is the number of blocks read. • For backup input rows, it is the number of blocks read from the files being backed up. • For backup output rows (backup set or image copy), it is the number of blocks written so far to the backup piece. • For restore operations, it is the number of blocks processed so far to the destination files. • For proxy copies (copy operations from a media manager to or from disk), it is the number of files that have been copied so far. The column TOTALWORK has a similar definition, except that it estimates the total amount of work required during the step: • For image copies, it is the total number of blocks in the file. • For backup input rows, it is the total number of blocks to be read from all files in the step. OCA/OCP Oracle Database 11g All-in-One Exam Guide 662 • For backup output rows, it is always zero because RMAN does not know how many blocks will be written into a backup piece until it is done. • For restore operations, it is the total number of blocks in all files restored in a single job step or aggregate. • For proxy copies, it is the total number of files to be copied in the job step. To calculate the progress of an RMAN step as a percentage, you can divide SOFAR by TOTALWORK as follows and add this expression to the SELECT statement: round(sofar/totalwork*100,1) Tuning RMAN You can tune RMAN operations in many ways. You can tune the overall throughput of a backup by using multiple RMAN channels and assigning datafiles to different channels. Each channel is assigned to a single process, so parallel processing can speed the backup process. Conversely, you can multiplex several backup files to the same backup piece. For a particular channel, you can use the MAXPIECESIZE and MAXOPENFILES parameters to maximize throughput to a specific output device. The BACKUP command uses these parameters in addition to FILESPERSET and BACKUP DURATION to optimize your backup operation. You can also use BACKUP DURATION to minimize the effect of the backup on response time if your database must be continuously available and you have to contend with stringent SLAs. Finally, you can also use database initialization parameters to optimize backup and recovery performance, especially for synchronous I/O operations. If you understand how each tuning method works, you can keep the user response time fast, optimize your hardware and software environment, and potentially delay upgrades when budgets are tight (which is almost always). A throughput bottleneck will almost always exist somewhere in your environment. A bottleneck is the slowest step or task during an RMAN backup. The next section reviews the basic steps that a channel performs during a backup operation. The techniques presented in the following sections will help you identify where the bottleneck is within the channel’s tasks and how to minimize its impact on backup and recovery operations. Identifying Backup and Restore Steps RMAN backup performs its tasks within a channel in one of three main phases: 1. Read phase: The channel reads data blocks into the input buffers. 2. Copy phase: The channel copies blocks from the input buffers to the output buffers and performs additional processing, if necessary: • Validation Check blocks for corruption, which is not CPU-intensive. • Compression Use BZIP2 or ZLIB to compress the block, which is CPU-intensive. Chapter 17: Advanced RMAN Facilities 663 PART III • Encryption Use an encryption algorithm (transparent, password- protected, or both) to secure the data, which is CPU-intensive. 3. Write phase: The channel writes the blocks from the output buffers to the output device (disk or tape). Using dynamic performance views, you can identify which phase of which channel operation is the bottleneck and address it accordingly. In some scenarios, you may want to increase the backup time to ensure that the recovery time will be short. Creating image copies and recovering the image copies on a daily or hourly basis will add to the backup time but will dramatically reduce recovery time. Parallelizing Backup Sets One of the simplest ways to improve RMAN performance is to allocate multiple channels (either disk or tape). The number of channels you allocate should be no larger than the number of physical devices; allocating two or more channels (and therefore processes) for a single physical device will not improve performance and may even decrease performance. If you’re writing to a single Automatic Storage Management (ASM) disk group or a file system striped by the operating system, you can allocate more channels and improve throughput, since the logical ASM disk group or striped file system maps to two or more physical disks. You can allocate up to 255 channels, and each channel can read up to 64 datafiles in parallel. Each channel writes to a separate backup copy or image copy. If the number of datafiles in your database is relatively constant, you can allocate a fixed number of channels and assign each datafile to a specific channel. Here is an example: run { allocate channel dc1 device type disk; allocate channel dc2 device type disk; allocate channel dc3 device type disk; backup as compressed backupset incremental level 0 (datafile 1,2,9 channel dc1) (datafile 3,5,8 channel dc2) (datafile 4,6,7 channel dc3) ; } Note also that you can specify the path name for a datafile instead of the datafile number, as in this example: (datafile '/u01/oradata/users02.dbf' channel dc2) To automate this process further, you can use the CONFIGURE command to increase the parallelism for each device type. Here is the default RMAN configuration for disk device channels: CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default OCA/OCP Oracle Database 11g All-in-One Exam Guide 664 TIP It is generally said that the number of channels should not exceed the number of devices. However, experience on some hardware shows that allocating several channels per device may speed up RMAN operations. Experiment, and find out what works best for your environment. Understanding RMAN Multiplexing You can improve RMAN performance and throughput by multiplexing backup and recovery operations. Multiplexing enables RMAN to read from multiple files simultaneously and write the data blocks to the same backup piece. Using multiplexing as an RMAN tuning method is one way to reduce bottlenecks in backup and recovery operations. The level of multiplexing is primarily controlled by two parameters: FILESPERSET and MAXOPENFILES. The FILESPERSET parameter of the RMAN BACKUP command determines the number of datafiles to put in each backup set. If a single channel backs up 10 datafiles and the value of FILESPERSET is 4, RMAN will back up only 4 files per backup set. The parameter FILESPERSET defaults to 64. The level of multiplexing (the number of input files that are read and written to the same backup piece) is the minimum of MAXOPENFILES and the number of files in each backup set. The default value for MAXOPENFILES is 8. Here is an equation that may make the calculation easier to understand: multiplexing_level = min(MAXOPENFILES, min(FILESPERSET, files_per_channel)) This example backs up 10 datafiles in one channel, the value for MAXOPENFILES is 12, and the value for FILESPERSET is at the default value of 64. Therefore, the multiplexing level is calculated as follows: multiplexing_level = min(12, min(64, 10)) = 10 RMAN allocates a different number and size of disk I/O buffers depending on the level of multiplexing in your RMAN job. Once the level of multiplexing is derived by RMAN using the FILESPERSET and MAXOPENFILES parameters using the aforementioned equation, you can use the information in Table 17-2 to find out how many and what size buffers RMAN needs to perform the backup. Oracle recommends that the value FILESPERSET should be 8 or less to optimize recovery performance. In other words, putting too many input files into a single backup Level of Multiplexing Size of Input Disk Buffer <= 4 16 buffers of 1MB each divided among all input files 5–8 A variable number of 512MB buffers to keep total buffer size under 16MB > 8 Total of 4 buffers of 128KB for each (512KB) for each input file Table 17-2 RMAN Datafile Buffer Sizing Chapter 17: Advanced RMAN Facilities 665 PART III set will slow down a recovery operation because the RESTORE or RECOVER command will still have to read a large number of unneeded blocks in the backup set when all you may need is to recover a single datafile. Tuning the BACKUP Command Just like the CONFIGURE CHANNEL command, the BACKUP command has parameters that can help you improve performance or limit the computing resources that a channel uses for an RMAN backup. Here are the key tuning parameters for the BACKUP command: • MAXPIECESIZE: The maximum size of a backup piece per channel • FILESPERSET: The maximum number of files per backup set • MAXOPENFILES: The maximum number of input files that a channel can have open at a given time • BACKUP DURATION: Decrease or increase the time to complete the backup You’ve seen the parameters MAXPIECESIZE, FILESPERSET, and MAXOPENFILES before. Note that MAXPIECESIZE and MAXOPENFILES have the same purpose as in the CHANNEL commands, except that they apply to all channels in the backup. BACKUP DURATION specifies an amount of time to complete the backup. You can qualify this option with MINIMIZE TIME to run the backup as fast as possible or MINIMIZE LOAD to use the entire timeframe specified in the BACKUP DURATION window. In addition, you can use the PARTIAL option, as you might expect, to save a partial backup that was terminated due to time constraints. For example, to limit a full database backup to two hours, run it as fast as possible, and save a partial backup; you may use this command: RMAN> backup duration 2:00 partial database; If the backup does not complete in the specified time frame, the partial backup is still usable in a recovery scenario after a successive BACKUP command finishes the backup and you use the PARTIAL option. Without the PARTIAL option, the backup would terminate with an error. Configure RMAN for Asynchronous I/O Whether you use synchronous or asynchronous I/O in your RMAN environment depends on several factors. These factors include the type of device you use for backup sets (disk or tape) and whether the output device or host operating system supports synchronous or asynchronous I/O. Even if the host operating system or device does not support native asynchronous I/O, you can configure RMAN to simulate asynchronous I/O using initialization parameters such as DBWR_IO_SLAVES. After you review the key differences between asynchronous and synchronous I/O, you will learn how to monitor the performance of each type of I/O using dynamic performance views, identify where the throughput bottleneck is, and adjust RMAN parameters accordingly. . channel can read up to 64 datafiles in parallel. Each channel writes to a separate backup copy or image copy. If the number of datafiles in your database is relatively constant, you can allocate. save a partial backup that was terminated due to time constraints. For example, to limit a full database backup to two hours, run it as fast as possible, and save a partial backup; you may use. catalog, if you have one) and run a command such as recover tablespace interface until time '18-12-08 09:01:00' auxiliary destination '/u01/app /oracle/ oradata/auxdata' ; This