Share the content if you found it is useful (You can share using 300 community websites) click "share" at the end of the post.

You are encouraged to leave a comment.








Showing posts with label Cloning of Oracle Applications. Show all posts
Showing posts with label Cloning of Oracle Applications. Show all posts

Monday, November 08, 2010

ORA-25153: Temporary Tablespace is Empty has been detected

The Following Error was detected while doing Cloning of DB Tier.

The actual Fact was:
The server was heavily loaded, so the control file creation terminated unsuccessfully. So manually created the control file and opened the database.

After this, I began run adconfig.sh

$cd $ORACLE_HOME/appsutil/bin
$ ./adconfig.sh
[oracle@prod bin]$ ./adconfig.sh
Enter the full path to the Context file: /oracle/PROD/db/tech_st/11.1.0/appsutil/UPGRDE_prod.xml
Enter the APPS user password:
The log file for this session is located at: /oracle/PROD/db/tech_st/11.1.0/appsutil/log/UPGRDE_prod/11081336/adconfig.log

AutoConfig is configuring the Database environment...

AutoConfig will consider the custom templates if present.
Using ORACLE_HOME location : /oracle/PROD/db/tech_st/11.1.0
Classpath : :/oracle/PROD/db/tech_st/11.1.0/jdbc/lib/o jdbc5.jar:/oracle/PROD/db/tech_st/11.1.0/appsutil/java/xmlparserv2.jar:/oracle/PROD/db/tech_st/11.1.0/appsutil/java:/oracle/PROD/db/tech_st/11.1.0/jlib/netcfg.jar:/oracle/PROD/db/tech_st/11.1.0/jlib/ldapjclnt11.jar

Using Context file : /oracle/PROD/db/tech_st/11.1.0/appsutil/UPGRDE_prod.xml

Context Value Management will now update the Context file

Updating Context file...COMPLETED

Attempting upload of Context file and templates to database...ERROR: InD bCtxFile.uploadCtx() : Exception : Error executng BEGIN fnd_gsm_util.append_ctx_ fragment(:1,:2,:3); END;: 1; Oracle error -25153: ORA-25153: Temporary Tablespac e is Empty has been detected in FND_GSM_UTIL.APPEND_CTX_FRAGMENT.
oracle.apps.ad.autoconfig.oam.InDbCtxFileException: Error executng BEGIN fnd_gsm _util.append_ctx_fragment(:1,:2,:3); END;: 1; Oracle error -25153: ORA-25153: Temporary Tablespace is Empty has been detected in FND_GSM_UTIL.APPEND_CTX_FRAGMENT.
at oracle.apps.ad.autoconfig.oam.InDbCtxFile.uploadCtx(InDbCtxFile.java: 249)
at oracle.apps.ad.autoconfig.oam.CtxSynchronizer.uploadToDb(CtxSynchroni zer.java:328)
at oracle.apps.ad.tools.configuration.FileSysDBCtxMerge.updateDBCtx(File SysDBCtxMerge.java:678)
at oracle.apps.ad.tools.configuration.FileSysDBCtxMerge.updateDBFiles(Fi leSysDBCtxMerge.java:222)
at oracle.apps.ad.context.CtxValueMgt.processCtxFile(CtxValueMgt.java:16 88)
at oracle.apps.ad.context.CtxValueMgt.main(CtxValueMgt.java:763)
FAILED


So after creating the controlfile, i did not created a tempfile.

So,
sqlplus "/as sysdba"

SQL*Plus: Release 11.1.0.6.0 - Production on Mon Nov 8 13:45:51 2010

Copyright (c) 1982, 2007, Oracle. All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select * from v$tempfile;

no rows selected

SQL> alter tablespace TEMP1 add tempfile '/oracle/PROD/db/apps_st/data/TEMP01.dbf' size 500M autoextend on;

Tablespace altered.

SQL> select * from v$tempfile;

FILE# CREATION_CHANGE# CREATION_TIME TS# RFILE# STATUS
---------- ---------------- ------------------ ---------- ---------- -------
ENABLED BYTES BLOCKS CREATE_BYTES BLOCK_SIZE
---------- ---------- ---------- ------------ ----------
NAME
--------------------------------------------------------------------------------
1 5.9652E+12 08-NOV-10 284 1 ONLINE
READ WRITE 524288000 64000 524288000 8192
/oracle/PROD/db/apps_st/data/TEMP01.dbf


After this, again run adconfig.sh on DB Tier

