FAQS: What is AutoConfig? AutoConfig is a configuration tool that supports automated configuration of an Oracle Applications Instance.

All of the information required for configuring an Applications instance is collected into a central repository, called the Applications Context. When the AutoConfig tool runs, it uses information from the Applications Context file to generate configuration files and update database profiles. See OracleMetaLink Note 165195.1 for details on installing and migrating to AutoConfig. Does Rapid Clone modify the source system? No, Rapid Clone does not modify the source system. adpreclone.pl prepares the source system to be cloned by collecting information about the database and creating generic templates of files containing source specific hardcoded values. These templates are stored in the appsutil/template directory leaving the original files untouched. This process usually takes a few minutes to complete the first time. Migrating to Autoconfig on the database node (pre-req to Rapid Clone), however, will update the RDBMS init.ora and network listener files. See the instructions in the Autoconfig document 165195.1 (Section 4: Migrating to AutoConfig on the Database Tier) on how to preserve customizations to these files. How does adcfgclone.pl know the target system values? adcfgclone.pl will prompt for the values required to create the new context file used to configure the target system. A few values are calculated from the current target system (hostname, user and group). The rest of the target specific values are prompted for: Prompt Comment database SID Target database SID domain name Target system domain name Prompts specific to the DB Tier Target System database name Target System database name Target instance is a Real Application Cluster (RAC) instance (y/n) Answer yes if the target system is going to be part of a RAC instance. Current node is the first node in an N Node RAC Cluster (y/n) This prompt only appears when you answered "yes" to the previous question. Answer yes" to this question if the current host is the first node being configured in the target system RAC cluster. The tool will then ask for the number of nodes that

will exist in the final RAC instance and gather, the following information for every node: - Hostname - Database Sid - Instance number - Listener port - Private interconnect name

Answer "no" to this qion if at least one node of the target RAC cluster has already been configured by Rapid Clone (i.e if you already replied "yes" to this question for any other node in the cluster). The tool will then prompt for the following information to connect to a life node (the answers must describe a node that has already been configured): - Hostname - Database Sid - Listener port RDBMS ORACLE_HOME directory Path to the Target system RDBMS ORACLE_HOME Number of DATA_TOP's: DATA_TOP 1: DATA_TOP 2: DATA_TOP 3: Database mount points. Enter the number of distinct directories containing the target database dbfs, then their paths. Prompts specific to the Apps Tier database server node hostname of the machine hosting the database server Does the target system have more than one applications tier server node (y/n)? Answer yes if the target system is part of a multi-nodes configuration. The tool with then prompt for the hostnames of: - concurrent processing node - administration node

- forms server node - web server node Is the target system APPL_TOP divided into multiple mount points (y/n)? Answer yes if the target system APPL_TOP is divided across multiple mount points. The tool will then prompt for each auxiliary mount (4 mounts): - APPL_TOP mount point - APPL_TOP aux.1 - APPL_TOP aux.2 - APPL_TOP aux.3 Note: if your APPL_TOP is divided into 2 or 3 mounts only, you can specify identical mounts to the above prompts. APPL_TOP mount point APPL_TOP directory COMMON_TOP directory COMMON_TOP directory 8.0.6 ORACLE_HOME directory 8.0.6 ORACLE_HOME directory iAS ORACLE_HOME directory iAS ORACLE_HOME directory Location of JDK 1.3.1 Location of JDK 1.3.1 Prompt common to DB and Apps Tiers Port pool number:[0-99] Enter the port pool that you want to use on the target system. Make sure to specify the same port pool on the DBTier and the AppsTier. If the source and target machines are different, you have the option to preserve the source port values on the target system. What is the port pool? What if I want to give a specific value to a Server Port? If you are cloning on the same machine or want to redefine the server ports , you will be prompted for a port pool. The port pool provides a way to use a set of predefined server ports. There are 100 port pools. For example, if you select 3, the default database port number (1521) becomes 1524. The following table lists all the server ports. To see how the port pool calculation works, enter a number between 0 and 99(both inclusive) in the form and click "Get Ports". Port Name Autoconfig Variable (Default) Port Numbers allocated for Port Pool: 0 (Custom) Port Numbers allocated for Port Pool:

