Вы находитесь на странице: 1из 35

http://books.google.co.in/books? id=JJGfm3E6M5sC&pg=PA69&lpg=PA69&dq=adpatch.

lgi&source=bl&ots=cNIvaWm vmI&sig=Uczk4x0aJBvW6tb97D_WWAC6hVU&hl=en&ei=mQRhTr3MONDHrQe417 0F&sa=X&oi=book_result&ct=result&resnum=7&ved=0CE0Q6AEwBg#v=onepage&q &f=true

WHAT IS RMAN ? (for DBA) Recovery Manager is a tool that: manages the process of creating backups and also manages the process of restoring and recovering from them. WHY USE RMAN ? (for DBA) No extra costs ?Its available free ?RMAN introduced in Oracle 8 it has become simpler with newer versions and easier than user managed backups ?Proper security ?You are 100% sure your database has been backed up. ?Its contains detail of the backups taken etc in its central repository Facility for testing validity of backups also commands like crosscheck to check the status of backup. Faster backups and restores compared to backups without RMAN RMAN is the only backup tool which supports incremental backups. Oracle 10g has got further optimized incremental backup which has resulted in improvement of performance during backup and recovery time Parallel operations are supported Better querying facility for knowing different details of backup No extra redo generated when backup is taken..compared to online backup without RMAN which results in saving of space in hard disk RMAN an intelligent tool Maintains repository of backup metadata Remembers backup set location Knows what need to backed up Knows what is required for recovery Knows what backups are redundant UNDERSTANDING THE RMAN ARCHITECTURE An oracle RMAN comprises of RMAN EXECUTABLE This could be present and fired even through client side TARGET DATABASE This is the database which needs to be backed up . RECOVERY CATALOG Recovery catalog is optional otherwise backup details are stored in target database controlfile . It is a repository of information queried and updated by Recovery Manager It is a schema or user stored in Oracle database. One schema can support many databases

It contains information about physical schema of target database datafile and archive log ,backup sets and pieces Recovery catalog is a must in following scenarios . In order to store scripts . For tablespace point in time recovery Media Management Software Media Management software is a must if you are using RMAN for storing backup in tape drive directly. Backups Oracle RMAN These backups complete backups in in RMAN are of backup OR RMAN are of RMAN RMAN the following type incremental backup proprietary nature

IMAGE COPY The advantage of uing Image copy is its not in RMAN proprietary format.. Backup Format RMAN backup is not in oracle format but in RMAN format. Oracle backup comprises of backup sets and it consists of backup pieces. Backup sets are logical entity In oracle 9i it gets stored in a default location There are two type of backup sets Datafile backup sets, Archivelog backup sets One more important point of data file backup sets is it do not include empty blocks. A backup set would contain many backup pieces. A single backup piece consists of physical files which are in RMAN proprietary format. Example Taking In non RMAN You RMAN Connect using target of archive get > to database taking backup RMAN mode in the target controlfile using dos prompt RMAN Backup type prompt Target Magic catalog

RMAN Connect database : instead of recovery

Lets take a simple backup of database in non archive mode shutdown immediate ; Shutdowns the database startup mount backup database ;its start backing the database alter database open; We can fire the same command in archive log mode And whole of datafiles will be backed Backup database plus archivelog; Restoring Restoring It database has been is made very simple in database 9i . just

Restore database.. RMAN has become intelligent to identify which datafiles has to be restored and the location of backuped up file. Oracle Enhancement for RMAN in 10 G

Flash Recovery Area Right now the price of hard disk is falling. Many dba are taking oracle database backup inside the hard disk itself since it results in lesser mean time between recoverability. The new parameter introduced is DB_RECOVERY_FILE_DEST = /oracle/flash_recovery_area By configuring the RMAN RETENTION POLICY the flash recovery area will automatically delete obsolete backups and archive logs that are no longer required based on that configuration Oracle has introduced new features in incremental backup Change Tracking File Oracle 10g has the facility to deliver faster incrementals with the implementation of changed tracking file feature.This will results in faster backups lesser space consumption and also reduces the time needed for daily backups Incrementally Updated Backups Oracle database 10g Incrementally Updates Backup features merges the image copy of a datafile with RMAN incremental backup. The resulting image copy is now updated with block changes captured by incremental backups.The merging of the image copy and incremental backup is initiated with RMAN recover command. This results in faster recovery. Binary compression technique reduces backup space usage by 50-75%.

With the new DURATION option for the RMAN BACKUP command, DBAs can weigh backup performance against system service level requirements. By specifying a duration, RMAN will automatically calculate the appropriate backup rate; in addition, DBAs can optionally specify whether backups should minimize time or system load. New Features in Oem to identify RMAN related backup like backup pieces, backup sets and image copy Oracle 9i New features Persistent RMAN Configuration A new configure command has been introduced in Oracle 9i , that lets you configure various features including automatic channels, parallelism ,backup options, etc. These automatic allocations and options can be overridden by commands in a RMAN command file. Controlfile Auto backups Through this new feature RMAN will automatically perform a controlfile auto backup. after every backup or copy command.

Block Media Recovery If we can restore a few blocks rather than an entire file we only need few blocks. We even dont need to bring the data file offline. Syntax for it as follows Block Recover datafile 8 block 22; Configure Backup Optimization Prior to 9i whenever we backed up database using RMAN our backup also used take backup of read only table spaces which had already been backed up and also the same with archive log too. Now with 9i backup optimization parameter we can prevent repeat backup of read only tablespace and archive log. The command for this is as follows Configure backup optimization on Archive Log failover If RMAN cannot read a block in an archived log from a destination. RMAN automatically attempts to read from an alternate location this is called as archive log failover There are additional commands backup database not backed up since time '31-jan-2002 Do not backup previously backed up (say a previous backup failed and you want to restart from where it Similar syntax is supported for backup device sbt backup set all Copy a disk backup (backing up a Additionally it . Backup of server parameter . Parallel operation . Extensive reporting . . Duplex backup . Corrupt block . Backup archive like 14:00:00' files left off). restores to tape backup supports file supported available Scripting sets detection logs

