Managing Patches

Database patches are cumulative for all previous Critical Patch Updates
– Database patches include non-security fixes
– Windows patches are really version upgrades
– Testing should be similar to a version upgrade (i.e., 9.2.0.7 to 9.2.0.8)

Database patches provide the greatest security benefit –Apply them ASAP
– Apply database patches now, other patches later
– Otherwise, enable Listener Invited Nodes feature

Common CPU Patching Mistakes
1. CPU Forgotten Steps
2. Database Upgrades
3. ORACLE_HOME vs. Database
4. ORACLE_HOME and New Database

#1 CPU Forgotten Steps
CPU is two parts:

1.OPatchto update files in the ORACLE_HOME
2.catcpu.sql to update database objects

Some CPUs require additional manual steps, for example the January 2008 CPU requires all views to be recompiled due view/SQL complier bugs in July 2007 CPU

Remember to query SYS.REGISTRY$HISTORY to verify CPU row is present

#2 Database Upgrades
Scenario:
– Latest CPU patch is applied (January 2009)
– Upgrade database to new version or patchset (10.2.0.3 to 10.2.0.4)
- Do I have to reapply the latest CPU after the database upgrade?
Yes!!!, you must apply 10.2.0.4 January 2009 patch


Database Upgrades and CPU Patches

Database Version Upgrade Patch	Latest CPU Patch Included In Upgrade Patch
9.2.0.8	July 2006
10.1.0.5	October 2005
10.2.0.3	October 2006
10.2.0.4	April 2008
11.1.0.6	October 2007
11.1.0.7	January 2009

#3 ORACLE_HOME vs. Database
Scenario:
– Latest CPU patch is applied (January 2009) to ORACLE_HOME
– Install a new database from the patched ORACLE_HOME
- Do I have to run the catcpu.sqlfrom the January 2009 CPU?
Yes!!!, since some of the SQL statements in the catcpu.sql do not exist as files in the Oracle Home
Remembet that catcpu.sql does perform some drops and grants

#4 ORACLE_HOME and New Database
Scenario:
– Latest CPU patch is applied (January 2009) to ORACLE_HOME
– Install a new database from the patched ORACLE_HOME using DBCA and a seeded database
- Do I have to run the catcpu.sqlfrom the January 2009 CPU?
Yes !!!!, since the seeded database files are pre‐loaded with packages and none of the vulnerable packages would be updated without running catcpu.sql