Wednesday, October 27, 2010

Display User Lock Information

Hi

        Find the script below.


set echo off
set pagesize 60
Column SID         FORMAT 999 heading "Sess|ID "
COLUMN OBJECT_NAME FORMAT A17 heading "OBJ NAME or|TRANS_ID" Trunc
COLUMN OSUSER      FORMAT A10 heading "Op Sys|User ID"
COLUMN USERNAME    FORMAT A8
COLUMN TERMINAL    FORMAT A8  trunc
select B.SID, C.USERNAME, C.OSUSER, C.TERMINAL,
       DECODE(B.ID2, 0, A.OBJECT_NAME,
            'Trans-'||to_char(B.ID1)) OBJECT_NAME,
     B.TYPE,
       DECODE(B.LMODE,0,'--Waiting--',
                      1,'Null',
                      2,'Row Share',
                      3,'Row Excl',
                   4,'Share',
                      5,'Sha Row Exc',
           6,'Exclusive',
                        'Other') "Lock Mode",
       DECODE(B.REQUEST,0,' ',
                      1,'Null',
                      2,'Row Share',
                      3,'Row Excl',
                      4,'Share',
                      5,'Sha Row Exc',
                      6,'Exclusive',
                     'Other') "Req Mode"
  from DBA_OBJECTS A, V$LOCK B, V$SESSION C
where A.OBJECT_ID(+) = B.ID1
  and B.SID = C.SID
  and C.USERNAME is not null
order by B.SID, B.ID2;

Display SQL text from Locked Transactions

Hi

      Find the script below.

set pagesize 60
set linesize 132
select s.username username, 
       a.sid sid, 
       a.owner||'.'||a.object object, 
       s.lockwait, 
       t.sql_text SQL
from   v$sqltext t, 
       v$session s, 
       v$access a
where  t.address=s.sql_address 
and    t.hash_value=s.sql_hash_value 
and    s.sid = a.sid 
and    a.owner != 'SYS'
and    upper(substr(a.object,1,2)) != 'V$'

Report sessions waiting for Locks

Hi
       If you find waiting user sessions for locks. Below script you can use for this.

column username format  A15
column sid      format  9990    heading SID
column type     format  A4
column lmode    format  990     heading 'HELD'
column request  format  990     heading 'REQ'
column id1      format  9999990
column id2 format  9999990
break on id1 skip 1 dup
spool tfslckwt.lst
SELECT sn.username, m.sid, m.type,
        DECODE(m.lmode, 0, 'None',
                        1, 'Null',
                        2, 'Row Share',
                        3, 'Row Excl.',
                        4, 'Share',
                        5, 'S/Row Excl.',
                        6, 'Exclusive',
                lmode, ltrim(to_char(lmode,'990'))) lmode,
        DECODE(m.request,0, 'None',
                         1, 'Null',
                         2, 'Row Share',
                         3, 'Row Excl.',
                         4, 'Share',
                         5, 'S/Row Excl.',
                         6, 'Exclusive',
                         request, ltrim(to_char(m.request,
                '990'))) request, m.id1, m.id2
FROM v$session sn, v$lock m
WHERE (sn.sid = m.sid AND m.request != 0)
        OR (sn.sid = m.sid
                AND m.request = 0 AND lmode != 4
                AND (id1, id2) IN (SELECT s.id1, s.id2
     FROM v$lock s
                        WHERE request != 0
              AND s.id1 = m.id1
                                AND s.id2 = m.id2)
                )
ORDER BY id1, id2, m.request;
spool off
clear breaks


==============
Sample Output:
==============


USERNAME          SID TYPE HELD        REQ           ID1        ID2
--------------- ----- ---- ----------- ----------- -------- --------
SYSTEM             12 TX   Exclusive   None          131087     2328
SCOTT               7 TX   None        Exclusive     131087     2328
SCOTT               8 TX   Exclusive   None          131099     2332
SYSTEM             10 TX   None        Exclusive     131099     2332
SYSTEM             12 TX   None        Exclusive     131099     2332

Friday, October 22, 2010

Upgrade Oracle Applications from R12.1.1 to R12.1.2

Hi

     Follow the doc for upgrading application from  R12.1.1 to R12.1.2