Pitfalls of using RMAN Previous to version Oracle 9i backups were not that easy which means you had to allocate a channel compulsorily to take backup You had to give a run etc . The syntax was a bit complex ?RMAN has now become very simple and easy to use.. If you changed the location of backup set it is compulsory for you to register it using RMAN or while you are trying to restore backup It resulted in hanging situations There is no method to know whether during recovery database restore is going to fail because of missing archive log file. Compulsory Media Management only if using tape backup Incremental backups though used to consume less space used to be slower since it used to

read the entire database to find the changed blocks and also They have difficult time streaming the tape device. . Considerable improvement has been made in 10g to optimize the algorithm to handle changed block. Observation Introduced in Oracle 8 it has become more powerful and simpler with newer version of Oracle 9 and 10 g. So if you really don't want to miss something critical please start using RMAN. Explain the difference between a hot backup and a cold backup and the benefits associated with each. - A hot backup is basically taking a backup of the database while it is still up and running and it must be in archive log mode. A cold backup is taking a backup of the database while it is shut down and does not require being in archive log mode. The benefit of taking a hot backup is that the database is still available for use while the backup is occurring and you can recover the database to any point in time. The benefit of taking a cold backup is that it is typically easier to administer the backup and recovery process. In addition, since you are taking cold backups the database does not require being in archive log mode and thus there will be a slight performance gain as the database is not cutting archive logs to disk. You have just had to restore from backup and do not have any control files. How would you go about bringing up this database? - I would create a text based backup control file, stipulating where on disk all the data files where and then issue the recover command with the using backup control file clause.

1. Which types of backups you can take in Oracle?

logical backups:... exp imp datapump physical backup:... cold,hot rman

2. A database is running in NOARCHIVELOG mode then which type of backups you can take? Only Cold backup can be taken and no other options. 3. Can you take partial backups if the Database is running in NOARCHIVELOG mode?

No... Should take complete backup as no incarnation level is defined. no u cant take partial backup. but u can have a tablespace back up . u need to make the tablespace offline and then begin backup of tablespace.

4. Can you take Online Backups if the the database is running in NOARCHIVELOG mode? No. B'coz for online Backups database should be in ARCHIVELOG mode 5. How do you bring the database in ARCHIVELOG mode from NOARCHIVELOG mode?

shut the database then do fllowing 1)In Parameter file set logfile destination 2)startup mount 3)alter database archivelog 4)alter database open 5)archive lo list;
6. You cannot shutdown the database for even some minutes, then in which mode you should run the database? archive mode enable level

7. Where should you place Archive logfiles, in the same disk where DB is or another disk? Yes, Archive log files should be on different disk because in case of database failure we can get the data from the Archive logfiles.

8. Can you take online backup of a Control file if yes, how? Yes you could take a online backup of a control file. SQL> alter database backup controlfile to trace; This will create a text copy of your controlfile. You could use this text file to recreate your controlfile.

== >>Alter database backup controlfile to 'PATH/control.ctl'; The above query will backup the controlfile in binary format which is not editable and can be used for restore and recovery... or We can use RMAN to backup a current controlfile RMAN>backup current controlfile; === I do not agree with you. Backup controlfile to trace would create just a Scripts for recreating the controlfile. It does not backup the controlfile even when the word backup is used in the command. Remind you control file is used even when database is shutdown. It stores complete database structure. Hence it could not be backed up while database is open. 9. What is a Logical Backup?

Logical backup involves reading a set of databse records and writing them into a file. Export utility is used for taking backup and Import utility is used to recover from backup === Logical backup is a process of extracting data in the form of SQL statements,where it is useful to recover in case the objects ate lost.The main drawback of this backup is that MEAN TIME TO RECOVER is high. === Logical backups are backups in which the export utility (for example exp) uses SQL to read database data and then export it into a binary file at the operating system level. We can then import the data back into a database using the import utility (imp).

10. Should you take the backup of Logfiles if the database is running in ARCHIVELOG mode? No. When the database runs on Archivelog mode, you backup only control files and datafiles

Take backup of redologfiles only when you are doing cold backup not when you are taking hot backup in that case take backup of datafiles and controlfiles (thru backup trace command) and archivelogs.

11. Why do you take tablespaces in Backup mode? We need to put the tablespaces in backup mode during hot backup so that writing to datafiles related to this tablespace would stop and be written in the archive logs instead during the period of the backup. If you will not put the tablespaces in backup mode and copy directly while the database is up, your backup would be not restorable. We need to backup so that it can be used in case if any failure. We restore it from these backup. Now for the backup to be used for restore it has to be valid backup. Some thing like SCN, Timestamp has to be in consistant state. So that it can be applied against the same point in time while restoring. Now you would have know as to why we take the tablespace in backup mode...just to get the consistant image of data while taking backup. Though the work (Write) on the same tablespace is carried out but the header of the datafile associated with this backup is freezed. All of these changes are written to redo logs. In a otherwise situation when the database is not in backup mode..only the change vector is written to redo logs but in backup mode the entire changed block is writen to redo logs and that's reason why we see the redo logs getting filled very fast.

12. What is the advantage of RMAN utility? 1). copies only the filled blocks i.e. even if 1000 blocks is allocated to datafile but 500 are filled with data then RMAN will only create a backup for that 500 filled blocks. 2). incremental and accumulative backup. 3). catalog and no catalog option. 4). detection of corrupted blocks during backup; 5). can create and store the backup and recover scripts. 6). increase performance through automatic parallelization( allocating channels), less redo generation.

13. How RMAN improves backup time? RMAN will not take backup of free blocks and will have multiple channels so it would be fastest than any other old / traditional ways.

14. Can you take Offline backups using RMAN? Yes... we can take backup offline with RMAN db in mount stage.

15. How do you see information about backups in RMAN? RMAN> List Backup; 16. What is a Recovery Catalog? Catalog is an inventory of the backup taken by RMAN for the said database 17. Should you place Recovery Catalog in the Same DB?

No ,Recovery catalog should be place in separated database for security reason as recommended by oracle. we can use RMAN without RC,by using Target Database control file.
18. Can you use RMAN without Recovery catalog? Yes we can use RMAN without catalog. The information gets stored in the control file. $>connect target / no catalog

19. Can you take Image Backups using RMAN? Yes. The command used to take image copy of database is, RMAN> backup as copy database; 20. Can you use Backupsets created by RMAN with any other utility? No. The backup Sets created by RMAN utility cannot be used in other utility other than