Web Listener Port s_webport 8000 8001 Database Port s_dbport 1521 1522 RPC Port s_rpcport 1626 1627 Reports Port s_repsport 7000 7001 OPROC Manager Port s_oprocmgr_port 8100 8101 Web PLSQL Port s_webport_pls 8200 8201 Servlet Port s_servletport 8800 8801 Forms Listener Port s_formsport 9000 9001 Metrics Server Data Port s_metdataport 9100 9101 Metrics Server Req. Port s_metreqport 9200 9201 JTF Fulfillment Server Port s_jtfuf_port 9300 9301 iMeeting Collaboration Server Port s_imtsrvport 9500 9501 iMeeting Recording Server Port s_imtrecport 9600 9601 iMeeting Monitor (iMon) Port s_imtimonport 9700 9701 Map Viewer Servlet Port s_mapviewer_port 9800 9801 OEM Web Utility Port s_oemweb_port 10000 10001 VisiBroker OrbServer Agent Port s_osagent_port 10100 10101 MSCA Server Port s_mwaPortNo 10200 10201 MSCA Dispatcher Port s_mwaDispatcherPort 10300 10301 TCF Port s_tcfport 15000 15001 OACORE Servle Port Range s_oacore_servlet_portrange 16000-16009 16010-16019 Discoverer Servlet Port Range s_disco_servlet_portrange 17000-17009 17010-17019 Forms Servlet Port Range s_forms_servlet_portrange 18000-18009 18010-18019 XMLSVCS Servlet Port Range s_xmlsvcs_servlet_portrange 19000-19009 1901019019 Forms Start Port s_frmStartPort 20000 20001

Java Object Cache Port s_java_object_cache_port 12345 12346 If you want to give a specific value to a port on the target system, independently from the port pool, you must first complete the Target System configuration with adcfgclone.pl (temporarily select a value for the port pool). Once adcfgclone.pl completes successfully, edit the new target context file with editcontext or OAM and modify the corresponding Autoconfig variables. Run Autoconfig to refresh the system with the new values (see OracleMetaLink document 165195.1). Does Rapid Clone preserve the patch history? Yes, Rapid Clone preserves the patch history of the complete Applications Stack: RDBMS ORACLE_HOME: preserve the OUI oraInventory. iAS ORACLE_HOME: preserve the OUI oraInventory. 806 ORACLE_HOME: preserve the patch level and ORCA inventory. APPL_TOP and Database: preserve the patch level and history tables. Can I clone a clone? Yes, a cloned system created with Rapid Clone can then be used as the Source System in the next cloning. RapidInstall itself is now a clone of a clone using the Rapid Clone technology. Can I change the database dbf files layout while cloning? Yes, Rapid Clone allows to add or remove database mount points or redidtribute dbf files among mount points in the target system. As long as all the source system dbf files are present in the target system database mount points specified during the adcfgclone prompts (see question "How does adcfgclone.pl know the target system values?"), Rapid Clone will find them and re-create the database control file accordingly. What is the oraInventory? The oraInventory is the location for the OUI (Oracle Universal Installer)'s bookkeeping. The inventory stores information about: All Oracle software products installed in all ORACLE_HOMES on a machine Other non-Oracle products, such as the Java Runtime Environment (JRE) In a 11i Application system the RDBMS and iAS ORACLE_HOMEs are registered in the oraInventory. The 806 ORACLE_HOME, which is not managed through OUI, is not.

