1. 程式人生 > >Oracle官方adop,admrgpch工具介紹文件

Oracle官方adop,admrgpch工具介紹文件



Patching Utilities

The adop Utility

You use the adop (AD Online Patching) utility to apply patches to the Oracle E-Business Suite file system or database. You can either allow adop to prompt for the information required to apply a patch, or enter the information without being prompted. Whichever method you choose, adop will then perform the tasks required to apply the patch:

  • Reads patch metadata to determine patch dependencies and requirements

  • Uploads patch information from a prior patch session to the database (if applicable)

  • Reads and validate the patch driver file and reads the product driver files

  • Compares version numbers of object modules from the product libraries and version numbers of the existing files against the patch files

  • Backs up all existing files that will be changed by the patch

  • Copies files

  • Archive files in libraries

  • Relinks executables

  • Generates forms, reports, messages, graphics, and Java archive (JAR) files

  • Compiles JSP files and invalid database objects

  • Updates database objects

  • Runs AutoConfig to update configuration files if any template files are introduced or updated by the patch

  • Saves patch information to the database

Be aware of the following important points about adop:

  • The adop utility always runs from the run edition file system. It automatically sets its environment correctly, regardless of the edition it is run from. Editions are described in more detail later.

  • If a patch contains no new updates to files or database objects in your system, adop takes no action.

  • If adop detects a previously failed patching session, it will attempt to recover that session.

adop Parameters

Run from the command line, adop accepts many parameters. Some are required, while others are optional. Some parameters override other parameters, and some have a higher order of precedence over others. All the parameters must be entered in name=value pairs.

adop Parameters
Parameter Purpose Values Comments
phase Used to tell adop which phases it is to run.
  • prepare

  • apply

  • finalize

  • cutover

  • cleanup

  • fs_clone

  • abort

    actualize_all

You can use a comma-separated list to specify multiple phases. For example, 'phase=prepare,apply'

Note: Neither the abort nor fs_clone phases can be specified with any other phase.


If you supply a phase other than those listed, a usage statement will be printed and adop will exit.
loglevel Used to specify the amount of information logged and displayed as adop performs its operations.
  • STATEMENT

  • PROCEDURE

  • EVENT

  • WARNING

  • ERROR

  • UNEXPECTED

  • STATEMENT is only used for debugging.

  • PROCEDURE is only used for debugging high level procedures.

  • EVENT is used to display informational messages in normal processing. This is the default value.

  • WARNING is used to indicate an internal error that is handled by the system and does not affect processing.

  • ERROR indicates an action failed and will need to be reviewed by the user, but the system was able to continue processing.

  • UNEXPECTED indicates an unrecoverable error that halts processing and requires user intervention before processing can continue.

apply_mode Allows patches to be applied in downtime or hotpatch modes, by adding the relevant option to the adop phase=apply command.
  • online (default)

  • downtime

  • hotpatch

apply_mode=downtime applies the specified patches in downtime mode. When using this mode, you only run the apply phase.
apply_mode=hotpatchapplies the specified patches in hotpatch mode. When using this mode, you only run the apply phase.

Important: The downtime and hotpatch modes should only be used where directed by the patch readme or other documentation.

cleanup_mode Provides cleanup processing control.
  • quick

  • full

cleanup_mode=quick performs minimum cleanup, which includes removal of crossedition triggers and obsolete seed data.
cleanup_mode=full does the same as standard mode, and also drops obsolete columns and old editions.
finalize_mode Specifies the processing to be performed in the finalize phase.
  • full

  • quick

finalize_mode=full gathers statistics to help improve performance. If you specify this mode, allow extra time (about an hour) for finalize to complete.
finalize_mode=quick does not gather statistics, and therefore completes more quickly. This is the default.
input_file Used to specify the name of the input_file supplied to adop. User-specified. Must be an absolute file path.
maxworkers Used to override the default formula calculation for the number of workers. User-specified. For example, if the default calculation gives 30 workers, but the desired number of workers is 50, adop can be run by specifying workers=50 maxworkers=60
maxworkers should always be set to greater than the desired number of workers, so the default value is overridden.
patches Used to specify the patches adop is to apply. User-specified.
Patches can be specified in two ways:
  • <Patch Number>:

    For example, to apply patch number 123456 you would specify 'patches=123456'.

  • <Patch Directory>: <Patch Driver File>:

    For example, to apply the Korean language translation for patch 123456 you would specify 'patches=123456_KO:u123456.drv'. Note that patch directory is relative to the $PATCH_TOP.

You can use a comma-separated list to specify that multiple patches are to be applied in the same patching operation. The numbered-only and containing-a-colon categories of patch can be mixed.
For example, you would specify patch number 111 and the Korean language version of patch 222 as 'patches=111,222_KO:u222.drv'.
hotpatch Specifies whether the patches are to be applied in hotpatch mode. yes/no hotpatch=yes applies the specified patches to the run edition while this edition is in active use.

Important: Only use hotpatch mode if support for doing so is explicitly stated in the patch readme.

flags Used to specify numerous options. To see a full list, enter:
$ adop -examples

