Oracle 23c New Features for DBA'sWell, this is fairly an old topic but explored lately by me. Very big post click on read more to scroll down to full page.
Ah, I was trying to explore the upgrade from 11gr2 to 12c but not traditional way, and go these two excellent white papers.
The high level overview of this feature is something like below,
- Environment consists of Primary & Physical standby
- Guaranteed restore point created
- Physical standby will be converted into a logical standby temporarily to allow the upgrade
- Startup the logical standby in 12c home (assuming you have the 12c software only installation done)
- Upgrade the logical standby
- Switch over the primary to physical standby and logical standby to primary
- Flashback the primary database to guaranteed restore point taken
- Apply the redo's generated in logical standby in primary (no upgrade required here)
To allow you the failed upgrade,
- You should create flashback guaranteed restore point
- Do not change the compatible parameter until all the databases (primary/standby) are upgraded
Let's have a look of my environment
- Primary:- 11.2.0.2 – Prod1 (on same host Geek DBA11g)
- Standby:- 11.2.0.2 – Prod1DR (Physical Standby) (on same host Geek DBA11g)
- 12c software installed on both sides - /u01/app/oracle/product/12.1.0/db_1
- Flash back enabled on both sides
In order to perform all the activities (6 steps) you will have to do lot of manual work, instead Oracle provide you the script to physru.
Oracle11g Data Guard: Database Rolling Upgrade Shell Script(Doc ID 949322.1)
Now executed the script, (no prereqs, no changes, nothing just that both DB's are up and running)
Step 1
Explanation:- This script takes 6 inputs, username, Primary, Standby, PrimaryTns, StandbyTns, Targetversion
In below, if you see,
Stage1 :- Script stops the media recovery, create restore point on both standby and primary and also backs up the control file
Stage2:- Script create the dictionary build and converts the logical standby to physical standby and awaits until the dictionary load happen and finally open the Prod1DR in open mode (logical standby)
[oracle@Geek DBA11g ~]$ ./physru.sh sys Prod1 Prod1DR Prod1 Prod1DR 12.1.0.1.0
Please enter the sysdba password:### Initialize script to either start over or resume execution
Oct 02 03:41:53 2014 [0-1] Identifying rdbms software version
Oct 02 03:41:54 2014 [0-1] database Prod1 is at version 11.2.0.2.0
Oct 02 03:41:54 2014 [0-1] database Prod1DR is at version 11.2.0.2.0
Oct 02 03:41:54 2014 [0-1] verifying flashback database is enabled at Prod1 and Prod1DR
Oct 02 03:41:54 2014 [0-1] ERROR: flashback database disabled at Prod1
Oct 02 03:41:54 2014 [0-1] ERROR: flashback database disabled at Prod1DR
Oct 02 03:41:54 2014 [0-1] verifying available flashback restore points
Oct 02 03:41:54 2014 [0-1] verifying DG Broker is disabled
Oct 02 03:41:54 2014 [0-1] exiting: errors must be addressed in order to proceedErrors:- The Primary and standby does not have flashback enabled, enabled and reran it again
[oracle@Geek DBA11g ~]$ ./physru.sh sys Prod1 Prod1DR Prod1 Prod1DR 12.1.0.1.0
### Initialize script to either start over or resume execution
Oct 02 03:44:03 2014 [0-1] Identifying rdbms software version
Oct 02 03:44:03 2014 [0-1] database Prod1 is at version 11.2.0.2.0
Oct 02 03:44:03 2014 [0-1] database Prod1DR is at version 11.2.0.2.0
Oct 02 03:44:03 2014 [0-1] verifying flashback database is enabled at Prod1 and Prod1DR
Oct 02 03:44:03 2014 [0-1] verifying available flashback restore points
Oct 02 03:44:04 2014 [0-1] verifying DG Broker is disabled
Oct 02 03:44:04 2014 [0-1] looking up prior execution history
Oct 02 03:44:04 2014 [0-1] purging script execution state from database Prod1
Oct 02 03:44:04 2014 [0-1] purging script execution state from database Prod1DR
Oct 02 03:44:04 2014 [0-1] starting new execution of script### Stage 1: Backup user environment in case rolling upgrade is aborted
Oct 02 03:44:04 2014 [1-1] stopping media recovery on Prod1DR
Oct 02 03:44:04 2014 [1-1] creating restore point PRU_0000_0001 on database Prod1DR
Oct 02 03:44:04 2014 [1-1] backing up current control file on Prod1DR
Oct 02 03:44:05 2014 [1-1] created backup control file /u01/app/oracle/product/11.2.0/db_1/dbs/PRU_0001_Prod1DR_f.f
Oct 02 03:44:05 2014 [1-1] creating restore point PRU_0000_0001 on database Prod1
Oct 02 03:44:05 2014 [1-1] backing up current control file on Prod1
Oct 02 03:44:06 2014 [1-1] created backup control file /u01/app/oracle/product/11.2.0/db_1/dbs/PRU_0001_Prod1_f.fNOTE: Restore point PRU_0000_0001 and backup control file PRU_0001_Prod1DR_f.f
can be used to restore Prod1DR back to its original state as a
physical standby, in case the rolling upgrade operation needs to be aborted
prior to the first switchover done in Stage 4.### Stage 2: Create transient logical standby from existing physical standby
Oct 02 03:44:06 2014 [2-1] verifying RAC is disabled at Prod1DR
Oct 02 03:44:06 2014 [2-1] verifying database roles
Oct 02 03:44:06 2014 [2-1] verifying physical standby is mounted
Oct 02 03:44:07 2014 [2-1] verifying database protection mode
Oct 02 03:44:07 2014 [2-1] verifying transient logical standby datatype supportWARN: Objects have been identified on the primary database which will not be
replicated on the transient logical standby. The complete list of
objects and their associated unsupported datatypes can be found in the
dba_logstdby_unsupported view. For convenience, this script has written
the contents of this view to a file - physru_unsupported.log.Various options exist to deal with these objects such as:
- disabling applications that modify these objects
- manually resolving these objects after the upgrade
- extending support to these objects (see metalink note: 559353.1)If you need time to review these options, you should enter 'n' to exit
the script. Otherwise, you should enter 'y' to continue with the
rolling upgrade.Are you ready to proceed with the rolling upgrade? (y/n):
Oct 02 03:44:28 2014 [2-1] continuing
Oct 02 03:44:28 2014 [2-2] starting media recovery on Prod1DR
Oct 02 03:44:33 2014 [2-2] confirming media recovery is running
Oct 02 03:44:33 2014 [2-2] waiting for apply lag to fall under 30 seconds
Oct 02 03:44:41 2014 [2-2] apply lag measured at 8 seconds
Oct 02 03:44:41 2014 [2-2] stopping media recovery on Prod1DR
Oct 02 03:44:42 2014 [2-2] executing dbms_logstdby.build on database Prod1
Oct 02 03:44:54 2014 [2-2] converting physical standby into transient logical standby
Oct 02 03:45:02 2014 [2-3] opening database Prod1DR
Oct 02 03:45:13 2014 [2-4] configuring transient logical standby parameters for rolling upgrade
Oct 02 03:45:14 2014 [2-4] starting logical standby on database Prod1DR
Oct 02 03:45:22 2014 [2-4] waiting until logminer dictionary has fully loaded
Oct 02 03:45:53 2014 [2-4] dictionary load 12% complete
Oct 02 03:46:03 2014 [2-4] dictionary load 45% complete
Oct 02 03:46:13 2014 [2-4] dictionary load 62% complete
Oct 02 03:46:23 2014 [2-4] dictionary load 71% complete
Oct 02 03:46:33 2014 [2-4] dictionary load 75% complete
Oct 02 03:46:45 2014 [2-4] dictionary load is complete
Oct 02 03:46:48 2014 [2-4] waiting for apply lag to fall under 30 seconds
Oct 02 03:46:52 2014 [2-4] apply lag measured at 4 secondsNOTE: Database Prod1DR is now ready to be upgraded. This script has left the
database open in case you want to perform any further tasks before
upgrading the database. Once the upgrade is complete, the database must
opened in READ WRITE mode before this script can be called to resume the
rolling upgrade.NOTE: If Prod1DR was previously a RAC database that was disabled, it may be
reverted back to a RAC database upon completion of the rdbms upgrade.
This can be accomplished by performing the following steps:1) On instance Prod1DR, set the cluster_database parameter to TRUE.
eg: SQL> alter system set cluster_database=true scope=spfile;2) Shutdown instance Prod1DR.
eg: SQL> shutdown abort;3) Startup and open all instances for database Prod1DR.
eg: srvctl start database -d Prod1DR
Step 2
In this phase, you will have to upgrade your logical standby (Prod1DR) to 12c (remember its in read/write mode hence you can run upgrade script)
[oracle@Geek DBA11g ~]$ export ORACLE_HOME=/u01/app/oracle/product/12.1.0/db_1
[oracle@Geek DBA11g ~]$ export PATH=/u01/app/oracle/product/12.1.0/db_1/bin:$PATH
[oracle@Geek DBA11g ~]$ export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib
[oracle@Geek DBA11g ~]$ export ORACLE_SID=Prod1DR
[oracle@Geek DBA11g ~]$ cp /u01/app/oracle/product/11.2.0/db_1/dbs/* /u01/app/oracle/product/12.1.0/db_1/
SQL> startup upgrade
ORACLE instance started.Total System Global Area 521936896 bytes
Fixed Size 2290264 bytes
Variable Size 209718696 bytes
Database Buffers 306184192 bytes
Redo Buffers 3743744 bytes
Database mounted.
Database opened.SQL> select protection_level,protection_mode from v$database; PROTECTION_LEVEL PROTECTION_MODE -------------------- -------------------- RESYNCHRONIZATION MAXIMUM AVAILABILITYSQL> select name,dbid,database_role from v$database; NAME DBID DATABASE_ROLE --------- ---------- ---------------- PROD 1990932220 LOGICAL STANDBY
Whist the Logical standby is upgraded, the status of Primary shows in alert as follows,
Whilst upgrading the Production to Standby synchronisation is halted,
Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
Thread 1 advanced to log sequence 19 (LGWR switch)Current log# 1 seq# 19 mem# 0: /u01/oradata/Prod1/Prod1/redo01.log
Thu Oct 02 08:42:09 2014
Archived Log entry 31 added for thread 1 sequence 18 ID 0x7c0c8265 dest 1:
Thu Oct 02 08:42:10 2014
Destination LOG_ARCHIVE_DEST_2 no longer supports SYNCHRONIZATION
Thread 1 advanced to log sequence 20 (LGWR switch)Current log# 2 seq# 20 mem# 0: /u01/oradata/Prod1/Prod1/redo02.log
Thu Oct 02 08:42:25 2014
Archived Log entry 32 added for thread 1 sequence 19 ID 0x7c0c8265 dest 1:
Do the upgrade, run the script as below
In 12c , the database can be upgraded using catctl.pl
cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catctl.pl -n 4 catupgrd.sql
.....
....
Time: 81s
Restart Phase #:24 Files: 1 Time: 0sSerial Phase #:25 Files: 1 Time: 108s
Restart Phase #:26 Files: 1 Time: 0s
Parallel Phase #:27 Files: 0 Time: 0s
Serial Phase #:28 Files: 1 Time: 0s
Parallel Phase #:29 Files: 130 Time: 13s
Serial Phase #:30 Files: 1 Time: 0s
Restart Phase #:31 Files: 1 Time: 0s
Serial Phase #:32 Files: 1 Time: 0s
Parallel Phase #:33 Files: 122 Time: 19s
Serial Phase #:34 Files: 1 Time: 0s
Restart Phase #:35 Files: 1 Time: 0s
Serial Phase #:36 Files: 4 Time: 68s
Restart Phase #:37 Files: 1 Time: 0s
Parallel Phase #:38 Files: 13 Time: 86s
Restart Phase #:39 Files: 1 Time: 0s
Parallel Phase #:40 Files: 10 Time: 19s
Restart Phase #:41 Files: 1 Time: 0s
Serial Phase #:42 Files: 1 Time: 12s
Restart Phase #:43 Files: 1 Time: 0s
Serial Phase #:44 Files: 1 Time: 8s
Serial Phase #:45 Files: 1 Time: 1s
Restart Phase #:46 Files: 1 Time: 0s
Serial Phase #:47 Files: 2
Time: 522s
At this moment, the Standby is upgraded and opened as logical standby, the next steps involve to switchovers.
Step 3
In this phase, script will perform an switchover of Logical standby to Primary and Primary to Physical Standby, note the (primary in phyiscal standby)
At first point the db home to 12c Home
At this moment, the listener entry and /etc/oratab should be changed for Prod1DR to New home
(SID_DESC =
(GLOBAL_DBNAME = Prod1DR)(ORACLE_HOME = /u01/app/oracle/product/12.1.0/db_1)
(SID_NAME = Prod1DR)
)
[oracle@Geek DBA11g ~]$ lsnrctl reload
cp initProd1.ora /u01/app/oracle/product/12.1.0/db_1/dbs
cp orapwProd1.ora /u01/app/oracle/product/12.1.0/db_1/dbs
cp tnsnames.ora /u01/app/oracle/product/12.1.0/db_1/dbs
cp listener.ora /u01/app/oracle/product/12.1.0/db_1/dbs
Run the script,
Little Explanation again,
Stage 3, A verification whether the Prod1DR is running on 12.1.0.1
Stage 4, Logical standby will be switched to Primary, while doing that it will wait to process all redo that it has pending and perform switchover, finally Prod1DR will be primary
Stage 5, Primary database will be switched as standby, once it is, it will be flashbacked to the restore point in the Step 1 (taken automatically by scripts) and from there it will start synchornize the redo from the standby (current Primary)
[oracle@Geek DBA11g ~]$ ./physru.sh sys Prod1 Prod1DR Prod1 Prod1DR 12.1.0.1.0
Please enter the sysdba password:### Initialize script to either start over or resume execution
Oct 02 09:33:51 2014 [0-1] Identifying rdbms software versionOct 02 09:33:51 2014 [0-1] database Prod1 is at version 11.2.0.2.0
Oct 02 09:33:51 2014 [0-1] database Prod1DR is at version 12.1.0.1.0
Oct 02 09:33:53 2014 [0-1] verifying flashback database is enabled at Prod1 and Prod1DR
Oct 02 09:33:53 2014 [0-1] verifying available flashback restore points
Oct 02 09:33:54 2014 [0-1] verifying DG Broker is disabled
Oct 02 09:33:54 2014 [0-1] looking up prior execution history
Oct 02 09:33:55 2014 [0-1] last completed stage [2-4] using script version 0001
Oct 02 09:33:55 2014 [0-1] resuming execution of script
### Stage 3: Validate upgraded transient logical standby
Oct 02 09:33:55 2014 [3-1] database Prod1DR is no longer in OPEN MIGRATE modeOct 02 09:33:55 2014 [3-1] database Prod1DR is at version 12.1.0.1.0
### Stage 4: Switch the transient logical standby to be the new primary
Oct 02 09:33:57 2014 [4-1] waiting for Prod1DR to catch up (this could take a while)Oct 02 09:33:58 2014 [4-1] starting logical standby on database Prod1DR
Oct 02 09:34:10 2014 [4-1] waiting for apply lag to fall under 30 seconds
Oct 02 09:34:38 2014 [4-1] apply lag measured at 28 seconds
Oct 02 09:34:41 2014 [4-2] switching Prod1 to become a logical standby
Oct 02 09:34:53 2014 [4-2] Prod1 is now a logical standby
Oct 02 09:34:54 2014 [4-3] waiting for standby Prod1DR to process end-of-redo from primaryOct 02 09:35:08 2014 [4-4] switching Prod1DR to become the new primary
Oct 02 09:35:39 2014 [4-4] Prod1DR is now the new primary
### Stage 5: Flashback former primary to pre-upgrade restore point and convert to physical
Oct 02 09:35:45 2014 [5-1] shutting down database Prod1Oct 02 09:36:41 2014 [5-1] mounting database Prod1
Oct 02 09:36:55 2014 [5-2] flashing back database Prod1 to restore point PRU_0000_0001
Oct 02 09:37:07 2014 [5-3] converting Prod1 into physical standbyOct 02 09:37:08 2014 [5-4] shutting down database Prod1
NOTE: Database Prod1 has been shutdown, and is now ready to be started
using the newer version Oracle binary. This script requires thedatabase to be mounted (on all active instances, if RAC) before calling
this script to resume the rolling upgrade.
You can see the alert of standby whilst its switching,
Alert log (Standby - Prod1DR)
Created guaranteed restore point PRU_0403
Thu Oct 02 09:35:08 2014alter database commit to switchover to primary
Thu Oct 02 09:35:08 2014
ALTER DATABASE SWITCHOVER TO PRIMARY (Prod1DR)
Thu Oct 02 09:35:08 2014
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY (Prod1DR)
LOGSTDBY: Successful close of the current log stream:
LOGSTDBY: primary: [2081205093]
LOGSTDBY: first scn: [0x0000.00000000]
LOGSTDBY: end scn: [0x0000.000feff5]
LOGSTDBY: processed scn: [0x0000.000feff6]
LOGSTDBY: Preparing to Create Detached Dictionary Build, pre-lockdown scn is [0x0000.00290ea4]
Thu Oct 02 09:35:09 2014
Logminer Bld: Build started
Alert Log (Primary - Prod1)
Completed: ALTER DATABASE MOUNTThu Oct 02 09:36:55 2014
flashback database to restore point PRU_0000_0001
Flashback Restore StartThu Oct 02 09:37:06 2014
Flashback Restore Complete
Flashback Media Recovery Start
Serial Media Recovery started
Flashback Media Recovery Log /u01/app/oracle/fast_recovery_area/PROD1/archivelog/2014_10_02/o1_mf_1_9_b2rz69p9_.arc
Incomplete Recovery applied until change 1020211 time 10/02/2014 03:44:05
Flashback Media Recovery Complete
Completed: flashback database to restore point PRU_0000_0001
Thu Oct 02 09:37:07 2014
alter database convert to physical standby
ALTER DATABASE CONVERT TO PHYSICAL STANDBY (Prod1)
LOGSTDBY: Cleared controlfile of logical standby state.
Clearing standby activation ID 2081194597 (0x7c0c8265)
The primary database controlfile was created using the
'MAXLOGFILES 16' clause.
There is space for up to 13 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;
Completed: alter database convert to physical standby
At this point, the primary will be Prod1DR (logical standby) and the Standby will be Prod1 (Primary) (in physical)
Step 3
In this phase, third time the script will need to be executed after starup mount the Prod1 with new home (i.e 12.1.0)
At first point change the listener.ora for Prod1 to point to New home
At this moment, the listener entry and /etc/oratab should be changed for Prod1DR to New home
(SID_DESC =
(GLOBAL_DBNAME = Prod1)(ORACLE_HOME = /u01/app/oracle/product/12.1.0/db_1)
(SID_NAME = Prod1)
)
[oracle@Geek DBA11g ~]$ lsnrctl reload
copy the password file and parameter files to new home
cp initProd1.ora /u01/app/oracle/product/12.1.0/db_1/dbs
cp orapwProd1.ora /u01/app/oracle/product/12.1.0/db_1/dbs
Mount the Prod1 as standby database
SQL> startup mount force;
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instanceORACLE instance started.
Total System Global Area 521936896 bytes
Fixed Size 2290264 bytesVariable Size 209718696 bytes
Database Buffers 306184192 bytes
Redo Buffers 3743744 bytes
Database mounted.
SQL> select name,dbid,database_role from v$database;
NAME DBID DATABASE_ROLE
--------- ---------- ----------------PROD1 2081205093 PHYSICAL STANDBY
SQL>
Run the script again
Explanation:-
In stage 6,
SCN 1037798 is the point where the upgrade redo has been started and SCN 2689073 is where upgrade recovery ended, so we have to cope all this SCN to make the standby sync with upgrade.
where in my Standby (the Prod1) lagged behind SCN 1020318 from Upgrade SCN 1037798, so it has to catch up first and the start the upgrade redo applying,
This line tells, synching with the SCN that has before upgrade.
Oct 02 09:46:24 2014 [6-2] last applied scn 1021068 is approaching upgrade redo start scn 1037798
This lines tells, doing the recovery of redo that whilst generated during upgrade in logical standby
Oct 02 09:56:10 2014 [6-3] recovery of upgrade redo at 01% - estimated complete at Oct 02 20:24:43
[oracle@Geek DBA11g ~]$ ./physru.sh sys Prod1 Prod1DR Prod1 Prod1DR 12.1.0.1.0
Please enter the sysdba password:### Initialize script to either start over or resume execution
Oct 02 09:43:33 2014 [0-1] Identifying rdbms software versionOct 02 09:43:33 2014 [0-1] database Prod1 is at version 12.1.0.1.0
Oct 02 09:43:34 2014 [0-1] database Prod1DR is at version 12.1.0.1.0
Oct 02 09:43:35 2014 [0-1] verifying flashback database is enabled at Prod1 and Prod1DR
Oct 02 09:43:36 2014 [0-1] verifying available flashback restore points
Oct 02 09:43:36 2014 [0-1] verifying DG Broker is disabled
Oct 02 09:43:36 2014 [0-1] looking up prior execution history
Oct 02 09:43:37 2014 [0-1] last completed stage [5-4] using script version 0001
Oct 02 09:43:37 2014 [0-1] resuming execution of script
### Stage 6: Run media recovery through upgrade redo
Oct 02 09:43:39 2014 [6-1] upgrade redo region identified as scn range [1037798, 2689073]
Oct 02 09:43:39 2014 [6-1] starting media recovery on Prod1Oct 02 09:43:58 2014 [6-1] confirming media recovery is running
Oct 02 09:43:58 2014 [6-1] waiting for media recovery to initialize v$recovery_progress
Oct 02 09:45:06 2014 [6-1] monitoring media recovery's progress
Oct 02 09:45:35 2014 [6-2] last applied scn 1020318 is approaching upgrade redo start scn 1037798
Oct 02 09:45:50 2014 [6-2] failed to determine the last applied scn by media recoveryOct 02 09:45:50 2014 [6-2] confirming media recovery is running
Oct 02 09:46:05 2014 [6-2] failed to determine the last applied scn by media recovery
Oct 02 09:46:05 2014 [6-2] confirming media recovery is running
Oct 02 09:46:24 2014 [6-2] last applied scn 1021068 is approaching upgrade redo start scn 1037798
Oct 02 09:46:39 2014 [6-2] last applied scn 1023037 is approaching upgrade redo start scn 1037798
Oct 02 09:46:54 2014 [6-2] last applied scn 1023341 is approaching upgrade redo start scn 1037798
......
Oct 02 09:54:34 2014 [6-2] last applied scn 1037659 is approaching upgrade redo start scn 1037798
...
Oct 02 09:56:10 2014 [6-3] recovery of upgrade redo at 01% - estimated complete at Oct 02 20:24:43
...
Oct 02 10:22:52 2014 [6-3] recovery of upgrade redo at 48% - estimated complete at Oct 02 11:01:38
Oct 02 10:24:50 2014 [6-3] recovery of upgrade redo at 49% - estimated complete at Oct 02 11:03:48Oct 02 10:25:40 2014 [6-3] recovery of upgrade redo at 50% - estimated complete at Oct 02 11:04:08
Oct 02 10:39:09 2014 [6-3] recovery of upgrade redo at 91% - estimated complete at Oct 02 10:44:02
Oct 02 10:39:25 2014 [6-3] recovery of upgrade redo at 92% - estimated complete at Oct 02 10:43:47Oct 02 10:40:07 2014 [6-3] recovery of upgrade redo at 94% - estimated complete at Oct 02 10:43:27
Alert log in Prod1
....
MRP0: Background Managed Standby Recovery process started (Prod1)Thu Oct 02 09:43:44 2014
RFS[2]: New Archival REDO Branch(resetlogs_id): 859866301 Prior: 859861928
RFS[2]: Archival Activation ID: 0x7c0d0055 Current: 0x0
RFS[2]: Effect of primary database OPEN RESETLOGS
RFS[2]: Managed Standby Recovery process is active
Thu Oct 02 09:43:44 2014
RFS[2]: Incarnation entry added for Branch(resetlogs_id): 859866301 (Prod1)
Thu Oct 02 09:43:44 2014
Setting recovery target incarnation to 3
Thu Oct 02 09:43:44 2014
Archived Log entry 48 added for thread 1 sequence 142 ID 0x7c0d0055 dest 1:
Thu Oct 02 09:43:47 2014
RFS[3]: Assigned to RFS process (PID:17124)
RFS[3]: Opened log for thread 1 sequence 2 dbid 2081205093 branch 859866301
Thu Oct 02 09:43:47 2014
Serial Media Recovery started
Managed Standby Recovery starting Real Time Apply
Thu Oct 02 09:43:53 2014
Archived Log entry 49 added for thread 1 sequence 2 rlc 859866301 ID 0x7c0d0055 dest 2:
Thu Oct 02 09:43:53 2014
Once the script done with recovery it will ask you to perform a switchover of Primary and standby to their original roles
### Stage 7: Switch back to the original roles prior to the rolling upgrade
NOTE: At this point, you have the option to perform a switchover
which will restore Prod1 back to a primary database andProd1DR back to a physical standby database. If you answer 'n'
to the question below, Prod1 will remain a physical standby
database and Prod1DR will remain a primary database.
Do you want to perform a switchover? (y/n): y
Oct 02 10:48:07 2014 [7-1] continuing
[7-1] continuing
[7-2] waiting for v$dataguard_stats view to initialize[7-2] waiting for apply lag on Prod1 to fall below 30 seconds
[7-2] apply lag is now less than 30 seconds
[7-3] switching Prod1DR to become a physical standby
[7-3] Prod1DR is now a physical standby
[7-3] shutting down database Prod1DR
[7-3] mounting database Prod1DR
[7-4] waiting for standby Prod1 to process end-of-redo from primary
[7-5] switching Prod1 to become the new primary
[7-5] Prod1 is now the new primary
[7-5] opening database Prod1
[7-6] starting media recovery on Prod1DR
[7-6] confirming media recovery is running
### Stage 8: Statistics
script start time:
script finish time:
total script execution time:
wait time for user upgrade:
active script execution time:
transient logical creation start time:
transient logical creation finish time:
primary to logical switchover start time:
logical to primary switchover finish time:
primary services offline for:
total time former primary in physical role:
time to reach upgrade redo:
time to recover upgrade redo:
primary to physical switchover start time:
physical to primary switchover finish time:
primary services offline for:SUCCESS: The physical rolling upgrade is complete
Finally, the databases are in 12.1.0.1, ofcourse there is little thing you have to do here if you use the physru script but you do not have the control when it fails , again you have to get back to alert logs etc.
Lessons learnt:-
1. Ensure you archive destinations works properly from both sides
2. Had been awaited long time for standby to be synchronized and the primary status showing not allowed, have to do manual recovery.
3. END of redo record is not being received to put a full stop for media recovery where had to finish off the recovery apparently my standby corrupts.
Conclusion:- Nice tool to do the upgrade, you need not to do 2 times upgrade rather one time upgrade is enough.
Follow Me!!!