Oracle RMAN 11g Backup and Recovery- P9

368 Part III: Using RMAN Effectively List of Datafiles in backup set 211 File LV Type Ckp SCN Ckp Time Name - -1 Incr 4471684 23-FEB-06 C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\SYSTEM01.DBF Incr 4471684 23-FEB-06 C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\NEWTBS01.DBF Incr 4471684 23-FEB-06 C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\TEST RECOVER 01.DBF Incr 4471684 23-FEB-06 C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\TEST RECOVER TWO 01.DBF BS Key Type LV Size Device Type Elapsed Time Completion Time - - 216 Incr 728.00K DISK 00:00:38 23-FEB-06 BP Key: 216 Status: AVAILABLE Compressed: YES Tag: TAG20060223T144904 Piece Name: C:\ORACLE\PRODUCT\10.2.0\FLASH RECOVERY AREA\ROB10R2\BACKUPSET\2006 02 23 \O1 MF NNND1 TAG20060223T144904 1ZW7Y40G BKP List of Datafiles in backup set 216 File LV Type Ckp SCN Ckp Time Name - -2 Incr 4472638 23-FEB-06 C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\UNDOTBS01.DBF Incr 4472638 23-FEB-06 C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\SYSAUX01.DBF Incr 4472638 23-FEB-06 C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\USERS01.DBF Incr 4472638 23-FEB-06 C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\EXAMPLE01.DBF BS Key Type LV Size Device Type Elapsed Time Completion Time - - 217 Incr 328.00K DISK 00:01:10 23-FEB-06 BP Key: 217 Status: AVAILABLE Compressed: YES Tag: TAG20060223T144904 Piece Name: C:\ORACLE\PRODUCT\10.2.0\FLASH RECOVERY AREA\ROB10R2\BACKUPSET\2006 02 23 \O1 MF NNND1 TAG20060223T144904 1ZW7Z98D BKP List of Datafiles in backup set 217 File LV Type Ckp SCN Ckp Time Name - -1 Incr 4472653 23-FEB-06 C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\SYSTEM01.DBF Incr 4472653 23-FEB-06 C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\NEWTBS01.DBF Incr 4472653 23-FEB-06 C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\TEST RECOVER 01.DBF Incr 4472653 23-FEB-06 C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\TEST RECOVER TWO 01.DBF Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Chapter 14: List of Key 300 Archived Log Thrd Seq 23 RMAN Advanced Recovery Topics 369 Copies S Low Time Name - - -A 23-FEB-06 C:\ARCHIVE\ROB10R2ARC00023 0582936761.001 Media recovery start SCN is 4472638 Recovery must be done beyond SCN 4472653 to clear data files fuzziness Finished restore at 23-FEB-06 Some vendors support “recalling” media from a DR site to use for a local restore The restore database preview recall supports this functionality, allowing you to initiate a recall of the required backup files from a remote disaster recovery site in order to perform the restore preview Restoring with the validate and check logical Commands The restore command comes with some great options that allow you to verify that your database is recoverable and that the backup itself is valid First, you can use the validate parameter of the backup command to cause RMAN to check the backup sets and to make sure your database is recoverable When you use the validate option, Oracle checks the most current backup set that will be needed to recover your database, ensuring that it is complete This option also checks any datafile copies and archived redo log backup sets that will be required for recovery and ensures that they are all complete Additionally, the validate option does a general validation of the backup sets to ensure that they are intact Validation doesn’t take very long and is one way to ensure that your database is recoverable Here is an example of a validate operation on our database: RMAN> restore database validate; Starting restore at 05-JUL-02 using channel ORA DISK using channel ORA DISK channel ORA DISK 1: starting validation of datafile backupset channel ORA DISK 2: starting validation of datafile backupset channel ORA DISK 1: restored backup piece piece handle D:\BACKUP\RECOVER\BACKUP 4QDSM5IB 1 tag TAG20020703T221224 params NULL channel ORA DISK 1: validation complete channel ORA DISK 2: restored backup piece piece handle D:\BACKUP\RECOVER\BACKUP 4RDSM5IC 1 tag TAG20020703T221224 params NULL channel ORA DISK 2: validation complete Finished restore at 05-JUL-02 Another, more complete check of the most current backup set is the check logical parameter of the restore command This command causes RMAN to check the backups of the database, if they pass a physical corruption check, for logical corruption within the data and index segments backed up If logical errors are found, Oracle responds in one of two ways: ■ If the maxcorrupt parameter has been set and this count is not exceeded during the restore check logical operation, RMAN populates the Oracle V$ table V$DATABASE_ BLOCK_CORRUPTION with a list of corrupted block ranges ■ If maxcorrupt is exceeded during the operation, then the operation will terminate Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 370 Part III: Using RMAN Effectively By default, maxcorrupt is set to 0, so any logical corruption will cause the operation to fail The maxcorrupt parameter default is modified via the set command and can only be established within the confines of a run block Additionally, maxcorrupt is set for each datafile individually, not collectively The following is an example of setting maxcorrupt to allow for some corruption to appear, and then logically validating backups of our database In this example, we have set maxcorrupt for all the datafiles in our database (1 through 5), and we not only are checking that the latest backup sets are present and recoverable, but also are looking for logical corruption within the backup sets RMAN> run { 2> set maxcorrupt for datafile 1,2,3,4,5,6 to 5; 3> restore database check logical validate; 4> } executing command: SET MAX CORRUPT Starting restore at 05-JUL-02 using channel ORA DISK using channel ORA DISK channel ORA DISK 1: starting validation of datafile backupset channel ORA DISK 2: starting validation of datafile backupset channel ORA DISK 1: restored backup piece piece handle D:\BACKUP\RECOVER\BACKUP 4QDSM5IB 1 tag TAG20020703T221224 params NULL channel ORA DISK 1: validation complete channel ORA DISK 2: restored backup piece piece handle D:\BACKUP\RECOVER\BACKUP 4RDSM5IC 1 tag TAG20020703T221224 params NULL channel ORA DISK 2: validation complete Finished restore at 05-JUL-02 Using the validate backupset Command Using the restore command with the validate and/or check logical parameters only checks the most current backup set There may well be times that you want to check a specific backup set To this, you use the validate backupset command To use this command, you first need to determine the backup set key that you want to back up Each backup set, when it is made, is assigned a unique identifier called the backup set key To determine the key assigned to the backup set you are interested in, you can use the list backupset command, as shown in the following example: RMAN> list backupset; List of Backup Sets BS Key Type LV Size Device Type Elapsed Time Completion Time - - 141 Full 320K DISK 00:02:09 03-JUL-02 BP Key: 141 Status: AVAILABLE Tag: TAG20020703T221224 Piece Name: D:\BACKUP\RECOVER\BACKUP 4QDSM5IB 1 List of Datafiles in backup set 141 File LV Type Ckp SCN Ckp Time Name - -2 Full 647435 03-JUL-02 D:\ORACLE\ORADATA\RECOVER\REVDATA.DBF Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Chapter 14: Full 647435 Full 647435 RMAN Advanced Recovery Topics 371 03-JUL-02 D:\ORACLE\ORADATA\RECOVER\TOOLS01.DBF 03-JUL-02 D:\ORACLE\ORADATA\RECOVER\REVINDEX.DBF BS Key Type LV Size Device Type Elapsed Time Completion Time - - 142 Full 113M DISK 00:03:28 03-JUL-02 BP Key: 142 Status: AVAILABLE Tag: TAG20020703T221224 Piece Name: D:\BACKUP\RECOVER\BACKUP 4RDSM5IC 1 List of Datafiles in backup set 142 File LV Type Ckp SCN Ckp Time Name - -1 Full 647439 03-JUL-02 D:\ORACLE\ORADATA\RECOVER\SYSTEM01.DBF Full 647439 03-JUL-02 D:\ORACLE\ORADATA\RECOVER\INDX01.DBF Full 647439 03-JUL-02 D:\ORACLE\ORADATA\RECOVER\USERS01.DBF Here, we are interested in the report’s BS Key column, which lists the backup set key number Notice that the files in the backup set also are listed, as are the date and time of the backup All of this information should make it easy to identify the backup set you wish to validate Once you have determined the set you need to check, then validating the backup set is as easy as running the validate backupset command, as shown in the next two examples: RMAN> validate backupset 141; using channel ORA DISK using channel ORA DISK channel ORA DISK 1: starting validation of datafile backupset channel ORA DISK 1: restored backup piece piece handle D:\BACKUP\RECOVER\BACKUP 4QDSM5IB 1 tag TAG20020703T221224 params NULL channel ORA DISK 1: validation complete RMAN> validate backupset 141 check logical; using channel ORA DISK using channel ORA DISK channel ORA DISK 1: starting validation of datafile backupset channel ORA DISK 1: restored backup piece piece handle D:\BACKUP\RECOVER\BACKUP 4QDSM5IB 1 tag TAG20020703T221224 params NULL channel ORA DISK 1: validation complete Call the Movers! Cross-Platform Database Movement and RMAN Oracle Database supports manually moving databases across different platforms, even those of different endian formats The endian formats relate to byte ordering, and there are two different formats, big endian and little endian If you want to move a database between databases of different endian byte formats, then you have to so manually, using the RMAN convert datafile or convert tablespace command along the way to convert the datafiles being transported to the correct endian format In this section, we quickly cover cross-platform transportable tablespaces We then discuss the different endian byte-ordering formats Next, we discuss converting tablespaces for transport Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 372 Part III: Using RMAN Effectively to platforms with different endian byte formats We finish with a discussion of using RMAN to move databases between different platforms with the same endian byte format Introduction to Cross-Platform Transportable Tablespaces On several occasions, we, as DBAs, really wanted to be able to move our tablespaces between our development NT Oracle database and our production Sun Oracle database We have had cases where we really wanted to move them between a Sun platform and an AIX platform Until Oracle Database 10g, this was just a dream Now, Oracle supports transporting tablespaces across almost all platforms of the Oracle database family This has a number of benefits, including: ■ Efficient publication of data between different content providers ■ Easy movement of data between data warehouses, data marts, and OLTP systems ■ Easy migration of databases across platforms NOTE Not all platforms are currently supported for this functionality Check your platform-specific documentation to determine if your platform is eligible There are a few other issues to mention To move a tablespace between platforms, compatible must be set to 10.0.0 or higher When this occurs, tablespace datafiles will be made platformaware upon the next startup operation Note that read-only and offline datafiles become crossplatform compatible only after they have been made read-write or brought online Byte Ordering and Datafile Conversion In this section, first, we introduce you to the concept of byte ordering in Oracle database datafiles and how this impacts transporting your tablespace between different platforms Then, we will look at how to convert these datafiles, if that is required Datafile Byte Ordering Oracle platforms generally use two different byte-ordering schemes (known as the endian formats) If the platforms use the same byte-ordering scheme, then you can transport tablespaces as you always have in the past, no problem… Go ahead and try it We will wait for you! If the byte-ordering scheme is different, then you will need to use the convert command in RMAN to convert the tablespace to the format that it will need to be in on the target platform You can determine the endian format via a join of the dynamic view V$DATABASE and the new V$TRANSPORTABLE_PLATFORM view, as shown in this example: SQL> Select endian format From v$transportable platform tp, v$database d Where tp.platform name d.platform name; ENDIAN FORMAT -Little Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Chapter 14: RMAN Advanced Recovery Topics 373 In this case, the system we are on is using the little endian format Thus, if the query returns the same result on both systems, you have a compatible datafile format; if it does not, you need to use RMAN and the compatible parameter to transport the tablespaces Converting the Tablespace Endian Format with RMAN If you need to convert a tablespace for another platform, RMAN is the tool you use First, create the directory that the converted file will be copied to In our example, we will use the directory path c:\oracle\oradata\betatwo Next, make the tablespace that you wish to convert read-only Then, simply start RMAN and use the new convert tablespace command, as shown in this example: Rman target / RMAN> convert tablespace users to platform ' AIX-Based Systems (64-bit)' db file name convert 'c:\oracle\oradata\betatwo', 'c:\oracle\admin\transport aix'; You can also convert datafiles at the destination site: Rman target / RMAN> convert datafile c:\oracle\oradata\betatwo\*' from platform ' AIX-Based Systems (64-bit)' db file name convert 'c:\oracle\oradata\betatwo', 'c:\oracle\admin\transport aix'; The platform name that we use comes from the PLATFORM_NAME column of the V$TRANSPORTABLE_PLATFORM view Oracle is very picky about putting the name in just right Once you have completed the conversion, you may complete the move by manually moving the datafiles/tablespaces using transportable tablespaces Note that in cases where the endian format is different, RMAN will not be able to help you If the endian format is the same, read the next section to see if you can use RMAN’s new feature that moves your database across platforms for you! We Like to Move It! Move It! RMAN in Oracle Database 10g offers a brand-new feature to assist you in moving your databases across platforms of the same endian byte format The convert database command, in combination with the DBMS_TDP package, can help reduce the overall workload of moving your database between platforms The process consists of the following steps: Open the database as read only: startup mount; alter database open read only; Use the dbms_tdb.check_db procedure to check the database state You should have already determined your platform name (from the PLATFORM_NAME column of the V$TRANSPORTABLE_PLATFORM view) This program should be run with serveroutput turned on, as in this example: set serveroutput on declare db ready boolean; begin db ready : dbms tdb.check db Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 374 Part III: Using RMAN Effectively ('Microsoft Windows IA (32-bit)',dbms tdb.skip readonly); end; / Use the dbms_tdb.check_external procedure to identify external objects: set serveroutput on Declare external boolean; begin external : dbms tdb.check external; end; / When the database is ready for transport, use the RMAN convert database command RMAN creates scripts that are required for the database move RMAN does not actually the move, but creates only the files that are used for the move CONVERT DATABASE NEW DATABASE 'copydb' transport script 'c:\oracle\copydb\copyscripts' to platform 'Microsoft Windows IA (32-bit)'; The optional db_file_name_convert parameter allows you to define the directory filenames for datafiles that need to be converted Here is an example: CONVERT DATABASE NEW DATABASE 'copydb' transport script 'c:\oracle\copydb\copyscripts' to platform 'Microsoft Windows IA (32-bit)' db file name convert 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2','C:\ORACLE\NEWDBDEST'; Once the command completes, simply follow the directions that RMAN will give you to complete the conversion process on the target database Sometimes Things Just Go Wrong Sometimes you just cannot get a break On some rare occasions, RMAN just will not work like it’s supposed to So, what you do? Here are some suggestions we suggest you try if your RMAN restore/recover is not quite going the way you want it to If the restore is not working successfully, execute the crosscheck command, and make sure that all the backup sets that RMAN thinks are available are actually available The crosscheck command is used to make sure that the RMAN catalog and control file are in synch with what is actually on disk We discuss the crosscheck command in detail in Chapter 17 In the case where a restore command is not working, or is picking up a wrong backup set, run these commands: crosscheck backup of database; crosscheck backup of archivelog all; crosscheck archivelog all; If any of the backup sets show up with a status of EXPIRED, then you may be missing backup sets that are needed to perform the restore This can be due to many reasons—loss of a disk drive, or perhaps a well-meaning system administrator has backed them up to tape for you Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Chapter 14: RMAN Advanced Recovery Topics 375 If the backup sets are all okay, and the restore is still not running correctly, then make sure you check things such as how you have set the UNTIL TIME parameter if you are doing a pointin-time restore True story: In one case, we had a DBA (a really smart one, by the way) who was trying to restore from a backup taken on 04/01/09 Unfortunately, it took something like four hours for him to realize that his restore string read 03/01/09 instead It is small syntax errors like this that can drive you mad Oftentimes the error messages can give you some clue as to the problem For example, they may indicate that the media management layer is not properly configured This is a common problem, particularly if you are restoring a backup to a database server other than the one where the backup originally occurred If the restore command works great but the recover command is failing, check for syntax errors again This is another place where you can get your dates wrong Also make sure that all the needed archived redo logs are available One problem we see from time to time is that some of the needed redo ends up not having been archived Sometimes we have to go to the online redo logs to replay that redo In cases like this, we will actually need to go into SQL*Plus and complete the recover process manually To recover manually using the SQL*Plus prompt, the following: Perform the normal RMAN restore command It’s fine to use the until time clause Perform the normal RMAN recover command If Step fails, start SQL*Plus from a separate terminal window Determine which archived redo logs are required for your restore You can use the V$ARCHIVED_LOG and V$LOG views to determine the location of the archived redo logs, the time they were created, and their associated log sequence number Here is an example of queries against the V$ARCHIVED_LOG, V$LOG, and V$LOGFILE views that give us some important information that we will need to complete our recovery: This tells us the last archived redo log file sequence number select max(sequence#), max(resetlogs time), max(resetlogs change#) from v$log history where resetlogs time (select max(resetlogs time) from v$log history); This tells us the online redo log sequence numbers select a.sequence#, a.first time, b.member from v$log a, v$logfile b where a.group# b.group# order by a.sequence#; The recover database command will indicate which archived redo log it wishes to recover In some cases, you may need to enter the name of the online redo log to recover the database, because the redo contained in it had not been archived yet In this case, we will apply the redo from online redo log C:\ORACLE\ORADATA\BETA1\REDO02.LOG: SQL> recover database ORA-00279: change 5071334 generated at 08/17/2008 15:35:51 needed for thread ORA-00289: suggestion : /oracle01/flash recovery area/ORCL/archivelog/2008 08 17/ o1 mf 4bk6onh8 arcORA-00280: Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 376 Part III: Using RMAN Effectively change 5071334 for thread is in sequence #5 Specify log: { suggested | filename | AUTO | CANCEL} C:\ORACLE\ORADATA\BETA1\REDO02.LOG Log applied Media recovery complete Then simply open the database: SQL> alter database open; Database altered Summary In this chapter, we have explored point-in-time recoveries that are available in RMAN Timebased, SCN-based, and cancel-based recoveries are all supported by RMAN This chapter also touched on RMAN’s ability to recover through the resetlogs command, a welcome feature to us old-time DBAs who have struggled with this issue This chapter also covered some miscellaneous recovery topics We touched on things like archived redo log recoveries, read-only tablespace recovery considerations, and block-level recovery In short, we covered the wide gamut of RMAN’s recovery toolbox Finally, in this chapter, we explored tablespace point-in-time recoveries Specifically with tablespace point-in-time recovery, you can run into complexities for various reasons, and thus, it might well be that you will need to reference the Oracle documentation for implementation details that relate to your case Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark CHAPTER 15 Surviving User Errors: Flashback Technologies Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark ... your database is recoverable and that the backup itself is valid First, you can use the validate parameter of the backup command to cause RMAN to check the backup sets and to make sure your database... validate backupset command To use this command, you first need to determine the backup set key that you want to back up Each backup set, when it is made, is assigned a unique identifier called the backup. .. determine the key assigned to the backup set you are interested in, you can use the list backupset command, as shown in the following example: RMAN> list backupset; List of Backup Sets BS Key Type LV