ADOP options availble in R12.2

 Need to find all the availble options in ADOP, here is the command.

adop -examples

[oracle@preprod appsTier]$ adop -examples
Applications DBA Online Patching Tool (adop)

See Oracle E-Business Suite Maintenance Guide for a full description of
adop features, operation, and usage.


Standard Online Patching Cycle:

    In Oracle E-Business Suite Release 12.2, patches are normally applied
    using an online patching cycle.  The online patching cycle consists of
    five phases which are executed in order.

    Example - Typical online patching cycle:

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

    Note that after cutover the command line environment should be re-loaded
    as the run edition file system has changed.

    In a multi-node deployment, adop commands are only executed from the
    primary node.  The primary adop session uses remote execution to
    automatically perform required actions on any secondary node.

    Multiple phases can be executed in a single adop command.

    Example - combined finalize/cutover/cleanup:

        adop phase=finalize,cutover,cleanup

    Prior to cutover, it is possible to execute additional
    "apply" and "finalize" phases as needed.

    Example - applying multiple patches using separate apply commands:

        source <ebs_root>/EBSapps.env run
        adop phase=prepare
        adop phase=apply patches=123456
        adop phase=apply patches=223456
        adop phase=finalize
        adop phase=apply patches=323456
        adop phase=finalize
        adop phase=cutover
        source <ebs_root>/EBSapps.env run
        adop phase=cleanup

    Note that it is possible to apply additional patches after running the
    finalize phase, but if you do so then you will need to run the finalize
    phase again.  Finalize must always be run immediately prior to cutover.


General parameters applicable to all phases:


    workers=<number>  [default: computed]
        Number of parallel workers used to execute tasks.  Default value is
        computed principally according to number of available CPU cores.

        Example:

            adop phase=prepare workers=8

        The example command executes the prepare phase with 8 parallel workers.
        Not all processing can be executed with parallel workers, and in such
        cases the workers parameter is ignored.  In multi-node systems the
        workers parameter indicates workers per node.


    input_file=<file_name>
        As well as being entered directly on the command line, adop parameters
        can be specified in a text file, with one
            <parameter>=<value>
        on each line of the file.  Command line parameters override input file
        parameters.

        Example - Input File text "empty_cycle.txt" for empty patching cycle:

            phase=prepare,finalize,cutover,cleanup
            workers=4
            loglevel=statement

        Example - Use input file to execute empty patching cycle:

            adop input_file=empty_cycle.txt workers=1

        The example command will execute an empty patching cycle with a
        single worker and maximum log detail.


    loglevel=(statement|procedure|event|warning|error|unexpected)
        [default: event]
        Controls the level of diagnostic log detail displayed on the
        console output.  Each log message is tagged with a level:
            1) statement  - internal debugging messages
            2) procedure  - internal procedure begin/end messages
            3) event      - significant processing action
            4) warning    - important user message or possible problem
            5) error      - a patching action has failed, processing continues
            6) unexpected - a critical action has failed, processing halted
        Setting loglevel will display messages at that level and higher.

        Example - Display full log details:

            adop phase=prepare loglevel=statement

        Example - Display only warnings and errors:

            adop phase=prepare loglevel=warning


    prompt=(yes|no)  [default: yes]
        Specifies whether adop should prompt for user input on warnings.
        By default adop will ask user whether to continue or exit on
        some warning messages.  If this parameter is set to "no" adop
        will remain fully non-interactive, and will continue past any
        warning messages without user confirmation.

        Example - Disable user prompt for warnings:

            adop phase=cutover prompt=no


Diagnostic Parameters, normally not used unless directed by Support:

    allowcoredump=(yes|no)  [default: no]
        Specifies whether adop should create a core dump if it crashes.  This
        option should only be used if directed by support.

        Example - Enable writing of core dump files:

            adop phase=cutover allowcoredump=yes


    analytics=(yes|no)  [default: no]
        Controls whether adop writes additional reports with information
        that might be helpful in some diagnostic situations.  This option
        should not be used unless directed by Support.

        Example - Enable additional analytic reports

            adop phase=finalize analytics=yes


    defaultsfile=<file_name>  [default: adalldefaults.txt]
        Name of the response file providing default parameter values for
        non-interactive execution of adadmin and adop.  The file must be in
        the $APPL_TOP/admin/$TWO_TASK directory in both run edition and patch
        edition file systems.  The default file "adalldefaults.txt" is
        maintained by AutoConfig and normally you should not need to change
        any values.

        Example - Using a custom AD Defaults file:

            adop phase=apply defaultsfile=adcustomdefaults.txt