On Unix/Linux, the location of the oraInventory is defined by the content of oraInst.loc, at: - /var/opt/oracle/oraInst.loc on Solaris, HP-UX and Tru64 - /etc/oraInst.loc on Linux and AIX On Windows, the location of the oraInventory is defined by the value of the registry key HKEY_LOCAL_MACHINE|Software\Oracle\INST_LOC or if this value is not defined, at C:\Program Files\Oracle\Inventory What is a binary oraInventory? Is my Inventory binary? Before OUI 2.X, the oraInventory was binary. A binary oraInventory centralizes, in a binary format, the location of every Oracle products on the machine and the detail of their patch level. The oraInventory location is defined by the content of oraInst.loc. You will have a binary inventory only if ALL of the following conditions are met: you are on 11.5.7 or earlier (11.5.8+ install XML inventory out of the box) you have never installed OUI 2.X or higher (Install converts the inventory to XML) you have never run Rapid Clone (Rapid Clone converts the inventory to XML) If the following file exists, the oraInventory is NOT binary: /ContentsXML/inventory.xml What is a XML oraInventory? Is my Inventory XML? Starting with OUI 2.X and 11.5.8, the information in the inventory is stored in Extensible Markup Language (XML) format. The XML format allows for easier diagnosis of problems and faster loading of data Rapid Clone requires the inventory to be in XML format in order to clone it, and will take care of performing the binary to XML convertion if necessary. Unlike the binary oraInventory, The XML inventory is divided into 2 distinct components: The Global inventory (or Central inventory) The Local inventory (or Home inventory) More information about these components is available under other questions in this FAQ The inventory is XML if the following file exists:

$ORACLE_HOME/inventory/ContentXML/comps.xml What is the Global (or Central) Inventory? The Global Inventory is the part of the XML inventory that contains the high level list of all oracle products installed on a machine. There should therefore be only one per machine. Its location is defined by the content of oraInst.loc. The Global Inventory records the physical location of Oracle products installed on the machine, such as ORACLE_HOMES (RDBMS and IAS) or JRE. It does not have any information about the detail of patches applied to each ORACLE_HOMEs. The Global Inventory gets updated every time you install or de-install an ORACLE_HOME on the machine, be it through OUI Installer, Rapid Install, or Rapid Clone. Note: If you need to delete an ORACLE_HOME, you should always do it through the OUI de-installer in order to keep the Global Inventory synchronized. What is the Local (or Home) Inventory? There is one Local Inventory per ORACLE_HOME. It is physically located inside the ORACLE_HOME at $ORACLE_HOME/inventory and contains the detail of the patch level for that ORACLE_HOME. The Local Inventory gets updated whenever a patch is applied to the ORACLE_HOME, using OUI. How does Rapid Clone deal with the oraInventory? Rapid Clone requires OUI 2.2 to be installed in the ORACLE_HOME as a prerequisite and will performs all the actions necessary to clone the inventory: Converts the Global inventory to xml format when it was binary on either the source system or the target system Registers the cloned ORACLE_HOME in the target system Global Inventory Updates the Local Inventory of the target ORACLE_HOME to reflect the new machine, paths, users, etc. Why don't I need to manually copy the oraInventory when cloning? The local inventory is automatically copied from the source system to the target system as part of copying the ORACLE_HOME itself. The Global Inventory is machine specifc and therefore should not be copied. If you are cloning from one machine to a different machine, Rapid Clone will simply register the target ORACLE_HOME in the target machine Global Inventory (This