RMAN. 21. Where RMAN keeps information of backups if you are using RMAN without Catalog? control files. 22. You have taken a manual backup of a datafile using o/s. How RMAN will know about it? Whenever we take any backup through RMAN, in the repository information of the backup is recorded. The RMAN respository can be either controlfile or recovery catalog. However if I take a backup through OS command then RMAN does not aware of that and hence recorded are not reflected in the repository. This is also true whenever we create a new controlfile or a backup taken by RMAN is transferred to another place using OS command then controlfile/recovery catalog does not know about the prior backups of the database. So in order to restore database with a new created controlfile we need to inform RMAN about the backups taken before so that it can pick one to restore. This task can be done by catalog command in RMAN. With catalog command it can -Add information of backup pieces and image copies in the repository that are on disk. -Record a datafile copy as a level 0 incremental backup in the RMAN repository. -Record of a datafile copy that was taken by OS. But CATALOG command has some restrictions. It can't do the following. -Can't catalog a file that belong to different database. -Can't catalog a backup piece that exists on an sbt device. Examples of Catalog command 1)Catalog an archive log: To catalog two archived logs named /oracle/oradata/arju/arc001_223.arc and /oracle/oradata/arju/arc001_224.arc the command is, RMAN>CATALOG ARCHIVELOG '/oracle/oradata/arju/arc001_223.arc', '/oracle/oradata/arju/arc001_224.arc'; 2)Catalog a file copy as an incremental backup: To catalog datafile copy '/oradata/backup/users01.dbf' as an incremental level 0 backup your command will be, RMAN>CATALOG DATAFILECOPY '/oradata/backup/users01.dbf' LEVEL 0; Note that this datafile copy was taken backup either using the RMAN BACKUP AS COPY command, or by using operating system utilities in conjunction with ALTER TABLESPACE BEGIN/END BACKUP. 3)Catalog multiple copies in a directory: To catalog all valid backups from directory /tmp/backups issue, RMAN>CATALOG START WITH '/tmp/backups' NOPROMPT; 4)Catalog files in the flash recovery area: To catalog all files in the currently enabled

flash recovery area without prompting the user for each one issue, RMAN>CATALOG RECOVERY AREA NOPROMPT; 5)Catalog backup pieces: To catalog backup piece /oradata2/o4jccf4 issue, RMAN>CATALOG BACKUPPIECE '/oradata2/o4jccf4'; Uncatalog Backup In many cases you need to uncatalog command. Suppose you do not want a specific backup or copy to be eligible to be restored but also do not want to delete it. To uncatalog all archived logs issue, RMAN>CHANGE ARCHIVELOG ALL UNCATALOG; To uncataog tablespace USERS issue, RMAN>CHANGE BACKUP OF TABLESPACE USERS UNCATALOG; To uncatalog a backuppiece name /oradata2/oft7qq issue, RMAN>CHANGE BACKUPPIECE '/oradata2/oft7qq' UNCATALOG; == RMAN> catalog datafilecopy 'c:\users01.dbf'; using target database control file instead of recovery catalog cataloged datafile copy datafile copy filename=C:\USERS01.DBF recid=1 stamp=695238977 RMAN> list copy; using target database control file instead of recovery catalog specification does not match any archive log in the recovery catalog List of Datafile Copies Key File S Completion Time Ckp SCN Ckp Time Name ------- ---- --------------- ---------- --------------- ---- 1 4 A 18-AUG-09 546902 18-AUG-09 C:\USERS01.DBF

23. You want to retain only last 3 backups of datafiles. How do you go for it in RMAN? CONFIGURE RETENTION POLICY TO REDUNDANCY 3 you need to configure retention period in RMAN.

24. Which is more efficient Incremental Backups using RMAN or Incremental Export? Obviously RMAN incremental backup 25. Can you start and shutdown DB using RMAN? Yes 26. How do you recover from the loss of datafile if the DB is running in NOARCHIVELOG mode?

you can recover from cold backup only but it wouldnt be consistent... i.e. you need to restore complete cold backup 27. You loss one datafile and it does not contain important objects. The important objects are there in other datafiles which are intact. How do you proceed in this situation? Simply,drop the datafile recreate the new datafile If database is in Archive log mode and have full backup Restore the datafile from backup and recover it If database is not in archive log mode and dont have backup Re Create the Datafile and this file will be empty. it dont contain any data 28. You lost some datafiles and you don't have any full backup and the database was running in NOARCHIVELOG mode. What you can do now? Well, you can recreate that but data would be lost U lost datafiles and u dont have backup and not in archive log mode...... re create the datafiles which will be empty..... u can not recover, becuase u dont have backup and not in archive log mode . 29. How do you recover from the loss of datafile if the DB is running in ARCHIVELOG mode? Restore the data file and recover tha same. 30. You loss one datafile and DB is running in ARCHIVELOG mode. You have full database backup of 1 week old and partial backup of this datafile which is just 1 day old. From which backup should you restore this file? Restore it from Full backup and recover that data file using archive log files which are after Full backup to till date 31. You loss controlfile how do you recover from this?

Recovery: All Control Files Missing


You have lost all copies of the control file. The normal database activities continue until the next update of the control file. When this happens (during the next checkpoint or redo log file switch, at the latest), the database system crashes. A complete recovery of the database is possible provided one of the following conditions is fulfilled:

A current backup copy of the control file, that is, a copy with the current structure of the database, exists. A current log of the files in the database exists, enabling you to create the control file again. If all the control files (even the backups) are lost, you must first reconstruct the control file before you can start the recovery process. This procedure is much more complicated and not always guaranteed to be successful. Please therefore strictly observe the following note, which cannot be repeated often enough:

Follow SAPs recommendations and back up your database after every structure change! If you do this, you always have a backup of a control file that reflects the current structure of the database.

Recovery Using the Backed-Up Control File


