Oracle Database Patching Terminology

-
Oracle Database Patching Terminology:
New Name
Old Name
Description
Interim Patch
PSE, MLR, Exception release, One-Off, x-fix, Hotfix, Security One-Off
A patch containing one or more fixes made available to customers who cannot wait until the next patch set or new product release to get a fix. This may be any patch in a My Oracle Support document or from a Service Request.
Diagnostic Patch
Diagnostic Patch, test Patch, Fix Verification Binary (FVB), e-fix
An interim patch created specifically to diagnose a problem and not to fix a bug. This may be from a Service Request to help diagnose your issue after a defect has been filed but not fully resolved.
Bundle Patch
Maintenance Pack, Service Pack, MLRs, Cumulative Patch, Update Release, Bundle Patch
An iterative, cumulative patch that is issued between patch sets. Bundle patches usually include only fixes, but some may include minor enhancements. Examples are the Database Windows Bundles and SOA Bundle Patches. These will be documented in My Oracle Support documents.
Patch Set Update (PSU)
Patch Set Update (PSU)
A quarterly patch that contains the most critical fixes for the applicable product, allowing customers to apply one patch to avoid many problems. These will be documented in My Oracle Support documents and initially released from the Critical Patch Update program.

For example, Oracle WebLogic Server has a PSU delivered with the CPU program where the 5th digit, signifies that PSU release, e.g. 10.3.6.0.xx.

Patch Set Updates are released on quarterly basis mostly on the third week of January, April, July and October.
Once the PSU is applied only PSUs can be applied in future quarters until the database is upgraded to knew base version
Security Patch Update (SPU)
Critical Patch Update (CPU)
An iterative, cumulative patch consisting of security fixes. Formerly known as Critical Patch Update.

SPUs are single patches for a single product or component to fix a security vulnerability. These are cumulative for the same product or component they are released for, e.g. Oracle HTTP Server, noting other components installed together will have separate patches, e.g. OPMN and SSL installed with OHS. These will be documented in My Oracle Support documents and initially released from the Critical Patch Update program.

The program name which delivers SPUs will still be called Critical Patch Update, as defined below:

Oracle's program for quarterly release of security fixes. Patches released as part of this program may be Patch Set Updates, Security Patch Updates, and Bundle Patches. Regardless of the patch type, the patches are cumulative.

Critical patch updates or CPUs are released on quarterly basis. Mostly they are released on the third week of January, April, July and October.
For the database, SPUs can not be applied once PSUs have been applied until the database is upgraded to a new base version.

For more details refer : (Doc ID 1430923.1)

Comments

Post a Comment

Popular posts from this blog

Guarantee Restore Point Primary-Standby Environment

-
Guarantee Restore Point Primary-Standby Environment: When we have a Data Guard environment (Primary RAC and Standby Standalone Databases) and we want to make use of restore points. We need to follow below steps. Always create a restore point on the standby database first then in Primary. The main reason for this is because the SCN of the standby must be less than the SCN of the primary in case you need to flashback your database. If we didn’t follow the step 1 then we need to rebuild the standby. 1.) Stop Managed Recovery on the Standby Database using SQL*PLUS or Data Guard Broker. $ dgmgrl sys/<Password>@<PRIM/STDBY> DGMGRL>  show database ' STDBY '; edit database 'STDBY' set state = 'APPLY-OFF'; show database ' STDBY ';   OR STDBY.SYS.SQL> select inst_id, process, status, thread#, sequence#, block#, blocks from gv$managed_standby order by inst_id; alter database recover managed standby database ca
Read more

Steps on converting a Snapshot Standby database to Physical Standby database

-
Steps on converting a Snapshot Standby database to Physical Standby database: 1) Check for database role, open mode & Restore point create by this conversion. STDBY.SYS.SQL> set serveroutput on long 2000000 longchunksize 20000 pagesize 50000 linesize 1000 set trimspool on time on timi on feedback on verify off echo off heading on; col name for a65 col scn for 9999999999999999999999 col time for a40 col guarantee_flashback_database for a30 col db_unique_name for a15 select a.name db_name, a.db_unique_name, b.instance_name, b.instance_role, a.database_role, a.open_mode, a.protection_level, a.fs_failover_status, a.dataguard_broker, a.log_mode, a.force_logging, a.flashback_on from gv$database a, gv$instance b; select name, scn, time, guarantee_flashback_database, storage_size, database_incarnation# from gv$restore_point; 2) If the standby database is a RAC setup then we need to shutdown all the instances except one on which we will be using the conversion c
Read more

Flashback Database to Restore Point in Primary-Standby Environment

-
Flashback Database to Restore Point in Primary-Standby Environment: When we have a Data Guard environment (Primary RAC and Standby Standalone Databases) and we want Flashback database to restore point. We need to follow below steps. a) Always flashback the primary database first. Then follow below step for Standby. b) On the primary, connect using RMAN and list the incarnations. c) On the standby, cancel the recovery and flashback the standby to restore point created earlier. d) On the standby, connect using RMAN and list the incarnations. e) If there is a mismatch in incarnation between primary and standby then need to reset the incarnation of standby and start recovery (Details not available in this DOC). 1)    Disable Log Transport Services to the Standby Database for the Destination serving the Standby Database on all Primary Instances: $ dgmgrl sys/<Password>@<PRIM/STDBY> DGMGRL>  show database 'PRIM '; edit database '
Read more