Prepare: This syncs the current patch file system with run file system, to make sure patch file system is up to date compared to run file system and ready for the patches to get applied. This also created a new patch edition in the database. This syncing process is incremental process to be efficient.
1. Verifying data dictionary
2. Validating system is ready to prepare.
3. Detecting configuration changes
4. Detecting ad/txk codelevel bumpup
5. Checking for pending cleanup actions
6. Validating database is ready to prepare.
7. Starting Apps listener -- will be already running
8. Submitting ADZDPATCH concurrent program
This request is waiting to be processed by the Conflict Resolution
Manager. This request cannot yet begin execution because other requests
may conflict with it. The Conflict Resolution Manager will determine when
this request may begin execution. User SYSADMIN submitted this request on
09-FEB-2019
9. Creating database patch edition
10. Synchronizing patch filesystem with run filesystem.
[1] SINGLE PATCH (DRV=u27984039.drv): 27984039
SYNCHRONIZATION is in progress
11. Stopping services on patch file system
- Stopping admin server -- already shutdown
- Stopping node manager -- already shutdown
12. The prepare phase completed successfully.
- Prepares the system for patching cycle.
- Creates the Database Patch Edition
- Validates system configuration
- Check & Submit Concurrent Request 'Online Patching In Progress'(ADZDPATCH)
- Prepare is run on all nodes in a mute-node configuration
- Synchronizes the Run and Patch File System
- If cleanup was not executed in previous adop cycle it will also run Cleanup.
1.Checks whether to perform a cleanup, which will be needed if the user failed to invoke cleanup after the cutover phase of a previous online patching cycle.
2.Validates system configuration to ensure that the system is ready to start an online patching cycle.
3.Checks to see if the database is prepared for online patching:
a)Checks if the database user is edition-enabled. If not, adop immediately exits with an error.
b) Checks to see if the patch service has been created. adop requires that a special database service exists for the purpose of connecting to the patch edition. This service is created automatically, but its continued existence is validated on each prepare.
c) Checks to see if logon trigger exists and is enabled. If the logon trigger is missing or the patch service has not been created, adop will automatically try to fix the issue so that it can proceed. If it cannot do so, it will exit with an error message.
d)Checks the integrity of the database data dictionary. If any corruption is found, adop exits with an errorease 12.2.
e) Checks that the E-Business Suite Technology Codelevel Checker (ETCC) has has been run, to verify that all required patches have been applied to the database.
4.Checks system configuration on each application tier node. A number of critical settings are validated to ensure that each application tier node is correctly registered, configured, and ready for patching.
Checks the file system, using the TXK script $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl. This script checks for the file system space, database connections, Apps/System/Weblogic Passwords, Contextfile Validation and so on
And it also Produces a report showing information about the most important tablespaces is generated. This report is created in $APPL_TOP/admin/$TWO_TASK/out.
5.Checks for the existence of the “Online Patching In Progress” (ADZDPATCH) concurrent program. This program prevents certain predefined concurrent programs from being started, and as such needs to be active while a patching cycle is in progress (that is, while a database patch edition exists).
The flow of process is
a.If the ADZDPATCH program has not yet been requested to run, a request is submitted.If it does not exists ,below error is reported
ERROR at line 1:
ORA-20008: No Concurrent Manager is defined that can run concurrent program
ADZDPATCH
b.The status of ADZDPATCH is determined. If it is pending, it may be waiting for an incompatible program to finish. After the incompatibility is clear, its status will change to running, and it will allow the prepare phase to proceed. A message to this effect is displayed to the user.
c.The next stage depends on whether the concurrent managers are running:
i.If the concurrent managers are all down, the prepare phase continues, with ADZDPATCH entering a status of pending (with the highest priority) until the managers are started.
ii.If the concurrent managers are partially up, but there is no manager defined that can run ADZDPATCH, then the prepare phase will exit with an error.
iii.If the concurrent managers are up, and there is one defined that can run ADZDPATCH, processing will loop until ADZDPATCH changes status from pending to running . The prepare phase then continues.
ADZDPATCH is cancelled when the cutover phase is complete.
If you want any custom program not to run in patching cycle ,you will have to make it incompatible with this program.
6.Invokes the TXK script $AD_TOP/patch/115/bin/txkADOPPreparePhaseSynchronize.pl to synchronize the patches which have been applied to the run APPL_TOP, but not the patch APPL_TOP. The script depends on the adop repository for patches that have been applied on the run APPL_TOP but not the patch APPL_TOP.
it Identify the patches that were applied to the run APPL_TOP and apply them to the patch APPL_TOP. The following steps are performed automatically:
a.The patches that need to be applied to the patch APPL_TOP are identified from the database.
b.The merged patches are applied by the adop utility.
The adop utility identifies the delta patches to be applied, and applies them silently to the current patch APPL_TOP. As this procedure only requires the application of delta patches, it requires less time
In some circumstances, the delta-style (incremental) synchronization method may fail when applying a series of patches to the patch edition. This can happen if the previous patching cycle included patches that failed to apply correctly, and was followed by subsequent patches that corrected the issue.
The skipsyncerror parameter enables you to specify that you expect any synchronization errors in the prepare phase to be fixed automatically in the synchronization that takes place with subsequent patches.
If the value of the parameter is passed as ‘yes’, the first patch to be synchronized will be done with the ‘autoskip’ flag set.
Important: It is your responsibility to check the log files and correct any errors in the subsequent apply phase, or to confirm that synchronization with subsequent patches resolved the issue.
An example of using this parameter would be as follows.
a.You run adop phase=prepare.
b.The phase fails with an error when trying to synchronize the run and patch file systems. That is, the attempt to synchronize a patch fails, but it is known that a subsequent patch will correct the problem.
c.You examine the log files and conclude that the synchronization errors will be fixed automatically in the synchronization that takes place with subsequent patches.
d.You run the command adop phase=prepare skipsyncerror=yes to restart the prepare phase. This time, application of the patch that failed in the previous prepare will be retried with the ‘autoskip’ flag set.
Synchronizing Customizations
The default delta-style (incremental) method of file system synchronization handles official patches but will not synchronize any manually applied customization. Examples of patching actions that are not synchronized by default include:
Compiling user-defined JSPs
Copying some third-party libraries
Copying and compiling user-defined concurrent programs
Copying and generating user-defined forms
To include custom patching actions in the default file system synchronization, you must include the required commands in the Custom Synchronization Driver, $APPL_TOP_NE/ad/custom/adop_sync.drv. You will add your customizations to the following section of the file:
#Begin Customization
…
#End Customization
All the actions defined in this file will be performed by adop automatically during the prepare phase. Be aware that there are two categories of custom command in adop_sync.drv: those that are run one time only, and those that are run at each file system synchronization (during the adop prepare phase).
Important: The adop_sync.drv file is not currently reset to its template file at any point. Consequently, after cutover (and before the next prepare phase), you should review the contents of adop_sync.drv and ensure the requirementns for your custom commands continue to be met.
7.Checks the database for the existence of a patch edition, and creates one if it does not find one.
a)A patch edition is created in the database.
b)All code objects in the patch edition begin as pointers to code objects in the run edition. Code objects in the patch edition begin as lightweight “stub objects” that point to the actual object definitions, which are inherited from earlier editions. Stub objects consume minimal space, so the database patch edition is initially very small in size.
c) As patches are applied to the patch edition, code objects are actualized (have a new definition created) in that edition.
8.Calls the $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl script again to confirm that the database connection to the patch edition is working.
Apply phase:
1. It will check for Run Edition context file :
2. It will check for Patch edition context file:
3. It will check for Patch file system free space.
4. Shut down the application tier services
5. Run the following commands in the order shown
$AD_TOP/patch/115/sql/ADFIXUSER.sql
@ $AD_TOP/sql/adutlrcmp.sql
6. Checking for existing adop sessions.
Continuing with existing session
7. Applying patch
- Patches are applied in this phase.
- Adop internally calls adpatch to apply the patches, but we cannot run adpatch utility as standalone in R12.2 .
- Patches are applied in the Patch Edition.
- Application user are connected to RUN edition and they are not impacted by patching cycle.
- We can apply multiple patches in a patching cycle.
Patches are applied to the copy (Patch Edition)
The production application is unaffected by the changes
Users are connected to the Application and can perform their work unaffected by the patch
Changes are made in the isolation of an Edition
The running application is unaffected by these changes.
Finalize Phase:
1. It compile invalid objects
2. It generate derived objects
3. We can run Finalize phase in ‘quick’ mode or ‘full’ mode where ‘quick’ mode is the default mode.
4. It is recommended to be done explicitly in order to reduce cutover (downtime) phase time
5. In this phase adop patching cycle can be pause as long as required, because after this finalize phase we need to run cutover where downtime required.
- Ready the system for Cutover.
- Compile Invalid objects.
- If we don't run finalize, then the cutover phase will call finalize automatically before doing the actual cutover. But that will increase the downtime window for the cutover.
- Computes any DDL to be executed before the cutover.
Cutover phase: This is downtime phase.This ensure ,ready to commit to application of the selected patches.Once cutover is complete, it is not possible to revert to the previous edition.
1. First it performs the ADOP validations on all of the application nodes
2. When we run the Cutover Phase all the users will be logged off the system including the third party applications.
3. First it will bring down the Application Services and then will start up the Application Services.
4. After the start up the Patch file system and Run file system will be switched over like patch file will be Run fs and Run fs will be Patch fs.
5. Even the Patch database edition will be promoted to be the Run database edition
6. It will terminates ‘ADZDPATCH’ concurrent program which was started in prepare phase.
- Switches to the patch edition of database and file system.
- In the phase, the system actually goes down.
- All application tier services are stopped and starts after the cutover.
Following steps in this phase:
1) Shut down internal concurrent manager: The adop utility signals the internal concurrent manager to shut down, but will wait for any existing concurrent requests to finish before it proceeds with cutover actions. The system is still available to users during this waiting period.
If you do not wish to wait indefinitely for concurrent requests to finish, specify the option cm_wait=<maximum_minutes_to_wait> with a number of minutes that reflects your operational needs
On production systems, do not specify cm_wait, but monitor progress of concurrent tasks and take manual action on them if needed.It is good to schedule cutover during the time where least jobs are running.
On non-production systems, we specify cm_wait to limit the waiting time before cutover proceeds as it is development and we can tolerate abort of Concurrenyt Manager
Note: Cutover will take longer if it has to wait for long-running concurrent processes to complete. In such a case, you can expect to see an informational message of the form:
[STATEMENT] [END ] Waiting for ICM to go down
If you do not want to wait for in-progress concurrent requests to finish normally, you can terminate the internal concurrent manager by executing the adcmctl.sh abort command from a different shell
4) Cutover file system: Promote patch file system to become the new run file system, switching the $FILE_EDITION values in the patch and run enviroments. The current patch APPL_TOP becomes the new run APPL_TOP, and the current run APPL_TOP becomes the new patch APPL_TOP.
This task is completed by Autoconfig
5) Terminate old database sessions: Terminate any database connections to the old run edition of the database.
This task is performed by $FND_TOP/bin/txkADOPCutOverPhaseCtrlScript.pl script
6) Start application tier services: Application tier services are restarted, on the new run edition. The system is now available again to users.
This task is performed by $FND_TOP/bin/txkADOPCutOverPhaseCtrlScript.pl script
Example .
$ adop phase=cutover
This will promote the patch edition to be the new run edition, as well as switching the patch and run labels on the file systems (and thereby, as noted above, changing the patch file system to be the new run file system and the run file system to be the new patch file system).
Deferring Application Tier Restart at Cutover
Many times you may need to perform additional manual steps after cutover but before restarting the application tier services. If this is the case, you can supply an additional parameter to the cutover command that causes the application services to remain shut down:
$ adop phase=cutover mtrestart=no
With this parameter, cutover will complete without restarting the application tier services. You can perform any additional steps that require the services to be shut down, and then start the application tier services manually using the adstrtal.sh script.
JAR Files and Cutover
In an online patching cycle, the requisite JAR files are initially stored in the $APPL_TOP/admin/<SID>/out directory, and then uploaded into the database during the cutover phase. Therefore, the out directory must not be deleted at least until cutover is complete.
This task is performed by $FND_TOP/bin/txkADOPCutOverPhaseCtrlScript.pl script
2) Shut down application tier services: All application tier services are brought down. During this period, the system is unavailable to users.
This task is performed by $FND_TOP/bin/txkADOPCutOverPhaseCtrlScript.pl script
3) Cutover database: Promote patch database edition to become the new run database edition, using adzdpmgr.pl script.
This task is performed by $FND_TOP/bin/txkADOPCutOverPhaseCtrlScript.pl script
what happenes during cutover?
All the patching is done in online way. We just need to small downtime which is called cutover to complete the whole patching
During cutover ,these things happens
– Users are logged off the system
– The Patch file system is promoted to be the Run file system
– The Patch database edition is promoted to be the Run database edition
– Perform final maintenance operations
– Users are brought back online on the patched system.
Cleanup Phase:
- Cleans up old edition and objects.
- Recovers space.
No comments:
Post a Comment