In the procedure described in the following, we assume that you are able to restore the control file from your last database backup. To update the database, the appropriate redo log files must exist. It is essential that the saved control file always reflects the current structure of the database. The paths for the data and log files and the status of the log sequence numbers are not important, but the control file must have the exact information about the number of files and - indirectly - the number of tablespaces in the database. Proceed as follows for recovery: If the database system is still operating, shut down all instances with the following SVRMGR command: shutdown abort ABORT is generally necessary because the control files are no longer available to include a checkpoint during the shutdown. Use the ALERT and trace files to analyze the error. Check whether other damage has occurred to the database: Find out whether all data files and redo log files are readable. Back up the online redo log files of all instances (if they exist in readable form) so that you can repeat the recovery process if an error occurs. Place the backup copies of the control file in the directories or on the raw devices specified in the control_files parameter in the init.ora profile. If further files were damaged, restore the backup copies of these files. You do not need to restore undamaged files from the backup. If you have to restore data files, you will also have to restore all the offline redo log files of all instances that have been archived since

the last backup (for SAP databases, offline redo log files are usually archived by the BRARCHIVE program) in the local archiving directory (default value: <ORACLE_HOME>/saparch ). For detailed information on recovery after the loss of redo log or data files, please refer to the relevant parts of this documentation and to your ORACLE documentation. Enter the following SVRMGR commands to mount the local instance: connect internal startup mount If you could not load backed up files into their original directories or had to change file name, you must update the control file. Change path or group names with the following command: alter database rename file '<file name>' to '<file name>'; See Updating the Control File. If the data files of the database were set to status OFFLINE during the shutdown, change the status of the files in the control file to ONLINE. To find OFFLINE files, search for "offline" in the ALERT file. To change the status of a data file in the control file, use the following command: alter database datafile '<file name>' online; See Updating the Control File. Start recovery with the following SVRMGR command: recover database until cancel using backup controlfile; If you are prompted to do so, enter the full path name for the redo log files required for recovery, including the active online redo log file. When all redo log files are processed, end the recovery process with the command cancel . After the message recovery canceled , you can reopen the database by using the following SVRMGR command: alter database open resetlogs; or alter database open noresetlogs; The RESETLOGS option initializes the existing online redo log files. Therefore, only use this option after a partial recovery. If a full recovery has been performed, you should not use this option. The NORESETLOGS option causes the online redo log files to be used in their current form. A complete recovery is required to use this option. The database system resumes operations with the log sequence number following the number of the last current online redo log file.

Carry out a complete backup of the database. The backup is necessary to back up the control file and to guarantee a full recovery of the database if further database problems occur. See also: Actions after a Partial Recovery.

DB Recovery Using a New Control File


If you do not have a valid copy of the control file, a full recovery is still possible by reconstructing the control file. To do this, you need a current log of all the database files, for example, the BRBACKUP log. Caution: If a structural change to the database has been carried out after this backup, it may be impossible to perform a recovery (e.g. if no backup of the new or changed data files is available). Proceed as follows during recovery: If the database is still active, shut down all instances with the following SVRMGR command: shutdown abort ABORT is generally necessary because the control files are no longer available to include a checkpoint during the shutdown. Use the ALERT and trace files to analyze the error. Make sure no further damage has occurred in the database, and find out whether all data files and online redo log files exist in readable form. Back up the online redo log files of all instances (if they exist in readable form) so that you can repeat the recovery process if an error occurs. If other files were damaged, restore the backup copies of these files. You do not need to restore undamaged files from the backup. If you have to recover data files, also restore all the offline redo log files of all instances that have been archived since the backup of these data files in the archiving directory. Enter the following SVRMGR commands to demount the database: connect internal startup nomount Use the following command to create the control file (for detailed syntax information, please refer to your ORACLE documentation): create controlfile database <name> logfile '<online redo log groups>' noresetlogs|resetlogs maxlogfiles 10 maxlogmembers <your value> datafile '<names of all data files>' maxdatafiles 254 archivelog; Path names: The path names of the online redo log files and data files can be found in the last detail log from BRBACKUP. Noresetlogs/Resetlogs: Only select RESETLOGS when an online redo log group was

lost in addition to the control file. You should otherwise always use NORESETLOGS. Mount the database. alter database mount; Start the recovery with the following command (a recovery is required whenever the control file was generated with the RESETLOGS object or when a data file was restored. Recovery is recommended for security reasons in other cases, as well.): recover database [until cancel] [using backup controlfile]; You must select the option using backup controlfile when you used the RESETLOGS option to create the control file. If you select until cancel , you can interactively decide how many files of the existing redo log files you want to read during the recovery. You should enter all the redo log files of all instances, including the current ones. Use the following SVRMGR command to start up the database: alter database open [noresetlogs/resetlogs]; Use alter database open if you created the control file with NORESETLOGS and have performed no recovery or a full recovery (without until cancel ). Use alter database open noresetlogs if you created the control file with NORESETLOGS and performed a full recovery despite the use of the until cancel option. Use alter database open resetlogs if you created the control file with RESETLOGS or when you performed a partial recovery. After the recovery, be sure to perform a complete backup to save the newly created control file and to ensure that a recovery of the database in the event of failure is possible.

32. The current logfile gets damaged. What you can do now? Once current redolog file is damaged, instance is aborted and it needs recovery upto undamaged part. Only undamaged part can be recovered. Here DBA must apply time based recovery, means it can be a point in time or specified by SCN. It leads to incomplete recovery 33. What is a Complete Recovery?

Complete and Incomplete Media Recovery


Media recovery updates a backup to either to the current or to a specified noncurrent time. When performing media recovery, you can recover the whole database, a tablespace, or a datafile. In any case, you always use a restored backup to perform the recovery.

This section contains the follow topics: Complete Recovery Incomplete Recovery

Complete Recovery
Complete recovery involves using redo data or incremental backups combined with a backup of a database, tablespace, or datafile to update it to the most current point in time. It is called complete because Oracle applies all of the redo changes contained in the archived and online logs to the backup. Typically, you perform complete media recovery after a media failure damages datafiles or the control file.

You can perform complete recovery on a database, tablespace, or datafile. If you are performing complete recovery on the whole database, then whether you are using RMAN or SQL*Plus you must: Mount the database Ensure that all datafiles you want to recover are online Restore a backup of the whole database or the files you want to recover Apply online or archived redo logs, or a combination of the two

If you are performing complete recovery on a tablespace or datafile, then you must: Take the tablespace or datafile to be recovered offline if the database is open Restore a backup of the datafiles you want to recover Apply online or archived redo logs, or a combination of the two

