Oracle RMAN 11g Backup and Recovery (169 page)

Chapter 23: RMAN in the Workplace: Case Studies
535

The Solution

Thom’s only recovery option in this case is to restore from the last offline backup. In this case, Thom’s recovery catalog database was not lost (it was on another server), and his file systems are in place, so all he needs to do is recover the database. First, Thom needs to recover the database SPFILE, followed by the control file. Then, he needs to recover the database datafiles to the file systems.

The Solution Revealed
Based on the preceding considerations, Thom devises and implements the following recovery plan:

1.
Restore a copy of the SPFILE. While you will be able to nomount the Oracle instance in many cases without a parameter file at all, to properly recover the database, Thom has to restore the correct SPFILE from backup. Because he doesn’t have a control file yet, he cannot configure channels permanently. In this case, Thom has configured his autobackups of the control files to go to default disk locations. Thus, once Thom restored his Oracle software backups, he also restored the backup pieces to the autobackups of the control file. This makes the recovery of the SPFILE simple as a result: rman target sys/password catalog rcat user/rcat password@catalogdb

startup force nomount;

restore spfile from autobackup;

shutdown immediate;

startup nomount;

NOTE

If you are not using the FRA, you will need to set the DBID of

the database before performing the restore of the SPFILE and the

control file.

2.
Restore a copy of the control file. Using the same RMAN session as in Step 1, Thom can do this quite simply. After the restore operation, he mounts the database using the restored control file:

restore controlfile from autobackup;

alter database mount;

3.
Configure permanent channel parameters. Now that Thom has a control file restored, he can update the persistent parameters for channel allocation to include the name of the tape device his backup sets are on. This will allow him to proceed to restore the backup from tape and recover the database.

configure default device type to sbt;

configure channel 1 device type sbt

parms "env (nb ora serv mgtserv, nb ora client cervantes)";

4.
Perform the restore and recovery:

restore database;

recover database noredo;

alter database open resetlogs;

536
Part IV: RMAN in the Oracle Ecosystem

NOTE

Thom used the
alter database open resetlogs
command. He could
have used the SQL command (
sql “alter database open resetlogs”
),
too. However, one benefit of using the RMAN
alter
command is
that the catalog and the database will both be reset. Using the SQL

version, only the database is reset.

Case #2: Recovering from Complete Database Loss

(NOARCHIVELOG Mode) Without a Recovery Catalog

The Scenario

Charles is the DBA of a development OLTP system. Because it is a development system, the decision was made to do RMAN offline backups and to leave the database in NOARCHIVELOG

mode. Charles did not decide to use a recovery catalog when doing his backups. Further, Charles has configured RMAN to back up the control file backups to disk by default, rather than to tape.

The Problem

Sevi, a developer, developed a piece of PL/SQL code designed to truncate specific tables in the database. However, due to a logic bug, the code managed to truncate all the tables in the schema, wiping out all test data.

The Solution

If there were a logical backup of the database, this would be the perfect time to use it. Unfortunately, there is no logical backup of the database, so Charles (the DBA) is left with performing an RMAN

recovery. Since his database is in NOARCHIVELOG mode, Charles has only one recovery option in this case, which is to restore from the last offline backup. Because all the pieces to do recovery are in place (the RMAN disk backups, the Oracle software, and the file systems), all that needs to be done is to fire up RMAN and recover the database.

The Solution Revealed
Based on the preceding considerations, Charles devises and implements the following recovery plan:

1.
Restore the control file. When doing a recovery from a cold backup, it is always a good idea to recover the control file associated with that backup (this prevents odd things from happening). In this case, Charles will be using the latest control file backup (since he doesn’t back up the control file at other times). Since Charles uses the default location to create control file backup sets to, he doesn’t need to allocate any channels. If Charles is not using the Oracle flash recovery area and not using a recovery catalog, he will need to set the DBID of the system, since he is not using a recovery catalog before he can restore the control file. If Charles is using a recovery catalog or the FRA, then setting the DBID

would not be required. Once Charles restores the control file, he mounts the database: rman target sys/password

startup nomount

set dbid 2540040039;

restore controlfile from autobackup;

sql 'alter database mount';

Chapter 23: RMAN in the Workplace: Case Studies
537

NOTE

If you are using the FRA, you will not need to set the database DBID.

