Stat 6.2 - User Guide

Environment History Tab

The Environment History tab displays a record of all the patch application, patch backout, and impact analysis requests that are either pending or have been completed in each active environment.

If any of the environments displayed in the Environment History tab have been refreshed, you can view the information in the tab in either a state-based or activity-based format. A state-based report takes into account changes made to an environment due to a refresh event. It shows the impact analyses and patches that have been applied to an environment at a particular moment in time. This is in contrast to activity-based reports that show all the impact analyses and patches that have been applied to an environment, even those that have been overwritten due to a refresh event. For more information on environment refresh events and state-based and activity-based reporting, see Change/Service Requests .

The Environment History tab also features an Impacted Objs. button, which functions the same way as the Impacted Analysis button described in the section, Process Request Tab .

To switch the view between patch application, backout, or impact analysis requests, click Patch Apply or Impact Analysis. Patch backout requests are displayed with patch application requests. To switch between state-based and activity-based reporting, select the corresponding check box.

In the Environment History tab, the Process Status column shows if AutoPatch encountered an error when processing a patch. Possible statuses include Completed, Completed with Warnings, and Completed with Errors (Pending requests have a status of Pending/New, Sent to Agent, Received by Agent, or In Process. The status Not Processed means AutoPatch failed the process event before processing the driver). There are many reasons why AutoPatch may fail to process a patch, some of which are trivial and can be disregarded. However, because failed patches are treated differently by other functions within Stat (such as environment compare), you can manually change the status of a patch if you determine the reasons it failed are insignificant (as indicated in the AutoPatch log file). You may also want to assign a patch that completed successfully an error-type status. This feature works in conjunction with manually changing the status of process events and patch driver files. To properly change the status of a patch, users must also change the status of the process event and associated driver files, in addition to the patch itself. For more information, see Changing Process Event Statuses and Viewing Patch Approvals and Patch Drivers .

You can view driver files or approval information concerning a patch application or backout request by right-clicking it and in the pop-up menu selecting either View Patch Approvals or View Patch Drivers. The Patch Approvals window shows the name of each user that has approved the patch, if any, and the date when the approval was made. The Patch Drivers window shows the driver files that were processed when AutoPatch executed the patch application request.

In the Patch Drivers window, the Process Status column shows if AutoPatch encountered an error when processing a driver file. Possible statuses include Completed, Completed with Warnings, and Completed with Errors (Pending requests have a status of Pending/New, Sent to Agent, Received by Agent, or In Process. The status Not Processed means AutoPatch failed the process event before processing the driver).

There are many reasons why AutoPatch may fail to process a driver file, some of which are trivial and can be disregarded. However, because patches with driver files that failed to process may be treated differently by other functions within Stat (such as environment compare), you can manually change the status of a driver file if the reasons it failed to process (as indicated in the AutoPatch log file) are insignificant.

You may also want to assign a patch that completed successfully an error-type status. This feature works in conjunction with manually changing the status of process events and patches. To properly change the status of a driver file, users must also change the status of the process event and the patch, in addition to the driver files. For more information, see Changing Patch Process Statuses and Changing Process Event Statuses .

Rescheduling Requests

If the Stat Central Agent is for some reason unable to process your patch application or impact analysis request (for example, because the server that hosts the target environment is down), you can reschedule the request and have the Agent process it a second time. You can initiate a reschedule request from the Process Request tab of either the Oracle Applications Management Console or the CSR window.

IMPORTANT: AutoPatch can report a patch process request as having failed for several reasons, some of which are trivial and can be disregarded. If a patch request is reported as having failed but has in fact been successful (as determined by the agent log file), instead of rescheduling the request, you can manually change its status from Complete with Errors to Complete Successfully. For more information, see Changing Process Event Statuses .

Changing Process Event Statuses

A process request may fail for several reasons, some minor and others critical. Stat does not distinguish between minor and critical process event errors. In either case, the event receives a Complete with Errors process status. However, because certain functions within Stat (such as environment compare) treat failed process requests differently than requests that were processed successfully or with warnings, you can manually change the status of a process request event that failed for minor or insignificant errors so that it will be treated as having been processed successfully. After changing a status, you must explain the reason why you making the change. This explanation is then written to the Agent log file for auditing purposes.

NOTE: Changing the status of a patch-related event does not change the status of the patch itself or its associated driver files. An Apply Patch or Patch Impact event may include multiple patches, in which case changing the event to Completed does not change the associated patches or drivers to Completed. This is because the event may have failed for a reason other than a patch or driver failing. To properly change the status of a process event, you must also change the status of the patch and its associated driver files, in addition to the event. For more information, see Changing Patch Process Statuses and Viewing Patch Approvals and Patch Drivers .

Backing Out Patches

When a patch is applied to an environment, an archive of all impacted objects is automatically taken from the target environment. If after applying a patch to an environment you decide that you want to return the impacted file objects and schema objects to their original, ‘pre-patch’ state, you can use Stat’s Patch Backout feature.

With Patch Backout, you can restore file objects and the following schema object types: tables, views, indexes, packages, and sequences. However, some changes may not be recovered, while others may be impossible to recover due to transactional activity during or after the patch was applied. Also, new schema objects inserted into an environment by way of a patch may not be deleted.

IMPORTANT: The Patch Backout feature is intended to augment, not replace established IT practices for system backups. The Backout feature does not provide a full system recovery from a patch. If a full system recovery is desired, standard backup and restore procedures should be used.