R12 d49656 gc10-apps dba 24
Download as PPT, PDF0 likes909 views
This document discusses various modes and options for running the AutoPatch utility in Oracle Applications, including: - Test mode runs validation and version checking but does not make changes. - Pre-install mode updates utilities but does not run SQL or load drivers. - Non-interactive mode runs AutoPatch without prompts using a defaults file. - Command line options control behaviors like running in test mode, specifying drivers and directories, and enabling parallelization.
![Using AutoPatch in Pre-Install Mode $ adpatch preinstall=y Copyright (c) 2002 Oracle Corporation Redwood Shores, California, USA Oracle Applications AutoPatch Version 12.0.0 NOTE:... adpatch records your adpatch session in a text file you specify. Enter your adpatch log file name or press [Return] to accept the default name shown in brackets. Filename [adpatch.log] : Mode Pre-Install = YES](https://image.slidesharecdn.com/r12-d49656gc10-appsdba24-110917032957-phpapp02/85/R12-d49656-gc10-apps-dba-24-11-320.jpg)
R12 d49656 gc10-apps dba 24
- 1. Other Patching Topics Patching Topics
- 2. Objectives After completing this module, you should be able to do the following: Run AutoPatch in test mode Run AutoPatch in pre-install mode Run AutoPatch in non-interactive mode Use AutoPatch command line options Use test systems to test patches Merge patch drivers from multiple patches
- 3. Module Overview This module consists of the following topics: AutoPatch Modes AutoPatch Options Java Release Infrastructure Patching Java Files Adding Translations and New Products Using Test and Production Systems AD Merge Patch Merging Patches
- 4. AutoPatch Modes In addition to the normal (patch application) mode, AutoPatch can be run in these modes: Test mode Pre-install mode Non-interactive mode
- 5. AutoPatch Test Mode In test mode, AutoPatch: Reads and validates the patch driver file Reads the product file driver files Extracts object modules to allow version verification Performs version verification and documents which files would be copied Determines which SQL scripts and EXEC commands it would have run Runs AutoConfig in test mode
- 6. AutoPatch Test Mode In test mode, AutoPatch does not: Copy files Archive object modules Relink any executables Generate any forms, reports, menus, or PL/SQL libraries Run any SQL scripts or executables Record patch history Update configuration files or database profiles
- 7. Using AutoPatch in Test Mode $ adpatch apply=n Performing second half of mirrored copies... No mirrored copies were executed in this patch Running SQL scripts or EXEC commands... Updating the Patch History file... Did not update Patch History file (empty patch) AutoPatch is complete. Messages stating that no actions were performed: Command to run AutoPatch in Test Mode:
- 8. AutoPatch Pre-Install Mode Pre-install mode is generally used: During the upgrade process to Update AD utilities Apply family consolidated upgrade patches To work around patching issues
- 9. AutoPatch Pre-Install Mode Applying a patch in pre-install mode performs the following actions only: Version checking File copy actions Relink FND and AD executables Save patch history information to the file system (patch history files)
- 10. AutoPatch Pre-Install Mode AutoPatch in pre-install mode will not: Run SQL or EXEC commands Generate files Read product driver files Apply maintenance packs
- 11. Using AutoPatch in Pre-Install Mode $ adpatch preinstall=y Copyright (c) 2002 Oracle Corporation Redwood Shores, California, USA Oracle Applications AutoPatch Version 12.0.0 NOTE:... adpatch records your adpatch session in a text file you specify. Enter your adpatch log file name or press [Return] to accept the default name shown in brackets. Filename [adpatch.log] : Mode Pre-Install = YES
- 12. AutoPatch Non-Interactive Mode For Release 12, you can run AutoPatch to apply patches without user intervention By specifying a patch top location, AutoPatch will locate and run all patch drivers specific to the patch you want to apply Before you can run AutoPatch non-interactively, you must initially create an AutoPatch defaults file for your current system
- 13. AutoPatch Non-Interactive Mode Creating a Defaults File Specify defaultsfile=<Defaults File Name> on the AutoPatch command line The defaults file must be located under APPL_TOP/admin/<SID> Run AutoPatch up to the point where it asks you for the directory where your Oracle Applications patch has been unloaded, then enter the command abort Verify that your defaults file was created
- 14. Using AutoPatch in Non-Interactive Mode Command to run AutoPatch in non-interactive mode: $ adpatch defaultsfile=$APPL_TOP/admin/testdb1/def.txt \ logfile=c123456.log \ patchtop=$APPL_TOP/patch/123456 \ workers=3 \ interactive=no
- 15. Restarting a Non-Interactive Session Where: The defaults file is $APPL_TOP/admin/testdb1/def.txt The PATCH_TOP is $APPL_TOP/patch/123456 The number of parallel workers is 3 Restart non-interactive session is yes Command to restart AutoPatch in non-interactive mode: $ adpatch defaultsfile=$APPL_TOP/admin/testdb1/def.txt \ logfile=cpy123456.log \ patchtop=$APPL_TOP/patch/123456 \ workers=3 \ interactive=no \ restart=yes
- 16. AutoPatch Options AutoPatch accepts command line arguments that consist of a comma separated list of keywords You can use these keywords to turn off certain processing options or defaults For example, the following command runs AutoPatch in test mode: $ adpatch apply=n
- 17. AutoPatch Command Line Arguments - apply Tells AutoPatch whether to run in test mode. Purpose Example Default Values apply y, meaning that AutoPatch does not run in test mode. n, meaning that AutoPatch does run in test mode. adpatch apply=n y
- 18. AutoPatch Command Line Arguments - driver Tells AutoPatch the name of the patch driver file. This is usually used in non-interactive mode. It is only valid when the AutoPatch patchtop option is also used. Purpose Example Default Values driver A driver file name, or comma-separated list of patch driver file names. adpatch patchtop=/d01/apps/patches/2344175 driver=u2344175.drv None, meaning that AutoPatch prompts for the patch driver file name.
- 19. AutoPatch Command Line Arguments - patchtop Tells AutoPatch the top-level directory for the current patch. This is normally used in non-interactive mode. Purpose Example Default Values patchtop A fully-qualified directory name. adpatch patchtop=/d01/apps/patches/2344175 None, meaning that AutoPatch prompts for the patch directory.
- 20. AutoPatch Command Line Arguments - preinstall Tells AutoPatch whether to run in pre-install mode. Pre-install mode is used to update AD utilities before an upgrade, and to apply family consolidated upgrade patches. Purpose Example Default Values preinstall y, meaning that AutoPatch runs in pre-install mode. n, meaning that AutoPatch does not run in pre-install mode. adpatch preinstall=y n
- 21. AutoPatch Command Line Arguments - uploadph Tells AutoPatch to upload patch history information from the patch information files to the database, and then exit. Purpose Example Default Values uploadph y, meaning that AutoPatch uploads patch history information; n, meaning that AutoPatch does not upload patch history information. adpatch uploadph=y None.
- 22. AutoPatch Command Line Arguments - options Pass generic options to AutoPatch. See the following slides for more information on available options. Purpose Example Default Values options A comma-separated list of options. adpatch options=autoconfig None, meaning that no generic options are passed.
- 23. AutoPatch Options - autoconfig Tells AutoPatch to run AutoConfig automatically. Purpose Comments Default options=noautoconfig 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. A more common strategy is to merge the patches first using AD Merge Patch.
- 24. AutoPatch Options - checkfile Tells AutoPatch to either skip running SQL and EXEC commands if they are recorded as already run and to record them as having run after running them. Use nocheckfile to turn off the checkfile feature. Purpose Comments Default options=nocheckfile checkfile Using checkfile provides significant performance benefits.
- 25. AutoPatch Options - compiledb Tells AutoPatch to automatically compile invalid objects in the database after running actions normally found in the database driver. Purpose Comments Default options=nocompiledb compiledb for standard patches; nocompiledb for standard patch translations, documentation patches, and documentation patch translations. In cases where multiple non-merged patches are applied in a maintenance window, you can use nocompiledb to save time. However, merging multiple patches and applying a single merged patch is usually a better strategy.
- 26. AutoPatch Options - compilejsp Tells AutoPatch whether to automatically compile out-of-date JSP files. Purpose Comments Default options=nocompilejsp compilejsp for standard patches; nocompilejsp for standard patch translations, documentation patches, and documentation patch translations. JSP files are only compiled if the patch contains copy actions for at least one JSP file.
- 27. AutoPatch Options - copyportion Tells AutoPatch whether to run commands normally found in the copy portion of the driver. Purpose Comments Default options=nocopyportion copyportion Use nocopyportion to tell AutoPatch not to perform copy actions of the driver.
- 28. AutoPatch Options - databaseportion Tells AutoPatch whether to run commands normally found in the database portion of the driver. Purpose Comments Default options=nodatabaseportion databaseportion Use nodatabaseportion to tell AutoPatch not to perform database actions of the driver.
- 29. AutoPatch Options - generateportion Tells AutoPatch whether to run commands normally found in the generate portion of the driver. Purpose Comments Default options=nogenerateportion generateportion Use nogenerateportion to tell AutoPatch not to perform generate actions of the driver.
- 30. AutoPatch Options - hotpatch Tells AutoPatch to apply a patch regardless of whether the Oracle Applications system is in Maintenance Mode. Purpose Comments Default options=hotpatch nohotpatch AutoPatch aborts the patching session if Maintenance Mode is disabled and the options=hotpatch command is not used.
- 31. AutoPatch Options - integrity Tells AutoPatch whether to perform patch integrity checking, which verifies that the version of each file referenced in a copy action matches the version present in the patch. Purpose Comments Default options=integrity nointegrity As the integrity of Oracle Applications patches is checked before they are released, the default of nointegrity is safe and avoids some AutoPatch overhead.
- 32. AutoPatch Options - parallel Tells AutoPatch whether to run actions that update the database (such as) and actions that generate files (such as genform) in parallel. Use noparallel to tell AutoPatch to run actions serially. Purpose Comments Default options=noparallel parallel Oracle does not recommend using the noparallel option. Oracle Applications patches are tested on systems using parallel processing.
- 33. AutoPatch Options - phtofile Tells AutoPatch whether to upload patch history information to the database after applying the patch, or to write it to the patch information files in the file system. Purpose Comments Default options=phtofile nophtofile Using phtofile allows you to defer uploading of patch history information to the database until after the system downtime. Use adpatch uploadph=y to upload patch history information from the patch information files to the database during uptime.
- 34. AutoPatch Options - validate Tells AutoPatch whether to connect to all registered Oracle Applications schemas at the start of the patch. Purpose Comments Default options=validate novalidate Useful for finding problems with incorrectly-registered Oracle Applications schemas or schemas with invalid passwords.
- 35. Java Release Infrastructure (JRI) Java Release Infrastructure: Is used for the purpose of developing, releasing, patching, and maintaining Oracle Applications Java code Allows JAR files to be generated and signed on-site
- 36. Java File Patching The process used by AutoPatch to apply a Java patch is: Patch Java files Regenerate JAR Files Sign JAR Files
- 37. Adding Translations and New Products The following are delivered as patches: Translations of existing patches to languages other than American English Products not included in the base release (off-cycle products)
- 38. Using Test and Production Systems Oracle Applications Test Database Oracle Applications Test File System Oracle Applications Production Database Oracle Applications Production File System AutoPatch 1. Apply to Test 2. Apply to Production
- 39. AD Merge Patch AD Merge Patch is: A utility that is designed to merge multiple AutoPatch-compatible patches into a single integrated patch Located in the bin directory of $AD_TOP
- 40. Merging Patches Umerged.drv Source Destination U<Patch2>.drv U<Patch1>.drv
- 41. Merging Patches AD Merge Patch also merges the set of files contained in the individual patches under the source directory according to file revision and copies them to 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
- 42. Merging Unzipped ARUs You can merge patches without unzipping the ARUs by using a manifest file 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 will resemble the following: /home/applmgr/patches/p3903945_12_GENERIC.zip /home/applmgr/patches/p3892799_12_GENERIC.zip /home/applmgr/patches/p3874740_12_LINUX.zip
- 43. Source and Destination Directories 2345671 destination <TOP> source 2345672 2345673 2345674
- 44. Running AD Merge Patch To merge two or more patches into a single merged patch, run AD Merge Patch with the following arguments: UNIX: Windows: $ admrgpch <source directory> <destination directory> C:\> admrgpch <source directory> <destination directory>
- 45. Using the Manifest File To merge two or more patches without unzipping the ARUs, run AD Merge Patch with the following arguments: UNIX: Windows: $ admrgpch -s <source directory> \ -d <destination directory> \ -merge_name <name> -manifest <filename> C:\> admrgpch -s <source directory> \ -d <destination directory> \ -merge_name <name> -manifest <filename>
- 46. AD Merge Patch AD Merge Patch will not merge patches of different: Releases Platforms Parallel modes
- 47. Naming the Merged Patch To specify the name of the merged patch drivers, run AD Merge Patch with the following arguments: UNIX: Windows: $ admrgpch -s <source directory> \ -d <destination directory> \ -merge_name <name> C:\> admrgpch -s <source directory> \ -d <destination directory> \ -merge_name <name>
- 48. Module Summary In this module, you should have learned how to do the following: Run AutoPatch in test mode Run AutoPatch in pre-install mode Run AutoPatch in non-interactive mode Use AutoPatch command line options Use test systems to test patches Merge multiple patches into a single patch
- 49. Module Discussion Name two actions performed by AutoPatch when running in test mode What is the purpose of the Java Release Infrastructure? What are the benefits of using AD Merge Patch?
- 50. Module Practice Running AutoPatch non-interactively Merging patches
Editor's Notes
- #2: ILT Schedule: Timing Topic 45 minutes Lecture 60 minutes Practice 105 minutes Total
- #3: <Course name> <Lesson number> -
- #4: <Course name> <Lesson number> - Overview In this module, we focus on the modes of AutoPatch, as well as AutoPatch command line options. We also learn about the AD Merge Patch utility and how you can merge multiple patches into a single merged patch.
- #5: <Course name> <Lesson number> - AutoPatch Modes In addition to the normal (patch application) mode, AutoPatch can be run in the following modes: Test mode Pre-install mode Non-interactive mode
- #6: <Course name> <Lesson number> - AutoPatch Test Mode With test mode, you can see the effects applying a patch will have on your system before applying the patch. In test mode, AutoPatch does not apply the patch. Instead, it lists each file it would have copied, relinked, executed, or generated and shows the actions it would have performed had it applied the patch.
- #7: <Course name> <Lesson number> - AutoPatch Test Mode Applying a patch in test mode works like applying a patch interactively, except that AutoPatch does not: Copy any files from the patch directory to the installation area. Archive any object modules into the product libraries. Relink any executables. Generate any forms, reports, PL/SQL libraries, or menu files. Run any sql or exec commands (commands that change the database). Record patch history. Update the release version in the database.
- #8: <Course name> <Lesson number> - Running AutoPatch in Test Mode To run AutoPatch in test mode, use the apply=no command as shown in the slide.
- #9: <Course name> <Lesson number> - AutoPatch Pre-Install Mode In some situations, such as upgrading Oracle Applications to R12, you may need to patch upgrade related files before performing the upgrade. See the Upgrading Oracle Applications book, Oracle Applications Release Notes and the patch readme file for instructions on when to use pre-install mode. AutoPatch in pre-install mode asks all normal start-up questions except those relating to the database. Run AutoPatch in pre-install mode only if the patch explicitly requires it.
- #10: <Course name> <Lesson number> - AutoPatch Pre-Install Mode Because AutoPatch does not read product driver files in pre-install mode, it copies all product files in the patch to the APPL_TOP directory, even if they should not exist on this node. For example, it will copy forms files to an APPL_TOP that only implements the admin server. Additionally, if a file in the patch should be in APPL_TOP and in another directory (such as in $OA_HTML), AutoPatch will only copy the file to APPL_TOP in pre-install mode.
- #11: <Course name> <Lesson number> -
- #12: <Course name> <Lesson number> - Using AutoPatch in Pre-Install Mode To run AutoPatch in pre-install mode, use the preinstall=y command shown at the top of the slide.
- #13: <Course name> <Lesson number> - AutoPatch Non-Interactive Mode Non-interactive patching is a way to avoid some of the prompts and automate the patching process. First create a defaults file by running AutoPatch interactively with the specific command line option. Alternatively, you can copy $APPL_TOP/admin/adalldefaults.txt to $APPL_TOP/admin/<SID>/<new_file>.txt and edit it as needed. Then run AutoPatch non-interactively, providing the name of the defaults file you created plus other command line options. After AutoPatch completes, perform any post-AutoPatch steps listed in the patch readme file.
- #14: <Course name> <Lesson number> - AutoPatch Non-interactive Mode - Creating a Defaults File To create an AutoPatch defaults file: Specify defaultsfile=<Defaults File Name> on the AutoPatch command line. The defaults file must be located under APPL_TOP/admin/<SID>. For example: $ adpatch defaultsfile=$APPL_TOP/admin/testdb1/defs.txt Run AutoPatch up to the point where it asks for the directory where your Oracle Applications patch has been unloaded. Then enter abort at this prompt. Verify that your defaults file was created. Once you have an AutoPatch defaults file for your current system, you can run AutoPatch non-interactively.
- #15: <Course name> <Lesson number> - Using AutoPatch in Non-Interactive Mode To apply a standard patch to your APPL_TOP and database non-interactively, use the AutoPatch command in the slide, where the defaults file is $APPL_TOP/admin/testdb1/def.txt, the patch top is $APPL_TOP/patch/123456, the number of parallel workers is 3, and the mode is non-interactive. A standard patch consists of a single unified driver. A unified driver has the following naming convention: u<patchnum>.drv
- #16: <Course name> <Lesson number> - Restarting a Non-Interactive Session If AutoPatch encounters an error during a non-interactive patch session, you can not restart AutoPatch by executing the original AutoPatch command. To restart a non-interactive AutoPatch session, use the same command line options you originally used, but add the “restart=yes” command-line option that you see at the bottom of the command in the slide. It is important that you do not omit any of the original command-line arguments, as this omission may change AutoPatch's behavior and cause unpredictable results.
- #17: <Course name> <Lesson number> - AutoPatch Options In addition to the command line options covered in the AD Utilities section of this course, the options in the following slides can be used by AutoPatch.
- #18: <Course name> <Lesson number> -
- #19: <Course name> <Lesson number> - AutoPatch Command Line Arguments - driver Note: The driver option is generally used for non-standard patches, however, it can be used with standard patches to bypass the driver prompt when running AutoPatch in normal mode.
- #20: <Course name> <Lesson number> -
- #21: <Course name> <Lesson number> -
- #22: <Course name> <Lesson number> -
- #23: <Course name> <Lesson number> - AutoPatch Command Line Arguments - options The options= argument is used to pass generic options to AutoPatch in the form of a comma-separated list. For example, options=nocopyportion,nogenerateportion (do not add a space after the comma). Valid options are on the following slides.
- #24: <Course name> <Lesson number> -
- #25: <Course name> <Lesson number> - AutoPatch Options - checkfile Note: The use of options=nocheckfile is not recommended. You should use this option only when requested to do so by Oracle Support.
- #26: <Course name> <Lesson number> -
- #27: <Course name> <Lesson number> - AutoPatch Options - compilejsp In cases where multiple non-merged patches are applied in a maintenance window, you can use nocompilejsp to save time. However, merging multiple patches and applying a single merged patch is usually a better strategy.
- #28: <Course name> <Lesson number> -
- #29: <Course name> <Lesson number> -
- #30: <Course name> <Lesson number> -
- #31: <Course name> <Lesson number> -
- #32: <Course name> <Lesson number> -
- #33: <Course name> <Lesson number> -
- #34: <Course name> <Lesson number> -
- #35: <Course name> <Lesson number> -
- #36: <Course name> <Lesson number> - Java Release Infrastructure (JRI) Much of the functionality of JRI is invisible to the user. The only direct interaction you may have with JRI is during the Java patching process when AutoPatch calls the jcopy program to patch the Java archive (JAR) patch files located on the Oracle Applications file system and during the maintaining process when AD Administration is used to regenerate JAR files.
- #37: <Course name> <Lesson number> - Java File Patching The process used automatically by AutoPatch to apply a Java patch is: Patch changed Java classes. Regenerate Java archive, or JAR files: The generation portion of the Java patch process regenerates the JAR files under both the $APPL_TOP and $JAVA_TOP. The JAR files in the $APPL_TOP are located in <PROD>_TOP/java/jar and the JAR files under the $JAVA_TOP are located in $JAVA_TOP/oracle/apps/<prod>/jar. JAR files can be regenerated as a maintenance task at any time with the regenerate product JAR file option of AD Administration. Sign JAR files: The final step of the Java patching process is the signing of all JAR files with the customer’s digital signature. This is an inherent part of the Java patching process, and no user intervention is required.
- #38: <Course name> <Lesson number> - Adding Translations and New Products The following are delivered as patches: Translations of existing patches to languages other than American English. Products not included in the base release (off-cycle products): A “new products patch” associated with a maintenance pack is applied using AutoPatch. An individual “new products patch” is delivered as a single patch. Applying this patch involves running AD Splicer followed by AutoPatch. The respective patch readme file contains detailed information on applying a translation or new product patch. Note: AutoPatch is translation-aware. When applying a base patch, AutoPatch notifies you if a translated patch also needs to be applied.
- #39: <Course name> <Lesson number> - Using Test and Production Systems It is important to use a test system to check patches before applying them to your production system. The test database and the production database should always be kept separate. The production database must use a different file system than any other database, including a separate ORACLE_HOME. After you are sure that the patch works correctly and the original issue has been resolved in the test system, apply the patch to your production file system and production database.
- #40: <Course name> <Lesson number> - AD Merge Patch By applying merged patches, you can save a substantial amount of time in the maintenance of your Oracle Applications system. Each time AutoPatch runs, it prompts you for a series of answers and based on your input attempts to connect to your Oracle Applications system. This initial phase may take several minutes. If you repeat this phase dozens of times, the time required for the initial phases for the series of patches can add up. In addition, merging patches eliminates duplicate link, generate and database tasks.
- #41: <Course name> <Lesson number> - Merging Patches Merging multiple patches into one patch not only saves time but makes patching easier. AD Merge Patch is an executable that reads the driver files for each patch in the source directory and merges them together to create a single set of driver files in the destination directory. AD Merge Patch identifies the latest version of a patch if there are different versions in the source patches. The merged patch driver file is named umerged.drv by default. Use the -merge_name parameter to specify a name other than “merged.”
- #42: <Course name> <Lesson number> -
- #43: <Course name> <Lesson number> - Merging Unzipped ARUs Use the -manifest option to use a manifest file that contains the name and location of the patch zip files. 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.
- #44: <Course name> <Lesson number> - Source and Destination Directories When merging patches, the source and the destination directories cannot be child or parent directories of each other. We recommend that you run AD Merge Patch from the parent directory of the source directory, and that the destination directory also be located in the same parent directory. For example, if you run AD Merge Patch from a directory named <TOP>, both the source and destination directories should be subdirectories of <TOP>. The source directory must have all patches to be merged as immediate child directories. The patch directories cannot be in a lower directory under the source directory. For example, if four patches are to be merged, they must be in a directory structure similar to the one in the slide. If you are using a manifest file, place all zipped ARUs in the source directory.
- #45: <Course name> <Lesson number> - Running AD Merge Patch The AD Merge Patch utility has two required arguments: The source directory where the patches to merge have been unloaded. The destination directory where the unified patch will be created. AD Merge Patch creates the merged patch driver files and copies the actual files needed by the merged patches into the destination directory. Always check the AD Merge Patch log file for errors after merging patches. The default log file name is admrgpch.log and is located in the directory in which AD Merge Patch was run.
- #46: <Course name> <Lesson number> -
- #47: <Course name> <Lesson number> - AD Merge Patch AD Merge Patch is capable of merging generic patches with patches of a specific platform, however, it cannot merge patches of two different platforms.
- #48: <Course name> <Lesson number> - Naming the Merged Patch To specify the name of the merged patch, use the command shown on the slide. For example the following command would merge the patches located in the /d01/ patches/source directory and place them in the /d01/ patches/destination directory. $ admrgpch -s /d01/patches/source -d /d01/patches/destination -merge_name NLS99
- #49: <Course name> <Lesson number> -
- #50: <Course name> <Lesson number> -
- #51: <Course name> <Lesson number> - Refer to Practice - Running AutoPatch Non-Interactively [ LAB421BY ] Refer to Practice - Merging Patches [ LAB421CY ]