Tài liệu Oracle RMAN 11g Backup and Recovery- P6 pdf

218 Part II: Setup Principles and Practices RC_BACKUP_CONTROLFILE (V$BACKUP_DATAFILE) This view provides information about backups you have taken of your control file. This does not include control file copies; there is a different view for copies that have been made with the copy command or cataloged with the catalog command. This view is an excellent source to reference if control file restore operations are behaving strangely, particularly if you are trying to duplicate for standby database creation. To review control file copies in V$BACKUP_DATAFILE, you would look at records with a file number of 0—this represents the control file: select file#, creation time, resetlogs time, blocks, block size, controlfile type from v$backup datafile where file# 0; The following query would give you information about all the control file backups for the database V102, with the completion time, the status, the type of control file (B for a normal backup and S for a standby control file backup), and the date of the autobackup (this will be null if you do not have the control file autobackup configured): column completion time format a25 column autobackup date format a25 alter session set nls date format 'DD-MON-YYYY:HH24:MI:SS'; select db name, status, completion time, controlfile type, autobackup date from rc backup controlfile where db name 'V102'; RC_BACKUP_CORRUPTION (V$BACKUP_CORRUPTION) This view lists the corruption that exists in datafile backups. To tolerate corruption, the value of MAXCORRUPT must be set to a non-zero value, which indicates how many corrupt blocks RMAN will back up before it throws an error and aborts. The corrupt blocks are not discarded, but rather are backed up as is. Do not confuse this view with RC_DATABASE_BLOCK_CORRUPTION (described later in this chapter), which lists blocks that are corrupt in the database based on the last backup operation (or backup validate). RC_BACKUP_CORRUPTION lists blocks that are corrupt in the backup, not in the database itself. The following code provides a list of corrupt blocks, with block number, file number, backup piece in which the corruption exists, and the type of corruption for the database V102: select db name, piece#, file#, block#, blocks, corruption type from rc backup corruption where db name 'V102'; RC_BACKUP_DATAFILE (V$BACKUP_DATAFILE) This view has extensive information about datafiles that exist in backup sets. If you are interested in viewing specific information about datafiles that have been backed up, use this view. RC_BACKUP_FILES (V$BACKUP_FILES) This view most completely corresponds to the information provided by the commands list backup and list copy from the RMAN command-line interface. This view provides details about all backup Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Chapter 10: Using the Recovery Catalog 219 files known to the recovery catalog, regardless of whether the file is a backup set, datafile copy, or proxy copy. To use this view, you must first call DBMS_RCVMAN.SETDATABASE to indicate which database you are looking for: CALL DBMS RCVMAN.SETDATABASE(null,null,null,2283997583,null); select backup type, file type, status, bytes from rc backup files; RC_BACKUP_PIECE (V$BACKUP_PIECE) Reference this view for information about specific backup pieces that have been created during normal backup operations. Remember that a backup set contains more than one backup piece, and that the backup piece is the physical file that corresponds to the logical unit of the backup set. RC_BACKUP_REDOLOG (V$BACKUP_REDOLOG) The name of this view is something of a misnomer: RMAN cannot back up online redo logs; it can back up only archived redo logs, which most often are simply referred to as archive logs. This view lists archive logs that exist in backup sets. It has a record for each archive log that has been backed up; if the same archive log is backed up twice, there will be two records. The following query provides information for a particular range of archive logs, with backup set information, the status of the backup set, and the completion time: alter session set nls date format 'DD-MON-YYYY:HH24:MI:SS'; select db name, bs key, sequence#, thread#, first change#, status from rc backup redolog; RC_BACKUP_SET (V$BACKUP_SET) Information in this view refers to each logical backup set. You have to specify what type of backup set you would like to review: full backups, incremental backups, or archive log backups. RC_BACKUP_SPFILE (V$BACKUP_SPFILE) In this view, you will find information on SPFILE backups that exist in backup sets. RC_CONTROLFILE_COPY (V$DATAFILE_COPY) Like RC_BACKUP_CONTROLFILE, the corresponding view here, V$DATAFILE_COPY, also includes information about control files, encoded as file number 0. In the catalog, this view contains control file copy information for control files created with the copy command or cataloged with the catalog command. RC_COPY_CORRUPTION (V$COPY_CORRUPTION) This view is the same as RC_BACKUP_CORRUPTION, except that it reports blocks that are corrupt in copies instead of in backup sets. The select statement, then, would omit a piece#, but would otherwise be identical: select db name, file#, block#, blocks, corruption type from rc COPY corruption where db name 'V102'; Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 220 Part II: Setup Principles and Practices RC_DATABASE (V$DATABASE) This view contains basic information about each database registered in the catalog: the database name, DBID, current incarnation number, and last RESETLOGS time and SCN. RC_DATABASE_BLOCK_CORRUPTION (V$DATABASE_ BLOCK_CORRUPTION) This view provides the corruption list that is populated when a backup or backup validate operation discovers corrupt blocks. Remember that these are the actual corrupt blocks in the database, and not in the backups or copies themselves. This view is refreshed on each backup operation to reflect current corruption (if any). V$DATABASE_BLOCK_CORRUPTION is the view used during block media recovery when you specify blockrecover corruption list and is therefore the one that you will most often be referencing. The following code is an example select statement against this view: select file#, block#, corruption type from v$database block corruption; DATABASE_INCARNATION (V$DATABASE_INCARNATION) This view contains a record for each incarnation of each database registered in the catalog. The most important information here is the RESETLOGS information, which by definition defines each incarnation. The following code is an example select statement against this view: select dbid, name, dbinc key, resetlogs time, current incarnation from rc database incarnation where db key <database key> and dbinc key <current incarnation key number>; RC_DATAFILE (V$DATAFILE) This view exists so that the catalog has access to the same schematic information as does the control file about the location and specifics of each datafile in the database. You are much more likely to use V$DATAFILE when you want to look at your datafile information; however, in a recovery situation, this view can be extremely helpful if a current control file is not available. It also contains tablespace information in addition to datafile information, and in that way resembles the fixed view DBA_DATA_FILES. In addition, this view contains permanent configuration information for the commands configure exclude and configure auxname. The following code is an example select statement against this view: select db name, ts#, tablespace name, file#, name, bytes, included in database backup, aux name from rc datafile where db name 'V102'; RC_DATAFILE_COPY (V$DATAFILE_COPY) This view provides metadata about datafile copies created by the copy command or OS copies that have been registered with the catalog command. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Chapter 10: Using the Recovery Catalog 221 RC_LOG_HISTORY (V$LOG_HISTORY) V$LOG_HISTORY is the view that contains historical information about online redo logs, such as when they switched and what the SCN was at the time of the switch. This is a little redundant with V$ARCHIVED_LOG, but V$LOG_HISTORY does not concern itself with any current files, just the historical log switching information. RC_OFFLINE_RANGE (V$OFFLINE_RANGE) Offline ranges set the parameters for when a datafile went offline or read-only, and when it came back to read/write mode (if ever). It is important for RMAN to know this about a file when doing backups and restores. From a recoverability standpoint, it is critical to know the entire time range when a file was offline. If a backup of a datafile exists from before a transition from online to offline (or read-only), archive logs will be required from the moment the file was taken offline or read-only until the current point in time. RC_REDO_LOG (V$LOG, V$LOGFILE) From a schematic point of view, this is the same for RMAN as knowing the information in V$DATAFILE—on rebuilds, it needs to know where the online redo log files are located. This view is a combination of both V$LOG and V$LOGFILE, so that thread and group membership is available alongside the name of each log. RC_REDO_THREAD (V$THREAD) Thread information is really only important in RAC environments, where there is more than a single thread of redo being generated at once. This view lists a record for each separate thread in the current database incarnation, along with the status of the thread and its redo stream. The following code is an example select statement against this view: select db name, thread#, status, sequence# from rc redo thread where db name 'V102'; RC_RESYNC This view provides information for each catalog resync operation that occurs. Obviously, there is no corresponding v$view for this one. You can use this view to determine if any of your enterprise databases need a resync, or to troubleshoot possible resynchronization problems. The following code is an example select statement against this view: select db name, controlfile time, controlfile sequence#, resync type, resync time from rc resync where db name 'V102'; RC_RMAN_CONFIGURATION (V$RMAN_ CONFIGURATION) This view is equivalent to a show all command, giving the name and value for each configuration parameter that is set for each of your target databases. It is worth noting that three configuration parameters are not stored here: configure exclude information is found in RC_TABLESPACE Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 222 Part II: Setup Principles and Practices (V$TABLESPACE), configure auxname information is found in RC_DATAFILE (V$DATAFILE), and configure snapshot controlfile information is found only in the target database control file (there is no catalog equivalent). It is also important to point out that RC_RMAN_CONFIGURATION does not have a DB_ NAME column, so you have to use the primary key DB_KEY value from RC_DATABASE to get the values for the appropriate database registered in your catalog. Furthermore, no values are listed in either V$RMAN_CONFIGURATION or RC_RMAN_ CONFIGURATION for default values. Only values that have been manually changed will appear in this list. The following code is an example select statement against this view: select name, value from rc rman configuration where db key 1; RC_TABLESPACE (V$TABLESPACE) Tablespace information is included in this view. The real benefit of this view over V$TABLESPACE is that historical information about dropped tablespaces is kept in the catalog. Therefore, you can use this view to look back and see when a tablespace was dropped. In addition, this view contains the information recorded for any configure exclude commands. RC_TEMPFILE (V$TEMPFILE) RMAN, since version 10g, is tempfile aware and can rebuild tempfiles upon restore so that you do not have to do it manually, as in the past. RC_TEMPFILE provides the bridge for this functionality, and a window into the existing tempfiles for a database. Catalog Views Intended for Use by Oracle Enterprise Manager A series of new views in the recovery catalog were created specifically to provide performance and functionality enhancements to the OEM Console and thus have limited functionality for end users. Most of these views do not have corresponding v$views in the target database control file. It is worth taking a look at these views and identifying their parts, to avoid any misunderstanding. If you are looking for a way to leverage the information in these views, you can find the same information in them in OEM’s backup and recovery functionality. The following table lists and briefly describes the RC_* views that are built primarily for use by OEM. RC_* View Note RC_BACKUP_ARCHIVELOG_DETAILS Detailed information about backed up archive logs. RC_BACKUP_ARCHIVELOG_SUMMARY Summarized archive log backup information. RC_BACKUP_CONTROLFILE_DETAILS Detailed control file backup information. RC_BACKUP_CONTROLFILE_SUMMARY Summarized information about all control file backups known to RMAN. RC_BACKUP_COPY_DETAILS Detailed information regarding all control file and datafile copies. RC_BACKUP_COPY_SUMMARY Summarized control file and datafile copy information. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Chapter 10: Using the Recovery Catalog 223 RC_BACKUP_DATAFILE_DETAILS Detailed information about all datafile backups—in backup sets as well as image copies. RC_BACKUP_DATAFILE_SUMMARY Summary information about datafile backups. RC_BACKUP_PIECE_DETAILS Detailed information about available backup pieces in the catalog. RC_BACKUP_SET_DETAILS Detailed information regarding available backup sets in the catalog. This includes backups created with the backup backupset command. RC_BACKUP_SET_SUMMARY Aggregated information about available backup sets. RC_BACKUP_SPFILE_DETAILS Detailed information about available SPFILE backups. RC_BACKUP_SPFILE_SUMMARY Summarized information about available SPFILE backups. RC_RMAN_OUTPUT Assists OEM with job status tracking. The corresponding v$view is V$RMAN_OUTPUT. RC_RMAN_BACKUP_JOB_DETAILS Detailed information on individual backup job sessions, combining all operations in the same session. RC_RMAN_BACKUP_SUBJOB_DETAILS Details concerning groups of similar operations within an RMAN session. RC_RMAN_STATUS A historical view of RMAN sessions for all databases in the recovery catalog. It does not contain current session information, as does its corresponding v$view, V$RMAN_STATUS. RC_UNUSABLE_BACKUPFILE_DETAILS A list of all backup files of any type that have been marked as UNAVAILABLE or EXPIRED. RC_RMAN_BACKUP_TYPE Provides filtering information to OEM during its report building. Summary In this chapter, we detailed what a recovery catalog is and how it can help you to manage your backups—and save you during a recovery. We discussed how to build the catalog, add managed databases to it, and how to drop it. Oracle Database 11g provides the option for generating virtual private catalogs to maintain privacy and security. In addition, 11g offers the capability to merge multiple catalogs as you work to centralize and simplify your ecosystem management. Finally, we provided an overview of the critical recovery catalog views that can be utilized to understand the metadata surrounding your backups and to help guide the backup maintenance and recovery operation planning. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. This page intentionally left blank Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 11 RMAN Backups Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 226 Part II: Setup Principles and Practices ow that we have covered all the startup essentials, we are actually ready to use RMAN to back up something. In this chapter, we are going to talk all about doing backups with RMAN. From offline backups to online backups, backups of archived redo logs to incremental backups, we will cover it all. We will look at how to back up entire databases and individual database datafiles. So, let’s move on! Benefits of RMAN Backups vs. Scripted Backups Why use RMAN to back up your databases? You may already be doing online backups with some wonderfully crafted, homegrown scripts, and you may be asking yourself, “Why should I start using RMAN when my scripts work so reliably?” In this section, we hope to answer that question. Although your scripts may never fail, some scripts out there that others have crafted do break. This raises two problems. First, when the script breaks, the database backup fails. Second, when the script fails, someone has to fix it. You might be a wizzo Unix scripter. Unfortunately, after you take that DBA job on the international space station, there is no guarantee that the person following you will be an equally gifted Unix scripter. That poor person is going to be sitting there looking at your marvelous code and cussing you up one side and down the other. His or her boss isn’t going to be happy, and, most importantly, the database will be at risk. Of course, the other possibility is that you will be the one having to debug the “Code from the Netherworld” since it was your predecessor, the shell scripter from nether regions, who went to work on the space station. Therein lies one big plus for RMAN—it is supported by Oracle, so, you can go to Oracle with your RMAN woes. Of course, there are a number of other positives to using RMAN: RMAN will detect corrupted blocks and report them to you. RMAN can back up your database online without having to put the tablespaces in hot backup mode. Thus, the additional (sometimes quite significant) redo generated during a hot backup is reduced. RMAN will automatically track new datafiles and tablespaces for you, which means you no longer have to add new tablespaces or datafiles to scripts. RMAN will only back up used data blocks (up to the high-water mark [HWM]). Thus, RMAN backup images typically are smaller than those of online backup scripts. RMAN offers true compression of backup images. RMAN provides easy, automated backup, restore, and recovery operations. RMAN tracks all the backups that you need to recover the database if a restore is required and will restore only those objects that are needed. RMAN can work fairly seamlessly with third-party media management products. RMAN supports incremental backup strategies. ■ ■ ■ ■ ■ ■ ■ ■ N Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Chapter 11: RMAN Backups 227 With RMAN, you can actually test your backups without restoring them. Try that with your backup scripts! If you use the repository, then RMAN provides a nice, centralized reporting facility. If you are running Oracle Database 11g, the new Data Recovery Advisor (DRA) can simplify diagnosing difficult database recovery issues quickly. It can then provide restore and recovery recommendations and can automate restores via RMAN. RMAN with DRA can simplify diagnosing difficult issues quickly and can implement the solutions to problems found using the 11g RMAN DRA commands. If you used RMAN in versions prior to Oracle Database 10g, you will find that your earlier RMAN backup commands still work. RMAN is very backward compatible. However, if you don’t take the time to review the features that RMAN offers and to implement those that might benefit you, you will not be getting the most out of RMAN. RMAN Compatibility Issues Before you haul off and start doing backups, you need to consider some compatibility issues. Your enterprise probably has differing versions of Oracle running, and you need to consider RMAN compatibility issues as you plan your backup strategy. Not all databases are compatible with all RMAN versions, and when you add the recovery catalog into the mix, things get even more complex. Table 11-1 provides a quick reference to the compatibility issues related to RMAN. In Table 11-1, you can see the RMAN target database version (say your database is version 10.2.0) and the RMAN client that supports backups of that database version (in our example, a 10.2.0 database can be backed up by RMAN versions >=9.0.1.3 and up to version 10.2.0 of RMAN). Also, you will find the version of the RMAN catalog database that must be in place to support the backup of that database (in our 10.2.0 example, the catalog that is required is a 9.0.1 version of the catalog). Finally, the version of the catalog schema that is required is listed (>= the version of the RMAN client being used in our example). As you can see from Table 11-1, you need to know what version your recovery catalog schema is. The RCVER view in the recovery catalog schema will give you this information. Here is an example: SQL> select * from rcver; VERSION 10.02.00.00 Finally, if you are faced with having to create more than one recovery catalog, there is no reason that all recovery catalogs cannot be maintained in the same database, as long as the database is version 9.0.1 or later. This still makes for a single recovery catalog database, which facilitates easy enterprise-wide reporting from that database. ■ ■ ■ ■ Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... 22:02:50 22:02:50 BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP LOGS LOGS LOGS LOGS LOGS LOGS LOGS LOGS LOGS LOGS LOGS LOGS Archive Log Deletion Policies Starting in Oracle Database 11g Release 1, you can configure a retention policy for archived redo logs beyond just Oracle Standby Databases (see Chapter 21 for more on RMAN and Oracle Standby Databases) Starting with Oracle Database 11g Release... regard to archive log backups, is also available with backup set backups When used, the delete input option will cause the files of the source backup set to get deleted after a successful backup Here are some examples of this command: backup backupset all; backup backupset all format 'd: \backup\ newbackups \backup %U.bak' tag 'Backup of backupsets on 6/15' channel 'ORA DISK 1'; backup backupset completed... backup backupset completed before 'sysdate - 2' delete input; backup backupset completed after 'sysdate - 2' delete input; An example of a backup strategy here might be to perform RMAN backups to disk, and then to back up the backup sets to tape with the backup backupset command Perhaps you want to keep two days’ worth of your backup sets on disk You could then issue two commands First, issue the backup. .. Set Backups Perhaps you like to back up to disk first, and then to back up your backup sets to tape RMAN supports this operation through the use of the backup command For example, suppose we issued a backup database command, and the entire backup set went to disk because that is our configured default device Now, we wish to move that backup set to tape We could issue the backup command with the backupset... FRA by default, and since both the archive log– backup backup set pieces and the database -backup backup set pieces cannot exist in the FRA if the keep parameter is used This is not required in Oracle Database 11g backup database tag 'keep full' format 'c: \oracle\ backup\ %U' keep until time 'sysdate+180' logs plus archivelog format 'c: \oracle\ backup\ %U'; Regardless of which version of Oracle you are running,... managed ■ The backup is a backup set and is a full backup or a level zero incremental backup ■ 237 The backup set has been created on disk If these conditions are met, Oracle will not back up any unused block, and your backups will therefore take up less space on your disks or tape RMAN Backup Compression We provided an example earlier in this chapter of a database backup using RMAN compression RMAN has... commands First, issue the backup backupset completed before ‘sysdate - 2’ command to back up the last two days of backups Next, to back up and then remove any backup sets older than two days, issue the backup backupset completed after ‘sysdate - 2’ delete input command, which would cause one final backup of the old backup sets and then remove them NOTE Backup set backups are very handy if you want to back... incremental backups and archived redo log backups to facilitate a complete database recovery Database, Tablespace, and Datafile Image Copies The backup command supports the creation of database image copies Simply use the backup as copy command to do image copies, and the process is much like performing backup sets Here is an example of making a database image copy with RMAN: RMAN> backup as copy database; RMAN. .. indicate a specific backup to be used This applies to full backups, tablespace backups, datafile backups, incremental backups, and even backup copies (all of which will be discussed in this chapter) Here is an example of assigning a tag to a full backup: backup database tag 'test backup' ; In this example, we used the tag parameter to identify this backup Each tag should be unique, and RMAN will allocate... various backup command flavors, such as backup database (which we just covered), backup tablespace, backup datafile, and other backup options, which we will cover later in this chapter A number of different options available for use with the backup command allow you to do such things as provide a naming format for individual backup pieces, or limit the size of those backup pieces The backup command even . the 11g RMAN DRA commands. If you used RMAN in versions prior to Oracle Database 10g, you will find that your earlier RMAN backup commands still work. RMAN. by the commands list backup and list copy from the RMAN command-line interface. This view provides details about all backup Please purchase PDF Split-Merge