Oracle RMAN 11g Backup and Recovery- P6

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

Thêm vào BST

Báo xấu

177
lượt xem 24
download

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

Oracle RMAN 11g Backup and Recovery- P6: 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- P6

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 and dbinc key ; 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 N 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. 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.
228 Part II: Setup Principles and Practices RMAN Target RMAN Client Version (with RMAN Catalog RMAN Catalog Database Version applied patches) Database Version Schema (with (with applied (with applied patches) applied patches) patches) 8.0.6 8.0.6 >=8.1.7 >=8.0.6 8.1.7 8.0.6.1 >=8.1.7 >=8.1.7 8.1.7 8.1.7 8.1.7 >=RMAN client 8.1.7.4 8.1.7.4 >=8.1.7 8.1.7.4 8.1.7.4 8.1.7.4 >=8.1.7 >=9.0.1.4 9.0.1 9.0.1 >=8.1.7 >=RMAN client 9.2.0 >=9.0.1.3 and =8.1.7 >=RMAN client database executable version 10.1.0 >=9.0.1.3 and =9.0.1 >=RMAN client database executable version 10.2.0 >=9.0.1.3 and =9.0.1 >=RMAN client database executable version 11.1.0 >=9.0.1.3 and =9.0.1 >=RMAN client database executable version 11.2.0 >=9.0.1.3 and =9.0.1 >=RMAN client database executable version TABLE 11-1 RMAN Compatibility Matrix Monitoring RMAN Backup Status RMAN produces output during the backup process. If you enable logging when you start RMAN, that output is suppressed. You can monitor RMAN operations by keeping an eye on the log file being generated, or you can use the V$ view V$RMAN_OUTPUT, as shown in this example: SQL> select output from v$rman output order by stamp; OUTPUT Starting backup at 12 NOV 05 using target database control file instead of recovery catalog allocated channel: ORA DISK 1 channel ORA DISK 1: sid 138 devtype DISK allocated channel: ORA DISK 2 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 11: RMAN Backups 229 channel ORA DISK 2: sid 154 devtype DISK channel ORA DISK 1: starting compressed full datafile backupset channel ORA DISK 1: specifying datafile(s) in backupset input datafile fno 00001 name C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\SYSTEM01.DBF input datafile fno 00004 name C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\USERS01.DBF channel ORA DISK 1: starting piece 1 at 12 NOV 05 input datafile fno 00003 name C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\SYSAUX01.DBF channel ORA DISK 2: specifying datafile(s) in backupset channel ORA DISK 2: starting compressed full datafile backupset input datafile fno 00005name C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\EXAMPLE01.DBF input datafile fno 00002name C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\UNDOTBS01.DBF channel ORA DISK 2: starting piece 1 at 12 NOV 05 Offline RMAN Database Backups Okay, so you think this RMAN thing sounds good, and the first few chapters were sure interesting. Time to really put the beast to work! The first backup topic we will discuss is performing offline (or cold) backups of the Oracle database. An offline RMAN backup is taken with the database mounted, but not open (obviously). If you have set up your default configuration settings for RMAN (as discussed in Chapter 3), then an offline RMAN backup is fairly straightforward. Offline Backups Using Default Settings To do an offline backup, first sign into RMAN (in the example we provide for this backup, we are not using a recovery catalog). Next, use the RMAN commands shutdown and startup mount to mount the database, which is the condition that the database must be in to perform an offline backup. Once the database has been mounted, simply issue a backup database command and the backup will occur. Here is an example of the commands you would issue to perform an offline backup via RMAN: shutdown startup mount backup database; startup If you prefer, you could do this as a compressed backup set: shutdown startup mount backup as compressed backupset database; startup Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
230 Part II: Setup Principles and Practices RMAN Workshop: Do an Offline Backup Workshop Notes This workshop assumes that your database has been configured with automatic channels, as shown in Chapter 3. It also assumes that you have configured a database account called backup_ admin for backups (as described in Chapter 3). In addition, it assumes that if you are using the Media Management Library (MML) layer, it has been configured. Step 1. Start up RMAN: C:\>rman target backup admin/robert Step 2. Shut down the database with the shutdown immediate command: RMAN> shutdown immediate Step 3. Mount the database with the startup mount command: RMAN> startup mount Step 4. Back up the database with the backup database command. In this case, to save disk space, we will compress our backup set (since we have not configured compression as a default setting): RMAN> backup as compressed backupset database; Step 5. Use the alter database open command to open the database: RMAN> alter database open; Here is an example of a complete offline RMAN backup following these steps: C:\>rman target backup admin/Robert RMAN> shutdown using target database control file instead of recovery catalog database closed database dismounted Oracle instance shut down RMAN> startup mount connected to target database (not started) Oracle instance started database mounted Total System Global Area 272629760 bytes Fixed Size 1248504 bytes Variable Size 83886856 bytes Database Buffers 184549376 bytes Redo Buffers 2945024 bytes RMAN> backup as compressed backupset database; Starting backup at 04 NOV 05 allocated channel: ORA DISK 1 channel ORA DISK 1: sid 157 devtype DISK allocated channel: ORA DISK 2 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 11: RMAN Backups 231 channel ORA DISK 2: sid 155 devtype DISK channel ORA DISK 1: starting compressed full datafile backupset channel ORA DISK 1: specifying datafile(s) in backupset input datafile fno 00001 name C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\SYSTEM01.DBF input datafile fno 00004 name C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\USERS01.DBF channel ORA DISK 1: starting piece 1 at 04 NOV 05 channel ORA DISK 2: starting compressed full datafile backupset channel ORA DISK 2: specifying datafile(s) in backupset input datafile fno 00003 name C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\SYSAUX01.DBF input datafile fno 00005name C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\EXAMPLE01.DBF input datafile fno 00002name C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\UNDOTBS01.DBF channel ORA DISK 2: starting piece 1 at 04 NOV 05 channel ORA DISK 1: finished piece 1 at 04 NOV 05 piece handle C:\ORACLE\PRODUCT\10.2.0\FLASH RECOVERY AREA\ROB10R2\BACKUPSET\2005 11 04\ O1 MF NNNDF TAG20051104T102913 1PQ32XLB .BKP tag TAG20051104T102913 comment NONE channel ORA DISK 1: backup set complete, elapsed time: 00:01:12 channel ORA DISK 2: finished piece 1 at 04 NOV 05 piece handle C:\ORACLE\PRODUCT\10.2.0\FLASH RECOVERY AREA\ROB10R2\BACKUPSET\2005 11 04\ O1 MF NNNDF TAG20051104T102913 1PQ33J52 .BKP tag TAG20051104T102913 comment NONE channel ORA DISK 2: backup set complete, elapsed time: 00:01:11 Finished backup at 04 NOV 05 Starting Control File and SPFILE Autobackup at 04 NOV 05 piece handle C:\ORACLE\PRODUCT\10.2.0\FLASH RECOVERY AREA\ROB10R2\AUTOBACKUP\2005 11 04\ O1 MF S 573474457 1PQ357T0 .BKP comment NONE Finished Control File and SPFILE Autobackup at 04 NOV 05 Finished Control File and SPFILE Autobackup at 04 NOV 05 RMAN> alter database open; Note that in the preceding example and the RMAN Workshop, we used very few commands. RMAN will automatically use the default configuration settings that we have defined (refer to Chapter 3). We really didn’t have to do anything but issue the shutdown and startup mount commands to shut down and restart the database. We then issued the backup as compressed backupset database command and sat back to watch our backup take off. Pretty easy, huh? RMAN has backed up our database datafiles, our control file, and our SPFILE (assuming we have configured it to do so). Once it’s done, all we need to do is issue the alter database open command, and our backup is complete. In this example, Oracle created two backup sets, each of which contains a single backup piece. As you can see from the output, these backup pieces will be created in the flash recovery area (FRA) of this database, which is C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA: piece handle C:\ORACLE\PRODUCT\10.2.0\FLASH RECOVERY AREA\ROB10R2\BACKUPSET\2005 11 04\ O1 MF NNNDF TAG20051104T102913 1PQ33J52 .BKP tag TAG20051104T102913 comment NONE Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
232 Part II: Setup Principles and Practices NOTE Oracle only supports backups of SPFILEs. You cannot back up your database text-based init.ora parameter file with RMAN. Finally, we might have opted to connect to the recovery catalog when we did this backup (and this applies to all backups that we do in this chapter). To connect to the recovery catalog, all you need to do is add the catalog parameter when starting RMAN: C:\>set oracle sid recover C:\>rman target backup admin/Robert catalog rcat owner/password@robt One interesting thing to note here is that when we connected to our recovery catalog owner, we did so using Oracle Net because we had our ORACLE_SID set to the SID of our database rather than the SID of the recovery catalog. When you do a backup with a recovery catalog, you need to use a service name and Oracle Net to connect either to the database you are backing up or to the catalog. We generally recommend using the networking connection to connect to the catalog and connecting directly to the database if possible. Also, note that if we had not configured automated backups of our control file, RMAN would still back up the control file as long as we were backing up datafile 1. The control file would be backed up into the backup set that contains datafile 1. You would also want to do a separate control file backup after your database backup was complete, so you would have the most current control file backed up (because the control file backed up with the backup set will not have the complete information on the current backup in it). Note that this control file, if it must be recovered, is a bit more complicated to recover if you have not configured control file autobackups. Because of this, we strongly suggest that you configure control file autobackups on your system. Offline Backups Without Using Configured Defaults What if we had not configured default settings (see Chapter 3)? Or what if the defaults were not what we wanted to use (maybe we don’t want to back up to the FRA)? In this case, we have a few more things that we need to do. Let’s look at an example of such a backup and determine what it is doing: shutdown startup mount run { allocate channel c1 device type disk format 'd:\backup\robt\robt %U'; allocate channel c2 device type disk format 'c:\backup\robt\robt %U'; backup as compressed backupset database; backup current controlfile; } The next few sections look at this example in a bit more detail. In the Beginning, Shut Down and Mount the Database This example looks a bit more complicated than the earlier example. First, we have the shutdown and startup mount commands that we had in the previous example. These are required for any offline backup. We will discuss online backups later in this chapter. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 11: RMAN Backups 233 Run, Oracle, Run! Next, we have a run block, which is a set of one or more statements, contained within the confines of braces of a run command, that are executed together as a block. Oracle will not run any of the statements until the entire block of statements has been entered. After you have entered all the statements, you complete the run block with the closing brace (followed, of course, by pressing ENTER). The run block is then compiled and executed. NOTE This book was written using Oracle Database 11g Release 2. In this release of RMAN (and 9i and 10g, in general), many commands that previously had to run within the confines of a run block no longer need to. We deliberately do not use run blocks unless required by this release. Many of the backup and restore/recover commands you will see in this and the next chapter will work in previous versions, but need to be run within a run block. Allocate Channels In the preceding code example, we have several different RMAN commands in the run block. First, the allocate channel commands each allocate a channel to RMAN for the database backup. We have discussed channels already (in Chapter 3, for example), but let’s look into their use a bit more for a moment. First, a word on backup sets and backup set pieces. Each time we create a channel, this implies that we are going to create one or more backup sets. There are some exceptions to this statement, but generally this is true, so for the sake of this discussion, assume this is a true statement. Let’s quickly define some terms: ■ Backup sets Logical entities, one or more of which will be created for each channel you define (generally, it’s one backup set per channel). ■ Backup pieces The actual physical files that the backed up data resides in. One or more backup pieces may be associated with each backup set. You can control the overall backup set size with the backup command (or, alternatively, you can configure a default value for it), or you can control the overall backup piece size with the allocate channel command (again, this can be configured when you configure default channels). We will further discuss limiting backup set sizes later in this chapter. The allocate channel command defines to which device a given channel (and thus, an individual backup set) is to be allocated. This device might be a disk (type disk) or a tape drive (type sbt). If we were allocating a channel to a tape system, we might also include certain parameter settings required by the MML vendor that we were using. An example of an allocate channel command to tape using an MML vendor, VERITAS NetBackup, might look like this: allocate channel t1 type sbt parms 'ENV (NB ORA CLASS RMAN db01)'; This particular channel is being allocated to a tape device. Refer to Chapters 4 through 10, which discuss topics related to non-disk backup location, for more on allocating RMAN channels to MML devices, Amazon S3, and Oracle Secure Backup. Having allocated two channels to the backup, RMAN will automatically try to parallelize the backup stream among those channels. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
234 Part II: Setup Principles and Practices Thus, since we have allocated two channels, two different backup sets will be created, and each backup set will have one backup piece. The size is defined in bytes, but you can use the k, m, or g specifications to indicate kilobytes, megabytes, or gigabytes, respectively, as required. Here is another example of the allocate channel command: allocate channel t1 type disk maxpiecesize 100m; In this example, we have limited to 100MB the maximum size of each individual piece of a backup set (remember that each channel will create a single backup set) created through that channel. This is a great way to ensure that you do not create an individual backup piece that is larger than your tape or file system can handle. Here is another example: allocate channel t1 type disk maxpiecesize 100m format 'd:\backup\robt\robt %U.bak' In this example, we have used the format parameter to define where the backup pieces will be put on the disk and what the naming convention will be for the backup pieces. Since we use the format parameter, we are essentially telling RMAN not to use the default location for the backup set pieces (which is typically the FRA). Note the %U format placeholder in the format command. Since we are not backing up to the FRA, we need to define the file naming convention associated with the backup pieces that will be created; in this case we use the %U format indicator. The resulting name will include the database name (robt) followed by an underscore and then an eight-character mnemonic that consists of the following: ■ The backup set identifier. Each backup set is assigned a unique identifying number by RMAN when it is created. ■ The time the backup set piece was created. Following the eight-character mnemonic will be an underscore, followed by the backup set piece number. Because the backup set piece number uniquely identifies each piece of the backup set, it is unique to that backup set. Finally, another underscore will be followed by the copy number of the backup set piece. Each multiplexed backup set piece copy has its own unique number assigned to it. If you are not multiplexing, the copy number will be 1. An example of the resulting backup set piece name might look like this: Rob1 16E112V9 1 1 Note in this filename that the time component of the eight-character mnemonic is not readily discernable, but that’s not really a problem. The important thing about the use of the %U placeholder is that it guarantees that the name of each backup set piece is unique. Of course, several different mnemonics are available for use with the format command, but generally %U will suffice. We added the instance name to the name and the extension just out of habit and good practice. Finally, there are a number of other options with the allocate channel command. Check out Appendix A for the entire syntax of the allocate channel command. If you are using the FRA, Oracle will create backup set filenames based on the Oracle Managed Files naming standard. See the Oracle Database 11g Release 2 Database Administrators Guide for more details on the Oracle OMF naming standard. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 11: RMAN Backups 235 NOTE You might have noticed that we are using SBT instead of SBT_TAPE. Earlier versions of RMAN used SBT_TAPE, but this is now just SBT. SBT_TAPE is still usable for backward compatibility. Channels can fail. Perhaps the hardware might fail, or some other failure might occur. Many RMAN backups consist of more than one channel going to a different location. If RMAN is using multiple channels and one channel should fail, the remaining channels will attempt to complete the work of the failed channel. Backup Is the Name of the Game Moving on now with our example code, after we have allocated the channels, it’s time to back up the database with the backup command (using the database option). The sum result of the backup database command is that RMAN will proceed to use the two channels we created and back up the database. The command is a bit different from the backup database command we issued earlier, as this backup database command is issued within the confines of a run command block. We had to perform this backup using a run block because we manually allocated the channels with the allocate channel command. The backup command also takes care of the control file and server parameter file (SPFILE) for us if datafile 1 is getting backed up (which it always will during an offline backup or any full backup, which is the default). Where this control file backup is stored depends on the setting of the controlfile autobackup parameter. If this parameter is set to off, then the control file is included in the database backup set along with the server parameter file (if an SPFILE is being used). If the parameter is set to on, the control file and SPFILE backup will be made to a separate control file backup piece. You can force RMAN to put the control file in the database backup set by including the include current controlfile clause in the backup database command (assuming you are not backing up datafile 1). Better yet, as we have done in our example, a separate backup of the control file is a good idea, to ensure that you have a control file backup that is current, including the most recent database backup. NOTE RMAN will only back up a server parameter file (SPFILE). It will not back up text-based init.ora files. The backup database command comes with a number of different options (and is, in fact, a subset of the larger backup command). Let’s look at the use of some of the options of the backup command. NOTE A new feature in Oracle Database 11g RMAN backups is the elimination of the backup of most UNDO within the database. Since a great deal of UNDO is not needed during a database recovery (for transactions that are already committed), it does not need to be backed up. This can reduce the size of the backups of the UNDO tablespaces a great deal! Note that this is a feature that cannot be disabled. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
236 Part II: Setup Principles and Practices Backup Command Options Now that we have introduced you to the backup command, let’s look at the number of different options you can use with it. These backup command options can be used with many of the 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 allows you to manually decide which channels will be used to back up what, should you wish to override the choices that RMAN makes otherwise. Let’s look at some of the options that you can use with the backup command. Multisection Backups A new feature in Oracle Database 11g is the ability to split out backups of large datafiles into multiple sections of a fixed size. These sections can be backed up over different channels, thus parallelizing the backup of a large datafile. This is very helpful if you are using bigfile tablespaces, which were first available in Oracle Database 10g. A backup that takes advantage of this new feature is called a multisection backup. To enable multisection backups, you specify the section size parameter within RMAN. RMAN will divide the files being backed up into file sections, which are just logically divided, contiguous blocks in a file. RMAN will create a backup set with one backupset piece for each file section. Here is an example of backing up a bigfile tablespace called USER_DATA, chunking the backup into 1GB sections: backup section size 1g tablespace USER DATA; Multisection backups are a great way to spread the load of a backup over a number of different I/O devices. Compression As you saw in previous examples, you can actually compress backup sets. By default, RMAN does NULL data block compression. RMAN also offers true compression of backup sets, which can reduce the overall storage space consumed by backup images. We discuss these two different types of compression next. NULL Data Block Compression With this form of compression, Oracle does not back up unused data blocks. NULL data block compression occurs in two different ways: ■ Data blocks that have never been used will not be backed up. ■ RMAN will also skip backing up blocks that were once used given specific criteria. In the first case, any block that has never had data in it will simply not be backed up. In the second case, if the database and the associated block meet certain criteria, then an empty block will not be backed up even if it contained data at one time. The following are the conditions that must be met to allow RMAN to skip backing up these blocks: ■ The compatible parameter is set to 10.2. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Chapter 11: RMAN Backups 237 ■ No guaranteed restore points are defined for the database. ■ The datafile is locally managed. ■ The backup is a backup set and is a full backup or a level zero incremental backup. ■ 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 the ability to apply compression algorithms to your backup sets. The end result is that backup sets are often much smaller. RMAN compression can significantly reduce the size of backup sets. Compression can be significant; for example, in one of our test databases, we saw a 70 percent difference in the size of the backup set images when using compression. If you don’t have the database configured to automatically compress backup sets, you can use the as compressed backupset parameter to create the backup set as a compressed backup set. If you have compression configured and you do not wish to use it in a given backup command, simply use the as backupset parameter (without the compressed keyword) of the backup command. RMAN in Oracle Database 11g Release 2 offers several different compression options to choose from: ■ DEFAULT ■ LOW ■ MEDIUM ■ HIGH The DEFAULT compression type is the same compression that was available starting with Oracle Database 10g Release 1 and does not require a license. The LOW, MEDIUM, and HIGH levels of compression offer you the ability to control the overall impact of compression on the system. LOW offers some compression with minimal CPU impact, whereas MEDIUM and HIGH offer incrementally better compression with incrementally higher performance impacts. If you use any compression other than DEFAULT, you must purchase a separate license from Oracle. You can configure compression as a default value by using the RMAN configure command (discussed in Chapter 3). Here is an example of configuring default compression in an Oracle 11g Release 2 Database: Configure compression algorithm 'DEFAULT'; Configure compression algorithm 'HIGH'; Configure compression algorithm 'MEDIUM'; Configure compression algorithm 'LOW'; Configure compression algorithm clear; You could configure compression as a default in earlier Oracle Database 10g and 11g Release 1. Each is done in a slightly different way. Please reference the Oracle documentation for more information on how to enable compression for the version of the database that you are running. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.