ORA E-Business Suite – System Administrator

EBS-1 2009 Cristian Stanca S.C. RomSoft S.R.L.

Oracle E-Business Suite System Administrator


Components and Architectureof Oracle Applications

• The Oracle E-Business Suite is a complex ERP (Enterprise Resource Planning) program that consists of many components.

• The primary components that comprise the E-Business Suite are the Client, Forms Server, Web Server, Concurrent Processor, and Oracle Database. Each of these plays a role in servicing Oracle Applications.


Oracle Applications Components & Architecture


Servicing User Requests—OracleApplications Components

• In order to understand the primary components of the Oracle E-Business Suite, it is important to know how the user accesses the application. As the first step to accessing Oracle Applications, a user will launch a web browser and enter the URL (http://app.vulcan.ro:8008) that is the web entry point for the application. The Web Server then services the access request.


Servicing User Requests—OracleApplications Components

• The first page that is displayed by the Web Server is a login screen. Once logged in, the user picks a responsibility, such as System Administrator, and then a menu option, such as Security: User Define, ➤to begin his work. The menu option will direct the user to an HTML or JavaServer Pages (JSP) page, or to a Forms application. The Web Server will continue to service HTML or Java servlet requests; however, if a Forms application is launched, a Forms servlet or the Forms Server will service it. Throughout this process, the user is retrieving data and executing packages from within the Oracle Database.


Oracle Applications Components

• Client: The requirements and processes on the user workstation

• Web Node: Web Server processes that run on the Web Node

• Forms Node: Forms Server processes that run on the Forms Node

• Concurrent Processing Node: Concurrent Manager processes running on the Concurrent Processing Node

• Admin Node: Administrative tasks executed on the Admin Node

• Database Node: Database services that run on the Database Node


Oracle Applications ComponentsClient

• Users accessing Oracle Applications are required to have an Oracle-certified web browser, such as Microsoft Internet Explorer or Netscape. Oracle Applications are served as either web applications or Oracle Forms. A user’s first interaction with the application is a login screen that is presented in the web browser, and from there the user can either continue to access web pages or can access Forms applications. The Oracle JInitiator plug-in is required to run Oracle Forms as Java applets on the Client.


Oracle Applications ComponentsClient


Oracle Applications Components Web Node

• The user initially accesses the application via a web browser with a URL for the web entry point. The Web Server services this web page request. For Oracle applications, the Web Server is the Oracle Application Server, which is based on Apache technology, and the Web Node is the node that runs this server. The Oracle Application Server is also called iAS, AS, Oracle HTTP Server (OHS), or simply Apache.

• The iAS listens for incoming requests on a specific port. The iAS also runs the JServs that are used to service Java requests. For Oracle Applications, the iAS may also be configured to run Forms servlets. If this is the case, then the iAS will also service Forms sessions.


Oracle Applications Components Web Node


Oracle Applications Components Forms Node

• If Forms servlets are not configured for the iAS, then Forms sessions are serviced by the Forms Server. When a Forms request is initiated, the iAS hands off the Forms request to the Forms Server. Much like the iAS, the Forms Server listens for incoming requests on a specific port. The Forms Node is the node that runs the Forms Server.

• The Forms server hosts the Oracle Applications forms and associated runtime engine that support the professional interface. It is an Oracle Developer 6i component that mediates the communication between the desktop client and the Oracle database server, displaying client screens and initiating changes in the database according to user actions.


Oracle Applications Components Forms Node


Oracle Applications Components Concurrent Processing Node

• Concurrent processing is a special feature of Oracle Applications. It allows the user to schedule jobs, which Oracle calls requests. These requests may be standard Oracle requests or custom requests, they can be scheduled as onetime requests or on a repeating schedule, and they can be submitted to execute immediately or at a specific time. Requests are scheduled with the scheduling manager, which is called the Concurrent Manager. The node that runs the Concurrent Manager processes is called the Concurrent Processing Node.


Oracle Applications Components Reports Server

• The Reports server is automatically installed on the same node as the Concurrent Processing server, and its reports are contained in the same directory as the concurrent processing reports. However, reports generated by the Reports server are monitored and administered separately from concurrent processing reports. The Reports server dynamically selects the report language at runtime, so users see their reports in their preferred language.


Oracle Applications Components Reports Server


Oracle Applications Components Admin Node

• There are many administrative tasks that are executed in order to maintain the Oracle E-Business Suite, such as regenerating forms, regenerating jar files, applying application patches, and recompiling flexfields. The Admin Node is used to execute administrative tasks.

• You carry out the following operations from this server:

• Upgrading Oracle Applications - AutoUpgrade utility (adaimgr)

• Applying database patches to Oracle Applications - AutoPatch utility (adpatch)

• Maintaining Oracle Applications data - AD Administration utility (adadmin)


Oracle Applications Components Database Node

• The heart and soul of the E-Business Suite is the database. The database not only stores the data in tables under various schemas, but also stores many other objects (such as procedures, packages, database triggers, functions, indexes, and sequences) that are required for the application to function. The Database Node is where the Oracle Database instance runs and accesses the database files.


Oracle Applications ArchitectureFundamental Architecture

• When a system is deployed with a basic approach to architecture, it typically does not have large transactional processing requirements or a large concurrent user base. For this environment, there are no special configuration requirements. These implementations may run on one tier, meaning that all nodes are running on one physical server, but this is a very inefficient method.

• Some implementations run the application components on one server, while the database node runs on a separate server. This is a two-tier architecture. Multi-tier environments do not require special configuration or design effort unless multiple nodes for the same component are required.


Oracle Applications Architecturetwo-tier architecture


Oracle Applications Architecture Advanced Architecture

• When more nodes of the application tier are split across multiple servers, and additional nodes are defined for the same component, we begin to enter into advanced configuration topics and design.

• Advanced, multi-tier configurations for Oracle Applications include combining multiple Web, Forms, Concurrent Processing, and Database Nodes. The number of nodes required is dependent upon your environmental requirements for concurrent user support and transactional processing.


Oracle Applications Architecture an advanced multi-tier architecture


Oracle Applications Maintenance

• After your system is installed, it will be necessary to perform certain maintenance tasks to keep it running smoothly. For example, you will generate form files, maintain snapshot information, relink executables, compile or validate the APPS schema, and so on. Some tasks are routine, and should be performed on a regular basis. Other tasks are performed more infrequently.

• You run maintenance tasks from the command line using AD Administration. Once you start this utility, it presents the tasks in menu form, grouped generally by type of activity you will perform. For example, the tasks associated with compiling and reloading Applications database entities are grouped on the same menu.


Oracle Applications MaintenanceAD Administration

• AD Administration manages most of the maintenance tasks required for your Oracle Applications system. Currently, these maintenance tasks are grouped by the following types: generating Applications files, maintaining Applications files, compiling and reloading Applications database entities, maintaining Applications database entities, and enabling maintenance mode.

• When you start AD Administration from the command line, it prompts you for the basic system-specific information it needs. For example, you need to supply a name for the log file where processing actions and error messages will be recorded.


AD Administration Interface Main Menu

[app@app PROD_app]$ adadmin


AD Administration InterfaceGenerating Applications Files

• You may need to generate Applications files from time to time during your Applications life cycle. You access the associated tasks from the Generate Applications Files menu.

• If system users are having difficulty accessing messages, forms, reports, or graphics, you may be able to resolve the issue by generating the associated files. Or, when you apply a patch that adds or changes product functionality, you may want to generate the associated files after you apply the patch, instead of running the generate driver during the patching downtime. The generate files tasks may be performed on any server, as required.


AD Administration InterfaceGenerating Applications Files Menu



• Generate message files

• Oracle Applications uses these files to display messages. This task generates message binary files (extension .msb) from Oracle Application Object Library tables.

• Generate form files

• Generates executable Oracle form files (extension .fmx) from the binary forms definition files (extension .fmb). The definition files are located under AU_TOP, and the executable files are stored under each product’s directory.

• Generate report files

• Generates the binary Oracle Reports report files (extension.rdf).



• Generate graphics files

• Generates the Oracle Graphics files (extension .ogd) from the graphics definition files (extension .ogx).

• Generate product JAR files

• Generate Java archive (JAR) files whenever you upgrade the Developer6i technology stack or when recommended by Oracle Support Services.


AD Administration Interface Maintaining Applications Files

• Certain maintenance tasks are required to keep your Applications files up to date. For example, you may need to copy product files to a central location or convert files in the APPL_TOP to another character set. These tasks are grouped on the Maintain Applications Files menu.

• Some of these tasks are performed for you without having to run AD Administration. For example, each time you run AutoConfig, it creates the environment file. However, when required, you can run any of these tasks by choosing it from this menu. They may be performed on any server, as required.


AD Administration Interface Maintaining Applications Files Menu



• Relink Applications programs

• Relinks Oracle Applications executable programs with the Oracle server libraries so that they function with the Oracle database. For each product, choose whether to link all executables or only specific ones.

• Create Applications environment file

• Creates an environment file (UNIX) or an environment subkey (Windows registry) that defines your system configuration. The environment file is placed directly under the APPL_TOP (UNIX) or under the \\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\APPLICATIONS\11.5.10 subkey (Windows registry).



• 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.

• Convert character set

• Prepares the files in the APPL_TOP for conversion to another character set, and then performs the conversion.



• Maintain snapshot information

• There are two types of snapshots: APPL_TOP snapshots and global snapshots. An APPL_TOP snapshot lists patches and versions of files in the APPL_TOP. A global snapshot lists patches and latest versions of files in the entire Applications system (that is, across all APPL_TOPs).

• Check for missing files

• 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 there are files missing in your APPL_TOP.


AD Administration Interface Compiling or Reloading Database Entities

• Database entities are database objects or data in the database related to Oracle Applications.

• You run the tasks on this menu any time you need to compile or reload database objects. For example, after you upload new menu entries or apply a patch that changes the setup of flexfields. Run these tasks only on the node where the core AD technology directories (the administration server) are located.


AD Administration Interface Compiling or Reloading Database Entities -

Menu



• Compile APPS schema

• Spawns parallel workers to compile invalid database objects in the APPS schema.

• 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.

• AD Administration asks if you want to force compilation of all menus. If you choose the default (No), only menus with changes are compiled. If you enter Yes, all menus are compiled. Compiling all menus is generally not advised



• Compile flex field data

• Compiles flexfield data structures in Oracle Application Object Library (FND) tables. Choose this task after you apply a patch that changes the setup of flexfields. Patches usually indicate when you should perform this step.

• Reload JAR files to database

• Reloads all appropriate Oracle Applications JAR files into the database. Choose this task if all Oracle Applications Java classes are removed from your database, for example, if the database Java Virtual Machine (JVM) is reloaded because of a corrupt database.


AD Administration InterfaceMaintaining Applications Database Entities

• During normal system use, the integrity of your database can be compromised, for example through user error or after you apply a large patch. It’s a good idea to verify the integrity of database entities as a regular maintenance procedure, or whenever the behavior of your system indicates that database entities may have been corrupted. These maintenance tasks are grouped on the Maintain Applications Database Entities menu.

• Some tasks on this menu report on issues, or potential issues, with database entities, and others actually remedy the issues. Run these tasks only on the node where the core AD technology directories (the administration server ) are located.



- Menu



• Validate APPS schema

• Verifies the integrity of the APPS schema. It produces a report named <APPS schema name>.lst (located in $APPL_TOP/admin/<SID>/out) that lists issues and potential issues, grouped by the action required:– Issues you MUST fix (not specific to the APPS schema)– Issues you MUST fix (specific to the APPS schema)– Issues you may want to address (specific to the APPS

schema)

• Most issues can be fixed by either compiling invalid database objects or recreating grants and synonyms.



• Recreate grants and synonyms for APPS schema

• This task 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 schema. Typically, you run this task after the Validate APPS schema task has reported issues with missing grants and synonyms.

• Maintain multi-lingual tables

• Run this task after you add a language. It prompts you for the number of workers, then updates all multilingual tables.



• Check DUAL table

• Some Oracle Applications products must access the DUAL table. It must exist in the SYS schema and contain exactly one row. This tasks verifies the existence of this table and the single row.

• Maintain [or Convert to] Multiple Reporting Currencies

• If you have installed Multiple Reporting Currencies (MRC) functionality, this menu option is called Maintain Multiple Reporting Currencies schema. If you have not, it is called Convert to Multiple Reporting Currencies, which you use to install MRC.



• Convert to Multi-Org

• Appears as a menu choice only if Multi-Org is not installed in your database. Use it to convert a standard product group into a Multi-Org product group with one operating unit defined at the site level. The Convert to Multi-Org task does the following: – Asks for the number of parallel workers.– Disables all enabled triggers in the APPS schema. – Converts seed data and transaction data to Multi-Org in

parallel. – Re-enables all previously disabled triggers in the APPS

schema.


AD Administration InterfaceChanging Maintenance Mode

• Maintenance mode affects the process of maintaining Oracle Applications and must be enabled to optimize performance and reduce downtime of AutoPatch sessions. You toggle maintenance mode from enabled to disabled by using the Change Maintenance Mode menu of AD Administration.

• When you choose Change Maintenance Mode from the Main Menu, the Change Maintenance Mode menu appears with the maintenance mode status displayed at the top.

• Select option 1 to enable maintenance mode or option 2 to disable it. Maintenance mode must be enabled before running AutoPatch and disabled during normal runtime operation.


AD Administration InterfaceChanging Maintenance Mode


Oracle Applications Maintenance Preventative Maintenance

• There are many tasks that need to be performed on a regular basis to maintain the overall health of the Oracle E-Business Suite. Many of these tasks should be scheduled with crontab, EM 10g Grid Control, or a like utility, or as a concurrent request.

• The following preventative maintenance topics will be discussed:

• Gathering statistics

• Recompiling invalid objects



• Gathering Statistics

Statistics are gathered so that the cost based optimizer (CBO) can determine the best execution plan for queries that are executed. For Oracle Applications, statistics may be gathered with the fnd_stats package or with a few Oracle-standard concurrent requests. Regardless of the method chosen, statistics should be gathered on a regularly scheduled basis. Failure to do so will result in severe performance degradation.

While the frequency with which statistics are gathered is environment specific, it is recommended that you gather stats at least once per week. If an environment experiences frequent data changes throughout the week, this frequency may not be sufficient.



• Gathering Statistics Using fnd_statsThe fnd_stats package is based on the standard Oracle

dbms_stats package. It was created to generate statistics for the Oracle E-Business Suite. This package should be executed on the database as the APPS user.

Procedures available for gathering statistics with fnd_stats:

• fnd_stats.gather_schema_statistics: Gather statistics for schemas

• fnd_stats.gather_tables_stats: Gather table-level statistics

• fnd_stats.gather_column_stats: Gather column-level statistics

• fnd_stats.gather_index_stats: Gather index statistics



• Gathering Statistics with Concurrent Requests

Statistics may also be gathered by scheduling standard Oracle concurrent requests. The following is a list of the concurrent requests available to gather statistics:

• Gather schema statistics: Used to gather statistics for schemas

• Gather table statistics: Used to gather table-level statistics

• Gather column statistics: Used to gather column-level statistics

• Analyze all index column statistics: Used to gather index statistics



• Recompiling Invalid Objects

Objects in the database will at times become invalid. While most objects will recompile upon access, sometimes dependencies upon other objects hinder this ability.

Recompiling invalid objects can also be performed with the adadmin utility. To recompile invalids using adadmin, first select menu option 3 (Compile/Reload Applications Database Entities), then menu option 1 (Compile APPS schema). Recompiling invalids using adadmin is a manual process; however, it allows for a parallel recompile of invalid objects owned by the APPS schema.


Oracle Applications PatchingAbout Patches and Patching

• Throughout the course of the Oracle Applications life cycle, patches are applied for a number of reasons, including:

• Updating to a higher maintenance level

• Applying the latest product enhancements

• Adding a new feature or functionality

• Fixing an existing issue

• Based on the type of patch, it may update the file system, or the database, or both. Patches are applied and tracked as needed by using one of the utilities designed specifically for that purpose. Some of these utilities are run from the command line, and others are web-based.


Oracle Applications PatchingTypes of Application Patches

• There are several different types of Oracle Applications patches. These are the more common patches:

• One-off patch: This is the simplest type of patch. It is created to resolve a specific bug.

• Minipack patch: This is a collection of one-off patches and enhancements related to a particular module. Alphabetic characters denote the Minipack version for the module; for example, the product code for the Application DBA utilities is AD, and version Minipack I of this product would be called AD.I.



• Family Pack patch: This is a collection of Minipack patches for a particular family group of application modules. Alphabetic characters denote the Family Pack version; for example, the J version of the Human Resources Suite Product Family would be HR_PF.J.

• Maintenance Pack patch: This is a collection of Family Packs that serves as a point-level release upgrade; Oracle Applications Release 11.5.10 is an example of a Maintenance Pack.



• There are also other special types of patches:

• Consolidated patch: This is a collection of one-off fixes for a Family Pack or Maintenance Pack; Oracle Applications 11.5.10 Consolidated Update 2 (CU2) is an example of a consolidated patch.

• Interoperability patch: This is a patch that is required for Oracle Applications to function with a newer version of a technology stack component; for example, you would apply an interoperability patch when upgrading the database to version 10g.

• NLS patch: This is a patch that updates language-specific information for multi-language installations.



• Rollup patch: This is a collection of one-off patches that update code levels for particular products.

• Legislative patch: This is a special patch for HR Payroll customers; it contains legislative data for multiple countries.


Oracle Applications PatchingPatch File Structure

• Patches generally consist of a top-level directory, several files in the top-level directory, and one or more subdirectories. The top-level directory is named <patchnum>, where <patchnum> is the number of the patch. The most important files in the top-level directory are: README.txt, README.html and the driver files (c<patchnum>.drv, d<patchnum>.drv, g<patchnum>.drv and u<patchnum>.drv). For most patches, applying the patch drivers is the only action required.


Oracle Applications Patching Patch Driver Files

• A patch may contain one or more split patch driver files. A split driver means that patch actions are divided by function: a copy driver to change product files, a database driver to change database objects, and a generate driver to generate new forms, messages, graphics, and other new objects. Unless you are instructed to apply only one driver, you always apply split patch drivers in the following order: copy driver, database driver, and generate driver.

• In some cases, rather than split drivers, a patch may contain one unified driver. This driver contains the commands necessary to change files and database objects, and to generate new objects, in a single driver file.


Oracle Applications Patching Preparing your System for Patching

• Enable maintenance mode

• Before you initiate an AutoPatch session, you need to shut down the Workflow Business Events System and set up function security so that no Oracle Applications functions are available to users. This ensures optimal performance and reduces downtime when applying a patch. Maintenance mode (new in 11.5.10), provides a clear separation between normal runtime operation of Oracle Applications and system downtime for maintenance.

• During a maintenance mode downtime, user login is restricted. Users are redirected to a system downtime URL, which informs them that the maintenance session is in progress.


Oracle Applications Patching Preparing your System for Patching

• Shut down services

• If you are applying a patch that updates or relinks files, shut down the concurrent manager, Web server listeners, forms server listeners if the files are on a node that contains the associated servers. For example, if the files are on the node that contains the concurrent processing server, shut down the concurrent managers.


Oracle Applications Patching Applying Patches

• Step 1 Set the environment

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

• Step 2 Unzip patches

• Create a patch top directory, if it doesn’t already exist. Download the patch and unzip it.

• Step 3 Review information in the readme file

• This file contains instructions for applying the patch, including any prerequisite patches and/or manual steps.

• Step 4 Shut down services

• According to the configuration of your system, you may need to shut down concurrent managers, Web server listeners, or forms server listeners.


Oracle Applications Patching Applying Patches

• Step 5 Enable maintenance mode

• Use the Change Maintenance Mode option in AD Administration to enable maintenance mode.

• Step 6 Start AutoPatch

• AutoPatch is located in the AD_TOP/bin directory. However, you start it from the directory that contains the unzipped patch files.

• Step 7 Respond to prompts

• Respond to the AutoPatch prompts for information about your system.

• Step 8 Complete the remaining patching tasks

• Step 9 Exit AutoPatch


Oracle Applications Patching Using AD Patch

• The administrative tool used to apply application patches is AD Patch, also referred to by its command line executable, adpatch.

• The parameters supported by the adpatch command differ depending upon the AD Minipack level applied with Oracle Applications.

• Use the command adpatch help=y to see the available options.

• In order to enable an option with adpatch, use the following syntax:

adpatch options=[option1, option2..]



• The adpatch options shown below are commonly used to accelerate the patching process:

• novalidate Prevents adpatch from validating all schema connections

• noprereq Prevents adpatch from checking the existence of prerequisite patches

• nocompiledb Prevents adpatch from compiling database objects

• nocompilejsp Prevents adpatch from compiling JSP objects

• noautoconfig Prevents adpatch from running autoconfig after the patch has completed



• nogenerateportion Prevents adpatch from compiling forms, menus, and plls

• hidepw Prevents passwords from being displayed in log files

• hotpatch Allows adpatch to be run when the instance is not in maintenance mode


Oracle Applications Patching Monitoring and Resolving Patching

Problems• Patching problems manifest themselves in many

different ways. Typically the adpatch session will display an error or will appear to be hung on one task for a long period of time. The first step in resolving the issue is to review the adpatch log file and associated worker log file. Next, the reason the worker failed must be determined and resolved. After resolution has been obtained, adctrl can be used to continue the patching process.



Problems• Reviewing Log Files

During and after the application of patches, it is helpful to review log files of the adpatch session and its workers. These files are found in the $APPL_TOP/ admin/$CONTEXT_NAME/log directory. The adpatch log filename is specified during the patch process.

In order to monitor the patch from a telnet session other than the one where the patch was started, a simple UNIX command such as tail –f u[patch#].log will display information as it is written to the log file.

The log files for the workers will be named adwork[xxx].log, where [xxx] is the number of the patch worker process. If a particular worker has failed, examine the related log file for detailed information.



Problems• Using AD Control

The administrative tool used to manage patch workers is AD Control, or adctrl. Frequently workers will fail or hang, which will require the Oracle Applications DBA to interface with adctrl.

To execute an adctrl menu option, simply type the menu option and press Enter. If options 2–6 are chosen, either specify the number of the worker that requires action, or press Enter for the action to be executed for all workers.

The “Skip Worker” menu option is a hidden adctrl menu option. If a worker needs to be skipped, start adctrl, enter 8, and then enter the worker number. Only use this option if advised by Oracle Support.



Problems



Problems• Resolving AD Patch Worker Failure

If a worker has failed, the adpatch session will normally display a failedworker message. The status of the worker may also be determined using adctrl. If a worker has failed, the worker error can be obtained by viewing the worker log file. Once the worker issue has been resolved, use adctrl to restart the worker.

If a worker has failed, and it is determined that the step the worker was trying to execute may be skipped, the hidden option 8 of the adctrl menu, “Skip Worker,” may be used to skip the worker. It is only advisable to do this if the step is not critical to the environment being patched.



Problems• Additional Tips for Resolving Patching Issues

If a patch has hung or workers have failed, and the reason for this failure cannot be determined, it is advisable to check the number of invalid objects in the database. If the number of invalid objects is high, recompile the invalid objects in parallel and restart the patching session.

If the adpatch session is hung, and all other methods for resolution have been executed, it may be necessary to bounce the database and restart the patch session. This method for resolving patching issues is sometimes necessary, especially when applying large patches, such as Maintenance Packs.



Problems• Additional Tips for Resolving Patching Issues

If a failure occurs during the application of a patch, it may be necessary to apply another patch to resolve the issue. If this type of issue occurs during the application of a large patch, you may want to be able to restart the original patch from the point of failure. MetaLink Note 175485.1 provides details for applying a patch with adpatch already running.


Oracle Applications Patching Post-Patching Steps

• Many patches require post-patching steps to be executed to complete the patching process. Also, if the patch was applied using options such as nocompiledb, notautoconfig, nogenerateportion, and others, those steps need to be performed now.

• Typical post-patching steps include generating message files, regenerating JAR files, regenerating menu options, relinking executables, recompiling invalids, and recompiling flexfields. Most of the post-patching requirements can be performed with the AD Administration utility, adadmin.

• After the patches have completed, check for additional entries in the dba_jobs table. Verify that any newly created jobs are required by your environment.


Oracle Applications Patching Patching Cleanup

• After a patch has completed, there will be an increase in the used space for the Oracle Applications filesystem. Some of this space can be reclaimed by removing backup copies of application code. For example, located in the $FND_TOP/bin directory are files such as FNDSCH.sav and FNDSCH.xxxxx, where xxxx is a number. These files are copies of the FNDSCH file created by the patch utility.

• A list of directories containing backup files can be created using the UNIX find command. From the $APPL_TOP directory, execute the following command to list the directories containing *.sav files: [testapp@test app]$ find . -name "*.sav"


Oracle Applications Patching Patching Cleanup

• If there are any concerns about the removal of such files, create a temporary directory and move the files from their $[module]_TOP/bin location. After verifying that the system functions properly, these files can be removed.

• Another area of cleanup involves the backup subdirectory of the directory where the patch was unbundled. If you are applying a patch from a common directory to multiple instances, space can be reclaimed in the patch directory by removing files written to the backup subdirectory from previous patch applications.


Oracle Applications Patching Database Patching

• Database patching consists of either upgrades or interim fixes. Database upgrades are typically complex in nature and require installation of new software when upgrading from one point release to another. Obsolete and new initialization parameters must be reviewed when upgrading to a new release of the database.

Database upgrades can be accomplished manually or by using dbmig, the database migration utility. Since the method for upgrading the database is version and platform dependent, the associated readme file for the upgrade must be reviewed, and the steps required to perform the upgrade should be documented.



Interim patch fixes for the database are applied as the owner of the database install with the opatch utility or by running an operating system script. Details on how to apply database patches are outlined in the patch’s readme.

Before upgrading or applying a patch to the database, the oraInst.loc file must point to the correct Oracle inventory location for the database ORACLE_HOME. It is also important to cleanly shut down the database before proceeding, and to perform a cold database backup.



To validate that opatch is functioning properly, execute the following command: $opatch lsinventory

Once opatch has been successfully set up, the database interim patch fix may be applied. To do this, first review the readme file for the patch. Make certain that all prerequisites have been met. Document any post-patching steps that are required. Download the patch and unbundle it. Change to the directory where the

patch has been unbundled. Verify that the database has

been shut down. Apply the patch by executing opatch as the database owner: $opatch apply



To verify that a patch has successfully been applied, the lsinventory option can again be executed. This will display all patches that have been applied to the database.

If the opatch fails, there may be a patch_locked file located under the hidden directory $ORACLE_HOME/.patch_storage. The opatch utility may not be executed until the patch_locked file is removed.


Oracle Applications Advanced Topics Application Instance Clones

• Cloning is a method for copying an application instance and database to a test application instance and database. Clones are often required for development and testing purposes.

• Using Rapid Clone

Oracle’s recommended method for cloning is to use the Rapid Clone utility. Oracle provides the following MetaLink Notes to assist with this process: 230672.1 and 216664.1.



• Using OAM

There is functionality built into OAM to assist with cloning. These wizards can be accessed from the Site Map

Maintenance Cloning➤ ➤ menu options. Two wizards, Simple Clone and Advanced Clone, are available depending upon your requirements.



• Cloning Cleanup

• There are several post-cloning steps that must be performed. Currently the Rapid Clone utility does not clean up workflow-related tables or profiles other than site-level profiles. Additionally, if printer requirements differ, new printers will need to be defined in the cloned instance. Many of these postcloning steps may be scripted and called as post-cloning cleanup. The post-cloning steps for this process are described in MetaLink Note 230672.1.


Oracle Applications - Managing Printers

• Oracle Applications reports are generated by Oracle Reports. A completed report is sent to the operating system by the concurrent manager, which issues an operating system print command, or calls a custom print program that issues an operating system print command.



• Oracle Reports and report generation

Page break, carriage return, line feed, text bold on/off, and text underline on/off instructions within the output file are defined by values in an SRW (SQL*ReportWriter) driver file. Page break, carriage return, and line feed instructions that are issued before the output file is to be printed or after the output file is printed must be entered in an Oracle Applications printer driver’s initialization or reset strings, which are defined by the Printer Drivers form.

Metalink Note: 73999.1



• SRW Drivers and Oracle Applications Printer Drivers

When the report is not to be printed (number of copies = 0 and the target printer field is blank), Oracle Reports uses the SRW driver named by the print style in the Print Styles form.

When the report is to be printed (number of copies > 0) Oracle Reports uses the SRW driver named by the Oracle Applications printer driver in the Printer Drivers form.

The dimensions of a report are determined by the columns and rows values in the print style, defined using the Print Styles form. These values override the width and height values in an SRW driver file.



• Concurrent Manager Issues or Calls a Print Command

When a report is completed, the concurrent manager prepends an initialization string to the output file. The initialization string is defined using the Printer Drivers form.

The concurrent manager appends an reset string to the output file. The reset string is defined using the Printer Drivers form.



• Concurrent Manager Issues or Calls a Print Command

An Oracle Applications printer driver is typically executed in one of two methods, by issuing a print command or calling or print program.

When the printer driver method is Command, the concurrent manager can issue an operating system print command and arguments, entered in the Arguments field of the Printer Drivers form.

When the printer driver method is Program, the concurrent manager can call a custom print program, named (along with its path) in the Name field of the Printer Drivers form. Arguments to the program may be entered in the form’s Arguments field.



• Concurent Manager can provide values for arguments

• the name of the file to be printed

• the operating system name of the target printer

• the title of the file, which appears on a header page if it is printed

• the number of copies to be printed



• Defining Printer Types and Registering Printers

You register a printer so Oracle Applications recognizes the printer andcan forward to it the output from a report program.

To register a printer with Oracle Applications, you must first specify what kind of printer it is by selecting a printer type. Because many printers can be registered as the same type of printer, you need only define each printer type once.



• Defining Printer Types and Registering Printers

You register individual printers with Oracle Applications by specifying the printer’s operating system name, which uniquely identifies the printer, and selecting the type of printer it is.

For example, if you want users of Oracle Applications to be able to print to a newly purchased printer, you:

• Register the operating system name of the new printer (e.g.,printer39), and select the printer type (e.g. LN03).

• If the correct printer type is not defined, you must define the new printer type (e.g., LN03) before you can register the printer



• Print Styles

A Print style defines the page format for a printer; the number of columns (page width), and the number of rows (page length).

Each printer type (i.e., each printer) can have one or more associated print styles.

Print styles allow you to setup report dimensions on a variety of printers.

• For example, users may wish to print a menu report with a wider left margin to allow for hole punching the paper.

• As System Administrator you register this new style, which users can then access if the printer (type) supports it



• Print Styles

At report submission time, users select the style in which to output the report.

• Only styles available on the destination printer are displayed.

• Some concurrent programs predefine either the printer or the print style, and these values may not be changed.



• Printer Drivers

Date post:	01-Jan-2016
Category:	Documents
Upload:	florinidinu
View:	46 times
Download:	0 times

ORA E-Business Suite – System Administrator

Documents