How To Deinstall/Uninstall Oracle Home In 11gR2

From 11gR2, de-installing Oracle Home should be done by deinstall tools provided separately. De-installation from 11.2 OUI is desupported.   Please note the following text taken from the 11.2 Installation guides under:

Caution:
When you run the deinstall command, if the central inventory (oraInventory) contains no
other registered homes besides the home that you are deconfiguring and removing, then the
deinstall command removes the following files and directory contents in the Oracle base directory of the Oracle Database installation owner:

 admin

 cfgtoollogs

 checkpoints

 diag

 oradata

 flash_recovery_area

Oracle strongly recommends that you configure your installations using an
Optimal Flexible Architecture (OFA) configuration, and that you reserve Oracle base and
Oracle home paths for exclusive use of Oracle software. If you have any user data in
these locations in the Oracle base that is owned by the user account that owns the Oracle
software, then the deinstall command deletes this data.

It is also suggested that before doing a deinstall on a server where more than one ORACLE_HOME exists there are a valid set of backups for the ORACLE_HOMEs, databases, and oraInventory.

Official documentation presents two methods to remove Oracle Database software:

1) External de-install utility downloadable from OTN ***Recommended method***

It is advised to use the external De-install utility that is downloadable from OTN as currently there are some open bugs with the deinstall script.

To get the external tool :

http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html

Under Oracle Database 11g Release 2, click See All for the respective platform for which you want to download the De-install utility.

If the intent is to deinstall 11.2.0.1 or 11.2.0.2 then you should use the latest version of the 11.2 deinstall utility, which would be version 11.2.0.3.0.

The De-install utility is available for download from the following links:

Microsoft Windows (32-bit)

Microsoft Windows (x64)

Linux x86

Linux x86-64

Solaris (SPARC) (64-bit)

Solaris (x86-64)

HP-UX Itanium

HP-UX PA-RISC (64-bit)

AIX (PPC64) 

2) Deinstall script located inside Oracle Home (It is highly recommended not use the $ORACLE_HOME deinstall utility for versions 11.2.0.1 and 11.2.0.2, Download an use the 11.2.0.3.0 version):

$ORACLE_HOME/deinstall/deinstall (unix/linux platforms)

%ORACLE_HOME%\deinstall\deinstall.bat (windows platforms)

3) It is possible to run the deinstall utility without doing the deinstall to confirm the deinstall will remove what is expected and allow any potential problems to be sorted out by running the following command:

$ /<path to location of deinstall utility>/deinstall/deinstall -home <path to ORACLE_HOME that is to be removed> -checkonly (unix/linux platforms)

% \<path to location of deinstall utility>\deinstall\deinstall -home <path to ORACLE_HOME that is to be removed> -checkonly (WINDOWS platform)

The logs can be found in one of the locations noted in the LOG LOCATION section below.

This will also generate a parameter file that can be used with interactive or silent deinstall.  The parameter file will be generated in the /<path to location of deinstall utility>/deinstall/response directory.

De-installing Oracle Home using external de-install utility

If Oracle Home deinstall script has some issue and you want to deinstall home then you can download separate de-install utility from OTN and use it.

1. Download and unzip de-install utility in some folder outside Oracle Home.

2. Go to the deinstall folder.

3. Invoke deinstall utility with the -home option specifying the full path of the Oracle Home you want to deinstall.

Example:

$./deinstall -home /data/oracle/app/oracle/product/11.2.0/db_1

4. If you want to do a non-interactive deinstall you can use the -silent option with a parameter file.

Example:

[oracle@NVMBD1BZY150D00 ~]$ cd $ORACLE_HOME

[oracle@NVMBD1BZY150D00 db_1]$ cd deinstall/

[oracle@NVMBD1BZY150D00 deinstall]$ ./deinstall

Checking for required files and bootstrapping ...

Please wait ...

Location of logs /tmp/deinstall2014-12-11_11-21-08AM/logs/

############ ORACLE DEINSTALL & DECONFIG TOOL START ############

######################### CHECK OPERATION START #########################

## [START] Install check configuration ##

Checking for existence of the Oracle home location /data/oracle/app/oracle/product/11.2.0/db_1

Oracle Home type selected for deinstall is: Oracle Single Instance Database

Oracle Base selected for deinstall is: /data/oracle/app/oracle

Checking for existence of central inventory location /data/oracle/app/oraInventory

Checking for sufficient temp space availability on node(s) : 'NVMBD1BZY150D00'

## [END] Install check configuration ##

