Oracle s Cloning Methods

---

Oracle's Cloning Methods

Oracle has seen iterations of what it supports from a cloning perspective, from nothing being supported to the current two ways depending on where you are version-wise. It has come a long way and it has vastly improved even within the last year. Here are the two current methods that Oracle directly supports for cloning.

Cloning with ADCLONE

For all systems up to Version 11.5.5, this is the basic method of cloning one environment and its data to another. It is fairly straightforward and has minimal problems that will rear their ugly heads. The basic process is outlined in this chapter.

Run Rapid Install

Rapid Install needs to be run once for every environment in your enterprise. Production (or whatever environment you are cloning from) needs to be at whatever level you choose to clone from.

You do not need to run Rapid Install once for every clone. Not only would this be wasted time and effort, it would likely introduce far more errors into the equation than the clone and subsequent testing would ever hope to eliminate. This installation is exactly the way any installation gets done, with the complete set of ports and servers identified at installation time. Without these unique settings, the system will perform incorrectly and will likely either access the wrong database (introducing data corruption and inconsistencies) or will not work at all. The newly installed (target) environment does not have to be patched (other than the patch necessary for cloning) and only has to be minimally functional before the clone. All of the Oracle E-Business Suite products and functionality will come from the cloned from (source) system.

This setup needs to at least have a cursory test run to make sure that the PHP loads and that you can shutdown and restart the services as they are when the configuration is finished. If you are not confident that you have a basic baseline from which to proceed, if your clone should appear to fail, you will not be able to say that it was working before the clone, and you will not be able to assure the analyst who gets assigned to your iTAR that any error condition is definitely caused by the clone procedure.

Once you have at least a minimally functional environment, you need to stop and get a backup of the middle tier system and the database so you have something to go back to if the clone should fail too badly. Make sure that both backups are successful and that the tapes of those backups can be read.

Once you have a good backup and your system is ready for cloning, you will first need to apply patch number 2115451 in preinstall mode to all middle tier $APPL_TOP directories. This patch contains the ADCLONE utility.

It is highly recommended that you change at least the APPS, APPLSYS, and APPLSYSPUB passwords back to their default values before you start the cloning process (more on changing passwords can be found in Chapter 14).

If your middle tier is on any of the flavors of UNIX or Linux and you are cloning a system that was originally installed with the multi-user option that was available with Release 11.5.1's version of Rapid Install, you will need to change the ownership of the $COMMON_TOP file system from whoever owns it at this point to the applmgr user (whoever is the owner of the rest of the binaries on the system) to conform with the new structure and allow not only ADCLONE to function properly, but the resulting product as well.

To accomplish this change, shut down all services on the target system, change to the $COMMON_TOP file system, and make the ownership change. The process will look something like the following interaction, supposing that your $COMMON_TOP points to a directory called /apps/viscommon:

 $cd/apps/viscommon $chown -R <applmgr username>./util/apache $cd admin/scripts $chown <applmgr username> adaprctl.sh adcmctrl.sh admctrl.sh adfmsctrl.sh adfroctl.sh adrepctrl.sh adalnctrl.sh 

While it would be more expedient in the last step to change all of the ownerships of all of the sh files, it would not be advisable to do so as many have to maintain the ownership that they started with.

Log into the target system (the system that you are cloning to) as the applmgr user on that system and (without sourcing the environment) run the cloning utility to preserve the target system's settings.

Make sure that you have the path to the Perl interpreter in the path of the user logged in (applmgr here) before running the ADCLONE utility. If your target system was installed as a Version 11.5.1 installation, the Perl utility is located under the %COMMON_TOP%/Apache/ perl/bin/perl. For systems whose base installation was later than Release 11.5.1, Perl is located under the $ORACLE_HOME/iAS/Apache/ perl/bin/perl on the middle tier.

On UNIX you would set your path as follows:

 $ PATH=<APACHE directory>/perl/bin:${PATH} $ export PATH 

Double-check to make sure that your environment is looking at the right Perl by issuing the Which command and making sure that it returns the path to this Perl interpreter.

 $ which perl 

On Windows, the command is as follows:

 D:\> set PATH=%PATH%<APACHE directory>/perl/bin C:\> which perl 

Again, make sure the which command returns the correct path to Perl. This works because of MKS Toolkit.

