Patch failed but the fix is another patch!
Fortunately this happens infrequently (in my experience) and is usually caught the first time patch(es) are applied in a sandbox or dev environment. There could be a few reasons why this happens, a couple off the top of my head:
- Your patch analysis wasn't complete. [If you have been in pre-req hell before, it can be very easy to miss a patch.]
- You've hit a bug and Oracle informs you another patch is required.
- Some large patches, especially family packs usually have functional prerequisites. These are usually in the README file as a chart which lists the product, feature and patches required. If you are using, or plan to use the products listed in the chart, you are required to apply the patch(es).
Just recently, we hit an issue in which we had to go back and apply a functional pre-req for a module we don't use.
So how do you resolve this? There are two options:
1. Cancel the patch, apply the new patch, then start the first one over again.
2. Backup the first patch, apply the new patch, restore the first patch and let it continue where it left off.
The benefit of option 2 is to save deployment time. Obviously if you are 2-3 hours into a large patch and you choose option 1 you have to start over.
So, the steps to backup the first patch are:
1. Use adctrl to shutdown all of the workers.
2. Backup the FND_INSTALL_PROCESSES and AD_DEFERRED_JOBS tables.
3. Backup the .rf9 files under $APPL_TOP/admin/[SID]/restart
4. Drop the tables in step 2.
5. Apply the new patch.
6. Restore the .rf9 files backed up in step 3.
7. Restore the tables backed up in step 2.
8. Recreate Synonyms under apps:
- create synonym AD_DEFERRED_JOBS for APPLSYS.AD_DEFERRED_JOBS;
- create synonym FND_INSTALL_PROCESSES FOR APPLSYS.FND_INSTALL_PROCESSES;
9. Start adpatch and continue.
Now, this only works if one of the workers fail while executing tasks for the first patch. If a fatal error happens elsewhere then you can't use the steps above.
Fortunately this happens infrequently (in my experience) and is usually caught the first time patch(es) are applied in a sandbox or dev environment. There could be a few reasons why this happens, a couple off the top of my head:
- Your patch analysis wasn't complete. [If you have been in pre-req hell before, it can be very easy to miss a patch.]
- You've hit a bug and Oracle informs you another patch is required.
- Some large patches, especially family packs usually have functional prerequisites. These are usually in the README file as a chart which lists the product, feature and patches required. If you are using, or plan to use the products listed in the chart, you are required to apply the patch(es).
Just recently, we hit an issue in which we had to go back and apply a functional pre-req for a module we don't use.
So how do you resolve this? There are two options:
1. Cancel the patch, apply the new patch, then start the first one over again.
2. Backup the first patch, apply the new patch, restore the first patch and let it continue where it left off.
The benefit of option 2 is to save deployment time. Obviously if you are 2-3 hours into a large patch and you choose option 1 you have to start over.
So, the steps to backup the first patch are:
1. Use adctrl to shutdown all of the workers.
2. Backup the FND_INSTALL_PROCESSES and AD_DEFERRED_JOBS tables.
3. Backup the .rf9 files under $APPL_TOP/admin/[SID]/restart
4. Drop the tables in step 2.
5. Apply the new patch.
6. Restore the .rf9 files backed up in step 3.
7. Restore the tables backed up in step 2.
8. Recreate Synonyms under apps:
- create synonym AD_DEFERRED_JOBS for APPLSYS.AD_DEFERRED_JOBS;
- create synonym FND_INSTALL_PROCESSES FOR APPLSYS.FND_INSTALL_PROCESSES;
9. Start adpatch and continue.
Now, this only works if one of the workers fail while executing tasks for the first patch. If a fatal error happens elsewhere then you can't use the steps above.
0 comments:
Post a Comment