Network Configuration check config START

Network de-configuration trace file location: /tmp/deinstall2014-12-11_11-21-08AM/logs/netdc_check2014-12-11_11-21-13-AM.log

Specify all Single Instance listeners that are to be de-configured [LISTENER]:

Network Configuration check config END

Database Check Configuration START

Database de-configuration trace file location: /tmp/deinstall2014-12-11_11-21-08AM/logs/databasedc_check2014-12-11_11-21-17-AM.log

Use comma as separator when specifying list of values as input

Specify the list of database names that are configured in this Oracle home [TESTDB]:

###### For Database 'TESTDB' ######

Single Instance Database

The diagnostic destination location of the database: /data/oracle/app/oracle/diag/rdbms/testdb

Storage type used by the Database:

The details of database(s) TESTDB have been discovered automatically. Do you still want to modify the details of TESTDB database(s)? [n]:

Database Check Configuration END

Enterprise Manager Configuration Assistant START

EMCA de-configuration trace file location: /tmp/deinstall2014-12-11_11-21-08AM/logs/emcadc_check2014-12-11_11-21-21-AM.log

Checking configuration for database TESTDB

Enterprise Manager Configuration Assistant END

Oracle Configuration Manager check START

OCM check log file location : /tmp/deinstall2014-12-11_11-21-08AM/logs//ocm_check3625.log

Oracle Configuration Manager check END

######################### CHECK OPERATION END #########################

####################### CHECK OPERATION SUMMARY #######################

Oracle Home selected for deinstall is: /data/oracle/app/oracle/product/11.2.0/db_1

Inventory Location where the Oracle home registered is: /data/oracle/app/oraInventory

Following Single Instance listener(s) will be de-configured: LISTENER

The following databases were selected for de-configuration : TESTDB

Database unique name : TESTDB

Storage used :

No Enterprise Manager configuration to be updated for any database(s)

No Enterprise Manager ASM targets to update

No Enterprise Manager listener targets to migrate

Checking the config status for CCR

Oracle Home exists with CCR directory, but CCR is not configured

CCR check is finished

Do you want to continue (y - yes, n - no)? [n]: Y

A log of this session will be written to: '/tmp/deinstall2014-12-11_11-21-08AM/logs/deinstall_deconfig2014-12-11_11-21-12-AM.out'

Any error messages from this session will be written to: '/tmp/deinstall2014-12-11_11-21-08AM/logs/deinstall_deconfig2014-12-11_11-21-12-AM.err'

######################## CLEAN OPERATION START ########################

Enterprise Manager Configuration Assistant START

EMCA de-configuration trace file location: /tmp/deinstall2014-12-11_11-21-08AM/logs/emcadc_clean2014-12-11_11-21-21-AM.log

Updating Enterprise Manager ASM targets (if any)

Updating Enterprise Manager listener targets (if any)

Enterprise Manager Configuration Assistant END

Database de-configuration trace file location: /tmp/deinstall2014-12-11_11-21-08AM/logs/databasedc_clean2014-12-11_11-21-29-AM.log

Database Clean Configuration START TESTDB

This operation may take few minutes.

Database Clean Configuration END TESTDB

Network Configuration clean config START

Network de-configuration trace file location: /tmp/deinstall2014-12-11_11-21-08AM/logs/netdc_clean2014-12-11_11-21-41-AM.log

De-configuring Single Instance listener(s): LISTENER

De-configuring listener: LISTENER

    Stopping listener: LISTENER

    Listener stopped successfully.

    Deleting listener: LISTENER

    Listener deleted successfully.

Listener de-configured successfully.

De-configuring Listener configuration file...

Listener configuration file de-configured successfully.

De-configuring Naming Methods configuration file...

Naming Methods configuration file de-configured successfully.

De-configuring Local Net Service Names configuration file...

Local Net Service Names configuration file de-configured successfully.

De-configuring backup files...

Backup files de-configured successfully.

The network configuration has been cleaned up successfully.

Network Configuration clean config END

Oracle Configuration Manager clean START

OCM clean log file location : /tmp/deinstall2014-12-11_11-21-08AM/logs//ocm_clean3625.log

Oracle Configuration Manager clean END

Setting the force flag to false

Setting the force flag to cleanup the Oracle Base

Oracle Universal Installer clean START

Detach Oracle home '/data/oracle/app/oracle/product/11.2.0/db_1' from the central inventory on the local node : Done

Delete directory '/data/oracle/app/oracle/product/11.2.0/db_1' on the local node : Done