Author –
A.Kishore
http://appsdba.info
Upgrade Oracle Applications from R12.1.1 to R12.1.2
Reference Note -
Oracle E-Business Suite Readme, Release 12.1.2 (Doc ID 949406.1)
1> Database Preparation Guidelines for an E-Business Suite Release 12.1.1 Upgrade (Doc ID 761570.1)
The minimum required database version should be 11.1.0.7, R12.1.1 comes with 11.1.0.7
Test - Passed
2>
ID 454811.1)
Upgrading to the Latest OracleAS 10g 10.1.3.x Patch Set in Oracle E-Business Suite Release 12 (Doc
The minimum required version of
[applmgr12@linux1 ~]$ grep "ias_version" $CONTEXT_FILE
<ias_version oa_var="s_ias_version">10.1.3.4.0</ias_version>
OracleAS 10g should be 10.1.3.4, R12.1.1 comes with 10.1.3.4
Test - Passed
3>
Upgrading OracleAS 10g Forms and Reports in Oracle E-Business Suite Release 12 (Doc ID 437878.1)
The minimum required version of
with 10.1.3.4
OracleAS 10g Forms and Reports should be 10.1.2.3.0, R12.1.1 comes
[applmgr12@linux1 ~]$ grep "forms_version" $CONTEXT_FILE
<forms_version oa_var="s_forms_version">10.1.2.3.0</forms_version>
Test - Passed
Author –
A.Kishore
http://appsdba.info
4> Below patches/steps are required to upgrade from R12.1.1 to R12.1.2
- Use AutoPatch to apply R12.AD.B.DELTA.2 Patch 8502056
-
Use AutoPatch to apply Release 12.1.2 Patch 7303033 – Patch size is 3.2 GB
-
Use AutoPatch to apply the latest consolidated online help Patch 7303032
-
Post-Update Steps
5> Use AutoPatch to apply R12.AD.B.DELTA.2 Patch 8502056
The readme says to run admsi.pl (Patch application assistant)
Author –
A.Kishore
http://appsdba.info
Patch Location - /d01/oracle/R1212/8502056
Author –
A.Kishore
http://appsdba.info
Author –
A.Kishore
http://appsdba.info
-- stop the services
su - applmgr12
cd $ADMIN_SCRIPTS_HOME
sh adstpall.sh apps/apps
-- Enable Maintenance Mode
adadmin defaultsfile=$APPL_TOP/admin/$TWO_TASK/adalldefaults.txt logfile=adadmin.log
menu_option=ENABLE_MAINT_MODE workers=4
export PATCH_TOP=/d01/oracle/R1212
Create $ORACLE_HOME/appsutil/admin on the database server.
su – oracle12
cd $ORACLE_HOME/appsutil
Author –
A.Kishore
http://appsdba.info
mkdir admin
Copy adgrants.sql (UNIX) from this patch directory to
cd $ORACLE_HOME/appsutil/admin
cp $APPL_TOP/admin/adgrants.sql .
sqlplus "/as sysdba" @adgrants.sql APPS
-- Apply patch 8502056 in non interactive mode
-- Takes 30 minutes
adpatch defaultsfile=$APPL_TOP/admin/$TWO_TASK/adalldefaults.txt logfile=u8502056.log
patchtop=$PATCH_TOP/8502056 driver=u8502056.drv workers=4
5>
Use AutoPatch to apply Release 12.1.2 Patch 7303033 – Took 18 hours
Run admsi.pls as per the readme file
Author –
A.Kishore
http://appsdba.info
adpatch defaultsfile=$APPL_TOP/admin/$TWO_TASK/adalldefaults.txt logfile=u7303033.log
patchtop=$PATCH_TOP/7303033 driver=u7303033.drv workers=4
Issue 1>
I told Yes and continued with patch
grep 'Error' adrelink.lsv
make: *** [/d02/oracle/PROD/apps/apps_st/appl/msc/12.0.0/bin/MSCCPP] Error 1
Solution -
Relink Error On All MSC Executables On Oracle Enterprise Linux (OEL) 5.x/Red Hat Linux (RHEL) 5.x (Doc ID
758831.1)
The below link from forums.oracle.com has given me the clue.
http://forums.oracle.com/forums/thread.jspa?threadID=1026800&tstart=0
You should follow the instructions in Metalink note 758831.1.
I had a similar problem while patching from 12.1.1 to 12.1.2, all of the MSC... files would not relink. I had to reinstall the binutils library and
all went well.
It might work for you too (I'm running OEL 5 64bit)
Read the whole note but since I already downloaded and installed those packages as part of the initial install I just needed to reinstall this
one
rpm -U binutils-2.17.50.0.6-6.0.1.el5.x86_64.rpm
Author –
A.Kishore
http://appsdba.info
Issue 2>
/d02/oracle/PROD/apps/apps_st/appl/cs/12.0.0/patch/115/sql/csusrs.pls
CREATE OR REPLACE PACKAGE CS_ServiceRequest_UTIL AUTHID CURRENT_USER
Unable to process file in PACKAGE mode.
AD Worker error:
ORA-00060: deadlock detected while waiting for resource
Solution – I executed the csusrs.pls manually and there was no issue
sqlplus apps/apps @/d02/oracle/PROD/apps/apps_st/appl/cs/12.0.0/patch/115/sql/csusrs.pls
I have restarted the failed worker using adctrl
Issue 3> Few pll/fmx have failed to compile
Author –
A.Kishore
http://appsdba.info
I told Yes and continued with the patch and then manually generated the plls/fmx files using adadmin,
the issue got resolved.
3>
Use AutoPatch to apply the latest consolidated online help Patch 7303032
adpatch defaultsfile=$APPL_TOP/admin/$TWO_TASK/adalldefaults.txt logfile=u7303032.log
patchtop=$PATCH_TOP/7303032 driver=u7303032.drv workers=4
Post-Update Steps
Update database tier nodes with the Release 12.1.2 code level.
After you have upgraded to Release 12.1.2, perform the following post-update steps to update all
database tier nodes with the code level, provided by Release 12.1.2:
Application tier:
As the APPLMGR user, run the environment (UNIX) or the command (WINDOWS) file for the current
APPL_TOP.
UNIX
. ./<APPL_TOP>/APPS<CONTEXT_NAME>.env
Run the admkappsutil.pl utility to create the file appsutil.zip in the <INST_TOP>/admin/out directory.
perl <AD_TOP>/bin/admkappsutil.pl
As the ORACLE user, run the environment (UNIX) or the command (WINDOWS) file for the current
ORACLE_HOME.
UNIX
cd <RDBMS ORACLE_HOME>
. ./<RDBMS ORACLE_HOME>/<CONTEXT_NAME>.env
Copy or FTP the appsutil.zip file to the <RDBMS ORACLE_HOME>.
Uncompress appsutil.zip under the <RDBMS ORACLE_HOME>.
cd <ORACLE_HOME>
mv appsutil appsutil_old
Author –
A.Kishore
http://appsdba.info
unzip -o appsutil.zip
Run AutoConfig on the <RDBMS ORACLE_HOME>.
perl adbldxml.pl appsuser=apps appspass=apps
Below is the error
JRE_TOP or java executable not found at its desired location /d02/oracle/PROD/db
/tech_st/11.1.0/appsutil/jre, /d02/oracle/PROD/db/tech_st/11.1.0/appsutil/jre/bin/java
Solution :
Copy the jre from appsutil_old
cd $ORACLE_HOME/appsutil_old
cp -R jre /d02/oracle/PROD/db/tech_st/11.1.0/appsutil
perl adbldxml.pl appsuser=apps appspass=apps
The context file has been created at:
/d02/oracle/PROD/db/tech_st/11.1.0/appsutil/ PROD_linux1.xml
n
cd /d02/oracle/PROD/db/tech_st/11.1.0/appsutil/bin
sh adconfig.sh
Enter the full path to the Context file: /d02/oracle/PROD/db/tech_st/11.1.0/appsutil/ PROD_linux1.xml
Enter the APPS user password:
Run autoconfig
Database tier and application tier:
Re-run adpreclone.pl on the database tier and the application tier. Since updates included in RUP6 were
applied to the system, adpreclone must be run again to apply the updates to the clone directory
structures that were used during cloning.
perl adpreclone.pl dbTier
perl adpreclone.pl appsTier
Author –
A.Kishore
http://appsdba.info
n
adadmin menu_option=DISABLE_MAINT_MODE workers=4 defaultsfile=$APPL_TOP/admin
/$TWO_TASK/adalldefaults.txt logfile=adadmin_DISABLE_MAINT_MODE.log
Disable the maintenance mode
n
cd $ADMIN_SCRIPTS_HOME
sh adstrtal.sh apps/apps
Final check - Check whether the update is done or not from backend
Author –
Start the servicesA.Kishore
http://appsdba.info
Check whether application is running from frontend

Rapid clone doc

Hi

     For the cloning of application  you follow the mentioned doc of Rapid Clone.


Cloning Oracle Applications Release 12 with Rapid Clone

Last Updated: September 27, 2010

This knowledge document describes the process of cloning an Oracle Applications Release 12 system.
The content applies to all Release 12.x.x versions, such as 12.0, 12.0.4, and 12.1.x. Where applicable, 12.0.x releases will in general be referred to as Release 12.0, and 12.1.x releases as Release 12.1.
The most current version of this document can be obtained in Oracle Support Knowledge Document 406982.1.
There is a change log at the end of this document.

In This Document

Terminology

Cloning is the process used to create a copy of an existing Oracle Applications system. There are various scenarios for cloning an Oracle Applications system, including:
  • Standard cloning - Making a copy of an existing Oracle Applications system, for example a copy of a production system to test updates.
  • System scale-up - Adding new machines to an Oracle Applications system to provide the capacity for processing an increased workload.
  • System transformations - Altering system data or file systems, including actions such as platform migration, data scrambling, and provisioning of high availability architectures.
  • Patching and upgrading - Delivering new versions of Applications components, and providing a mechanism for creating rolling environments to minimize downtime.
An important principle in Oracle Applications cloning is that the system is cloned, rather than the topology. Producing an exact copy of the patch level and data is much more important than creating an exact copy of the topology, as a cloned system must be able to provide the same output to the end user as the source system. However, while a cloned system need not have the full topology of its source, it must have available to it all the topology components that are available to the source.
Conventions used in this document include the following:
Term or Usage Meaning or Action
Source system Oracle Applications system being cloned.
Target system Oracle Applications system being created as a copy of the source.
APPLMGRUser that owns the application tier file system (APPL_TOP and application tier technology stack).
ORACLE User that owns the database tier file system (RDBMS ORACLE_HOME and database files).
CONTEXT_NAMEThe CONTEXT_NAME variable refers to the name of the Applications context file. By default, CONTEXT_NAME is [SID]_[HOSTNAME].
Monospace Text Represents command line text. Type this command exactly as shown.
[ ] Text enclosed in brackets represents a variable. Substitute a value for the variable text. Do not type the brackets.

Section 1: Prerequisite Tasks

Before cloning, prepare the source system by applying any required patches and running AutoConfig.
  1. Verify OS requirements on target system
    Before cloning to a new server, ensure the target system meets all the requirements for Oracle Applications Release 12 stated on the Oracle Applications Release Notes, and on the Oracle Applications Installation and Upgrade Notes for each Platform. For the latest installation guidelines refer to My Oracle Support Knowledge Document 405565.1.

    Note: On Microsoft Windows, Rapid Clone is not currently certified for use from Domain User Accounts.
  2. Verify source and target system software components and versions
    In addition to the Oracle Applications software requirements (see Oracle Applications Installation Guide: Using Rapid Install), the following software component versions must exist on the source or target nodes as applicable. The 'Location' column indicates the node where the software component must reside.

    Table 1: Software Requirements

    Software Component Minimum VersionRequired LocationComments
    Zip2.3
    (or higher)
    All source system nodes Download from InfoZip. Zip must be in your $PATH. If using files bigger than 2Gb, you should use InfoZip ZIP 3.0 or higher.
    Unzip5.52
    (or higher)
    All source system nodes Download from InfoZip. Unzip must be in your $PATH. If using files bigger than 2Gb, you should use InfoZip UNZIP 5.52 or higher.
    Operating system utilities N/AAll target system nodesThe required operating system utilities for your platform must be in your $PATH when running adcfgclone.pl. For example, make, ld, and ar on UNIX. Refer to Oracle Applications Installation Guide: Using Rapid Install (see Footnote 1)
    Perl5.xAll target system nodes Use the Perl shipped with OracleAS 10.1.3 and Database 10g, or download it from Perl.com. Perl must be in your $PATH, and $PERL5LIB must be set correctly before cloning.

    Footnote 1 This is the Release 12.1.1 version; versions for earlier releases are also available from the Oracle E-Business Suite Online Documentation Library
  3. Apply the latest AD patch
    Apply patch 6510214 (R12.AD.A.DELTA.4) or higher. Refer to My Oracle Support to obtain the latest AD patch.
  4. 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 My Oracle Support Knowledge Document 387859.1 for details of the latest AutoConfig Template rollup patch.
  5. Apply the latest Rapid Clone patches
    Update the Oracle Applications file system with the latest Rapid Clone files by applying the following patches to all Applications nodes.

    • For Release 12.0:

      Apply patches as listed in Table 2.a.

      Table 2.a: Release 12.0 Rapid Clone patches

      Patch Description
      5484000Oracle E-Business Suite 12.0.2 Release Update Pack (RUP2) or higher
      9171651:R12.OAM.A12.0 RAPIDCLONE CONSOLIDATED FIXES JUL/2010
    • For Release 12.1:

      Apply patches as listed in Table 2.b.

      Table 2.b: Release 12.1 Rapid Clone patches

      Patch Description
      9171651:R12.OAM.B12.1 RAPIDCLONE CONSOLIDATED FIXES JUL/2010
    • Other Patches (All releases):

      Apply patches as listed in Table 2.c.

      Table 2.c: Other Patches

      Patch Description
      8246709Required for Microsoft Windows if using OracleAS 10.1.3.4. This patch must be re-applied to the OracleAS 10.1.3.4 ORACLE_HOME before every cloning operation.

    Note: If new Rapid Clone or AutoConfig updates are applied to the system, steps 6, 7, and 8 below must be executed again in order to apply the new files to the database node.
  6. Run AutoConfig on the application tiers
    Follow the steps under section " Run AutoConfig on the Application Tiers " in My Oracle Support Knowledge Document 387859.1 to run AutoConfig on all application tier nodes.
  7. Synchronize appsutil on the database tier nodes
    Follow the steps under section "Copy AutoConfig to the RDBMS ORACLE_HOME" in My Oracle Support Knowledge Document 387859.1 to copy AutoConfig and Rapid Clone files to each database node via the admkappsutil.pl utility.
  8. Run AutoConfig on the database tier
    Follow the steps under section "Run AutoConfig on the Database Tier" in My Oracle Support Knowledge Document 387859.1 to run AutoConfig on the database tier nodes.
  9. Maintain snapshot information
    Log in to each application tier node as the APPLMGR user, and run "Maintain Snapshot information" in AD Administration. Refer to Oracle Applications Maintenance Utilities for more information (this is the Release 12.1 version; versions for earlier releases are also available from the Oracle E-Business Suite Online Documentation Library).

Section 2: Cloning Tasks

Use Rapid Clone to create template files for cloning on the source system. After the source system is copied to the target, Rapid Clone updates these templates to contain the new target system configuration settings.
Note: Rapid Clone never changes the source system configuration.
The cloning process consists of three phases, each of which is made up of several logical sections and their steps.
  1. Prepare the source system
    Execute the following commands to prepare the source system for cloning:

    1. Prepare the source system database tier for cloning
      Log on to the source system as the ORACLE user, and run the following commands:
      $ cd [RDBMS ORACLE_HOME]/appsutil/scripts/[CONTEXT_NAME]
      $ perl adpreclone.pl dbTier
    2. Prepare the source system application tier for cloning
      Log on to the source system as the APPLMGR user, and run the following commands on each node that contains an APPL_TOP:
      $ cd [INST_TOP]/admin/scripts
      $ perl adpreclone.pl appsTier
      Note: If new Rapid Clone or AutoConfig updates are applied to the system, adpreclone.pl must be executed again on the dbTier and on the appsTier in order to apply the new files into the clone directory structures that will be used during the cloning configuration stage.
  2. Copy the source system to the target system
    Copy the application tier file system from the source Applications system to the target node by executing the following steps in the order listed. Ensure the application tier files copied to the target system are owned by the target APPLMGR user, and that the database node files are owned by the target ORACLE user.

    Note: In the copying tasks below, UNIX/Linux users should ensure that the symbolic links (soft links) are preserved when copying. On most UNIX platforms, this can be accomplished with the cp -RH command. Consult the UNIX man page for the cp command to check the parameters available on your platform.
    For example: cd /target_dest_dir/db cp -RH /source_dir/db/*
    Alternatively, the tar command can be used to compress the directories into a temporary staging area. If you use this command, you may require the -h option to follow symbolic links, as following symbolic links is not the default behavior on all platforms. Consult the UNIX man page for the tar command.

    Additionally, verify the permissions of the executables under ORACLE_HOME/bin that can potentially be owned by root (i.e. nmo, nmhs, nmb, etc).

    1. Copy the application tier file system
      Log on to the source system application tier nodes as the APPLMGR user and shut down the application tier server processes. Copy the following application tier directories from the source node to the target application tier node:

      • [APPL_TOP]
      • [COMMON_TOP]
      • Applications Technology Stack:
        • [OracleAS Tools ORACLE_HOME]
        • [OracleAS Web IAS_ORACLE_HOME]
    2. Copy the database node file system
      Log on to the source system database node as the ORACLE user, and then:

      1. Perform a normal shutdown of the source system database
      2. Copy the database (.dbf) files from the source system to the target system
      3. Copy the source database ORACLE_HOME to the target system
      4. Start the source Applications system database and application tier processes
  3. Configure the target system

    Run the following commands to configure the target system. You will be prompted for specific target system values such as SID, paths, and ports.

    1. Configure the target system database server
      Log on to the target system as the ORACLE user and enter the following commands:
      $ cd [RDBMS ORACLE_HOME]/appsutil/clone/bin
      $ perl adcfgclone.pl dbTier
    2. Configure the target system application tier server nodesLog on to the target system as the APPLMGR user and enter the following commands:
      $ cd [COMMON_TOP]/clone/bin
      $ perl adcfgclone.pl appsTier

Section 3: Finishing Tasks

This section lists tasks that may be necessary, depending on your implementation and the intended use of the cloned system.
  1. Update profile options
    Rapid Clone updates only site level profile options. If any other profile options are set to instance specific values, you must update them manually.
  2. Update printer settings
    If the new cloned system needs to utilize different printers, update the target system with the new printer settings now.
  3. Update Workflow configuration settings
    Cloning an Oracle Applications instance will not update the host and instance-specific information used by Oracle Workflow. Review the tables and columns listed in Table 3 to check for any instance-specific data in the Workflow configuration on the target system.

    Table 3: Workflow configuration settings

    Table Name Column Name Column Value Details
    WF_NOTIFICATION_ATTRIBUTESTEXT_VALUE Value starts with http://[old web host]: Update to new web host.
    WF_ITEM_ATTRIBUTE_VALUESTEXT_VALUEValue starts with "http://[old web host]: Update to new web host.
    WF_SYSTEMSGUIDUsing the Workflow Administrator Web Applications responsibility, create a new system defined as the new global database name.
    WF_SYSTEMSNAMEReplace value with the database global name.
    WF_AGENTSADDRESSUpdate database link with the new database global name.
    FND_FORM_FUNCTIONSWEB_HOST_NAMEUpdate with the new web host name.
    FND_FORM_FUNCTIONSWEB_AGENT_NAMEUpdate to point at the new PL/SQL listener name.
    FND_CONCURRENT_REQUESTSLOGFILE_NAMEUpdate with the correct path to the logfile directory.
    FND_CONCURRENT_REQUESTSOUTFILE_NAMEUpdate with the new directory path on the target system.
  4. Verify the APPLCSF variable setting
    Source the APPS environment and review that the variable APPLCSF (identifying the top-level directory for concurrent manager log and output files) points to a suitable directory. To modify it, change the value of the s_applcsf variable in the context file and then run AutoConfig.
  5. Update the SESSION_COOKIE_DOMAIN value in ICX_PARAMETERS
    If the target system is in a different domain name than the source system and SESSION_COOKIE_DOMAIN was not null in the source system, update that value to reflect the new domain name.
  6. Re-Implement SSL and SSO configuration
    If the Source System was SSL or SSO enabled, reconfigure the Target by following the SSL/SSO documentation.

Section 4: Advanced Cloning Options

This section describes various advanced cloning procedures that may need to be employed in the appropriate circumstances.

Option 1: Refreshing a Target System

You may need to refresh the target system periodically to synchronize it with changes to the source system.
Note: Back up the target context file on the target system before refreshing the database or application tiers.
To refresh the target system, perform the following steps as described in previous sections:
  1. Prepare the source system.
  2. Copy the source system to the target system.

    1. If the application tier file system if the APPL_TOP, COMMON_TOP, or technology stack needs to be refreshed, copy the portion of the application tier file system that has been updated
    2. If the RDBMS ORACLE_HOME or the database needs to be refreshed, copy the database node file system. If refreshing the database, the ORACLE_HOME should be refreshed at the same time.
  3. Configure the target system.

    Specify the existing target system context file when running adcfgclone.pl commands.

    1. Configure the target system database server by logging on to the target system as the ORACLE user and entering the following commands to configure and start the database:
      $cd [RDBMS ORACLE_HOME]/appsutil/clone/bin
      perl adcfgclone.pl dbTier [Database target context file]

      Where Database target context file is [RDBMS ORACLE_HOME]/appsutil/[Target CONTEXT_NAME].xml
    2. Configure the target system application tier server nodes by logging on to the target system as the APPLMGR user and entering the following commands:
      $ cd [COMMON_TOP]/clone/bin
      $ perl adcfgclone.pl appsTier [APPL_TOP target context file]

      Where APPL_TOP target context file is [INST_TOP]/appl/admin/[Target CONTEXT_NAME].xml
  4. Perform the standard finishing tasks.

Option 2: Cloning a Multi-Node System

This procedure allows the source system or target system to be a multi-node system. As of Release 12, all APPL_TOPs are unified APPL_TOPs. This means that all files required for all application tier services are installed on every application tier node. Thus, only one copy of the applications tier node files needs to be copied to the target system, regardless of whether a shared file system is being used on the source or target system. Multiple application tier nodes are distinguished from each other by the services running.
  1. Perform the standard prerequisite tasks.
    Carry out these steps on all source and target nodes.
  2. Carry out the previously-described cloning tasks.

    Prepare, copy and configure the cloned Applications system. When creating more than one application tier node on the target system, follow these steps:

    1. Perform a full clone (Prepare, copy and configure steps) of the database node and primary application tier node.
    2. To add shared application tier nodes on the target system, follow the instructions in My Oracle Support Knowledge Document 384248.1, Section 4: Adding a node to a Shared Application Tier File System.
    3. To add non-shared application tier nodes, execute the copy and configure steps as on the primary node.
    4. Specify the services to start on each target Applications tier node when responding to the prompts during the configuration step.
  3. Perform the required finishing tasks

Option 3: Adding a New Node to an Existing System

You can use Rapid Clone to clone a node and add it to the existing Applications system, a process also known as scale up or scale out. The new node can run the same services as the source node, or different services. Follow the instructions in the Application tier part of Cloning Tasks.
  1. Prepare the source system, copy it to the new node and configure it.
  2. After adcfgclone.pl completes, source the Applications environment and run the following commands on the target system:
    $ cd [COMMON_TOP]/clone/bin
    $ perl adaddnode.pl
Note: After adding new nodes, refer to My Oracle Support Knowledge Document 380489.1 for details of how to set up load balancing.


Note: If SQL*Net Access security is enabled in the existing system, you first need to authorize the new node to access the database through SQL*Net. See the Oracle Applications Manager on line help for instructions on how to accomplish this.

Option 4: Cloning an Oracle RAC system

For instructions on how to Clone RAC-Enabled Systems with Rapid Clone, refer to My Oracle Support Knowledge Document 559518.1.

Option 5: Adding a Node to an Existing Oracle RAC Cluster

From Release 12, Rapid Clone is no longer used to migrate a database tier to Oracle RAC. Refer to My Oracle Support Knowledge Document 388577.1 for instructions on how to perform this task.

Option 6: Cloning the Database Separately

Some situations require the database to be recreated separately, without using Rapid Clone. Typical scenarios are when system downtime is not feasible, or advanced database replication tools like RMAN are being used to copy the database in hot backup mode.
This section documents the steps needed to allow manual creation of the target database control files within the Rapid Clone process. This method needs to be used for databases located on raw partitions, or when cloning a hot backup. Follow the complete steps in Cloning Tasks, but replace Step 3a (Configure the target system database server) with the following steps:
  1. Log on to the target system as the ORACLE user
  2. Configure the [RDBMS ORACLE_HOME]
    $ cd [RDBMS ORACLE_HOME]/appsutil/clone/bin
    $ perl adcfgclone.pl dbTechStack
  3. Create the target database control files manually

    In this step, you copy and recreate the database using your preferred method, such as RMAN restore, Flash Copy, Snap View, or Mirror View.
  4. Start the target database in open mode
  5. Run the library update script against the database
    $ cd [RDBMS ORACLE_HOME]/appsutil/install/[CONTEXT NAME]
    $ sqlplus "/ as sysdba" @adupdlib.sql [libext]

    Where [libext] should be set to 'sl' for HP-UX, 'so' for any other UNIX platform, or 'dll' for Windows.
  6. Configure the target database

    The database must be running and open before performing this step.
    $ cd [RDBMS ORACLE_HOME]/appsutil/clone/bin
    $ perl adcfgclone.pl dbconfig [Database target context file]

    Where Database target context file is: [RDBMS ORACLE_HOME]/appsutil/[Target CONTEXT_NAME].xml.

How to clone a database with rman

Hi

      If anybody clone the database with rman backup. Everybody follow these steps.


In this Document
  Goal
  Solution
     Duplicate database from server A to server B (Non ASM)
     1. Backup of the primary database.
     2. Determine how much disk space will be required.
     3. Ensuring you have enough space on your target server.
     4. Making the backup available for the duplicate process.
     5. Creating the init.ora & administration directories for the duplicate database.
     6. Ensuring SQL*NET connections to primary database and RMAN catalog are working.
     7. Prepare RMAN duplicate script.
     8. Execute the RMAN script.
  References




Applies to:

Oracle Server - Enterprise Edition - Version: 9.0.1.4 to 11.2.0.0
Information in this document applies to any platform.
Checked for relevance on 06-AUG-2009

Goal

The following note will guide a user in creating a duplicate database on a new host (non ASM).  The scenario refers to a recovery catalog however a catalog is not mandatory. The following example has been completed on a linux operating system.

The note is applicable for 9i, 10g and 11g. However 11g has new features related to the DUPLICATE.
See for more details on the 11g DUPLICATE new features : Note 452868.1 RMAN 'Duplicate Database' Feature in 11G

Solution

Duplicate database from server A to server B (Non ASM)


Assumed database names:
Primary Database SID:       PROD
Duplicate Database SID:    AUX
RMAN Catalog SID:          RMAN


====================================================================================
Steps

1.  Backup the primary database.

2.  Determine how much disk space will be required.

3.  Ensuring you have enough space on your target server.

4.  Making the backup available for the duplicate process.

5.  Creating the init.ora & administration directories for the duplicate database.

6.  Ensuring SQL*NET connections to primary database and RMAN catalog are working.

7.  Prepare RMAN duplicate script.

8.  Execute the RMAN script.

=====================================================================================


1. Backup of the primary database.


Host A (Target)

Prior to creating a duplicate database you must have a backup of the target database. In this example we assume the backup media is disk. Find appropriate disk space on host A and take a full backup including archive logs and current controlfile (Figure 1a). If you are planning to duplicate a subset of the database refer to (Figure 1b) this illustrates the RMAN command to backing up certain tablespaces.

[oracle@linux] export ORACLE_SID=PROD

[oracle@linux] rman target=/ catalog=rman/rman@RMAN

RMAN> run {
        allocate channel d1 type disk;
        backup format '/backups/PROD/df_t%t_s%s_p%p' database;
        sql 'alter system archive log current';
        backup format '/backups/PROD/al_t%t_s%s_p%p' archivelog all;
        release channel d1;
      }

       Figure 1a - This command will perform a full database backup including archivelogs and the current controlfile.


[oracle@linux] export ORACLE_SID=PROD

[oracle@linux] rman target=/ catalog=rman/rman@RMAN

RMAN> run {
        allocate channel d1 type disk;
        backup format '/backups/PROD/df_t%t_s%s_p%p'
               tablespace SYSTEM, SYSAUX, UNDO, USERS;
        sql 'alter system archive log current';
        backup format '/backups/PROD/al_t%t_s%s_p%p' archivelog all;
        release channel d1;
     }
    Figure 1b- This command will perform a tablespace backup ( SYSTEM, SYSAUX, UNDO & USERS) including archive logs and the current controlfile.

2. Determine how much disk space will be required.


Host A(Target) -

After deciding what you will be duplicating, calculate the entire space this will require on the new host. The full database calculation (Figure 2a) will calculate the entire space required whereas (figure 2b) allows you to enter the tablespace names in order to calculate the space required. Figure 2c provides a sample output.

Note: sql valid for version 10g only.
SQL> select DF.TOTAL/1048576 "DataFile Size Mb",
            LOG.TOTAL/1048576 "Redo Log Size Mb",
            CONTROL.TOTAL/1048576 "Control File Size Mb",
            (DF.TOTAL + LOG.TOTAL + CONTROL.TOTAL)/1048576 "Total Size Mb"
     from dual,
    (select sum(a.bytes) TOTAL from dba_data_files a) DF,
    (select sum(b.bytes) TOTAL from v$log b) LOG,
    (select sum((cffsz+1)*cfbsz) TOTAL from x$kcccf c) CONTROL;
     Figure 2a - Calculate total space for all datafiles within database.

SQL> select DF.TOTAL/1048576 "DataFile Size Mb",
            LOG.TOTAL/1048576 "Redo Log Size Mb",
            CONTROL.TOTAL/1048576 "Control File Size Mb",
            (DF.TOTAL + LOG.TOTAL + CONTROL.TOTAL)/1048576 "Total Size Mb" from dual,
    (select sum(a.bytes) TOTAL from dba_data_files a
     where tablespace_name in('SYSTEM','UNDOTBS1', 'SYSAUX', 'USERS')) DF,
    (select sum(b.bytes) TOTAL from v$log b) LOG,
    (select sum((cffsz+1)*cfbsz) TOTAL from x$kcccf c) CONTROL;
     Figure 2b - Calculate space for list of tablespaces within primary database.

DataFile Size Mb Redo Log Size Mb Control File Size Mb Total Size Mb
---------------- ---------------- -------------------- -------------
             900              150             20.34375    1070.34375
     Figure 2c - Sample output of space calculation.

3. Ensuring you have enough space on your target server.


Host B (Aux)

Prior to starting the duplicate process you must ensure you have enough disk space within file system to hold the database.

[oracle@linux] df -kh
Filesystem         Size     Used     Avail     Use%     Mounted on
/dev/vg01/root     9.9G     2.8G      6.6G      30%              /
/dev/sda1          145M      16M      122M      12%          /boot
none               999M        0      999M       0%       /dev/shm
/dev/vg01/tmp      2.0G     383M      1.5G      20%           /tmp
/dev/vg01/u01       20G      12G      7.0G      62%           /u01
/dev/vg01/u02      4.9G    1010M      3.6G      22%           /u02
/dev/vg01/backups  5.9G     1.2G      4.4G      22%       /backups
/dev/vg01/oradata   15G      13G      2.0G      87%       /oradata
     Figure 3a - Sample output showing the space available on your filesystem.

Compare the results received from this query with the output from 2a or 2b and ensure you have enough diskspace for your duplicate database.


4. Making the backup available for the duplicate process.


If your backup resides on disk you will need to copy this back up from host A to host B. Ensure you place it in the same directory as where it was created. In the example below (figure 4a) the backup piece resides in ‘/backups/PROD’ these files need to be copied into the same directory on host B.

Furthermore also ensure than all archive log backups have also been moved and any archive logs in the archive log directory that may be require for the recovery. The archive logs required will depend on the point in time of the recovery.

RMAN> list backup;

BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
22 Full 529M DISK 00:00:51 2006/05/16 11:12:54
BP Key: 22 Status: AVAILABLE Compressed: NO Tag: TAG20060516T111203
Piece Name: /backups/PROD/df_t590584323_s23_p1
List of Datafiles in backup set 22
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- ------------------- ----
1 Full 1393845 2006/05/16 11:12:03 /oradata/PROD/system01.dbf
2 Full 1393845 2006/05/16 11:12:03 /oradata/PROD/undotbs01.dbf
3 Full 1393845 2006/05/16 11:12:03 /oradata/PROD/sysaux01.dbf
4 Full 1393845 2006/05/16 11:12:03 /oradata/PROD/users01.dbf


BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ -------------------
24 48M DISK 00:00:06 2006/05/16 11:13:07
BP Key: 24 Status: AVAILABLE Compressed: NO Tag: TAG20060516T111301
Piece Name: /backups/PROD/al_t590584381_s25_p1

List of Archived Logs in backup set 24
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- ------------------- ---------- ---------
1 78 1344750 2006/05/15 04:55:34 1353208 2006/05/15 10:00:19
1 79 1353208 2006/05/15 10:00:19 1353213 2006/05/15 10:00:20
1 80 1353213 2006/05/15 10:00:20 1371564 2006/05/15 22:00:11
1 81 1371564 2006/05/15 22:00:11 1373291 2006/05/15 22:00:59
1 82 1373291 2006/05/15 22:00:59 1381066 2006/05/16 03:00:05
1 83 1381066 2006/05/16 03:00:05 1390685 2006/05/16 09:03:00
1 84 1390685 2006/05/16 09:03:00 1393870 2006/05/16 11:13:00
1 85 1393870 2006/05/16 11:13:00 1393929 2006/05/16 11:13:00
     Figure 4a - A list backup showing the backup pieces that need to be copied across Host B

5. Creating the init.ora & administration directories for the duplicate database.


Host B(AUX)


Create the pfile [initAUX.ora] parameter file in the $ORACLE_HOME/dbs directory for the auxiliary database. An example is shown below (figure 5a) with bare minimum settings. Note you may require to set parameters which are the same as your production database (refer to you primary init.ora)

# +----------------------------------------+
# | FILE : initAUX.ora                     |
# | DATABASE NAME : AUX                    |
# +----------------------------------------+
# Set the below to location of the clone Duplicate database / name of
# clone database.

audit_file_dest =/oradata/AUX/adump
background_dump_dest =/oradata/AUX/bdump
core_dump_dest =/oradata/AUX/cdump
user_dump_dest =/oradata/AUX/udump
db_name ="AUX"
instance_name =AUX

cluster_database=false (in case the production is a rac environment)


# Set the below to the location of the duplicate clone control file.

control_files =('/oradata/AUX/control01.ctl','/oradata/AUX/control02.ctl','/oradata/AUX/control03.ctl')



# Set the below for the from and to location for all data files / redo
# logs to be cloned.

db_file_name_convert =("/oradata/PROD/", "/oradata/AUX/")
log_file_name_convert =("/oradata/PROD/", "/oradata/AUX/")
#Set the below to the same as the production target

undo_management =AUTO
undo_retention =10800
undo_tablespace =UNDOTBS1
db_block_size = 8192
compatible = 10.2.0.1.0
     Figure 5a - Sample initAUX.ora with minimal settings

Following the creation of the initAUX.ora startup nomount the auxiliary instance.

[oracle@linux]export ORACLE_SID=AUX

[oracle@linux] sqlplus '/as sysdba'

SQLPLUS> startup nomount;
Figure 5b - startup nomount the AUX instance.


6. Ensuring SQL*NET connections to primary database and RMAN catalog are working.


Host B(AUX)

Ensure the production target database is open or at least mounted. If using a catalog database this must also be open. Test your SQL*NET connections: From Host B you must be able to connect to the primary DB as sysdba and make an rman connection to RMAN. Perform a basic test using sqlplus. When you have successfully connected exit sqlplus and move onto the next step.

[oracle@linux]% sqlplus ‘sys/oracle@PROD as sysdba’

[oracle@linux]% sqlplus rman/rman@RMAN   (not mandatory)
     Figure 6a - SQL*NET connections

7. Prepare RMAN duplicate script.


In a working directory on Host B create an RMAN script file duplicate.rcv. The example below (figure 7a) shows the command for a complete duplicate (figure 7b) skips the tablespaces which are not required in the duplicate and (figure 7b) provide the syntax required for a point in time duplicate.

run {
  allocate auxiliary channel C1 device type disk;
  duplicate target database to AUX;
}
     Figure 7a - Sample duplicate command.

run {
  allocate auxiliary channel C1 device type disk;
  duplicate target database to AUX skip tablespace ABC, XYZ;
}
     Figure 7b- Sample duplicate script omitting optional tablespaces;

run {
  set until time "to_date('Jan 01 2000 12:00:00','Mon DD YYYY HH24:MI:SS')";
  allocate auxiliary channel C1 device type disk;
  duplicate target database to AUX;
}
      Figure 7c- Sample duplicate script to a point in time.

8. Execute the RMAN script.


Start RMAN, connect to the production target, the catalog instance and also the auxiliary clone. Run the RMAN duplicate script as shown below. Before doing this ensure that the Oracle SID environment variable is set to the duplicate clone database.

[oracle@linux] export ORACLE_SID=AUX

[oracle@linux] rman target sys/sys@PROD catalog rman/rman@rman auxiliary /

RMAN> @duplicate.rcv

Database cloning with Hotbackup

Hi
     When you create a clone database with hotbackup then you follow these steps.

Introduction
This document gives you a detailed flow of how to backup the database in a 24x7 operation and use it for cloning a Development or Test database. By using the System switching of Log files option, it reduces the amount of archive logs to be applied and reduces the time of recovery (the goal).Most sites running Oracle databases need the latest production databases to be cloned for the development and test teams to work on. These sites need to be refreshed periodically with the production database and Application. Most DBAs use Cold Backup procedures to clone a database. Although cold backups are the most common backup procedures for database cloning, there may be situations where no downtime is available. Hot Backups can be performed when the database is up and in Archive log mode.


Scope

This document explains, in details, about how to perform user managed cloning of a active production database into test/development environment. It does not take into account the process of cloning using the Recovery Manager (RMAN) utility provided by Oracle.

Definitions and Assumptions

Source Database: The active production instance/database to be cloned.
Target Database: The cloned database, typically a test/development database.

Cloning steps



We need to make sure that all the present online logs are switched and archived, so that the time to do the media recovery to the cloned database is as small as possible.
Query the number of log groups that exists in the database and switch as many times as there are log groups.

Switching Logs

Code :
Select group#,archived,status from v$log;
 
GROUP#     ARCHIVED STATUS
1           YES       INACTIVE
2           NO         CURRENT
We can see from the example above, we need to switch logs to archive the online logs.

Code :
alter system switch logfile;
System altered.
Make sure that no log group shows a “STALE” status.


Create the destination directory structures as you would like to move the data files and redo log files. Also create the dump directory to hold the target database dumps (udmp, bdump cdump, adump etc).
Let’s note down the last archive log file from the archive log destination directory or from the alert log and then do another

Alter system switch logfile;

This would give us the current log that got archived by switching and also a
checkpoint occurs. Remember that switching leads to check pointing and check pointing not necessarily need lead to a log switch. So the data files all get consistent since the current scn’s are stamped. We do the switch to the number of log groups we have. That means the first archive log file that was switched might be your full file size and the subsequent ones would have lesser size depending on the data.


The next step is to copy all the data files of the source database to the destination database directories.
Before starting to copy the files of a particular tablespace, we need to put that tablespace into hot backup mode.
By putting a tablespace into hot backup mode, we will ensure two things.
1) The first time a block is changed in a data file that is in hot backup mode, the entire block is written to the redo log files, not just the changed bytes. Normally only the changed bytes (a redo vector) are written. In hot backup mode, the entire block is logged the first time. This is because you can get into a situation where the process copying the data file and DBWR are working on the same block simultaneously.
2) The data file headers which contain the SCN of the last completed checkpoint are not updated while a file is in hot backup mode. This lets the recovery process understand what archive redo log files might be needed to fully recover this file.
To limit the effect of this additional logging, you should ensure you only place one tablespace at a time in backup mode and bring the tablespace out of backup mode as soon as you have backed it up. This will reduce the number of blocks that may have to be logged to the minimum possible.
List out all the tablespaces present in the system and their corresponding data files.

Destination Directory structure creation

Copy source database files to the target

Code :
select tablespace_name,status,contents from dba_tablespaces
 
TABLESPACE_NAME      STATUS CONTENTS
SYSTEM               ONLINE PERMANENT
UNDOTBS1            ONLINE UNDO
SYSAUX               ONLINE PERMANENT
TEMP                   ONLINE TEMPORARY
USERS                  ONLINE PERMANENT
FLIRT                   ONLINE PERMANENT
6 rows selected.
 
select tablespace_name,file_name from dba_data_files order by tablespace_name;
TABLESPACE_NAME          FILE_NAME
FLIRT             C:\FLIRT\DBFILES\FLIRT01.DBF
SYSAUX          C:\FLIRT\DBFILES\SYSAUX01.DBF
SYSTEM          C:\FLIRT\DBFILES\SYSTEM01.DBF
UNDOTBS1       C:\FLIRT\DBFILES\UNDOTBS01.DBF
USERS            C:\FLIRT\DBFILES\USERS01.DBF
5 rows selected
Now put each tablespace into hot backup mode, copy it’s corresponding data files to the destination directory, and then bring out the tablespace from the hot backup mode, one tablespace at a time.
Alter tablespace FLIRT begin backup;
!copy C:\FLIRT\DBFILES\FLIRT01.DBF C:\VALEN\DBFILES\FLIRT01.DBF
Alter tablespace FLIRT end backup;
It is better to do the above exercise using a script, so that manual intervention, and hence, chance of committing an error, is also less.
Following is a script that you can use to generate a hot backup copy script from any database
set serveroutput on
set heading off
set feedback off
spool c:\scripts\backup.sql
declare
fname varchar2(55);
tname varchar2(55);
tname1 varchar2(55);
cursor tspaces is
select tablespace_name,file_name from v$datafile,sys.dba_data_files
where enabled like '%WRITE%' and file# = file_id order by 1
begin
dbms_output.enable(32000);
dbms_output.put_line('spool hotback');
open tspaces;
fetch tspaces into tname,fname;
tname1 := tname;
dbms_output.put_line('alter tablespace '||tname||' begin backup;');
while tspaces%FOUND loop
if tname1 != tname then
dbms_output.put_line('alter tablespace '||tname1||' end backup;');
dbms_output.put_line('alter tablespace '||tname||' begin backup;');
tname1 := tname;
end if;
dbms_output.put_line('!copy '||fname||' c:\VALEN\DBFILES\');
--Change the line above line with o.s specific copy command.
fetch tspaces into tname,fname;
end loop;
dbms_output.put_line('alter tablespace '||tname1||' end backup;');
close tspaces;
dbms_output.put_line('spool off');
end;
/
spool off
set heading on
set feedback on
set serveroutput off
 
Comments 3 Comments
  1. simply_dba's Avatar
    Switch logs again
    Once again, once the copy is complete, switch log groups the required number of times. In this way we need to copy over only those archive files starting with the ones that we noted down when we started the log switch to the ones we have when we did the log switch after the backup. These would be very few and hence the recovery would also be faster when we apply these archive files. We would also have a set of archive files that we are sure of and consistency can thus be assured.
    Backup the Control File.
    Now we need a control file creation script for the target database. The best way to achieve this is to backup the source control file to trace with the following command.
    Code :
    alter database backup controlf ile to trace;
    Database altered.
    Copy the appropriate archive logs and online redo logs to the target location.
    Prepare Initialization Parameter File
    Make appropriate changes to the initialization parameter file of the target db to reflect the new file locations and new database. Create appropriate target dump locations (adump, bdump, udump etc).
    Creating Service and control files in target
    Set the sid to the target database. If the target host is windows, then you will need to create database service control with the oradim command. Use the following syntax to create the service. Oradim –new –sid <target db name> -intpwd <sys password> -startmode manual start a sqlplus session as sysdba and start the instance in nomount mode with target init file. Open the control file trace backup. Towards the end, you’ll find controlfile creation statement with resetlogs option .Following is an example:
    CREATE CONTROLFILE reuse DATABASE "FLIRT" RESETLOGS ARCHIVELOG MAXLOGFILES 16 MAXLOGMEMBERS 3 MAXDATAFILES 100 MAXINSTANCES 8 MAXLOGHISTORY 2920 LOGFILE GROUP 1 'C:\FLIRT\REDO1\REDO01.LOG' SIZE 5M, GROUP 2 'C:\FLIRT\REDO2\REDO02.LOG' SIZE 5M -- STANDBY LOGFILE DATAFILE 'C:\FLIRT\DBFILES\SYSTEM01.DBF', 'C:\FLIRT\DBFILES\UNDOTBS01.DBF', 'C:\FLIRT\DBFILES\SYSAUX01.DBF', 'C:\FLIRT\DBFILES\USERS01.DBF', 'C:\FLIRT\DBFILES\FLIRT01.DBF', 'C:\FLIRT\DBFILES\DGOD01.DBF' CHARACTER SET WE8MSWIN1252 ;
    Change the first line of the statement to look like this :
    CREATE CONTROLFILE set DATABASE "VALEN" RESETLOGS ARCHIVELOG ……..
    Also change the file locations of the database mentioned in the statement to reflect the target file location. After all the changes to the statement, it should look like following :
    CREATE CONTROLFILE set DATABASE "VALEN" RESETLOGS ARCHIVELOG MAXLOGFILES 16 MAXLOGMEMBERS 3 MAXDATAFILES 100 MAXINSTANCES 8 MAXLOGHISTORY 2920 LOGFILE GROUP 1 'C:\valen\REDO1\REDO01.LOG' SIZE 5M, GROUP 2 'C:\valen\REDO2\REDO02.LOG' SIZE 5M -- STANDBY LOGFILE DATAFILE 'C:\valen\DBFILES\SYSTEM01.DBF', 'C:\valen\DBFILES\UNDOTBS01.DBF', 'C:\valen\DBFILES\SYSAUX01.DBF', 'C:\valen\DBFILES\USERS01.DBF', 'C:\valen\DBFILES\flirt01.DBF', 'C:\valen\DBFILES\DGOD01.DBF' CHARACTER SET WE8MSWIN1252 ;
    Go the sqlplus session and execute the above (changed) controlfile creation statement to create the controlfiles. Controlfile should be created without any errors.
    Apply Media Recovery
    Now you need to apply media recovery to make the database consistent. Execute the following statement.
    RECOVER DATABASE USING BACKUP CONTROLFILE;
    You may need to apply the online redo logs to make the media recovery complete. After media recovery is complete open the database in restelogs mode.
    Code :
    Alter database open resetlogs;
    Add tempfiles to the temporary tablespaces.
    Code :
    ALTER TABLESPACE TEMP ADD TEMPFILE
    'C:\valen\DBFILES\TEMP01.DBF'
    SIZE 20971520 REUSE AUTOEXTEND OFF;