Oracle Database Upgrade 12c to 19c with Physical Standby Database Using DBUA
In this article, we show the procedure to upgrade the oracle database 12c to 19c with the physical standby database using DBUA. Standby physical database will be upgraded through redo applying from the primary database and there is no need to rebuild the physical standby database after upgrading the primary database. Upgrade procedure details are as follows.
Primary & Standby Database Activities:
Step 1: Install oracle software only in both the primary & standby database server
Create a new database home for both primary and standby databases. Unzip the database into the new 19c home and install the software only RDBMS.
# mkdir -p /u01/app/oracle/product/19c/db_1
# chown -R oracle:oinstall /u01/app/oracle/product/19c/db_1
# chmod -R 775 /u01/app/oracle/product/19c/db_1
Unzip the software to the new 19c home using the following command
Unzip Oracle_19.3_Linux_x86-64_DB_V982063-01.zip -d /u01/app/oracle/product/19c/db_1
# cd /u01/app/oracle/product/19c/db_1
# ./runInstaller
Primary Database Activities:
Step 2: Check the Invalid Objects if there have any invalid objects compile them before the upgrade.
As a prerequisite, it Is recommended to check for invalid objects. If there have any invalid objects validate the invalid objects.
$ sqlplus / as sysdba
SQL*Plus: Release 12.2.0.1.0 Production on Thu Jan 5 16:12:57 2023
Copyright (c) 1982, 2016, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
$ SQL> select count(*) from dba_objects where status='INVALID';
Step 3: Create the required directory where store the upgradation script
# mkdir -p /u01/spool/preupgrade -- Primary database
# chown -R oracle:oinstall /u01/spool/preupgrade
# chmod -R 775 /u01/spool/preupgrade
Step 4: Execute the Pre-upgrade script in the primary node only
In the below screenshot, we have executed the preupgrade.jar from the 19c Oracle Home. The
preupgrade.jar output provides pre and post-upgradation recommendation fixup SQL script. The pre
and post-upgradation fixup SQL scripts can be located in the directory location as created above. In the
output, we also get the command to run the pre and post-fixup steps.
# /u01/app/oracle/product/12c/db_1/jdk/bin/java -jar /u01/app/oracle/product/19c/db_1/rdbms/admin/preupgrade.jar FILE DIR /u01/spool/preupgrade/
Carefully check the preupgrade.log log and fixup the issues before preceding the upgrade.
Output:
==============
BEFORE UPGRADE
==============
REQUIRED ACTIONS
================
None
RECOMMENDED ACTIONS
===================
1. (AUTOFIXUP) Gather stale data dictionary statistics prior to database
upgrade in off-peak time using:
EXECUTE DBMS_STATS.GATHER_DICTIONARY_STATS;
Dictionary statistics do not exist or are stale (not up-to-date).
Dictionary statistics help the Oracle optimizer find efficient SQL
execution plans and are essential for proper upgrade timing. Oracle
recommends gathering dictionary statistics in the last 24 hours before
database upgrade.
For information on managing optimizer statistics, refer to the 12.2.0.1
Oracle Database SQL Tuning Guide.
INFORMATION ONLY
================
2. Check the Oracle Backup and Recovery User's Guide for information on how
to manage an RMAN recovery catalog schema.
If you are using a version of the recovery catalog schema that is older
than that required by the RMAN client version, then you must upgrade the
catalog schema.
It is good practice to have the catalog schema the same or higher version
than the RMAN client version you are using.
ORACLE GENERATED FIXUP SCRIPT
=============================
All of the issues in database DPDB
which are identified above as BEFORE UPGRADE "(AUTOFIXUP)" can be resolved by
executing the following
SQL>@/u01/spool/preupgrade/preupgrade_fixups.sql
Step 6: Perform the recommended actions as per preupgrade log.
SQL> EXECUTE DBMS_STATS.GATHER_DICTIONARY_STATS;
SQL> @/orasoft/spool/preupgrade/preupgrade_fixups.sql
Step 7: Enable flashback in both primary and standby databases and create a restore point
If the flashback is not enabled first enable the flashback database in both the primary and standby database using the following procedure as well as keep enough free space in db_recovery_file_dest.
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=60G;
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/u01/oraflash/';
SQL> alter database flashback on;
Now create the guarantee restore point in both primary & standby databases.
Primary DB:
SQL> create restore point before_upgrade_19c_PG guarantee flashback database;
SQL> select name from v$restore_point;
NAME
--------------------------------------------------------------------------------
BEFORE_UPGRADE_19C_PG
Standby DB:
SQL> create restore point before_upgrade_19c_DG guarantee flashback database;
SQL> select name from v$restore_point;
NAME
--------------------------------------------------------------------------------
BEFORE_UPGRADE_19C_DG
Step 8: Shutdown the standby database and defer log archive destination
SQL> alter system set log_archive_dest_state_2=DEFER SCOPE=BOTH;
Standby database:
SQL> shut immediate;
Stop the listener
# lsnrctl stop
Step 9: Copy the listener, tns, and password file 12c database to the new 19c database.
Start the listener as 19c database steps are as follows.
# export ORACLE_HOME=/u01/app/oracle/product/12c/db_1
# export PATH=$ORACLE_HOME/bin:$PATH;
# lsnrctl stop
# export ORACLE_HOME=/u01/app/oracle/product/19c/db_1
# export PATH=$ORACLE_HOME/bin:$PATH;
# lsnrctl start
Step 10: Set the new 19c database environment
# export ORACLE_HOME=/u01/app/oracle/product/19c/db_1 (19c database home)
# cd $ORACLE_HOME/bin
./dbua
Action: Click the Next button
Action: No error is found and the showing message is the post-upgrade recommendation. If there have any error messages resolve the error before going to the following windows. Click the following button.
Action: Click the next button
Action: We created a restore point before preceding the upgrade and here we use the restore point and click the next button.
Action: Use the existing listener and click the next button
Action: Click the next button
Action: This is the summary window, if found all are okay click the Finish button.
Action: Check the alter log to see what is happening if arise any error messages carefully read and solve the issue.
Action: Upgrade is completed successfully.
Post Upgrade Tasks
Step 1: Verify /etc/oratab and check if ORACLE_HOME location has changed to 19c home
# cat /etc/oratab |grep -i DPDB
Step 2: Verify the time zone and invalid objects
SQL> SELECT version FROM v$timezone_file;
VERSION
----------
32
SQL> select count(1) from dba_objects where status='INVALID';
COUNT(1)
----------
0
Step 3: Verify DBA_REGISTRY
SQL> col COMP_ID for a10
col COMP_NAME for a40
col VERSION for a15
set lines 180
set pages 999
select COMP_ID,COMP_NAME,VERSION,STATUS from dba_registry;
Step 4: Run postupgrade_fixups.sql, this script already ran by DBUA under the post-upgrade section. However, we have executed it again
SQL>@/orasoft/spool/preupgrade/postupgrade_fixups.sql
Step 5: Once the upgrade is completed successfully and all are found okay then you can drop the restore point.
SQL> col name for a20
SQL> col GUARANTEE_FLASHBACK_DATABASE for a10
SQL> col TIME for a60
SQL> set lines 190
SQL> select NAME, GUARANTEE_FLASHBACK_DATABASE, TIME from V$restore_point;
NAME GUARANTEE_ TIME
-------------------- ---------- ------------------------------------------------------------
BEFORE_UPGRADE_19C_PG YES 22-FEB-23 11.45.22.000000000 AM
SQL> drop restore point BEFORE_UPGRADE_19C_PG;
The restore point dropped.
Step 6: Update the COMPATIBLE parameter
Note: After the upgrade, the database has to be tested properly before updating the compatible parameter. Once the parameter is updated database cannot be downgraded.
SQL> show parameter compatible;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
compatible string 12.2.0
SQL> alter system set compatible='19.0.0' scope=spfile;
SQL> shutdown immediate;
SQL> startup;
SQL> show parameter compatible;
The database has been successfully upgraded to 19c.
SQL> select name, open_mode, version from v$database, v$instance;
NAME OPEN_MODE VERSION
-------------------- -------------------- ---------------
DPDB READ WRITE 19.0.0.0.0
Standby Database Activities:
Step 1: Copy the listener, tns, and password file to the new 19c database home location
# cd $ORACLE_HOME/ network/admin - 12c home
# cp listener.ora tnsnames.ora /u01/app/oracle/product/19c/db_1/network/admin - 19c home
# cd $ORACLE_HOME/dbs
# cp orapwDPDB /u01/app/oracle/product/19c/db_1/dbs
Stop the listener and export the 19c home and start the listener
# lsnrct stop
# export ORACLE_HOME=/u01/app/oracle/product/19c/db_1
# export PATH=$ORACLE_HOME/bin:$PATH;
# export ORACLE_SID=DPDB_STBY
# lsnrctl start
# lsnrctl status
Start the database from 19c home
SQL> STARTUP MOUNT;
Check the network check
# tnsping DR_TNSNAME
# tnsping DC_TNSNAME
Primary database Activities:
# tnsping DR_TNSNAME
# tnsping DC_TNSNAME
Log archive destination enable in the primary database
SQL> alter system set log_archive_dest_state_2=ENABLE scope = both;
Standby Database Activities:
Check database mode and role using the following command
SQL> select open_mode, database_role from v$database;
Start the recovery manager in the standby database
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
The physical standby database will be upgraded through the redo apply.
Check the redo log and apply details using the following query.
SQL> select process, status, thread#, sequence#, block#, blocks from v$managed_standby;
Done!
Post a Comment
0 Comments