130  Chapter 3  n  Performing Oracle User-Managed Database Recoveries

E x e r c i s e 3 . 3   ( c o n t i n u e d )

ORA-00280: change 5112317 for thread 1 is in sequence #8

ORA-00279: change 5112647 generated at 08/17/2008 16:31:29 needed for thread 1 ORA-00289: suggestion : /oracle01/flash_recovery_area/ORCL/archivelog/2008_08_17 /o1_mf_1_9_4bk9p2mz_.arc

ORA-00280: change 5112647 for thread 1 is in sequence #9

ORA-00279: change 5112649 generated at 08/17/2008 16:31:30 needed for thread 1 ORA-00289: suggestion : /oracle01/flash_recovery_area/ORCL/archivelog/2008_08_17 /o1_mf_1_10_4bk9p3gz_.arc

ORA-00280: change 5112649 for thread 1 is in sequence #10 Log applied.

Media recovery complete.

10.Open the database with the alter database open resetlogs command. Note that once you have done this you will not be able to recover any data that was entered after the point of the recovery.

SQL> alter database open resetlogs; Database altered.

11.Log into the scott schema. Do a select * from test_table. You should have only two records in the table.

SQL> Connect scott/tiger Connected.

SQL> Select * from test_table; ID

----------

1

2

Performing Other Types of Recoveries

You will need to be prepared for other types of user-managed recoveries when taking your OCP exam or just in the course of managing your Oracle database. In the following sections, we will talk about the following types of user-managed recoveries:

Recovering from the Loss of a Tempfile

Tempfiles are used with temporary tablespaces. As discussed in Chapter 2, you do not need to back up a tempfile. Because of its temporary nature, the contents of a tempfile are not needed during a recovery. You will need to re-create the tempfile after any recovery that includes the temporary tablespace. This is done by using the alter tablespace add tempfile command as shown in this example, where we add a tempfile to the TEMP tablespace:

ALTER TABLESPACE TEMP ADD TEMPFILE ‘/oracle01/oradata/orcl/temp01.dbf’ SIZE 200m REUSE AUTOEXTEND ON;

Recovering from the Loss of an Online Redo Log Group

Loss of the online redo logs comes in four different flavors:

Any loss of an entire online redo log group makes for a very bad day. Loss of the last two categories (loss of an active or current online redo log) is often a disaster.

Recall that the redo logs are written to as soon as there is a commit (and other events can cause writes too). Remember also that the database datafiles are written to later, sometimes much later. Thus, the database datafiles are often way out of synchronization with the actual current state of the database. If the database crashes, then often the database datafiles are not up-to-date and this forces Oracle to apply redo to get them current when you start up the database. Normally, Oracle will do this automatically in a process called instance recovery.

As a result of the fact that the database datafiles are often out of synch with the actual state of the database, loss of an active or the current online redo log group can be disastrous. Loss of an active online redo log can result in loss of data. Loss of the current online redo log will likely result in data loss, but this is not always the case. As a result, redo logs are quite important. You may wonder what the difference between the current, active, and inactive redo logs is:

132  Chapter 3  n  Performing Oracle User-Managed Database Recoveries

NNActive: Not currently in use but the dirty blocks associated with the redo in the log file still need to be written to the datafiles by DBWR. Also, the group may still need to be archived.

NNInactive: Not currently in use and dirty blocks associated with the redo in the log file have been written to datafiles by DBWR.

You can see the status of an online redo log group by querying the STATUS column of the V$LOG view. Let’s look at what to do when it comes to recovering from loss of redo log groups.

Dealing with the Loss of an Inactive Online Redo Log Group Member

If you have lost one or more members of an online redo log group (but not the entire group) then the response is pretty easy. You can simply re-create the member using the alter database add logfile member command. For example, you might see this error in the alert log:

ORA-00313: open failed for members of log group 2 of thread 1 ORA-00312: online log 2 thread 1: ‘C:\ORACLE\ORADATA\ORCL\REDO02.LOG’

If the database has not shut down, you should immediately attempt to checkpoint the database using the alter system checkpoint command. The alter system checkpoint command forces the database to write any dirty blocks from the database buffer cache to the database datafiles in an urgent manner. This will be helpful in the event the database crashes because of this missing online redo log.

Once the checkpoint has completed, you would issue the alter database add logfile command to re-create the redo log group member redo02.log:

SQL>alter database add logfile ‘C:\ORACLE\ORADATA\ORCL\REDO02.LOG’ reuse to group 2;

If the database happened to crash before you could add the log file, you would mount the database and then issue the alter database add logfile command. You should then be able to open the database.

Another option is to shut down the database in a consistent manner (shutdown, shutdown transactional, shutdown normal) and then copy another member of the redo log group to the location of the missing member. You can then restart the database normally.

Dealing with the Loss of an Inactive Online Redo Log Group

Loss of an inactive online redo log group is not a terribly big deal in and of itself and is quite easy to recover from. There are two different situations you will need to be prepared for. First is loss of an inactive online redo log group during database startup. Second is loss of an inactive online redo log group during database operations. Let’s look at these two situations in more detail.

