Once the database software is installed copy the spfile , initfile, oracle password file, tnsnames.ora and listener.ora file from the 12.1.0.1 oracle home into the 12.1.0.2 oracle home. In this case the 12.1.0.1 oracle home is /opt/app/oracle/product/12.1.0/dbhome_1 and 12.1.0.2 oracle home is /opt/app/oracle/product/12.1.0/dbhome_2
echo $ORACLE_HOME /opt/app/oracle/product/12.1.0/dbhome_1 ## 12.1.0.1 ORALCE HOME cd $ORACLE_HOME/dbs $ cp spfileent12c1s.ora initent12c1s.ora orapwent12c1s ../../dbhome_2/dbs/ $ cd ../network/admin/ $ cp tnsnames.ora listener.ora ../../../dbhome_2/network/admin/Open the listener.ora file that is in the new ORACLE_HOME/network/admin and edit the static listener entries to reflect the new oracle home path. These static listener entries were created as part of the data guard configuration.
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = ent12c1)
(SID_NAME = ent12c1)
(ORACLE_HOME = /opt/app/oracle/product/12.1.0/dbhome_2)
)
)Defer the redo transport on the primary until the standby is mounted using the new 12.1.0.2 oracle home.SQL> alter system set log_archive_dest_state_2='defer';and cancel the redo apply on the standby
SQL> alter database recover managed standby database cancel;Modify the /etc/oratab to reflect the new oracle association with the standby instance
cat /etc/oratab ent12c1s:/opt/app/oracle/product/12.1.0/dbhome_2:NStop the listener started out of the 12.1.0.1 home.
Modify the environment variables so that they are pointed to new 12.1.0.2 oracle home (ORACLE_HOME,PATH and etc). Start the listener using the 12.1.0.2 oracle home. Verify that listener is started from the new home
$ lsnrctl start Starting /opt/app/oracle/product/12.1.0/dbhome_2/bin/tnslsnr: please wait... TNSLSNR for Linux: Version 12.1.0.2.0 - Production System parameter file is /opt/app/oracle/product/12.1.0/dbhome_2/network/admin/listener.ora Log messages written to /opt/app/oracle/diag/tnslsnr/hpc5/listener/alert/log.xml ... Services Summary... Service "ent12c1s" has 1 instance(s). Instance "ent12c1s", status UNKNOWN, has 1 handler(s) for this service..Mount the standby database using the 12.1.0.2 oracle home and start the redo apply
SQL> startup mount; SQL> alter database recover managed standby database disconnect;Verify from the alert log that database is started using 12.1.0.2 oracle home parameter file.
ORACLE_HOME = /opt/app/oracle/product/12.1.0/dbhome_2 System name: Linux Node name: hpc5.domain.net Release: 2.6.18-194.el5 Version: #1 SMP Tue Mar 16 21:52:39 EDT 2010 Machine: x86_64 Using parameter settings in server-side spfile /opt/app/oracle/product/12.1.0/dbhome_2/dbs/spfileent12c1s.oraEnable the redo transport on the primary
alter system set log_archive_dest_state_2='enable'This conclude the upgrade activity on the standby. The standby database instance will be upgrade once the redo generated during the primary database upgrade is transported and applied on to the standby.
Although the setup used on this post consists of a data guard configuration the primary site steps are valid for single instances without data guard configuration as well. The software upgrade on the primary is done as an out of place upgrade. Once the 12.1.0.2 software is installed run the preupgrade script from the new home.
cd /opt/app/oracle/product/12.1.0/dbhome_2/rdbms/admin
SQL> @preupgrd.sql
Loading Pre-Upgrade Package...
***************************************************************************
Executing Pre-Upgrade Checks in ENT12C1...
***************************************************************************
************************************************************
====>> ERRORS FOUND for ENT12C1 <<====
The following are *** ERROR LEVEL CONDITIONS *** that must be addressed
prior to attempting your upgrade.
Failure to do so will result in a failed upgrade.
1) Check Tag: PURGE_RECYCLEBIN
Check Summary: Check that recycle bin is empty prior to upgrade
Fixup Summary:
"The recycle bin will be purged."
You MUST resolve the above error prior to upgrade
************************************************************
************************************************************
====>> PRE-UPGRADE RESULTS for ENT12C1 <<====
ACTIONS REQUIRED:
1. Review results of the pre-upgrade checks:
/opt/app/oracle/cfgtoollogs/ent12c1/preupgrade/preupgrade.log
2. Execute in the SOURCE environment BEFORE upgrade:
/opt/app/oracle/cfgtoollogs/ent12c1/preupgrade/preupgrade_fixups.sql
3. Execute in the NEW environment AFTER upgrade:
/opt/app/oracle/cfgtoollogs/ent12c1/preupgrade/postupgrade_fixups.sql
************************************************************
***************************************************************************
Pre-Upgrade Checks in ENT12C1 Completed.
***************************************************************************
***************************************************************************As instructed on the output run the fixup sql on the primary database @/opt/app/oracle/cfgtoollogs/ent12c1/preupgrade/preupgrade_fixups.sqlRun pre upgrade sql again and check of errors and warnings. If there are any errors of warnings fix them before continuing with DBUA. To being the upgrade run DBUA from the 12.1.0.2 home.
Select the database upgrade option.
Select the source oracle home and the instance to upgrade.
The DBUA detects the data guard configuration is in place and prompt to sync the standby database. This is not an error but an information provided by the DBUA. There should not be any archive gaps prior to the primary upgrade.
Once the upgrade is completed set the environment variables to reflect the new oracle home.
Also run the post upgrade script as suggested by the pre upgrade sql
@/opt/app/oracle/cfgtoollogs/ent12c1/preupgrade/postupgrade_fixups.sqlVerify listener is running out of the new home. If as mentioned earlier listener.ora and tnsnames.ora files are not moved to the new oracle home, move them manually to the 12.1.0.2 home. Once moved stop the listener and start it to run out of the new 12.1.0.2 oracle home.
To validate the data guard configuration is working carry out few log file switches and verify they are received at the standby and applied.
Once tested and satisfied with the upgrade, update the compatible initialization parameter to 12.1.0.2. It is not possible to downgrade the database once this has been set. In this case the standby was the first to be set compatible = 12.1.0.2 followed by the primary. Read data guard admin guide for exact steps.
This conclude the upgrade from 12.1.0.1 to 12.1.0.2 This is not an extensive "how to" guide but only the highlights. For complete information refer the oracle upgrade guide and the following metalink notes.
Useful metalink notes
Oracle 12cR1 Upgrade Companion [ID 1462240.1]
Oracle Database Upgrade Path Reference List [ID 730365.1]
Master Note For Oracle Database 12c Release 1 (12.1) Database/Client Installation/Upgrade/Migration Standalone Environment (Non-RAC) [ID 1520299.1]
Actions For DST Updates When Upgrading To Or Applying The 12.1.0.2 Patchset [ID 1665676.1]
Related Posts
Upgrading RAC from 11.2.0.4 to 12.1.0.2 - Grid Infrastructure
Upgrading RAC from 12.1.0.1 to 12.1.0.2 - Grid Infrastructure
Upgrade from 11.1.0.7 to 11.2.0.4 (Clusterware, ASM & RAC)
Upgrading from 10.2.0.4 to 10.2.0.5 (Clusterware, RAC, ASM)
Upgrade from 10.2.0.5 to 11.2.0.3 (Clusterware, RAC, ASM)
Upgrade from 11.1.0.7 to 11.2.0.3 (Clusterware, ASM & RAC)
Upgrading from 11.1.0.7 to 11.2.0.3 with Transient Logical Standby
Upgrading from 11.2.0.1 to 11.2.0.3 with in-place upgrade for RAC
In-place upgrade from 11.2.0.2 to 11.2.0.3
Upgrading from 11.2.0.2 to 11.2.0.3 with Physical Standby - 1
Upgrading from 11.2.0.2 to 11.2.0.3 with Physical Standby - 2
Upgrading from 11gR2 (11.2.0.3) to 12c (12.1.0.1) Grid Infrastructure