To preserve your environment setting, run the following command at the command prompt using the literal values instead of the environment variables (remember, you have not sourced the environment so you cannot rely on the variables being set correctly):

 perl <ad_top>/bin/adclone.pl -mode=preclone - env_name=<SID> -node_name=<hostname> - config_file=<config file> -ad_top=<ad_top> 

Literally, for a VIS database with VISAPPL/ad/11.5.0 being the AD_TOP, the command would look like this (strung out, no carriage returns or line breaks):

 perl D:\VISAPPL\ad\11.5.0\bin\adclone.pl -mode= preclone -env_name=VIS   -node_name=<your middletier node>  -config_file= D:\VISAPPL\config.txt -ad_top= D:\VISAPPL\ad\11.5.0 

The arguments to the command and their meanings are located in Table 11.1.

Table 11.1: ADCLONE Arguments and Their Meanings

Argument	Meaning
Mode	Preclone when run at the beginning of the clone process. Postclone when run at the end of the clone process.
Env_name	The TWO_TASK value on your system or your SID.
Node_name	Name of your target system's node, without the domain added.
Config_file	This is the path to and name of the config file that is created when Rapid Install runs. Recall that this file is one that you want to keep copies of in as many places as you can.
AD_TOP	The full path to the AD directory in your APPL_TOP. This is where the patch number 2115451 puts ADCLONE.

When ADCLONE runs in preclone mode, it shuts down any running services that may be on your system (as standard practice, you should shut all of these down manually when you are doing any maintenance on the system). It then saves the configurations and port and node specific settings of your APPL_TOP, JAVA_TOP, and your OA_HTML directories and all configuration files from your COMMON_TOP to $COMMON_TOP/admin/clone and removes the APPL_TOP, JAVA_TOP, and OA_HTML directory contents. It is critical that you check to make sure that the to $COMMON_TOP/admin/clone directory exists after adclone finishes preclone mode. If it is not there, your preclone steps were not successful and you should not try to go any further as you will not be able to retrieve the settings (and all of the files that may have contained any of those settings) once the APPL_TOP, JAVA_TOP, and OA_HTML directories have been removed.

The removal step is often unsuccessful. This is sometimes due to a DLL not being released when the services are stopped, sometimes for other reasons. If the $COMMON_TOP/admin/clone directory exists and there are files in it, you can usually safely delete the contents of the directories and continue. However, this might be an advisable place to log a well-timed iTAR.

Shutdown the target database and remove all of the database files that are not part of the binary installation from the target system. This includes all log files, all control files, and all data and index tablespace files.

Copy the Existing Source Database to the Target Database Location

Now it is time to start the actual cloning process.

Before you shut down the source database, create a backup of the control file that you can edit to create the new control on the target system. Find the resulting trace file in the user dump (udump) destination on the source system and copy it to the target system in a common location. I usually put it in the $HOME directory of the applmgr user so it is easily accessible and centrally located.

Alter Database Backup Control File to Trace

Once you have the backup of the control file (which is necessary to point the target database at all of the datafiles that will be copied from the source databases location), shutdown the source database either normal or immediate, and then create a cold backup of the database files. This will ensure that you have a good copy if something should go wrong.