The flags typically exist in pairs, such as autoskip/noautoskip
: Using the example of autoskip/noautoskip: this pair of flags is used to specify whether adop should quit if there is a driver action failure when applying a patch. Using the example of autoskip/noautoskip: the default is noautoskip (quit processing). You can force processing to continue by specifying flags=autoskip on the command line or in the input file.
prompt Specifies whether adop prompts the user whether to continue after warnings. yes/no Default is 'yes' (prompt the user). Set prompt=no to enable fully non-interactive mode, in which adop will continue past warning messages without user confirmation.
options Used to specify various options during the apply phase. See "adop Options" section later this this chapter. option-specific Refer to individual options.
cm_wait Can be used when running cutover to specify how long to wait for existing concurrent processes to finish running before shutting down the Internal Concurrent Manager. User-specified integer representing number of minutes to wait. By default, adop will wait indefinitely for in-progress concurrent requests to finish.
workers Used to specify the number of parallel workers to be employed. User-specified integer. If you omit the 'workers' argument, a suitable number of workers will be be chosen automatically.
If you specify more workers than the machine can handle, adop will exit with an error.
defaultsfile Used to specify the path to the custom adop defaults file. User-specified (but has a default value - see next column). Must be an absolute file path. Defaults to $TWO_TASK if not specified by user.
patchtop Used to specify the location where the patches are unloaded. User-specified (but has a default value - see next column). Must be an absolute file path. Defaults to $APPL_TOP_NE/EBSapps/patch if not specified by user.
merge Used to merge multiple patches. You can merge the unified driver files into a single driver file that is passed to adop. yes/no If merge is set to the default of 'no', then the patches are applied sequentially in the order listed. You can set the merge parameter to 'yes' in order to merge a base patch with any required corrective patches, so that the corrected merge patch is applied as a single operation.
abandon Specify whether to abandon a previous failed attempt to apply a patch. Use this mode if you want to continue with the online patching actions even though a patch apply has failed.

Note: If there was an error in the previous run, and 'abandon' is not set to 'yes', the same parameters will be re-used that were used in the failed run.

yes/no Default value is 'no'. You cannot set the abandon parameter to 'yes' if the restart parameter is also set to 'yes'.
restart Specify if the previous failed patch apply should be restarted. This allows you to retry applying the previous patch from where it left off. This is useful if you were able to correct the cause of the error and want patch application to continue executing. yes/no Default value is 'no'. You cannot set the restart parameter to 'yes' if the abandon parameter is also set to 'yes'.
skipsyncerror Enables the user to specify that any synchronization errors in the prepare phase are expected to be fixed automatically in the synchronization that takes place with subsequent patches. yes/no Default value is 'no'. Set the value to 'yes' in order to work around synchronization failures that may occur when patches that failed to apply correctly in a previous patching cycle are synchronized during the prepare phase.
mtrestart Used to specify whether to restart application tier services after cutover. yes/no Default value is 'yes'. If 'no' is specified, the services can later be restarted with the the adstrtal utility.
allowcoredump Used to specify that a core dump should be generated if adop crashes. yes/no Default value is 'no'. A value of 'yes' should be specified only if diagnostic information needs to be gathered.
analytics Used to generate reports that can be helpful in debugging certain types of issue. Available with apply, finalize, cutover, and cleanup adop phases. yes/no Default value is 'no'. A value of 'yes' should be specified only if reports specifically need to be generated. This is because of the extra processing overhead involved.

Online Help

To obtain help about the basics of adop operation, enter the command:

adop -help

The help usage statement will also appear if you supply an invalid parameter on the adop command line.

Optionally, you can also display examples of the various adop parameters by entering the command:

adop -examples

The Input File

adop also accepts parameters in an input file. From the command line, you specify an input file by using the parameter input_file=<myinput.txt>, where myinput.txt is the name of your input file.

Input File Parameters

Note: You should always provide the full path to the input file.

Major parameters that can be specified in the input file include:

patches
phase
patchtop
merge
defaultsfile
abandon
restart
workers

Input file parameters must appear in name=value format, with one parameter per line. For example:

phase=apply
patches=123456
workers=8
autoskip=yes

Note: If you supply a parameter to the input file twice (for example, workers is defined on both lines 2 and lines 5 of your input file), the last definition (in this example, on line 5) will be used.

The Defaults File

Parameters can also be passed to adop into adop through a defaults file.From the command line, you can specify a defaults file by using the parameter defaultsfile=<mydefaults.txt>, where mydefaults.txt is the name of your file.

Your own defaults file will be checked the validity of its contents, and if issues are found an error will be raised. If you do not specify a custom defaults file, adop will use the one that is automatically generated by the system (using AutoConfig).

If adop is being run in hotpatch mode, your own defaults file should be located on the run file system, under $APPL_TOP/admin/$TWO_TASK. Otherwise, the defaults file should be in the same location, but on thepatch file system.

Note: Instead of using your own defaults file, it is generally preferable to supply your own parameters via the command line or in an input file. Parameters supplied in either of these ways take precedence over parameters in the the defaults file.

Parameters In Defaults File

Only one parameter, patchtop, can currently be defined in the defaultsfile. This parameter is used to specify the location where patches are unloaded. The default patchtop directory is on the non-editioned file system, at $NE_BASE/EBSapps/patch.

If you wish to use the patchtop supplied in the defaults file, you must specify the defaults file as a parameter either on the command line or in the input file. If you do not specify the defaults file in one of these two locations, the file will not be read and the defaults file patchtop will not be used.

Order of Parameters

As described above, most parameters can be defined in at least two locations, with patchtop able to be defined in three different locations. If multiple different definitions are specified, the following order is used.

  1. Command Line: An adop parameter specified on the command line will take precedence over all others.

  2. Input File: An adop parameter given here will only be lower in precedence to a parameter specified on the command line.

  3. Defaults File: Parameters defined here have the lowest level of precedence.

Important: Because you can supply higher-priority parameters on the command line and in the input file, you should never need to edit the defaults file.

Patch Log Files

It is advisable to review the relevant log files after any patching operation. The adop log filesare located on the non-editioned file system (fs_ne), under:

$NE_BASE/EBSapps/log/adop/<adop_session_id>/<phase>_<date>_<time>/<context_name>/log