Dealing with the Loss of an Inactive Online Redo Log Group on Startup

First, if you start up the database and the inactive online redo log group can not be opened, you will get the following error message:

ORA-00313: open failed for members of log group 2 of thread 1 ORA-00312: online log 2 thread 1: ‘C:\ORACLE\ORADATA\ORCL\REDO02.LOG’

The response to this condition is to drop the log-file group using the alter database command as shown here:

SQL> alter database drop logfile group 2;

You can then re-create the online redo log group using the alter database add logfile command:

SQL> alter database add logfile

2group 2 ‘c:\oracle\oradata\orcl\redo02.log’ size 50m; SQL> alter database add logfile

2group 2 ‘c:\oracle\oradata\orcl\redo02.log’ size 50m;

Dealing with the Loss of an Inactive Online Redo Log Group When the Database Is Running

If you lose an inactive online redo log group (or it becomes corrupted) while the database is running, the database will sometimes keep operating. It will sometimes skip the online redo log group that went missing and continue to operate normally. In this case, you can issue an alter system checkpoint command and then clear the log-file group with the alter database clear logfile group command as shown here:

SQL>alter system checkpoint;

SQL>alter database clear logfile group 1;

It may be that when you try to clear the log file you will receive an error that indicates that the log file needs to be archived:

SQL> alter database clear logfile group 1; alter database clear logfile group 1

*

ERROR at line 1:

ORA-00350: log 1 of instance orcl (thread 1) needs to be archived ORA-00312: online log 1 thread 1: ‘/oracle01/oradata/orcl/redo01.log’

134  Chapter 3  n  Performing Oracle User-Managed Database Recoveries

Since the log file is not there, it cannot be archived. You can use the alter database clear unarchived logfile command to clear the unarchived log file, and rebuild the log file in its current location as shown here:

SQL> alter database clear

2 unarchived logfile ‘/oracle01/oradata/orcl/redo01.log’;

You will need to back up your database in this case, since an archived redo log will have been lost.

Sometimes the database will not crash but will freeze. In this case, you will open another SQL*Plus session and issue the alter database checkpoint command followed by either the alter database clear logfile or the alter database clear unarchived logfile command, depending on the type of recovery required. After issuing these commands, the database should operate as usual.

Back Up the Database After Clearing Unarchived Log Files

Sometimes the database will crash as a result of the loss of the online redo log group. In this case, you will need to follow this procedure:

Dealing with the Loss of an Active but Not Current Online Redo Log Group

Loss of an ACTIVE (as shown in V$LOG column status) online redo log group requires the use of the alter database clear unarchived logfile command as shown in the previous section. This is because the active online redo log will not have been archived and you need to indicate to Oracle that this is okay. This command will rebuild the online redo log and allow Oracle to proceed with normal operations. You should always back up the database after this operation.

Dealing with the Loss of the Current Online Redo Log Group

Losing the current online redo log group is, perhaps, the worst disaster your Oracle database could encounter. This is because there is a significant risk of loss of data in such cases. When you lose the current online redo log group, you can expect that the database will shut down.

If the database has not yet shut down, you should immediately attempt to checkpoint the database using the alter system checkpoint command and then shut down the database

afterward as soon as practical. The alter system checkpoint command forces the database to write any dirty blocks from the database buffer cache to the database datafiles in an urgent manner.

It may be that you can open the database without any recovery being required. This is the best-case situation. To try to restart the database do the following:

NNIssue the alter database clear unarchived logfile for the redo log group that was lost. Examples of this command can be seen in earlier sections of this chapter.

If the database opens successfully, you are in luck. If the database fails to open, you are in a bad way. You will need to perform incomplete recovery of the database as discussed in the section “Performing an Incomplete Recovery.” You can see an example of recovering the database as a result of the loss of the current online redo log group in Exercise 3.1.

Recovering from the Loss of a Control File

Recovery from loss of a control file depends on the nature of the loss. There are two different situations you might encounter. You might lose one or more but not all control files. You might also lose all control files. Let’s look at what to do in these cases.

Dealing with the Loss of One or More Control Files but Not All

If you have but one control file left, recovery is quite simple. Follow these steps:

NNCopy one of the remaining control files to the location of the lost control files and give it the same name as the lost control file.

Recovering from Loss of All Control Files

If you lose your control files, Oracle is not shy about telling you. If you are trying to start up your database and your control files are missing, you will see an error like this:

ORA-00205: error in identifying control file, check alert log for more info

As already discussed in Chapter 2, the alter database backup controlfile to trace command creates a script that you can use to recover your control file. The script will need to be modified before it can be used.

The script contains the following sections:

As you can see, the script has two different versions of the create controlfile command. One is for recoveries where the online redo logs are intact. You will want to edit the script so that the correct type of recovery is done. Each version of the script also contains code to register archived redo logs, recover the database, and then open the database automatically.