Prepare Parameters:

    skipsyncerror=(yes|no)  [default: no]
        Specifies whether to ignore errors that may occur during incremental
        file system synchronization.  This might happen if you applied
        a patch in the previous patching cycle that had errors but decided
        to continue with the cutover.  When the patch is synchronized on
        the next patching cycle, the apply errors may occur again, but
        can be ignored.

        Example:

            adop phase=prepare skipsyncerror=yes


Apply Parameters:

    apply=(yes|no)  [default: yes]
        Controls whether adop actually applies the patch.  You can specify
        "apply=no" to run adop in test mode, where the patch will not actually
        be applied, and adop will record what it would have done in the log.

        Example - Execute adop apply in test mode:

            adop phase=apply apply=no patches=1234


    patches=<patch#>[,<patch#>...]
    patches=<patch_directory>:<driver>[,<patch_directory>:<driver>...]
        This parameter specifies a comma-separated list of patches to be
        applied.  Patches can be specified either as the patch number or
        by the patch directory and driver file.  All patches are expected
        to be in the $PATCH_TOP directory on all tiers.  Patches are applied
        serially unless the merge=yes parameter is specified.

        Example - Apply two patches in series:

            adop phase=apply patches=1234,5678

        Example - Apply patch and its translation:

            adop phase=apply patches=1012464,10124646_AR:u10124646.drv


    patchtop=<directory_name>  [default: $PATCH_TOP]
        Path to a user-specified directory where patches are unzipped.
        The default and recommend location is the $PATCH_TOP directory
        automatically created by the install.  When using an alternate
        patchtop you must ensure that the location is not within the
        editioned file systems (fs1, fs2) and is accessible by the same
        path for all nodes of a multi-node deployment.

        Example - Apply patch from alternate patchtop directory:

            adop phase=apply patches=123456 patchtop=/install/patches


    apply_mode=(online|downtime|hotpatch)  [default: online]
        Use online mode to apply a patch to the patch edition during an
        online patching cycle; downtime mode to apply a patch to the
        run edition when application services are down; and hotpatch
        mode to apply a patch to the run edition when application
        services are up. Only use hotpatch mode when explicitly
        directed by documentation.

        Example - apply a patch in downtime mode:

            adop phase=apply patches=123456 apply_mode=downtime

        In downtime mode, adop will validate that application services
        are shutdown before apply the patch.  The patch will be applied
        to the run edition of the system.  Downtime mode cannot be used
        if there is an online patching cycle in progress.

        Example - apply a patch in hotpatch mode:

            adop phase=apply patches=123456 apply_mode=hotpatch

        In hotpatch mode, adop will apply the patch to the run edition
        of the system while application services are still running.  Patches
        that can be safely applied in hotpatch mode (such as NLS and Online
        Help patches) will document this in the patch readme.  Hotpatch mode
        cannot be used if there is an online patching cycle in progress.


    merge=(yes|no)  [default: no]
        Indicates whether adop should merge a list of patches before applying.
        By default, adop will apply a list of patches serially in the order
        specified.  You can also use AD Merge Patch to merge multiple patches
        ahead of the apply command.

        Example - Merge multiple patches before applying

            adop phase=apply patches=1234,5678 merge=yes

        In some cases it may be necessary to merge patches, such as when
        an additional patch corrects an installation issue in the main patch.
        If the merge parameter is required, this will be documented in the
        patch readme.


    restart=(yes|no)  [default: no]
        Use restart=yes to resume the previous failed apply command
        from where processing terminated.  If an apply command fails,
        check the log files for further information.  If the problem
        can be corrected, you can then restart the apply command where
        it left off using the restart parameter.

        Example - Restart a apply command

            adop phase=apply patches=123456 restart=yes

        When restarting a failed apply it is important to use the
        same parameters as the failed command, with only the addition
        of the restart=yes parameter.


    abandon=(yes|no)  [default: no]
        Use abandon=yes to abandon the previous failed apply command
        and start a new apply command.  Note that any changes made
        to the system by the failed command will remain in effect.
        The abandon flag is most useful when applying a replacement
        patch for the failing patch.

        Example - Abandon previous apply command and apply replacement

            adop phase=apply patches=223456 abandon=yes

        If a patch fails to apply and there is no replacement patch,
        you may also abort the online patching cycle.  See abort phase
        later in this text.


    options=<patch_option>[,<patch_option>...]
        Options can be specified in a comma-separated list to control
        advanced features when a patch is applied.  These options are normally
        not needed unless specified by documentation or support.  Note
        that these options can be prefixed with "no", e.g. "nocheckfile",
        to disable the behavior, and for some options "no" is the default.

            checkfile       - Skip running exec, SQL, and exectier
                              commands if they are recorded as already run.
                              [default: checkfile]

            compiledb       - Compile invalid objects in the database
                              after running actions in the database driver.
                              [default: compiledb]

            compilejsp      - Compile out-of-date JSP files, if the patch
                              has copy actions for at least one JSP file.
                              [default: compilejsp]

            copyportion     - Run commands found in a copy driver.
                              [default: copyportion]

            databaseportion - Run commands found in a database driver.
                              [default: databaseportion]

            generateportion - Run commands found in a generate driver.
                              [default: generateportion]

            integrity       - Perform patch integrity checking
                              [default: nointegrity]

            autoconfig      - Run AutoConfig.
                              [default: autoconfig]

            actiondetails   - Turn off display of action details.
                              [default: actiondetails]

            parallel        - Run actions that update the database or
                              actions that generate files in parallel.
                              [default: parallel]

            prereq          - Perform prerequisite patch checking prior to
                              running patch driver files.
                              [default: noprereq]

            validate        - Connect to all registered Oracle E-Business
                              Suite schemas at the start of patch application.
                              [default: novalidate]

            phtofile        - Save patch history to file
                              [default: nophtofile]

            forceapply      - Reapply a patch that has already been applied.
                              Useful in combination with "nocheckfile" option
                              to rerun files that have already been executed.
                              [default: noforceapply]

        Example - Apply patch again, force re-execution of driver commands:

            adop phase=apply patches=123456 options=forceapply,nocheckfile

        This command will apply the patch again, and will execute SQL, exec
        and exectier actions even if they have already been executed.


    flags=<patch_flag>[,<patch_flag>...]
        Flags can be specified in a comma-separated list to control advanced
        features when applying a patch.  Note that these flags can be prefixed
        with "no", e.g.  "nologging", to disable the behavior and for some
        flags "no" is the default.

            hidepw          - Omit the "HIDEPW:" comments in the log file.
                              [default: hidepw]

            trace           - Log all database operations to a trace file.
                              [default: notrace]

            logging         - Create indexes in LOGGING or NOLOGGING mode.
                              [default: nologging]

            autoskip        - To proceed with adpatch execution even if some
                              driver actions failed.  Failed actions are
                              recorded in a log file.
                              [default: noautoskip]

        Example - Skip apply failures:

            adop phase=apply patches=123456 flags=autoskip


    preinstall=(yes|no)  [default: no]
        Allows a patch to be applied to the file system without connecting
        to the database.  Do not use this parameter unless directed by Oracle.


    wait_on_failed_job=(yes|no)  [default: no]
        Controls whether adop apply command exits when all workers have
        failed.  Instead of exiting, you can force adop to wait, and use
        the "adctrl" to retry failed jobs.


    printdebug=(yes|no)  [default: no]
        Controls whether to display additional debugging information.


    uploadph=(yes|no)  [default: yes]
        Controls whether to upload patch history information to database after
        applying the patch.