For example, if s_ne_base was /u01/R122_EBS/fs_ne, the session ID was 15, and the <CONTEXT_NAME> was patch01_testsys, the path to the adop log files from 9th July 2014 would resemble this:

/u01/R122_EBS/fs_ne/EBSapps/log/adop/15/apply_20140709_112226/patch01_testsys/log

Patch Log File Directory Structure

the picture is described in the document text

Note: The environment variable for s_ne_base is called $NE_BASE.

Other log files are created for specific purposes, for example, to record all the actions associated with parallelworkers.These worker log files are written to the non-editioned file system, under EBSapps/log/adop/<adop_session_id>/<phase_timestamp>. For example, /u01/R122_EBS/fs_ne/EBSapps/log/adop. Review these files when the patching session is complete.

Other AD log files include those shown in the following table:

Non-adop AD Log Files
Log File Used For
adrelink.log Relinking
adlibin.log Moving C object files into the C library of a product
adlibout.log Moving C object files out of the C library of a product
adworkxxx.log Database operations run in parallel
<language>_<filename>_ldt.log Seed data loader files

If adop does not perform an action, it does not generate the log file associated with that type of action.

Note: You can also review log files using the View Log Files feature of OAM Timing Reports. See:View Log Files.

JAR File List

In the apply phase of an online patching cycle, adop creates a file called jarlist.txt. This file is provided in case you wish to perform your own JAR file signing using a very secure certificate. In such cases, you will need to specify the adop command line parameter option=nojarsigning in order to bypass the standard JAR file signing activity that will otherwise performed by AD.

The jarlist.txt file is placed in the same directory as the patch log file. The following example is for patch 13358502, which was applied during a patching session that had ID=14: $NE_BASE/EBSapps/log/adop/14/apply_20130515_125116/testenv_sys3220410/13358502/log/jarlist.txt.

Sessions

The adop utility maintains a session for each online patching cycle. A new session is created when you run the prepare phase. Each session is given a numeric ID number. The session is used to maintain the state of the online patching cycle across the various adop phases and commands. You can only run one adop session at a time on a particular Oracle E-Business Suite system.

Patch Directory (Patchtop)

The directory where the patch files have been unzipped is referred to as the patchtop. The default patch top directory is $NE_BASE/EBSapps/patch, which is pointed to by the $PATCH_TOP environment variable.

If specifying your own choice of directory, you must supply the full path, and the operating system user that is running adop must have write permissions to that directory. Oracle recommends using the default $PATCH_TOP direcotory.

Note: If you have a multi-node environment, you must download and unzip the patches (under $PATCH_TOP) on all the nodes.

If you want to merge patches before applying them, you need to download and unzip all the individual patches in the same location as that of the merged driver file. For example, if you merge patches 111, 222, and 333 (using AD Merge Patch), and the merged patch driver file location is $PATCH_TOP/mergetest/mergetest.drv, you should then download and unzip the individual patches as $PATCH_TOP/patch/mergetest/111, $PATCH_TOP/mergetest/222, and $PATCH_TOP/mergetest/333.

Patch Driver File

The unified driver, named u<patchnum>.drv, contains the commands necessary to change files and database objects, and to generate new objects. It contains copy, database, and generate portions and performs the copy, database, and generate actions in the stated order. The adop utility runs the unified driver on all APPL_TOPs, but only performs the specific actions that are actually required for each APPL_TOP.

Copy Portion of a Unified Driver

When the copy portion of a unified driver runs, adop performs the following actions:

  • Extracts the appropriate files from the C library of each product.

  • Compares the extracted object modules with their corresponding files in the patch directory. It also makes this type of comparison with files such as forms, reports, and SQL scripts.

  • Backs up any product file with a more recent version in the patch directory to a subdirectory in the patch directory. For example, if <patch_dir> is the patch directory, <system_name> is the applications system name, <appl_top_name> is the APPL_TOP name, and <prod> is the name of the product being patched, it backs up:

    <PROD>_TOP/<subdir(s)>/<old_file_name>
    

    to

    <patch_dir>/backup/<system_name>/<appl_top_name>/<prod>/<subdir(s)>/<old_file_name>
    

    Note: The Applications system name and the APPL_TOP name are determined during the Rapid Install process.

  • Replaces the outdated files of each product with newer files from the patch directory.

  • Loads the new object modules into the C libraries.

  • Relinks the Oracle E-Business Suite products with the operating system, Oracle server, and other Oracle products libraries.

  • Applies changed Java class files and regenerates JAR files as needed.

  • Copies any specified HTML or media files to their respective destinations.

  • Compiles out-of-date Java Server Page (JSP) files (if any JSP files are included in the patch).

Database Portion of a Unified Driver

When the database portion of a driver runs, adop performs these actions:

  • Gets a list of current invalid objects in the APPS schema.

  • Determines whether the action was performed in a previous patch.

  • Runs SQL scripts and EXEC commands, which change Oracle E-Business Suite database objects. By default, adop runs scripts and commands in parallel.

  • Compiles invalid objects in the database.

  • Assembles a list of current invalid objects in the APPS schema.

Generate Portion of a Unified Driver

When the generate portion of a driver runs, adop performs these actions:

  • Generates Oracle Forms PL/SQL library files

  • Generates Oracle Forms menu files

  • Generates Oracle Forms executable files

  • Generates Oracle Reports PL/SQL library files

  • Generates Oracle Reports files

  • Generates message files

  • Generates Oracle Workflow resource files

Number of Parallel Workers

By default, adop runs database updates and file generation commands in parallel using multiple workers. The default number of workers is computed based on the system hardware configuration, but the number can be specified explicitly using the 'workers' parameter. Tasks are assigned to workers, the workers run the tasks to completion, and adop assigns new tasks.