2.
The control file that Charles restored has the correct default persistent parameters already configured in it, so all he needs to do is perform the restore and recovery: restore database;

recover database noredo;

sql "alter database open resetlogs";

Case #3: Recovering from Complete Database Loss

(ARCHIVELOG Mode) Without a Recovery Catalog

The Scenario

We meet Thom from Case #1 again. Thom’s company finally has decided that putting the database in ARCHIVELOG mode seems like a good idea. (Thom’s boss thought it was his idea!) Unfortunately for Thom, due to budget restrictions, he was forced to use the space that was allocated to the recovery catalog to store archived redo logs. Thus, Thom no longer has a recovery catalog at his disposal.

The Problem

As if things have not been hard enough on Thom, we also find that Unfortunate Company is also an unfortunately located company. His server room, located in the basement as so many server rooms are, suffered the fate of a broken water main nearby. The entire room was flooded, and the server on which his database resides has been completely destroyed.

Thom’s backup strategy has improved. It now includes tape backups to an offsite media management server. Also, he’s sending his automated control file/SPFILE backups to tape rather than to disk. Again, he’s salvaged a smaller server from the wreckage, which already has Oracle installed on the system, and now he needs to get the database back up and running immediately.

The Solution

Again, Thom has lost the current control file and the online redo logs for his database, so it’s time to employ the point-in-time recovery skills. Thom still has control file autobackups turned on, so he can use them to get recovery started. In addition, he’s restoring to a new server, so he wants to be aware of the challenges that restoring to a new server brings; there are media management, file system layout, and memory utilization considerations.

Media Management Considerations
Because he’s restoring files to a new server, Thom must first make sure that the MML file has been properly set up for use on his emergency server. This means having the media management client software and Oracle Plug-In installed prior to using RMAN for restore/recovery. Thom uses the sbttest utility—a good way to check to make sure that the media manager is accessible.

Next, Thom needs to configure his tape channels to specify the client name of the server that has been destroyed. Thom will need to specify the name of the client from which the backups were taken. In addition, he needs to ensure that the media management server has been configured to allow for backups to be restored from a different client to his emergency server.

538
Part IV: RMAN in the Oracle Ecosystem

File System Layout Considerations

Thom’s new system has a different file system structure

from his original server. The production database had files manually striped over six mount points: /u02, /u03, /u04, /u05, /u06, and /u07. His new server has only two mount points: /u02

and /u03. Fortunately, Thom employed directory structure standards across his enterprise, and all data directories are /oradata/prod/ on all mount points. In addition, he has a standard that always puts the ORACLE_HOME on the same mount point and directory structure on every server.

Memory Utilization Considerations

Thom’s emergency server has less physical memory than

his lost production server. This means he will have to significantly scale back the memory utilization for the time being in order to at least get the database up and operational.

The Solution Revealed
Based on the preceding considerations, Thom devises and implements the following recovery plan:

1.
Determine the DBID of the target database. Thom can do this by looking at the file handle for his control file autobackup. He needs to be able to view the media management catalog to do so. Even easier, Thom has every DBID for all his databases stored somewhere in a log—a notebook, a PDA, whatever. Whatever you decide to use, just make sure it’s accessible in an emergency.

2.
Restore a copy of the SPFILE. As you may remember, Thom will have to force an instance to be opened using a dummy SPFILE, and then restore the correct SPFILE from backup.

Because Thom changed the default location for his control file/SPFILE autobackups to tape, he needs to manually configure the channel for this backup, because he doesn’t have a control file yet; thus, he cannot configure channels permanently. Instead, he has to imbed
channel allocation
commands in a
run
block, and then issue the
startup
command to start the database with the correct SPFILE.

rman target /

set dbid 204062491;

startup force nomount;

run {

allocate channel tape 1 type sbt

parms 'env (nb ora serv rmsrv, nb ora client cervantes)';

restore spfile from autobackup;}

shutdown immediate;

startup nomount;

NOTE

If you are using the FRA, then you will not need to set the

database DBID.

3.
Make changes to the SPFILE. Thom must modify his SPFILE to take into account the new server configuration. This means changing memory utilization parameters and setting filename conversion parameters. He must connect to the newly started instance from SQL*Plus and make the necessary changes.

alter system set control files '/u02/oradata/prod/control01.dbf',