Launching OUI

When all the prerequisites are met, and all upgrade best practices have been performed, you are good to go with the upgrade process. So, let’s get into the real action. Navigate through the Oracle 12c GI software staging location and launch OUI by running the following command:

./runInstaller

The Importance of the Rootupgrade.sh Script

Only software binaries are deployed under the respective homes on the local and remote nodes until the rootupgrade.sh script is executed. The rootupgrade.sh actually performs the core Clusterware stack configuration and upgrade. In the context, the script does the following core duties:

On the local node (first node):

1. ASM upgrade will be performed.
2. OLR will be configured accordingly.
3. The cluster auto start entries in the /etc/inittab file on the OS will be modified.
4. The existing cluster stack will be shut down.
5. The Oracle 12c cluster stack on the local node will be started up.
6. The OCR will be configured with necessary information before displaying the success Cluster configuration message.

The following output is expected when the rootupgrade.sh script is executed on the local and other nodes of the cluster, except the last node in the cluster:

[root@rac1 oracle]# /u01/app/12.1.0/grid_1/rootupgrade.sh
Performing root user operation for Oracle 12c
 
The following environment variables are set as:
    ORACLE_OWNER= oracle
    ORACLE_HOME=  /u01/app/12.1.0/grid_1
 
Enter the full pathname of the local bin directory: [/usr/local/bin]:
The file "dbhome" already exists in /usr/local/bin.  Overwrite it? (y/n)
[n]:
The file "oraenv" already exists in /usr/local/bin.  Overwrite it? (y/n)
[n]:
The file "coraenv" already exists in /usr/local/bin.  Overwrite it? (y/n)
[n]:
 
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Using configuration parameter file: /u01/app/12.1.0/grid_1/crs/install/crsconfig_params
2013/04/12 10:07:18 CLSRSC-363: User ignored prerequisites during installation
 
ASM upgrade has started on first node.
 
OLR initialization - successful
2013/04/12 10:12:29 CLSRSC-329: Replacing Clusterware entries in file '/etc/inittab'
 
CRS-4133: Oracle High Availability Services has been stopped.
CRS-4123: Oracle High Availability Services has been started.
CRS-2673: Attempting to stop 'ora.drivers.acfs' on 'rac1'
CRS-2677: Stop of 'ora.drivers.acfs' on 'rac1' succeeded
2013/04/12 10:17:24 CLSRSC-343: Successfully started Oracle clusterware stack
 
clscfg: EXISTING configuration version 5 detected.
clscfg: version 5 is 11g Release 2.
Successfully accumulated necessary OCR keys.
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
2013/04/12 10:20:34 CLSRSC-325: Configure Oracle Grid Infrastructure for a Cluster ... succeeded

On the last node:

1. OLR will be configured accordingly.
2. Modify the cluster auto start entries in the /etc/inittab file on the OS.
3. Existing cluster stack will be shut down.
4. Start-up the Oracle 12c cluster stack on the local node.
5. Configure the OCR with necessary information.
6. Starts the actual OCR,CSS,ASM & CRS process.

The following output is expected when the rootupgrade.sh script is executed on the last node in the cluster:

[root@rac2 ∼]# /u01/app/12.1.0/grid_1/rootupgrade.sh
Performing root user operation for Oracle 12c
 
The following environment variables are set as:
    ORACLE_OWNER= oracle
    ORACLE_HOME=  /u01/app/12.1.0/grid_1
 
Enter the full pathname of the local bin directory: [/usr/local/bin]:
The file "dbhome" already exists in /usr/local/bin.  Overwrite it? (y/n)
[n]:
The file "oraenv" already exists in /usr/local/bin.  Overwrite it? (y/n)
[n]:
The file "coraenv" already exists in /usr/local/bin.  Overwrite it? (y/n)
[n]:
 
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Using configuration parameter file: /u01/app/12.1.0/grid_1/crs/install/crsconfig_params
2013/04/12 10:22:05 CLSRSC-363: User ignored prerequisites during installation
 
OLR initialization - successful
2013/04/12 10:25:18 CLSRSC-329: Replacing Clusterware entries in file '/etc/inittab'
 
CRS-4133: Oracle High Availability Services has been stopped.
CRS-4123: Oracle High Availability Services has been started.
CRS-2673: Attempting to stop 'ora.drivers.acfs' on 'rac2'
CRS-2677: Stop of 'ora.drivers.acfs' on 'rac2' succeeded
2013/04/12 10:29:28 CLSRSC-343: Successfully started Oracle clusterware stack
 