Finalize Parameters:

    finalize_mode=(full|quick)  [default: quick]
        Quick mode will provide the shortest execution time, by
        skipping non-essential actions.
        Full mode performs additional actions such as gathering
        statistics that may improve performance after cutover.

        Example - Perform additional optimizations during Finalize:

            adop phase=finalize finalize_mode=full

        Using full mode after applying a major patch can help maintain
        optimal system performance.


Cutover Parameters:

    mtrestart=(yes|no)  [default: yes]
        Specifies whether to restart application tier servers after cutover.
        Leave at default unless you need to perform any manual steps during
        downtime.

        Example - Perform downtime actions after cutover:

            adop phase=cutover mtrestart=no
            <Perform downtime steps>
            adstrtal.sh


    cm_wait=<minutes>  [default: forever]
        Specifies the number of minutes to wait for Concurrent Manager
        shutdown.  Adop cutover starts by requesting a concurrent manager
        shutdown and then waits for in-progress requests to complete.
        If Concurrent Manager does not shutdown within the specified
        time limit, remaining concurrent requests will be killed and
        cutover will proceed.

        Example - cutover with maximum wait of 15 minutes:

            adop phase=cutover cm_wait=15

        Note that any concurrent requests killed during forced shutdown
        may need to be manually re-submitted after cutover.  To avoid
        killing concurrent requests, schedule cutover at a time of
        minimal user activity or manually shutdown Concurrent Manager
        in advance of cutover.