adop runs (adop) all database actions based on phase order, a grouping of actions in the database portion of the patch that minimizes dependencies. This order is not necessarily the order in which the commands are listed in the database portion of the patch driver.

Note: For more information, see Using Parallel Processing in the Maintenance section of this book.

Customized Files

adop reviews the AD_FILES table to determine if anycustomized files (Register Flagged Files) will be replaced by the patch. If so, it displays a message listing the customized files it will replace.

Note: For more information, see Customization Standards,Oracle E-Business Suite Developer's Guide, and Register Flagged Files.

NLS

If the patch you are applying has an NLS-related version, and if you are an NLS customer, adop prompts you about the NLS-related version of the patch before allowing you to continue.

Principles of Non-Interactive Patching

Non-interactive patching saves time by automating the patching process. It is used with all the major phases of adop, including the apply phase.

The adop utility runs non-interactively by default. You must specify all required parameters for each adop command, either on the command line or in an input file.

After the patching actions are complete, you perform any post-patching steps listed in the patchreadme file. See Performing Non-Interactive Patching,Oracle E-Business Suite Maintenance Guide.

Messages

adop generates several types of messages. Each message is recorded in a log file. SeeLog Files for a list and descriptions.

Informational Messages

Informational messages are written to the informational message file. This log file uses the same base file name as the main adop log file, but substitutes a .lgi extension for the .log extension. For example, if the adop log file is named u1234567.log, the adop informational log file is named u1234567.lgi.

For example, adop writes information pertaining to the files not updated because they are up-to-date in the informational log file.

File will not be copied to destination.

Version check:
/slot03/appmgr/prodappl/ad/12.2/xml/oam/patch/history/SearchFiles.uix
version is equal to or lower than
/slot03/appmgr/prodcomn/html/oam/patch/history/SearchFiles.uix.
File will not be copied to destination.

Version check:
/slot03/appmgr/prodappl/ad/12.2/xml/oam/patch/history/SearchFilesCriteriaAdvanced.uix
version is equal to or lower than

/slot03/appmgr/prodcomn/html/oam/patch/history/SearchFilesCriteriaAdvanced.uix

Error Messages

When adop is using parallel processing and an error occurs, the job fails. Review the main adop log file and the adworkxxx.log file to determine the source of the error, resolve the issues and continue. Restart adop using the adctrl command.

Note: See Monitoring and Controlling Parallel Processing, , for details on using the adctrl command.

If you cannot resolve the issue, you must:

  • Verify that all steps in the readme file were completed.

  • Check My Oracle Support for additional information regarding the patch you are applying.

If the message indicates that a worker has failed its job, you can fix the problem and restart the worker while the manager is running. Some failed jobs are deferred (not immediately reassigned) by the manager. These jobs do not cause the manager or otherworkers to stop.

Successful Completion Message

adop displays a success message when processing is complete. If you do not see a such a completion message, you should investigate and identify the reason.

Backup Directory

When adop runs, a backup directory is created in the directory where you unzip the patch. The old version of each file updated by the patch is copied into the backup directory. When applying large patches (such asrelease update packs, product family RUPs, and pre-upgrade patches), ensure there is enough disk space on the system where you unzip the patch, or the patching process may fail. We recommend having at least twice the amount of disk space as the unzipped patch file uses.

Tip: When there is no patching cycle in progress, you can if desired delete the files in thebackup directory to free the space.

adop Patching Modes

The adop utility is normally used execute an online patching cycle, but patches can also be applied in other modes for special situations. If these special options are available or required, they will be documented in the patch readme file or other installation instructions.

Downtime Mode

To optimize the process of upgrading to Oracle E-Business Suite Release 12.2, support is provided for the capability to apply Oracle E-Business Suite patches in downtime mode.When applying patches in this mode, adop will first confirm that the application tier services are down, and will then proceed to apply the patch to the run edition of the Oracle E-Business Suite database and file system. Downtime mode patching does not use an online patching cycle. The process of applying a patch in downtime mode completes more quickly than in online mode, but at the cost of increased system downtime.

To run adop in downtime mode, you use the following command line options. In this example, patch 123456 is applied in downtime mode:

$ adop phase=apply patches=123456 apply_mode=downtime

Important: Be aware that:

  • Release 12.2 patches are not normally tested in downtime mode.

  • Downtime mode is only supported for production use where explicitly documented, or when directed by Oracle Support or Development.

Pre-Install Mode

Pre-install mode is generally used during the upgrade process to update AD utilities, apply pre-upgrade patches, or work around other patching issues. adop asks all startup questions except those relating to the database.

Warning: Run adop in pre-install mode only if the patch readme instructs you to do so.

To run adop in pre-install mode, include preinstall=y on the adop command line. It performs the following actions:

  • Compares version numbers

  • Copies files

  • Relinks FND and AD executables

  • Saves patch information to the file system

Because adop does not read driver files in pre-install mode, it copies all product files in the patch to the APPL_TOP directory. Additionally, even if a file in the patch should be both in the APPL_TOP and in another directory (such as in $OA_HTML), adop copies the file only to the APPL_TOP.

In preinstall mode, adop validates codelevels against the files Preinstall_Codelevel_AD.txtand Preinstall_Codelevel_MP.txt. These files are located in the $APPL_TOP/admin directory, and contain codelevel information about AD and other products registered in the database tables.

Since no database connection is available in pre-install mode, adop tries to validate whether the current patch should be applied based on the codelevel information in these two files, as follows:

  • If Preinstall_Codelevel_AD.txt is missing from the APPL_TOP, adop will apply the patch in pre-install mode without validating the patch for codelevel compatibility.

  • If Preinstall_Codelevel_MP.txt is missing from the APPL_TOP, adop will proceed with patch application without validating the patch for codelevel compatibility of the entities.

  • If both files are missing, adop will not validate codelevels in pre-install mode.