[oracle@prod bin]$ ./adconfig.sh
Enter the full path to the Context file: /oracle/PROD/db/tech_st/11.1.0/appsutil/UPGRDE_prod.xml
Enter the APPS user password:
The log file for this session is located at: /oracle/PROD/db/tech_st/11.1.0/appsutil/log/UPGRDE_prod/11081348/adconfig.log

AutoConfig is configuring the Database environment...

AutoConfig will consider the custom templates if present.
Using ORACLE_HOME location : /oracle/PROD/db/tech_st/11.1.0
Classpath : :/oracle/PROD/db/tech_st/11.1.0/jdbc/lib/ojdbc5.jar:/oracle/PROD/db/tech_st/11.1.0/appsutil/java/xmlparserv2.jar:/oracle/PROD/db/tech_st/11.1.0/appsutil/java:/oracle/PROD/db/tech_st/11.1.0/jlib/netcfg.jar:/oracle/PROD/db/tech_st/11.1.0/jlib/ldapjclnt11.jar

Using Context file : /oracle/PROD/db/tech_st/11.1.0/appsutil/UPGRDE_prod.xml

Context Value Management will now update the Context file

Updating Context file...COMPLETED

Attempting upload of Context file and templates to database...COMPLETED

Updating rdbms version in Context file to db111
Updating rdbms type in Context file to 32 bits
Configuring templates from ORACLE_HOME ...

AutoConfig completed successfully.
[oracle@prod bin]$


Cheers... Hope this helps...

Sunday, January 18, 2009

Migration - Oracle 11i to Linux Platform

Linux platform migration provides a way to quickly and easily move an existing Oracle Applications middle tier System from any platform to Linux, allowing you to utilize fast, low-cost hardware for your Applications middle tier. The migration utility retains your exact Applications patch level, so that no APPL_TOP/Database synchronization is necessary. It also allows you to retain many customizations.


This Blog applies to the Application Tier Only. The Database Tier is not covered on this Note. Please refer to Document 230627.1 in OracleMetalink for instructions on the Database Migration.

This document describes the process of migrating an Oracle Applications Release 11i System. The most current version of this Note is Document 238276.1 on OracleMetaLink.

For additional information on these migration steps, their expected behavior and troubleshooting procedures, please refer to Document 567703.1 in OracleMetalink.

Attention: Windows NT/2000 users. This document typically uses UNIX syntax when specifying directories; Substitute the appropriate Windows syntax.

Conventions


Convention Meaning

Middle tier The application tier comprising the Admin, Concurrent Processing, Forms and Web servers.

Source System Applications System being migrated.

Target System Applications System being created as a copy of the Source.

APPLMGR User who owns the applications file System (APPL_TOP and middle tier technology stack)

ORACLE User who owns the database file system (RDBMS ORACLE_HOME and database files).

Monospace Text Represents command line text. Type this command exactly as shown.

( ) Text enclosed in angle brackets represents a variable. Substitute a value for the variable text. Do not type the angle brackets.


Section 1: Prerequisites

Prepare the Source System before migrating to a new platform. If the System is installed using multi nodes, the following prerequisite steps must be performed on all nodes.

  1. Verify OS requirements on Target System
    Before migrating to the new platform, ensure the Target System meets all the requirements for Oracle Applications Release 11i stated on the Oracle Applications Release Notes and on the Oracle Applications Update Notes for the Target Platform.

  2. Verify the software versions on the Target System
    In addition to the Oracle Applications OS requirements the following software component versions must exist on the Source and Target nodes.
    Software Minimum Version Details
    Perl 5.005 You can use the Perl shipped with iAS1022 and RDBMS 9i or download it from Perl.com. Perl must be in the PATH.
    JDK 1.3.1
    1.4.2
    The minimum JDK version is 1.3. If migrating to Red Hat Enterprise Linux 3.0 or 4.0 then the minimium JDK version is 1.4. The Source System must be at the correct JDK version before migrating platform. For Oracle Applications 11i JDK upgrade, refer to Upgrading 11i to JDK 1.3 (document 130091.1) or Upgrading 11i to JDK 1.4 (document 246105.1)

  3. Verify the database version
    If your database version is lower than Oracle8i Enterprise Edition Release 8.1.7.4, upgrade it to the latest certified patchset of Oracle8i Release 8.1.7 or any higher certified version.

    Note: If the Database is not on a certified combination with Oracle Applications, you must upgrade the Database to the latest certified version available.

  4. Apply the latest AD Patch
    Apply patch 5161680 (AD.I.5) or higher. Please refer to OracleMetaLink to obtain the latest MiniPack available for AD. The AD patch level can be found in the report generated by the following command:
    sqlplus (AppsUsr)/(AppsPwd) @$AD_TOP/sql/adutconf.sql

  5. Implement AutoConfig on the Application Tier
    If the Source Applications System was created with Rapid Install version 11.5.8 or earlier you must migrate the System to Autoconfig. Follow the instructions on Migrating to AutoConfig on the Application Tier in document 165195.1 in OracleMetaLink.
    This step can be ignored if Autoconfig have already been implemented.

  6. Apply the latest AutoConfig Template patch
    Update the Oracle Applications file system with the latest AutoConfig template files by applying the TXK AutoConfig Template rollup patch to all application tier server nodes. Refer to Document 165195.1 in OracleMetaLink for details of the latest Autoconfig Template rollup patch available. If you already applied the latest patch available, you can skip this step.

  7. Apply the latest Rapid Clone patch
    Update the Oracle Applications file system with the latest Patches required by Rapid Clone. Refer to Document 230672.1 in OracleMetaLink for details of the latest required patches.

  8. Maintain snapshot information
    Run adadmin to maintain snapshot information on all nodes. Refer to the Oracle Applications Maintenance Utilities manual for more details.


