Vous êtes sur la page 1sur 10

g:\prints\ebs_clone\clone document.

txt
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PRODUCTION HOT CLONE:
++++++++++++++++++++

clone from production to development

-Take the backup of application binaries as well as database backup.


-Mount the backups to the target side, if it is not mounted then do the scp.
-Create blackouts on target side and send an outage email to business users that
this instance is going to clone.
-shutdown the application services, shutdown the database and startup restrict-mode
drop the database, and take backup if required (export-import, pfile, context_file
and other config files) sometimes it depends on your project to project)

untar the binaries (db) and prepare the pfile, in pfile keep all the parameters
which is there, just add two parameters (db_file_name_convert and
log_file_name_convert)which actually convert the filesystem from source to target,
and then we do startup nomount (which starts the instance and background processes)
Now we will run rman duplicate
rman connect auxiliary and run command allocate channels
duplicate target database to name of the database along with the backup location
and then release channels

what internally rman duplicate will do is?

-it will restore the controlfile from the backup.


-it will mount the database internally (alter database mount).
-it will restore the database.
-it will recover the database.
-and then it will open the database with resetlogs.

when you open the database with resetlogs, incarnation of the database will be
happen, it means new logfile sequence number will be assigned and it will be set to
1 and the redologfile will be given a new timestamp, and new scn number will be
assigned and then your datafile and controlfile will be sync.

untar binaries for application side, and then go to common_top/clone/bin and fire
perl adcfgclone.pl appsTier.
fire perl adcfgclone.pl appsTier context_file=<give cloned instance contextfile>

Post Clone Steps:


1)Change the APPS password
2)Cancel the scheduled requests
3)change the java color and banner
4)Updating workflow mail status
6)Cleanup the nodes table by running
EXEC FND_CONC_CLONE.SETUP_CLEAN;
7)Run autoconfig on both the tiers.
8)Etc.

Source Side:
run preclone scripts on dbtier as well as application tier (every time not
necessarily to run)
take the backup of application binaries as well as database backup
Mount the backups to the target side, if it is not mounted then do the scp

Target Side:
1. create blackouts on target side and send an outage email to business users that
this instance is going to clone, shutdown the application services, shutdown the
database and startup restrict-mode drop the database, and take backup if required
(export-import, pfile, context_file and other config files) sometimesit depends on
your project to project)

2.untar the binaries (db)Configure RDBMS oracle_home adcfgclone.pl (if hot backup
dbTechStack)
Prepare the pfile, in pfile keep all the parameters which is there, just add two
parameters (db_file_name_convert and log_file_name_convert) and then we do startup
nomount (which starts the instance and background processes)

3. Configure pfile of clone environment and two parameters


db_file_name_convert
log_file_name_convert
db_name
control_files
never took pfile from production, take any other instance and make a clone pfile.

4. Configure network connectivity with source and target ( check ifile tnsnames.ora
on target )

5. all the servers should be pinged


tnsping ping should be worked on source, target and rman catalog if used (all
should work)
tnsing prod
tnsping uat/dev/test (clone)
tnsping rman
Always put tnsnames.ora entries should be production as well as clone instance.
producation database always uses ifile.

6. check the connectivity and start the database in nomount state with newly pfile.