Note the following restrictions when applying a patch in pre-install mode:

  • NLS patches cannot be applied on the instance.

  • Baseline or codelevel-introducing patches cannot be applied on the instance.

  • adop will not check to see if the patch is already applied on the system.

Test Mode

In test mode, adop does not apply the patch. Instead, it lists each file it would have copied, relinked, executed, or generated and shows exactly what actions it would have performed had it applied the patch. It also runs AutoConfig in test mode to determine any impending changes to the configuration files. This allows you to see the effects of the patch on your production system before you apply it.

To run adop in test mode, specify the apply=no parameter. In test mode, adop will go through the process of applying the patch but willnot perform any of the following actions:

  • Copy files from the patch directory to the Oracle E-Business Suite file system

  • Archive object modules into the product libraries

  • Relink executables

  • Generate forms, reports, PL/SQL libraries, or menu files

  • Run SQL or EXEC commands (commands that change the database)

  • Instantiate new configuration files

  • Update the patch information files

  • Update patch information and release version in the database

See: Testing a Patch Before Applying It, Oracle E-Business Suite Maintenance Guide.

adop Command Line Arguments

You can adjust the way adop operates by supplying arguments to the various parameters that adop recognizes. Arguments can be passed either directly on the command line or through an input file. adop is non-interactive (except for passwords), so all required arguments must be specified when entering an adop command.

An input file is specified as follows:

$ adop phase=apply input_file=<input_file.txt> 

Arguments are specified on the command line or input file in "name=value" format, where "name" is the adop parameter name and "value" is your specified value. Parameter names are specified in lower case, and parameter values should be assumed to be case-sensitive.

You can enter more than one token=value argument on a single command line by separating them with a single space, as in the following example.

printdebug=y flags=hidepw

In some cases, you can include more than one value for a token. When doing so, you separate the values with commas and no spaces. For example:

flags=nohidepw,trace

is valid, but

flags=nohidepw, trace

is not valid.

adop Options

The "options" argument is used to pass options that control how the patch is applied. It takes the form of a comma-separated list. Enter a single option, or a comma-separated list of options such asadop options=nocopyportion,nogenerateportion.

Note: As with adop arguments, there must be no space after the comma.

adop Options
Option Description
actiondetails Purpose: Tells adop to print details of actions taken in a patching operation.
Default: actiondetails
Specify options=noactiondetails if you do not want the details to be printed.
Comments: It is generally preferable to accept the default, as the action details can be useful in understanding adop operations and diagnosing issues.
autoconfig Purpose: Tells adop to run AutoConfig automatically.
Default: autoconfig
Use options=noautoconfig if you are applying a number of patches in sequence and want to run AutoConfig once, after applying the last patch of the sequence.
Comments: The dual file system in Release 12.2 means that there is no need to shut down application tier services before running AutoConfig.
checkfile Purpose: Tells adop to either skip running EXEC, SQL, and EXECTIER commands if they are recorded as already run, or to record them as having run after running them.
Default: checkfile
Use options=nocheckfile to turn off the checkfile feature.
Comments: This option is currently not supported unless explicitly documented in the patch readme.
If you are reapplying a patch with options=nocheckfile and the patch contains a call for a seed table upgrade (AD_ZD_SEED.UPGRADE), you may receive the error message "ORA-20001: Cannot upgrade existing table from Patch Edition". You can safely ignore this message if the table already contains the column 'ZD_EDITION_NAME'.
compiledb Purpose: Tells adop to automatically compile invalid objects in the database after running actions normally found in the database portion of the driver.
Default: compiledb for standard patches. nocompiledb for standard patch translations, documentation patches, and documentation patch translations.
Use options=nocompiledb to save time when multiple non-merged patches are applied in the same patching operation.
Comments: Merging multiple patches and applying a single merged patch is usually a better strategy.
compilejsp Purpose: Tells adop whether to automatically compile out-of-date JSP files. JSP files are only compiled if the patch contains copy actions for at least one JSP file.
Default: compilejsp for standard patches. nocompilejsp for standard patch translations, documentation patches, and documentation patch translations.
Use options=nocompilejsp to save time when multiple non-merged patches are applied in a maintenance window.
Comments: Merging multiple patches and applying a single merged patch is usually a better strategy.
copyportion Purpose: Tells adop whether to run commands normally found in the copy portion of the driver.
Default: copyportion
Comments: Use options=nocopyportion to tell adop not to perform copy actions of the driver.
databaseportion Purpose: Tells adop whether to run commands normally found in the database portion of the driver.
Default: databaseportion
Comments: Use options=nodatabaseportion to tell adop not to perform database-related driver actions.
forceapply Purpose: Tells adop to reapply a patch that has already been applied.
Default: noforceapply
Comments: Use the nocheckfile option in conjunction with forceapply to rerun files which may already have been executed.
If you try to apply a patch that has already been applied and do not specify the forceapply parameter, adop will display an error like this:
 [WARNING] Skipping the application of patch
14125999_AR since it has been already applied
[WARNING]  Hint: Patches can be applied again by
specifying options=forceapply when invoking adop 
generateportion Purpose: Tells adop whether to run commands normally found in the generate portion of the driver.
Default: generateportion
Use options=nogenerateportion to tell adop not to perform generate actions of the driver.
integrity Purpose: Tells adop whether to verify that the version of each file referenced in a copy action matches the version present in the patch.
Default: nointegrity
Comments: Using options=nointegrity is safe and avoids some adop overhead.
parallel Purpose: Tells adop whether to run actions that update the database in parallel (such as SQL) and actions that generate files in parallel (such as genform).
Default: parallel
Comments: Oracle does not recommend changing the default, as Oracle E-Business Suite patches are fully tested using this option.
phtofile Purpose: Tells adop where to place patch history information after applying the patch.
Default: nophtofile
Use options=phtofile to tell adop to write patch history information to the patch information files in the file system ($APPL_TOP/admin/$TWO_TASK) instead of uploading it to the database.
Comments: Using phtofile allows you to defer the uploading of patch history information to the database until after the system downtime.
validate Purpose: Tells adop whether to connect to all registered Oracle E-Business Suite schemas at the start of the patch.
Default: novalidate
Use options=validate to validate password information for all Oracle E-Business Suite schemas.
Comments: Useful for finding problems with incorrectly registered Oracle E-Business Suite schemas or schemas with invalid passwords.

