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.
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;
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...
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';
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) :