Tuesday 1 June 2010

Patch History Not Being Loaded to Database

When you installing patch, at the end of the session will get error similar to

An Autopatch session fails with the following error:

AutoPatch error:
adphistInsertIntoPtchRunBugAct: Unexpected Database Error

AutoPatch error:
ORA-00001: unique constraint (APPLSYS.AD_PATCH_RUN_BUG_ACTIONS_U2) violated

AutoPatch error:
Error Calling adphistStoreJavaPtchRunBugAct

Error in calling adphistUpdateCheckFileTemp().

AutoPatch error:

Unable to upload Java Classes to DB from file:
/.../javaupdates20060911112913.txt

0 "left over" javaupdates.txt files uploaded to DB

To solve this issue, there is an Autopatch option which allows patch history to be uploaded :

The fix for this issue will be available in 11.5.10.CU.3 and the merged patches will be able to be queried via OAM until then there is a workaround which is to insert extension mergedate mm/dd/yy hh:mm:ss in the merged u driver.

To allow this merged patch to be applied there is also a need to to move the javaupdates.txt file from the directory and then run the adpatch command to apply the failing patch. Once the patch is applied there is then the secondary issue in that the patch history is not up to-date.

* uploadph - To upload the patch history from the filesystem to the database and exit. Default is NO

Therefore put the javaupdates.txt file that was renamed earlier and then run "adpatch uploadph=y" to upload the patch history.

These updates should also be uploaded in the Master Archive which is $JAVA_TOP/META-INF/JRIMETA.dat file.

To generate the differences between the file system and the Archive run the following and upload the output file:-

adjava -mx512m -nojit oracle.apps.ad.jri.adjcopy \
-masterArchive $JAVA_TOP -sync -reportfile /tmp/jrimetadifferences.lst

The contents of the archive can be reviewed by (without -sync)

adjava -mx512m -nojit oracle.apps.ad.jri.adjcopy \
-masterArchive $JAVA_TOP -reportfile /tmp/jrimetafull.lst

adjava -mx512m -nojit oracle.apps.ad.jri.adjlist -archives $JAVA_TOP -reportfile /tmp/versions.txt -allinfo

These steps should force the patch history to be applied to the database and ensure the Master Archive is up to date.

Previously, patch history was stored in a text file called applptch.txt in the $APPL_TOP/admin/< SID> directory. AutoPatch appended information about each applied patch to the applptch.txt file automatically.

Since AD Minipack E, the Patch History feature stores all patch information in database tables. If the information cannot be written to the database, it is stored in the file system, and is automatically loaded to the database each time AutoPatch is run. In this case, the temporary patch history file was named applptch.txt.

In AD Minipack H (and later), there are two patch history files:

•javaupdates.txt - records patch history about changes to Java files
•adpsv.txt - records patch history about changes to all non-Java files.
The best way to review patching history is to use the Applied Patches utility provided by Oracle Applications Manager (OAM). From the Applied Patches interface, you can perform a simple search by querying on the patch number, the number of days or date range during which patches were applied and/or the patch language. An advanced search provides additional search criteria. The search results display useful information including patch name, description, a list of merged patches, location of applied patch, language, files changed or copied, bug fixes in each driver file, whether patch application was successful and timing information

But in the case of patch driver fails, fix the issue and restart AutoPatch. AutoPatch will allow you to continue where the patch left off. Re-running the patch from the beginning may result in it being applied incorrectly. So we beware of it.

Cheers!

Related Posts by Categories



1 comment:

Anonymous said...

In Case of R12..how to upload the patch history