The adop Interface

adop is run from the command line. It prompts for required passwords, but expects all other input parameters to be specified on the command line or in an input file.

Running adop

The following is a summary of the steps you use to run adop. For a complete procedural description of all the steps, see Creating Customized Instructions for Patching Using PAA.

Step 1: Set the environment

You must set the environment to apply the configuration parameters that define your system. This task is common to many AD utilities. Your Oracle E-Business Suite installation includes a shell script in the root installation directory that helps you easily set the run edition or patch edition environment. For example:

$ . <EBS_ROOT>/EBSapps.env run

Step 2: Unzip the patch

Download and unzip the patch into the patch top directory, which is identified by the $PATCH_TOP environment variable.

Step 3: Review the information in the readme file

In the directory where you unzipped the patch, you will find a README.txt file and aREADME.html file. Review either readme file for information about the patch and for instructions on using Oracle Patch ApplicationAssistant (PAA) to generate customized instructions for your system.

Step 4: Run Oracle Patch Application Assistant

Run PAA (admsi.pl) to generate customized instructions for your system. Follow the steps in the customized instructions to start the patching process.

Step 5: Run adop

The customized instructions generated by PAA describe how to run adop using the adop command.

Note: You can add arguments on the command line to refine the way adop runs. Seeadop Modes and Command Line Arguments.

A simple example of the commands to execute a complete online patching cycle for patch 123456 is as follows:

$ . <EBS_ROOT>/EBSapps.env run
$ adop phase=prepare
$ adop phase=apply patches=123456
$ adop phase=finalize
$ adop phase=cutover
$ . <EBS_ROOT>/EBSapps.env run
$ adop phase=cleanup

Monitoring Status

You can obtain a brief report for the current patching session by running the command:

$ adop -status

This will display information that includes phases completed and the time taken. In the example below, the current patching session ID is 5:

Current Patching Session ID: 5
Node Name       Node Type       Phase       Status          Started          
              Finished                       Elapsed
 --------------- --------------- ----------- ---------------
 ------------------------------ ------------------------------ ------------
 patchtest1      master          PREPARE     COMPLETED       06-MAY-13
 11:31:38 -07:00      07-MAY-13 12:27:51 -07:00      0:56:13
                                 APPLY       COMPLETED       07-MAY-13
 04:19:17 -07:00      07-MAY-13 04:43:12 -07:00      0:23:55
                                 CUTOVER     COMPLETED       07-MAY-13
 05:54:03 -07:00      07-MAY-13 05:57:57 -07:00      0:03:54
                                 CLEANUP     COMPLETED       07-MAY-13
 09:14:33 -07:00      07-MAY-13 09:22:46 -07:00      0:08:13

The output is also recorded in a log file, called /u01/R122_EBS/fs_ne/EBSapps/log/status_<YYYYMMDD>_<HHMMSS>/adzdshowstatus.out. For example, /u01/R122_EBS/fs_ne/EBSapps/log/status_20130507_111647/adzdshowstatus.out.

Two additional options with this command are as follows.

  • If you want information about a particular session, specify the relevant session ID:

    $ adop -status <session ID>
  • If you want additional details of operations performed:

    $ adop -status -detail

    This option will give a summary of last ten adop session IDs, and full details of the file system and database changes introduced by a patch. It also shows the log file location of the current patching cycle.

Aborting an Online Patching Cycle.

If a patching cycle is failing and the issue cannot be resolved quickly, it is possible to abort the patching cycle and return to normal runtime operation. The patch edition will be dropped.

You can abandon a patching cycle (without applying any patches) by running the command:

$ adop phase=abort

Important: This 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.

Aborting a patching cycle will drop the patch edition, but you must then run the cleanup and fs_clone phases before starting a new patching cycle. The cleanup must be a full cleanup.

For example:

$ adop phase=prepare
$ adop phase=apply patches=123456
[Patch application encounters problems and you want to abort]
$ adop phase=abort
$ adop phase=cleanup cleanup_mode=full
$ adop phase=fs_clone

Optionally, you can combine the abort and cleanup commands as follows:

$ $ adop phase=abort,cleanup cleanup_mode=full

Restarting adop

If you have shut down the workers, or if adop quits while performing processing actions, it saves all the actions completed up to that point in restart files. Investigate and resolve the problem that caused the failure, then restart adop. After you restart adop, it will ask if you want to continue with the previous session (at the point where the processing stopped), or start a new session.

Note: A difference from adpatch is that adop restart behavior is controlled by the abandon=yes/no and restart=yes/no options in the input_file that can be passed to the adop command in the apply phase.

AD Merge Patch

Important: The functionality of AD Merge Patch is now included in the adop tool (described in the next section). If you want adop to merge patches, you must explicitly specify merge=yes when invoking the tool. AD Merge Patch is still supported, however, and its usage is described in this section.

When a series of patches are applied individually, some patching actions (such as linking executables) may need to be performed repeatedly, which can take a lot of time. Also, in some special cases a corrective patch must be merged with a base patch in order to have the desired effect. In both these scenarios it is beneficial to merge multiple patches into a single merged patch, and then apply the merged patch.

