Wednesday, December 16, 2015

Exadata - Exachk finding: The bundle patch version installed does not match the bundle patch version registered in the database

You may encounter a failed check in Exachk report saying : "The bundle patch version installed does not match the bundle patch version registered in the database"

This may likely be encountered after applying a Database Bundle Patch, like "Patch 20950328 (DATABASE BUNDLE PATCH: 12.1.0.2.9"

This exack failure is based on the data that needs to be stored in "dba_registry_sqlpatch".. Exach just try to match the patch info stored in oraInventory with the patch info stored in dba_registry_sqlpatch. If it can't match those, it concludes this check as a failed one.

The manuel check can be done by executing the following shell commands in sequence;

opatch_bp=$($ORACLE_HOME/OPatch/opatch lspatches 2>/dev/null|grep -iwv javavm|grep -wi database|head -1|awk -F';' '{print $1}') 

database_bp_status=$(echo -e "set heading off feedback off timing off \n select STATUS from dba_registry_sqlpatch where PATCH_ID = $opatch_bp;"|$ORACLE_HOME/bin/sqlplus -s " / as sysdba" | sed -e '/^ *$/d')

if [ "$database_bp_status" == SUCCESS ]
then
      echo "SUCCESS: Bundle patch installed in the database matches the software home and is installed successfully."
else
      echo "FAILURE: Bundle patch installed in the database does not match the software home, or is installed with errors." 
 fi

The failure is actually caused by not running post installation instructions, as these post instructions makes you running datapatch to record the patch information in to the sql inventory.
On the other hand; the readme of the bundle patches are a little wrong, as running datapatch may require the database to be in upgrade mode and if you are patching Exadata , which is generally a RAC based environment, you need to set the cluster_database=false before starting the database using startup upgrade command;
Also note that, you must have at least 1 job_queue_process in the database environment.

Running datapatch is easy.

go to $ORACLE_HOME/OPatch directory and execute it as follows;

[oracle@exadatanode1 OPatch]$ ./datapatch -verbose
SQL Patching tool version 12.1.0.2.0 on Tue Dec 15 18:15:04 2015
Copyright (c) 2015, Oracle.  All rights reserved.

Log file for this invocation: /oracle/PROD/proddb/cfgtoollogs/sqlpatch/sqlpatch_130061_2015_12_15_18_15_04/sqlpatch_invocation.log

Connecting to database...OK
Bootstrapping registry and package to current versions...done
Determining current state...done

Current state of SQL patches:
Patch 20415564 (Database PSU 12.1.0.2.3, Oracle JavaVM Component (Apr2015)):
  Installed in the binary registry only
Bundle series DBBP:
  ID 9 in the binary registry and not installed in the SQL registry

Adding patches to installation queue and performing prereq checks...
Installation queue:
  Nothing to roll back
  The following patches will be applied:
    20415564 (Database PSU 12.1.0.2.3, Oracle JavaVM Component (Apr2015))
    20950328 (DATABASE BUNDLE PATCH: 12.1.0.2.9 (20950328))

Installing patches...
Patch installation complete.  Total patches installed: 2

Validating logfiles...
Patch 20415564 apply: SUCCESS
  logfile: /oracle/PROD/proddb/cfgtoollogs/sqlpatch/20415564/18617752/20415564_apply_PROD_2015Dec15_18_15_39.log (no errors)
Patch 20950328 apply: SUCCESS
  logfile: /oracle/PROD/proddb/cfgtoollogs/sqlpatch/20950328/18903184/20950328_apply_PROD_2015Dec15_18_15_40.log (no errors)
SQL Patching tool complete on Tue Dec 15 18:16:24 2015

No comments :

Post a Comment