![Objectives ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
Tendances
Tendances (19)
En vedette
En vedette (15)
Similaire à USER-MANAGED BACKUP AND RECOVERY TITLES
Similaire à USER-MANAGED BACKUP AND RECOVERY TITLES (20)
Plus de vivaankumar
USER-MANAGED BACKUP AND RECOVERY TITLES
- 1. Performing User-Managed Backup and Recovery
- 3. Restoring and Recovering Restore Recover Redo log
- 7. Recovering from a TEMPFILE Loss Password file Parameter file SYSTEM SYSAUX UNDO USERS INDEX Redo log file 1B Redo log file 1A Redo log file 2B Redo log file 2A Control files TEMP
- 9. Recovering from the Loss of a Redo Log Group Group status Inactive Active Fix media? Yes No Clear log file Perform checkpoint CKPT successful? Yes Done No Restore and recover until cancel Start Current
- 10. Clearing a Log File Log file archived? Yes No Start ALTER DATABASE CLEAR LOGFILE ... ALTER DATABASE CLEAR LOGFILE UNARCHIVED ... Needed for data file? No ALTER DATABASE CLEAR LOGFILE UNARCHIVED ... UNRECOVERABLE DATAFILE Yes
- 12. Recreating Indexes Full Notes Page
- 14. Authentication Methods for Database Administrators Remote database administration Local database administration Yes Yes No No Do you have a secure connection? Use OS authentication. Use a password file. Do you want to use OS authentication?
- 16. Re-Creating a Password Authentication File Full Notes Page
- 18. Complete Recovery Process Restored data files Data files containing committed and uncommitted transactions Recovered data files Changes applied Undo applied 5 1 Database opened 6 3 2 Archived log Archived log Online Redo log 4
- 19. Incomplete Recovery Process Data files containing committed and uncommitted transactions up to PIT PIT-recovered data files X X Changes applied to point in time (PIT) Restored data files from as far back as necessary Undo applied 5 1 Database opened Archived log Archived log Online Redo log 6 3 2 4
- 20. Incomplete Recovery Process Full Notes Page
- 22. Performing a User-Managed Backup of the Database ARCHIVELOG mode? Shutdown Put tablespaces into backup mode Copy files No Yes
- 23. The Need for Backup Mode Database block A DML statement updates a database block: Different parts of the block are written to at different times: t 2 t 1 t 3 Copy data file while online If the block is copied at time t 2 , then the block is fractured .
- 24. Identifying Files to Manually Backup SQL> select name from v$datafile; NAME ------------------------------------------------------------------------/u01/app/oracle/oradata/ORCL/datafile/o1_mf_system_36mky81f_.dbf /u01/app/oracle/oradata/ORCL/datafile/o1_mf_sysaux_36mky81p_.dbf /u01/app/oracle/oradata/ORCL/datafile/o1_mf_undotbs1_36mky857_.dbf /u01/app/oracle/oradata/ORCL/datafile/o1_mf_users_36mky876_.dbf /u01/app/oracle/oradata/ORCL/datafile/o1_mf_example_36ml2cmh_.dbf /u01/app/oracle/oradata/ORCL/datafile/survey01.dbf SQL> select name from v$controlfile; NAME ------------------------------------------------------------------------/u01/app/oracle/oradata/ORCL/controlfile/o1_mf_36ml1f8x_.ctl /u01/app/oracle/flash_recovery_area/ORCL/controlfile/o1_mf_36ml1fkk_.ctl
- 29. Performing Complete Closed Database Recovery: Overview Database open? Shutdown. No Yes Query for files to recover. Query for needed archive logs. Restore damaged files and archive logs. Repair hardware. Mount database. Open database. Recover data files. Bring data files online.
- 31. Restoring Recovery-Related Files Data files Archive logs /disk2/datafile.dbf /disk1/datafile.dbf ONLINE 1 2 3
- 32. Restoring Recovery-Related Files Full Notes Page
- 34. Performing Complete Open Database Recovery Query for files to recover. Query for needed archive logs. Restore damaged files and archive logs. Diagnose media problem. Recover data files. Bring tablespaces online. Take damaged data files offline. Yes No Done Can bring data files online?
- 35. Performing Complete Open Database Recovery Full Notes Page
- 39. Performing User-Managed Incomplete Recovery Full Notes Page
- 42. User-Managed Time-Based Recovery Steps Full Notes Page
- 46. Recovering NOLOGGING Database Objects SQL> CREATE TABLE sales_copy NOLOGGING; SQL> INSERT /*+ APPEND */ INTO sales_copy 2 SELECT * FROM sales_history; Redo log
- 47. Recovering from the Loss of All Control File Copies: Overview Online log status Data file status Unavailable Available Restore backup control file, perform complete recovery, OPEN RESETLOGS Restore backup control file, perform complete recovery, OPEN RESETLOGS Restore backup control file, perform incomplete recovery, OPEN RESETLOGS Backup Re-create control file, OPEN RESETLOGS Current
- 48. Recovering the Control File to the Default Location Repair hardware. Yes SHUTDOWN ABORT Restore control file. STARTUP MOUNT Start database recovery. No Yes Specify online log. Open database using RESETLOGS . No Database open? Archivelog missing?
Notes de l'éditeur
- Oracle Database 11 g : Administration Workshop II 6 -
- Restoring and Recovering The “recovery” portion of backup and recovery tasks includes two major types of activities: restoring and recovering. Restoring a file is the process of copying a backup into place to be used by the database. This is necessary if, for example, a file is damaged because the physical disk it is on fails. This is usually due to hardware problems, such as disk write errors, or controller failure. In that case, a backup of the file needs to be copied onto a new (or repaired) disk. Recovering the file entails applying redo such that the state of the file is brought forward in time, to whatever point you want. That point is usually as close to the time of failure as possible. In the database industry, these two operations are often referred to, collectively, with the single term “recovery.”
- Causes of File Loss Files can be lost or damaged due to: User error: An administrator may inadvertently delete or copy over a necessary operating system file. Application error: An application or script can also have a logic error in it, as it processes database files, resulting in a lost or damaged file. Media failure: A disk drive or controller may fail fully or partially, and introduce corruption into files, or even cause a total loss of files.
- Critical Versus Noncritical A noncritical file is one that the database and most applications can operate without. For example, if the database loses one multiplexed redo log file, there are still other redo log file copies that can be used to keep the database operating. Although the loss of a noncritical file does not cause the database to crash, it can impair the functioning of the database. For example: The loss of an index tablespace can cause applications and queries to run much slower, or even make the application unusable, if the indexes were used to enforce constraints. The loss of an online redo log group, as long as it is not the current online log group, can cause database operations to be suspended until new log files are generated. The loss of a temporary tablespace can prevent users from running queries or creating indexes until they have been assigned to a new temporary tablespace.
- Losing a TEMPFILE If a temporary file (tempfile) belonging to the TEMP tablespace is lost or damaged, the TEMP tablespace will not be available. This problem manifests itself as errors during the execution of SQL statements that require TEMP space for sorting. The SQL statement shown in the slide has a long list of columns to order by, which results in the need for TEMP space. This is when the missing file error is encountered. The Oracle database can start up with a missing temporary file. If any of the temporary files do not exist when the database is started, they are created automatically, and the database opens normally. When this happens, a message like the following appears in the alert log during startup: Recreating tempfile /u01/app/oracle/oradata/orcl/temp01.dbf
- Recovering from a TEMPFILE Loss You can recover from a lost TEMPFILE without restarting the database . For example, to recover the database when the temp01.dbf data file belonging to the default temporary tablespace TEMP has been deleted at the operating system (OS) level, add a new data file, and then drop the one that was deleted: SQL> ALTER TABLESPACE temp ADD TEMPFILE '/u01/app/oracle/oradata/orcl/temp02.dbf' SIZE 20M; Tablespace altered. SQL> ALTER TABLESPACE temp DROP TEMPFILE '/u01/app/oracle/oradata/orcl/temp01.dbf'; Tablespace altered.
- Oracle Database 11 g : Administration Workshop II 6 - Log Group Status: Review To deal with the loss of redo log files, it is important to understand the possible states of redo log groups. Redo log groups cycle through three different states as part of the normal running of the Oracle database. They are, in order of the cycle: CURRENT : This state means that the redo log group is being written to by LGWR to record redo data for any transactions going on in the database. The log group remains in this state until there is a switch to another log group. ACTIVE : The redo log group still contains redo data that is required for instance recovery. This is the status during the time when a checkpoint has not yet executed that would write out to the data files all data changes that are represented in the redo log group. INACTIVE : The checkpoint discussed above has indeed executed, meaning that the redo log group is no longer needed for instance recovery, and is free to become the next CURRENT log group.
- Oracle Database 11 g : Administration Workshop II 6 - Recovering from the Loss of a Redo Log Group If you have lost an entire redo log group, then all copies of the log files for that group are unusable or gone. The simplest case is where the redo log group is in the inactive state. That means it is not currently being written to, and it is no longer needed for instance recovery. If the problem is temporary, or you are able to fix the media, then the database continues to run normally, and the group is reused when enough log switch events occur. Otherwise, if the media cannot be fixed, you can clear the log file. When you clear a log file, you are indicating that it can be reused. If the redo log group in question is active, then, even though it is not currently being written to, it is still needed for instance recovery. If you are able to perform a checkpoint, then the log file group is no longer needed for instance recovery, and you can proceed as if the group were in the inactive state. If the log group is in the current state, then it is, or was, being actively written to at the time of the loss. You may even see the LGWR process fail in this case. If this happens, the instance crashes. Your only option at this point is to restore from backup, perform cancel-based incomplete recovery, and then open the database with the RESETLOGS option.
- Oracle Database 11 g : Administration Workshop II 6 - Clearing a Log File Clear a log file using this command: ALTER DATABASE CLEAR LOGFILE [UNARCHIVED] GROUP <n> [UNRECOVERABLE DATAFILE] When you clear a log file, you are indicating that it can be reused. If the log file has already been archived, the simplest form of the command can be used. Use the following query to determine which log groups have been archived: SQL> SELECT GROUP#, STATUS, ARCHIVED FROM V$LOG; For example, the following command clears redo log group 3, which has already been archived: SQL> ALTER DATABASE CLEAR LOFGILE GROUP 3; If the redo log group has not been archived, then you must specify the UNARCHIVED keyword. This forces you to acknowledge that it is possible that there are backups that rely on that redo log for recovery, and you have decided to forgo that recovery opportunity. This may be satisfactory for you, especially if you take another backup right after you correct the redo log group problem; you then no longer need that redo log file. It is possible that the redo log is required to recover a data file that is currently offline.
- Re-Creating Indexes When creating or re-creating an index, you can use the following keywords to reduce the creation time: PARALLEL ( NOPARALLEL is the default ): Multiple processes can work together simultaneously to create an index. By dividing the work necessary to create an index among multiple server processes, the Oracle server can create the index more quickly than if a single server process created the index sequentially. The table is randomly sampled and a set of index keys is found that equally divides the index into the same number of pieces as the specified degree of parallelism. A first set of query processes scans the table, extracts key, row ID pairs, and sends each pair to a process in a second set of query processes based on the key. Each process in the second set sorts the keys and builds an index in the usual fashion. After all index pieces are built, the parallel coordinator concatenates the pieces (which are ordered) to form the final index.
- Re-Creating Indexes (continued) NOLOGGING : Using this keyword makes index creation faster because it creates a very minimal amount of redo log entries as a result of the creation process. This greatly minimized redo generation also applies to direct path inserts and Direct Loader (SQL*Loader) inserts. This is a permanent attribute and thus appears in the data dictionary. It can be updated with the ALTER INDEX NOLOGGING/LOGGING command at any time. When an index is lost, it may be faster and simpler just to re-create it rather than attempt to recover it. One way to determine the SQL for creating the index is by using the impdp SQLFILE=< filename > command on a previously generated expdp output file. This generates the SQL statements needed to create the objects in the dump file. The expdp and impdp utilities are covered in detail in the Oracle Database 11g: Administration Workshop I course.
- Oracle Database 11 g : Administration Workshop II 6 - Recovering from a List Index Tablespace Indexes are computed objects, in that they do not provide any original data, and they are only a different representation of data that already exists. So, in most cases, indexes can be re-created easily. If you have a tablespace that contains only indexes, recovering from a loss of a data file belonging to that tablespace can be simplified. When a data file like this is lost, you can perform the following steps: 1. Drop the data file. 2. Drop the tablespace. 3. Re-create the index tablespace. 4. Re-create the indexes that were in the tablespace.
- Oracle Database 11 g : Administration Workshop II 6 - Authentication Methods for Database Administrators Depending on whether you want to administer your database locally on the same machine on which the database resides or to administer many different database servers from a single remote client, you can choose either operating system or password file authentication to authenticate database administrators: If the database has a password file and you have been granted the SYSDBA or SYSOPER system privilege, then you can be authenticated by a password file. If the server is not using a password file, or if you have not been granted SYSDBA or SYSOPER privileges and are, therefore, not in the password file, you can use operating system authentication. On most operating systems, authentication for database administrators involves placing the operating system username of the database administrator in a special group, generically referred to as OSDBA . Users in that group are granted SYSDBA privileges. A similar group, OSOPER , is used to grant SYSOPER privileges to users. Operating system authentication takes precedence over password file authentication. Specifically, if you are a member of the OSDBA or OSOPER group for the operating system, and you connect as SYSDBA or SYSOPER , you will be connected with associated administrative privileges regardless of the username/password that you specify .
- Oracle Database 11 g : Administration Workshop II 6 - Re-Creating a Password Authentication File The Oracle database provides a password utility, orapwd , to create a password file. When you connect using the SYSDBA privilege, you are connecting as the SYS schema and not the schema associated with your username. For SYSOPER , you are connected to the PUBLIC schema. Access to the database using the password file is provided by GRANT commands issued by privileged users. Typically, the password file is not included in backups because, in almost all situations, it can be easily re-created. It is critically important to the security of your system that you protect your password file and the environment variables that identify the location of the password file. Any user with access to these could potentially compromise the security of the connection. You should not remove or modify the password file if you have a database or instance mounted using REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE or SHARED . If you do, you will be unable to reconnect remotely using the password file. Note: Passwords are case-sensitive, so you must take that into consideration when recreating the password file.
- Oracle Database 11 g : Administration Workshop II 6 - Re-Creating a Password Authentication File (continued) Using a Password File The following are the steps for re-creating the password file: 1. Create the password file by using the password utility orapwd . orapwd file=filename password=password entries=max_users where: filename is the name of the password file (mandatory). password is the password for SYSOPER and SYSDBA (mandatory). Entries is the maximum number of distinct users allowed to connect as SYSDBA or SYSOPER . If you exceed this number, you must create a new password file. It is safer to have a larger number. There are no spaces around the “equal to” (=) character. Example: orapwd file=$ORACLE_HOME/dbs/orapwU15 password=admin entries=5 2. Connect to the database by using the password file created in step 1, and grant privileges as needed. SQL> CONNECT sys/admin AS SYSDBA SQL> grant sysdba to admin2; Password File Locations UNIX: $ORACLE_HOME/dbs Windows: %ORACLE_HOME%database Maintaining the Password File Delete the existing password file by using operating system commands, and create a new password file by using the password utility.
- Oracle Database 11 g : Administration Workshop II 6 - Comparing Complete and Incomplete Recovery When you perform complete recovery, you bring the database to the state where it is fully up-to-date, including all committed data modifications to the present time. Incomplete recovery, however, brings the database to some point in the past. This means there are missing transactions; any data modifications done between the recovery destination time and the present are lost. In many cases, this is the desirable goal because there may have been some changes made to the database that need to be undone. Recovering to a point in the past is a way to remove the unwanted changes.
- Oracle Database 11 g : Administration Workshop II 6 - Complete Recovery Process The following steps describe what takes place during complete recovery following the loss of data files: 1. Damaged or missing files are restored from a backup. 2. Changes from incremental backups, archived redo log files, and online redo log files are applied as necessary. The redo log changes are applied to the data files until the current online log is reached and the most recent transactions have been reentered. Undo blocks are generated during this entire process. This is referred to as rolling forward or cache recovery. 3. The restored data files may now contain committed and uncommitted changes. 4. The database is opened before undo is applied. This is to provide higher availability. 5. The undo blocks are used to roll back any uncommitted changes. This is sometimes referred to as transaction recovery. 6. The data files are now in a recovered state and are consistent with the other data files in the database. Note: Even if the database is opened read-only, the undo data is applied for uncommitted transactions.
- Oracle Database 11 g : Administration Workshop II 6 - Incomplete Recovery Process Incomplete recovery, or database point-in-time recovery, uses a backup to produce a noncurrent version of the database. That is, you do not apply all of the redo records generated after the most recent backup. Perform this type of recovery only when absolutely necessary. To perform incomplete recovery, you need: A valid offline or online backup of all the data files made before the recovery point All archived logs from the time of the backup until the specified time of recovery
- Oracle Database 11 g : Administration Workshop II 6 - Incomplete Recovery Process (continued) The progression taken to perform an incomplete recovery is listed below: 1. Restore the data files from backup: The backup that is used may not be the most recent one, if your restore point destination is to be not very recent. This entails either copying files using OS commands or using the RMAN RESTORE command. 2. Use the RECOVER command: Apply redo from the archived redo log files, including as many as necessary to reach the restore point destination. 3. State of over-recovery: Now the data files contain some committed and some uncommitted transactions because the redo can contain uncommitted data. 4. Use the ALTER DATABASE OPEN command: The database is opened before undo is applied. This is to provide higher availability. 5. Apply undo data: While the redo was being applied, redo supporting the undo data files was also applied. So, the undo is available to be applied to the data files in order to undo any uncommitted transactions. That is done next. 6. Process complete: The data files are now recovered to the point in time that you chose. Point-in-time recovery is the only option if you must perform a recovery and discover that you are missing an archived log containing transactions that occurred sometime between the time of the backup you are restoring from and the target recovery SCN. Without the missing log, you have no record of the updates to your data files during that period. Your only choice is to recover the database from the point in time of the restored backup, as far as the unbroken series of archived logs permits, and then open the database with the RESETLOGS option. All changes in or after the missing redo log file are lost.
- Oracle Database 11 g : Administration Workshop II 6 - Types of Backup and Recovery Practices There are two methods you can use to recover your database. You can use RMAN, and take advantage of its automatic recovery capabilities. It can restore the appropriate files and bring the database back to a current state by using very few commands. You can also recover manually. This is called user-managed recovery . User-managed recovery entails moving the files around using OS commands, and then issuing the recovery commands in SQL*Plus. Both of these methods use restore and recovery processes.
- Oracle Database 11 g : Administration Workshop II 6 - Performing a User-Managed Backup of the Database You can back up the database by using OS commands to make copies of the data files. The course of action depends on whether the database is in ARCHIVELOG mode or not. If it is, then you can keep the database open and available by putting each tablespace into backup mode before copying its data files. Otherwise, you have to shut down the database before copying the data files.
- Oracle Database 11 g : Administration Workshop II 6 - The Need for Backup Mode When a block is being written to as part of the execution of a data manipulation language (DML) statement, there could be several parts of the block affected. Not all of the modifications to the block happen at the same time, so there is the possibility of inconsistency in the block at certain times. Suppose time t 2 represents the time between when different parts of the block are written to. If, at time t 2 , the block is copied as part of the execution of an OS copy command, then the block is considered fractured. Also, the OS copy command does not necessarily copy the file header first, so it must be frozen for the duration of the copy execution. RMAN has the means to deal with this problem. If a fractured block is read, it keeps rereading it until it is consistent. However, if an OS command such as the Linux cp command is copying the data file, the fractured block is not recognized as such, and the copy of the block is not consistent. In order to remedy this, put the tablespace, or even the entire database, into what is called backup mode . The effect of doing this is that additional redo is generated. An image of each block, before it is modified, is written to the redo log. Then, during recovery of blocks in that data file, the before image of a fractured block can be used for the basis of recovery, and the additional redo data is applied to it. In order to reduce the overhead associated with maintaining extra redo data, Oracle recommends putting one tablespace at a time into backup mode, while its data files are being copied.
- Oracle Database 11 g : Administration Workshop II 6 - Identifying Files to Manually Backup User-managed backups require you to know the data file names and locations on disk, so you know what files need to be copied. Identify the data files to be backed up by querying the V$DATAFILE view. Identify the control file location by querying the V$CONTROLFILE view. Only one of the multiplexed control files needs to be backed up, because they are identical.
- Oracle Database 11 g : Administration Workshop II 6 - Manually Backing Up a NOARCHIVELOG Database You can make a consistent, whole database backup of a NOARCHIVELOG database by shutting down the database and copying all of the data files to a backup directory. Because the action of copying the files is done using OS commands (in this case, the Linux cp command), the database must be shut down first. This puts it in a consistent state. If your database is running in NOARCHIVELOG mode, this is your only option. Otherwise, in ARCHIVELOG mode, you can make inconsistent backups, which allows you to leave the database running while you take the backup.
- Oracle Database 11 g : Administration Workshop II 6 - Manually Backing Up an ARCHIVELOG Database If the database is in ARCHIVELOG mode, then you do not necessarily have to shut it down before copying the files. You end up with an inconsistent backup, but the application of redo data recovers it to a consistent state. Starting Backup Mode You do have to put each of the data files into backup mode before copying them, though. Do this using the BEGIN BACKUP clause of the ALTER TABLESPACE and ALTER DATABASE commands. Here is the syntax for each: ALTER TABLESPACE <tablespace> BEGIN BACKUP; ALTER DATABASE BEGIN BACKUP; The ALTER TABLESPACE command affects only those data files that belong to that tablespace. ALTER DATABASE affects all data files in the database. Ending Backup Mode It is important to bring the data files out of backup mode. You cannot have any data files in backup mode at the time the database is shut down. If you attempt to shut down the database in that state, you will receive an error. Also, because backup mode causes additional redo to be generated, there is extra load on the system. There is no reason to have any data files in backup mode if you are not actively backing them up.
- Oracle Database 11 g : Administration Workshop II 6 - Backing Up the Control File You should back up the control file every time you make a structural change to the database. Use one of the commands shown in the slide to do this. The first command creates a binary copy of the file. You can optionally supply the REUSE keyword, if the backup file already exists and you want to overwrite it. The second command makes a plain text version of the control file, which is actually a script that creates the control file when run. The resulting script is written to the diagnostics trace directory, such as: $ORACLE_BASE/diag/rdbms/orcl/orcl/trace
- Performing Complete Database Recovery: Overview Complete database recovery brings the database back to its most current state. You can recover the entire database, or a single tablespace or data file at a time. You must have a current control file in order to perform complete database recovery. You must also have backups available for all files in need of media recovery, which is the case where the physical stored file has been damaged in some way. You must have all the archive logs available, from the point in time the backups were taken, to the present. If you do not have all of them, you can only recover to the last point in time when redo is available. If no archive logs are required, then only online redo logs are applied. Query the following views: V$RECOVER_FILE : To see what files need media recovery V$RECOVERY_LOG : To see which archive logs are required to perform recovery
- Performing Complete Closed Database Recovery: Overview Under certain circumstances, such as damage to a file belonging to the SYSTEM tablespace, the instance shuts down automatically. Even if the instance keeps running, and there are problems with other data files, you may decide there is no value is keeping the database running; too many database objects are affected. In that case, shut down the database to perform the recovery. If the database is still open, you can query the V$RECOVERY_FILE view to see which data files are in need of recovery, and query V$RECOVERY_LOG to see which archive logs are required. That will tell you what files need to be restored from backup, if any. Then shut down the database. Look into the media failure to determine the cause of the problem. Repair the problem so that you can restore the files from backup. For example, you may need to replace a disk drive. Now, you can perform the recovery using the RECOVER command. Limit the scope of the recovery to only what is needed, such as data file or tablespace. If needed, recover the entire database. Then bring the data files online, and open the database.
- Identifying Recovery-Related Files In order to determine which data files require recovery, query the V$RECOVER_FILE view. The ERROR column indicates why the file requires recovery. If this column has any value other than OFFLINE NORMAL , then it needs recovery. To see the whole picture of which data files and tablespaces are affected, join V$DATAFILE and V$TABLESPACE in this query. Here is an example: SELECT r.FILE#, d.NAME df_name, t.NAME tbsp_name, d.STATUS, r.ERROR, r.CHANGE#, r.TIME FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t WHERE t.TS# = d.TS# AND d.FILE# = r.FILE#; This tells you the extent of the damage, helping you decide what the objects of the RECOVER command should be. The V$RECOVERY_LOG view shows what archive log files are needed to perform the recovery. If the list shows files that have since been moved off the default archive log location, then you have to restore them to some location before performing recovery. After recording the results of these queries, shut down the database.
- Restoring Recovery-Related Files After determining what data files and archive log files are required, restore them to appropriate disk locations. Restore a data file by copying it from the backup location. An example is: $ cp /disk2/backup/datafile/survey01.dbf > $ORACLE_BASE/oradata/ORCL/datafile/survey01.dbf If any archive logs are needed for recovery, check whether they are still in the default disk location for archive logs. They may not be, if they have been moved to tape or another disk drive, for example. If they have been moved, they need to be restored, either to the default archive log location or to a temporary location. If there is enough space available in the default location (which is specified by the LOG_ARCHIVE_DEST_1 initialization parameter), then restore them there. Otherwise, you can put them on some other disk location. When it is time to restore, you can specify that alternate location to find archive log files. If you had to move a data file, that fact has to be recorded in the control file. That is done by renaming the file. Here is an example: SQL> ALTER DATABASE RENAME FILE 2> '?/oradata/ORCL/datafile/survey01.dbf' 3> '/newdisk/ORCL/datafile/survey01.dbf';
- Restoring Recovery-Related Files (continued) After all files have been restored and renamed (if necessary), mount the database and bring all the data files online. You can check the status of each data file by querying the V$DATAFILE view. Bring the data files online by using a command like the following: SQL> ALTER DATABASE DATAFILE 2 > '/newdisk/ORCL/datafile/survey01.dbf' ONLINE;
- Applying Redo Data Now, the data files have been restored to some point in the past. The archive log files have also been restored: either to their default location or to some other location, for the purpose of this recovery only. You are ready to perform the actual recovery step, which means the redo is applied and the data files are brought up to the latest SCN. Do that using the SQL*Plus RECOVER command. If you do not specify the AUTOMATIC option, then you are prompted for each redo log file that is about to be applied. That gives you more control over the recovery process. Typically, AUTOMATIC is used for full recovery. If the archive log files have been restored to some disk location other than the default for the database, then you must specify the FROM clause. Supply the directory where the files are stored, and the recovery process will look there for the files. Finally, open the database. It is now fully recovered.
- Performing Complete Open Database Recovery If media failure occurs while the database is open, the database continues to function. When an attempt is made to write to one of these data files, the data file is taken offline automatically. A query against one of these data files does not cause it to go offline, but it does result in an error being returned to the user that issued the query. As with the closed database recovery, you first need to query for the files and archive logs that need to be recovered. Then, take all tablespaces that contain damaged data files offline. Use a command such as the following to do this: SQL> ALTER TABLESPACE survey OFFLINE TEMPORARY; Using the TEMPORARY option causes Oracle to perform a checkpoint on any online data files belonging to the tablespace. Checkpointed data files do not require recovery when they are brought back online, because they are up-to-date for the latest SCN of any transactions that would have affected them. This is the more desirable option, although the data files must be available at the time this command is run. It is possible that the problem was temporary, and you are able to bring the tablespaces online with no errors.
- Performing Complete Open Database Recovery (continued) Inspect the media to determine the cause of the problem. You can use the DBVERIFY utility for this. If the files are permanently damaged, then proceed to restore and recover as described for the closed database recovery earlier in this lesson. After the restore and recovery steps are complete, bring all the tablespaces online again. Note: For more information about the DBVERIFY utility, see the Backup and Recovery User’s Guide .
- Performing User-Managed Incomplete Recovery: Overview An incomplete recovery is one that does not bring the database back to the most recent SCN that was transacted. For some reason, as listed in the slide, you need to recover that database only up to a point in the past, not to the present. The processing that occurs when performing incomplete recovery differs from the processing for complete recovery, basically, in the amount of redo that is applied.
- Choosing an Incomplete Recovery Method As you plan your incomplete recovery, decide which method you want to use for specifying when to stop applying redo data. You stop the recovery process by specifying one of the following: A time: The time in the logs, at which recovery should stop. This can be automated so that the process does not prompt you for each file name. An SCN: The system change number at which recovery should stop. This can be automated so that the process does not prompt you for each file name. CANCEL : That the CANCEL keyword will be input when recovery prompts for the next redo log file name. This cannot be automated so that the process does not prompt you for each file name. It must prompt you, giving you the opportunity, at any time, to cancel the recovery.
- Oracle Database 11 g : Administration Workshop II 6 - Performing User-Managed Incomplete Recovery The following command is used to perform incomplete recovery: RECOVER [AUTOMATIC] DATABASE option Following are the meanings of the options: AUTOMATIC : Automatically applies archived and redo log files option : UNTIL TIME 'YYYY-MM-DD:HH24:MI:SS' UNTIL CANCEL UNTIL CHANGE <integer> USING BACKUP CONTROLFILE Cancel-Based Incomplete Recovery Cancel-based incomplete recovery is very much like closed database complete recovery. The difference is how you execute the RECOVER command; specify the UNTIL CANCEL clause. This clause causes the recovery process to prompt you with the suggested name for each redo log file to be applied. So, as the recovery proceeds, you are prompted with an archived or online redo log file name, and, for each one, you can either accept it or change it. When you reach the point where you want the recovery to stop, enter CANCEL instead of accepting the file name. This stops the recovery.
- Oracle Database 11 g : Administration Workshop II 6 - Performing User-Managed Incomplete Recovery (continued) Cancel-Based Incomplete Recovery (continued) After this is done, you have to open the database with the RESETLOGS option. The database is in another instantiation now, so the redo log sequence numbers need to be reset. After opening the database, check the alert log for messages. This is how you find out if the recovery was successful. To apply redo log files automatically during recovery, you can use the SQL*Plus SET AUTORECOVERY ON command, enter AUTO at the recovery prompt, or use the RECOVER AUTOMATIC command. Time- and Change-Based Incomplete Recovery Both time- and change-based incomplete recovery are like the cancel-based recovery, except that different criteria are used to specify when to stop the recovery. Time-based recovery uses a time specified on the command line of the RECOVER command, to know when to stop. Change-based recovery uses an SCN, specified on the command line. As with all incomplete recoveries, the database must then be opened using the RESETLOGS option.
- Performing User-Managed Incomplete Recovery: Steps 1. If the database is open, shut it down by using the NORMAL , IMMEDIATE , or TRANSACTIONAL option. 2. Restore all data files from backup (the most recent, if possible). You may also need to restore archived logs. If there is enough space available, restore to the LOG_ARCHIVE_DEST location or use the ALTER SYSTEM ARCHIVE LOG START TO < LOCATION > command or the SET LOGSOURCE < LOCATION > command to change the location. Mount the database. 4. Recover the database by using the RECOVER DATABASE command. 5. To synchronize data files with control files and redo logs, open the database by using the RESETLOGS option.
- User-Managed Time-Based Recovery: Example The following is a typical scenario employing UNTIL TIME recovery. Assume the following facts: The current time is 12:00 PM on November 28, 2005. A job was run incorrectly, and many tables in several schemas were affected. This happened at approximately 11:45 AM. Database activity is minimal because most staff are currently in a meeting. The state of the database before the job ran must be restored. Because the approximate time of the error is known and the database structure has not changed since 11:44 AM, you can use the UNTIL TIME method: 1. If the database is open, shut it down by using the NORMAL , IMMEDIATE , or TRANSACTIONAL option. 2. Restore all data files from backup (the most recent if possible). You may also need to restore archived logs. If there is enough space available, restore to the LOG_ARCHIVE_DEST location or use the ALTER SYSTEM ARCHIVE LOG START TO < LOCATION > command or the SET LOGSOURCE < LOCATION > command to change the location. 3. Mount the database.
- User-Managed Time-Based Recovery: Example (continued) 4. Recover the database: SQL> recover database until time '2005-11-28:11:44:00' ORA-00279: change 148448 … 11/27/05 17:04:20 needed for thread ... Media recovery complete. 5. To synchronize data files with control files and redo logs, open the database by using the RESETLOGS option: SQL> alter database open resetlogs; SQL> archive log list ... Oldest online log sequence 0 Next log sequence to archive 1 Current log sequence 1 When recovery is successful, notify users that the database is available for use, and any data entered after the recovery time (11:44 AM) will need to be reentered.
- Oracle Database 11 g : Administration Workshop II 6 - User-Managed Cancel-Based Recovery: Example After searching through the directory for the redo log files, you notice that redo log log2a.rdo cannot be located and has not been archived. Therefore, you cannot recover past this point. Querying V$LOG_HISTORY confirms the absence of archived log sequence 48 ( log2a.rdo ): SQL> SELECT * FROM v$log_history; RECID STAMP ... FIRST_CHANGE FIRST_TIME ----- --------- ... ------------ ---------- 1 318531466 ... 88330 05-11-15:12:43 47 319512880 ... 309067 05-11-28:11:26
- Oracle Database 11 g : Administration Workshop II 6 - User-Managed Cancel-Based Recovery: Example (continued) The steps for cancel-based recovery are the same as for time-based recovery, except for the RECOVER DATABASE step. When the RECOVER DATABASE UNTIL CANCEL command is executed, it recovers the database until it cannot find a log file. When you are prompted for the file name, enter CANCEL , and the recovery stops at that point in time.
- Recovering a Read-Only Tablespace Because read-only tablespaces are not being written to, there are special considerations to take into account, which can make the recovery process faster and more efficient. You do not have to put a read-only tablespace into backup mode or take it offline before copying it to the backup location. Simply copy it. When restoring a read-only tablespace, take the tablespace offline, restore the data files belonging to the tablespace, and then bring the tablespace back online. Consider the following scenario, where a read-only tablespace is changed to be read/write: 1. Make a backup of a read-only tablespace. 2. Make the tablespace read-write. 3. Recover the tablespace. The backup you made in step 1 can still be used to recover this tablespace, even though, since the backup was made, the tablespace was made read-write, and has even possibly been written to. In this case, the tablespace requires recovery, after the files are stored from such a backup.
- Recovering NOLOGGING Database Objects Take advantage of the efficiencies of the NOLOGGING attribute of tables and indexes if you can. When you create a table as NOLOGGING , no redo data is written to the redo stream to support the creation of the object. This is useful for making large inserts go faster. In the example in the slide, the SALES_COPY table is created as a NOLOGGING table. As a result, when an insert is done with the APPEND hint, no redo is generated for that particular insert statement. So, you cannot recover this transaction on the SALES_HISTORY table. If that is a problem, it is important that you make a backup of whatever tables you populate in this way, right afterward. Then you are able to go to the more recent backup of the table. If you perform media recovery, and there are NOLOGGING objects involved, they will be marked logically corrupt during the recovery process. In this case, drop the NOLOGGING objects and re-create them.
- Recovering from the Loss of All Control File Copies: Overview Even though you have copies of the control file stored in different locations, there is still the possibility that you will, at some point, have to recover from losing all of those copies. If you have lost all copies of the current control file, and have a backup control file, your course of action depends on the status of the online log files and the data files. The chart in the slide shows what to do in each of the situations shown. Online Logs Available If the online logs are available and contain redo necessary for recovery, and the data files are current, then you can restore a backup control file, perform complete recovery, and open the database with the RESETLOGS option. You must specify the file names of the online redo logs during recovery. If the data files are not current, then restore a backup control file, perform complete recovery, and open the database with the RESETLOGS option. Online Logs Not Available If the online logs are not available, and the data files are current, then re-create the control file and open RESETLOGS . However, if the data files are not current, restore a backup control file, perform incomplete recovery, and open RESETLOGS .
- Recovering the Control File to the Default Location If you need to recover the control file, and the default location is still a valid one, follow the steps shown in the slide. The database must be shut down first. Then repair any hardware, so that the default location is able to remain as a valid one. Restore the control file to the default location. Do this using a command such as this, which copies the backup control file to the default location: % cp /backup/control01.dbf /disk1/oradata/trgt/control01.dbf % cp /backup/control02.dbf /disk2/oradata/trgt/control02.dbf Mount the database, and start the recovery process. You must specify that a backup control file is being used. SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL; If, during the recovery process, you are prompted for a missing redo log, it probably means that the missing redo log is an online redo log file. When prompted, supply the name of the online redo log file. After the recovery completes, open the database, specifying the RESETLOGS option.
- Oracle Database 11 g : Administration Workshop II 6 -
- Oracle Database 11 g : Administration Workshop II 6 -