122 Chapter 3 n Performing Oracle User-Managed Database Recoveries
Performing Database Recoveries in the Real World
In this book, we are providing you with some of the most common recovery situations that you might face and that appear on the OCP exam. The reality is that in the real world, recovery can quickly become very complex and overwhelming. You have people looking over your shoulder, 200 opinions on how to fix the problem (all of them different, of course), and you face an issue that does not quite neatly fit into the backup and recovery case studies that you have experienced in your training.
The key to figuring out what to do is to sit back and think about what the problem is and why it is happening. Another key is if you feel that you might be getting in over your head, get Oracle support on the line. Sometimes it takes a while to get them geared up to really help you, and the sooner you get them engaged, the better you will be in the end.
Finally, when you are troubleshooting, don’t shotgun solutions. If you are not sure about your solution, think it out very carefully. Talk to other DBAs around you and get their opinions. Nothing makes a bad day worse like having a database failure and then realizing that you just made it a bigger problem by screwing up the recovery process.
Performing Incomplete Recoveries
Incomplete recovery (also called point-in-time recovery) is the process of recovering the database to a different point in time than the most current point in time. Why would one do such a thing, you ask? There may be a number of reasons:
NN |
Loss of one of the online redo log groups making full recovery impossible |
|
|
NN |
User error requiring a recovery of the database to a different point in time |
NN |
Creation of a duplicate database to a point in time other than that of the source database. |
In the following sections, we will cover the basics of incomplete recovery. First we will discuss the requirements for and mechanics of incomplete recovery, and then we will cover preparation for incomplete recovery. Finally, we will walk through the process of an actual incomplete recovery.
Requirements for and Mechanics of an Incomplete Recovery
The requirements for incomplete recovery are much like those of a complete recovery from an online backup. First, the database must be in ARCHIVELOG mode. Second, you have to
Performing Incomplete Recoveries |
123 |
have a backup of the database (online or offline) and all of the archived redo logs required to get your database to the point in time that you are interested in.
Preparing for an Incomplete Recovery
The first step in performing an incomplete recovery is to restore the database from a backup that was taken before the point in time to which you want to restore the database.
Notice that you have to restore the entire database. This can sometimes confuse lessexperienced DBAs. With incomplete recovery, you must restore the entire database, and it must be restored to a point in time before the point in time that you wish to recover to.
For example, suppose it’s 2 p.m. and you wish to recover just the USERS tablespace objects to 1 p.m. because someone messed something up. To do so, it’s not just as simple as restoring the USERS tablespace datafiles to 1 p.m. You have to restore the entire database to 1 p.m.
Tablespace Point-in-Time Recovery
There is a concept of tablespace point-in-time recovery that allows you to restore just a tablespace to a point in time different from that of the database. We will discuss tablespace point-in-time recovery using RMAN in Chapter 8. The OCP exam does not require that you know how to do tablespace point-in-time recovery manually, so we are not covering that topic in this book.
Oracle is persnickety about datafile consistency. Recall the concept of the SCN, which is Oracle’s internal counter for all operations. When you do an insert, it is assigned an SCN. When you then commit that insert, it is assigned a different, higher SCN. This way, Oracle knows the insert came first and the commit came second.
When you start the Oracle database, it’s a demanding bit of software. It requires that the SCN in each datafile be the same before it will open the database (there is an exception to this with read-only tablespaces). Also, there are SCNs stored in the control file that have
to jibe with the SCNs in the datafiles. If the SCNs don’t jibe, then some form of recovery is required.
So, if the entire database is at SCN 12345 (see Figure 3.1) and you restore the USERS tablespace to SCN 1234, that will be a problem. Oracle will detect the different SCNs and require a complete recovery. Not quite what we hoped for.
So, when you want to perform an incomplete database recovery, you have to restore all the datafiles to a point in time at or before the point in time that you actually want to recover to. In Figure 3.2, you can see that all the datafiles are recovered to SCN 1230 or less, so you can now begin an incomplete recovery to SCN 1234 as you wish.
Note that you do not need to restore the control file to a previous version for incomplete recovery to work. Once you have finished the incomplete-recovery process, Oracle will reset the control file so that it will correctly reflect the current state of the database.
124 Chapter 3 n Performing Oracle User-Managed Database Recoveries
F i g u r e 3 .1 Database with datafiles restored incorrectly for incomplete recovery
SCN the Same |
SCN the Same |
SCN the Same |
SCN Different |
Datafile #1 |
Datafile #2 |
Datafile #3 |
Datafile #4 |
SYSTEM |
SYSAUX |
UNDO |
USERS |
Tablespace |
Tablespace |
Tablespace |
Tablespace |
SCN: 12345 |
SCN: 12345 |
SCN: 12345 |
SCN: 1234 |
You want to recover to SCN 1234. Datafiles 1, 2, and 3 are at SCN 12345, which is after SCN 1234. Incomplete recovery to SCN 1234 is not possible because recovery rolls forward SCNs, not backward.
F i gu r e 3 . 2 Database with datafiles restored correctly for incomplete recovery
SCN the Same |
SCN the Same |
SCN the Same |
SCN the Same |
Datafile #1 |
Datafile #2 |
Datafile #3 |
Datafile #4 |
SYSTEM |
SYSAUX |
UNDO |
USERS |
Tablespace |
Tablespace |
Tablespace |
Tablespace |
SCN: 1230 |
SCN: 1230 |
SCN: 1230 |
SCN: 1230 |
You want to recover to SCN 1234. All datafiles are at SCN 1230. It’s now easy to recover them all to SCN 1234.
You will also need to restore all archived redo logs that were generated from the time of the backup image until the point that you want to restore to. You can determine which archived redo log sequence numbers you want to restore by looking at the V$ARCHIVED_LOG view (we provided a query using the V$ARCHIVED_LOG view in a note earlier in this chapter). Keep in mind that you may also need redo contained in an online redo log that has not been archived yet. Since you will not be restoring any online redo logs, this won’t be
a problem.
Now that you have restored all the database datafiles and the needed archived redo logs, you are ready to execute your incomplete database recovery.
Performing an Incomplete Recovery
Having restored the database datafiles, recovery is pretty easy. First you determine the type of recovery that you want to do, and then you perform the recovery using the recover database command. Finally, you open the database. Let’s look at these steps in some more detail next.
Performing Incomplete Recoveries |
125 |
Determining the Type of Point-in-Time Recovery
There are three types of point-in-time recovery that you can perform:
Time-based recovery Time-based recovery is based on the time that you want to recover your database to. Time-based recovery is granular to the nearest second.
Log sequence–based recovery Log sequence–based recovery is based on defining the log sequence number you wish the database to be recovered to. You will need to determine the correct log sequence number. The V$ARCHIVED_LOG and V$LOG views may be helpful in making this determination.
Change-based recovery Change-based recovery is based on the SCN that you wish to restore your database to. You can determine what the current SCN of the database is by querying the CURRENT_SCN column of the V$DATABASE view. You can also associate a given time to an approximate SCN by using the TIMESTAMP_TO_SCN, SCN_TO_TIMESTAMP, or SMON_ SCN_TIME view.
Perform Your Point-in-Time Recovery
Regardless of which of the three point-in-time recoveries you choose to perform, the overall process is very similar. You will use the recover database command for your recovery. Each recovery type will take a different keyword, as shown here:
Time-based recovery To perform time-based recovery use the recover database until time command. The format of the time in the command is ‘yyyy-mm-dd:hh24:mi:ss’, which is consistent in each Oracle database (so it is not dependent on parameters such as NLS_DATE_ FORMAT). Here is an example of the use of the recover database until time command:
Recover database until time ‘2008-10-23:13:00:00’
In this example, the database will be recovered up to October 23, 2008 at 1 p.m. Any transaction that are committed after that point will be rolled back.
Log sequence–based recovery To perform log sequence–based recovery, use the recover database until sequence command. This example recovers to log sequence 34:
Recover database until sequence 34;
Change-based recovery To perform change-based recovery, use the recover database until change command followed by the SCN you wish to recover to. In this example, we recover to SCN 226250:
Recover database until change 226250;
Once the recovery begins, you will be prompted for the appropriate archived redo logs to apply just as with a complete database recovery. The main difference is that the application of archived redo logs (and possibly online redo logs) will automatically cease once the point
126 Chapter 3 n Performing Oracle User-Managed Database Recoveries
in time, change, or SCN has been reached. Once the redo has been applied, the database is ready to be opened.
Opening the Database
Having recovered the database, you will want to open it. A point-in-time recovery will result in a new incarnation of the database. A new incarnation is a new logical version of the database. The data remains the same, of course, but the redo stream essentially starts over. The log sequence number is reset to 1 (the SCN is not reset) and a new life begins for the database.
To indicate to Oracle that you are doing an incomplete recovery, you will open the database in a slightly different way. You will still use the alter database open command, but you will also include the keyword resetlogs. The resetlogs command indicates to Oracle that it should reset the control file and the redo log sequence number and open the database as a brand-new incarnation. The entire command looks like this:
alter database open resetlogs;
Through Oracle Database 10g, Oracle recommended that you back up the database anytime you issue a resetlogs operation. This was because Oracle did not support recovering a database through a resetlogs operation. In Oracle Database 11g, Oracle has been modified to allow for a recovery through resetlogs. This is supported through the new %r format string available in the LOG_ARCHIVE_FORMAT parameter (see Chapter 2 for more on this parameter). This format string will include a resetlogs number in the naming of each archived redo log. This will help Oracle keep the redo-log stream straight.
If you should need to do a recovery after a resetlogs operation, simply restore the same backup that you used to do the point-in-time recovery and recover using that backup. You can do full recovery or point-in-time recovery using the redo associated with the new incarnation. In Exercise 3.3, you’ll perform a point-in-time recovery.
E x e r c i s e 3 . 3
Performing a Point-in-Time Recovery
In this exercise, you will do a point-in-time recovery by restoring the database to a previous SCN.
1.Back up the database. Details on how to do a full online database backup are found in Chapter 2. In summary, follow these steps:
NN |
First put the database in hot backup mode. |
|
|
NN |
Copy all database datafiles to a backup location. |
NN |
Take the database out of hot backup mode. |
NN |
Force a log switch. Back up the archived redo logs. |
|
Performing Incomplete Recoveries |
127 |
E x e r c i s e 3 . 3 ( c o n t i n u e d )
Here is an example of a backup:
[oracle@localhost orcl]$ sqlplus “/ as sysdba”
SQL*Plus: Release 11.1.0.6.0 - Production on Sun Aug 17 15:35:48 2008 Copyright (c) 1982, 2007, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> alter database begin backup;
Database altered.
SQL> host cp /oracle01/oradata/orcl/*.dbf /oracle01/backup/orcl SQL> alter database end backup;
Database altered.
SQL> alter system switch logfile; System altered.
SQL> host cp /oracle01/backup/arch/* /oracle01/backup/orcl/* SQL> alter database backup controlfile to trace;
Database altered.
SQL> alter database backup controlfile to ‘/oracle01/oradata/orcl/control1.bak’; Database altered.
2.Next, log into the database as scott/tiger and create a new table. Insert two records into the new table and commit the insert.
SQL> connect scott/tiger Connected.
SQL> create table test_table (id number); Table created.
SQL> insert into test_table values (1); 1 row created.
SQL> insert into test_table values (2); 1 row created.
SQL> commit; Commit complete.
3.Now log in as SYS and determine the current SCN by using the CURRENT_SCN column of the V$DATABASE table. Your SCN will be different from that in the example.
SQL> connect sys as sysdba Enter password:
128 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 )
Connected.
SQL> select current_scn from v$database; CURRENT_SCN
-----------
5135413
4.Log back in as scott/tiger and add two more records. Commit the inserts.
SQL> connect scott/tiger Connected.
SQL> insert into test_table values (3); 1 row created.
SQL> insert into test_table values (4); 1 row created.
SQL> commit; Commit complete.
5.Log in as SYS again and query the current SCN by using the CURRENT_SCN column of the V$DATABASE table. Notice that the SCN has changed.
SQL> connect sys as sysdba Enter password: Connected.
SQL> select current_scn from v$database; CURRENT_SCN
-----------
5135522
6.Shut down the database.
SQL> shutdown immediate Database closed. Database dismounted.
ORACLE instance shut down.
7.Once you are sure the database is down, restore the database datafiles from their backup location to the location where the database files belong.
[oracle@localhost orcl]$ pwd /oracle01/backup/orcl
[oracle@localhost orcl]$ cp *.dbf /oracle01/oradata/orcl/*
Performing Incomplete Recoveries |
129 |
E x e r c i s e 3 . 3 ( c o n t i n u e d )
8.Mount the database.
[oracle@localhost orcl]$ sqlplus “/ as sysdba”
SQL*Plus: Release 11.1.0.6.0 - Production on Sun Aug 17 17:53:14 2008 Copyright (c) 1982, 2007, Oracle. All rights reserved.
Connected to an idle instance. SQL> startup mount
ORACLE instance started. |
|
|
Total System Global Area |
167395328 |
bytes |
Fixed Size |
1298612 |
bytes |
Variable Size |
142610252 |
bytes |
Database Buffers |
20971520 |
bytes |
Redo Buffers |
2514944 |
bytes |
Database mounted. |
|
|
9.Recover the database using the recover database until change command. You will use the SCN you queried in step 3 as the SCN to recover to. Enter AUTO when prompted for an archived redo log to apply.
SQL> Recover database until change 5135413;
ORA-00279: change 5071334 generated at 08/17/2008 15:35:51 needed for thread 1 ORA-00289: suggestion : /oracle01/flash_recovery_area/ORCL/archivelog/2008_08_17 /o1_mf_1_5_4bk6onh8_.arc
ORA-00280: change 5071334 for thread 1 is in sequence #5 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} auto
ORA-00279: change 5071583 generated at 08/17/2008 15:40:04 needed for thread 1 ORA-00289: suggestion : /oracle01/flash_recovery_area/ORCL/archivelog/2008_08_17 /o1_mf_1_6_4bk76kwk_.arc
ORA-00280: change 5071583 for thread 1 is in sequence #6
ORA-00279: change 5091960 generated at 08/17/2008 15:49:05 needed for thread 1 ORA-00289: suggestion : /oracle01/flash_recovery_area/ORCL/archivelog/2008_08_17 /o1_mf_1_7_4bk9ksb4_.arc
ORA-00280: change 5091960 for thread 1 is in sequence #7
ORA-00279: change 5112317 generated at 08/17/2008 16:29:13 needed for thread 1 ORA-00289: suggestion : /oracle01/flash_recovery_area/ORCL/archivelog/2008_08_17 /o1_mf_1_8_4bk9p236_.arc