Section 2: Migrate Platforms with Oracle Applications 11i

  1. Generate and upload the manifest of customer-specific files
    1. Log in to your Source System primary administration node as the APPLMGR user and source the APPL_TOP environment file. Execute the following command to generate the customer-specific file manifest. This step should take about a minute:
      perl $AD_TOP/bin/adgenpsf.pl

    2. Go to http://updates.oracle.com/PlatformMigration (use your OracleMetaLink username and password) and follow the instructions on the screen to upload the manifest file previously generated:
      $APPL_TOP/admin/$TWO_TASK/out/adgenpsf.txt

  2. Create the Target System APPL_TOP
    Copy the middle tier file system from the Source Applications System to the Target Node by executing the following steps in the order listed. Ensure that the application tier files copied to the Target System are owned by the Target APPLMGR user.

    Note: The Source System can remain up and running until the last step of the migration.

    1. Copy the APPL_TOP file system
      Log on to the Source System application tier node as the APPLMGR user and copy the following application tier directories from the Source System to the Target System
      • (APPL_TOP)
      • (OA_HTML)
      • (OA_JAVA)
      • (COMMON_TOP)/util
      • (COMMON_TOP)/_pages (when that directory exists)

      Attention: Copy only the directories listed, not the full COMMON_TOP.

      Warning: In order to preserve the Concurrent Manager log files and output files you need to consider the configuration of the variables $APPLCSF/$APPLOG and $APPLCSF/APPLOUT.
      If these variables are pointing to locations inside the COMMON_TOP directory structure (i.e. $COMMON_TOP/admin/out/$CONTEXT_NAME and $COMMON_TOP/admin/log/$CONTEXT_NAME you will need to copy these files into similar directory structures on the Target System.

    2. Copy the security file for JInitiator
      • If you wish to preserve the Source System digital signature on the migrated System, copy the identitydb.obj file from the Source System to the Target System. This file is located in the APPLMGR user's home directory on UNIX or the root directory of the %SystemDrive% on Windows.
      • If you want the migrated System to have a new digital signature, remove the following file from the Target System:
        rm (APPL_TOP)/admin/appltop.cer

  3. Clone the AutoConfig XML context file on the Target System
    The Clone Context tool will ask for all the new mount points on the Target migration node. Log on to the Target System as the APPLMGR user and run the following commands:
    • cd (AD_TOP)/bin
    • perl adclonectx.pl migrate java=(JDK HOME) contextfile=(Source System contextfile)
      where:
      (JDK HOME) complete path where the JDK is installed.
      (Source System contextfile) full path to the Source System Applications XML context file located in /admin on the Target System.

    Respond to the prompts. This will create the following Target System context file:
    (APPL_TOP)/admin/(SID)_(hostname).xml

    Note: See document 216664.1 on OracleMetaLink for more information on port pool.

  4. Install the Middle Tier Technology Stack
    Run the Rapid Install Wizard with the -techstack option to install the iAS technology stack. Use the Target System context file created in the previous step.

    cd [Stage11i]/startCD/Disk1/rapidwiz
    ./rapidwiz -techstack

    Follow the instructions in the "Installation Tasks" section of Installing Oracle9i Application Server 1.0.2.2.2 with Oracle Applications 11i" (document 146468.1).

    Note: Use the latest startCD available in OracleMetalink. Refer to the "Current Version of Rapid Install" section in the Oracle Applications Release Notes for details on the latest startCD Patch.
    More details on how to execute rapidwiz can be found on the Oracle Applications 11i Installation Manual.

    Attention: Review the log files (setup_stubs..log) under the iAS ORACLE_HOME to ensure that there are no errors.

  5. Apply the Oracle interoperability patches for Red Hat Enterprise Linux
    If the Application System is 11.5.9 or lower, and on Red Hat Enterprise Linux 3.0 or 4.0, then apply the following Oracle server interopability patches.

    Patches Description
    3830807 Oracle 8.0.6.3 Interop patch
    3170128 Oracle 8.0.6 Interop patch for Discoverer 4i
    3846086 8.1.7.4 Interop patch for iAS ORACLE_HOME

  6. Run AutoConfig setup phase on the Target System
    Execute the INSTE8_SETUP phase of AutoConfig with the new context file. This will create the environment files required for the AutoPatch session:
    • cd (AD_TOP)/bin
    • ./adconfig.sh run=INSTE8_SETUP contextfile=(Target System ctxfile)

      Note: This command does not require the environment to be sourced.

  7. Download and apply the customer-specific update with AutoPatch
    Within 30 minutes from the time you uploaded the manifest file at step 1.b you will receive a notification email saying that your customer specific update patch is ready. Follow the instructions in the email to download it from Oracle MetaLink. The patch should be applied on all Target System application nodes. Source the APPL_TOP environment file and follow the instructions in the README to apply the patch. AutoPatch will automatically relink the executables.


  8. Apply patch 3077161 (only if migrating from Windows):
    Only if you are migrating from Windows, download and apply the Linux patch 3077161 containing the Unix-specific files that don't exist in a Windows APPL_TOP.

  9. Review the technology stack patch level
    Identify any patches previously applied to your Source System technology stack which are not included in the (document 146468.1). Apply these patches to your Target System technology stack.

    Note: For information and instructions on applying the latest Developer 6i patchset, see Note 125767.1

  10. Download and apply the techstack interop patch
    Apply patch 4139957 to the Target Oracle Applications file system.

  11. Regenerate the file system objects
    Source the APPL_TOP environment file and perform the following tasks to regenerate the platform dependent files on the Target System:
    1. If migrating the Forms node, run the following script:
      $AD_TOP/patch/115/bin/adgensgn.sh Apps User/Apps Password
    2. Run adadmin to generate messages, forms, reports, graphics and jar files.

  12. Run AutoConfig to complete the Target System configuration
    $AD_TOP/bin/adconfig.sh contextfile=Target System context file

    Note: The database will be updated to reflect the new Target System profile. Make sure all users are off the system and shut down the Source System application tier server processes. After this step, the Source System middle tier will no longer be available.


Section 3: Finishing Tasks

This section lists tasks that may be necessary depending on your implementation and the intended use of the migrated System.

  1. Update 3rd party extensions
    If your Applications System is implementing any products which use Ilog, Roguewave, or Quantum, you will need to update the Target System with the objects for the 3rd party extensions and relink any dependent products.

    Software Details
    ILOG Apply patch 2837811 and relink dependent executables.
    ROGUEWAVE Apply patch 3006092 and relink dependent executables.
    QUANTUM Follow instructions in document 224273.1 on OracleMetaLink

  2. Review and update your Target System application tier settings and customizations
    1. Recompile any custom code (forms, C) in the Target System APPL_TOP.
    2. If you were using UTF8 charset, Discoverer 4i, SSO or Portal 3i on the Source System, refer to the corresponding documentation to complete the migration:









  3. Update printer settings
    If the newly migrated System needs to utilize different printers, update the Target System with the new printer settings now.

  4. Update Workflow configuration settings
    Migrating an Oracle Applications instance will not update the host and instance specific information used by Oracle Workflow. Review the following tables and columns to verify there is no instance-specific data in the Workflow configuration on the Target System.

    Table Name Column Name Column Value Details
    WF_NOTIFICATION_ATTRIBUTES TEXT_VALUE Value starts with http://old web host : Update to new web host
    WF_ITEM_ATTRIBUTE_VALUES TEXT_VALUE Value starts with "http://old web hos : Update to new web host
    WF_SYSTEMS GUID Create a new System defined as the new global database name using the Workflow Administrator Web Applications responsibility.
    WF_SYSTEMS NAME Value needs to be replaced with the database global name
    WF_AGENTS ADDRESS Update database link with the new database global name.
    FND_FORM_FUNCTIONS WEB_HOST_NAME Update with the new web host name
    FND_FORM_FUNCTIONS WEB_AGENT_NAME Update to point at the new PLSQL listener name
    FND_CONCURRENT_REQUESTS LOGFILE_NAME Update with the correct path to the logfile directory
    FND_CONCURRENT_REQUESTS OUTFILE_NAME Update with the new directory path on the Target System

  5. Review your CLASSPATH setting
    Log in to the Target APPL_TOP environment (source the environment file) and perform the following tasks to consolidate your CLASSPATH:

    1. Verify the AD classpath:
      • Run $ADJVAPRG -version
      • If the result shows a java version of 1.3.1 or higher, use Context Editor to update the variable s_adovar_classpath in the context file: replace appsborg.zip by appsborg2.zip in the classpath string.

    2. Verify the AF classpath:
      • Run $AFJVAPRG -version
      • If the result shows a java version of 1.3.1 or higher, use Context Editor to update the variable s_adovar_afclasspath in the context file: replace appsborg.zip by appsborg2.zip in the classpath string.

    3. Run AutoConfig as described in document 165195.1 on OracleMetalink.

  6. Start all services on the Target System
    Start all services by running the script:
    adstrtal.sh AppsUser/AppsPwd
    located in COMMON_TOP/admin/scripts/ContextName/
Cheers!!!!

Monday, January 05, 2009

Cloning of Oracle Applications (Non Autoconfig Enabled)

This Blog contains details of Cloning of Oracle Applications 11i (11.5.1 to 11.5.5) (non - Autoconfig Enabled) really a tough job ahead!!!. (Step - By - Step Explanation)

CLONING ORACLE APPLICATIONS
Cloning an Oracle Applications Release 11i system involves the following
general steps:
• Run Rapid Install.
• Copy the existing database.
• Copy the existing file system (APPL_TOP, JAVA_TOP, and OA_HTML).
• Update the configuration information.

Install the AD cloning utility on the source system
Download and apply patch # 2115451 in pre-install mode to all APPL_TOPs on the source system. This patch contains the AD cloning utility. It is highly recommend to backup the source system Applications files and database before performing the AD cloning process. We also suggest changing the APPS, APPLSYS and APPLSYSPUB passwords to their default values. The Oracle Applications System Administrator’s Guide contains details on the Oracle Applications schema password change utility (FNDCPASS).

Note: The source system APPL_TOP will be copied to the target system later in the cloning process. This copy of the AD cloning utility will be run at that time.Do not run the AD cloning utility against the source system.

Prepare the target system
Complete the following steps to prepare the target system for cloning.

1. Run Rapid Install to install a new instance
Use the Rapid Install you originally used to create the source system. For instance, if you originally installed 11.5.4 and applied a subsequent maintenance pack (for example, 11.5.5), run the 11.5.4 Rapid Install. Choose the “Install Oracle Applications” option to install all Oracle Applications components.

Identify the name of the target system database and choose to install a “fresh install database”. Create a new configuration file. This file will be used later during the cloning process.

The following options in the target system must match the source system:
• Type of database (that is, if the source system database is a Vision demonstration database, the target system database must be a Vision demonstration database; if the source system database is a fresh install database, the target system database must be a fresh install database.)
• Base language
• Default territory
• APPL_TOP character set
• Server and node configuration (for example, if the source system has two nodes −one node for admin, concurrent processing, and database and the other for forms and web− the target system must be identically configured in two nodes.)
• Platform

The following configuration options for the target system may differ from the source system:
• Port numbers
• Server hostname
• Domain name
• Disk mount points
• Operating system installation account and/or group
• Database name
You may disregard the Product Selection and the Country-specific Functionality screens, as all product and country-specific functionality licensing information are already stored in the database from the source system.If you are cloning a multi-node Oracle Applications system, install the data server node first. Copy the new configuration file to each node in the target system and run Rapid Install on each of the additional nodes by using the “Read configuration from file” option.

When cloning a multi-node system, repeat the remaining steps in this section on each node in your system.

2. Modify user configuration (required for 11.5.1 UNIX users only)
If you are cloning an Applications system originally installed using the Release11.5.1 Rapid Install on UNIX or Linux and the Applications system was installed with the multi-user option, you need to change the COMMON_TOP file system owner from the oracle user to the applmgr user to conform with the new structure.

Shutdown all services owned by the oracle user on the source system and the target system:
$cd /admin/scripts
$adapcctl.sh stop
$adcmctl.sh / stop
$adfmcctl.sh stop
$adfmsctl.sh stop
$adfroctl.sh stop
$adrepctl.sh stop
$adalnctl.sh stop APPS_

Once the services have been shut down, perform the following as the oracle user on both the source system and the target system:
$ cd
$ chown -R ./util/apache
$ cd admin/scripts
$ chown adapcctl.sh adcmctl.sh \
adfmcctl.sh adfmsctl.sh adfroctl.sh adrepctl.sh \
adalnctl.sh
Note: Do not change ownership of all scripts in the directory, as some must remain owned by the oracle user.

3. Install the AD cloning utility on the target system
Download and apply the latest AD cloning patch (2115451) in pre-install mode to all APPL_TOPs on the target system.

4. Preserve Oracle Applications configuration files specific to the target system
To save the target system configuration, log in as the applmgr user on the target system, do not run or execute the Applications environment setup file, and run the AD cloning utility.

Attention: The AD cloning utility is meant to preserve the configuration of the target system and should not be run from the source system.

The AD cloning utility is written in the Perl language. Perl is located in the Apache directory of your Applications system (i.e. …/Apache/perl/bin/perl). For release 11.5.1, Apache is located in the COMMON_TOP directory and for later releases it is located in the iAS ORACLE_HOME. Add the .../perl/bin directory used by Apache to the PATH variable before running the adclone command. Validate this by ensuring the "which" command returns the correct location.

UNIX:
$ PATH=/perl/bin:${PATH}
$ export PATH
$ which perl

Windows:
C:\> set PATH=%PATH%/perl/bin
C:\> which perl

Note: If you updated your system to Apache 1.3.12, verify that the PERL5LIB environment variable is set properly. It should be set to /Apache/perl/lib/5.00503:
/Apache/perl/lib/site_perl/5.005;.

For all users:
Run the AD cloning utility in preclone mode from a temporary directory not located under the APPL_TOP of the target system with the following command:

perl /bin/adclone.pl -mode=preclone -env_name= -node_name= -config_file= -ad_top=

For example:
perl /d02/apps115/TESTappl/ad/11.5.0/bin/adclone.pl -mode=preclone -env_name=TEST -node_name=ap100sun -config_file=/d01/apps115/config.txt ad_top=/d02/apps115/TESTappl/ad/11.5.0

The AD cloning utility in preclone mode:
• Shuts down any running services on the current node
• Saves the configuration files from the APPL_TOP
• Saves the configuration files from the COMMON_TOP
• Removes APPL_TOP, JAVA_TOP, and OA_HTML directory contents

If you are cloning a multi-node Applications system, run the AD cloning utility in preclone mode on each of the additional nodes of the target system.

The configuration files are saved to COMMON_TOP/admin/clone. Do not edit these files during the cloning process.

5. Upgrade the database ORACLE_HOME (conditionally required)
If you upgraded the database ORACLE_HOME of the source system to a different version than the one included with Rapid Install, upgrade the database ORACLE_HOME of the target system. For example, if the source system was installed with Rapid Install version 11.5.3, the original version of the database was ORACLE 8.1.6. Since that time you may have upgraded the database to ORACLE 8.1.7. If so, you need to upgrade the database ORACLE_HOME of the target system to match the database ORACLE_HOME of the source system.

Once the database ORACLE_HOME upgrade is complete, update the DBS_ORA816 parameter of the Rapid Install configuration file with the new ORACLE_HOME path. If the new ORACLE_HOME was installed with the Oracle Universal Installer (OUI), and not Rapid Install, create an ORACLE_HOME/appsutil directory and copy the contents from the old ORACLE_HOME/appsutil directory to the newly created one. Then, update ORACLE_HOME/appsutil/install/adupdlib.sql to reflect the new target system ORACLE_HOME location (for releases before 11.5.3, update adupdprf.sql).

6. Remove the database files from the target system
As you will be using copies of the database files from the source system, the database files created by Rapid Install for the target system can be removed. Use the database server process control script (addbctl.sh) to shutdown the database of the target system.

Delete all of the database files (*.dbf files) from the target system.

7. Copy the source system database
To copy the source system database to the target system, perform the following steps.

a) On the source system database, create a list of datafiles and online redo log files of your source system database by issuing an "alter database backup controlfile to trace" command in the source system database. Examine the resultant trace file located in the user_dump_dest directory.

