Oracle Silent Mode, Part 2: Patching 10.2 And 11.1 Databases

This post is the second in a series of ten posts exploring some of the Oracle Universal Installer (OUI), Network Assistant (NETCA), Database Creation Assistant (DBCA), Database Upgrade Assistant (DBUA), and many more syntaxes you can use to script or speed up Oracle Installations. The complete series should look like:

1. Installation of 10.2 And 11.1 Databases
2. Patches of 10.2 And 11.1 databases (this post!)
3. Cloning Software and databases
4. Install a 10.2 RAC Database
5. Add a Node to a 10.2 RAC database
6. Remove a Node from a 10.2 RAC database
7. Install a 11.1 RAC Database
8. Add a Node to a 11.1 RAC database
9. Remove a Node from a 11.1 RAC database
10. A ton of other stuff you should know

In the first post, you can find syntaxes to install a 10.2 or a 11.1 database, and how to apply a Patch Set on top of them. This post is way shorter and digs into a couple OPatch, DBUA, and OUI syntaxes. It explains how to apply a one-off patch, how to upgrade a database and how to uninstall a previous ORACLE_HOME.

Foreword

There are basically two ways to upgrade your Oracle Database Software to a new Patch Set level:

1. The In-Place Way: reuse the same ORACLE_HOME
2. The Out-of-Place Way necessitates that you create a new ORACLE_HOME for the new Patch Set

If the 10g OFA standard contains only the Base Release version, you will be able to perform an In-Place Upgrade. Thi approach, however, has several drawbacks:

• It requires that you stop all the components (Listeners, ASM, Instances, Database Console) during the software upgrade.
• It doesn’t leave the previous ORACLE_HOME install intact, and makes more complex the build of a rollback scenario.
• If you’ve installed a one-off patch, it is very likely the patchset will erase them, but Inventory will keep track of them.

For all those reasons, it’s safer to use a new ORACLE_HOME and so I won’t cover how to perform an In-Place update. Actually it’s not really different, so you should easily be able to build that scenario by yourself. And if you think: “Well, what the use of keeping only the major Database version in the OFA standard if you advise using a new ORACLE_HOME ?”, the answer is: “Once you’ve release the 10.2.0.3 ORACLE_HOME to use a 10.2.0.4 ORACLE_HOME, with that changed in the OFA standard, you’ll be able to use that ORACLE_HOME for the next Patch Set without reinstalling the software and the names will stay consistent!”. But enough of this foreword.

Important:
Before you apply any patch or upgrade, make sure you have a valid backup of your database. What you may want to do to is (a) create a restore point and (b) make a backup of the controlfile right after that. Note also that changing the value of the COMPATIBLE parameter will prevent you from rolling back the patch and in most cases from using the Flashback database feature.

Installing Oracle Database 10.2, 11.1 and Applying a Patch Set

Before you proceed with a one-off Patch or a Database Upgrade, you may want to install the Database Software or apply a Patch Set on top of it. In order to get some details about how to perform those tasks, you can refer to the previous post of these series and the following sections:

• Install Oracle 10.2 Database Software
• Apply The Latest Patch Set to the Oracle 10.2 Database Software
• Install Oracle 11.1 Database Software
• Apply The Latest Patch Set to the Oracle 11.1 Database Software

Using Oracle Patch to apply a single patch

OPatch is the tool that is used to apply one-off patches and the Critical Patch Updates (CPU). Depending on the patch, you may of may not run Pre- and Post- steps and use different types of commands. To know more about OPatch,you can run the set of commands below:

$ export ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1
$ export PATH=$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$PATH
$ opatch -help
$ opatch lsinventory -help
$ opatch apply -help
$ # Only if OPatch 10.2.0.4
$ #         or later is installed
$ opatch napply -help
$ opatch util -help
$ opatch query -help
$ opatch prereq -help
$ opatch rollback -help
$ # Only if OPatch 10.2.0.4
$ #      or later is installed
$ opatch nrollback -help

To apply a patch with OPatch, nonetheless the pre- and post- steps, the application procedure consists in the following steps:

1. Download and Unzip the patch in a directory (e.g. $DISTRIB). To do it from FTP, refer to the Metalink node 398595.1.

   $ cd $DISTRIBS
   $ unzip p7022905_10204_Linux-x86.zip
   $ cd 7022905

2. Run the pre-Step. Refer to the patch README.txt file to see what needs to be done
3. Stop all the components that are using the ORACLE_HOME (Listener, ASM, Database, EM Database Console)
4. Apply the patch with Oracle Patch

   $ export ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1
   $ export PATH=$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$PATH
   $ opatch apply

