Datapatch New Features And Changes

Overview:

In 12.1  we have two different types of patches – Bundle patch /PSU patches and interim patches (non bundles) :

  The versioning scheme up until 12.2.0.1 splits the patch metadata into 2 places :

1. _{The XML patch descriptor found under $ORACLE_HOME/sqlpatch/bug id/bug uid/bug id.xml}  
2. _{bundledata_<series>.xml found under $ORACLE_HOME/rdbms/admin.}

datapatch uses the metadata from both locations to determine if a given SQL file should be run for a particular install

They have three important pieces of metadata as described below :

Bundle patches are marked with ‘B’ in the flags column of dba_registry_sqlpatch.

Change in 18c :

With the new model, there are still 2 main types of patches – release updates/release update revision and interim patches.

To migrate to a new release update or revision, we will use the patching process (opatch for binary changes, datapatch for SQL changes).

This implies that, like our current bundle patches, a release update or revision must be RAC rolling, and can therefore be installed with zero down time.

The bundle series/bundle ID metadata which we have currently in 12.1.0.2 and 12.2.0.1 will not work for this new model. Hence we will have instead the following new metadata:

From the file : $ORACLE_HOME/sqlpatch/28090523/22329768/28090523.xml

The source_* and target_* columns of dba_registry_sqlpatch will encode the full version information .

bundledata.xml is no longer needed as the XML descriptor includes all the patch specific and RU metadata

Complete Version Description:

In order to completely describe a given release update, all 3 components of the version are needed:

• 5 digit version string (i.e. 18.3.2.0.0). Although this string includes 5 digits, currently only the first 3 will be updated with this model.
• Patch type (i.e. RU)
• Release_Update_Revision

Collectively these 3 pieces of metadata are known as a version description.

The oraversion executable can be used to determine the current version description of the binaries in a given oracle home:

Binary patching can be accomplished with opatch inplace operations, or out of place patching between two homes/containers at different releases. SQL patching may require more than one operation to complete, depending on the binary and SQL versions when datapatch is invoked, as described below.

The recommended action for customers is to stay on the RU branch unless they only want security and regression fixes.

SQL Registry Changes :

The structure of registry$sqlpatch and dba_registry_sqlpatch in 18c is as follows. Columns in bold are new in 18c.

Note the following about this table structure:

We introduce a second SQL registry table registry$sqlpatch_ru_info, with associated view dba_registry_sqlpatch_ru_info, with the following structure:

Each row in dba_registry_sqlpatch_ru_info will contain the metadata associated with an RU patch.

Following files used by Datapatch :

Simpler call to patch_initialize:

Currently the call to patch_initialize in the apply or rollback script looks as follows:

BEGIN
dbms_sqlpatch.patch_initialize(p_patch_id => patch ID,
p_patch_uid => patch UID,
p_flags => ‘&flags’,
p_description => ‘&description’,
p_action => ‘APPLY’,
p_logfile => ‘&full_logfile’,
p_bundle_series => ‘&bundle_series’);
END;
/

The flags, description, action, and bundle series parameters are no longer needed, so the call starting in 18.1 should look as follows:

BEGIN
dbms_sqlpatch.patch_initialize(p_patch_id => patch ID,
p_patch_uid => patch UID,
p_logfile => ‘&full_logfile’);
END;
/

Procedure Changes :

The following table summarizes the changes to each of the main routines within datapatch.

Addional Logfile :

sqlpatch_debug.log  === > Starting from 18c this logfile will be created for each invocation of datapatch .

Location : $ORACLE_BASE/cfgtoollogs/sqlpatch_pid_<timestamp>