Now log onto the target database server as that environment's applmgr, source the environment for the instance (usually called <SID>.env on UNIX or <SID>.cmd on Windows) and copy the database files from the source database to the target database. The copy command on the OS that you are on will usually work well enough if both the source and target dbf files are accessible from a central location.

 $cp/prodfilesystem/data/*/visfilesystem/data/ D:\ xcopy/s/e/i G:\proddata\data\* D:\visdata\data 

Finally, compare the init.ora parameters on the source system with the init.ora parameters on the target system and make any changes to the target system that are found as differences between the two. While some of the changes may be cosmetic, it is best to keep the settings as much the same as you can when cloning so that the data dictionary does not have any trouble resolving the differences. You can easily do this during the time that the data files are copying; this will likely take several hours due to the sheer volume of data that has to be copied.

Now it is time to get ready to create your new control file. Rename your trace file copied from the source system to something logical with a SQL extension. I usually use something like create_<target sid>_from_<source sid>_<date>.sql; that way I can keep a running set if I choose to monitor what has changed on which system at which date. This is not really a necessity, as you can always find the one you need by looking at the date of the file, but it is handy and self-documenting. In the trace file, remove all comment lines and change the mount points for all files from where the trace file points on the source system to where you have copied them in your target system. Looking at the copy command we used earlier, this would mean changing all references from/prodfilesystem to /visfilesystem. What is more, you will need to make the following changes as well.

Remove the statement:

 STARTUP NOMOUNT 

You do not have to remove this, but if you follow the directions in the Metalink white paper faithfully, it will complain because it will have already started up nomount and it cannot be started again. If you do not remove the line from the tracefile, just log into the database as sysdba (if you have migrated to 9.2, remember internal and svrmgrl are gone) and run your script from there.

Change

 CREATE CONTROLFILE REUSE DATABASE "PROD" NORESETLOGS 

to

 CREATE CONTROLFILE SET DATABASE "VIS" RESETLOGS 

Because the create controlfile script will have been created to recreate the source database's control file, it will be trying to reuse the old control file and will be trying to recreate the database using the same name. This would probably not be a good idea as your front end is looking for a database that is called, in this case, VIS and will not understand a database called PROD in its place and your init file will more than likely cause you troubles. This rename is also why you have to use the resetlogs command both in the create controlfile statement and in the open database statement.

 ALTER TABLESPACE TEMP ADD TEMPFILE '/visfilesystem/data/temp2.dbf'       SIZE 1048576000   REUSE AUTOEXTEND OFF; 

Whenever I try to recreate a control file in this manner, I have never been able to get this command to complete successfully. It errors every time I run the trace file script. I will have a Temporary Tablespace, but I will have 1 of 0 bytes. Running the command to add the datafiles back to the Temporary Tablespace can be run successfully once the database is mounted and open.

Once you have made sure your init files are correct, the trace file has been edited, and the files are done being copied, you can start your new database and create your new control file.

 $sqlplus '/as sysdba' SQL> startup nomount SQL> @<your create script>.sql SQL> alter database open resetlogs; 

If you are using Recovery Manager (RMAN) (as a free tool that continues to become more stable and easier to use, you probably should consider it), you will have to reset the Database Identifier (DBID) with a unique ID. Since your source system's files have not been changed in any way by being migrated (other than to have the logs reset), they retain the DBID of the source system in the header portion of the datafiles, temp and log files, and in the new control file regardless of the name of the database. To reset the DBID you will need to perform the following steps:

Shut down the database cleanly, either as normal or as immediate.

 $ sqlplus '/as sysdba' SQL> shutdown immediate 

Startup mount the instance, but do not open it.

 SQL> startup mount 

Create the new DBID in the file headers.

 SQL> exec sys.dbms_backup_restore.zerodbid(fno => 0); 

Since you changed the name of the database when you created the new control file, you can recreate the global name as well. Since this example is cloning to the VIS database, we will rename it to VIS, but replace this with whatever you are cloning to:

 SQL> alter database rename global_name to VIS 

Now you should open the database, start up the listener, and make sure that you can connect to the database both from the OS command line and from a remote SQL*Plus session. I usually try to connect to the database from a SQL*Plus session on the server where your middle tier applications are. You will not have removed either the TNSNAMES file or the SQL*Plus capabilities in the cloning process, so you should be able to talk to the database from this server at this point in this way.

Copy the Existing File System (APPL_TOP, JAVA_TOP, and OA_HTML)

Note 

This can be done while the database files are copying to save time. It is not necessary to wait for the database to be up and functional before you start copying these files. Running the copy jobs in parallel will cut your overall time by at least a third.

Oracle suggests that you make sure that all users are off of the source system and that all services are shutdown before starting this process. If your database is shut down for the copy of the database files from one instance to the other, there is a good chance that all of your users are off of the system. Do make sure that your services are all down before starting the copy job though. Some of the files find it difficult to copy if there is something actively writing to them.

Log on to the target middle tier server as the applmgr user and copy the APPL_TOP, JAVA_TOP, and OA_HTML directories and their contents from the source to the target. If you are on Windows, this will be easier if you map a drive to the location of the files; if you are on UNIX and the files are on two physical servers, NFS mounting the file system will make this easier. The copy command can be used in these cases and FTP (file transfer protocol) does not have to be used. Logging on as applmgr user on the target system allows you to get all of the file permissions correct when the files get to their destinations and limits what you have to do later.

If your system is multi-node, make sure that the appropriate directories get to the correct nodes.

UNIX:

 $ cp -r/PROD_APPS/PRODAPPL/VIS_APPS/VISAPPL 

Windows:

 C:\> xcopy/s/e/i g:\prodappl d:\visappl 

Update the Configuration Information

Before you can finish the ADCLONE steps, you have to make sure that not only is the database started, but also that you can connect to it from the middle tier server and that the listener is running. Connect via SQL*Plus to the database as any users (e.g., system, apps, a development user).

 select sysdate from dual 

If you can connect, it should be safe to finish the ADCLONE steps.

You can now safely run ADCLONE in postclone mode to maintain the target settings. Make sure that you are logged on to the target system as the applmgr user. Again, although it may not even be possible at this point, if it is possible, do not source the environment file. Just go to a command prompt at the OS level and run ADCLONE in postclone mode to configure the target system from the source system's files. Running ADCLONE this time helps to configure the database profile option values, replaces the configuration files in the APPL_TOP and in the COMMON_TOP (it actually does not remove the old configuration files if they are not named the same thing, it just puts a version of those files that are configured for the source system into the file system), generates the database connectivity file (DBC), and updates the Intermedia libraries for the target system. The format of ADCLONE in postclone mode is as follows:

 perl adclone.pl -mode=postclone -env_name=<SID> - node_name=<hostname> -config_file=<config file> - ad_top=<ad_top> 

Example of a working command:

 perl D:\VISAPPL\ad\11.5.0\bin\adclone.pl - mode=postclone -env_name=VIS -node_name=<your middletier node>   -config_file= D:\VISAPPL\config.txt -ad_top= D:\VISAPPL\ad\11.5.0 

If you are cloning in a multi-node configuration, repeat all steps on all nodes.

Finishing Up

Now we come to the optional steps. At this point, you can safely bring up your source system and allow users to start accessing it again.

If you applied any patches that were not captured in the clone process, this is where you would apply them to the target system. These patches would include anything patched in Apache, any of the Developer Suites of products, Discoverer before Version 11.5.7, or JInitiator. If you have made any tuning configuration changes or any changes to take advantage of any of the iAS security settings from the configuration files you would make these similar changes to the files in the target system as well. There are also configurations that you can make to the appsweb.cfg file that is located in both the FND_TOP/resource directory and in the OA_HTML/bin directory. Make sure that you make the same changes to both of these files, but first make backup copies of the originals. That way if you find something messed up later, you can copy the backups over the ones that you edited. Make special note of the Environment Specific Parameters section of the appsweb.cfg file and make sure that the parameters reflect the values that should be pointing to the target system (VIS in this case).

If your primary browser is Internet Explorer, you need to alter the default Session_cookie_domain from null or from whatever value it is in the system at this point to whatever the domain is for this instance.

 sqlplus apps/apps SQL> update ICX_PARAMETERS 2> set SESSION_COOKIE_DOMAIN = '<MyDomainName>'; 

You already created an Identirydb.obj file on the target system. If you have not, you will need to run adjava to create the obj file.

 adjkey -initialize 

Whether or not you recreate the digital signature, it is usually a good idea to recreate the jar files via ADADMIN on the target system. Strictly speaking, it may not be necessary to do this, but it is always better (especially in the case of a clone) to err on the side of caution. In the case of a clone (where it is not usually the case in a patch situation) you want to force regeneration of all jar files when prompted by the utility.

Further, it is suggested that it would be a good idea to relink the AD executables on each node of the target system on which those utilities may exist (typically not on the database node).

 Adrelink force=y 'ad all' 

Test the Target System

Now comes the moment of truth. Testing the target system is an important part of any clone. You can run preliminary tests on the system. Try logging in as a user with sysadmin privileges. Remember you are using any login that would have carried over from the source system including user IDs and passwords.

Navigate to the screen from which you submit concurrent requests and run something nonintrusive like Active Responsibilities. This will prove that the Concurrent Managers are functional, but will not in any way impact the data.

 http://<apache host>:<apache port>/pls/VIS/FND_WEB.PING http://<apache host>:<apache port>/servlets/ IsItWorking http://myapacheserver .mydomain.com:7777/pls/vis/fnd_web.ping http://myapacheserver.mydomain.com:7777/ servlets/IsItWorking 

Find and Mitigate Settings That the Clone Did Not Take Care Of

I have yet to perform a clone in this manner where all of the profile option values were correctly updated by the postclone script. Likely places to start looking are in the Table.Columns in Table 11.2. To be on the safe side, create a backup table of all of the tables that you manually alter.

Columns to Investigate

 WF_NOTIFICATION_ATTRIBUTES.TEXT_VALUE WF_ITEM_ATTRIBUTE_VALUES.TEXT_VALUE FND_FORM_FUNCTIONS.WEB_HOST_NAME FND_FORM_FUNCTIONS.WEB_AGENT_NAME FND_FORM_FUNCTIONS.WEB_HTML_CALL FND_PROFILE_OPTION_VALUES.PROFILE_OPTION_VALUE FND_PRODUCT_GROUPS.APPLICATIONS_SYSTEM_NAME FND_CONCURRENT_REQUESTS.LOGFILE_NAME FND_CONCURRENT_REQUESTS.OUTFILE_NAME 

 Profile_options (locate these through the Profiles screen if necessary) 

 ICX: Report Link       ICX: Report Launcher ICX: Report Images     ICX: Forms Launcher Help System Base URL   Apps Servlet Agent Applications Help Web  Applications Web Agent Agent POR_SSP_HOME           POR_SSP_ECMANAGER POR_UPDATE_REQ         ICX_AP_WEB_OPEN_EXP ICX:Report Cache       POR_RESUBMIT_URL FND_FORM_FUNCTIONS     WF_NOTIFICATION_ATTRIBUTES TCF:HOST               JTF_BIS_OA_ HTML                   _WF_WEB_AGENT 

 Create table wf_notification_attributes_<your initials> as select * from wf_notification_attributes 

While these are most of the common places where postclone falls down on the job, they are not the only ones that you may have to change. I usually run a query against the fnd_profile_option_values table to determine if anything is pointing at the source environment.

 Select profile_option_value from fnd_profile_option_values where profile_option_value like '%MYSERVER%'; 

Run queries on as many different configurations or portions of the port number, the middle tier server name, the database SID value, and any other pieces of these that you can think of. It may seem like an exercise in futility, but after a clone or two you will learn which values your particular clone setup misses routinely.

Cloning with Rapid Clone

The newer and less prone to error manner of cloning includes using AutoConfig and a new utility, Rapid Clone, to facilitate the cloning procedure. While the required list of software for running a clone using the old method was minimal, the new cloning method requires a more extensive listing of software to be present on the system. Table 11.3 provides the software requirements, required versions, node on which it has to be present, and additional notes.

Table 11.3: Software Necessary to Support Rapid Clone

Software	Version	Node	Notes
Oracle Universal Installer	2.1.0.17	All nodes as all are potential source nodes	This version of Universal Installer was included with all 11.5.7 environments that used Rapid Install. If you have a system that was installed at an earlier release level and migrated to 11.5.7 or higher or if you are still at an earlier release, you will need to install patch number 2949808 to bring the correct version of the Universal Installer into your environment.
Perl	5.005	All nodes	The Perl shipped with iAS Version 1022 or with the RDBMS 9i is sufficient. Alternatively, it can be downloaded from perl.com. NOTE: Perl must not only be loaded into the system, it must be included in the path of the user running the clone before cloning.
JRE	1.1.8	All database nodes	This is only necessary if the RDBMS binaries in the ORACLE_HOME were not installed using Rapid Install. If this was not the manner used to install the binaries, it is necessary to install JRE 1.1.8 into the %ORACLE_HOME%/jre/1.1.8 directory.
JRE	1.3.1	All Windows-based database nodes	Windows users only: it is necessary to install JRE 1.3.1 into the %ORACLE_HOME%/jre/1.3.1 directory.
JDK	1.3.1	All middle tier nodes
Zip	2.3	All nodes	Download from infozip.com. Not only must it be available on the system, zip must also be in the path of the user running the clone before cloning.

If you are running on a Windows platform and have not already done so, apply patch number 2237858 to enable support on your system of long filenames. If you have applied patches to your system up to this point, you likely already have this patch applied or many other patches would have encountered difficulty. Double-check to make sure.

Apply the Rapid Clone patch. See, even in cloning, there are patches to apply. Patching is simply going to become second nature to you. To enable your Applications file system to be cloned using Rapid Clone, you will need to apply Rapid Clone patch number 2926786 to all middle tier nodes and the AutoConfig patch number 2942559 to all middle tier nodes.

One of the primary requirements for being able to run Rapid Clone is for all sources and targets to be AutoConfig enabled. If your system was created as an 11.5.5 system or earlier and you have not yet migrated to AutoConfig, being able to clone in this manner is a good reason to do so now. Note number 165195.1 can help you in migrating and maintaining your system with AutoConfig.

For Rapid Clone to work correctly, you will have to update your ORACLE_HOME file system. On the Application Tier log into the APPL_TOP environment as the owner of the application on the middle tier and source the environment file. Once logged in, update your middle tier file system with the adchkcfg utility by applying another patch, patch number 2952369, and create appsutil.zip file by issuing the following command:

 Perl%AD_TOP%\bin\admkappsutil.pl 

On the database tier, as the owner of the RDBMS binaries, copy or FTP the appsutil.zip file created in the previous step to your %ORACLE_HOME% and unzip the file once it has been copied.

 cd%ORACLE_HOME% unzip -o appsutil.zip 

If you have not yet migrated your database tier to AutoConfig, this is the place to make this migration. To create the context file on the database tier, run the following command:

UNIX

 $cd $ORACLE_HOME/appsutil/bin $adbldxml.sh tier=database appsuser=apps appspasswd=apps 

Windows

 D:\ cd/d%ORACLE_HOME%\apps\bin D:\<%ORACLE_HOME% adbldxml.cmd tier=databae appsuser=apps appspasswd=apps 

You are now ready to run your clone. The first step is to create a set of template files on the source system. Rapid Clone takes these templates and updates them once they get to the target system with the target configuration. Rapid Clone will not make any changes to the source system.

To prepare the database for the clone, log on to the source database tier as the applmgr user and run the following commands:

 $ cd $ORACLE_HOME/appsutil/scripts/PROD $ perl adpreclone.pl dbTier 

On the source middle tier, log on (again as the applmgr user) and run the following command:

 D:\ cd%COMMON_TOP%\admin\scripts\PROD D:\PRODCOMMIN\admin\scirpts\PROD perl adpreclone.pl appsTier 

Now copy the middle tier file systems from the source to the target system by running the following commands in exactly the order provided.

Shut Down the Server Processes

Copy all of the following directories:

 $APPL_TOP $OA_HTML $OA_JAVA $COMMON_TOP/util $COMMON_TOP/clone $806_ORACLE_HOME $iAS_ORACLE_HOME 

Make sure that the copied file systems are owned by the target's applmgr on all tiers and nodes.

Log on to the database tier as the applmgr user that owns the database. Shut down the database either normal or immediate and, once the system has shut down successfully, copy the database files from the source system to the target system. When the database files are finished, copy the $ORACLE_HOME from the source system to the target system and start up the source system on all tiers and nodes.

To configure the database, log into the server as the applmgr user of that server and run the following commands:

 $ cd $ORACLE_HOME/appsutil/clone/bin $ perl adcfgclone.pl dbTier 

Now, to configure the middle tier nodes, log on to each node as the applmgr user and run the following commands:

 D:\ cd%COMMON_TOP%\clone\bin D:\VISCOMMON\clone\bin perl adcfgclone.pl appsTier 

If you are running any of the middle tier nodes on Windows servers, add the 806 Oracle Home to the path prior to running this script.

Now we complete the finishing steps.

Rapid Clone does not update any profile option values lower than site level. If there were any instance-specific values set on your source or your preclone target, you will have to manually reset these. If different printers are being called from the target system than from the source system, you will need to manually update these as well as the workflow configuration settings in Table 11.4.

Table 11.4: Rapid Clone Tables to Check for Incorrect Values

Table Name	Column Name
WF_NOTIFICATION_ATTRIBUTES	TEXT_VALUE
WF_ITEM_ATTRIBUTE_VALUES	TEXT_VALUE
WF_SYSTEMS	GUID
WF_SYSTEMS	NAME
WF_AGENTS	ADDRESS
FND_FORM_FUNCTIONS	WEB_HOST_NAME
FND_FORM_FUNCTIONS	WEB_AGENT_NAME
FND_CONCURRENT_REQUESTS	LOGFILE_NAME
FND_CONCURRENT_REQUESTS	OUTFILE_NAME

---