b) Perform a normal shutdown of the source system database.

c) Perform a cold backup of the source system database.

d) Log on to the target system as the oracle user and set the database environment using the database environment file. The environment file for the database server is located in the database server ORACLE_HOME, and is called .env (UNIX or Linux) or .cmd (Windows).

e) Copy the database files to the target system. Identify the new mount points for the database files and copy the database files from the backup of the source system to the new target system.

f) Verify the target system init.ora parameters. You may have updated the database initialization file in your source system. Verify that the parameter changes are reflected in the init.ora of your target system. Check all parameters, especially the location of your control files and the names of your rollback segments.

g) Create a new control file.
To create new control files:
• Update the trace file from step a) with SID and mount point information pertinent for the target system and use it to create a control file creation script.
• Start up the target system instance, but do not mount or open the database.
• Create a new control file for the database using the control file creation script. Specify the RESETLOGS option if the database SID was renamed. Otherwise, use the NORESETLOGS option.

See the Oracle8i Administrator's Guide for details on creating control files.

h) Open the database.
If RESETLOGS was specified when creating the control file, use ALTER DATABASE OPEN RESETLOGS, else use ALTER DATABASE OPEN.

i) Reset the database identifier (required for Oracle Recovery Manager users)

If you use Oracle Recovery Manager (RMAN) with Oracle Applications, you must reset the database identifier (DBID) with a unique ID. RMAN requires that each database instance have a unique DBID. As the targetsystem database files are copied directly from the source system, they
retain the source system DBID.
The DBID is stored in the generic file header of the control file, datafiles, temp files and online log files. To reset the DBID in all of these locations perform the following steps:

Cleanly shut down the database

Start the instance and mount the database, but leave it closed
Attention: Do not perform the following step with the database open

Delete the existing DBID. Perform this command in SQL*Plus as the SYS user:
SQL> exec sys.dbms_backup_restore.zerodbid(fno => 0);
A new DBID will be generated when you create a new control file by using the CREATE CONTROLFILE statement

j) Update the GLOBAL_NAME (conditionally required)
If the database name was changed, perform this command in SQL*Plus as the SYSTEM user to change the GLOBAL_NAME in the database:
SQL> alter database rename global_name to

k) Start the Net8 listener and verify that it allows remote connections to the database.

8. Copy the source system files
To copy the source APPL_TOP, OA_HTML, and JAVA_TOP directories to the target system, perform the following steps:
a) Verify that all users have logged off the source system and that all Applications server processes have been shut down.
b) Log on as the applmgr user on the target system.
c) Copy the source APPL_TOP, OA_HTML, and JAVA_TOP.
Copy these directory trees from each node of the source system to each corresponding node of the new target system. If your target system is on the same machine as your source system or the disks are NFS mounted, you can copy an entire directory tree at once.
UNIX:
For example, if your source system APPL_TOP is
/d01/apps115/PRODappl:
$ cp -r /d01/apps115/PRODappl /d02/apps115/TESTappl

