Oracle Database Upgrade to 12c (In a Fail Safe Environment)

This a step-by-step detailed procedure for upgrading one Oracle Database 11gR2 ( on Windows Server 2012 to the latest version 12c ( with the latest available Windows Bundle Patch. The database is configure with Fail Safe (Active/Passive) cluster to provide some sort of high availability. This is an actual live upgrade for one of my customers.

Although this is a long post, but I hope it will be of a good value for any person doing the same task in the future.

Current Environment:



What is Fail Safe?

Oracle Fail Safe is a clustering solution from Oracle. It is an extra layer above “Microsoft Failover Cluster”.

Usually, this type of cluster consists of two servers with shared storage, and configured as Active/Passive cluster.

This means that one node will own the storage at any given point of time. This node will have the database up and running. Whenever there is any issue with node, the cluster will failover the database (and the shared storage) to the other node. End users see the cluster as one entity with one virtual IP, they don’t care which is the active node?. They got the same service from whatever active node. There are more complex cluster configuration, but let us keep it simple. Fail Safe is similar to “RAC One Node”, but it is not based on the Oracle Clusterware, and most important it is free!.

Upgrade Plan

  • Check certification/Compatibility between all components.
  • Install Oracle Software 12c ( along with the latest patches on both nodes.
  • Remove the 11gR2 Database from its FS group
  • Upgrade the Database to 12c
  • Verify the 12c Standby Database
  • Add the database back to its original FS Group
  • Finishing Tasks
  • Testing and Go-Live

We will proceed with the above plan step-by-step

Check certification/Compatibility between all components

I’m lucky as the installed Fail Safe version is the latest one (4.1.1), so, need for any patching at the Fail Safe level.

Let us check all certification of the different components through Oracle Support

Fail Safe Certification with Windows

Fail Safe is certified with Windows 20122

Fail Safe Certification with Oracle 12c

Oracle FS is supported with the 12c (Non-CDB)

Oracle Fail Safe Release 4.1.1, is supported in a multitenant container database environment (FS 4.1 is not supported).


Non-CDB or CDB Configuration

In database 12c, you can configure a normal database (Non-CDB or not-Multi-Tenant Database as the of 11g) or you may configure a CDB (or Multi-Tenant Database). So, which configuration should we choose for our upgrade?


From the Oracle Upgrade Blog:

you will find the following statement:

“Beginning with Oracle Database a non-CDB architecture is deprecated”

But in the same blog in the comments:

I just can tell you now that this (Single/Multi-Tenant is a must) won’t happen in Oracle 12.2.

We officially say (and write it down) that all potential architectures (non-CDB == as you know it, CDB with either one PDB or many) will be available free of choice until at least Oracle Database 12.2.

So, we still have time to enjoy the Non-CDB configuration.

So, my final decision is to go with Non-CDB for the following reasons:

There are many features that are still not available with the CDB/PDB architecture like:

  • Database Change Notification
  • Continuous Query Notification (CQN)
  • Client Side Cache
  • Heat Map
  • Automatic Data Optimization
  • Oracle Streams
  • Flashback Pluggable Database (Flashback Database works but will flashback CDB$ROOT including all PDBs)
  • Data Recovery Advisor (DRA)
  • Flashback Transaction Backout


Officially, you can use Non-CDB with version and the coming 12.2 without any problem, so we have a plenty of time to use Non-CDB

There is no critical need for my client for using CDB/PDB architecture at the moment              We don’t have time luxury to retest the application again in PDB


To reduce the down time, the new 12c version can be installed on each node while the old 11gR2 database is still running in the Fail Safe group.

Backup the 11g database

Ensure consistent stat of the cluster

Unzip The Software on both nodes

On Node1:


Extract the 12102 software:56

Also, extract the patch p22809813_121020_MSWIN-x86-64:


Repeat the extraction process on Node2

Ensure that you are login to Node 1 with the “Domain Administrator”, which is the user used initially to install the whole cluster.

Stop the currently running Oracle Services on Node 1 (just for safety!):


Note that the current:

11g ORACLE_HOME=C:\app\Administrator\product\11.2.0\dbhome_1

11g ORACLE_BASE= C:\app\Administrator


The current “Regedit” view is as follows:


Install Oracle Software 12c ( along with the latest patches on both nodes.

Install Oracle Database 12c on Node1

Start the OUI on node1:


It looks like, it is a must to specify non-administrator user in 12c !


Here I need to have a big stop regarding the above screen of choosing Oracle Home owner!!!

As per 12c Oracle Documentation, you can choose an existing Domain or Local user or you can create a new local user as I selected above. This is clear in the following part of the Database Installation Guide:


So, there is no problem of choosing local windows user to be the software owner, Actually I completed the installation successfully and upgraded the database successfully, But at the last step od adding the database back to the Fail Safe cluster, I got an error. After searching about this error, I found that the fix of this error is to use a Domain User as a software owner when using 12c with Fai Safe. This is not documented in any place. I just found the following screen shot on one tutorial:


But this was an example, not a mandatory requirements mentioned.

So, to save your time, please don’t use local user as a software owner. I had to create a domain user called “oinstall” and pass it in the above screen. But I had first to clean my 12c installation on both nodes and re-install them again.

<<<< Don’t use local user a software owner, this is a life safer! >>>>

<<<< Don’t use local user a software owner, this is a life safer! >>>>

<<<< Don’t use local user a software owner, this is a life safer! >>>>


Following is the Windows Services status after the installation:


Install Oracle® Database Windiows Bundle Patch (22809813) version


As per the patch readme file:

You must use the OPatch utility version or later to apply this patch. Oracle recommends that you use the latest released OPatch 12.1, which is available for download from My Oracle Support patch 6880880 by selecting the release.

Install the latest Opatch Utility

The current installed opatch version available with 12102 is:


Although the current installed opatch version is ok, but I decided to download and install the latest opatch

The latest version is as per:


Download the above opatch and move to both nodes:


To install the latest opatch patch you just need to unzip it under the ORACLE_HOME after deleting the old OPatch directory. Now the installed opatch version is


Windows BP Installation (2 min):

Now follow the following steps to install the Windows BP:

Shut down all instances and listeners associated with the Oracle home that you are updating

  • We don’t have right now, except the following service:


Explicitly stop the “Distributed Transaction Coordinator” service (which is not an Oracle service) if it is running.

  • net stop msdtc


Open CMD window

set ORACLE_HOME=D:\app\pisdb\product\12.1.0\dbhome_1

set PATH=%ORACLE_HOME%\perl\bin;%PATH%

D:\app\pisdb\product\12.1.0\dbhome_1\OPatch\opatch apply


But I got the following errors:

E:\DB12102\22809813>D:\app\pisdb\product\12.1.0\dbhome_1\OPatch\opatch apply

Exception in thread “main” java.lang.NoClassDefFoundError:




I found that there is an extra space on the above ORACLE_HOME setting. It should be:

set ORACLE_HOME=D:\app\pisdb\product\12.1.0\dbhome_1

instead of:

set ORACLE_HOME= D:\app\pisdb\product\12.1.0\dbhome_1

I corrected and run the opatch again:


Bundle Patch was applied successfully.

Check the installed patches:

D:\app\pisdb\product\12.1.0\dbhome_1\OPatch\opatch lsinv


Install Oracle Database 12c on Node2


Repeat the same steps done above at Node1 on Node2

Although, it should be safe to install 12c while the 11gR2 database is running on Node2, I decided to switchover the database and cluster to Node1, while installing on Node2.

Upgrade the Oracle Database to 12c

Run the Pre-Upgrade Information Tool (preupgrd.sql)

Copy preupgrd.sql and utluppkg.sql from the D:\app\oinstall\product\12.1.0\dbhome_1\rdbms\admin directory to C:\temp


set ORACLE_HOME=C:\app\Administrator\product\11.2.0\dbhome_1



cd c:\temp

sqlplus / as sysdba


A subdirectory or file C:\app\Administrator\product\11.2.0\dbhome_1\rdbms\log\ already exists.

Loading Pre-Upgrade Package…


Executing Pre-Upgrade Checks in PIS…


====>> ERRORS FOUND for PIS <<====

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.


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 PIS <<====


  1. Review results of the pre-upgrade checks:


  1. Execute in the SOURCE environment BEFORE upgrade:


  1. Execute in the NEW environment AFTER upgrade:



Pre-Upgrade Checks in PIS Completed.




SQL> @C:\app\Administrator\cfgtoollogs\PIS\preupgrade\preupgrade_fixups.sql

Pre-Upgrade Fixup Script Generated on 2016-05-23 11:52:15  Version: Build: 012

Beginning Pre-Upgrade Fixups…

Executing in container PIS


Check Tag:     EM_PRESENT

Check Summary: Check if Enterprise Manager is present

Fix Summary:   Execute emremove.sql prior to upgrade.


Fixup Returned Information:

WARNING: –> Enterprise Manager Database Control repository found in the database

In Oracle Database 12c, Database Control is removed during

the upgrade. To save time during the Upgrade, this action

can be done prior to upgrading using the following steps after

copying rdbms/admin/emremove.sql from the new Oracle home

– Stop EM Database Control:

$> emctl stop dbconsole

– Connect to the Database using the SYS account AS SYSDBA:




Without the set echo and serveroutput commands you will not

be able to follow the progress of the script.



Check Tag:     AMD_EXISTS

Check Summary: Check to see if AMD is present in the database

Fix Summary:   Manually execute ORACLE_HOME/oraolap/admin/catnoamd.sql script to remove OLAP.


Fixup Returned Information:

INFORMATION: –> OLAP Catalog(AMD) exists in database

Starting with Oracle Database 12c, OLAP Catalog component is desupported.

If you are not using the OLAP Catalog component and want

to remove it, then execute the

ORACLE_HOME/olap/admin/catnoamd.sql script before or

after the upgrade.




Check Summary: Check that recycle bin is empty prior to upgrade

Fix Summary:   The recycle bin will be purged.


Fixup Succeeded




Check Summary: Check that APEX will need to be upgraded.

Fix Summary:   Oracle Application Express can be manually upgraded prior to database upgrade.


Fixup Returned Information:

INFORMATION: –> Oracle Application Express (APEX) can be

manually upgraded prior to database upgrade

APEX is currently at version and will need to be  upgraded to APEX version 4.2.5 in the new release.

Note 1: To reduce database upgrade time, APEX can be manually upgraded outside of and prior to database upgrade.

Note 2: See MOS Note 1088970.1 for information on APEX installation upgrades.



[Pre-Upgrade Recommendations]



********* Dictionary Statistics *********


Please gather dictionary statistics 24 hours prior to upgrading the database.

To gather dictionary statistics execute the following command while connected as SYSDBA:

EXECUTE dbms_stats.gather_dictionary_stats;



************* Fixup Summary ***********

1 fixup routine was successful.

3 fixup routines returned INFORMATIONAL text that should be reviewed.

**************** Pre-Upgrade Fixup Script Complete *********************

So, based on the outcome from the preupgd.sql script, I’m going to take the following actions:

  • Remove the EM:

Copy the D:\app\pisdb\product\12.1.0\dbhome_1\rdbms\admin\emremove.sql to c:\temp

emctl stop dbconsole

sqlplus / as sysdba





  • Remove the OLAP Catalog component as follows:


Where ORACLE_HOME here is referring to the 11g home


  • Purge Recyclebin è already done by the sql script
  • Gather dictionary statistics:

EXECUTE dbms_stats.gather_dictionary_stats;

  • There are 181 invalid objects (non-sys objects)


select owner,object_type,count(*) from sys.registry$nonsys_inv_objs group by owner,object_type order by owner,object_type;

Compile invalid objects:


This reduced the number of invalid objects from 181 to 98



I will run the preupgrd.sql script again after the above fixes:


Now there is no errors

Remove the database from the Fail Safe Configuration

On Node1, from the “Fail Safe” Manager:



Now the group contains the following resources:56

Now, the Oracle services on Node1 looks as follows:


and, the Oracle services on Node2 looks as follows:



Upgrade the Database using the DBUA

Take another final offline backup for the database.

Start > Programs > Oracle-HOME_NAME > Configuration and Migration Tools >Database Upgrade Assistant.

{{Take care: Start the DBUA from the new oracle home 12c, not that of 11g!!}}596061626364656667

I asked to create a new non-default listener , until we register with the FS listener.


M:\ is the shared storage


Actually we are using pfile with FS not spfile

I clicked “Abort” in the above dialog

I created spfile from pfile:


It looks it continued successfully after that!




Upgrade Results

Database upgrade has been completed successfully, and the database is ready to use.

Source Database Target Database
Oracle Home: c:\app\administrator\product\11.2.0\dbhome_1 D:\app\pisdb\product\12.1.0\dbhome_1

Pre-Upgrade Checks

Database contains INVALID objects prior to upgrade. The list of invalid SYS/SYSTEM objects was written to registry$sys_inv_objs. The list of non-SYS/SYSTEM objects was written to registry$nonsys_inv_objs unless there were over 5000. Use utluiobj.sql after the upgrade to identify any new invalid objects due to the upgrade.
Oracle Application Express (APEX) can be manually upgraded prior to database upgrade.

Upgrade Details

The following summary lists the steps performed during the upgrade process. Log files for all the steps, as well as this summary, are available at “D:\app\pisdb\cfgtoollogs\dbua\PIS\upgrade1”.

Step Name Log File Name Status
Database Backup Backup.log Successful
Pre Upgrade PreUpgrade.log Successful
RDBMS Upgrade Oracle_Server.log Successful
Post Upgrade PostUpgrade.log Successful
Enterprise Manager Configuration emConfigUpgrade.log Successful
Timezone Upgrade UpgradeTimezone.log Successful
Generate Summary generateSummary.log Successful

Step Execution Information:

Database Backup
ORA-01565: error in identifying file ‘%ORACLE_HOME%\DATABASE\SPFILE%ORACLE_SID%.ORA’ORA-27041: unable to open file
The Database can be restored by running the following script “M:\Oracle\PIS\FLASH_RECOVERY_AREA\PIS\PIS_restore.bat” from the backup location.NOTE: This operation will remove all the upgrade changes made by the Database Upgrade Assistant.
Post Upgrade
A persistent initialization parameter file (spfile) has been created at the following location: D:\app\pisdb\product\12.1.0\dbhome_1\database\spfilePIS.ora.
Enterprise Manager Configuration
The Database will be managed by Enterprise Manager Database Express.
Timezone Upgrade
The time zone version and TIMESTAMP WITH TIME ZONE data of the Database has been successfully upgraded from version 14 to version 18.

Initialization Parameter changes

The following changes have been made in the initialization parameters:
Parameters Added:
Name Value
pga_aggregate_limit 2147483648
Parameters Updated:
Name Old Value New Value
diagnostic_dest C:\APP\ADMINISTRATOR D:\app\pisdb
Parameters Commented:
Name Value

Now Oracle services at Node1 looks like:

As a validation:

Post Upgrade Tasks

As a post upgrade steps:

  • Collect fixed objects statistics:


  • Change the database to run in archivelog mode(This is independent of the upgrade process):
  • Compile invalid objects again:


  • Testing the EM Database Express 12c connection:



Looks like it is working (from iexplorer, but has some issues with Chrome)

Verify the 12c Standby Database

Now it is the time to bring back our database to the cluster umbrella. The first step is to validate this database from the “Fail Safe Manager”.

Before doing that, and as I had bad experience configuring database with spfile with Fail Safe, I’m going to create a pfile from the current spfile and put it on the shared storage.

Backup the old pfile/spfile(s)

Sqlplus / as sysdba

Create pfile=’M:\Oracle\PIS\Database\initPIS.ora’ from spfile;


Now run the “Fail Safe Manager” to verify the standalone database:


It failed as expected, as the database was started using a local spfile.

As another test case I moved the spfile to the shared storage and created a new pfile in the shared storage also that contains the following line:


I stopped the database and started it again with the above pfile/spfile that reside on the shared storage.


Now I’ll try to validate the standalone database again:


The validation passed.

Add the database back into the group


I doubt that the above error is due to the referring to spfile, but to isolate this point, I deleted the one-line file init.ora file and used the original pfile, and I’ll not use any spfile at this stage.

Restart the database with the pfile:



Server parameter files (spfile) are now required to be stored on a shared disk. The text parameter file (pfile) must contain a spfile reference to the server parameter file. The text parameter file may be stored on a local disk if there are node specific parameters that need to be set. In general, unless there is a need to use different parameters on different cluster nodes, Oracle suggests storing the text parameter file on a shared disk.

Revalidate the standalone database


Now try to add the database to the group, following the same above steps:
I got the following error:

0x523: The name provided is not a properly formed account name

As I mentioned earlier this error was due to using local windows owner as the oracle software owner, after using a domain user, I was able to add the database successfully to the Fail Safe Group.



Fail Safe Tutorial

Database Upgrade Guide

 -Oracle® Fail Safe Concepts and Administration Guide

Release 4.1.1

for Microsoft Windows



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s