action will automatically create the Global Inventory if it did not exist on that machine). What does OUISetup.pl do? OUISetup.pl is shipped with the OUI patch, listed as a prerequisit to Rapid Clone (see Metalink Node 230672.1). It should be run as part of the OUI patch installation and will perform the following tasks: Register the OUI program in the Global Inventory Register the JRE in the Global Inventory Ensure that the ORACLE_HOME in which the patch is install is properly registered in the Global Inventory. In doing so, it will attempt to automatically fix Inventory corruptions that are known to cause problem whilie cloning, such as - Home indexes out of sync between the Global and Local Inventory - Duplicate Home Names entries - Duplicate Home Path entries You have just had to restore from backup and do not have any control files. How would you go about bringing up this database? I would create a text based backup control file, stipulating where on disk all the data files where and then issue the recover command with the using backup control file clause Compare and contrast TRUNCATE and DELETE for a table. Both the truncate and delete command have the desired outcome of getting rid of all the rows in a table. The difference between the two is that the truncate command is a DDL operation and just moves the high water mark and produces a now rollback. The delete command, on the other hand, is a DML operation, which will produce a rollback and thus take longer to complete. Give the reasoning behind using an index. Faster access to data blocks in a table. A table is classified as a parent table and you want to drop and re-create it. How would you do this without affecting the children tables? Disable the foreign key constraint to the parent, drop the table, re-create the table, enable the foreign key constraint.

Explain the difference between ARCHIVELOG mode and NOARCHIVELOG mode and the benefits and disadvantages to each. ARCHIVELOG mode is a mode that you can put the database in for creating a backup of all transactions that have occurred in the database so that you can recover to any point in time. NOARCHIVELOG mode is basically the absence of ARCHIVELOG mode and has the disadvantage of not being able to recover to any point in time. NOARCHIVELOG mode does have the advantage of not having to write transactions to an archive log and thus increases the performance of the database slightly. What command would you use to create a backup control file? Alter database backup control file to trace. Give the stages of instance startup to a usable state where normal users may access it. STARTUP NOMOUNT - Instance startup. Control File is read here. STARTUP MOUNT - The database is mounted. Datafiles are read for the status and checked with control file. STARTUP OPEN - The database is opened. Normal users can access. Explain an ORA-01555 You get this error when you get a snapshot too old within rollback. It can usually be solved by increasing the undo retention or increasing the size of rollbacks. Explain the difference between $ORACLE_HOME and $ORACLE_BASE. ORACLE_BASE is the root directory for oracle. ORACLE_HOME located beneath ORACLE_BASE is where the oracle products reside. Explain materialized views and how they are used. Materialized views are objects that are reduced sets of information that have been summarized, grouped, or aggregated from base tables. They are typically used in data warehouse or decision support systems. How would you determine what sessions are connected and what resources they are waiting for? Use of V$SESSION and V$SESSION_WAIT Describe what redo logs are.

Redo logs are logical and physical structures that are designed to hold all the changes made to a database and are intended to aid in the recovery of a database. Give two methods you could use to determine what DDL changes have been made. You could use Logminer or Streams What does coalescing a tablespace do? Coalescing is only valid for dictionary-managed tablespaces and de-fragments space by combining neighboring free extents into large single extents. What is the difference between a TEMPORARY tablespace and a PERMANENT tablespace? A temporary tablespace is used for temporary objects such as sort structures while permanent tablespaces are used to store those objects meant to be used as the true objects of the database. Name a tablespace automatically created when you create a database. The SYSTEM tablespace. VHow do you add a data file to a tablespace? ALTER TABLESPACE ADD DATAFILE SIZE How do you resize a data file? ALTER DATABASE DATAFILE RESIZE ; What view would you use to look at the size of a data file? DBA_DATA_FILES What view would you use to determine free space in a tablespace? DBA_FREE_SPACE How can you enable a trace for a session? Use the DBMS_SESSION.SET_SQL_TRACE or Use ALTER SESSION SET SQL_TRACE = TRUE; What is the difference between the SQL*Loader and IMPORT utilities? These two Oracle utilities are used for loading data into the database. The difference is that the import utility relies on the data being produced by another Oracle utility EXPORT while the SQL*Loader utility allows data to be loaded that has