clscfg: EXISTING configuration version 5 detected.
clscfg: version 5 is 11g Release 2.
Successfully accumulated necessary OCR keys.
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
Start upgrade invoked..
Started to upgrade the Oracle Clusterware. This operation may take a few minutes.
Started to upgrade the OCR.
Started to upgrade the CSS.
The CSS was successfully upgraded.
Started to upgrade Oracle ASM.
Started to upgrade the CRS.
The CRS was successfully upgraded.
Successfully upgraded the Oracle Clusterware.
Oracle Clusterware operating version was successfully set to 12.1.0.0.2
2013/04/12 10:35:20 CLSRSC-325: Configure Oracle Grid Infrastructure for a Cluster ... succeeded

Clusterware Downgrade

Whenever you prepare to introduce a new change to the existing environment, it is always a recommended and safe approach to have a complete backout plan to recover from any disasters that may occur after the change. If you work for a reputable organization, the management naturally expects a back-out plan to accompany all changes to the current environment. The back-out plan is a procedure to roll back the changes that were applied if the change didn’t go well, or the change creates new problems.

The objective of this section is to summarize all the necessary steps that are required to downgrade from a successfully upgraded or from a failed Clusterware/ASM to earlier versions.

Oracle’s out-of-place upgrade option makes the downgrade procedure faster by keeping the old and new versions of Oracle Clusterware software in different homes/locations. This makes the downgrade procedure a very light and quick process, in contrast with pre-11gR2 versions.

$GRID_HOME/crs/install/rootcrs.pl –downgrade

$GRID_HOME/crs/install/rootcrs.pl –downgrade -lastnode

./runInstaller -nowait -waitforcompletion -ignoreSysPrereqs -updateNodeList -silent CRS=false ORACLE_HOME=/u01/app/12.1.0/grid
 
./runInstaller -nowait -waitforcompletion -ignoreSysPrereqs -updateNodeList -silent CRS=false ORACLE_HOME=/u01/app/11.2.0/grid

$/u01/app/11.2.0/grid/bin/crsctl start crs

$ /u01/app/12.1.0/grid/rootupgrade –force

$/u01/app/12.1.0/grid/crs/install/rootcrs.pl –join –existingNode rac1 upgrade_node rac2

Deploying Manual Database Upgrade

In this section, you will learn all the mandatory steps that are required to perform a manual database upgrade to Oracle 12c. The following demonstrates the procedure to upgrade an Oracle 11.2.0.3 database, named PRDDB, to Oracle 12c:

Back up the source database, if no recent backup exists.

Connect to the source database as/sysdba and execute the pre-upgrade script from the Oracle 12c home. This is a mandatory step when you perform a manual database upgrade; on the flip side, if the script doesn’t run, the post–database upgrade step ultrp.sql script will be failed. Figure 13-13 shows how to run the pre-upgrade script on the source database:

export ORACLE_SID=PRDDB1
SQL> sqlplus / as sysdba
SQL> @/u01/app/oracle/product/12.0.1/rdbms/admin/preupgrd.sql
             
            You are likely to see the following output on running the pre-upgrade tool:

Unlike earlier Oracle database releases, the pre-upgrade output is written to a log file. You will have to review the preupgrd.log file generated by the pre-upgrade tool for any warnings and recommendations. Similarly, review and apply the recommendations stated in the preupgrade_fixups.sql andpostupgrade_fixups.sql scripts to fix any pre– and post–database upgrade issues recommended by the pre-upgrade tool on the source database, for example, collecting dictionary and fixed-objects statistics, database initialization parameter adjustments, invalid object details, tablespace size adjustments, etc. The log file and script files will typically be created under the $ORACLE_BASE/cfgtoolslogs/PRDDB/preupgrade location. If no $ORACLE_BASE variable is set on the server, the files in the context will be created under the $ORACLE_HOME/cfgtoolslogs/PRDDB/preupgrade location. The DBUA tool uses the pre-upgrade tool by default. The following shows the existence of the files under the $ORACLE_HOME location:

-rw-r--r-- 1 oracle dba 1444 Apr 13 09:34 postupgrade_fixups.sql
-rw-r--r-- 1 oracle dba 2491 Apr 13 09:34 preupgrade_fixups.sql
-rw-r--r-- 1 oracle dba 6397 Apr 13 09:34 preupgrade.log

