Wednesday, 8 July 2015

How to apply cpu patch in oracle 11gr2 RAC

How to apply cpu patch in oracle 11gr2 RAC
Posted: 05 Jul 2015 10:48 PM PDT

What is CPU Patch?


Critical patch update (CPU) patches are cumulative, which means fixes from previous Oracle security alerts and critical patch updates are included.
A Critical Patch Update is a collection of patches for multiple security vulnerabilities. Critical Patch Update patches are usually cumulative but each advisory describes only the security fixes added since the previous Critical Patch Update advisory. Thus, prior Critical Patch Update advisories should be reviewed for information regarding earlier published security fixes.

When is CPU Patches Released?

CPU patches is released 4 times a year.
January, April, July &October.

Information about the latest CPU Patch can be found in the below link

Note: To download the latest CPU patch, one must have a valid oracle support login.

Steps to Apply CPU

Pre-Installation: 
Shutdown all the instance , and oracle services such as listener. 
ensure $PATH variable.
Download Patchand unzip it.
Use the Opatch like this : opatch napply -skip_subset -skip_duplicate.
Startup databas.

Post-Installation :

 cd $ORACLE_HOME/rdbms/admin
sqlplus / as sysdba
SQL> @catbundle.sql cpu apply

***************************************************************************
How to apply it in a RAC Environment?

Applies to:

Operating System – RHEL/OEL 5.8

Oracle Version(s) – 11.2.0.1

Note: Before continue the following step please read the README file from the patch.

Step by step CPU patches Applying:


If you are wish to applying rolling CPU patch on RAC, then the following steps must be following.

Rolling patch (no downtime)
-Shutdown the Oracle instance on node 1
-Apply the patch to the RAC home on node 1
-Start the Oracle instance on node 1
-Shutdown the Oracle instance on node 2
-Apply the patch to the RAC home on node 2
-Start the Oracle instance on node 2
-Shutdown the Oracle instance on node 3
-Apply the patch to the RAC home on node 3
-Start the Oracle instance on node 3

1.Download the CPU patch p12419249_10204_Linux-x86 from Metalink.

2.Change the owner of the patch file to oracle user.
# chown –R oracle: install p12419249_10204_Linux-x86.zip

3.Set the PATH variable to locate the opatch utility.
$ export PATH=$PATH: $ORACLE_HOME/OPatch

4.unzip the patch and go the unzipped directory
$unzip p12419249_10204_Linux-x86.zip

5.Fine the Opatch version
$ opatch version
Invoking OPatch 10.2.0.4.2
OPatch Version: 10.2.0.4.2
$ opatch lsinventory
Note: if you want check the CPU patch is whether rolling support or not, follow the steps.
-go to the patch directory
Cd /oracle/12419249
[oracle@rac1 12419249]$ opatch query -all
Invoking OPatch 10.2.0.4.2
Oracle Interim Patch Installer version 10.2.0.4.2
Copyright (c) 2007, Oracle Corporation.  All rights reserved.
Oracle Home                  : /oracle/product/10.2.0/rdbms
Central Inventory           : /oracle/product/10.2.0/oraInventory
from                             : /etc/oraInst.loc
OPatch version               : 10.2.0.4.2
OUI version                    : 10.2.0.4.0
OUI location                   : /oracle/product/10.2.0/rdbms/oui
Log file location              : /oracle/product/10.2.0/rdbms/cfgtoollogs/opatch/opatch2011-05-01_08-55-20AM.log
-------------------------------------------------------------------------------- 
Patch created on 20 May 2011, 03:02:21 hrs PST8PDT
Need to shutdown Oracle instances: false      (<--hear false mean we no need to down the database)
 Patch is roll-backable: true
 Patch is a rolling patch: true
 Patch has sql related actions: false
 Patch is an online patch: false
 Patch is a portal patch: false
 List of platforms supported:
 46: Linux Intel
 List of bugs to be fixed:
 8534387: CPUJUL2009 DATABASE 10.2.0.4
 8290506: CPUAPR2009 DATABASE 10.2.0.4
 7375644: MLR BUG FOR 10.2.0.4 FOR CPUOCT2008
 9352191: CPUAPR2010 DATABASE 10.2.0.4
 9655017: CPUJUL2010 DATABASE 10.2.0.4
 7150470: MLR BUG FOR 10.2.0.4 FOR CPUJUL2008
 7592346: CPUJAN2009 DATABASE 10.2.0.4
 9952272: CPUOCT2010 DATABASE 10.2.0.4
 9119226: CPUJAN2010 DATABASE 10.2.0.4
 11725015: CPUAPR2011 DATABASE 10.2.0.4
 12419249: CPUJUL2011 DATABASE 10.2.0.4
 8836308: CPUOCT2009 DATABASE 10.2.0.4
 10249540: CPUJAN2011 DATABASE 10.2.0.4
 List of optional components:
 oracle.rdbms.rsf  :  10.2.0.4.0
 oracle.rdbms       :  10.2.0.4.0