7. connect rman
RMAN> rman target sys/****@PROD catalog rman/rman@RMU1 auxiliary
sys/*****@DEV/UAT/TEST (CLONE) > /home/clone.log

Three below messages will appear:


RMAN> target connected
RMAN> catalog connected
RMAN> auxiliary connected ( not mounted)

8. fire duplicate command in rman

RMAN> duplicate target database to "clone" ( HCU1, DEV, UAT );


RMAN> duplicate target database to clone from active database;
RMAN> duplicate target database to clone from '/u01/rman/dev';
* duplcate databae command will take 6 - 7 hours depends on size of db
* application will be take 3 - 4 hours

how you came to know that your all transactions made upto that time?
It depends on what type of backup you take? whether you take rman backup-base
location or you take backup using set until time command till that what time you
taken backup

cloning of 12.2
==============:
step.1 Gather Source Information

General
During the cloning process, you will be required to provide the passwords from the
SOURCE system for the following users:
Database: SYSTEM
Database/EBS: APPS
EBS: Weblogic Admin

step.2
Database
Gather Database space requirements
In this example, the database binaries, archivelogs, redologs, and datafiles are on
/u01, /u02, /u03, and /u04, and require 17G, 176M, 8.1G, and 880G respectively.
Please adjust for the system appropriately.

step.3
Locate Database backup and space requirements

The source backup in this example is in the �/backup/rman/20170216_234406� folder


and require 132G of space.
Please adjust for the source system appropriately

step.4
Apps
Gather Applications space requirements

In this example the EBS Apps are installed on /u01 and require 137G of space.
Please adjust for the system appropriately.
Determine the RUN filesystem
Login as the EBS applications software owner and source the run file system.
In this case the EBS Applications owner is �applmgr� and the run file system is on
�/u01/EBS/fs1�
Please adjust accordingly for the source system.

step.5
Locate EBS Applications backup and space requirements
The source backup in this example is in the �/backup/rman/20170216_234233� folder
and require 42G of space.
Please adjust for the source system appropriately

step.6
Prepare Target systems
Note: During the following steps, it is advised to perform them in a VNC or Screen
session to prevent from possible disconnects interrupting the cloning process.
Shutdown both the Apps and the Database from the clone system that will be
replaced.

step.7
Database
Prepare location to copy backups to the target system
Create a location to store the backups.
Clear out the location if needed.
Copy the backup to the prepared location
This example has the target backup location in the �/backup/rman� folder. Rsync was
used to copy the backups from the Source backup location to the Target backup
location.
Please adjust accordingly for the source system.
step.8
Backup files
If cloning over an existing system, copy the context file and init<Target SID>.ora
file to a safe location outside the standard directory structure. The database user
owner�s home directory is usually a safe place.

step.9
Collect filesystem information
Confirm there is enough space for the restoration of the backups.
Note: If you are setting the system up for the first time, make sure the chosen
file system layout will have enough space. It is also recommended to keep the file
system on the target the same or as close to the same as the source system.
In this example the /u01, /u02, /u03 all have sufficient space. The /u04 will be a
little close as the needed space is 880G and the total space of the target storage
location is only 886G (6G of space will be left over)

step.10
Clear old system files
Delete the old database data files, leaving the folder structure intact.
Remove the old ORACLE HOME binaries (in this case they are under /u01)
You may need to perform this step as root

step.11
Apps
Prepare location to copy backups to the target system
Create a location with enough space to store the backups.
Clear out the location if needed.
Copy the backup to the prepared location
This example has the target backup location in the �/backup/rman� folder. Rsync was
used to copy the backups from the Source backup location to the Target backup
location.
Please adjust accordingly for the source system.

step.12
Collect filesystem information
Determine the EBS apps base.
If the system already has an EBS R12.2 installation, you can find the EBS base by
sourcing the RUN file system
In this example, the EBS base is �/u01/EBS�
If this is the first time the system is being setup, you will need to create the
folder.
Note: When setting up a new target system, it is preferred to use the same
filesystem layout as the Source.
Backup the fs_ne file system and remove the fs1 and fs2 file systems.

step.13
Go to the oraInventory�sContentsXML folder and edit the inventory.xml file
Delete all HOME references to the old EBS clone (You can use the REFHOME LOC to
find which HOMES to remove)
This is how the file should look after deleting the old HOME references

step.14
Clone
Note: During the following steps, it is advised to perform them in a VNC or Screen
session to prevent from possible disconnects interrupting the cloning process.
Database
Restore binaries
Extract the Oracle Home binaries from the source backup

step.15
Prepare Binaries for EBS use
Run Rapid clone for the database tech stack. (adcfgclone.pl dbTechStack<context
file>)
You can provide the saved CONTEXT_FILE to auto answer questions about the database.
Enter the APPS password from the source system.

step.16
Copy the saved init<SID>.ora file back to its original location ($ORACLE_HOME/dbs)

step.17
Restore Database
Enter sqlplus/ as sysdba.
Startup the database with startup nomount
Exit sqlplus
Find the absolute path of the copied backups
Enter RMAN with connecting to the auxiliary database (the auxiliary database will
be the cloned database)

step.18
Run the following command (can be multiple lines or single line), replacing the
<NEW SID> with the desired SID and the <BACKUP LOCATION> found earlier.
DUPLICATE DATABASE TO <NEW SID> BACKUP LOCATION '<BACKUP LOCATION>'
NOFILENAMECHECK;
In this example, the command will be as follows:
DUPLICATE DATABASE DEV BACKUP LOCATION '/backup/rman/20170225_024410'
NOFILENAMECHECK;

step.19
Once the duplicate database is complete, exit RMAN
Enter sqlplus as sysdba
Shutdown the database
Startup the database
Create an spfile using the following command: create spfile from pfile;
Shutdown the database again (this is to start using the new spfile)
Startup the database

step.20
Complete clone steps
Cleanup the nodes table by running the following command as the apps user:
sqlplus apps/<APPSSPASS>
EXEC FND_CONC_CLONE.SETUP_CLEAN;
COMMIT;
EXIT;

step.21
Run autoconfig (adautocfg.sh) to complete the clone steps for the database
The APPS password will be the one from the SOURCE system

step.22
Run Post-Clone steps that can be executed before the apps are cloned. This can be
thins like, but not limited to:
1)Unlocking the APPS user
2)Setting profile limits
3)Putting the concurrent requests on hold
4)Updating workflow mail status
5)Etc.
Please see the Attached file for post clone steps

step.23
APPS
Restore binaries
Extract the file system that is the RUN file system from the source system (in this
example the RUN file system is fs1) to the EBS base
Delete the FMW_Home and inst directories from the newly extracted file system.

step.24
Clone the APPS Tier (RUN file system)
Run rapid clone on the apps tier by issuing adcfgclone.pl appsTiercommand.
Important! - When running the clone for the PATCH file system, you must NOT have
the run file system sourced. If you have sourced the run file system, please start
a new session without sourcing the run file system.
Enter the APPS password used in the Source system.

step.25
You are creating the RUN file system.
Enter the Hostname for the Applications tier for the Hostname.
Enter the SID used when duplicating the database (this case is DEV)
Enter the Database server hostname (do not include the domain portion), this
defaults to the same as the Apps Tier Hostname entered above, so you will probably
need to change this.
Make sure the Database Domain is correct. (you can just click enter/return if it is
or update it if it is wrong)
Enter the system Base Directory (/u01/EBS in this case)
Do NOT preserve the Display
Accept the default new display

step.26
Prepare the new RUN file system to create the PATCH file system
In a new window, source the new environment
Start the admin servers using �adadminsrvctl.sh start�

step.27
Run the rapid clone pre-clone script �adpreclone.pl appsTier�

step.28
Once the clone is completeshutdown the admin servers (you can use adadminsrvctl.sh
stop or adstpall.sh)
Copy the run file system EBSapps folder to the patch file system directory (in this
example fs1/EBSapps to fs2/)
Find the CONTEXT_FILE from the RUN file system for use later

step.29
Clone the APPS Tier (PATCH file system)
In the original window, run the clone again, this time for the patch file system.
Important! - When running the clone for the PATCH file system, you must NOT have
the run file system sourced. If you have sourced the run file system, please start
a new session without sourcing the run file system.
Provide the full path of the RUN file system�s CONTEXT FILE.
Choose a port for the patch file system to use, this cannot be the same port as the
RUN file system.

step.30
Once completed source the RUN file system.
Update the sitename in the CONTEXT_FILE to contain the clone date
step.31
Start the Apps Tier (adstrtal.sh)
Run remaining post clone steps.

High-level step clone process with AD and TKX delta6


=================================================:

1. execute the adpreclone.pl dbtiger and appsTier


2.Copy the database and applications files (run filesystem) from source to target
3.configure the database tier on the target server
4.configure the applcation tier on the run edition
5.copy the run editon to the patch edition
6.configure the application tier with patch edition

High-level steps clone process with AD and TKX Delta7

1.execute the adpreclone.pl on dbtier and appsTier.


2.copy the database and applcation files (run file system) from source to target.
3.configure the database tier on the target server.
4.configure the applcation tier on the run edition with the dualfs option.

Note:
When using the dualfs option, you don't have to copy the patch file system from the
run file system. Rapid clone will copy the patch file system and configure both
file systems.

adpreclone.pl operations:
======================:

* This script will collect the information from the database, and read the
configuration files from the existing configuration files, and the template files
based on the existing configuration. These template files will be sused ata a lated
stage for creating a new clone environment on the target server.

* Adpreclone.pl will prompt APPS password on the dbTier, but it doesn't require the
APPS password on appsTier (in 12.2 it will ask weblogic password on appsTier)

when you run adpreclone.pl dbTier . This will run in two steps TECHSTACK and
DATABASE.

TECHSTACK:

-It will create directories in $ORACLE_HOME/appsutil/clone

*data ===> info related to datafiles and other requried cloning files
*oui
*jlib ===> java related libray files
*jre
*dbts ===> driver files

-Creates driver files at ORACLE_HOME/appsutil/driver/instconf.drv


-Converts inventory from binary to xml, the xml file is located at
$ORACLE_HOME/appsutil/clone/context/db/Sid_context.xml

DATABASE:
-It creates database controlfile script and datafile location info file at
$ORACLE_HOME/appsutil/template

Two files:

dbfinfo.lst ===> dbf information file describing database (location of dbf files)
adcrdbclone.sql ===> script that recrates the controlfile

-Generate db creation driver file at ORACLE_HOME/appsutil/clone/data/driver

data.drv ===> template file driver

-Copy JDBC Libraries at ORACLE_HOME/appsutil/clone/jlib/classes12.jar and appsutil

adpreclone/adcfgclone options on dbTier

dbTier-------------------------configure database+database techstack


dbTechStack--------------------configure dbTechstack only
database-----------------------configure techstack
dbconfig-----------------------configure database but the db should up and running
addracnode---------------------scale up the RAC instances

adpreclone/adcfgclone options on appsTier

appsTier----------------------configure appltop+atTeckStack
apTeckStack-------------------configure dev10g+fmw+wlsconfig+ohsconfig
dev10gHOme--------------------configure
fmwHome-----------------------configure
wlsconfig---------------------configure
ohsconfig---------------------configure
appltop-----------------------configure

adcfgclone.pl operations:

- This script should be exectued once after copying the required files from source
system.
- This script will promt for various inputs, and these inputs will be used for
configuring the target sever.
- Below is the sequence that adcfgclone.pl will perform:

Rapid clone database tier configurations: database tier

CREATE DB CONTEXTFILE
REGISTER ORACLE_HOME IN INVENTORY
RELINK AND CONFIGURE ORACLE_HOME
RECREATE CONTROLFILES AND CONFIUGRES DATABASE
START DB AND LISTENER

Rapid clone application tier configuration: application tier

CREATE APPLICATION CONTEXTFILE


REGISTER FMW AND 10.1.2 HOME IN INVENTORY
RELINK AND CONFIGURE AS AND FMW ORACLE_HOME CONFIGURE APPL_TOP AND CREATE INST_TOP
START APPLCATION SERVICES
g:\prints\ebs_clone\clone prerequisite.txt
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Prerequisite Steps:

1. Make a note of the current Archived log number: Because the restored files will
require recovery, some archive logs will be needed. This applies even if you are
not intending to put the cloned database into archive log mode. Command to do so
is:
SQL> select max(first_change#) chng from v$archived_log;
Make sure to record this number so you can use it after hot backup is taken.
2. Take hot backup of Production database.
3. Ensure following commands are run since it is important for correct archive logs
to be copied over: SQL> alter system switch logfile; SQL> alter system archive log
current;
4. Identify which archive log files are required. When run, the following query
will ask for a change number. This is the number noted from Step 1.
SQL> select name from v$archived_log where first_change# >= &change_no order by
name;
5. Create the clone control file Create a control file for the new database. To do
this, connect to the source database and request a dump of the current control
file. From sqlplus:
SQL> alter database backup controlfile to trace;
6. These steps are important to recover cloned database correctly

g:\prints\ebs_clone\cloning questions.txt
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
What is cloning and why is it required?
� Cloning is the process of creating an identical copy of the Oracle application
system.
It is required due to following reasons
� Creating a test copy of your production system before upgrading.
� Moving an existing system to a different machine.
� To test some patches
� Creating a development copy of your environment to be used by the developers.

What is the location of adpreclone.pl for RDBMS_ORACLE_HOME?


$RDBMS_ORACLE_HOME/appsutil/scripts/$CONTEXT_NAME

What is the location of adcfgclone.pl for RDBMS_ORACLE_HOME?


$RDBMS_ORACLE_HOME/appsutil/clone/bin

What is the location of adpreclone.pl for applmgr user?


$COMMON_TOP/admin/scripts/

What is the location of adcfgclone.pl for applmgr user?


$COMMON_TOP/clone/bin

How do we find adpreclone is run in source or not ?


If clone directory exists under RDBMS_ORACLE_HOME/appsutil for oracle user and
$COMMON_TOP for applmgr user.

When do we run FND_CONC_CLONE.SETUP_CLEAN?

How often Do you clone?


Ans: Cloning happens biweekly or monthly depending on the organization requirement.
What are the scripts do you use while Apps cloning?

� adpreclone.pl prepares the source system and adcfgclone.pl configures the target
system.
� adpreclone.pl is located in $COMMON_TOP/admin/scripts/contextname directory and
adcfgclone.pl located in $COMMON_TOP/clone/bin.
� Adpreclone.pl collects information about the database.
� It also creates generic templates of files containing source specified hardcore
values.

Does clone preserve the patch history?


� Yes, Rapid clone preserves the patch history in following locations
� RDBMS ORACLE_HOME: preserves the OUI oraInventory.
� iAS ORACLE_HOME: preserves the OUI oraInventory
� 806 ORACLE_HOME: preserves the patch level and Oracle inventory
� APPL_TOP and Database: preserves the patch level and history tables.

g:\prints\ebs_clone\postclone steps.txt
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Postclone steps

1)Change profile option values


2)dba directories
3)change password of custom user,standard user(FNDCPASS),SYSTEM USER
3)change parameters in xml file like
s_applcsf/s_applout/s_appllog/s_cphost/s_jsp_main_mode/s_appltmp/s_appltmp/s_login/
s_lock_pid/s_web_pid/ and many more.
4)archive log disabled for non prod and it depends on the requiement
5)SSO registration
6)workflow mailer configuration
7)db links
8)export of any schema
9)color change
10) third party tools
11)softlinks that are pointing to production.
12)printer settings
13)Upload Responsibilities if any
14)Do sanity and release instance for user access.

Vous aimerez peut-être aussi