The arguments for the copy command may differ depending upon the UNIX operating system type.

Windows:
For example, if your source system APPL_TOP is d:\PRODappl:
C:\> xcopy /s /e /i d:\PRODappl e:\TESTappl

If the target system is on a separate node, you can zip or tar the source system directories and FTP them to the target system node.
Replace the target system configuration In the “Prepare the target system” section, the configuration specific to the target system was saved before replacing files with those from the source system.
Perform the following steps to re-implement the saved configuration on the target system:

1. Verify that the database is started and the Net8 listener allows remote connections to the database

2. Run the AD cloning utility
Log on as the applmgr user, do not run or execute the Applications environment setup file, and run the AD cloning utility in postclone mode to configure the target system. The AD cloning utility is located in the AD_TOP/bin directory.

Note: The AD cloning utility will prompt you for the SYSTEM and APPS passwords when running in postclone mode.
For all users:
perl adclone.pl -mode=postclone -env_name=
-node_name= -config_file=
-ad_top=

The AD cloning utility in postclone mode will:
• Configure the database profiles
• Replace the configuration files associated with the APPL_TOP
• Replace the configuration files associated with the COMMON_TOP
• Generate the database security (DBC) file
• Update the interMedia shared library path
• Startup the services for this node
When cloning a multi-node system, repeat the steps in this section on each node
in your system.

