Showing posts with label Oracle Patching. Show all posts
Showing posts with label Oracle Patching. Show all posts

Monday, October 16, 2017

set up the OPatch environment variable for Oracle Patching

To set up the OPatch environment variable, you need to add the OPatch directory (located within your Oracle Home) to your system’s PATH variable. This allows you to run OPatch commands directly from any shell prompt without specifying the full path. Below are the steps for setting up the PATH environment variable for both Korn/Bourne shells (like sh, bash, ksh) and C Shell (csh, tcsh).

Setting Up OPatch Environment Variable

  1. For Korn Shell (ksh), Bourne Shell (sh), and Bash Shell:

    Use the export command to modify the PATH variable.

    sh:

    # Add OPatch to the PATH export PATH=$PATH:$ORACLE_HOME/OPatch
    • Explanation:
      • export PATH=$PATH:$ORACLE_HOME/OPatch: This command appends the OPatch directory to the current PATH variable, making the OPatch utility accessible from the command line.
      • $ORACLE_HOME/OPatch: Refers to the OPatch directory within the Oracle Home path.
  2. For C Shell (csh, tcsh):

    Use the setenv command to update the PATH variable.

    csh:

    # Add OPatch to the PATH setenv PATH $PATH:$ORACLE_HOME/OPatch
    • Explanation:
      • setenv PATH $PATH:$ORACLE_HOME/OPatch: This command updates the PATH variable by appending the OPatch directory, allowing OPatch commands to be run without specifying the full path.

Important Notes:

  • Ensure Oracle Home is Set: Before running these commands, make sure the ORACLE_HOME environment variable is correctly set to your Oracle installation path. You can verify it using echo $ORACLE_HOME.
  • Persistent Changes: To make these changes persistent across sessions, add the corresponding command to your shell’s startup file (~/.bash_profile, ~/.profile for Bash/Korn shell or ~/.cshrc for C shell).
  • Verify OPatch: After setting the variable, verify the setup by running opatch version to ensure that the command is accessible and the correct OPatch version is in use.

This setup is crucial for applying patches and managing updates in your Oracle environment effectively using OPatch

Wednesday, September 16, 2015

Oracle Which Patch has been applied?

In the events when you want to know what all patches have been applied to the oracle database, you can just goto oracle_home/opatch and type lsinventory. but you can also do the same by using the below query in the database. 

Which Patch has been applied?

SET linesize 200 pagesize 200
col action_time FOR a28
col version FOR a10
col comments FOR a35
col action FOR a25
col namespace FOR a12

SELECT * FROM registry$history;


ACTION_TIME                  ACTION                    NAMESPACE    VERSION            ID COMMENTS                         BUNDLE_SERIES
---------------------------- ------------------------- ------------ ---------- ---------- ----------------------------------- ------------------------------
24-AUG-13 12.03.45.119862 PM APPLY                     SERVER       11.2.0.4            0 Patchset 11.2.0.2.0              PSU
18-DEC-13 03.15.56.778103 PM APPLY                     SERVER       11.2.0.4            0 Patchset 11.2.0.2.0              PSU
09-NOV-14 05.22.06.808354 PM APPLY                     SERVER       11.2.0.4            4 PSU 11.2.0.4.4                   PSU
08-MAR-15 06.13.17.927522 PM APPLY                     SERVER       11.2.0.4            5 PSU 11.2.0.4.5                   PSU


Which Patch has been installed?

The easies way to list the installed patches in the current ORACLE_HOME is to use the patch utility.
List of installed patches:
$ORACLE_HOME/OPatch/opatch lsinventory

Grep on the patch description:
$ORACLE_HOME/OPatch/opatch lsinventory|grep "Patch description"
Patch description:  "Database Patch Set Update : 11.2.0.3.7 (16619892)"

A more detailed list on the installed patches:
$ORACLE_HOME/OPatch/opatch lsinventory -details

Sunday, September 6, 2015

BACKUP ORACLE HOME AND INVENTORY

BACKUP ORACLE HOME AND INVENTORY

Oracle Home and Inventory Backup
-----------------------------------------
tar -cvf $ORACLE_HOME $ORACLE_HOME/oraInventory | gzip > Backup_Software_Version.tar.gz