Incomplete Recovery
Incomplete recovery uses a backup to produce a noncurrent version of the database. In

other words, you do not apply all of the redo records generated after the most recent backup. You usually perform incomplete recovery of the whole database in the following situations: Media failure destroys some or all of the online redo logs. A user error causes data loss, for example, a user inadvertently drops a table. You cannot perform complete recovery because an archived redo log is missing. You lose your current control file and must use a backup control file to open the database.

To perform incomplete media recovery, you must restore all datafiles from backups created prior to the time to which you want to recover and then open the database with the RESETLOGS option when recovery completes. The RESETLOGS operation creates a new incarnation of the database--in other words, a database with a new stream of log sequence numbers starting with log sequence 1.

Tablespace Point-in-Time Recovery

The tablespace point-in-time recovery (TSPITR) feature enables you to recover one or more tablespaces to a point-in-time that is different from the rest of the database. TSPITR is most useful when you want to: Recover from an erroneous drop or truncate table operation Recover a table that has become logically corrupted Recover from an incorrect batch job or other DML statement that has affected only a subset of the database Recover one independent schema to a point different from the rest of a physical database (in cases where there are multiple independent schemas in separate tablespaces of one physical database) Recover a tablespace on a very large database (VLDB) rather than restore the whole database from a backup and perform a complete database roll-forward Media Recovery Options Because you are not completely recovering the database to the most current time, you must tell Oracle when to terminate recovery. You can perform the following types of media recovery.

Type of Recovery

Function

Time-based recovery

Recovers the data up to a specified point in time.

Cancel-based recovery

Recovers until you issue the CANCEL statement (not available when using Recovery Manager).

Change-based recovery

Recovers until the specified SCN.

Log sequence recovery

Recovers until the specified log sequence number (only available when using Recovery Manager).

34. What is Cancel Based, Time based and Change Based Recovery? Cancel-Based Recovery Steps Restore the damaged files from the backup. Using the following command, mount the database but do not open it:
startup mount

Start the recovery:


recover database until cancel [using backup controlfile]

At this point, you will be prompted for the location of the archived redo log files, if necessary. Enter cancel to cancel recovery after Oracle has applied the archived redo log file just prior to the point of corruption. If a backup control file or recreated control file is being used with incomplete recovery, you should specify the using backup controlfile option. In cancel-based recovery, you cannot stop in the middle of applying a redo log file. You either completely apply a redo log file or you don't apply it at all. In time-based recovery, you can apply to a specific point in time, regardless of the archived redo log number. Open the database:
alter database open resetlogs

Whenever an incomplete media recovery is being performed or the backup control file is used for recovery, the database should be opened with the resetlogs option. The resetlogs option will reset the redo log files. Perform a full backup of database. If you open the database with resetlogs, a full backup of the database should be performed immediately after recovery. Otherwise, you will not be able to recover changes made after you reset the logs. Verify that the recovery worked. Time-Based Recovery Steps Restore the damaged files from the backup. Using the following command, mount the database but do not open it:
startup mount

Start the recovery:


recover database until time [using backup controlfile]

For example
recover database until time '1999-01-01:12:00:00' using backup controlfile

At this point, you will be prompted for the location of the archived redo log files, if necessary. Oracle automatically terminates the recovery when it reaches the correct time. If a backup control file or recreated control file is being used with incomplete recovery, you should specify the using backup controlfile option. Open the database:
alter database open resetlogs

Whenever an incomplete media recovery is being performed or the backup control file is used, the database should be opened with the resetlogs option, so that it resets the log numbering. Perform a full backup of the database. If the database is opened with resetlogs, a full backup of the database should be performed immediately after recovery. Otherwise, you will not be able to recover the changes made after you reset the logs. Verify that the recovery worked. Change-Based Recovery Steps Restore the damaged files from the backup. Using the following command, mount the database but do not open it:
startup mount

Start the recovery:


recover database until change [using backup controlfile]

For example
recover database until change 2315 using backup controlfile

At this point, you will be prompted for the location of the archived redo log files, if necessary. Oracle automatically terminates the recovery when it reaches the correct system change number (SCN). If a backup control file or a recreated control file is being used with an incomplete recovery, you should specify using the backup controlfile option. Open the database.
alter database open resetlogs

Perform a full backup of the database. If the database is opened with resetlogs, a full backup of the database should be performed immediately after recovery. Otherwise, you will not be able to recover the changes made after you reset the logs. Verify that the recovery worked. System Tablespace Versus a Non-System Tablespace Recovery When a system data file is lost or damaged, the only way to recover the database is by doing a closed database recovery using RECOVER DATABASE command. Checking for Files Needing Recovery The following command can be used to check the data file status. This command works when the database is mounted or open.
select name, status from v$datafile;

Before you actually start recovering the database, you can obtain information about the files that need recovery by executing the following command. To execute the statement, the database must be mounted. The command also gives error information.
select b.name, a.error from v$recover_file a, v$datafile b where a.file# = b.file#

Time-Based Recovery
Time-based recovery allows the DBA to recover to a desired point. This situation is most likely to occur if archive logfiles or redo logfiles needed for recovery are lost or damaged and cannot be restored. In this situation you would apply all logs until a point in time specified by the UNTIL TIME clause of the RECOVER command. Follow these steps to execute a time-based recovery:

If the database is still open, shut down the database using the SHUTDOWN command with the ABORT option. Make a full backup of the database including all datafiles, a control file, and the parameter files in case an error is made during the recovery. Correct the problem that caused the media failure. If the problem cannot be corrected, the datafiles must be restored to an alternate location. If this is the case, the ALTER TABLESPACE RENAME DATAFILE command must be used to change the location of the datafile in the control file. If the current control files do not match the physical structure of the database at the time you want to recover to, restore a backup of the control file that matches the database's physical file structure at the point in time you want to recover to. Replace all current control files of the database with the one you want to use for recovery. If you do not have a backup copy of the control file, you can create a new one. Restore backups of all datafiles. Make sure the backups were taken before the point in time you are going to recover to. Any datafiles added after the point in time you are recovering to should not be restored. They will not be used in the recovery and will have to be recreated after recovery is complete. Any data in the datafiles created after the point of recovery will be lost. Make sure read-only tablespace are offline before you start recovery so recovery does not try to update the datafile headers. Start SQL*Plus and connect to Oracle as SYS. Start the instance and mount the database using the STARTUP command with the MOUNT option. If you restored files to an alternative location, change the location now in the control file by using the ALTER TABLESPACE RENAME DATAFILE command. Make sure all the datafiles in the database are online using the ALTER DATABASE command with the DATAFILE ONLINE option. You can check the status of datafiles by querying the V$DATAFILE view. Use the RECOVER DATABASE UNTIL TIME 'YYYY-MM-DD:HH24:MI:SS' command to start time-based recovery. If backup control files are used, then you may also specify the USING BACKUP CONTROLFILE option:
RECOVER DATABASE UNTIL TIME 'YYYY-MM-DD:HH24:MI:SS' USING BACKUP CONTROLFILE;

Oracle will now start the roll forward by applying the archived redo logfiles and the online redo logfile. If AUTORECOVERY is set to ON, the applying of the log files is automatic. If it is not set to ON, you will be prompted for each log file. If

you used a backup control file you must enter the names of the online redo logfiles. Oracle will automatically stop recovery when the time specified in the RECOVER command has been reached. Oracle will respond with a recovery successful message. Use the ALTER DATABASE OPEN command with the RESETLOGS or NORESETLOGS option. You should use the RESETLOGS option if you used a backup of the control file in recovery or the recovery was incomplete. Use the NORESETLOGS option if the recovery was complete. If you are using a standby database and must reset the logs, the standby database will need to be re-created. You can check the ALERT file to see if your incomplete recovery was actually a complete recovery. If the recovery was a complete recovery, the message in the ALERT file is as follows:
RESETLOGS after complete recovery through change scn

If the recovery was incomplete, the following message is recorded:


RESETLOGS after incomplete recovery UNTIL CHANGE scn

After opening the database using the RESETLOGS option, perform a normal shutdown and a full database backup. If you do not do this, any changes made after the recovery and before the next full backup are unrecoverable. If you did not reset the logs, the database is still recoverable.

35. Some user has accidentally dropped one table and you realize this after two days. Can you recover this table if the DB is running in ARCHIVELOG mode? Yes. 36. Do you have to restore Datafiles manually from backups if you are doing recovery using RMAN? No..Not possible. 37. A database is running in ARCHIVELOG mode since last one month. A datafile is added to the database last week. Many objects are created in this datafile. After one week this datafile gets damaged before you can take any backup. Now can you recover this datafile when you don't have any backups? You can to create a empty datafile, for example: alter database create datafile '/u01/oradata/users01.dbf'; and perform a recover of this datafile

38. How do you recover from the loss of a controlfile if you have backup of controlfile? Generally, you would include "using backup control file" in your recovery statement under two conditions: 1. Anytime the controlfile is older than any of your datafiles. 2. You do not have a valid current control file. (It is either missing or corrupt.) e.g: 1) cp -a /backup/control.bkp /u01/oradata/control[xx].ctl 2) startup mount 3) recover database using backup controlfile (apply the archived redo log file and on-line redo log files if necessary) 4) alter database open resetlogs; 1. The current logfile gets damaged. What you can do now? Not multiplexed ? Then you will need to perform an incomplete recovery: Restore the datafiles from the last backup, use the RECOVER UNTIL CANCEL command, open the database with RESETLOGS option, and make a full cold backup ... 39. Only some blocks are damaged in a datafile. Can you just recover these blocks if you are using RMAN? Yes..This example recovers corrupt blocks in three datafiles:
BLOCKRECOVER DATAFILE 2 BLOCK 12, 13 DATAFILE 3 BLOCK 5, 98, 99 DATAFILE 4 BLOCK 19; CORRUPTION LIST:Recovers

all blocks listed in the V$DATABASE_BLOCK_CORRUPTION

view 40. Some datafiles were there on a secondary disk and that disk has become damaged and it will take some days to get a new disk. How will you recover from this situation? Firstly, you will need to put these datafiles in OFFLINE mode ... in order to prevent the DBWR try write in these datafiles, after you will need restore these lost datafiles from last backup and apply the archive redo log files ... 41. Have you faced any emergency situation. Tell us how you resolved it? 42. At one time you lost parameter file accidentally and you don't have any backup. How you will recreate a new parameter file with the parameters set to previous values. From Alertlog file

Opening or Bringing the database in Archivelog mode.


To open the database in Archive log mode. Follow these steps: STEP 1: Shutdown the database if it is running.

STEP 2: Take a full offline backup. STEP 3: Set the following parameters in parameter file. LOG_ARCHIVE_FORMAT=ica%s.%t.%r.arc LOG_ARCHIVE_DEST_1=location=/u02/ica/arc1 If you want you can specify second destination also LOG_ARCHIVE_DEST_2=location=/u02/ica/arc1 Step 3: Start and mount the database. SQL> STARTUP MOUNT STEP 4: Give the following command SQL> ALTER DATABASE ARCHIVELOG; STEP 5: Then type the following to confirm. SQL> ARCHIVE LOG LIST; STEP 6: Now open the database SQL>alter database open; Step 7: It is recommended that you take a full backup after you brought the database in archive log mode.

To again bring back the database in NOARCHIVELOG mode. Follow these steps:
STEP 1: Shutdown the database if it is running. STEP 2: Comment the following parameters in parameter file by putting " # " . # LOG_ARCHIVE_DEST_1=location=/u02/ica/arc1 # LOG_ARCHIVE_DEST_2=location=/u02/ica/arc2 # LOG_ARCHIVE_FORMAT=ica%s.%t.%r.arc STEP 3: Startup and mount the database. SQL> STARTUP MOUNT; STEP 4: Give the following Commands

