mgdRcvryMdeDetails.html
09-09-2001 Bikle
-----------------
This file describes a few steps and displays some screen dumps related
to placing a standby database in Managed Recovery Mode.
The main steps are listed below:
-Shutdown the standby database
-Generate some archived redolog files on the primary
-Copy archived redolog files over to standby database
-STARTUP
-MOUNT
-Manual recovery
-Managed recovery mode
-Generate some archived redolog files on the primary
-Watch for them on the standby
I relist the steps below along with screen dumps and comments:
-Shutdown the standby database
$ BBIKLE.csh
sf49er.bikle.com 1 % sqi
SQL*Plus: Release 8.1.7.0.0 - Production on Sun Sep 9 22:52:04 2001
(c) Copyright 2000 Oracle Corporation. All rights reserved.
Connected to:
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
22:52:04 SQL> shutdown abort
ORACLE instance shut down.
22:52:20 SQL> exit
Disconnected from Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
-Generate some archived redolog files on the primary
$ ABIKLE.csh
sf49er.bikle.com 1 % sqi
SQL*Plus: Release 8.1.7.0.0 - Production on Sun Sep 9 22:52:57 2001
(c) Copyright 2000 Oracle Corporation. All rights reserved.
Connected to:
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
22:52:57 SQL> alter system switch logfile;
System altered.
22:53:06 SQL> /
System altered.
22:53:11 SQL> SELECT MAX(SEQUENCE#) FROM V$LOG_HISTORY;
MAX(SEQUENCE#)
--------------
141
22:53:43 SQL> exit
Disconnected from Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
-Copy archived redolog files over to standby database
sf49er.bikle.com 4 % cd /u2/oracle/data/ABIKLE/arch/
/u2/oracle/data/ABIKLE/arch
sf49er.bikle.com 5 % ls
./ arch_1_132.arc arch_1_135.arc arch_1_138.arc
../ arch_1_133.arc arch_1_136.arc arch_1_139.arc
arch_1_131.arc arch_1_134.arc arch_1_137.arc arch_1_140.arc
sf49er.bikle.com 6 % cp -p arch_1_140.arc arch_1_139.arc arch_1_138.arc /u2/oracle/data/BBIKLE/arch/
sf49er.bikle.com 7 % cp -p arch_1_140.arc arch_1_139.arc arch_1_138.arc /u2/oracle/data/BBIKLE/archstandby
sf49er.bikle.com 8 % exit
-STARTUP
sf49er.bikle.com 9 % $ BBIKLE.csh
sf49er.bikle.com 1 % sqi
SQL*Plus: Release 8.1.7.0.0 - Production on Sun Sep 9 22:57:18 2001
(c) Copyright 2000 Oracle Corporation. All rights reserved.
Connected to an idle instance.
22:57:18 SQL> STARTUP NOMOUNT
ORACLE instance started.
Total System Global Area 186908832 bytes
Fixed Size 73888 bytes
Variable Size 75399168 bytes
Database Buffers 100933632 bytes
Redo Buffers 10502144 bytes
-MOUNT
22:57:27 SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
Database altered.
-Manual recovery
22:57:59 SQL> 22:57:59 SQL> RECOVER AUTOMATIC STANDBY DATABASE
ORA-00279: change 118437 generated at 09/09/2001 22:53:06 needed for thread 1
ORA-00289: suggestion : /u2/oracle/data/BBIKLE/arch/arch_1_141.arc
ORA-00280: change 118437 for thread 1 is in sequence #141
ORA-00278: log file '/u2/oracle/data/BBIKLE/arch/arch_1_141.arc' no longer needed for this recovery
ORA-00308: cannot open archived log '/u2/oracle/data/BBIKLE/arch/arch_1_141.arc'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
22:58:07 Specify log: {=suggested | filename | AUTO | CANCEL}
CANCEL
Media recovery cancelled.
22:58:15 SQL> exit
Disconnected
-Managed recovery mode
According to the Oracle documentation, we initiate this step with the
sql command listed below:
RECOVER MANAGED STANDBY DATABASE
sf49er.bikle.com 2 % cat $ORACLE_HOME/dbs/rec.sh
#! /bin/ksh
sqlplus internal > rec.sh.out <&rec.out&
[1] 7204
sf49er.bikle.com 5 %
sf49er.bikle.com 5 % exit
Notice that in the above screen dump, we "wrapped" the RECOVER command
within a shell script. Once the command was wrapped in a shell
script, this allowed us to then place the script in the background in
nohup mode. What happens if we do not wrap the RECOVER command?
When I issue the RECOVER command, control is not returned to the sql
prompt. This behavior raises an obvious question, "What happens if I
issue the above command and then shutdown the terminal session which
issued the above command?"
We ran an experiment to get an answer to the above question. Details
of the experiment and the results are linked below:
experiment.txt
When we ran the above experiment, we found that the standby database
will stay in Managed Recovery mode. Archived redolog files will
continue to propagate to the standby database and they will be applied
by the Oracle instance at the standby database.
-Generate some archived redolog files on the primary
sf49er.bikle.com 6 % $ ABIKLE.csh
sf49er.bikle.com 1 % cd /u2/oracle/data/ABIKLE/arch/
/u2/oracle/data/ABIKLE/arch
sf49er.bikle.com 2 % ls
./ arch_1_133.arc arch_1_137.arc arch_1_141.arc
../ arch_1_134.arc arch_1_138.arc
arch_1_131.arc arch_1_135.arc arch_1_139.arc
arch_1_132.arc arch_1_136.arc arch_1_140.arc
sf49er.bikle.com 3 % sqi
SQL*Plus: Release 8.1.7.0.0 - Production on Sun Sep 9 23:04:19 2001
(c) Copyright 2000 Oracle Corporation. All rights reserved.
Connected to:
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
23:04:19 SQL> alter system switch logfile;
System altered.
23:04:32 SQL> /
System altered.
23:04:33 SQL> exit
Disconnected from Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
sf49er.bikle.com 4 % ls
./ arch_1_133.arc arch_1_137.arc arch_1_141.arc
../ arch_1_134.arc arch_1_138.arc arch_1_142.arc
arch_1_131.arc arch_1_135.arc arch_1_139.arc arch_1_143.arc
arch_1_132.arc arch_1_136.arc arch_1_140.arc
sf49er.bikle.com 5 % sqi
SQL*Plus: Release 8.1.7.0.0 - Production on Sun Sep 9 23:04:57 2001
(c) Copyright 2000 Oracle Corporation. All rights reserved.
Connected to:
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
23:04:57 SQL> SELECT MAX(SEQUENCE#) FROM V$LOG_HISTORY;
MAX(SEQUENCE#)
--------------
143
23:05:16 SQL> exit
Disconnected from Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
sf49er.bikle.com 6 % exit
-Watch for them on the standby
sf49er.bikle.com 7 % $ BBIKLE.csh
sf49er.bikle.com 1 % cd /u2/oracle/data/BBIKLE/archstandby
/u2/oracle/data/BBIKLE/archstandby
sf49er.bikle.com 3 %
sf49er.bikle.com 3 % ls
./ arch_1_133.arc arch_1_137.arc arch_1_141.arc
../ arch_1_134.arc arch_1_138.arc arch_1_142.arc
arch_1_131.arc arch_1_135.arc arch_1_139.arc arch_1_143.arc
arch_1_132.arc arch_1_136.arc arch_1_140.arc
sf49er.bikle.com 4 % sqi
SQL*Plus: Release 8.1.7.0.0 - Production on Sun Sep 9 23:06:52 2001
(c) Copyright 2000 Oracle Corporation. All rights reserved.
Connected to:
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
23:06:52 SQL>
23:07:17 SQL> SELECT MAX(SEQUENCE#) FROM V$LOG_HISTORY;
MAX(SEQUENCE#)
--------------
143
23:07:20 SQL>
23:07:41 SQL> 23:07:41 SQL> exit
Disconnected from Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
sf49er.bikle.com 5 %
It's obvious from this last query of V$LOG_HISTORY that the two
databases are communicating with each other and that archived redolog
files are moving from the primary database to the standby database
where they are then applied.