been produced by other utilities from different data sources just so long as it conforms to ASCII formatted or delimited files. Important tables for ADPATCH AD_APPL_TOPS, AD_APPLIED_PATCHES, AD_BUGS, AD_PATCH_DRIVERS, AD_FILE_VERSIONS, AD_FILES, AD_PATCH_DRIVER_LANGS, AD_PATCH_RUN_BUG_ACTIONS, AD_PATCH_RUN_BUGS, AD_PATCH_RUNS, AD_RELEASES,AD_PATCH_COMMON_ACTIONS Patching history of a file - adfhrept.sql The file name is adfhrept.sql and is present under $AD_TOP/patch/115/sql

AutoPatch modes, arguements and options Filed under: Oracle Application R12, Oracle Applications 11i advait @ 6:20 pm Tags: adpatch, adpatch options, patching options Here are the various options for applying the patch in Oracle apps 11i and R12. ADpatch comes with lots of option that can be used, especially when we are applying the patch in production. Modes of ADPATCH If we talk about the mode of applying patch, there are 3 modes 1) Pre-Install Mode Pre-install mode is used to update AD utilities before an upgrade and to apply family consolidated upgrade packs. AutoPatch Pre-AutoInstall mode allows you to apply patches when your installation is missing database information and/or filesystem information that AutoPatch requires to run in normal mode. Examples of when you would run AutoPatch in Pre-AutoInstall mode (and cannot run it in normal mode) include: Prior to installing Oracle Applications for the first time Prior to upgrading Oracle Applications to the latest release. During an upgrade (to apply a bug fix that stopped your upgrade) Applying patch in pre-install mode performs following tasks:

 Version checking File copy actions Relink FND and AD executables Save patch history information to file system AutoPatch in pre-install mode will NOT: Run SQL of EXEC command Generate files Read product driver files Apply maintenance pack To apply patch in pre-install mode, run adpatch preinstall=y 2) Test Mode AutoPatch provides a test mode in which it tells you everything it would have done in applying a patch, but doesnt 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 comands it would have run. Its a good practice to run the patch in test mode and analyze the things before applying the patch in normal mode. 3) Non-Interactive Mode Starting in Release 11.5, you can run AutoPatch non-interactively. Creating a defaults file Before you can run AutoPatch non-interactively, you must first create an AutoPatch defaults file for your current environment. Here is a simple way to create an AutoPatch defaults file for your current environment: 1. Specify defaultsfile= on the AutoPatch command line. The defaults file must be located under $APPL_TOP/admin/. For example: adpatch defaultsfile=$APPL_TOP/admin/testdb1/my_def.txt 2. Run AutoPatch up to the point where it asks you for the directory where your Oracle Applications patch has been unloaded. Then type abort at this prompt. 3. Verify that your defaults file exists. Once you have an AutoPatch defaults file for your current environment, you can run AutoPatch non-interactively. Applying a single patch driver file non-interactively

Before applying any Oracle Applications patch, either interactively or noninteractively, you should read the README file (usually called readme.txt) supplied with the patch. You should also read the documentation supplied with the patch (if any). It is possible to apply just a single patch driver file non-interactively using AutoPatch. Here is an example: Assume the following: defaults file is $APPL_TOP/admin/testdb1/def.txt Applying copy driver for patch 123456, which is located in directory $APPL_TOP/patch/123456. Using three parallel workers AutoPatch log file name is cpy123456.log The AutoPatch command line would be: adpatch defaultsfile=$APPL_TOP/admin/testdb1/def.txt \ logfile=cpy123456.log \ patchtop=$APPL_TOP/patch/123456 \ driver=c123456.drv \ workers=3 \ interactive=no If we dont give any of the mode as mentioned above and apply the patch simply using adpatch command then its a normal mode of patch application. Having seen the modes of patch application, now we will see various arguements for applying patch. 1) defaultsfile Purpose: This option is used when we are running the patch in non interactive mode. In that case we create defaults file and provide that file as an option for running patch in non-interactive mode. Default: none. No default file read or written. 2) logfile