Note: 
tar -cvf <destination_location> <source_location>

ORACLE_HOME & ORACLE_CRS_HOME backup’s (for all nodes in RAC)

$ tar -zcvf db_1_bak.tar.gz db_1

$ cd /u01/app/oracle/product/11.2

$ ls -al
total 353532
drwxr-xr-x  3 oracle oinstall      4096 Sep  6 17:32 .
drwxrwxr-x  3 oracle oinstall      4096 Sep 12  2013 ..
drwxr-xr-x 80 oracle oinstall      4096 Jun 11 02:03 db_1
-rw-r--r--  1 oracle oinstall 361627648 Sep  6 17:34 db_1_bak.tar.gz


Controlfile Backup
---------------------
alter database backup controlfile to trace; 

show parameter user_dump_dest
(go to udump dest and make the note of controlfile trace)

Monday, July 14, 2014

Applying CPU Patch On Primary Database Server Environment

 Applying CPU Patch On Primary Database Server Environment.


 Step 1:

Incase if you have standby server. Now disable log shipping on the primary database by setting the log_archive_dest_state_2 to disable. As I said earlier, parameter log_archive_dest_2 on my primary database is set to point to the standby database.

SQL> alter system set log_archive_dest_state_2=disable;

System altered.

Step 2:

Shutdown the Primary database and stop the listener running on the primary database server.

 
[oracle@PRIM ~]$ sqlplus sys/"as sysdba"

SQL*Plus: Release 11.2.0.2.0 Production

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

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, DataMining and Real Application Testing options

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, DataMining and Real Application Testing options

Now Stop the Listener.

[oracle@PRIM ~]$ lsnrctl stop

 [oracle@PRIM ~]$ ps -ef | grep pmon

Step 3:

Now apply the CPU patch on the Primary database.



Set the Opatch path.
[oracle@PRIM ~]$ export $ORACLE_HOME=/u01/app/oracle/product/11.2/db_1
[oracle@PRIM ~]$ export PATH=$PATH:$ORACLE_HOME/OPatch

OPatch Version: 11.2.0.3.0

OPatch succeeded.

[oracle@PRIM ~]$ opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /opt/12827726/
Oracle Interim Patch Installer version 11.2.0.3.0
Copyright (c) 2012, Oracle Corporation. All rights reserved.

PREREQ session
OPatch version : 11.2.0.3.0
OUI version : 11.2.0.2.0
Log file location : /u01/app/oracle/product/11.2.0.2/db1/cfgtoollogs/opatch/opatch2013-05-18_11-56-11AM_1.log

Invoking prereq "checkconflictagainstohwithdetail"

Prereq "checkConflictAgainstOHWithDetail" passed.

OPatch succeeded.

[oracle@PRIM ~]$ export PATH=$PATH:/u01/app/oracle/product/11.2.0.2/db1/OPatch
[oracle@PRIM ~]$ opatch apply /opt/12827726/

 OPatch succeeded.

 Step 4:

Start the listener on the primary database server and also start the Primary database.


[oracle@PRIM ~]$ lsnrctl start

[oracle@PRIM ~]$ sqlplus /"as sysdba"

SQL*Plus: Release 11.2.0.2.0 Production

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

Connected to an idle instance.

SQL> startup

ORACLE instance started.

 Step 5:

Incase if you have standby server. Now enable log shipping on the primary database by setting the log_archive_dest_state_2 to "enable". As I said earlier, parameter log_archive_dest_2 on my primary database is set to point to the standby database.

SQL> alter system set log_archive_dest_state_2=enable;


Step 6:

On the primary database, run the patching scripts like “catbundle.sql” in this case.
The script run generates archives and these archives would be shipped and applied to the standby database. So, there is no requriement to run the patching scripts on the standby database.

[oracle@PRIM ~]$ sqlplus /"as sysdba"

SQL*Plus: Release 11.2.0.2.0 Production

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

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, DataMining and Real Application Testing options

SQL> @?/rdbms/admin/catbundle.sql psu apply

SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)
--------------