Delete directory '/data/oracle/app/oraInventory' on the local node : Done

The Oracle Base directory '/data/oracle/app/oracle' will not be removed on local node. The directory is not empty.

Oracle Universal Installer cleanup was successful.

Oracle Universal Installer clean END

## [START] Oracle install clean ##

Clean install operation removing temporary directory '/tmp/deinstall2014-12-11_11-21-08AM' on node 'NVMBD1BZY150D00'

## [END] Oracle install clean ##

######################### CLEAN OPERATION END #########################

####################### CLEAN OPERATION SUMMARY #######################

Successfully de-configured the following database instances : TESTDB

Following Single Instance listener(s) were de-configured successfully: LISTENER

Cleaning the config for CCR

As CCR is not configured, so skipping the cleaning of CCR configuration

CCR clean is finished

Successfully detached Oracle home '/data/oracle/app/oracle/product/11.2.0/db_1' from the central inventory on the local node.

Successfully deleted directory '/data/oracle/app/oracle/product/11.2.0/db_1' on the local node.

Successfully deleted directory '/data/oracle/app/oraInventory' on the local node.

Oracle Universal Installer cleanup was successful.

Run 'rm -rf /etc/oraInst.loc' as root on node(s) 'NVMBD1BZY150D00' at the end of the session.

Run 'rm -rf /opt/ORCLfmap' as root on node(s) 'NVMBD1BZY150D00' at the end of the session.

Oracle deinstall tool successfully cleaned up temporary directories.

#######################################################################

############# ORACLE DEINSTALL & DECONFIG TOOL END #############

[oracle@NVMBD1BZY150D00 deinstall]$

We can also use following parameters while using deinstall utility.

./deinstall -home complete path of Oracle home [-silent] [-checkonly] [-local]

[-cleanupOBase] [-paramfile complete path of input parameter property file] [-params name1=value name2=value . . .]

[-o complete path of directory for saving files] [-help]

5. Check the logs created under <central_inventory>/logs folder for any issue.

6. Check the inventory is updated properly.

7. Check if Oracle Home folder is deleted or not. If not then you have to remove it manually.

LOG LOCATION

- deinstall tool creates logs as per this logic:

a) If there are other oracle home (OUI based) in this Host except one which you are installing then it will create log under <central_inventory>/log folder.

b) If this is last Oracle Home to be deinstalled then current central inventory will also get deleted along with deinstall , therefore in this case it will choose log locations in the following order:

- It will create log directory in current location where deinstall utility is launched.

- If current folder is not writable or remotely mounted (permission issues) then it will create user home directory (/home/oracle) as next option.

- If all criteria above is not met then it will proceed to create log directory under user TEMP location (/tmp).

by following the

I hope this article helped you. Your suggestions/feedback are most welcome.

Keep learning... Have a great day!!!

Switchover of Databases (Primary to standby and standby to primary)

A switchover is a role reversal between the primary database and one of its standby databases. A switchover guarantees no data loss. This is typically done for planned maintenance of the primary system. During a switchover, the primary database transitions to a standby role, and the standby database transitions to the primary role.
Setup physical standby database

After completing physical standby database creation.

standby database creation

Follow below steps to switchover database from primary to standby and vice versa

SETUP:

PRIMARY (Primary Database with connection string as “TESTDB”)

[oracle@NVMBD1BZY150D00 301214]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Mon Jan 5 15:33:44 2015

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> select instance_name,status,database_role from v$database,v$instance;

 

INSTANCE_NAME    STATUS       DATABASE_ROLE

---------------- ------------ ----------------

TESTDB           OPEN         PRIMARY

STANDBY (Secondary Database with connection string as “STANDBY”)

SQL> select instance_name,status,database_role from v$database,v$instance;

 INSTANCE_NAME    STATUS       DATABASE_ROLE

---------------- ------------ ----------------

STANDBY          OPEN         PHYSICAL STANDBY

 

Archivelog Destination 1 of Primary Database is “/data1/archive/testdb” and Archivelog destination 2 of Primary database is pointing to the service-name of the standby database.

Archivelog Destination 1 of PRIMARY:

SQL> sho parameter log_archive_dest_1

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

log_archive_dest_1                   string      LOCATION=/data1/archive/testdb VALID_

                                                 FOR= (ALL_LOGFILES, ALL_ROLES) D

                                                 B_UNIQUE_NAME=TESTDB

Archivelog Destination 2 of PRIMARY:

SQL> sho parameter log_archive_dest_2

 NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

