AD PATCH Reducing Downtime
Following the suggestions in this section can substantially reduce your system downtime during the application of patches.
1.Consolidate Patches
2.Apply Patches in Non-interactive Mode
3.Defer Database Tasks
4.Defer Upload of Patch Information
5.Apply on a Test System First
6.Use a Shared Application Tier File System
7.Use Distributed AD
8.Reduce Resource Related Issues
9.Manage Patching During an Upgrade
10.Evaluate Patch Drivers
11.Use AutoPatch Efficiently
12.Merge NLS (Translation) Patches and Apply Them During Uptime
1.Consolidate Patches
Using AD Merge Patch to merge multiple patches into a single patch eliminates the time it takes to start a new AutoPatch session. It also eliminates generic processes that are common to all patch applications.
2.Apply Patches in Non-interactive Mode
You can automate much of the patching process by applying patches in non-interactive mode. This process allows you to store the responses to the patching prompts in a defaults file, and then specify the name of this file when you run AutoPatch. See Oracle Applications Maintenance Procedures (11i) and Oracle Applications Patching Procedures (R12) for more information.
3.Defer Database Tasks
Use AutoPatch options=nocompiledb,nomaintainmrc to defer system-wide tasks such as "Compile APPS schema" and "Maintain MRC" until all patches have been applied. AutoPatch automatically compiles the APPS schema and maintains the MRC schema during the application of standard patches. Try deferring the compilation of database objects so users can log back in sooner. You should do this with this understanding:
Applying a patch in a test system shows data objects that are invalid because they cannot be compiled (as opposed to being invalid because the definition has changed and the object has not yet been compiled). Problems must be resolved on the production system using workarounds that are similar to those used on the test system.
The database server automatically compiles any uncompiled database objects that are present when the objects are accessed for the first time. This may affect performance as the first user waits for all invalid objects in the dependency chain to be compiled. You can minimize this effect by running "Compile APPS schema" in AD Administration immediately after you return your system to the user community.
4.Defer Upload of Patch Information
AutoPatch uploads patch history information to the database automatically each time it successfully applies a patch. The time required for the upload may be substantial depending on the size of the patch. You can defer this task during the AutoPatch session and upload the patch history information later, after you have made the system available to users. Use options=phtofile during the downtime patching session to defer the information upload. Then, after your system is up and users have returned, run AutoPatch again with the argument uploadph=y to upload the patch history information from the patch history files to your database. AutoPatch performs the upload and then exits.
5.Apply on a Test System First
To perform an analysis of the effects of applying a patch, apply it first to a test system. Note the following advantages:
Look for long-running jobs and phases which take the longest time in the timing statistics report ($APPL_TOP/admin//out/adt.lst).
If your test system is a reasonable copy of your production system, you can expect to return the production system to normal use before you compile invalid objects IF the patch application causes no errors (or has known workarounds).
Use the number of workers employed to apply the patch on the test system to extrapolate the number required for your production system.
Relink and regenerate all executables, forms, reports, libraries and Java archives on the test system, and then copy this file system to your production system.
Consider using a staged Applications system. See Using a Staged Applications System to Reduce Patching Downtime (OracleMetaLink Note 242480.1) for details. See also Using a Staged Applications System in Oracle Applications Maintenance Procedures (11i) and Oracle Applications Patching Procedures (R12).
6.Use a Shared Application Tier File System
Creating a multi-node system with a shared application tier file system saves patching time because you apply patches only once, on the primary node. See Sharing the Application Tier File System in Oracle Applications 11i (OracleMetaLink Note 233428.1) for details on creating a shared application tier file system.
7.Use Distributed AD
Distributed AD is a parallel processing feature that can reduce downtime by efficiently utilizing all the available resources on a shared application file system. AD Administration and AutoPatch run on the primary node and direct workers running on that node and other nodes in the system. The AD Controller utility controls and monitors the actions of the workers that you specify. For complete information, see Distributing Processing Tasks in Oracle Applications Maintenance Procedures (11i and R12) and Oracle Applications Patching Procedures (R12).
8.Reduce Resource Related Issues
Modify rollback segment sizing and temporary segment space to optimize resources during patch application.
Match batch commit size with your rollback segment sizing. Many scripts which process potentially large quantities of data accept a parameter that specifies the batch commit size. This parameter is automatically passed by AutoUpgrade to the script based upon the response the user gave when starting the upgrade. A larger batch commit size processes data more quickly, but requires larger rollback segments. Some customers with very large rollback/undo use 1,000,000. Test updates will help you tune the value.
Use as much temporary segment space as practical. Temporary tablespace (usually TEMP) should be created as a locally managed tablespace using the temporary file option with a uniform allocation size. Some scripts can run up to an order of magnitude faster by having sufficient temporary segment space (for example, 20 GB) to allow hash-join operations to be performed within the data server.
9.Manage Patching During an Upgrade
You need to apply the database upgrade driver and specific functional patches during an upgrade to Release 11i or 12. Here are some tips to reduce downtime:
Upgrade to Release 11.i.x or Release 12.0.x plus patches by running the copy, database and generate actions in a test environment. Then, copy this file system to your production system, where you need to run only the database actions to complete the upgrade.
Use a copy of the test system's APPL_TOP with all file system patches pre-applied. This way, only the consolidated database driver created by AD Merge Patch needs to be run during the Production upgrade. In addition, generation of files such as forms, reports and message files is not required as this has been performed already when the original patch was applied.
See Reduce Downtime by Using a Test APPL_TOP for a Production Upgrade to Release 11i (OracleMetaLink Note 217370.1) for details.
10.Evaluate Patch Drivers
You can perform an impact analysis on a patch, without affecting your system, by running AutoPatch with the command line option apply=no.
Some patches include only file system changes. Roughly 60% of Applications patches do not include database changes. Most UNIX systems allow an executable to be linked or generated while in use, and then the new version is used by new user access and prior processes continue to access the cached version. Windows will, however, fail with an exception when attempting to overwrite a file that is in use.
Some database changes require no downtime, for example, loading Help text and updating translations. See Merge NLS (Translation) Patches and Apply Them During Uptime in this note.
Aggregate patches that do not require downtime vs. those that do.
11.Use AutoPatch Efficiently
Using certain AutoPatch command line options and managing the number of workers can minimize patch application time.
The following AutoPatch command line options could reduce downtime during patch application:
The norevcache option can save 5 to 10 minutes. Use this option when zero or only a few PL/SQL packages and views become uncompiled.
The nolink option can save several minutes to hours. Use it when you apply several patches or when you plan to relink or regenerate the affected Applications (using AD Administration) after you apply a patch. Note: Be sure to always link AD and FND.
The nogenform and nogenrep options can save several minutes to hours. Use them in the same way that you use nolink.
AutoPatch can use parallel workers for all database tasks and for specific file system tasks such as forms generation.
Choose the number of workers appropriate for the machine, load and type of tasks.
You can also distribute the processing load to other nodes in your system by using Distributed AD. See the Distributed AD section of this note for additional information.
If you find that a certain phase could benefit from fewer workers, then use the AD Controller option "Tell worker to shut down/quit". When it is appropriate to increase the number of workers, restart the worker using the "Tell manager to start a worker that has shut down".
12.Merge NLS (Translation) Patches and Apply Them During Uptime
If you have multiple patches for multiple languages, merge all US patches into a single patch. Then, merge the NLS translation patches for each active language in your system into a single patch for each language. Apply the US patches first during downtime. Then, you can apply the merged NLS translation patches during uptime.
