How to rollback a failed Interim patch installation

Doc ID:  312767.1
Doc ID:  565601.1

Subject:  How to rollback a failed Interim patch installation
  Doc ID:  312767.1 Type:  PROBLEM
  Modified Date :  01-APR-2009 Status:  PUBLISHED

In this Document
  Symptoms
  Changes
  Cause
  Solution
  References

 

--------------------------------------------------------------------------------

 

Applies to:
Oracle Universal Installer - Version: 1.0.0.0.50 to 1.0.0.0.99
This problem can occur on any platform.
NOTE: This Document only addresses pre-10.2 Oracle installations running on Unix / Linux.

It does not apply to OPatch versions 10.2.0.x or later as these versions will automatically rollback patches should OPatch recognize an error during the installation. Should the automatic rollback fail, OPatch will provide the instructions for manually rolling back changes.
Symptoms
During the installation of an Interim patch using OPatch, the follow error is returned:

OPatch has encountered an error during the application of the patch.

Do you want to Stop:

Beginning with OPatch 1.0.0.0.53, the following will be included:

Replying 'Y' will terminate the patch installation immediately.It WILL NOT restore any updates that have been performed to this point. It WILL NOT update the inventory.
Replying 'N' will continue with updating the inventory showing the patch has been applied.
NOTE: After replying either 'Y' or 'N' it is critical to review:
      Metalink Note 312767.1 How to rollback a failed Interim patch installation.
Do you want to STOP?
Please respond Y|N >
Changes
Interim patch was applied.

Cause
During the installation of an Interim patch there were errors copying files, updating objects or relinking binaries.

Solution
Use one of the following options to successfully apply or rollback the patch. The steps below will remove patch number 1234567 (replace 1234567 with the patch correct patch number).

NOTE: OPatch (version pre-10.2) will not automatically rollback the objects that were updated. Rerunning OPatch before rolling back the objects will destroy the rollback.sh script. making it impossible to rollback the updates.

There are multiple solutions depending on the option taken to end the patch install:

Do you want to Stop:
深圳-小荷(34120993)  11:35:54

Scenario 1: Replying Y:

 Run the rollback scripts
% sh $ORACLE_HOME/.patch_storage/1234567/rollback_1234567 .sh

NOTE: Due to a known issue in OPatch, rollback_1234567.sh may throw many errors similar to the following:

  ./rollback_5901872.sh[89]: System: not found.
  ./rollback_5901872.sh[97]: System: not found.

These can be ignored as they should be Remarks in the Script.

% sh $ORACLE_HOME/.patch_storage/1234567/1234567_make.txt

Note: running the 1234567_make.txt is only required if the apply was in the relink phase when aborted. If the patch apply was terminated before the relink phase, 1234567_make.txt will not be generated and relinking will not be needed

Rename the OPatch backup directory
% mv $ORACLE_HOME/.patch_storage/1234567 $ORACLE_HOME/.patch_storage/1234567.orig

Scenario 2: Replying N:

Rollback the patch using OPatch

% cd
% opatch rollback -id

Scenario 3: The rollback.sh was overwritten:

Move (NOT remove) the original backup directory
% mv $ORACLE_HOME/.patch_storage/1234567 $ORACLE_HOME

Rebuild the rollback.sh by reapplying the patch with the no_inventory and no_relink options
% cd
% opatch apply -no_inventory -no_relink

Copy the rollback and make script. to the original directory
% cp $ORACLE_HOME/.patch_storage/1234567/rollback_1234567.sh $ORACLE_HOME/1234567
% cp $ORACLE_HOME/.patch_storage/1234567/1234567_make.txt $ORACLE_HOME/1234567

Move the original backup directory to $ORACLE_HOME/.patch_storage
% mv $ORACLE_HOME/.patch_storage/1234567 $ORACLE_HOME/1234567.rereun
% mv $ORACLE_HOME/1234567$ORACLE_HOME/.patch_storage

Run the rollback script. and make commands
% sh $ORACLE_HOME/.patch_storage/1234567/rollback_1234567.sh

NOTE: Due to a known issue, OPatch, rollback_1234567.sh may throw many errors similar to the following:

  ./rollback_5901872.sh[89]: System: not found.
  ./rollback_5901872.sh[97]: System: not found.

These can be ignored as they should be Remarks in the Script.

% sh $ORACLE_HOME/.patch_storage/1234567/1234567_make.txt

Rename the OPatch backup directory
% mv $ORACLE_HOME/.patch_storage/1234567$ORACLE_HOME/.patch_storage/1234567.orig

@ "rempatch.pl" utility from metalink under Patch 4321390 can be used to remove a patch from the inventory. "rempatch.pl" should only be used as a last resort because the ORACLE_HOME files may not be restored to their original state.  Also note that the patch is password protected.

深圳-小荷(34120993)  11:36:24

 

文章2：
深圳-小荷(34120993)  11:36:59
Subject:  Error When Applying a Patch: java.lang.RuntimeException: ArchiveAction::apply() failed: "ar: read error
  Doc ID:  565601.1 Type:  PROBLEM
  Modified Date :  25-NOV-2008 Status:  PUBLISHED

In this Document
  Symptoms
  Cause
  Solution

 

--------------------------------------------------------------------------------

 

Applies to:
Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.4
This problem can occur on any platform.

Symptoms
-- Problem Statement:

When attempting to install a patch using opatch, the following error occurs:

Patching component oracle.rdbms, 10.2.0.3.0...
INFO:Updating archive file "/u/app/oracle/product/10.2/lib/libserver10.a" with
"lib/libserver10.a/qmurd.o"
INFO:Start Archive Action at Wed Mar 26 09:38:58 EST 2008
INFO:Finish Archive Action at Wed Mar 26 09:39:00 EST 2008
INFO:Stack Description: java.lang.RuntimeException: ArchiveAction::apply() failed: "ar: read error
"
INFO:StackTrace: oracle.opatch.ArchiveAction.apply(ArchiveAction.java:1714)
INFO:StackTrace: oracle.opatch.ApplySession.modifySystem(ApplySession.java:1207)
INFO:StackTrace: oracle.opatch.ApplySession.apply(ApplySession.java:915)
INFO:StackTrace: oracle.opatch.ApplySession.processLocal(ApplySession.java:4159)
INFO:StackTrace: oracle.opatch.ApplySession.process(ApplySession.java:5238)
INFO:StackTrace: oracle.opatch.ApplySession.process(ApplySession.java:5146)
INFO:StackTrace: oracle.opatch.OPatchACL.processApply(OPatchACL.java:251)
INFO:StackTrace: oracle.opatch.opatchutil.NApply.process(NApply.java:1901)
INFO:StackTrace: oracle.opatch.opatchutil.OUSession.napply(OUSession.java:662)
INFO:StackTrace: sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
INFO:StackTrace: sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
INFO:StackTrace:
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
INFO:StackTrace: java.lang.reflect.Method.invoke(Method.java:324)
INFO:StackTrace: oracle.opatch.UtilSession.process(UtilSession.java:288)
INFO:StackTrace: oracle.opatch.OPatchSession.main(OPatchSession.java:1801)
INFO:StackTrace: oracle.opatch.OPatch.main(OPatch.java:570)
INFO:
The following actions have failed:
WARNING:OUI-67124:Archive not applied
/u/app/oracle/product/10.2/patch/6646853/6121242/files/lib/libserver10.a/qmurd.o to
/u/app/oracle/product/10.2/lib/libserver10.a... ''

Cause
libserver10.a is corrupted.

mtvnhp08:PARIS:/tmp/diags>ar xv libserver10.a
x - kqac.o
x - kqai.o
x - kqam.o
x - kqan.o
...
...
...
x - qmtest_qmr.o
x - qmtest_qms.o
x - qmtest_kokec.o
x - qmtest_qmlock.o
x - qmtest_qmx.o
x - qmtest_nls.o
x - qmtest_csx.o
x - qmtest_nfa.o
ar: read error

Solution
-- To implement the solution, please execute the following steps:

1. Verify if the patch download is corrupt, check the filesize against the size noted on download site. Also, confirm if you downloaded the correct patch for your platform.

2. Verify if library file libserver10.a is corrupted:

Perform. the following test and verify if it fails:

$ mkdir /tmp/diags
$ cp $ORACLE_HOME/lib/libserver10.a /tmp/diags
$ cd /tmp/diags
$ ar xv libserver10.a

If you obtain an error like "ar: read error" it means that lib libserver10.a is corrupted.

3.  Run "opatch lsinventory -detail" and check the output to see if any of the installed patches have updated libserver10.a.

a) If no patches have been touched the libserver10.a, then libserver10.a can be restored from the patchset source:

Steps to restore libserver10.a from patchset source:

- Identify the patchet that you have installed
- Go to the location where the patchset was unzipped
- Find the jar file where libserver10.a is present
深圳-小荷(34120993)  11:37:13
Example:

$ cd Disk1
$ for f in `find . -type f -name '*\.jar'`; do unzip -l $f | grep -i "libserver10.a" && echo "was found in $f"; done
162678516 04-04-08 04:09 libserver10.a
%s_patchLocation%/lib/libserver10.a
was found in ./stage/Patches/oracle.rdbms/10.2.0.4.0/1/DataFiles/filegroup40.1.1.jar
[ Disk1]$

- Change directory to Disk1/stage/Patches/oracle.rdbms/10.2.0.4.0/1/DataFiles
- Run:
$ rm -rf /tmp/diags/*
$ cp filegroup40.1.1.jar /tmp/diags
$ cd /tmp/diags
$ jar xvf filegroup40.1.1.jar
-- jar has to be in the PATH, if it is not, you can add it like this:
$ export PATH=$ORACLE_HOME/jdk/bin:$PATH
-- where Oracle Home is the 10g Oracle Home
$ cd $ORACLE_HOME/lib
$ mv libserver10.a libserver10.a.bad
$ cp /tmp/diags/libserver10.a .

The above example is for patchset 10.2.0.4.
The command

for f in `find . -type f -name '*\.jar'`; do unzip -l $f | grep -i "libserver10.a" && echo "was found in $f"; done

will give you the correct jar file where libserver10.a is present.

b) If any of the installed patches have updated libserver10.a, the easier solution is to reinstall oracle (rdbms) in a new ORACLE_HOME, reinstall all the one-off patches applied in the corrupted HOME that updated libserver10.a.
When finished, copy the updated library libserver10.a to your production $ORACLE_HOME/lib.

4. Apply patch again

Keywords
OPATCH ; JAVA.LANG.RUNTIMEEXCEPTION ; 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/20542911/viewspace-615683/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/20542911/viewspace-615683/