SQL> ALTER DATABASE NOARCHIVELOG; STEP 5: Shutdown the database and take full offline backup. TAKING OFFLINE BACKUPS. ( UNIX ) Shutdown the database if it is running. Then start SQL Plus and connect as SYSDBA. $sqlplus SQL> connect / as sysdba SQL> Shutdown immediate SQL> Exit After Shutting down the database. Copy all the datafiles, logfiles, controlfiles, parameter file and password file to your backup destination. TIP: To identify the datafiles, Logfiles query the data dictionary tables V$DATAFILE and V$LOGFILE before shutting down. Lets suppose all the files are in "/u01/ica" directory. Then the following command copies all the files to the backup destination /u02/backup. $cd /u01/ica $cp * /u02/backup/ Be sure to remember the destination of each file. This will be useful when restoring from this backup. You can create text file and put the destinations of each file for future use. Now you can open the database. TAKING ONLINE (HOT) BACKUPS.(UNIX) To take online backups the database should be running in Archivelog mode. To check whether the database is running in Archivelog mode or Noarchivelog mode. Start sqlplus and then connect as SYSDBA. After connecting give the command "archive log list" this will show you the status of archiving. $sqlplus Enter User:/ as sysdba SQL> ARCHIVE LOG LIST If the database is running in archive log mode then you can take online backups. Let us suppose we want to take online backup of "USERS" tablespace. You can query the

V$DATAFILE view to find out the name of datafiles associated with this tablespace. Lets suppose the file is "/u01/ica/usr1.dbf ". Give the following series of commands to take online backup of USERS tablespace. $sqlplus Enter User:/ as sysdba SQL> alter tablespace users begin backup; SQL> host cp /u01/ica/usr1.dbf /u02/backup SQL> alter tablespace users end backup; SQL> exit; RECOVERING THE DATABASE IF IT IS RUNNING IN NOARCHIVELOG MODE.

Option 1: When you dont have a backup.


If you have lost one datafile and if you don't have any backup and if the datafile does not contain important objects then, you can drop the damaged datafile and open the database. You will loose all information contained in the damaged datafile. The following are the steps to drop a damaged datafile and open the database. (UNIX) STEP 1: First take full backup of database for safety. STEP 2: Start the sqlplus and give the following commands. $sqlplus Enter User:/ as sysdba SQL> STARTUP MOUNT SQL> ALTER DATABASE DATAFILE '/u01/ica/usr1.dbf ' offline drop; SQL>alter database open;

Option 2:When you have the Backup.


If the database is running in Noarchivelog mode and if you have a full backup. Then there are two options for you. i . Either you can drop the damaged datafile, if it does not contain important information

