# Oracle RMAN 11g Backup and Recovery- P6

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

0
127
lượt xem
23

## Oracle RMAN 11g Backup and Recovery- P6

Mô tả tài liệu

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)

Lưu

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

1. 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.
2. 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. 3. 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. 4. 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.
5. 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. 6. 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. 7. This page intentionally left blank Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 8. CHAPTER 11 RMAN Backups Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 9. 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. 10. 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. 11. 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.
12. 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.
13. 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.
14. 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.