log_archive_dest_2                   string      SERVICE=STANDBY VALID_FOR=(ONL

                                                 INE_LOGFILES, PRIMARY_ROLE) DB_

                                                 UNIQUE_NAME=STANDBY

Archivelog Destination 1 of Standby database is “/data1/archive/STANDB” and archivelog destination 2 of standby database is pointing to the service-name of the primary database. (Note: destination 2 in standby database is not mandatory. It is required only if the standby database would be running in as primary database during switchover or failover. Hence it would be a good practice to set this parameter to avoid problems during the switchover or failover.)

Archive log destination 1 of STANDBY:

SQL> sho parameter log_archive_dest_1

 

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

log_archive_dest_1                   string      LOCATION=/data1/archive/STANDB

                                                 Y VALID_FOR=(ALL_LOGFILES,ALL_

                                                 ROLES) DB_UNIQUE_NAME=STANDBY

Archive log destination 2 of STANDBY:

SQL> sho parameter log_archive_dest_2

 

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

log_archive_dest_2                   string      SERVICE=TESTDB VALID_FOR=(ONLI

                                                 NE_LOGFILES,PRIMARY_ROLE) DB_U

                                                 NIQUE_NAME=TESTDB

Pre-Switchover Checks:

These checks will have to be performed before the switchover activity is performed.

Verify whether Managed Recovery process is running on the standby database

Use the following query to check if the managed recovery process is running on the standby database.

SQL> select process,status,sequence# from v$managed_standby;

PROCESS   STATUS        SEQUENCE#

--------- ------------ ----------

ARCH      CLOSING             157
ARCH      CLOSING             155
ARCH      CONNECTED             0
ARCH      CLOSING             156
RFS       IDLE                  0
RFS       IDLE                  0
RFS       IDLE                158
MRP0      WAIT_FOR_LOG        158

The above fig. shows that the Managed Recovery Process (MRP0) is running on the standby database. If MRP is not running, then start the process with real time enabled using the below query in the standby database.

SQL>alter database recover managed standby disconnect from session;

Once when the MRP has started on the standby database, make sure that the archive logs generated at the primary end are shipped and getting applied to the standby database.

At the primary side check the maximum archive log sequence that has got generated:

SQL> select thread#,max(sequence#) from v$archived_log group by thread#;

 THREAD# MAX(SEQUENCE#)

---------- --------------

1                163

          

At the standby side, check the maximum archive log sequence that has been applied from the primary database:

SQL> select thread#,max(sequence#) from v$archived_log group by thread#;

 THREAD# MAX(SEQUENCE#)

---------- --------------

         1            163

In the above case, sequence# 163 is the maximum sequence generated at the primary database and the same has been applied to the standby database.

Verify primary and standby tempfiles match

For each temporary tablespace on the standby, verify that temporary files associated with that tablespace on the primary database also exist on the standby database. Tempfiles added after initial standby creation are not propagated to the standby. Run this query on both the primary and target physical standby databases and verify that they match.

 SQL>select tmp.name filename,bytes,ts.name tablespace from v$tempfile tmp, v$tablespace ts where tmp.ts#=ts.ts#;

 

Verify that all datafiles are online on both primary and standby databases

Check whether all the datafiles are online prior to the switchover on both primary and standby databases

SQL>select name from v$datafile where status=’OFFLINE’;

 On Primary side:

 SQL> select name from v$datafile where status='OFFLINE';

 no rows selected

On Standby side:

SQL> select name from v$datafile where status='OFFLINE';

no rows selected

If there are any offline datafiles, then bring them online using the below query

 

SQL>alter database datafile <datafile name> online;

 Switchover Steps:

 These steps are performed during the switchover process at the primary database side.

 

Check if there are any jobs running on the primary database using the below query.

SQL> select * from dba_jobs_running;

no rows selected

If there are any jobs running on the primary database and if its execution is not very important, then terminate the job to continue further.

 

Block further job submission by setting the job_queue_processes parameter to 0 so that there would be no jobs running during switchover.

SQL> sho parameter job_que

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

job_queue_processes                  integer     1000

In the above fig. the job_queue_processes parameter is set to 1000. Set this parameter to the value 0.

SQL>alter system set job_queue_processes=0 scope=spfile;

System altered

SQL>

Verify that the primary database can be switched over to the standby

Query the switchover_status column of the v$database view on the primary database to determine whether the primary database can be switched over to the standby.

SQL> select switchover_status from v$database;

 SWITCHOVER_STATUS

--------------------