which you can afford to loose. ii . Or you can restore from full backup. You will loose all the changes made to the database since last full backup. To drop the damaged datafile follow the steps shown previously. To restore from full database backup. Do the following. STEP 1: Take a full backup of current database. STEP 2: Restore from full database backup i.e. copy all the files from backup to their original locations. (UNIX) Suppose the backup is in "/u2/oracle/backup" directory. Then do the following. $cp /u02/backup/* /u01/ica This will copy all the files from backup directory to original destination. Also remember to copy the control files to all the mirrored locations. RECOVERING FROM LOST OF CONTROL FILE. If you have lost the control file and if it is mirrored. Then simply copy the control file from mirrored location to the damaged location and open the database If you have lost all the mirrored control files and all the datafiles and logfiles are intact. Then you can recreate a control file. If you have already taken the backup of control file creation statement by giving this command. " ALTER DATABASE BACKUP CONTROLFILE TO TRACE; " and if you have not added any tablespace since then, just create the controlfile by executing the statement But If you have added any new tablespace after generating create controlfile statement. Then you have to alter the script and include the filename and size of the file in script file. If your script file containing the control file creation statement is "CR.SQL" Then just do the following. STEP 1: Start sqlplus STEP 2: connect / as sysdba STEP 3: Start and do not mount a database like this.

SQL> STARTUP NOMOUNT STEP 4: Run the "CR.SQL" script file. STEP 5: Mount and Open the database. SQL>alter database mount; SQL>alter database open; If you do not have a backup of Control file creation statement. Then you have to manually give the CREATE CONTROL FILE statement. You have to write the file names and sizes of all the datafiles. You will lose any datafiles which you do not include. Refer to "Managing Control File" topic for the CREATE CONTROL FILE statement. Recovering Database when the database is running in ARCHIVELOG Mode.

Recovering from the lost of Damaged Datafile.


If you have lost one datafile. Then follow the steps shown below. STEP 1. Shutdown the Database if it is running. STEP 2. Restore the datafile from most recent backup. STEP 3. Then Start sqlplus and connect as SYSDBA. $sqlplus Enter User:/ as sysdba SQL>Startup mount; SQL>Set autorecovery on; SQL>alter database recover; If all archive log files are available then recovery should go on smoothly. After you get the "Media Recovery Completely" statement. Go on to next step. STEP 4. Now open the database SQL>alter database open; Recovering from the Lost Archived Files: If you have lost the archived files. Then Immediately shutdown the database and take a full offline backup.

Time Based Recovery (INCOMPLETE RECOVERY). Suppose a user has a dropped a crucial table accidentally and you have to recover the dropped table. You have taken a full backup of the database on Monday 13-Aug-2007 and the table was created on Tuesday 14-Aug-2007 and thousands of rows were inserted into it. Some user accidently drop the table on Thursday 16-Aug-2007 and nobody notice this until Saturday. Now to recover the table follow these steps. STEP 1. Shutdown the database and take a full offline backup. STEP 2. Restore all the datafiles, logfiles and control file from the full offline backup which was taken on Monday. STEP 3. Start SQLPLUS and start and mount the database. STEP 4. Then give the following command to recover database until specified time. SQL> recover database until time '2007:08:16:13:55:00' using backup controlfile; STEP 5. Open the database and reset the logs. Because you have performed a Incomplete Recovery, like this SQL> alter database open resetlogs; STEP 6. After database is open. Export the table to a dump file using Export Utility. STEP 7. Restore from the full database backup which you have taken on Saturday. STEP 8. Open the database and Import the table.

Types of Oracle Recovery


This section contains these topics: Instance and Crash Recovery Media Recovery

Instance and Crash Recovery


Crash recovery is used to recover from a failure either when a single-instance database crashes or all instances of an Oracle Real Application Clusters database crashes. Instance recovery refers to the case where a surviving instance recovers a failed instance in an Oracle Real Application Clusters database.

The goal of crash and instance recovery is to restore the data block changes located in the cache of the dead instance and to close the redo thread that was left open. Instance and crash recovery use only online redo log files and current online datafiles. Oracle recovers the redo threads of the dead instances together.

Crash and instance recovery have the following shared characteristics: Redo the changes using the current online datafiles (as left on disk after the crash or SHUTDOWN ABORT) Use only the online redo logs and never require the use of the archived logs Have a recovery time governed by the number of dead instances, amount of redo generated in each dead redo thread since the last checkpoint, and by userconfigurable factors such as the number and size of redo log files, checkpoint frequency, and the parallel recovery setting

Oracle performs this recovery automatically on two occasions: At the first database open after the crash of a single-instance database or all instances of an Oracle Real Applications Cluster database (crash recovery). When some but not all instances of an Oracle Real Application Clusters configuration fail (instance recovery). The recovery is performed automatically by a surviving instance in the configuration.

The important point is that in both crash and instance recovery Oracle applies the redo automatically: no user intervention is required to supply redo logs. However, you can set parameters in the database server that can tune the duration of instance and crash recovery performance. Also, you can tune the rolling forward and rolling back phases of instance recovery separately. Finally, you can tune checkpointing so that recovery time is optimized.

Media Recovery
Media recovery is divided into the following types: Datafile media recovery Block media recovery

Typically, the term "media recovery" refers to recovery of datafiles. Block media recovery is a more specialized operation that you can only perform with RMAN.

Datafile Media Recovery

Datafile media recovery is used to recover from a lost or damaged current datafile or control file. It is also used to recover changes that were lost when a tablespace went offline without the OFFLINE NORMAL option. Datafile media recovery and instance recovery have in common the requirement to repair database integrity. However, these types of recovery differ with respect to their additional features. Media recovery has the following characteristics: Applies needed changes using restored backups of damaged datafiles. Can use archived logs as well as the online logs. Requires explicit invocation by a user. Does not detect media failure (that is, the need to restore a backup) automatically. After a backup has been restored, however, detection of the need to recover it through media recovery is automatic. Has a recovery time governed solely by user policy (for example, frequency of backups, parallel recovery parameters) rather than by Oracle internal mechanisms.

The database cannot be opened if any of the online datafiles needs media recovery, nor can a datafile that needs media recovery be brought online until media recovery has been executed. The following scenarios necessitate media recovery: You restore a backup of a datafile. You restore a backup control file (even if all datafiles are current).

A datafile is taken offline (either by you or automatically by Oracle) without the OFFLINE NORMAL option.

Unless the database is not open by any instance, datafile media recovery can only operate on offline datafiles. You can initiate datafile media recovery before opening a database even when crash recovery would have sufficed. If so, crash recovery still runs automatically at database open.

Note that when a file requires media recovery, you must perform media recovery even if all necessary changes are contained in the online logs. In other words, you must still run recovery even though the archived logs are not needed. Media recovery may find nothing to do -- and signal the "no recovery required" error -- if invoked for files that do not need recovery.

Block Media Recovery

Block media recovery is a technique for restoring and recovering individual data blocks while all database files remain online and available. If corruption is limited to only a few blocks among a subset of database files, then block media recovery may be preferable to datafile recovery. The interface to block media recovery is provided by RMAN. If you do not already use RMAN as your principal backup and recovery solution, then you can still perform block media recovery by cataloging into the RMAN repository the necessary user-managed datafile and archived redo log backups.

Redo Application During Recovery


Media recovery proceeds through the application of redo data to the datafiles. Whenever a change is made to a datafile, the change is first recorded in the online redo logs. Media recovery selectively applies the changes recorded in the online and archived redo logs to the restored datafile to roll it forward.

This section contains these topics: About Redo Application Cache Recovery

Transaction Recovery

About Redo Application


Database buffers in the buffer cache in the SGA are written to disk only when necessary, using a least-recently-used (LRU) algorithm. Because of the way that the database writer process uses this algorithm to write database buffers to datafiles, datafiles may contain some data blocks modified by uncommitted transactions and some data blocks missing changes from committed transactions.

Two potential problems can result if an instance failure occurs: Data blocks modified by a transaction might not be written to the datafiles at commit time and may only appear in the redo log. Therefore, the redo log contains changes that must be reapplied to the database during recovery. After the roll forward phase, the datafiles may contain changes that had not been committed at the time of the failure. These uncommitted changes must be rolled back to ensure transactional consistency. These changes were either saved to the datafiles before the failure, or introduced during the roll forward phase.

To solve this dilemma, two separate steps are generally used by Oracle for a successful recovery of a system failure: rolling forward with the redo log (cache recovery) and rolling back with the rollback or undo segments (transaction recovery).

Cache Recovery
The online redo log is a set of operating system files that record all changes made to any database buffer, including data, index, and rollback segments, whether the changes are committed or uncommitted. All changes to Oracle blocks are recorded in the online log.

The first step of recovery from an instance or disk failure is called cache recovery or rolling forward, and involves reapplying all of the changes recorded in the redo log to the datafiles. Because rollback data is also recorded in the redo log, rolling forward also regenerates the corresponding rollback segments

Rolling forward proceeds through as many redo log files as necessary to bring the database forward in time. Rolling forward usually includes online redo log files (instance recovery or media recovery) and may include archived redo log files (media recovery only).

After rolling forward, the data blocks contain all committed changes. They may also contain uncommitted changes that were either saved to the datafiles before the failure, or were recorded in the redo log and introduced during cache recovery.

Transaction Recovery
You can run Oracle in either manual undo management mode or automatic undo management mode. In manual mode, you must create and manage rollback segments to record the before-image of changes to the database. In automatic undo management mode, you create one or more undo tablespaces. These undo tablespaces contain undo segments similar to traditional rollback segments. The main difference is that Oracle manages the undo for you.

Undo blocks (whether in rollback segments or automatic undo tablespaces) record database actions that should be undone during certain database operations. In database recovery, the undo blocks roll back the effects of uncommitted transactions previously applied by the rolling forward phase.

After the roll forward, any changes that were not committed must be undone. Oracle applies undo blocks to roll back uncommitted changes in data blocks that were either written before the crash or introduced by redo application during cache recovery. This process is called rolling back or transaction recovery.

Figure 3-1 illustrates rolling forward and rolling back, the two steps necessary to recover from any type of system failure.