Let’s look at the following code, which is an example of using the NORESETLOGS case. The script is designed to do it all without any DBA interference. First it starts the database instance. It then proceeds to issue the create control file command. The script records some archived redo log records in the control file that will be needed for recovery. The database is then recovered and opened. Finally, the temporary tablespace tempfile is re-created.

STARTUP NOMOUNT

CREATE CONTROLFILE REUSE DATABASE “ORCL” NORESETLOGS ARCHIVELOG MAXLOGFILES 16

MAXLOGMEMBERS 3

MAXDATAFILES 100

MAXINSTANCES 8 MAXLOGHISTORY 292

LOGFILE GROUP 1 (

‘/oracle01/oradata/orcl/redo01.log’,

‘/oracle01/oradata/orcl/redo01a.log’ ) SIZE 100M,

GROUP 2 ( ‘/oracle01/oradata/orcl/redo02.log’, ‘/oracle01/oradata/orcl/redo02a.log’

) SIZE 50M,

GROUP 3 ( ‘/oracle01/oradata/orcl/redo03.log’, ‘/oracle01/oradata/orcl/redo03a.log’

)SIZE 50M

--STANDBY LOGFILE DATAFILE

‘/oracle01/oradata/orcl/system01.dbf’,

138  Chapter 3  n  Performing Oracle User-Managed Database Recoveries

‘/oracle01/oradata/orcl/sysaux01.dbf’,

‘/oracle01/oradata/orcl/undotbs01.dbf’,

‘/oracle01/oradata/orcl/users01.dbf’,

‘/oracle01/oradata/orcl/example01.dbf’, ‘/oracle01/oradata/orcl/retention_archives_01.dbf’, ‘/oracle01/oradata/orcl/my_secure_tbs_01.dbf’, ‘/oracle01/oradata/orcl/my_second_secure_tbs_01.dbf’

CHARACTER SET WE8MSWIN1252

;

--Configure RMAN configuration record 1 VARIABLE RECNO NUMBER;

EXECUTE :RECNO :=

SYS.DBMS_BACKUP_RESTORE.SETCONFIG(‘COMPRESSION ALGORITHM’,’‘’BZIP2’‘’);

--Configure RMAN configuration record 2

VARIABLE RECNO NUMBER;

EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG(‘CONTROLFILE AUTOBACKUP’,’ON’);

--Commands to re-create incarnation table

--Below log names MUST be changed to existing filenames on

--disk. Any one log file from each branch can be used to

--re-create incarnation records.

--ALTER DATABASE REGISTER LOGFILE

‘/oracle01/flash_recovery_area/ORCL/archivelog/2008_08_16/o1_mf_1_1_%u_.arc’; -- ALTER DATABASE REGISTER LOGFILE ‘/oracle01/flash_recovery_area/ORCL/archivelog/2008_08_16/o1_mf_1_1_%u_.arc’; -- ALTER DATABASE REGISTER LOGFILE ‘/oracle01/flash_recovery_area/ORCL/archivelog/2008_08_16/o1_mf_1_1_%u_.arc’;

--Recovery is required if any of the datafiles are restored backups,

--or if the last shutdown was not normal or immediate.

RECOVER DATABASE

-- Set Database Guard and/or Supplemental Logging

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

--All logs need archiving and a log switch is needed. ALTER SYSTEM ARCHIVE LOG ALL;

--Database can now be opened normally.

ALTER DATABASE OPEN;

--Commands to add tempfiles to temporary tablespaces.

--Online tempfiles have complete space information.

--Other tempfiles may require adjustment.

ALTER TABLESPACE TEMP ADD TEMPFILE ‘/oracle01/oradata/orcl/temp01.dbf’ SIZE 182517760 REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M;

Recovering from the Loss of the Password File

If you lose the database password file, it is simple to recover. First, if you have backed up the password file and it has not changed since the backup, you can simply restore it. If you did not have a backup of the password file, all you need to do is rerun the orapwd command to re-create the password file. The orapwd command is used to create password files. It’s executed from the command line as shown in this example:

[oracle@localhost dbs]$ cd $ORACLE_HOME/dbs

[oracle@localhost dbs]$ orapwd file=orapwtest entries=20 password=Robert

In this example, we first changed to the $ORACLE_HOME/dbs directory where password files are stored. Next we ran the orapwd command to create the password file. We passed the name of the password file using the file= parameter. Password files always start with orapw followed by the name of the database (test in this case). The entries parameter indicates the number of SYSADM entries that are allowed for, and password indicated the password associated with the SYS account.

Recovering from the Loss of Everything

Loss of everything might rightly be called the “full-meal deal.” It’s the worst possible case of data loss. If you have lost everything, you will need the following to recover your database when running in ARCHIVELOG mode:

The procedure to fully restore your database is as follows:

1.Create any new directories required.

2.Restore the Oracle software.

3.Restore or re-create the Oracle networking parameter files.

4.Restore the Oracle parameter file.

5.Rebuild the Oracle password file if required.

6.Restore the Oracle database datafiles.

7.Start up the database.

8.Recover the database using the procedure outlined in the section titled “Recovering from Loss of All Control Files.”