Oracle RMAN 11g Backup and Recovery- P8

Chia sẻ: Thanh Cong | Ngày: | Loại File: PDF | Số trang:50

Thêm vào BST

Báo xấu

211
lượt xem 23
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Oracle RMAN 11g Backup and Recovery- P8: Oracle, yet another edition of our RMAN backup and recovery book has hit the shelves! Oracle Database 11g has proven to be quite the release to be sure. RMAN has new functionality and whizbang new features that improve an already awesome product. RMAN has certainly evolved over the years, as anyone who started working with it in Oracle version 8 can attest to.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Oracle RMAN 11g Backup and Recovery- P8

318 Part III: Using RMAN Effectively Jun 11, 2009 3:37:09 PM oracle.sysman.emcp.EMDBPostConfig performConfiguration INFO: >\>\>\>\>\>\>\> The Database Control URL is https://horatio.hadba.com:1158/em
Chapter 13: Using Oracle Enterprise Manager for Backup and Recovery 319 From the Availability tab, the first thing that you need to do is configure backup settings, so click the link called Backup Settings. The Backup Settings page has three tabs, Device, Backup Set, and Policy, which are described in the following sections. Device Configuration From the Device tab, shown next, you can set up both disk and tape settings. These settings are not for setting which is the default device, but rather are individual settings for all channels on these devices. For disk backups, you set parallelism, the backup location, and the type of backup (backup set or image copy). This is also where you would turn compression on, if you want to use it. For tape backups, you tell OEM how many tape devices will be employed, and the tape backup type (compressed or noncompressed). In addition, for tapes, you can provide any environment settings that are required for the tape backup software to operate (for more on tape backup settings, see Chapters 4 through 8). Note that at the bottom of the Device tab is a place (not shown in the screen shot) for host credentials. These are required in order for OEM to submit a job to make the desired changes on the target database. This same requirement appears at the bottom of each tab of the Configure Backup Settings page. Backup Set Configuration After making device configuration decisions, click the Backup Set tab, which allows you to make permanent configuration settings for how the backup sets will be generated. Remember, this only applies to those backups that use backup sets instead of image copies (disk backups can be either; tape backups are always backup sets). If you are using disk backups, you have two things to configure here: the maximum size of your backup pieces, and the compression algorithm. The compression choice is between BZIP2 and ZLIB—with the former optimizing for maximum compression (at the cost of CPU cycles), and the latter optimizing for low CPU utilization (at the cost of less compression). If you will be Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
320 Part III: Using RMAN Effectively backing up to tape, you can set up how many copies of each datafile backup set you will create on the tape devices and the number of copies of each archive log backup to create. Policy Settings The Policy tab allows for configuration of those settings that relate to your business backup policy. This includes turning on autobackups of the control file and SPFILE, and specifying where the autobackups will be (if disk backups are used). On the Policy tab, you can turn on backup optimization (see Chapter 3 for details on backup optimization). This is also where you turn on block change tracking (see Chapter 16) and configure tablespace exclusions (see Chapter 3). Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 13: Using Oracle Enterprise Manager for Backup and Recovery 321 You also use the Policy tab to configure your retention policy. OEM provides three options: retain all backups (ack!), set a policy based on a recovery window, or set a policy based on redundancy. If you choose a recovery window or redundancy, you are required to specify how many days or how many copies, respectively. After this, you again provide host credentials and click OK to submit the changes. OEM connects to the target database host and issues the RMAN configure commands to make these changes. What Is Missing from OEM’s Backup Configuration? Not all things that RMAN can configure are configured in OEM. Some changes can be made only from the RMAN command line: ■ Backup encryption Encryption is enabled when you schedule a specific backup, not in the overall backup settings. When you go to schedule an Oracle-Suggested or Customized Backup, you can specify the Encryption level. ■ Default device type It could be argued that because you schedule backups within OEM to repeat, the default device type is not required. Regardless, you will not find it in the OEM interface. ■ Archive deletion policy From RMAN, you can set a specific archive log retention policy that is different from the backup set retention policy. No such option exists in OEM. ■ Snapshot control file location RMAN allows you to modify the snapshot control file location, which is handy for RAC configurations. OEM has no way of accomplishing this. ■ Backup throttling There is no rate command available in any OEM backups, so there is no way to throttle back the RMAN backup speed. This also holds true for the duration command that allows you to specify a backup window with the minimize time or minimize load options. RMAN Workshop: Configure Backup Settings in OEM Workshop Notes This workshop assumes that you have the v102 database and want to configure it to back up to a disk location other than the FRA with two channels, that you want filesperset to be 2, and that you want a recovery window of seven days. Step 1. Set up the disk backup settings. Click the Availability tab and then click the Backup Settings link. The default page that appears is the Device tab. Change Parallelism to 2 and Disk Backup Location to /u01/backup. Click the Test Disk Backup button to the right to confirm that the location you have specified exists. Step 2. Click the Backup Set tab. Change Maximum Backup Piece (File) Size to 500MB. Change the Compression Algorithm to ZLIB. Step 3. Click the Policy tab. Click the Automatically Backup the Control File and Server Parameter File check box. Set the Autobackup Disk Location to u01/backup (the same location as the backups in Step 1). Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
322 Part III: Using RMAN Effectively Step 4. Under the Retention Policy heading, change the policy to the second option, Retain backups that are necessary for a recovery to any time, and set the value to 7 days. Step 5. Under Host Credentials, set the host server username and password to the user that installed your database software. Then click OK. Step 6. Confirm that the changes have taken effect for this database. Connect to the host server where this database resides: Export ORACLE SID v112 rman target / RMAN> show all; using target database control file instead of recovery catalog RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; CONFIGURE CONTROLFILE AUTOBACKUP ON; … CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u01/backup/%F'; … CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO BACKUPSET; CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u01/backup/%U' MAXPIECESIZE 500 M; … CONFIGURE CHANNEL DEVICE TYPE 'SBT TAPE' MAXPIECESIZE 500 M; … Configuring Recovery Settings After configuring the backup settings, you will need to configure the database recovery settings. You can access this page from the main Availability tab of the database target by clicking the Recovery Settings link. Configuring the recovery settings actually covers a wide scope of options. On the Recovery Settings page, OEM further divides the recovery settings into three types of recovery: Instance Recovery, Media Recovery, and Flash Recovery, as described in the following sections. Instance Recovery Only one setting refers to instance recovery, FAST_START_MTTR_TARGET, as shown next. This is an initialization parameter that determines a target value, in seconds, which you are interested in hitting when instance recovery is initiated on the database. MTTR is an acronym for mean time to recover and is a common name for exactly how long it takes for a database to be operational again after it has crashed for some reason. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 13: Using Oracle Enterprise Manager for Backup and Recovery 323 Instance recovery is initiated automatically by Oracle when a database is started after a hard crash (or a shutdown abort). Instance recovery uses online redo logs and undo segments to remove any transactions that were uncommitted at the time of the crash and to set the database to a clean, synchronized state for further activity. Instance recovery must complete before the database can be started, so minimizing how long this takes affects how fast your database comes back to life after a crash. FAST_START_MTTR_TARGET is a combination of a number of changes that are made internally to facilitate the speedy recovery of your instance (also referred to as automatic checkpoint tuning). This parameter makes the LOG_CHECKPOINT_TIMEOUT and LOG_CHECKPOINT_INTERVAL parameters obsolete. From OEM, you can specify this value in seconds. The valid range is 0 to 3600 seconds (or 0 to 60 minutes). Media Recovery The ARCHIVELOG mode/NOARCHIVELOG mode switch appears in the Media Recovery section of the Recovery Settings page. It’s hard to find if no one has told you to look there—you might mistakenly start looking in, say, the Archive Logs link from the Server page of the database target. But here it is, halfway down the Recovery Settings page. It shows up here as a simple check box, but do not think that OEM has fired some magic bullet at the Oracle RDBMS: you still must reboot before this will take effect. In fact, OEM will submit a job to the OS to restart the database and perform the change. In addition to enabling ARCHIVELOG mode, you can specify your LOG_ARCHIVE_FORMAT and LOG_ARCHIVE_DEST parameters here. By default in 11g, the parameter USE_DB_RECOVERY_ FILE_DEST, also referred to as the flash recovery area (FRA), is set. In 11g, a new check box (shown next) has been added to Enable Minimal Supplemental Logging. This configures the database for additional logging required for using the LogMiner utility. Flash Recovery Under the heading Flash Recovery, you can configure your FRA, providing both an FRA destination and size. More useful, and unfortunately buried here in a configuration page, is an excellent pie graph displaying current used space in the FRA, broken down by file type. This is an excellent Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
324 Part III: Using RMAN Effectively quick view of the FRA that is hard to find anywhere else. Remember it is here under the Flash Recovery configuration settings; it can save you valuable time down the road. In addition to being where you configure the FRA, the flash recovery area is where you can turn on Flashback Database, functionality introduced in 10g that can radically reduce point-in- time recovery by rewinding the database (literally). Flashback Database, and all of the different configuration requirements and resource needs thereof, are discussed in Chapter 15. As with ARCHIVELOG mode, turning on Flashback Database requires a database reboot; we suggest that you do them both at the same time to save yourself a bit of hassle. Along with turning on Flashback Database, you can set your flashback retention time target, in hours. Note, finally, the Apply Changes to SPFILE Only check box. Checking this option is the same as changing parameters like this: alter database set db recovery file dest '/u01/fra' scope spfile; Note, of course, that checking this box will not “save” the ARCHIVELOG mode and Flashback Database changes. Either you restart the database and change them, or you wait and restart the database and change them later. Why Are My Archive Log and Flash Recovery Options Grayed Out? If you arrived at the Recovery Settings page only to find the options to turn on ARCHIVELOG mode and to modify the LOG_ARCHIVE_DEST locations grayed out in OEM (disallowing you from making changes to the mode or the flash recovery options), you have logged in as a user that does not have SYSDBA privileges. You must log out of Grid or Database Control, and log back in as user SYS with the role SYSDBA, to make changes on the Recovery Settings page. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 13: Using Oracle Enterprise Manager for Backup and Recovery 325 RMAN Workshop: Configure Recovery Settings in OEM Workshop Notes This workshop makes changes that set a second archive destination in addition to the FRA, add more space to the FRA, and enable Flashback Database. This workshop assumes you are already in ARCHIVELOG mode (see Chapter 3 if you are not, or just choose the ARCHIVE Log check box on the Recovery Settings page). Step 1. Log into OEM as user SYS with role SYSDBA. If you are not logged in as SYS, the options on the Recovery Settings page will be grayed out. Step 2. Navigate to the Database | Availability | Recovery Settings page. Step 3. Set a new archive log destination to /u01/backup. Click Add Another Row and then specify the location (here, we use /home/oracle/backup). Step 4. Change the Flash Recovery Area Size to 4GB. Step 5. Check the Enable Flashback Database check box. Set the Flashback Retention Time to 24 Hours. Step 6. Click the Apply button. This prompts you to restart the database. Click Yes. You then need to provide host and database credentials for the shutdown. Step 7. After the database is restarted, navigate back to the Recovery Settings page to confirm the changes. Configuring Recovery Catalogs in OEM Enterprise Manager cannot actually create a recovery catalog. You still need to manually create the catalog user, grant the user the RECOVERY_CATALOG_OWNER role, and then connect RMAN to this user and issue the command create catalog. There is no wizard or anything for these steps in OEM. This can be a bit confusing, as there is an Add Recovery Catalog button on the Recovery Catalog Settings page. However, this button only adds an existing recovery catalog to the Enterprise Manager repository; that is, we make EM aware of the existence of a recovery catalog, so that it can then add this particular database to the specified catalog. Once the catalog is created, you can inform OEM that you wish to use the recovery catalog. After you have registered the recovery catalog with OEM, you can register targets in the catalog. If you have registered more than one recovery catalog, you can specify that a particular one be put in use during different backup and recovery operations. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
326 Part III: Using RMAN Effectively RMAN Workshop: Register the Recovery Catalog with OEM Workshop Notes This workshop creates a catalog in the database emrep manually and then registers it for use in OEM. Step 1. Connect to the repository database as user SYS and create the user for the catalog: SQL> create tablespace reco cat datafile '/u01/app/oracle/oradata/emrep/reco cat1.dbf' size 100m; Tablespace created. SQL> create user rman identified by rman 2 default tablespace reco cat 3 quota unlimited on reco cat; User created. SQL> grant connect, resource, recovery catalog owner to rman; Grant succeeded. SQL> connect rman/rman Connected. Step 2. Make sure that you have the 11.2 $ORACLE_HOME/bin in your path before this step so that the RMAN executable is 11.2. Otherwise, OEM will not be able to register your catalog! $ echo $PATH /u01/app/oracle/product/10.2.0/bin [oracle@dex oracle]$ rman catalog rman/rman@v112 Recovery Manager: Release 11.2.0.0.2 on Wed Dec 21 Copyright (c) 1982, 2009, Oracle. All rights reserved. connected to recovery catalog database RMAN> create catalog; recovery catalog created Step 3. Now that the catalog is created, go to OEM | Database | Availability | Recovery Catalog Settings. Select Use Recovery Catalog, and then click the Add Recovery Catalog button. From Grid Control, you can choose an already discovered database or provide the host, the port, the SID, and the RMAN username and password. From Database Control, you cannot choose from a list and must provide the host:port:sid combination. In addition, you need to provide the recovery catalog credentials (the RMAN user created in Step 2). Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 13: Using Oracle Enterprise Manager for Backup and Recovery 327 Step 4. After the Add Recovery Catalog action returns you to Recovery Catalog Settings, you need to provide the Recovery Catalog user and password again, along with host credentials to run the job. When this is complete, you can click OK, and the register database action will complete. Related Links for Recovery Catalog Settings Three “related links” that provide additional functionality are at the bottom of the Recovery Catalog Settings page: ■ Resynchronize Catalog Manually do a sync operation to bring the database control file and the recovery catalog into a synchronized state. ■ Recovery Catalogs View and manage all recovery catalogs that EM has been made aware of. ■ Unregister Database Remove this database from the selected recovery catalog permanently. Database Backups from Enterprise Manager Now that you have configured your database for backups from the OEM interface, you can get to the nitty-gritty of actually taking a backup. From the OEM Console, after you have selected your database and clicked the Availability tab, click the Schedule Backup link. On the Schedule Backup page, you are given two options: the Oracle-Suggested Backup or Schedule a Customized Backup. Oracle-Suggested Backup Strategy Starting with Oracle Database 10g, Oracle has put together a full backup strategy that is “ready to wear” straight from the rack. This is available only via OEM (in both Grid Control and Database Control) and requires the existence of the FRA. The Oracle-suggested strategy checks the backup Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
328 Part III: Using RMAN Effectively and recovery settings you’ve configured for your database and draws conclusions about whether you want a disk-only backup, a tape-only backup, or a combined disk and tape backup. Disk-Only Oracle-Suggested Backup Strategy The disk-only backup strategy is the most straightforward. It uses the “incremental apply to database copy” functionality to create a backup strategy that is self-cleaning. Here’s an example of how it works. In this example, we start the Oracle-suggested strategy on a Monday evening at 10 P.M. The database is running in ARCHIVELOG mode, has automatic control file and SPFILE backups enabled, and uses the FRA. ■ Monday night A full image copy of every datafile is taken for the database. This backup is stored in the FRA. ■ Tuesday night A level 1 incremental backup set is created. All blocks that have changed since Monday night at 10 P.M. are backed up. ■ Wednesday night First, RMAN applies the Tuesday night incremental backup to the Monday night image copy, which makes the full image copy backup a current copy of the database as it looked Tuesday night at 10 P.M. After that is complete, RMAN takes a new level 1 backup. ■ Thursday night RMAN applies the Wednesday night incremental backup to the image copy, which makes our database backup current as of Wednesday night at 10 P.M. Then, a new incremental level 1 backup is taken, with all changes since Wednesday night. ■ Friday night RMAN does the exact same thing it did on Thursday night. On Saturday, it does the same thing. Same with Sunday. This action repeats every day until you tell it to stop. Notice a few things about this backup strategy. First, a full database backup is taken only once. After that, RMAN takes only level 1 incremental backups. Then, nightly, the previous night’s incremental backup is applied. This strategy ensures that the database backup is at least 24 hours behind the current point in time. This allows for a point-in-time recovery to any point in the previous 24 hours, but nothing earlier than that. At most, the database backup is 48 hours behind the current time, so recovery is never that far behind. There are limitations to this strategy, but that’s one of the drawbacks to a “one-size-fits-all” approach to backups. Tape-Only Oracle-Suggested Backup Strategy The tape-only suggested strategy differs in many ways from the disk-only suggested strategy. First, no backup will ever be created in the FRA. Sure, archive logs will accumulate there, but all backups will go directly to the tape device. In addition, the tape-only strategy cannot take advantage of the incremental apply feature. Remember, an image copy backup cannot be taken to tape. All backups to tape will be of the backup set type. When you schedule an Oracle-suggested tape-only backup, two RMAN scripts are generated: a daily backup and a weekly backup. First, the weekly script is run. This creates a full database backup, including all archive logs. Then, the daily script is run. The daily backup does an incremental backup of only changed blocks, along with all archive logs not already backed up. Then, once a week, the full database backup runs again. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 13: Using Oracle Enterprise Manager for Backup and Recovery 329 During the tape-only backup wizard, if you have not specified a retention policy, OEM asks you to specify one. Then, as part of the daily backup, your retention policy is enforced on the tape channel. After generating a tape-only suggested strategy, you will find that the scripts might look something like this: Daily Script: run { allocate channel oem sbt backup1 type 'SBT TAPE' format '%U' parms 'nb ora server (horatio.hadba.com)'; allocate channel oem sbt backup2 type 'SBT TAPE' format '%U' parms 'nb ora server (horatio.hadba.com)'; backup incremental level 1 cumulative database; backup archivelog all not backed up; } allocate channel for maintenance device type 'SBT TAPE' parms 'nb ora server (horatio.hadba.com)'; delete noprompt obsolete recovery window of 7 days device type 'SBT TAPE'; Weekly Script: run {allocate channel oem sbt backup1 type 'SBT TAPE' format '%U' parms 'nb ora server (horatio.hadba.com)'; allocate channel oem sbt backup2 type 'SBT TAPE' format '%U' parms 'nb ora server (horatio.hadba.com)'; backup incremental level 0 database; backup archivelog all not backed up; Combined Disk and Tape Oracle-Suggested Backup Strategy When you combine disk backups with tape backups, the hybrid solution demands more input from you than either of the previous Oracle-suggested strategies. And, for the first time, you must make a configuration decision. First, consider the disk part of the strategy. Backups to disk are identical in the combined disk and tape strategy and in the disk-only strategy: a full image copy in the FRA, and then incremental backups each night that are then applied to the image copy. As far as the tape part of the strategy, you must decide how much you want backed up to tape on a daily basis. On a weekly basis, the suggested strategy backs up all recovery-related files (with the backup recovery files command in RMAN). But, you must choose how much to back up daily: nothing, archive logs only, archive logs and incrementals, or archive logs and the full database copy. If you decide to back up archive logs and incrementals to tape daily, this would be the resulting daily and weekly script that OEM builds: Daily Script: run { allocate channel oem disk backup device type disk; recover copy of database with tag 'ORA$OEM LEVEL 0'; backup incremental level 1 cumulative copies 1 for recover of copy with tag 'ORA$OEM LEVEL 0' database; release channel oem disk backup; allocate channel oem sbt backup1 type 'SBT TAPE' format '%U' parms Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
330 Part III: Using RMAN Effectively 'nb ora server (horatio.hadba.com)'; backup archivelog all not backed up; backup backupset all not backed up since time 'SYSDATE-1'; } allocate channel for maintenance device type 'SBT TAPE' parms 'nb ora server (horatio.hadba.com)'; delete noprompt obsolete recovery window of 7 days device type 'SBT TAPE'; Weekly Script: run { allocate channel oem disk backup device type disk; recover copy of database with tag 'ORA$OEM LEVEL 0'; backup incremental level 1 cumulative copies 1 for recover of copy with tag 'ORA$OEM LEVEL 0' database; release channel oem disk backup; allocate channel oem sbt backup1 type 'SBT TAPE' format '%U' parms 'nb ora server (horatio.hadba.com)'; backup recovery area; } allocate channel for maintenance device type 'SBT TAPE' parms 'nb ora server (horatio.hadba.com)'; delete noprompt obsolete recovery window of 7 days device type 'SBT TAPE'; Final Note on Oracle-Suggested Strategies Taking a default backup strategy “off the shelf” has its benefits and its drawbacks. The benefits come from being able to “set and forget” the backups—they will run forever and clean themselves up. There is some assurance in having this option, particularly for low-priority development databases that typically are operated by someone other than you. If they come to you in a panic, you can always use these backups to fix the problem and save everyone a lot of headaches. But there is (almost) no customization, and sometimes the default strategy will not match your SLA. The most glaring example of this is in the ability to do point-in-time recoveries to some point in the past (a limitation of the disk-based strategy only). Remember, these strategies are merely Oracle suggestions. You don’t have to use them, and if they are giving you any heartburn, there is a simple answer: drop the suggested strategy and build your own. Scheduling a Customized Backup From the same Availability page where you can choose to schedule an Oracle-suggested backup strategy, you can also choose to build your own customized backup job. This is a wizard-driven process that steps you through the different choices to be made about the backup. When the wizard is finished, you can run the backup as a one-time backup immediately, schedule it for later, or set it up to repeat continually on a schedule. It is important that you take the time to develop a full backup strategy ahead of time, but OEM will provide some guidance about how to develop that strategy. These tips appear as small-font hints under some of the choices you will be asked to make in the Backup Scheduling Wizard. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 13: Using Oracle Enterprise Manager for Backup and Recovery 331 The Backup Scheduling Wizard is divided into four steps: 1. Choose backup options (what do you want to back up?). 2. Choose backup settings (how do you want to back up?). 3. Schedule the backup (when do you want to back up?). 4. Perform a final review (is everything to your liking?). On the final review page, you will be presented with the RMAN script that the wizard has created, as shown in the following example. At this stage, you can either submit the job for execution or edit the RMAN script from there. This allows you to make any minor tweaks in the script. Note that if you decide to modify the script manually, OEM warns you that you will not be able to go back and make any changes in the backup wizard pages. After you make any of your own changes, you can either cancel them or submit the job. RMAN Script Job vs. Scheduled Backup Wizard There is another way to use OEM to schedule and run RMAN backups of a target database. If you go to the Jobs tab in Grid Control (or the Jobs link under Related Links in Database Control) and look at the drop-down list of possible job types to create, you will see RMAN Script. This is a specific type of job specification that allows you to use OEM to execute an RMAN script that already exists at the target server. So what is the difference between an RMAN script job and a host command job? Both require a script to exist prior to scheduling the job. But if you choose an RMAN script job, OEM uses its built-in mechanisms to ensure that the environment is properly configured for your target database before running the script. This is a very nice feature, which you know if you have ever run into the dreaded “compatibility matrix” of RMAN executables versus target databases. Why Does OEM Always Try to Allocate a Tape Channel for Maintenance? You may notice that when you review your RMAN script after using the OEM wizard to schedule a backup, OEM has the following lines: allocate channel for maintenance type 'SBT TAPE'; delete noprompt obsolete device type disk; What gives? OEM has this little quirk. If you have, at any point, gone into the Configure Backup Settings page and set the number of tape drives to some value, then OEM has gone to your target database and configured a tape channel in the permanent configuration parameters. Thus, it assumes that any maintenance operation should always check tape and disk. From within OEM, there is no way to change this. You have to go to the RMAN command line and enter the following: configure channel device type 'sbt tape' clear; Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
332 Part III: Using RMAN Effectively RMAN Workshop: Create an RMAN Script Job in OEM Workshop Notes This workshop uses OEM to schedule an RMAN backup. However, the backup will be specified by an RMAN script that already exists as a file on the Linux machine where database v112 exists. In this example, this script, named rmanback.rcv, already exists in /home/oracle/scripts and contains the following code: backup incremental level 1 cumulative device type disk filesperset 2 database; backup device type disk filesperset 2 archivelog all not backed up delete all input; delete noprompt obsolete device type disk; Step 1. Go to the Jobs page of OEM. In Grid Control, there is a Jobs tab along the upper-right side. In Database Control, go to the bottom under Related Links to find the Jobs link. Step 2. Create a new job of type RMAN Script by using the drop-down list (that defaults to OS Command) to specify RMAN Script and then clicking Go. This will take you to a page with multiple tabs. Step 3. On the General tab, give the job the name RMAN_BACK_INC_1_ARCH_DELETE_OBS, as shown next. On this tab, you also need to add the target you want to back up. Click the Add button and select your desired database. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 13: Using Oracle Enterprise Manager for Backup and Recovery 333 Step 4. Click the Parameters tab. In the text box, provide the full path and name to the backup script you created on the target server. Step 5. On the Credentials tab, ensure that you have selected SYSDBA Database Credentials, as this is required by RMAN. Step 6. On the Schedule tab, set a schedule for the job. Your choice is One Time (Immediately), One Time (Later), or Repeating. New in 11g, you can also specify a Grace Period for the backup job: by specifying Indefinite, you are telling EM to let the job run until it signals that it is finished. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
334 Part III: Using RMAN Effectively By choosing End After, you are indicating to EM that you want the job killed if it hasn’t completed in the specified time. Step 7. Click the Submit button at the top of the page to send the job to the active jobs page. This submits the job as a one-time event. You can, alternatively, save the job to the library without submitting it immediately, or both submit the job now and save it to the library. Performing Recovery in Enterprise Manager After seeing all the backing up that can be done from OEM, it should come as no surprise that you can also perform recovery from OEM. That being said, there are not many situations where we’ve seen OEM’s recovery options being used—even when OEM is used for backups. The decision to use OEM for recovery boils down to your ability to mitigate the overwhelming sensation typically felt when you realize your database is hosed: panic. OEM does not help you manage your panic very well. You’d think that a GUI would be the best defense against panic—easy to use, quickly implemented, and all that. But this is actually quite the opposite of all DBAs’ reactions we’ve seen in a recovery situation. During the most solemn and distressing recovery situations we’ve been a part of, the one overwhelming DBA desire that we’ve noticed is not ease of use, built-in intelligence, or anything like that. What every DBA wants at that time is control. They want complete, total control over everything that they can possibly get control over. Database recovery is no time to be hitting the big red button and hoping for the best. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 13: Using Oracle Enterprise Manager for Backup and Recovery 335 The Recovery Wizard in OEM is primarily useful in all those databases you deployed in development for people who assured you that they would take care of it themselves. In other words, OEM Recovery is for databases that have Oracle-suggested backup strategies. There is one notable exception: if you have made yourself aware of how OEM Recovery works, you have noticed that it has the capabilities to lead you to the Oracle Flashback Technology, outlined in Chapter 15. Flashback Technology provides a whole new arsenal against downtime, particularly when it comes to user-induced trauma. So, if it is control you seek, understand that you are not in complete control of your recovery situation until you have explored your Flashback Technology options. While the Recovery Wizard may not help you manage panic after an unknown failure, there is a new feature in 11gR2 that will help you know about failures proactively, thereby saving you from the panic altogether. This new utility is built into each 11.2 database, and it is collectively referred to as the Data Recovery Advisor. Data Recovery Advisor and the OEM Checkers The Data Recovery Advisor (DRA) is an advisory function built into the core RDBMS of the database. It utilizes the same Diagnostic Repository that has been established in 11g for consolidating all diagnostic and fault information, so that remediation can occur more programmatically (for more on the Automatic Diagnostic Repository, see the discussion in Chapter 3). The DRA mines the data in the diagnostic repository to determine if there is a recovery action that the DBA should take in order to rectify the database and keep it available. To be able to provide intelligence on recovery situations, the DRA must have access to additional data in the diagnostic repository. Some of that information, such as the known state of datafiles, will end up in the repository no matter what, and if RMAN has discovered any corrupt blocks during its last backup. However, some of it will get there only if you run one of the newly integrated health checkers against the database. These checkers perform diagnostic data gathering operations on different aspects of the database and then store that data in the Diagnostic Repository for action by different actors (such as the DRA). The health checkers and the DRA are native components of the RDBMS in 11.2, so you don’t need Enterprise Manager to utilize the functionality. There is a fuller discussion on the command- line DRA in Chapter 3. Here, we are going to focus on the EM interface for the tools. This is one of those places where the GUI interface really earns its keep—in scheduling health check operations and in giving you a one-stop location to rectify any outages. The Checkers in EM There are seven checkers available in 11.2. Each of these performs actions against different database objects, or with different architectural needs. Each of these is described next. What they all have in common is that you get to them in EM from the main database home page, by scrolling down to Related Links and clicking Advisor Central. Advisor Central offers two pages— Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
336 Part III: Using RMAN Effectively Advisors and Checkers. Advisors is the default view; you will need to click the Checkers tab to see the health check utilities. From the Checkers page, you can see the most recent runs of the checkers and the results. By clicking on the Run Name, you can move to the Findings page to see if any alerts have been raised that require action. Each of the checkers may require unique inputs to run, but they all require at least two items in common: you must name the run you are asking to start (and it must be unique), and you must provide a time-out after which EM aborts the checker if it has not completed. ■ Data Block Integrity Check Checks a single block for corruption. You need to know the suspected file and block number (such as reported by an ORA-1578 error) to run this checker. ■ CF Block Integrity Check This is the Control File checker. Again, the expectation in the tool is that you know the suspected back block number that requires an integrity check. ■ Redo Integrity Check This checks for online or archive redo corruption and accessibility. You specify the SCN that you want to start moving forward from, and EM performs the check from there. ■ Transaction Integrity Check This is the same as the Undo Segment Integrity Check, in that it checks for logical undo corruptions, except that it does so for a single transaction. The required input is the transaction ID. ■ Undo Segment Integrity Check This checks for logical undo corruptions for an entire Undo segment. The Undo segment number is the required input. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 13: Using Oracle Enterprise Manager for Backup and Recovery 337 ■ DB Structure Integrity Check This checker provides a proactive mechanism for checking all database files for accessibility, header corruption, and SCN synchronicity across the files and the control file. There is no input required. ■ Dictionary Integrity Check This examines core data dictionary items to ensure consistency and integrity. You must provide the name of the data dictionary table you are checking, and the check mask. Data Recovery Advisor As with the health check utilities, you get to the Data Recovery Advisor through the Advisor Central link from Related Links on the database home page. If there are no current recovery- related findings in the database, the DRA will simply have a search field to search previous cataloged failures. If a new failure exists that hasn’t been rectified yet, you will see the option to Select failures and… take an action. If you click the Advise button, EM will take a few moments to examine the information and then will provide advice on what to do about the particular failure at hand. If there is an action it can take automatically, it will ask permission and then do so. Otherwise, it will recommend a manual action to take, as shown next. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.