Oracle RMAN 11g Backup and Recovery (170 page)

'/u03/oradata/prod/control02.dbf' scope spfile;

alter system set db file name convert ('/u04' , '/u02' ,

'/u05' , '/u02' ,

Chapter 23: RMAN in the Workplace: Case Studies
539

'u06' , ' u03' ,

'u07' , 'u03') scope spfile;

alter system set log file name convert ('/u04' , '/u02' ,

'/u05' , '/u02' ,

'u06' , ' u03' ,

'u07' , 'u03') scope spfile;

alter system set log archive dest 1

'location /u02/oradata/prod/arch' scope spfile;

alter system set db cache size 300m scope spfile;

alter system set shared pool size 200m scope spfile;

shutdown immediate;

startup nomount;

NOTE

You could also choose to use the
set newname
option here.

4.
Restore a copy of the control file. Using the same RMAN session as the preceding, Thom can do this quite simply (he’s already set the DBID). Then, mount the database using the restored control file.

run {

allocate channel tape 1 type sbt

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

restore controlfile from autobackup; }

alter database mount;

5.
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 lost server as the media management client. This serves two purposes: it allows RMAN to access the backups that were taken from the lost server, and RMAN will pass this client name to the media management server when any backups are taken from the new server.

That way, when the lost server is rebuilt, any backups taken from this stopgap system will be accessible at the newly reconstructed production server.

configure default device type to sbt;

configure device type sbt parallelism 2;

configure auxiliary channel 1 device type sbt parms

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

configure auxiliary channel 2 device type sbt parms

"env (nb ora serv mgtserv, nb ora cient cervantes)";

6.
Determine the last archive log for which there is a copy. Because Thom lost the entire server, he also lost any archive logs that had not yet been backed up by RMAN. So, he must query RMAN to determine what the last archive log is for which a backup exists.

list backup of archivelog from time 'sysdate-7';

7.
With the last log sequence number in hand, Thom performs his restore and recovery and opens the database:

restore database;

recover database until sequence ;

alter database open resetlogs;

540
Part IV: RMAN in the Oracle Ecosystem

Case #4: Recovering from Complete Database Loss

(ARCHIVELOG Mode) with a Recovery Catalog

The Scenario

Charles is taking over for Thom, because management recognized that Thom was a hero of a DBA and thus sent him and his wife to Hawaii for two weeks of R and R. Before he left, Thom’s company added additional disk storage and decided that using the RMAN recovery catalog was probably a good idea.

Unfortunately for Charles, disaster seems to follow him around. At his last company, a huge electrical fire caused all sorts of mayhem, and this time, it’s gophers. Yes, gophers. Somewhere outside the computer room, a lone gopher ate through the power cable leading to the computer room. This resulted in an electrical fire and a halon release into the computer room. As a result of the electrical fire, the server and disks on which his database resides have been completely destroyed…again.

The Problem

Charles reviews Thom’s backup strategy. Again, Charles has salvaged a smaller server that survived the fiasco, which already has Oracle installed on the system, and now he needs to get the database back up and running immediately. Fortunately, the recovery catalog server is intact, so Charles can use it during the recovery.

The Solution

Again, Charles has lost the current control file and the online redo logs for his database, so it’s time to employ his point-in-time recovery skills. The backup strategy still has control file autobackups turned on, so Charles 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 Charles is restoring files to a new server, he

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. Charles uses sbttest to check to make sure that the media manager is accessible.

Next, Charles needs to configure his tape channels to specify the client name of the server that has been destroyed. Charles 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.

File System Layout Considerations

On Charles’s new system, the file system structure is

different from that on 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. Luckily, directory structure standards exist 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 Considerations

Charles’s emergency server has less physical memory than his lost

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

Chapter 23: RMAN in the Workplace: Case Studies
541

The Solution Revealed

Based on the preceding considerations, Charles devises and

implements the following recovery plan:

1.
Get a copy of the SPFILE restored. First, Charles will nomount the database instance without a parameter file, since Oracle supports this. Then, he will restore the correct SPFILE from backup. Because he doesn’t have a control file yet, he cannot configure channels permanently. Instead, he has to embed
channel allocation
commands in a
run
block, and then issue the
startup
command to start the database with the correct SPFILE.

Since he has a recovery catalog, he doesn’t need to set the machine ID as he did earlier.

rman target / catalog rcat user/rcat password@catalog

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;

2.
Make changes to the SPFILE. Charles 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',

'/u03/oradata/prod/control02.dbf' scope spfile;

alter system set db file name convert "('/u04' , '/u02' ,

'/u05' , '/u02' ,

'/u06' , '/u03' ,

'/u07' , '/u03')" scope spfile;

alter system set log file name convert "('/u04' , '/u02' ,

'/u05' , '/u02' ,

'/u06' , '/u03' ,

'/u07' , '/u03')" scope spfile;

alter system set log archive dest 1

'location /u02/oradata/prod/arch' scope spfile;

alter system set db cache size 300m scope spfile;

alter system set shared pool size 200m scope spfile;

shutdown immediate;

startup nomount;

3.
Restore a copy of the control file. Using the same RMAN session, Charles can do this quite simply (he’s already set the DBID). Then, he must mount the database using the restored control file.

run {

allocate channel tape 1 type sbt

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

restore controlfile from autobackup; }

sql 'alter database mount';

542
Part IV: RMAN in the Oracle Ecosystem

4.
Configure permanent channel parameters. Now that Charles has a control file restored, he can update the persistent parameters for channel allocation to include the name of the lost server as the media management client. This serves two purposes: it allows RMAN to access the backups that were taken from the lost server, and RMAN will pass this client name to the media management server when any backups are taken from the new server.

That way, when the lost server is rebuilt, any backups taken from this stopgap system will be accessible at the newly reconstructed production server.

configure default device type to sbt;

configure device type sbt parallelism 2;

configure auxiliary channel 1 device type sbt parms

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

configure auxiliary channel 2 device type sbt parms

"env (nb ora serv mgtserv, nb ora cient cervantes)";

5.
Determine the last archive log for which there is a copy. Because Charles lost the entire server, he also lost any archive logs that had not yet been backed up by RMAN. So, he must query RMAN to determine what the last archive log is for which a backup exists: list backup of archivelog from time 'sysdate-7';

6.
With the last log sequence number in hand, Charles performs his restore and recovery and opens the database:

restore database;

recover database until sequence ;

sql "alter database open resetlogs";

Case #5: Recovering from the Loss of the SYSTEM Tablespace

The Scenario

Nancy, an awesome DBA, is in charge of a large database installation. She shut down her database so the system administrators of her Unix system could do some file system maintenance.

The Problem

Unfortunately, during the maintenance operation, the system administrators at her company managed to drop a file system her database is sitting on. They have since restored the file system, but none of the files from her database are on it, so she must recover them. Nancy lost all datafiles from the following tablespaces: USERS, SYSTEM, and INDEX.

The Solution

Fortunately for Nancy, this is not a complete loss of her system. Her online redo logs and control file are all intact. Because she has to recover the SYSTEM tablespace, she has to do her recovery with the database closed, not open. Otherwise, the recovery is a pretty easy one.

The Solution Revealed

Based on the preceding considerations, the recovery plan that Nancy

devises and implements simply requires her to restore the database, as follows: rman target / catalog rcat user/rcat password@catalog

startup force mount;

restore tablespace users, system, index;

recover tablespace users, system, index;

alter database open;