Purpose: This is the name of adpatch log file which it will write during patch application. Default: none. Adpatch prompts for this value. 3) workers Purpose: Specifies the number of workers to run. This value depends on number of CPU and other factors. Default: none. Adpatch prompts for this value. 4) patchtop Purpose: Top-level directory for the current patch. This is the directory after unzipping the patch. This directory will a patch number. Default: none. Adpatch prompts for this value. 5) driver Purpose: Name of the patch driver file. This comes with the patch and is present in patch directory. Default - none. Adpatch prompts for this value. 6) restart Purpose: To restart an existing session. Only valid when interactive=no is also specified Default: No 7) localworkers Purpose: Used in Distributed AD to specify the number of workers to be run on the current machine. If you have multi node instance (example RAC and shared APPL_TOP), then you can utilize this paramter to run the patch parallely in multiple nodes. You can start few workers on node 1, few on node 2 and so on. The way this can be done is that, you can start adpatch on one node with localworker=. Then run adctrl on other node in distributed mode and start some mode workers. This will speed up the process and utilized the resources effectively. Default: Value specified for workers. printdebug Purpose: To display extra debugging information. Default: No.

Now lets consider some common options that can be used with adpatch options= 1) checkfile Purpose: To skip running exec, SQL, and exectier commands if they are recorded as already run. Indicates that Autopatch should run the command *only* if a certain file is newer than the version of it that was last run. The idea behind it is to reduce the duration of an Autopatch session by skipping actions that dont really need to be performed. When used in the right manner, it can dramatically improve Autopatch performance, especially for big patches and/or long running actions. Default: checkfile (use nocheckfile to skip) 2) compiledb Purpose: To compile invalid objects in the database after running actions in the database driver. Default: compiledb (use nocompiledb to skip) 3) compilejsp Purpose: To compile out-of-date JSP files, if the patch has copy actions for at least one JSP file. Default: compilejsp (usenocompilejsp to skip) 4) copyportion Purpose: To run commands found in a copy driver. This will copy the higher version files from patch to product top. Default: copyportion (Use nocopyportion to skip. Use it only when mentioned in readme of patch) 5) databaseportion Purpose: To run commands found in a database driver. This portion includes applying the files (like sql, pls etc) to database. Default: databaseportion (use nodatabaseportion to skip. Use it only when mentioned in readme of patch) 6) generateportion Purpose: To run commands found in a generate driver. This portion will generate new executable files from the copied code of patch. For example if will generate new forms files (fmx) from new .fmb files.

Default: generateportion (use nogenerateporation to skip) 7) integrity Purpose: To perform patch integrity checking. Tells adpatch 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. Default: nointegrity (By default the integrity is not checked) maintainmrc Purpose: To maintain the MRC schema after running actions found in the database driver. Default: maintainmrc (use nomaintainmrc to skip) 9) autoconfig Purpose: Tells adpatch to run Autoconfig after patch installation. Default: autoconfig (use noautoconfig to skip) 10) parallel Purpose: To run actions that update the database or actions (like SQL) that generate files in parallel (like genform). Default: parallel (use noparallel to skip) 11) prereq Purpose: Tells adpatch whether to perform prerequisite patch checking prior to running patch driver files that contain actions normally found in the copy driver. Default: prereq (use noprereq to skip) 12) validate Purpose: To connect to all registered Oracle Applications schemas at the start of the patch. Adpatch validates the passwords for each schema. Default: novalidate (use validate to validate schema passwords) Following flags can be passed to adpatch 1) hidepw Purpose: This argument is used to hide the passwords in log files Default: nohidepw

