Skip to main content
Delphix

Oracle Patching (PSU/CPU) and how this can affect VDB refreshes(KBA8446)

 

KBA

KBA# 8446

 

Issue

Oracle releases patches quarterly for their software. This KBA will discuss how patching your Oracle software and database can affect a VDB managed by Delphix.

The Delphix engine checks to the fourth digit of the version number. The version number must be identical to the fourth digit else the VDB will fail to provision.

Example:

11.2.0.4.15 to 11.2.0.4.15 - OK

11.2.0.4.15 to 11.2.0.4.<some patch set> is usually OK

11.2.0.3 to 11.2.0.4 - Provisions or refreshes would fail.

With regards to patch levels, strictly speaking, we would advise that source and target be on the same precise version and patch level. 

However, in practice a different opatch level is normally not an issue and hence the Delphix engine only checks the first four digits.

If a VDB was acting strangely and it was found to be on a different patch level then we will likely advise that the patch level is changed. We've advised this in the past when this situation was encountered.

Issues can occur in two situations -

1) When the VDB is refreshed from production and production is at a lower patch level.

2) When production is at a higher patch level and you do not want to patch the VDB's Oracle Binaries yet.

Prerequisites

Must be installing Oracle's Patches at a different cadence for production and development/User testing etc.

Applicable Delphix Versions

Click here to view the versions of the Delphix engine to which this article applies
Major Release All Sub Releases
6.0 6.0.0.0, 6.0.1.0, 6.0.1.1, 6.0.2.0, 6.0.2.1, 6.0.3.0, 6.0.3.1, 6.0.4.0, 6.0.4.1, 6.0.4.2, 6.0.5.0, 6.0.6.0, 6.0.6.1, 6.0.7.0, 6.0.8.0, 6.0.8.1, 6.0.9.0, 6.0.10.0, 6.0.10.1, 6.0.11.0

5.3

5.3.0.0, 5.3.0.1, 5.3.0.2, 5.3.0.3, 5.3.1.0, 5.3.1.1, 5.3.1.2, 5.3.2.0, 5.3.3.0, 5.3.3.1, 5.3.4.0, 5.3.5.0, 5.3.6.0, 5.3.7.0, 5.3.7.1, 5.3.8.0, 5.3.8.1, 5.3.9.0

5.2

5.2.2.0, 5.2.2.1, 5.2.3.0, 5.2.4.0, 5.2.5.0, 5.2.5.1, 5.2.6.0, 5.2.6.1

5.1

5.1.0.0, 5.1.1.0, 5.1.2.0, 5.1.3.0, 5.1.4.0, 5.1.5.0, 5.1.5.1, 5.1.6.0, 5.1.7.0, 5.1.8.0, 5.1.8.1, 5.1.9.0, 5.1.10.0

5.0

5.0.1.0, 5.0.1.1, 5.0.2.0, 5.0.2.1, 5.0.2.2, 5.0.2.3, 5.0.3.0, 5.0.3.1, 5.0.4.0, 5.0.4.1, 5.0.5.0, 5.0.5.1, 5.0.5.2, 5.0.5.3, 5.0.5.4

Resolution

To resolve these issues - 

1) When the VDB is refreshed from production and production is at a lower patch level.

 - Even if the database is not acting strangely we would simply want to run the 

 -- @$ORACLE_HOME/rdbms/admin/catbundle.sql psu apply

As a post step to hopefully correct any issues that may occur.

2) When production is at a higher patch level and you do not want to patch the VDB's Oracle Binaries yet.

 - This is a little more complicated and will require the following - 

o Use the DE GUI to Migrate the VDB back in to an environment and home where the current PSU release is in place.
o Execute catbundle against it, this will generate the rollback script for that specific VDB.
o Edit the rollback script generated by catbundle to prevent it from executing catbundle.sql again during rollback so all that occurs is the rollback portion and not the re-run of catbundle. Commenting out the following line will do this.

REM @@?/rdbms/admin/catbundle.sql psu apply

o Execute the edited rollback script against the new/refreshed VDB.
o Migrate the VDB using the Delphix GUI to the new environment/target home running the lower PSU
o Execute the catbundle script from this home where the earlier PSU release is present to align the VDB release with the binaries PSU level.

 

Both these issues could also be minimized by using vfiles on the target server. By creating a vfiles of the ORACLE_HOME being used, then provision a new ORACLE_HOME where it can be patched with the current release of the CPU etc.

This would resolve having to migrate the VDB to a different server to generate the rollback script.

For reference, unstructured files is discussed in our documentation here.

 

Troubleshooting

May need to run opatch lsinventory to show the patches applied to an instance/database.

Also could run select * from sys.registry$history ;

Could also do -

opatch lsinventory -xml from both ORACLE_HOMEs

Then opatch compare [file1 file2]

 


Related Articles

The following articles may provide more information or related information to this article:

  • link
  • link
  • link