COMMON ERROR #1: Assuming that all patches can be applied using the hotpatch and nocheckfile parameters. ORACLE’S RECOMMENDATION: The adpatch ‘hotpatch’ parameter should be used very sparingly and is not intended to be an easy way of applying patches to your system without shutting down the application tier services. Most patches should only be applied during scheduled downtimes when all users are logged off the system, application tier services have been shut down and Maintenance Mode enabled. From the adpatch documentation:
“If an emergency patch can be applied without shutting down services, the customized instructions generated by PAA will explicitly state so. If the customized instructions do not explicitly state this, assume that you need to shut down services and enable Maintenance mode before applying the patch.”
Similarly, the ‘nocheckfile’ parameter should not be used on all patches. Nocheckfile forces the patch to run all jobs in a patch regardless of whether the jobs have been run before. It degrades patch performance and should only be used in specific circumstances where it is genuinely needed. It should not be used as the default option for applying all patches. There are very few cases in which you would want to run with nocheckfile.
COMMON ERROR #2: Assuming that patches can be applied “manually” or backed out of “manually”. ORACLE’S RECOMMENDATION: There is no manual alternative to using adpatch to apply a patch. It is not supported to selectively choose only certain files from a patch and manually copy or execute these files in your E-Business Suite environment. Similarly, there is no simple method of reversing a patch.
COMMON ERROR #3: Increasing the number of patch workers in an attempt to make patches run faster. ORACLE’S RECOMMENDATION: Do not assume more workers automatically improves patch performance. When you first test a patch, accept the default number of workers. Use this as the performance benchmark. If you think a different number of workers will improve patch performance then try this once you have your default benchmark, but do not exceed the default number of workers without good justification for doing so. Once a patch is started, the number of workers cannot be changed mid-patch.
---应用补丁一定要谨慎,或许会你的系统带来麻烦,一定要测试,测试,在测试.
COMMON ERROR #4: Ignoring or skipping patch workers that fail on products that are not used or needed. ORACLE’S RECOMMENDATION: You should aim to have zero errors when applying a patch. All E-Business Suite products are installed in the E-Business Suite database whether you are licenced to use them or not. Patches will update all products in the database whether they are licenced or not. If you find yourself having to skip jobs or ignore errors during patching then this indicates an underlying problem in your system that should always be investigated and addressed. Review the patch prerequisites and ensure all steps have been completed successfully.
COMMON ERROR #5: Using adpatch default log file names during patching. ORACLE’S RECOMMENDATION: Identify each new patch log file with a unique patch log file name. If you always choose the default log file name in adpatch, your adpatch.log quickly becomes enormous. This makes it very difficult to identify individual patch information in the log file and makes it difficult to keep an accurate record of your patch history. Use a simple naming convention, e.g. choose a unique adpatch log name for each patch (<patchnumber>.log. Archive and then delete your main patch log and worker files after each patch so each patch has new log and worker files.
--不容易错误的排查,这不是一个ebs dba的好习惯.
References
Related Articles