An alternative is to use AD Merge Patch. This utility merges multiple patches into a single patch, allowing you to reduce patch application time by eliminating the tasks you would otherwise have to have performed for each individual patch.

When merging compatible patches, AD Merge Patch bases its actions on metadata. It removes duplicate driver lines from the database portions of the driver. When merging two or more patches that have manual steps, the steps and readme files of both patches are also merged.

Source and Destination Directories

You extract the patches to be merged from the source directory. The destination directory is where the merged patch is created. AD Merge Patch reads the patch driver files for each patch in the source directory and merges them to create patch driver files in the destination directory. If a file exists in more than one source patch, only the highest revision of the file is copied to the destination directory.

The source and destination directories should be created under the same parent directory. For example, if the parent directory is named <top>, both the source and destination directories should be subdirectories of <top>. The source and the destination directories cannot be child or parent directories of each other.

Directory Structure for Source and Destination Directories - Basic Example

the picture is described in the document text

The source directory must have all patches to be merged as immediate child directories. The patch directories cannot be in a lower directory. For example, a directory structure for merging four patches would look like this:

Directory Structure for Source and Destination Directories - Merging Four Patches

the picture is described in the document text

Naming the Merged Patch

You should indicate the name of the merged patch on the command line, using the-merge_name option to provide a meaningful name. If you do not use this option, the patch will be given the default name ofmerged.

Merging Zipped Patches

The manifest file is a text file in which you document the location and names of the patch zip files. The contents of a manifest file resemble the following:

/d01/prodappl/patches/p3903945_12_GENERIC.zip
/d01/prodappl/patches/p3892799_12_GENERIC.zip
/d01/prodappl/patches/p3874740_12_LINUX.zip

You can use the -manifest option to create a manifest file. AD Merge Patch references this file, and unzips the patches listed. It copies the unzipped files into the source directory and includes them, along with any other files in the source directory, in the merged patch.

The AD Merge Patch Interface

You run AD Merge Patch and supply the information it needs from the command line. There are no menus or input screens.

Running AD Merge Patch

AD Merge Patch is located in the AD_TOP/bin directory. However, you run it from the parent directory (<top>) of the source directory. The following is a summary of the steps you use to run AD Merge Patch.

Step 1: Set the environment

You must set the environment to indicate the location of the configuration parameters that define your system. This task is common to many AD utilities.

Step 2: Run AD Merge Patch

From the parent directory (<top>), run AD Merge patch using the admrgpch command.

Using AD Merge Patch With adop

You can use AD Merge Patch to merge patches, and then apply them with adop. Refer to the next section for details of the relevant adop commands and options.

In this example, patches 111 and 222 are to be applied after merging. The two patches are staged in <FS_NE>/patch.

$ admrgpch -s <source_directory> -d <destination_directory>
$ pwd
/u01/R122_EBS/fs_ne/EBSapps/patch
$ admrgpch -s /u01/R122_EBS/fs_ne/EBSapps/patch \
-d /u01/R122_EBS/fs_ne/EBSapps/patch/test                   

Now patches 111 and 222 have been merged, and the merged patch's patchtop is /u01/R122_EBS/fs_ne/EBSapps/patch/test:

$ pwd
/u01/R122_EBS/fs_ne/EBSapps/patch/test
$ ls
fnd  u_merged.drv

You can then apply this patch:

$ adop phase=apply

During the next prepare phase, the synchronization steps expect the individual patches (111, 222) to be present under the merged patch's patchtop; in this example, /u01/R122_EBS/fs_ne/EBSapps/patch/test. You therefore need to move 111 and 222 to under /u01/R122_EBS/fs_ne/EBSapps/patch/test before running the next prepare:

$ pwd
$ /u01/R122_EBS/fs_ne/EBSapps/patch
$ mv 111 /u01/R122_EBS/fs_ne/EBSapps/patch/test
$ mv 222 /u01/R122_EBS/fs_ne/EBSapps/patch/test
$ cd /u01/R122_EBS/fs_ne/EBSapps/patch/test
$ ls
111  222  fnd  u_merged.drv

Oracle Patch Application Assistant

For patches that have manual steps, the patch readme file instructs you to useOracle Patch Application Assistant (PAA) by running the admsi.pl script. For merged patches, PAA automatically merges the contents of the individual patch readme files.

The Oracle Patch Application Assistant Interface

The Patch Application Assistant is started from the command line, and collects your input in a graphical user interface.

Running Oracle Patch Application Assistant

The following is a summary of the steps you use to run Patch Application Assistant. For a complete description of all the steps, seeCreating Customized Instructions for Patching Using PAA.

Step 1: Set the environment

You must set the environment to apply the configuration parameters that define your system. This task is common to many AD utilities.

Step 2: Unzip the patch

Download the patch into the patch top directory ($PATCH_TOP) and unzip it.

Step 3: Review the information in the readme file

In the directory where you unzipped the patch, you will find a README.txt file and a README.html file. Review either of these files for information about the patch and for instructions on using Oracle Patch Application Assistant to generate customized instructions for your system.

Step 4: Run Oracle Patch Application Assistant

Run PAA (admsi.pl) to generate customized instructions for your system. Follow the steps in the customized instructions to complete the patching process.

相關推薦

Oracle官方adop,admrgpch工具介紹

 Patching Utilities The adop Utility You use the adop (AD Online Patching) utility to apply patches to the Oracle E-Business Suite f

效能工具TProfiler介紹