TO STANDBY

A value of TO STANDBY or SESSIONS ACTIVE (which requires the WITH SESSION SHUTDOWN clause on the switchover command) indicates that the primary database can be switched to the standby role. If neither of these values is returned, a switchover is not possible because redo transport is either mis-configured or is not functioning properly.

Switchover the primary database to standby

Once when value of switchover_status returns “TO STANDBY” or “SESSIONS ACTIVE” on the primary database, then perform the switchover using the below query

SQL> select switchover_status from v$database;

 SWITCHOVER_STATUS

--------------------

TO STANDBY

 SQL> alter database commit to switchover to physical standby with session shutdown;

Database altered.

Now the primary database is switched over to the standby database. The execution of the above command may take some time and the archive logs generated during its execution would be automatically applied to the standby database. Once when the command is executed with the output as “Database altered”, it means that the primary database has been switched over to the standby.

Note: Always perform the switchover of the primary database to standby database first and then switchover the standby database to primary. If not, then you would end up landing with two primary databases

Switchover the standby database to primary

Query the switchover_status column from the v$database view at the standby side to determine whether the standby database can be switched over to the primary database.
SQL> select switchover_status from v$database;

SWITCHOVER_STATUS

--------------------

TO PRIMARY

A value of TO PRIMARY or SESSIONS ACTIVE indicates that the standby database is ready to be switched to the primary role. If neither of these values is returned, verify that redo apply is active and that redo transport is configured and working properly. Continue to query this column until the value returned is either TO PRIMARY or SESSIONS ACTIVE.

Once when the value of switchover_status returns “TO PRIMARY” or “SESSIONS ACTIVE” on the standby database, then perform the switchover using the below query

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS

--------------------

TO PRIMARY

SQL> alter database commit to switchover to primary with session shutdown;

Database altered.

Now the standby database has been switched over to the primary database.

Open the new primary database (STANDBY)

The new primary database will be in mount state. Open this new primary database using the below query.

SQL> alter database open;

Database altered.

SQL> select instance_name,status,database_role from v$database,v$instance;

INSTANCE_NAME    STATUS       DATABASE_ROLE

---------------- ------------ ----------------

STANDBY          OPEN         PRIMARY

 

 
Restart the new standby database

Restart the new standby database (old primary database prim), bring it to the mount stage and start the managed recovery process.

Shutdown the new standby database (TESTDB)

SQL>shutdown immediate;

Startup the new standby database (TESTDB) in mount stage

SQL> startup mount;

ORACLE instance started.

 

Total System Global Area  601272320 bytes

Fixed Size                  2230712 bytes

Variable Size             335545928 bytes

Database Buffers          251658240 bytes

Redo Buffers               11837440 bytes

Database mounted

Start the managed recovery process on the the new standby database (TESTDB)

SQL> alter database recover managed standby database disconnect from session;

Database altered.

SQL> select instance_name,status,database_role from v$database,v$instance;

INSTANCE_NAME    STATUS       DATABASE_ROLE

---------------- ------------ ----------------

TESTDB           MOUNTED      PHYSICAL STANDBY

 Post-Switchover tasks

Reset the job_queue_processes parameter to its previous value

Set the job queue processes to its original value on the new standby (TESTDB). 

SQL> sho parameter job_queue_processes

 NAME                                 TYPE        VALUE

----------------------------------- ----------- ------------------------------

job_queue_processes                  integer     1000

 

In the above fig. the job_queue_processes parameter is set to 1000. Set this parameter to the value 0.
SQL>alter system set job_queue_processes=1000 scope=spfile;

System altered

Now the roles of the databases have been changed. The primary database (TESTDB) has been changed to standby database and the standby database (STANDBY) has been changed to primary database.

The archive logs that get generated in the new primary database (STANDBY) get shipped automatically to the new standby database (TESTDB) and they are applied on it automatically.

Maximum archivelog generated at the new primary database (STANDBY)

SQL> select thread#,max(sequence#) from v$archived_log where applied=YES’ group by thread#;

  THREAD# MAX(SEQUENCE#)

---------- --------------

         1            163

Maximum archivelog that has been shipped and applied to the new standby database (TESTDB)

SQL> select thread#,max(sequence#) from v$archived_log where applied=YES’ group by thread#;

    THREAD# MAX(SEQUENCE#)

---------- --------------

         1            163

 

The roles can again be reversed by following the same above procedures.

 

I hope this article helped you. Your suggestions/feedback are most welcome.

Keep learning... Have a great day!!!