Perform finishing tasks
This section describes the tasks you may need to perform to complete the
cloning process.
1. Apply technology stack patches and configuration changes (conditionally required)
If you have applied patches or tuned the parameter settings in the source system for any technology stack components not referred to in this paper, you will need to apply the patches and re-implement the settings in the target system. Common examples of technology stack updates include upgrading Oracle Developer (Forms, Reports, Graphics), upgrading JInitiator, adjusting parameters such as Oracle HTTP Server parameters in the httpd.conf file located in the iAS
ORACLE_HOME/Apache/Apache/conf directory, and updating profile options such as the Applications Framework Agent.

2. Modify the web configuration file (conditionally required)
The web configuration file appsweb.cfg exists in two locations on the Applications file system: FND_TOP/resource and OA_HTML/bin. If appsweb.cfg was patched, updated or customized in the source system you must update this file in the target system:
a) Back up appsweb.cfg from FND_TOP/resource and OA_HTML/bin of the target system.
b) Copy appsweb.cfg from FND_TOP/resource and OA_HTML/bin of the source system to the target system.
c) Modify the values in the ENVIRONMENT SPECIFIC PARAMETERS section of the appsweb.cfg of the target system to reflect the values in the backup copy that you created in step d). These parameters should reflect the values for your target system.

3. Update Self-Service parameters (conditionally required)
If you use Internet Explorer and changed the default SESSION_COOKIE_DOMAIN from null to some other value, update the Self-Service parameters directly using SQL*Plus:
sqlplus /
SQL> update ICX_PARAMETERS set SESSION_COOKIE_DOMAIN = '’;