Cleanup Parameters:

    cleanup_mode=(full|standard|quick)  [default: standard]
        Quick mode provides the shortest execution time, by
        skipping non-essential actions.
        Standard mode performs additional processing to drop
        obsolete code objects from old editions.
        Full mode performs additional processing to drop empty
        database editions and unused table columns.

        Example - Run quick cleanup for minimum delay to next prepare:

            adop phase=cleanup cleanup_mode=quick

        Example - Run full cleanup for maximum space recovery:

            adop phase=cleanup cleanup_mode=full


Special Operations:

    Cloning the Patch Edition File System:
        The patch edition file system is normally synchronized with the
        run edition file system during the prepare phase.  There are some
        cases where it is helpful or required to manually re-clone the patch
        edition file system from the run edition.

            1) After aborting an online patching cycle.
            2) After manually changing the run edition file system.
            3) After patching middle-tier technology components.
            4) After applying an EBS RUP.

        By re-cloning the patch edition file system, you can be certain that
        it is correctly synchronized, and also minimize any synchronization
        delay that would normally occur on the next prepare command.

        Example - Re-clone the patch edition file system:

            adop phase=fs_clone

        If there is any error you must examine log files and correct the
        problem, then restart the fs_clone by running the command again.
        If fs_clone does not restart correctly you can force the process
        to restart from the beginning.

        Example - Restart failed fs_clone from the beginning:

            adop phase=fs_clone force=yes


    Aborting an online patching cycle:
        If an online patching cycle encounters problems that cannot be
        fixed immediately you can abort the patching cycle and return
        to normal runtime operation.

        Example - Aborting a failed online patching cycle:

            adop phase=prepare
            adop phase=apply patches=123456
            ### serious unfixable error reported
            adop phase=abort
            adop phase=cleanup cleanup_mode=full
            adop phase=fs_clone

        The abort command drops the database patch edition and
        returns the system to normal runtime state.  Immediately
        following abort, you must also run a full cleanup and
        fs_clone operation to fully remove effects of the failed
        online patching cycle.


    Dropping old database editions:
        As online patching cycles are completed, the system will build
        up a number of old database editions.  When the number of old
        database editions reaches about 25, you should consider running
        a special maintenance operation to drop old database editions.

        Example - Actualize_All and Full Cleanup:

            adop phase=prepare
            adop phase=actualize_all
            adop phase=finalize
            adop phase=cutover
            adop phase=cleanup cleanup_mode=full

        Warning: This maintenance operation will take much longer than a
        typical online patching cycle, and should only be performed when
        there is no immediate need to start a new online patching cycle.

        The actualize all and full cleanup can be done separately as shown
        above, or can be executed in conjunction with an online patching
        cycle.

        Example - Actualize_All and Full Cleanup combined with patching:

            adop phase=prepare
            adop phase=apply patches=123456
            adop phase=actualize_all
            adop phase=finalize
            adop phase=cutover
            adop phase=cleanup cleanup_mode=full


adop exiting with status = 0 (Success)