6.Backup the oraInventory  and Opatch directory
$cp -R oraInventory old_oraInventory
$cp -R opatch old_opatch
7.If you are Applying on RAC, follow the below steps:
Shut down the instance one of node
$ srvctl stop instance -d racdb –i racdb1
Shut down the ASM instanc respected node
$ srvctl stop asm -n rac1
Shut down all Nodeapps services of the node
$ srvctl stop ndoeapps -n rac1
8.Go to the Patch Directory and invoke opatch apply.
$ cd 12419249
$opatch apply or $opatch napply -skip_subset -skip_duplicate
9.Verify Patches are applied
$opatch lsinventory -detail -oh $ORACLE_HOME
10.Now start the Node1 and repeat the same 1 to 10 steps on Node2
$ srvctl start nodeapps –n rac1
$srvctl start asm –n rac1
$srvctl start instance –d racdb –i racdb1
Note: if the database on rac1 located, now relocate to node2
crs_relocate ora.racdb.db
11.Now stop Instance,asm and nodeapps on node2
$ srvctl stop instance –d racdb –i racdb2
$ srvctl stop asm –n rac2
$ srvctl stop nodeapps –n rac2
12.Go to the Patch Direcotry and invoke the opatch apply on node2
$ cd 12419249
$ opatch apply or opatch napply -skip_subset -skip_duplicate 
     13.Verify Patches are applied 
          $opatch lsinventory -detail -oh $ORACLE_HOME
     14.Start  the Instance,Asm and Nodeapps on node2
$srvctl start instance –d racdb –i racdb2
$srvctl start asm –n rac2
$srvctl start nodeapps –n rac2
$crs_stat –t 

Post CPU installation Steps:

For each database instance running on the Oracle home being patched, connect to the database using SQL*Plus on each node.

Connect as SYSDBA and run the catbundle.sql script as follows:
On node1 and node2:

cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP
SQL> @catbundle.sql cpu apply
SQL> @utlrp.sql
SQL> QUIT
The catbundle.sql execution is reflected in the dba_registry_history view by a row associated with bundle series CPU.
For information about the catbundle.sql script, see My Oracle Support Note 605795.1Introduction to Oracle Database catbundle.sql.
Check the following log files in $ORACLE_HOME/cfgtoollogs/catbundle for any errors:
catbundle_CPU__APPLY_.log
catbundle_CPU__GENERATE_.log

Recompiling Views in the Database
You may skip this section if you have recompiled views for this database during the installation of a previous CPU.
The time required to recompile the views and related objects depends on the total number of objects and on your system configuration. 
In one internal Oracle test with approximately 2000 views and 4000 objects, the total execution time for view_recompile_jan2008cpu.sql and utlrp.sql was about 30 minutes.
If you want to check whether view recompilation has already been performed for the database, execute the following statement.
SELECT * FROM registry$history where ID = '6452863';
If the view recompilation has been performed, this statement returns one or more rows. If the view recompilation has not been performed, this statement returns no rows. If no rows returns then go the following steps.
The following steps recompile the views in the database. For a RAC environment, perform these steps on only one node.

 Run the pre-check script (so named because it was initially released in CPUJan2008), which reports the maximum number of views and objects that may be recompiled:
cd $ORACLE_HOME/cpu/view_recompile
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> @recompile_precheck_jan2008cpu.sql
SQL> QUIT
The purpose of this step is to help you determine whether view recompilation should be done at the same time as the CPU install, or scheduled later.
Note:
 If the database is not in a RAC environment(if Single Instance), perform this step and skip the next step 2. (If the database is in a RAC environment, go to the next step2.)
Run the view recompilation script, note that this script is run with the database in upgrade mode, which restricts connections as SYSDBA.
cd $ORACLE_HOME/cpu/view_recompile
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP UPGRADE
SQL> @view_recompile_jan2008cpu.sql
SQL> SHUTDOWN;
SQL> STARTUP;
SQL> QUIT

