ADPATCH
Introduce the patch driver
c<bugnum>.drv (Copy driver )
You should always run this file first
This file contains commands for copying files to APPL_TOP
The file portion of the bug patch changes the files in APPL_TOP.
d<bugnum>.drv (Database driver )
You should run this file in the new session after c<bugnum> is run successfully. This file can apply the database portion of the bug patch. The database portion of the bug patch changes your Oracle Applications database objects.
This file is only included if the bug patch requires changes to your Oracle Applications database objects.
g<bugnum>.drv (Generate driver )
This file contains generation steps, and must be run after c<bugnum>.drv and d<bugnum>.drv have been run successfully.
The g<bugnum>.drv file is only included if the bug patch requires new forms, reports, or message files to be generated.
If there are errors, you must fix the problem and rerun Adpatch until it is completely successful.
u<patchnumber>.drv (Unified driver)
it is a consolidated driver containing all copy, database, and generate actions. Apply this driver to all APPL_TOPs on all application tier servers. AutoPatch knows which command should be run on each type of application tier. The unified driver requires only a single execution of AutoPatch
Adpatch mode
AutoPatch broadly supports three modes:
Normal mode
Test mode
Parallel mode
Test Mode
AutoPatch provides a test mode in which it tells you everything it would have done in applying a patch, but doesn't actually apply the patch.
To run AutoPatch in Test Mode, you must include 'apply=no' on the AutoPatch command line. For example:
$ adpatch apply=no
Instead of performing an action, AutoPatch indicates that it is not performing the action because "Apply=No". In general, AutoPatch lists each file it would have
Copied, generated, relinked, or executed. This shows you exactly what actions it would have performed.
AutoPatch test mode works the same as normal mode, with the following exceptions:
It does not copy any files from your patch directory into your installation area.
It does not copy any files from your APPL_TOP to JAVA_TOP or OAH_TOP.
It does not archive any object modules into your product libraries.
It does not generate any forms or reports.
It does not relink any executables.
It does not run any 'sql' or 'exec' commands.
It does not update the release version in the database.
It does not update the patch history file.
AutoPatch asks you the same initial questions in test mode as in normal mode. It performs the following actions to determine what it would have done if run in normal mode:
Reads and validates the patch driver file.
Reads product file driver files.
Extracts object modules from your product libraries (so it can perform version checking on the object modules it extracts).
Performs version checking.
Looks in the database to determine what 'sql' and 'exec' commands it would have run.
You can use AutoPatch Test Mode when running AutoPatch in Pre-Auto Install Mode.
Parallel Mode
By default, AutoPatch runs sql and exec commands in parallel.
AutoPatch also runs commands to generate Oracle Forms objects (genfpll and genform) in parallel.
You can cause AutoPatch to run sql and exec commands in serial using a command in the patch driver file.
You can cause AutoPatch to run sql and exec commands in serial, AND generate Oracle Forms objects in serial using the AutoPatch command-line option
'options=nonparallel'
Generating Oracle Forms objects in parallel is not linked to running sql and exec commands in parallel. You can run sql and exec commands in either serial or
parallel mode while generating Oracle Forms objects in parallel.
When we refer to "AutoPatch Parallel Mode", we are referring to the feature that runs sql and exec commands in parallel, not to the feature that generates Oracle
Forms objects in parallel.
AutoPatch starts up workers; the workers run tasks as assigned by the "manager" (AutoPatch); the workers eventually finish; then AutoPatch starts running again,
does a few more tasks, and exits. You can use the AD Controller program (adctrl) to monitor and alter AutoPatch parallel worker status.
ADCTRL
By using AD Controller, you can determine the status of AutoUpgrade, AD Administration, or AutoPatch workers and restart failed tasks.
AD Controller Menu
---------------------------------------------------
1. Show worker status
2. Tell worker to restart a failed job
3. Tell worker to shutdown/quit
4. Tell manager that a worker failed its job
5. Tell manager that a worker acknowledges quit
6. Tell manager to start a worker that has shutdown
7. Exit
· How to skip the failed adworker jobs ---using Hidden value
ADADMIN
AD Administration (adadmin) performs maintenance tasks on an installed Oracle Applications system to ensure that it runs smoothly. These tasks fall into two categories: database and file system.
Database Tasks:
Maintain Applications Database Objects
--------------------------------------------------
1. Validate APPS schema(s)
Runs a SQL script (advrfapp.sql) against the APPS schema to verify the integrity of the schema. It determines:
• Problems you MUST fix (not specific to the APPS schema)
• Problems you MUST fix (specific to the APPS schema)
• Issues you may want to address (specific to the APPS schema)
The problems and issues are described in separate sections in a report named <APPS schema name>.lst. This report is located in $APPL_TOP/admin/<SID>/out,
where <SID> is the value of the ORACLE_SID or TWO_TASK variable.
2. Compile APPS schema(s)
3. Compile menu information
Compiles menu data structures. Choose this task after you have uploaded menu entries to the FND_MENU_ENTRIES table, or if Compile Security concurrent requests submitted from the Menus form (after changing menu entries) fail for any reason.
4. Recreate grants and synonyms for APPS schema(s)
Recreates grants and synonyms for the Oracle Applications public schema (APPLSYSPUB), recreates grants on some packages from SYSTEM to APPS, and spawns parallel workers to recreate grants and synonyms linking sequences and tables in the base schemas to the APPS schemas.
To proactively verify that grants and synonyms are up to date, first run the Validate APPS Schema task. If you determine that grants and synonyms are missing, run this option to recreate them.
5. Compile flexfield data in AOL tables
Compiles flexfield data structures in Oracle Application Object Library (AOL) tables. Using this option after you modify flexfields for the first time improves performance at runtime.
6. Maintain multi-lingual tables
Calls PL/SQL routines to maintain multi-lingual tables. Run this task when adding a language.
7. Check DUAL table
Verifies that the DUAL table exists in the SYS schema, is accessible by Applications, and contains only one row. If the DUAL table does not exist, or if it does not contain exactly one row, Oracle Applications products that access this table will fail.
8. Maintain Multiple Reporting Currencies schema(s)
If you have installed Multiple Reporting Currencies (MRC) functionality, this menu option is called Maintain Multiple Reporting Currencies schema(s). If you have not, it is called Convert to Multiple Reporting Currencies option, which you use to install MRC.
MRC is implemented using an adjunct schema, which is an extra schema that contains synonyms to objects in the APPS schema, exact copies of some objects in the APPS schema, and modified copies of other objects in the APPS schema.
We have to bring down concurrent manager before maintaining MRC.
9. Convert to MultiOrg
Appears as a menu choice only if Multi-Org or Multiple Sets of Books Architecture(chart of accounts, currency and calendar) is not installed in your database. Use it to convert a standard product group (not Multiple Sets of Books Architecture and not Multi-Org) into a Multi-Org product group with one operating unit defined at the site level.
10. Return to Main Menu
File System Tasks:
Maintain Applications Files
----------------------------------------
1. Create Applications environment file
2. Relink Applications programs
Relinks Oracle Applications executable programs with the 8.0.6 Oracle server libraries so that they function with the Oracle database. For each product, you choose whether to link all executables or only specific ones.
You also have the option of relinking executables with debug information intact. Use this option only if requested to do so by Oracle Support Services. By default,
AD Administration relinks all executables without debug information.
AD Administration does not link executables for the AD product. To relink AD executables, run the adrelink utility.
3. Copy files to destinations
Copies files from each product area to central locations where they can be easily referenced by non-Applications programs. This option uses revision-based copy logic to ensure that the destination file versions are the same as, or higher than, the source file versions.
The file types and their respective destinations are shown as follows:
Java files --->$JAVA_TOP
HTML files --->$OAH_TOP
Media files --->$OAM_TOP
4. Convert character set
Converts the character set of files in the APPL_TOP. This task prompts for the source (or current) character set and the converted (destination) character set.
5. Maintain snapshot information
This feature allows you to record the current set of files and file versions in your APPL_TOP. There are two types of APPL_TOP snapshots: current view snapshots and named snapshots. Current view snapshots are created once and updated when appropriate to maintain a consistent view of the APPL_TOP contents. Named snapshots are created once using AD Administration and not updated. Both store information about files, file versions, and bug fixes present in an APPL_TOP.
Running AD Administration "Maintain snapshot information" for an APPL_TOP completely populates the APPL_TOP's current view snapshot. This complete information is required for the automatic prerequisite patch checking feature to give correct results.
AutoPatch automatically updates the list of file versions and bug fixes in the current view snapshot for each APPL_TOP as patches are applied to that APPL_TOP. The combination of running AD Administration "Maintain snapshot information" once for an APPL_TOP and AutoPatch's incremental updates ensures that the current view snapshot for a given APPL_TOP contains an accurate picture of the current set of files and bug fixes present in that APPL_TOP.
6. Verify files necessary for runtime
Verifies that all files needed to run Oracle Applications for the current configuration are in the current APPL_TOP. Choose this task if you suspect missing files at runtime.
7. Generate message files
Generates message binary files (extension .msb) from Oracle Application Object Library tables. Oracle Applications uses these files to display messages. Choose this task only when instructed to do so in an update or a patch.
8. Generate form files
9. Generate report files
10. Generate graphics files
11. Generate product jar files
Run this task whenever you upgrade the Developer6i technology stack. It performs the following actions:
• Generates all JAR (Java archive) files that are out-of-date.
• Generates product JAR files in APPL_TOP and JAVA_TOP.
• Copies Oracle Forms registry file (Registry.dat) from 8.0.6 ORACLE_HOME/forms60/java to JAVA_TOP/oracle/forms/registry.
• Signs JAR files, if on the web server.
• Recreates appsborg.zip under APPL_TOP and JAVA_TOP.
12. Return to Main Menu
AD Splicer
Products introduced after a given release (not on the base Oracle Applications CD for that release) can be difficult to install or maintain because the AD utilities don't recognize them as valid Oracle Applications products, therefore they may be ignored or failed. AD Splicer resolves this difficulty by modifying your APPL_TOP and database so that adpatch and adadmin recognize the off-cycle product(s) as being a valid Oracle Applications product(s) for the given release. ( adaimgr deliberately ignores products added by AD Splicer)
For example, the Oracle Business Intelligence Systems product (BIS) did not go out on the Rel 11.0 CD. It is distributed to Rel 11.0 customers using a combination of AD Splicer and AutoPatch.
Customers should do the following when splicing in a product or suite of products using AD Splicer:
Customers download a custom-built patch
Customers follow instructions in the patch readme file. See Sample AD Splicer readme file (for BIS).
The instructions in the readme file should say something like:
1.Apply prereq patches (if any).
2.Go to admin subdirectory of patch directory.
3.Edit newprods.txt (see Editing newprods.txt).
4.Manually copy AD Splicer control files (*.txt) to admin subdirectory under APPL_TOP.
5.Go to the admin subdirectory under APPL_TOP.
6.Run AD Splicer. Use newprods.txt as AD Splicer control file.
Make sure to create new environment file (or update the registry).
7.Non-NT platforms only: Integrate environment file created by AD Splicer with your existing environment file. If your existing environment file was not customized, you can just copy the new version on top of your existing version.
8.Log out and log back in so that you are using the new environment file (or registry entries) to set up your environment.
9.Verify that <PROD>_TOP environment variables are set for your newly-spliced products.
10.Run AutoPatch to install files and database objects for your new products.
How to edit newprods.txt
AD Splicer has two kinds of control files:
Product Definition Files
Two files per spliced product
<prod>prod.txt: Language-independent info for product <prod>
<prod>terr.txt: Language-dependent info for product <prod>
These files must not be edited
Product Configuration File
One file for each group of related spliced products
File is called newprods.txt by default
File should be edited by the customer
Each spliced product in newprods.txt has an entry like the following:
product=bis
base_product_top=*APPL_TOP*
oracle_schema=bis
sizing_factor=100
main_tspace=*Product_Name*D
index_tspace=*Product_Name*X
temp_tspace=*Temporary_Tablespace*
default_tspace=*Product_Name*D
For each spliced product, the newprods.txt file must contain all of the entries shown in the example above. The entries must be listed in the exact order shown above. No entry may be omitted.
AD Relink
AD Relink is used to relink Oracle Applications executable programs with the Oracle 8.0.6 Server product libraries. Executable programs can also be relinked through the Relink Applications Programs task from the Maintain Applications File menu of AD Administration. We can't use adadmin to relink AD executable because AD Administration doesn't relink AD executable.
adrelink.sh force=y "fnd f60webmx" "fnd ar60run" "fnd ar60rund" "fnd ar60runb" "fnd ar60desb"
AD Merge Patch (admrgpch)
Each time AutoPatch starts, it prompts for information and attempts to connect to the Oracle Applications system. In addition, there may be duplicate link, generate,and database tasks in a collection of patches. When patches are applied individually, these tasks are performed multiple times. Applying a patch driver that contains merged updates reduces the patch application time by eliminating redundant system verification and duplicate patch tasks.
AD Merge Patch merges multiple AutoPatch compatible patches into a single, integrated patch. The command for merging patches is admrgpch. It is an executable located in AD_TOP/bin.
To merge patches:
1. Review the readme files carefully.
Some patch readme files contain special instructions for applying merged patches. These may include manual steps.
2. Create directories.
In the patch top area, create a source directory and a destination directory. Choose any name for these directories.
3. Unzip patches.
Copy all patches to be merged into the source directory and unzip them.
4. Run AD Merge Patch using these arguments:
· The source directory where the patches to be merged have been unloaded (<source directory>).
· The destination directory where the integrated patch will be created (<destination directory>).
· The name of the merged patch (-merged_name).
Note: The -merged_name parameter is optional. AD Merge Patch uses the default merged patch names of cmerged.drv, dbmerged.drv, and gmerged.drv when the -merged_name parameter is not used.
From the patch top area, run AD Merge Patch with the following command:
admrgpch <source directory> <destination directory> -merged_name <name>
For example, when merging three patches called 123456, 123457, and 123458 located in the source directory ".../patches/source" to the destination directory
".../patches/destination" and using "merge88" for the name of the merged patch, use the following command:
$ admrgpch /d01/patches/source /d01/patches/destination -merged_name merge88
AD Merge Patch reads the c<patchnum>.drv, d<patchnum>.drv, and g<patchnum>.drv for each patch in the source directory and merges them to create a single set of driver files (for example, cmerge88.drv, dmerge88.drv, and gmerge88.drv) in the destination directory. It 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 is contained in more than one source patch, only the highest revision of the file is copied to the destination directory.
5. Check AD Merge Patch log files.
After AD Merge Patch runs, check the admrgpch.log file for errors. The file is located in the current working directory where AD Merge Patch was run.
Once a merged patch is created, apply it normally.
Note: AD Merge Patch cannot merge patches of different releases, different parallel modes, or different platforms. However, AD Merge Patch can merge patches for a specific platform with a Generic patch, a US patch with a language translation patch, or patches with different source character sets. When merging patches,
AD Merge Patch notifies you if there are incompatible patches.
ADIDENT
Use this utility to identify the version and translation level of Oracle Applications files. It is useful when collecting information about your site for Oracle Support Services.
If the specified file contains version information, AD File Identification displays it in a compact format. The translation level (used to distinguish different translation levels of the same file version) is shown in parentheses after the file version. For most files, the translation level is zero. For example:
$ adident $AD_TOP/sql/adutconf.sql
adutconf.sql: 115.13 (0)
Not all Oracle Applications files contain version information. If the specified file does not, AD File Identification displays a warning.
ADUTCONF
This utility is a SQL script that reports standard information about the installed configuration of Oracle Applications. Run this task only when asked to do so by Oracle Support in order to debug or document the status of your installation.Running AD Configuration generates a file (adutconf.lst) that contains the following:
• SQL*Plus PAUSE and NEWPAGE settings
• rollback segment information
• information about the product group
• whether Multi-Org is installed
• list of operating units
• whether Multiple Reporting Currency (MRC) is installed
• list of registered products
• information on all registered schemas
• information about all installed products, including shared and dependent products
• status of localization modules
• the base language and other installed languages
• NLS init.ora settings
Use the following command to run this script The output file is written to adutconf.lst in the current working directory.
cd $APPL_TOP/admin/<SID>/out
$ sqlplus <APPS schema username>/<APPS schema password> @$AD_TOP/sql/adutconf.sql
No comments:
Post a Comment