4. Sign the Java archive files
Applications R11i requires that all Java archive (JAR) files used in the client tier be certified using a customer specific digital certificate. If you plan to use the same digital signature on both the source and target systems, copy the identitydb.obj from the source system to the target system.

This file is located in the home directory of the source system’s main Applications user. Copy it to the home directory of the target system’s application user. If a different digital certificate is to be used for the target system, create a new one. Will be discussed in next blog...

Whether a new or existing digital certificate is used, run AD Administration (adadmin) to generate product JAR files. When prompted to force regeneration of all jar files, type yes. Perform this step on each node of the target system

5. Relink the f60webmx executable (conditionally required)
If the target system utilizes the HP platform, you need to relink the f60webmx executable. Run AD Administration and choose Relink Applications programs from the Maintain Applications Files menu. See the Maintaining Oracle Applications manual for instructions. After relinking successfully, run 'chatr +s enable f60webmx' to resolve issues with Shared Library path. The
f60webmx executable is located in the FND_TOP/bin directory.

6. Relink Applications executables (recommended)
Relinking all of your Applications executables is recommended. Use the relink Applications programs task of AD Administration to relink your Applications executables. Perform this step on each node of the target system

7. Reconfigure Portal (conditionally required)
If you use Oracle Portal, update the configuration by performing step 1.7 (Register Portal and Login Server URLs Using ssodatan) in OracleMetaLink Note 146469.1.

TEST THE TARGET SYSTEM
Perform the following steps to verify the newly created system:

1. Check client tier connectivity.
Use the following URLs:
• Database PL/SQL Cartridge Connection:
With Apache single listener (11.5.2 and later or migrated 11.5.1)
Go to http://:/pls//FND_WEB.PING
With WebDB 2.5 (default configuration for 11.5.1)
Go to http://://FND_WEB.PING
You should see a table with information about your database.
• Apache Jserv:
Go to http://:/servlets/IsItWorking
You should see a message reassuring you that Apache JServ is working.
• Applications logon and Apache Server:
Go to the Rapid Install portal page:
http://:
Click on Apps Logon Links, then click on the personal home page link.
Log on to Self-Service Applications as SYSADMIN. Click on the link to the System Administration responsibility. This should bring up forms.

2. Verify that you can start and use the target system successfully with the source system shut down.
1. Shutdown the source system
2. Start the target system
3. Carry out login checks on the target system

OTHER CONSIDERATIONS
1. Update patch history database
If you are using the Patch History Database and the target system APPL_TOP name or the target system name is different from the source system, export the patch history database information from the target system and import it using the new target system APPL_TOP name and the target system name. See Migrating Patch History Information in the AD Procedures Guide.

2. Update tables with target system environment information
The following tables and columns may contain references to the source system. If so, update these to reflect the target system configuration:
• 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

The following table and columns may contain PATH references to the source system. If so, update these to reflect the target system configuration:
• FND_CONCURRENT_REQUESTS.LOGFILE_NAME
• FND_CONCURRENT_REQUESTS.OUTFILE_NAME

3. Verify target system profile options
The following profile options may references to the source system. If so, update these to reflect the target system configuration:
• WF_NOTIFICATION_ATTRIBUTES
• FND_FORM_FUNCTIONS
• POR_RESUBMIT_URL
• POR_UPDATE_REQ
• ICX_AP_WEB_OPEN_EXP

• WF_WEB_AGENT
• POR_SSP_HOME
• POR_SSP_ECMANAGER
• Applications Help Web Agent
• Applications Web Agent
• Apps Servlet Agent
• Help System Base URL
• ICX: Forms Launcher
• ICX: Report Images
• ICX: Report Launcher
• ICX: Report Link
• ICX:Report Cache
• JTF_BIS_OA_HTML
• TCF:HOST


Related Posts Plugin for WordPress, Blogger...

Let us be Friends...

Share |

Popular Posts

Recent Comments