Another important task while performing a manual database upgrade is to copy the source database password file, init/spfile, from the Oracle 11g home to the Oracle 12c Database home. Also, ensure that the local/remote listener parameter TNS configuration details are added in the new Oracle 12c tnsnames.ora file to avoid database startup failures when database is started from the Oracle 12c home. For a RAC database, you must do it for all instances. The following example demonstrates the copy command on Linux OS:

$cp /u01/app/oracle/product/11.2.0/db_1/dbs/orapwPRDDB1 /u01/app/oracle/product/12.1.0/db_1/dbs

If required, run the preupgrade_fixups.sql script and subsequently shut down and mount the database to disable the archivelog mode to avoid excessive archive generation during upgrade and to expedite the upgrade process.

srvctl stop database –d PRDDB
 
export ORACLE_SID=PRDDB1
 
sqplus / as sysdba
 
SQL> STARTUP MOUNT
SQL> ALTER DATABASE NOARCHIVELOG;
SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=SPFILE;
SQL> SHUTDOWN IMMEDIATE;

Set the $ORACLE_HOME to Oracle Database 12c version on the server.

export ORACLE_HOME=/u01/app/oracle/product/12.1.0/db_1
export PATH=$ORACLE_HOME/bin:$PATH
cd $ORACLE_HOME

On the SQL prompt, run the following database upgrade command:

SQL> CONNECT / AS SYSDBA
SQL> STARTUP UPGRADE

Exit from the SQL prompt and subsequently initiate the upgrade process in parallel mode, using the new Parallel Upgrade Utility, as explained here:

$/u01/app/oracle/product/12.0.1/db_1/perl/bin/perl catctl.pl–n 2 –l /tmp catupgrd.sql

If you prefer to perform an upgrade in a serial mode, like in previous releases, do the following at the SQL prompt:

SQL>@?/rdbms/admin/catupgrd.sql parallel=no

Database will be automatically shut down once the preceding command successfully completes. You therefore have to perform the following steps to enable the CLUSTER_DATABASE, set the database COMPATIBLE parameter to 12c, enable archive log, etc.:

SQL> STARTUP MOUNT
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER SYSTEM SET CLUSTER_DATABASE=TRUE SCOPE=SPFILE;
SQL> ALTER SYSTEM SET COMPATIBLE=12.1.0 scope=spfile;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP
SQL> execute dbms_stats.gather_fixed_objects_stats;
SQL> @/u01/app/oracle/prdoduct/12.1.0/rdbms/admin/utlrp.sql
SQL> @/u01/app/oracle/product/12.1.0/rdbms/admin/utlobj.sql
SQL> @/u01/app/oracle/product/12.1.0/rdbms/admin/utlu121s.sql
SQL> SHUTDOWN IMMEDIATE;
SQL> EXIT
 
utlrp.sql             recomiples all invalid objects on the database
ultobj.sql             verfies the validity of all packages/classes on the database
utlu121s.sql             displays database upgrade summary

After successfully completing the database upgrade process, you will have to modify the cluster database configuration details in the OCR using the following command:

srvctl upgrade database –d PRODB –o /u01/app/oracle/product/12.1.0/db_1

At this point in time, your cluster database is successfully upgraded to 12c. Now, open the database using the following cluster command, which in turn will start all RAC database instances:

srvctl start database –d PRODB

Post-Database Upgrade Steps

Once the database is successfully upgraded to Oracle 12c, go through the following recommended post–database upgrade steps:

• Run the postupgrade_fixups.sql script as explained earlier
• Back up the database
• Also migrate the source database listener to Oracle 12 by dropping and re-creating the existing listener
• Adjust any RMAN backups, cron tab or other scripts, environment, profile variables, etc., to reflect the new Oracle Home settings
• Ensure that the database points to the new Oracle Home in the oratab file
• Adjust the ATTRIBUTE 'compatible.asm'='12.1' to the ASM diskgroups to make use of new ASM features
• Verify database configuration details with the following:

  $ ./srvctl config database –d PRODB

Database Upgrade Using the DBUA

After learning a manual database upgrade procedure, it’s time now to shift the focus to know how to perform a database upgrade using the DBUA tool in Oracle 12c. In addition to portraying the DBUA database upgrade procedure with a bunch of screenshots, this section also going to explain why DBUA is a preferred method over other methods to perform a RAC database procedure.

The step-by-step procedure that outlines database upgrade with DBUA tool is as follows:

Launch ./duba from the Oracle 12c home.

Select the Upgrade Oracle database option on the Select Operation page, as shown in Figure 13-14.