If the database is in a RAC environment, run the view recompilation script as follows, note that this script is run with the database in upgrade mode, which restricts connections as SYSDBA. Stop all instances except the one where the view recompilation is being executed.
cd $ORACLE_HOME/cpu/view_recompile
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP NOMOUNT
SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=spfile;
SQL> SHUTDOWN
SQL> STARTUP UPGRADE
SQL> @?/ cpu/view_recompile /view_recompile_jan2008cpu.sql
SQL> SHUTDOWN;
SQL> STARTUP NOMOUNT;

Set the CLUSTER_DATABASE initialization parameter to TRUE:
SQL> ALTER SYSTEM SET CLUSTER_DATABASE=TRUE SCOPE=spfile;
Restart the database:
SQL> QUIT
cd $CRS_HOME/bin

srvctl start database -d racdb
If any invalid objects were reported, run the utlrp.sql script as follows:
cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> @utlrp.sql
Then, manually recompile any invalid objects. For example:
SQL> alter package schemaname.packagename compile;

 Verify Patches are applied.
$opatch lsinventory -detail -oh $CRS_HOME #if you have CRS_HOME
$opatch lsinventory -detail -oh $ORACLE_HOME #if you have both ORACLE_HOME

  The CPU patch was successfully applied.

*****************************END*************************************

Tuesday, 26 May 2015

How To Permanently Change The Linux IP Address Manually?

1. Setting the IP
/etc/sysconfig/network-scripts/ifcfg-eth0

2. Setting the DNS
/etc/resolv.conf
/etc/hosts

3. Setting the Router
/etc/sysconfig/network

4. Restart the network
/etc/rc.d/init.d/network restart

Oracle Metalink Notes for Oracle Apps DBA

Here are the list of Oracle Metalink Notes, I do refer regularly. Moreover, these are very informative. So, I thought of sharing those note ids here with you.

Note: You have to have an account in Oracle Metalink to access notes.

Installation

Note: 452120.1 - How to locate the log files and troubleshoot RapidWiz for R12
Note: 329985.1 - How to locate the Rapid Wizard Installation log files for Oracle Applications 11.5.8 and higher
Note: 362135.1 - Configuring Oracle Applications Release 11i with Oracle10g...

How to check the Physical RAM and Swap Space in Unix/Linux Systems.

Following are the most requred OS commands while installing and configuring Oracle Software on Unix/Linux Operating Systems.

Operating System: AIX 5L Based Systems (64-Bit)
Physical RAM: # /usr/sbin/lsattr -E -l sys0 -a realmem
Swap Space: # /usr/sbin/lsps -a

Operating System: HP Tru64 UNIX
PPhysical RAM: # /bin/vmstat -P grep "Total Physical Memory"
Swap Space: # /sbin/swapon -s

Operating System: HP-UX Itanium
Physical RAM: # /usr/contrib/bin/machinfo grep -i Memory
Swap Space: # /usr/sbin/swapinfo -a

Operating System: HP-UX PA-RISC (64-Bit)
Physical RAM: # grep "Physical:" /var/adm/syslog/syslog.log
Swap Space: # /usr/sbin/swapinfo -a

Operating System: IBM zSeries Based Linux, LinuxItanium/POWER/x86/x86-64
Physical RAM: # grep MemTotal /proc/meminfo
Swap Space: # grep SwapTotal /proc/meminfo

Operating System: Solaris SPARC 64-Bit/x86/x86-64
Physical RAM: # /usr/sbin/prtconf grep "Memory size"
Swap Space: # /usr/sbin/swap -s

Saturday, 4 April 2015

RMAN - Sample Backup Scripts 10g (ID 397315.1)

Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 10.2.0.1 - Release: 10.1 to 10.2
Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 10.2.0.5.0 [Release: 10.1 to 10.2]

Information in this document applies to any platform.

Goal

Audience: Novice RMAN users.

The following note provides a DBA with several RMAN sample backup scripts. The scripts are very basic and an be executed as shown in examples.
Solution

RMAN - Sample Backup Scripts 10g

• Backup up Whole Database Backups with RMAN
• Backing up Individual Tablespaces with RMAN
• Backing up Individual Datafiles and Datafile Copies with RMAN
• Backing up Control Files with RMAN
• Backing up Server Parameter Files with RMAN
• Backing up Archived Redo Logs with RMAN
• Backing up the Whole database including archivelogs
=================================================================================

Making Whole Database Backups with RMAN

You can perform whole database backups with the database mounted or open. To perform a whole database backup from the RMAN prompt the BACKUP DATABASE command can be used. The simplest form of the command requires no parameters, as shown in this example:

RMAN> backup database;
In the following example no backup location was specified meaning that the backups will automatically be placed in the Flash Recovery Area (FRA). If the FRA has not been setup then all backups default to $ORACLE_HOME/dbs.

How to check if the RFA has been setup:

SQL> show parameter recovery_file_dest

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /recovery_area
db_recovery_file_dest_size big integer 50G

If your FRA is not setup (ie values are null) please refer to the following note for assistance in setting it up.

Note 305648.1 What is a Flash Recovery Area and how to configure it ?

If you wish to place your backup outside the FRA then following RMAN syntax may be used.

RMAN> backup database format '/backups/PROD/df_t%t_s%s_p%p';

Backing Up Individual Tablespaces with RMAN

RMAN allows individual tablespaces to be backed up with the database in open or mount stage.

RMAN> backup tablespace SYSTEM, UNDOTBS, USERS;

Backing Up Individual Datafiles and Datafile Copies with RMAN

The flexibilty of being able to backup a single datafile is also available. As seen below you are able to reference the datafile via the file# or file name. Multiple datafiles can be backed up at a time.

RMAN> backup datafile 2;

RMAN> backup datafile 2 format '/backups/PROD/df_t%t_s%s_p%p';

RMAN> backup datafile 1,2,3,6,7,8;

RMAN> backup datafile '/oradata/system01.dbf';

Backing Up the current controlfile & Spfile 

The controlfile and spfile are backed up in similar ways. Whenever a full database backup if performed, the controlfile and spfile are backed up. In fact whenever file#1 is backed up these two files are backed up also.

It is also good practise to backup the controlfile especially after tablespaces and datafiles have been added or deleted.

If you are not using an RMAN catalog it is more impotant that you frequently backup of your controlfile. You can also configure another method of controlfile backup which is referred to as 'autobackup of controlfile'.

Refer to the manual for more information regarding this feature.

RMAN> backup current controlfile;

RMAN> backup current controlfile format '/backups/PROD/df_t%t_s%s_p%p';

RMAN> backup spfile;

Backing Up Archivelogs

It is important that archivelogs are backed up in a timely manner and correctly removed to ensure the file system does not fill up. Below are a few different examples. Option one backs up all archive logs to the FRA or default location. Option two backs up all archivelogs generate between 7 and 30 days and option three backs up archive logs from log sequence number XXX until logseq YYY then deletes the archivelogs. It also backups the archive logs to a specified location.

RMAN> backup archivelog all;

RMAN> backup archivelog from time 'sysdate-30' until time 'sysdate-7';

RMAN> backup archivelog from logseq=XXX until logseq=YYY delete input format '/backups/PROD/%d_archive_%T_%u_s%s_p%p';

Backing up the Whole database including archivelogs

Below is an example of how the whole database can be backed up and at the same time backup the archive logs and purge them following a successful backup. The first example backups up to the FRA, however it you wish to redirect the output the second command shows how this is achieved.

RMAN> backup database plus archivelog delete input;

RMAN> backup database plus archivelog delete input format '/backups/PROD/df_t%t_s%s_p%p';

Find location of Install, Autoconfig, Patching , Clone and other logs in R12 - ID 804603.1

The list of Log file location in Oracle Applications for Startup/Shutdown, Cloning, Patching, DB & Apps Listener and various components in Apps R12/12i: 

Note:Instance top ($INST_TOP) is new directory added in R12 to keep the log files ,Startup/stop scripts for the application tier

A. Startup/Shutdown Log files for Application Tier in R12 
========================================================= 
i) Startup/Shutdown error message text files like adapcctl.txt, adcmctl.txt… :

$INST_TOP/apps/$CONTEXT_NAME/logs/appl/admin/log 

ii) Startup/Shutdown error message related to tech stack (10.1.2, 10.1.3 forms/reports/web) :

$INST_TOP/apps/$CONTEXT_NAME/logs/ora/ (10.1.2 & 10.1.3) 
$INST_TOP/apps/$CONTEXT_NAME/logs/ora/10.1.3/Apache/error_log[timestamp] 
$INST_TOP/apps/$CONTEXT_NAME/logs/ora/10.1.3/opmn/ (OC4J~…, oa*, opmn.log)
$INST_TOP/apps/$CONTEXT_NAME/logs/ora/10.1.2/network/ (listener log) 
$INST_TOP/apps/$CONTEXT_NAME/logs/appl/conc/log (CM log files) 

B. Log files related to cloning in R12 
======================================= 
Preclone (adpreclone.pl) log files in source instance 


i) Database Tier-$ORACLE_HOME/appsutil/log/$CONTEXT_NAME/(StageDBTier_