Note : Incase if you want to rollback the patch applied:


  1. Verify that an $ORACLE_HOME/rdbms/admin/catbundle_PSU_<database SID>_ROLLBACK.sql file exists for each database associated with this ORACLE_HOME. If this is not the case, you must execute the steps.
  2. Shut down all instances and listeners associated with the Oracle home that you are updating. 
  3. For more information, see Oracle Database Administrator's Guide.

            Run the OPatch utility specifying the rollback argument as follows.

            opatch rollback -id 12827726


Patch Post-Deinstallation Instructions for a Non Oracle RAC Environment

  1. Start all database instances running from the Oracle home. (For more information, see Oracle Database Administrator's Guide.)
  2. For each database instance running out of the ORACLE_HOME, connect to the database using SQL*Plus as SYSDBA and run the rollback script as follows:
    cd $ORACLE_HOME/rdbms/admin
    sqlplus /nolog
    SQL> CONNECT / AS SYSDBA
    SQL> STARTUP
    SQL> @catbundle_PSU_<database SID>_ROLLBACK.sql
    SQL> QUIT
    

Applying CPU Patch in a dataguard (Physical Standby) environment

Here is a brief explanation on how to apply CPU(Critical Patch Update) in a dataguard environment
In this demo, I am applying PSU 11.2.0.4.2 on the Primary and standby databases.

Standby  Database Name :ORCL_STBY
Primary  Database Name : ORCL


Primary Server:

[oracle@PRIM ~]$ sqlplus sys/oracle@srprim as sysdba
SQL*Plus: Release 11.2.0.2.0 Production on Tue Sep 18 10:43:50 2012
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, DataMining and Real Application Testing options
SQL> select status,instance_name,database_role from v$database,v$instance;
STATUS INSTANCE_NAME DATABASE_ROLE
------ ------------- ---------------
OPEN               ORCL            PRIMARY
 Standby Server:

[oracle@STBY~]$ sqlplus /"as sysdba"
SQL*Plus: Release 11.2.0.2.0 Production on Tue Sep 18 10:46:35 2012
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, DataMining and Real Application Testing options
SQL> select status,instance_name,database_role from v$database,v$instance;
STATUS   INSTANCE_NAME        DATABASE_ROLE
-------- --------------           ----------------------
MOUNTED      ORCL_STBY         PHYSICAL STANDBY
 
 Step 1:
As a first step we need to disable the log shipping from primary database to the standby database by setting the log_archive_dest_state_2 to “defer” on the primary database.




SQL> alter system set log_archive_dest_state_2=defer;
System altered.
 Step 2:

Now Cancel the Managed Recovery Process on your standby database .




SQL> alter database recover managed standby database cancel;
Database altered.
 Step 3:

CPU (Critical Patch Update)/ Patch Set patches  always needs to be applied first on the standby database and then on the primary database. In order to apply it on the standby database, shutdown the standby database and also the listener running on the standby server.
 SQL> shutdown immediate
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.

[oracle@STBY ~]$ lsnrctl stop

[oracle@STBY ~]$ ps -ef | grep tns
oracle 6958 5107 0 10:52 pts/1 00:00:00 grep tns

[oracle@STBY ~]$

[oracle@STBY ~]$ ps -ef | grep pmon
oracle 6960 5107 0 10:52 pts/1 00:00:00 grep pmon
 
 Step 4:
Now apply the CPU on the standby database.
[oracle@STBY ~]$ export PATH=$PATH:$ORACLE_HOME/OPatch
[oracle@STBY ~]$ opatch version
OPatch Version: 11.2.0.3.0

OPatch succeeded.
 
Step 5: 

Unzip the downloaded patch file.

unzip p18031668_112040_<platform>.zip 
 

cd 18031668
 
Verify pre-reqs:
opatch prereq CheckConflictAgainstOHWithDetail -ph ./
Now Apply Patch:

opatch apply
 
Step 6: 

Once the patch has been applied on the standby database,
start the listener and the standby database. 

[oracle@uat ~]$ lsnrctl start
 
[oracle@uat ~]$ sqlplus /"As sysdba"

SQL> startup mount
 
 
Step 7:
 
On Primary Database server, Start the archiving.




SQL> alter system set log_archive_dest_state_2=enable;
 System altered.
 
  
Note: Do not run any patching scripts on the standby database (Example: catbundle.sql). 
We are done with the patching on the standby database. 
 
Click on this Link to read further on how to apply CPU Patch On Primary Production Database Server Environment.