工具介紹 TProfiler是一個可以在生產環境長期使用的效能分析工具.它同時支援剖析和取樣兩種方式,記錄方法執行的時間和次數,生成方法熱點 物件建立熱點 執行緒狀態分析等資料,為查詢系統性能瓶頸提供資料支援. TProfiler在JVM啟動時把時間採集程式注入到位元組碼中,整個過程無需修改應用原始碼.執

轉://Oracle補丁及opatch工具介紹

獨立 管理所 無效對象 rim 計劃 目錄 conn 技術 有時 一. CPU(Critical Patch Update) 一個CPU內包含了對多個安全漏洞的修復,並且也包括相應必需的非安全漏洞的補丁。CPU是累積型的,只要安裝最新發布的CPU即可,其中包括之前

python工具 - 從名讀取特定信息到excel表格

lis 去掉 test 讀取 span 擴展名 tdi std class 情景:文件名中包含學號和用戶名,其中用戶名在前學好在後,學號為2位,如harry33.txt、natasha12.txt。 要求:將多個文件名中的用戶名與學號分開並保存到excle中。 代碼部分:

oracle 數據庫批處理

-c home min popu div ech local admin .... 文件夾結構 初始化腳本 |----orcl_sql |----init_user.sql |----tab_home.sql |----TAB_USER.s

【node.js】全局變量、常用工具系統

所有 格式 rmdir files cat 函數 lena roc close 學習鏈接:http://www.runoob.com/nodejs/nodejs-global-object.html 在 JavaScript 中,通常 window 是全局對象, 而 Nod

Oracle數據庫誤刪導致rman備份報錯RMAN-06169解決辦法

是什麽 miss read data- 刪除表空間 nts 系統 刪除表 erro Oracle數據庫誤刪文件導致rman備份報錯RMAN-06169解決辦法 可能是誤刪文件導致在使用rman備份時候出現以下提示 RMAN-06169: could not read fil

Oracle: 通過命令行下載安裝

ase nload oracl bsp thp 安裝 nbsp -o lin 1. 導出oracle cookies 參考:https://blog.pythian.com/how-to-download-oracle-software-using-wget-or-curl

TERSUS畫畫一樣開發軟 顯示相關處理元件介紹-類處理元件

軟件開發;管理軟件;無代碼軟件TERSUS無代碼手機電腦管理類軟件開發,其中對文件類處理元件包括:打印(Print)元件、聲音播放(Play Sound)元件、下載文件(Show File)元件、 拍照(Take Picture)元件 打印(Print)元件:打印元件是將顯示內容用打印方式處理的元件,此元件可

如何使用plsql導出oracle中的建表語句

ffd -i IT SQ 當下 sel acl user self 1 首先打開plsql,登陸所需要訪問的數據庫。 2 點擊工具欄的tools。 3 選擇下拉框中的export user object。 4 此時會彈出一個窗

ASP.NET CORE Linux發布工具對比 只上傳差異文;自動啟停WebServer命令;上傳完成自動預熱WebServer)

pps 手動更新 ftpclient centos paths config AS direct tco 最近這幾日在搞一個小網站:教你啊 ;(感興趣的朋友可以來捧場,在這個網站上有任何消費我都可以退還)由於更新頻繁,手動更新特別麻煩,於是開發了這個小工具用了一段時間,還是

Oracle 11g 管理重做日誌

自動 新的 以及 產生 防止 當前 數據文件 ESS 數據 重做日誌也稱聯機重做日誌。引入重做日誌的目的是數據恢復。在數據庫運行過程中,用戶更改的數據會暫時存放在數據庫的高速緩沖區中。為了提高寫數據的速度,並不是一旦有數據變化,就把變化的數據寫到數據文件中。頻繁的讀寫磁盤文

Oracle 11g R2 管理歸檔日誌

OS 歸檔模式 一定的 目標 size database ESS alter 方式 oracle數據庫有兩種運行方式:歸檔(ARCHIVELOG)方式和非歸檔(NO ARCHIVELOG)方式。在非歸檔模式下,日誌切換時直接覆蓋以前的重做日誌文件,不產生歸檔日誌。數據庫在歸

關於ORACLE導入EMP數據

關於 emp 2.0 分享 roc com image color use 首先,保證同一個版本號。然後知道系統的管理用戶和密碼。 1、導入的方式與導出的方式相同。exp 用戶名/密碼@實例名 file=d:\815.dmp full=ypause exp ecology/

#工具比較

++ names har () cin fst deb col malle 輸入兩個文件名,依次各自讀取字符串並比較,如果不同,輸出不同處的序號和各自的內容 1 #include<bits/stdc++.h> 2 using namespace std;

netcat 工具傳輸

md5值 多臺 打包 net 不能 securecrt 其余 是把 當前 因為電腦本地是 windows,多臺機器間以 windows 為中介傳輸文件極度不爽。window 下的 MobaXterm 工具不能使用 sz 和 rz 命令, 而 SecureCRT 工具使用體驗

oracle sqldrl命令與以及ctl

令行 style skip ted llc control 拆分 txt sqlldr 具體操作如下: 第一步:先編輯好數據控制文件 xx.ctl,如test.ctl options(skip=1) --跳過第一行(看實際情況) load data infile ‘C:

Confluence團隊協同工具使用

@(專案管理) Confluence協同工具使用文件 歡迎關注作者部落格 簡書傳送門 文章目錄 1.前言 2.Confluence介紹 2.1.統一資訊平臺

微信開發者工具及其

  資源中心包 https://open.weixin.qq.com/cgi-bin/showdocument?action=dir_list&t=resource/res_list&verify=1&id=open1419319164&toke

Oracle 表空間與數據

username 結構 rman 記錄日誌 back 返回 group bubuko 改名 Oracle 表空間與數據文件 一、概念 表空間:是一個或多個數據文件的邏輯集合 表空間邏輯存儲對象:永久段-->如表與索引