R12 d49656 gc10-apps dba 09

Editor's Notes

• #2: ILT Schedule: Timing Topic 40 minutes Lecture 30 minutes Practice 70 minutes Total
• #3: <Course name> <Lesson number> -
• #4: <Course name> <Lesson number> -
• #5: <Course name> <Lesson number> - Overview The AD utilities are a set of tools used to install, upgrade, patch and maintain the Oracle Applications database and file system. This section of the course introduces some of the key AD utilities. We cover many of the utilities in detail and provide a high level overview of others.
• #6: <Course name> <Lesson number> - AD Utilities Many of the utilities used for Oracle Applications maintenance are called AD utilities. AD is an abbreviation for Applications DBA. The AD utilities have similar interfaces, operation, input and report format. Much of the discussion about how these utilities work is common to all the AD utilities. In addition to the AD utilities, some maintenance tasks are run from the Oracle Applications Manager (OAM). OAM is a web-based application that provides a subset of System Administrator functions and many other features. Note: See Oracle Applications System Administrator’s Guide for more information on Oracle Applications Manager.
• #7: <Course name> <Lesson number> - Configuration and Environment Files The following configuration and environment files are pertinent to, and used by, most of the AD utilities. adconfig.txt: Contains environment information used by all AD utilities. Do not update this file manually. adalldefaults.txt: A template defaults file that contains entries for all defaults-enabled prompts in AD utilities. Can be copied to APPL_TOP/admin/<SID>/<new_name>.txt and edited. Used for AD utilities run in non-interactive mode. applprod.txt: The AD utilities product description file, which is used to identify all products and product dependencies. applterr.txt: The AD utilities territory description file. It contains information on all supported territories and localizations.
• #8: <Course name> <Lesson number> - Configuration and Environment Files (cont.) applora.txt: Contains information about required init.ora parameters for runtime. applorau.txt: Contains information about required init.ora parameters for install and upgrade. APPS<CONTEXT_NAME>.env (UNIX) or APPS<CONTEXT_NAME>.cmd (Windows): Calls the appropriate <CONTEXT_NAME>.env (UNIX) or <CONTEXT_NAME>.cmd (Windows) file to set up the Oracle Applications (APPL_TOP) and the Applications technology stack (10.1.2). (Called APPSORA.env in 11 i releases.) <CONTEXT_NAME>.env (UNIX) or <CONTEXT_NAME>.cmd (Windows): The APPL_TOP environment file used to configure the environment to run and maintain Oracle Applications. It is created by AutoConfig. adovars.env (UNIX) or adovars.cmd (Windows): Called by <CONTEXT_NAME>.env (UNIX) or <CONTEXT_NAME>.cmd (Windows) and is used to set environment variables for Java and HTML.
• #9: <Course name> <Lesson number> - Setting the Environment Before you start any AD utility, you must first set the Oracle Applications environment: 1. Log in as applmgr (Applications file system owner). 2. Run the environment or command file for the current APPL_TOP and database. Note: See the Oracle Applications Installation Update Notes for any additional steps. UNIX: The environment file is typically APPS<CONTEXT_NAME>.env, and is located under APPL_TOP. From a Bourne or Korn shell, type the following: $ . APPS<CONTEXT_NAME>.env Windows: Run %APPL_TOP%\\envshell<CONTEXT_NAME>.cmd using the Run command from the Start menu. This creates a Command Prompt window that contains the required environment settings for Oracle Applications. Run all subsequent commands in this Command Prompt window. 3. If you have made any changes to the environment, check that they are correctly set by entering the following commands: UNIX: $ echo $TWO_TASK $ echo $ORACLE_HOME $ echo $PATH Windows: C:\\> echo %LOCAL% C:\\> echo %ORACLE_HOME% C:\\> echo %PATH% C:\\> echo %APPL_CONFIG% ORACLE_HOME must be set to the OracleAS 10.1.2 Oracle home, and TWO_TASK or LOCAL must identify the correct database. On Windows, APPL_CONFIG must be set to <CONTEXT_NAME>. 4. Ensure that there is sufficient temporary disk space. You should have at least 50 MB in the temporary directories denoted by $APPLTMP, $APPLPTMP, and $REPORTS_TMP (UNIX) or %APPLTMP%, %APPLPTMP%, and %REPORTS_TMP% (Windows). You should also have space in the operating system’s default temporary directory, which is usually /tmp or /usr/tmp (UNIX) or C:\\temp (Windows). 5. Shut down all concurrent managers if you plan to relink Oracle Applications product files or modify Oracle Applications database objects.
• #10: <Course name> <Lesson number> - The AD Utilities The AD utilities perform a variety of tasks, including generating files, updating your system, merging and applying patches, and installing off-cycle products. There are three primary AD utilities: AD Administration and AutoPatch. Several other maintenance utilities were developed for specific Oracle Applications maintenance tasks. As one AD utility runs, it may automatically call one of the other utilities. However, you can also run most utilities directly. The following is a list of AD utilities and their program names. AD Administration: adadmin AutoPatch: adpatch AD Controller: adctrl
• #11: <Course name> <Lesson number> - The AD Utilities AD Relink: adrelink AD Merge Patch: admrgpch AD Splicer: adsplice
• #12: <Course name> <Lesson number> - The AD Utilities File Character Set Converter: adncnv AD Configuration: adutconf.sql AD File Identification: adident AD Timing Report: adtimrpt.sql
• #13: <Course name> <Lesson number> - The AD Utilities The following utilities are run from OAM: AutoConfig: Accessed through OAM and command line (adautocfg.sh or adautocfg.cmd) License Manager: Accessed through OAM
• #14: <Course name> <Lesson number> - The AD Utilities Patch Wizard: Accessed through OAM Applied Patches: Accessed through OAM
• #15: <Course name> <Lesson number> - Running the AD Utilities To run an AD utility, type the utility’s start command (such as adpatch, adadmin or adaimgr) and answer the prompts. You can exit most utilities by entering abort at any prompt. You can restart by typing the start command for that utility. When you restart, you can enter a new log file name or specify the log file from the previous session. When you reuse a log file, the utility adds the message “Start of <utility name> session” to the end of the file and appends messages from the continued session as it generates them. You can then do one of the following: Continue session (the default) The utility restarts at the point where your last session stopped. Start new session The utility asks you to confirm your choice if you choose not to continue the previous session. It then starts from the beginning. Note: Oracle Applications recommends continuing a prior session to completion.
• #16: <Course name> <Lesson number> - Command Line Arguments Enter AD command line arguments in lowercase. The "token" portion of the command is converted to lower-case, but the "value" is not. In some cases, "value" is a comma-separated list. Note that AD command line arguments cannot contain embedded whitespace characters. Note: Not all AD command line arguments are covered in this course as some should only be used when instructed by Oracle Support Services. Instructor Note: There is an Oracle internal-only document available on Oracle MetaLink (Note 233038.1) that describes additional AD command line options.
• #17: <Course name> <Lesson number> - Command Line Arguments The first line with invalid syntax contains a space between the arguments. On the second line with invalid syntax, the token ("OPTIONS") will be converted to lowercase, but the values (NOCOPYPORTION,NOGENERATEPORTION) will not be recognized in uppercase. Example of using multiple command line arguments: adpatch printdebug=y options=validate flags=hidepw
• #18: <Course name> <Lesson number> - Command Line Arguments - abandon The default is n, meaning that the last utility run non-interactively did not successfully complete the processing and the incomplete session will not be abandoned. Use abandon=y after a failed non-interactive session or you have aborted a prior session and you want to skip the incomplete non-interactive session and start a new one.
• #19: <Course name> <Lesson number> -
• #20: <Course name> <Lesson number> - Command Line Arguments - help Using the help argument does not actually run the utility.
• #21: <Course name> <Lesson number> -
• #22: <Course name> <Lesson number> -
• #23: <Course name> <Lesson number> -
• #24: <Course name> <Lesson number> -
• #25: <Course name> <Lesson number> - Command Line Arguments - parallel_index_threshold If a table contains less blocks than the threshold setting, indexes are created with parallel workers and serial DML. If the table contains more blocks than the threshold setting, indexes are created with one worker and parallel DML.
• #26: <Course name> <Lesson number> -
• #27: <Course name> <Lesson number> -
• #28: <Course name> <Lesson number> -
• #29: <Course name> <Lesson number> -
• #30: <Course name> <Lesson number> -
• #31: <Course name> <Lesson number> - AD Utilities Flags - hidepw Lines in an AD utility log file containing passwords are masked to not display the passwords. When nohidepw is specified, each line containing masked passwords is followed by a corresponding line prefixed with HIDEPW. The HIDEPW line shows the original line with passwords. When hidepw is specified, the HIDEPW: line is not displayed.The hide password functionality now also masks the password on the screen.
• #32: <Course name> <Lesson number> - AD Utilities Flags - logging LOGGING is the default in AutoPatch to support database media recovery and standby databases. We do not recommend using flags=nologging for production systems unless you make a complete backup both before and after running AutoPatch. Instructor Note: flags=nologging affects indexes created through ODF only, not SQL scripts. The XDF utility always creates indexes with logging. XDF is the next generation ODF.
• #33: <Course name> <Lesson number> - AD Utilities Flags - trace The flags=trace option creates multiple trace files for the AD utility and the AD workers. There is a new trace file each time the utility connects to the database. Note that flags=trace only traces database operations internal to the AD utility itself. Database operations in SQL scripts or external programs run by the AD utility are not recorded by flags=trace.
• #34: <Course name> <Lesson number> - AD Utilities Features AutoPatch and AD Administration, and some of the other utilities, employ certain common features. For example, they perform processing tasks in parallel, create log files, and make extensive use of prompts to gather the values for system-specific information.
• #35: <Course name> <Lesson number> - AD Feature Versions AD has several major features that require the files on the file system and the tables in the database to match. To ensure this, each major feature now has both a file system and database version, and AD only enables the feature if the file system and database versions match.
• #36: <Course name> <Lesson number> - AD Feature Versions During the initial startup of some AD utilities, the Feature Versions information will scroll across your screen. This example shows that the file system and database versions of key AD features are synchronized. The Active column states whether the feature is implemented. Instructor Note: There are six flags to the right of the information in the screen, which look like “Y Y N Y N N.” The meaning of the flags is as follows: First flag: Is the feature enabled in the APPL_TOP? Second flag : Does the feature require an enabling file on the file system? Third flag: Does the enabling file exist? Fourth flag: Does the feature depend on any database objects? Fifth flag: Is the value of the 6th flag relevant? Sixth flag: Is the feature enabled in the database?
• #37: <Course name> <Lesson number> - AD Prompts Many of the AD utilities prompt for the information needed to complete a task. Prompts typically include a description of the information needed, and may include a default answer (in square brackets). For example: The ORACLE username specified below for Application Object Library uniquely identifies your existing product group: APPLSYS Enter the ORACLE password of Application Object Library [APPS] : Press Return to accept the default value, or type a new value after the colon and press Return. Attention: Read the prompts carefully to make sure you supply the correct information.
• #38: <Course name> <Lesson number> - Parallel Processing Parallel processing is controlled by job managers , which, in turn, direct the actions of worker processes. The workers complete processing tasks assigned to them by the manager. Utilities that use parallel processing determine the list of tasks to be performed and prioritize them for execution. The utility also prompts for the number of workers you want to perform the tasks. For example, when AutoPatch is executing a database driver, it creates a list of database tasks and prompts for the number of workers that should run concurrently to execute these tasks. AutoPatch and AD Administration are the manager processes in this model. The worker processes are instances of the adworker program. The adworker program can only be called by the manager processes and cannot be run stand-alone. The manager creates the FND_INSTALL_PROCESSES table, assigns each worker a unique ID, and inserts a row for each worker. This table serves as a staging area for the job information, and as a way for the manager and the worker to communicate. Communication is accomplished using two columns: CONTROL_CODE and STATUS.
• #39: <Course name> <Lesson number> - Parallel Processing - Managers The manager updates the table with a subset of the list of jobs, one job per worker. For example, if there are five workers, then the table holds five jobs (even though there may be 100 or more jobs involved in the complete action). The manager starts the workers and uses the CONTROL_CODE and STATUS columns to assign tasks. It polls these two columns continuously, looking for updates from the workers. As a worker finishes its assignment, the manager updates each row with the next task in the list, and leaves another message for the worker. Once all jobs are complete, the manager tells the workers to shut down, and then drops the FND_INSTALL_PROCESSES table (after it is sure all workers have actually shut down).
• #40: <Course name> <Lesson number> - Parallel Processing - Workers Each worker updates the STATUS column, giving the manager a report on its progress. As the jobs are completed, the manager updates the table with the next job in the queue, and updates the CONTROL_CODE and STATUS columns telling the worker to start processing. If there is a failure, the worker reports a failed status. For certain tasks, worker processes spawn other child processes that do the actual work. The spawned child process returns a status code to the worker that spawned it. The worker interprets the code to determine if the job completed successfully. Examples of child processes are SQL*Plus and FNDLOAD. Use AD Controller to determine the status of workers and to control their operation.
• #41: <Course name> <Lesson number> - Parallel Processing - Deferred Jobs The deferred job feature uses the AD_DEFERRED_JOBS table. This table is created when the FND_INSTALL_PROCESSES table is created, and is dropped when the FND_INSTALL_PROCESSES table is dropped. Instructor Note: Total runtime of the job is the time required to complete the job.
• #42: <Course name> <Lesson number> -
• #43: <Course name> <Lesson number> - Note: Con is short for disable constraints and foreign keys.
• #44: <Course name> <Lesson number> - Distributed AD Many deployments utilize large database servers and multiple, smaller application (middle) tier systems. With the increasing deployment of low cost Linux-based systems, this configuration is becoming more common. A feature that facilitates distribution of work across such a system is therefore useful. Historically, AD has always utilized a job system, where multiple workers are assigned jobs. Information for the job system is stored in the database, and workers receive their assignments based on the contents of the relevant tables. The Distributed AD feature offers improved scalability, performance, and resource utilization, by allowing workers of the same AD session to be started on multiple application tier nodes, utilizing available resources to complete their assigned jobs more efficiently.
• #45: <Course name> <Lesson number> - Distributed AD Because the AD workers create and update file system objects as well as database objects, a shared APPL_TOP must be used to ensure the files are created in a single, centralized location. Instructor Note : See Chapter 9 of Oracle Applications Concepts for an introduction to using a shared APPL_TOP and shared application tier file system. For additional details, see Oracle MetaLink Note 384248.1, Sharing the Application Tier File System in Oracle E-Business Suite Release 12.
• #46: <Course name> <Lesson number> - Distributed AD On one of the shared APPL_TOP nodes, you start an AutoPatch or AD Administration session, specifying the number of local workers and the total number of workers. While using AutoPatch or AD Administration, you can start a normal AD Controller session from any of the nodes in the shared APPL_TOP environment to perform any standard AD Controller operations, using both local and non-local workers. Instructor Note: The job system can be invoked multiple times during AutoPatch and AD Administration runs. Each time an individual invocation of the job system completes, distributed AD Controller sessions will wait until either the job system is invoked again (at which point it will once again start the local workers) or until the AD utility session ends (at which point distributed AD Controller will exit).
• #47: <Course name> <Lesson number> - Log Files All AD utilities record their processing actions and any errors in log files. Many utilities prompt you for the name of the log file that will record the processing session. The default file name is <utility name>.log. For example, for AD Administration, the default log file is adadmin.log. The three primary AD utilities place the log file in $APPL_TOP/admin/<SID>/log, where <SID> is the value of your ORACLE_SID or TWO_TASK variable (UNIX), or in %APPL_TOP%\\admin\\<SID>\\log, where <SID> is the value of the LOCAL variable (Windows). Some utilities may not prompt you for a log file name, and they may write their log file in the directory from which the utility was run. Instructor Note: The location to which each utility writes its log file is covered in the specific utility section.
• #48: <Course name> <Lesson number> - Worker Log Files In addition to the information recorded in the <utility name>.log file, utilities that process jobs in parallel mode write details about any errors to worker log files. Review these adwork<number>.log files (adwork001.log, adwork002.log...) for information about any errors. These files are written to the $APPL_TOP/admin/<SID>/log directory, where <SID> is the value of the ORACLE_SID or TWO_TASK variable (UNIX), or in %APPL_TOP%\\admin\\<SID>\\log, where <SID> is the value of ORACLE_SID or LOCAL (Windows). Concurrent requests submitted during an AutoPatch or AD Administration session have their own log files, typically with a file extension of .req.
• #49: <Course name> <Lesson number> - Restart Files By default, AD utilities delete their restart files when processing completes, but leave backup versions with the extensions .bak, .bk2, or .bk3. Each worker may also have a restart file called adworkxxx.rf9. These files are stored in $APPL_TOP/admin/<SID>/restart or in %APPL_TOP%\\admin\\<SID> \\restart on Windows. The worker creates the restart file when the manager assigns it a job, and deletes the restart file when it finishes the job. Warning: Do not modify or delete any manager or worker restart files unless specifically told to do so by Oracle Support Services.
• #50: <Course name> <Lesson number> - Manager and Worker Log Messages AutoPatch and AD Administration act as managers that coordinate a number of workers and assign them jobs to run during the task. When these utilities are running, you see messages like the following on the screen: Starting phase 0 (A0): first There are now 2 jobs remaining (current phase=A0): 0 running, 2 ready to run and 0 waiting. Assigned: file ad_wait1sec.sql on worker 1 for product ad username APPLSYS. Assigned: file ad_wait2sec.sql on worker 2 for product ad username APPLSYS. FAILED: file ad_wait1sec.sql on worker 1 for product ad username APPLSYS. Deferred: file ad_wait1sec.sql on worker 1 for product ad username APPLSYS. (Defer number 1 for this job) Assigned: file ad_wait1sec.sql on worker 1 for product ad username APPLSYS. Completed: file ad_wait2sec.sql on worker 2 for product ad username APPLSYS. FAILED: file ad_wait1sec.sql on worker 1 for product ad username APPLSYS. Deferred: file ad_wait1sec.sql on worker 1 for product ad username APPLSYS. (Defer number 2 for this job) Assigned: file ad_wait1sec.sql on worker 1 for product ad username APPLSYS. FAILED: file ad_wait1sec.sql on worker 1 for product ad username APPLSYS. ATTENTION: All workers either have failed or are waiting: FAILED: file ad_wait1sec.sql on worker 1. ATTENTION: Please fix the above failed worker(s) so the manager can continue. Restarted: file ad_wait1sec.sql on worker 1 for product ad username APPLSYS. Completed: file ad_wait1sec.sql on worker 1 for product ad username APPLSYS. These messages indicate what each worker is doing. The example shows two workers running SQL scripts for one product, which is identified by its abbreviation (ad).
• #51: <Course name> <Lesson number> - Manager and Worker Log Messages In this example, worker 1 failed on the file adcjmdt.sql for Applications DBA (ad). If the job can be deferred, the manager displays a message that the job is deferred and assigns another job to the worker. If the job cannot be deferred, the worker, the failed job, and all jobs that depend on the failed job are idle after a worker fails. The manager continues to assign jobs that are not dependent on the failed job to the other workers. The AutoPatch, or AD Administration session is not complete until all jobs run successfully. When a job fails, determine the cause of failure, fix the problem, and restart the job.
• #52: <Course name> <Lesson number> - Maintenance Mode Maintenance mode is a mode of operation in which the Oracle Applications system is made accessible only for patching activities. This provides optimal performance for AutoPatch sessions, and minimizes downtime needed. Administrators can schedule system downtime using Oracle Applications Manager, and send alert messages to users about the impending downtime. When maintenance mode is enabled, users attempting to log on to Oracle Applications are redirected to a system downtime URL. Maintenance downtimes are scheduled through OAM. Maintenance mode is only needed for AutoPatch sessions. Other AD utilities do not require maintenance mode to be enabled. Instructor Note : Maintenance Mode minimizes downtime by shutting down the Workflow Business Events System, which uses the Cache Invalidation Workflow feature to generate Java cache invalidation messages for changes to seed data, and, as a result, impairs the performance of FNDLOAD. As some patch sessions update a significant amount of seed data, and also require running FNDLOAD in the background, disabling Cache Invalidation Workflow improves the performance of AutoPatch sessions.
• #53: <Course name> <Lesson number> - Maintenance Mode You can toggle Maintenance Mode between enabled and disabled using the Change Maintenance Mode menu in AD Administration, or the equivalent function in Oracle Applications Manager.
• #54: <Course name> <Lesson number> -
• #55: <Course name> <Lesson number> -
• #56: <Course name> <Lesson number> -
• #57: <Course name> <Lesson number> - Refer to Practice - Setting the Applications Environment and Locating the AD Utilities [ LAB41F6Y ]