5. Run the post-Steps. Refer to the patch README.txt file to see what needs to be done. Those steps should include restarting all the components that are using the ORACLE_HOME

Upgrading to the latest 10.2 Patch Set with DBUA

To know more about DBUA, you can run dbua -help or refer to the correponding section of the 10.2 Upgrade Guide. If you upgrade from a 10.2 earlier Patch Set and the /etc/oratab and the init.ora or spfile.ora are correctly setup, upgrading is as simple as the one line command below:

$ export ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_2
$ export PATH=$ORACLE_HOME/bin:$PATH

$ dbua -silent                                       \
    -sid BLACK                                       \
    -oracleHome /u01/app/oracle/product/10.2.0/db_1  \
    -autoextendFiles                                 \
    -recompile_invalid_objects true                  \
       -degree_of_parallelism 1                      \
    -emConfiguration NONE

The parameter used are the following:

• -silent must be use to run without any X Display
• -sid defines the instance to be upgraded (e.g. BLACK)
• -oracleHome defines the of the ORACLE_HOME that is currently used to the the instance (e.g. /u01/app/oracle/product/10.2.0/db_1)
• -autoextendFiles is a directive that means the files will be turn to auto extensible files during the upgrade process and will be turn back to their previous mode right after the upgrade
• -recompile_invalid_objects defines if the utlrp.sql script has to be executed after the upgrade (e.g. true)
• -degree_of_parallelism defines degree of parallelism to be used to run the utlrp.sql script (e.g. 1)
• -emConfiguration enables to register the new configuration is Enterprise Manager GridControl if an Agent has been installed previously or to configure Oracle Enterprise Manager (e.g. NONE)

If you upgrade from 9.2, you’ll have to add the -sysauxTablespace and its associated parameters to create the SYSAUX tablespace.

Upgrading to 11.1 with DBUA

To know more about DBUA, you can run dbua -help or refer to the correponding section of the 11.1 Upgrade Guide. If you upgrade from a 10.2 or a 11.1 release and the /etc/oratab and the init.ora or spfile.ora are correctly setup, upgrading to the latest 11.1 is as simple as the one line command below:

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

$ dbua -silent                                       \
    -sid BLACK                                       \
    -oracleHome /u01/app/oracle/product/10.2.0/db_1  \
    -diagnosticDest /u01/app/oracle                  \
    -autoextendFiles                                 \
    -recompile_invalid_objects true                  \
       -degree_of_parallelism 1                      \
    -emConfiguration NONE

The parameter used are the following:

• -silent must be use to run without any X Display
• -sid defines the instance to be upgraded (e.g. BLACK)
• -oracleHome defines the of the ORACLE_HOME that is currently used to the the instance (e.g. /u01/app/oracle/product/10.2.0/db_1)
• -diagnosticDest defines the location of the Automatic Diagnostic Repository (e.g. /u01/app/oracle)
• -autoextendFiles is a directive that means the files will be turn to auto extensible files during the upgrade process and will be turn back to their previous mode right after the upgrade
• -recompile_invalid_objects defines if the utlrp.sql script has to be executed after the upgrade (e.g. true)
• -degree_of_parallelism defines degree of parallelism to be used to run the utlrp.sql script (e.g. 1)
• -emConfiguration enables to register the new configuration is Enterprise Manager GridControl if an Agent has been installed previously or to configure Oracle Enterprise Manager (e.g. NONE)

If you move from 9.2, you’ll have to add the -sysauxTablespace and its associated parameters to create the SYSAUX tablespace.

Removing an ORACLE_HOME

Once you’ve installed a new ORACLE_HOME and upgrade the database to it, you may want to remove the previous database software. In order to do it, the fastest way is to use the Oracle Universal Installer in Silent mode as below:

$ cd $ORACLE_HOME/oui/bin
$ ./runInstaller -silent -deinstall -removeallfiles \
       REMOVE_HOMES={"/u01/app/oracle/product/10.2.0/db_1"}

The parameter used are the following:

• -silent must be use to run without any X Display
• -deinstall is used to deinstall the software
• -removeallfiles forces all the files, including the Universal Installer to be deleted
• REMOVE_HOMES contains a list of ORACLE_HOME to be deleted. Triple-check that directory before running the command (e.g. /u01/app/oracle/product/10.2.0/db_1)

In The Next Post

Stay tuned! I’m already working on the next posts. Part 3 will explain some of the syntaxes you can use to create “Gold Standards” for your database software and for your database templates. Those techniques will enable you to get one step further to speed up everything, again.