Prepare

Use adop phase=prepare sync_mode=delta. Sync_mode=delta is a new feature delivered in AD-TXK Delta 8. It is much faster than the previous sync_mode = patch. The new sync_mode=delta takes about 4-10 minutes on TruTek test servers. If the previous patch cycle was aborted, then FS_CLONE is run during the next prepare. The prepare phase can fail due to long running concurrent requests that are incompatible with the ADZDPATCH concurrent program.

FS_CLONE

Will copy all files including customizations and configurations – takes about 1 hour 40 minutes.Typiically, fs_clone only needs to be run after an abort. The usual sequence would be:

abort

cleanup (full)

fs_clone

Apply

We tested three apply modes: normal (default), hotpatch and downtime.

We found that downtime patching works, but the system must be down and the patch needs to be tested first in a test environment. Using hotpatch when the patch is not a hotpatch can result in a hung patch that can’t be aborted and can also cause an abandoned node. Neither downtime or hotpatch mode use an adop patch cycle and therefore cannot be aborted. Hotpatch mode requires the WebLogic Admin server to be running.

Finalize

Finalize prepares for the cutover by compiling invalid objects. This helps reduce the time cutover may need.

We found that if developers are applying hot custom code during finalize, that the compilation of objects can take a very long time (19 hours in one test)

Cutover

This is the most sensitive phase in ADOP for several reasons:

Users are not able to work during this phase, so the downtime needs to be very predictable

Any underlying code changes that affect tables, materialized views, and other objects may require the regeneration of logical views for tables, and regeneration of materialized views. The regeneration of materialized views from logical views is accomplished fairly quickly, however, repopulating the materialized view can take hours. I don’t think it is possible to prevent the regeneration of MVs, but we need to be able to predict the time it will take to regenerate MVs and other objects, so we can accurately advise the users/business of the downtime associated with each cutover.

The running concurrent requests need to be documented before we shutdown the concurrent managers. The ICM must also be shutdown. Otherwise, the cutover can take several hours to complete. This is because cutover waits for running concurrent requests to complete. It’s better to work with the business users and ask them to put long running requests on hold, before cutover starts.

We tested the cm_wait parameter (units are minutes). We found that no new requests were started, but the Internal Concurrent Manager is not shutdown/stopped. It took a long time for associated database sessions to be terminated.

Cleanup If a patch cycle has failed, it is possible to abort the patching cycle and return to normal runtime operation. Abort can be run for Prepare, Apply, Finalize, and Cutover phases. The abort command can only be used before successful completion of the cutover phase. After cutover, the system is running on the new edition, and abort is no longer possible for that patching cycle. An abort of prepare, apply or finalize, if complete on the master node and it fails on a slave node, will cause an abandoned node. There are two solutions: first, detach and re-attach the abandoned node. This can be very time consuming. If you have a “pairsfile” created ahead of time this can be done fairly quickly. There is also a  solution (undocumented on MOS) that has worked in all test cases, that requires shared disk on the apps tier. This solution is an update to the AD_ADOP_SESSIONS table, followed by an FS_CLONE.

Abort

This phase seems to be the easiest, and the patch session will determine if the cleanup needs to be standard or full. You can specify quick, but we’ve found it’s safest to let the cleanup determine what mode to use. If the proper mode is not used, then cleanup may be run during the prepare( followed by a fs_clone), extending the time for prepare.