2) trace Purpose: Tells the adpatch utility whether to log all database operations to a trace file Default: notrace 3) logging Purpose: Tells the adpatch utility whether to create indexes using the logging or nologging mode. Default: logging There is a good utility for checking all the techstack components and there versions present in e-business application. This is applicable to both 11i and R12 environments. There is a script $FND_TOP/patch/115/bin/txkInventory.pl on apps side which is going to fetch the versions of all components on apps side. This script can be run by giving input to $FND_TOP/patch/115/bin/TXKScript.pl script. TXKScript.pl script takes 2 mandatory arguments, one is the script to run and another is the directory for storing log file and out file. Other then these arguments you must give context file name and location and apps password as well. Also you need to give outfile where it will create report of techstack components. Login to apps side of your application and source the environment. Run the below command (appmgr06) appmgr - -bash $ perl $FND_TOP/patch/115/bin/TXKScript.pl -script=$FND_TOP/patch/115/bin/txkInventory.pl -txktop=$APPLTMP -contextfile=$CONTEXT_FILE -appspass=apps -outfile=$OA_HTML/techstack_info.html *** ALL THE FOLLOWING FILES ARE REQUIRED FOR RESOLVING RUNTIME ERRORS *** STDOUT = /slot06/appmgr/scmc2mq0comn/rgf/scmc2mq0/TXK/txkInventory_Fri_May_16_04_01 _03_2008_stdout.log Reportfile /slot06/appmgr/scmc2mq0comn/html/techstack_info.html generated successfully. You can access the above report file using http://(hostname.domain): (port)/OA_HTML/techstack_info.html

Many times we faces an issue which needs JSPs to be compiled, specially in case of development. Also for example, if some of the class files are missing then, in that case we can compile the JSPs and get the required class files. In Oracle Applications (11i as well as R12), we have a utility called ojspCompile.pl. This script carries out compilation of JSPs. Below is some information regarding this script. Oracle Apps 11i In 11i version, this script is present in JTF_TOP/admin/scripts ================================================== ========= (appmgr01) scripts - -bash $ ./ojspCompile.pl syntax: ./ojspCompile.pl COMMAND {ARGS} Oracle E-Business Suite R12 In case of Oracle E-Business suite R12, same ojspCompile.pl script is present for compiling JSPs, but this script is present under FND_TOP/patch/115/bin directory.Also, you cannot delete _pages directory under COMMON_TOP. Deleting this will make your application non-workable.The reason for the same being that, in case of R12, JSPs are not compiled as and when you access them. So dynamic compilation of JSPs are not present. This is basically done to improve the performance of application system. But in case _pages directory has been deleted, then you can recreate the same by running ojspCompile.pl compile flush command. Also some times, its required to have dynamic compilation of JSPs, specially in case of development environment, so that oacore will pick the latest changes. This setting can be done using a parameter in CONTEXT_FILE. The paramter name is s_jsp_main_mode. This parameter is by default having a value of justrun, this can be changed to recompile. Once changed, you can run autoconfig and Verify that the $INST_TOP/ora/10.1.3/j2ee/oacore/application-deployments/oacore/html/orionweb.xml has

main_mode recompile