Select the database from the given database list on the Select Database page, as shown in Figure 13-15.

Prerequisite checks are carried out and the result will be displayed. You will have an option to Ignore, Fix or Revalidate any prerequisite failures on this page. Also, you can run the prerequisite checks by clicking the Check Again button on the top right (Figure 13-16).

On the Upgrade Options screen, set the degree of parallelism to perform the upgrade and recompiling invalid objects in parallel. Optionally, you can also run any custom pre–/post–database upgrade Scripts.

Specify the configuration options for EM Cloud Control on the Management Options screen.

The new Move Database Files screen allows you to move the datafiles and FRA location between Filesystem, ASM, etc.

Also, the Network Configuration screen permits you to migrate an existing listener to the new Oracle release.

Optionally, the Recovery Options screen has the flexibility to define a recovery point to recover the database to the same point in case of any failures during the database upgrade process.

Once you input all the required information through the interactive screens, the Database Upgrade Information screen provides all details that you entered for this process.

Click on the Finish button to kick-start the upgrade action.

You will see the Upgrade Screen after the database upgrade is complete.

After going through the preceding steps, you will have a successful database upgrade for an Oracle 11gR2 (11.2.0.3) to Oracle 12c Database.

DBUA Advantages

This section will quickly take you through some of the following advantages of DBUA over other database upgrade options:

• When a RAC database is upgraded with DBUA, the tool automatically takes appropriate action, such as enabling, disabling CLUSTER_DATABAE parameter.
• There is the option to disable the archivelog mode during the course of upgrade, to avoid excessive archive log generation, which ultimately expedites the upgrade.
• DBUA makes use of the new tools by default: initiating the catupgrd process in parallel, running the pre-upgrade tool, etc.
• Recommendations in the forms of pre/postupgrade.slq also fix any recommendation failures.
• An option to recompile all objects post–database upgrade and gather pre-/post-database statistics is provided.
• The existing database listener is upgraded to the new Oracle home.
• Most importantly, the tool allows you to define a recovery point to roll back the upgrade in case of failure.
• You will also have an option to migrate the database from one Oracle 12c home to another 12c home.

Database Downgrade

Sometimes after a successful database upgrade, you might have to downgrade the database to its previous release for various factors; hence, you should have a back-out action plan in mind when you do an upgrade procedure. The following is the database downgrade procedure which lets you downgrade the database from 12c to a previous Oracle database release:

Perform the current database full backup.

Disable the database vault, if it exists.

Ensure that the database COMPATIBLE initialization parameter is set to the Database version that supports a direct upgrade (refer to Table 13-2).

Drop the sysman user if OEM is configured. You will have to reconfigure the OEM after you finish the downgrade process.

Disable the CLUSTER_DATABASE initialization parameter, and stop the database as follows:

export ORACLE_SID=PRDDB1
SQL> sqlplus / as sysdba
SQL> alter system set cluster_database=false scope=spfile;
 
srvctl stop database –d PRDDB

Start up the database in downgrade mode and then execute the downgrade script, as follows:

SQL> STARTUP DOWNGRADE;
SQL> SPOOL /tmp/dbdowngrade.log
SQL> @?/rdbms/admin/catdwgrd.sql

The catdwgrd.sql script under the Oracle 12c /rdbms/admin home downgrades the 12c Database components to the previous release. If you encounter any ORA issues during the course of downgrade, fix the issue and rerun the downgrade script once again.

After completing the script, shut down the database and exit from the SQL prompt.

Set the previous Oracle version to ORACLE_HOME, PATH OS env variables.

Start up the database in UPGRADE mode to reload the previous version components by running the catreload.sql script from the Oracle 11g /rdbms/admin home. Examples are as follows:

export ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1
sqlplus / as sysdba
 
SQL> STARTUP UPGRADE
SQL> spool /tmp/dbdowngrade.log
SQL> @?/rdbms/admin/catreload.sql

Enable the CLUSTER_DATABASE parameter, and shut down and start up the database.

SQL> ALTER SYSTEM SET CLUSTER_DATABASE=TRUE SCOPE=SPFILE;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP

Recompile all invalid objects running the utlrp.sql script.

SQL> @?/rdbms/admin/utlr.sql

Downgrade the database version in the OCR using the srvctl downgrade command from the Oracle 12c database home.

srvctl downgrade database –d PRDDB –o /u01/app/oracle/product/11.2.0/db_1 –to_version 11.2.0.3.0