Doing this will make new JSP to get compiled before it is shown on browser. References: Metalink Note ID 458338.1 Generating Event level Traces in Oracle Applications Filed under: Oracle Application R12 advait @ 7:39 am We have seen how the event traces can be generated for a database user session using Oracle Trace Utility. Now what if we need to generate the trace for some application user (either Apps 11i or E-business suite R12). In this case when a user connects to an application its very difficult to track the session. For this reason we have a profile option, which can be set to generate trace file for any event we want within the application. Follow the below steps for enabling the event level tracing within an application. 1) Login to application and go to System Administrator responsibility. 2) Navigate to Profile -> System 3) In the user field, enter the name of user you want to enable tracing for. This will be your application user. 4) On the profile search screen search for Initialization SQL Statement - Custom profile. 5) When the profile is shown you can set the value as begin fnd_ctl.fnd_sess_ctl(,,TRUE,'TRUE,'LOG,'ALTER SESSION SET EVENTS=10046 TRACE NAME CONTEXT FOREVER, LEVEL 12 tracefile_identifier=AppsTrace_10046); end; All the quotes are single quote here. You can just copy and paste the profile value. 6) DO NOT SAVE THE PROFILE 7) In another browser window, login as the user you are going to trace and prepare to reproduce the problem 8 ) Once you are ready to reproduce the problem, go back to the Applications Forms and Save the profile change 9) Reproduce the problem 10) Back in the Applications form, set profile to null so it does not trace anymore and Save the change

11) The trace will be located in the user_dump_dest. The trace can be identified using the trace identifier we have set - AppsTrace_10046. If you have set some different identifier, then you can search using that key word. Hope this helps !! Comments (2) February 4, 2008 Upgrading Jinitiator for Oracle Applications 11i Filed under: Oracle Application R12 advait @ 2:18 pm Oracle JInitiator is basically available on two streams of JDK for Oracle Applications 11i customers. One stream is based on Jinitiator version 1.1.8.X version and another stream is based on 1.3.1.X version. As JDK 1.1.8 has long been de-supported by Sun, Oracle will continue to provide critical updates to Jinitiator 1.1.8 through the de-support date for Release 11.0; Oracle strongly recommends that Oracle Applications 11i customers move to the latest certified version of JInitiator 1.3.1.x. In some cases, migration to JInitiator 1.3.1.x requires additional technology upgrades. Many a times you might face a situation where you need to upgrade your Jinitiator version to the latest version available. Also some times users are unable to open the forms. When they click on forms, system constantly ask for jinitiator upgrade, and even after upgrading the Jinititator system keeps on asking to install the same version again and again. This happens because of fundamental reason Your client system is not having correct version of Jinitiator then your application is at currently. Example the situation might be that your client PC is having a Jinitiator version of 1.3.1.18 where as your application expects a Jinitiator version of 1.3.1.25. In that case when you click on the forms window it will automatically ask you for installation of required Jinitiator version. But note that installation of required Jinitiator version is only one time job. Next time click on forms should open the forms window correctly. Reason for asking to install Jinitiator repeatedly is that if your application system is not having a correct version of Jinitiator then it will prompt to install the highest available version with it. If this version happens to be lower version then the required then it will repeatedly as you to install the same Jinitiator version again and again. This problem has two solutions. First solution is to download the correct version of Jinitiator manually and install in your client PC.

Another solution is to upgrade your Jinitiator version in application system. This will put the correct Jinit exe in your application which will be downloaded and installed first time when you click on forms. With proceeding clicks it will open up the forms correctly. This post explains about upgrading Jinitiator version of your application system. For more details, please refer to metalink note ID 124606.1. Upgrading JInitiator for application system For upgrading JInitiator version of your application, you need to apply 2 patches as given below depending on your Jinitiator current version. JInitiator Version JInitiator Patch Interop Patch 1.3.1.29 6350285 6169479

1.1.8.27 6612584 6615232

In the JInitiator patch (6350285 or 6612584) , there will be jinit*.exe. You can extract this exe file by unzipping the patch. Once the exe file is extracted, place the exe file at $COMMON_TOP/util/jinitiator/ directory. This is the place from where the jinitiator will be downloaded in your local client PC. After placing the exe, apply the interop patch for the respective version using the following steps. 1) Apply the patch driver in the interop patch using AutoPatch. 2) Run the jinit.sh script from the //fnd/patch/115/bin/ directory, against the web node of your middle tie. The usage of the script is jinit.sh Example: jinit.sh 13129 (If you are upgrading to 1.3.1.29 version).

The script will return the appropriate file, or prompt you for the following values: - Location of APPSORA.env file (This is located in APPL_TOP) - Location of Context File (echo $CONTEXT_FILE will give the location of context file) - Password for the APPS User in the database This will make the necessary changes to the application system and JInitiator version is now upgraded. You can bounce the services now and access the application. This will download the correct latest JInitiator version that you have upgraded to your local PC and it will install. You will be able to access the forms as well correctly. You can verify the JInitiator version that you have upgraded by enabling the Jinitiators console as per the steps given in metalink note ID 124606.1. Hope this helps !! References: Metalink note ID 124606.1