Cloning an Existing Oracle11g Release 2 (11.2.0.x) RDBMS Installation

-

Cloning an Existing Oracle11g Release 2 (11.2.0.x) RDBMS Installation:

 Step 1:
Make a copy of the existing (source) Oracle RDBMS installation. If the clone (target) installation is on the same server then the "cp -Rp" command could be used.

 NOTE: There should be no requirement to shutdown any databases, listeners, agents etc. that are running from the source home before copying the source installation because any processes that load the static binaries or libraries into memory should not hold a write lock.

 For example:
cp -Rp /u01/app/oracle/product/11.2.0 /u01/app/oracle/product/11.2.0_clone

NOTE: This command can be executed by either the 'root' user or the owner of the $ORACLE_HOME (For example, 'oracle'). The intention is to make sure that the ownership of the files is preserved correctly. Some files in $ORACLE_HOME/bin are owned by root and have the SUID / SGID set:

 -rws--x---   1 root     oinstall   20872 Apr 24 12:00 nmb
-rws--x---   1 root     oinstall   28720 Apr 24 11:59 nmo
-rwsr-x---   1 root     oinstall 1340408 Sep 25  2011 oradism

 so if you try to copy them as a non-root user the following errors occur:

 cp: cannot open `$ORACLE_HOME/bin/nmb' for reading: Permission denied
cp: cannot open `$ORACLE_HOME/bin/nmo' for reading: Permission denied
cp: cannot open `$ORACLE_HOME/bin/oradism' for reading: Permission denied

 However, after following the rest of the steps in this document (running OUI with the -clone option and running root.sh) the files are re-created and so there is no problem.

 Alternatively, the source installation could be packed up using the "tar" command:

 For example:
cd /u01/app/oracle/product/11.2.0 
tar -cvf /tmp/source.tar .

 and then moved to the target area (on the same server, or another server) and unpacked:

 For example:
cd /u01/app/oracle/product/11.2.0_clone 
tar -xvf /tmp/source.tar

 NOTE: As per the note above, this command can be executed by either the 'root' user or the owner of the $ORACLE_HOME (For example, 'oracle').

 IMPORTANT NOTES:
Before going to step 2, it is important to spend some time checking that the file permissions on files/directories in the target home match those in the source home. Please also check that the validity of any symbolic links has been preserved. Ensure that the links point to files/directories in the new target home, not files/directories in the source home. If necessary, re-create the links.
Also make sure that an oraInst.loc file exists, otherwise clone.pl may fail with the following errors:

 SEVERE:OUI-10036:Could not create the inventory location. You may not have permission to write to this location.
SEVERE:OUI-10180:Invalid Operating System group name specified.

 If you are cloning on AIX, make sure that the rootpre.sh script has been executed on the target server. This can be found on the Oracle11g Release 2 media.

 Step 2:
Run the following command to clone the installation with the Oracle Universal Installer (OUI):

 cd $ORACLE_HOME/clone/bin
perl clone.pl ORACLE_HOME="<target_home>" ORACLE_HOME_NAME="<unique_home_name>" ORACLE_BASE="<path_for_ORACLE_BASE>" OSDBA_GROUP=<OSDBA_privileged_group> OSOPER_GROUP=<OSOPER_privileged_group>

 NOTE: If you do not specify the OSDBA_GROUP and OSOPER_GROUP parameters, you may experience an ORA-01031: insufficient privileges error when using SQL*Plus.

 If no /etc/oraInst.loc (AIX, Linux) or /var/opt/oracle/oraInst.loc (Solaris, HP-UX) file exists on the server because Oracle has never been installed on the server before, create one. The file should contain a line like this:
inventory_loc=<path_to_oraInventory>

 For example:
inventory_loc=/u01/app/oracle/oraInventory

 If an oraInst.loc file exists on the server but is in a different location, edit the $ORACLE_HOME/clone/config/cs.properties file to add "-invPtrLoc <path>/oraInst.loc" to the clone_command_line.
This file can also be edited to add "-ignoreSysPrereqs" if required.

 The alternative method of cloning is to use the following commands:

 ./runInstaller -clone -silent -ignorePreReq ORACLE_HOME="<target_home>" ORACLE_HOME_NAME="<unique_home_name>" ORACLE_BASE="<path_for_ORACLE_BASE>" oracle_install_OSDBA=OSDBA_privileged_group oracle_install_OSOPER=OSOPER_privileged_group

 If necessary, add "-invPtrLoc <path>/oraInst.loc" or "-ignoreSysPrereqs" to the command line.

 If the server has more than one Perl version installed then it may be necessary to specify the PERL5LIB environment variable so that the versions of the Perl modules match with the Perl version used.
Note that the full path for the target $ORACLE_HOME should be provided (For example, /u01/app/oracle/product/11.2.0_clone).
Also note that the home name must be unique (that is, it must not already exist in the central inventory file <path>/oraInventory/ContentsXML/inventory.xml).

NOTE: If you are cloning on a server which already has a central inventory and the target home already exists in <path>/oraInventory/ContentsXML/inventory.xml then you should run the following command to 'detach' this home from the central inventory before performing the clone operation:

 ./runInstaller -detachHome ORACLE_HOME=<target_home>

 To clone an Oracle11g Release 2 client installation, run OUI directly:

 ./runInstaller -clone -silent -noconfig ORACLE_HOME="<target_home>" ORACLE_HOME_NAME="<unique_home_name>" ORACLE_BASE="<path_for_ORACLE_BASE>" OSDBA_GROUP=OSDBA_privileged_group OSOPER_GROUP=OSOPER_privileged_group

 Step 3:
On Unix/Linux installations, you will now need to run root.sh (as root) from the target home.

 NOTE: When running the root.sh in the clone it overwrites the files in /usr/local/bin (oraenv, coraenv, dbhome).  It does not prompt if those files are to be overwritten or give a choice (as in a clean install). These files should be backed up if used.

 Step 4:
The commands in step 2 do not create this structure Automatic Diagnostic Repository (ADR) directory structure in $ORACLE_BASE/diag in the target environment, so it is necessary to run the following command to create it:

 $ORACLE_HOME/bin/diagsetup basedir=<ORACLE_BASE> oraclehome=<ORACLE_HOME>

 Alternatively, the structure will be created when you first execute the Database Configuration Assistant (DBCA) to create a database in the target environment.

 NOTE:
* For Windows, use setup.exe (instead of runInstaller) to start OUI
* Log files are created in the central inventory (<path>/oraInventory/logs) and in the target home ($ORACLE_HOME/clone/logs)

 Step 5:
After cloning a database, the dba_libraries view contains reference to old home. because $ORACLE_HOME path has been hardcoded in file ordlib.sql and dbmssml.sql

 select library_name,file_spec from dba_libraries where file_spec is not null; --> FILE_SPEC should point to OLD HOME
@?/rdbms/admin/dbmssml.sql
alter session set current_schema=ORDSYS;
@?/ord/im/admin/ordlib.sql
select library_name,file_spec from dba_libraries where file_spec is not null; --> FILE_SPEC should point to NEW HOME

Step 6:
a relink of binaries

export ORACLE_HOME=<path_of_oracle_home>
export PATH=$PATH:$ORACLE_HOME/bin:.
$ORACLE_HOME/bin/relink all


For more details refer : (Doc ID 1221705.1)

Comments

Post a Comment

Popular posts from this blog

Guarantee Restore Point Primary-Standby Environment

-
Guarantee Restore Point Primary-Standby Environment: When we have a Data Guard environment (Primary RAC and Standby Standalone Databases) and we want to make use of restore points. We need to follow below steps. Always create a restore point on the standby database first then in Primary. The main reason for this is because the SCN of the standby must be less than the SCN of the primary in case you need to flashback your database. If we didn’t follow the step 1 then we need to rebuild the standby. 1.) Stop Managed Recovery on the Standby Database using SQL*PLUS or Data Guard Broker. $ dgmgrl sys/<Password>@<PRIM/STDBY> DGMGRL>  show database ' STDBY '; edit database 'STDBY' set state = 'APPLY-OFF'; show database ' STDBY ';   OR STDBY.SYS.SQL> select inst_id, process, status, thread#, sequence#, block#, blocks from gv$managed_standby order by inst_id; alter database recover managed standby database ca
Read more

Steps on converting a Snapshot Standby database to Physical Standby database

-
Steps on converting a Snapshot Standby database to Physical Standby database: 1) Check for database role, open mode & Restore point create by this conversion. STDBY.SYS.SQL> set serveroutput on long 2000000 longchunksize 20000 pagesize 50000 linesize 1000 set trimspool on time on timi on feedback on verify off echo off heading on; col name for a65 col scn for 9999999999999999999999 col time for a40 col guarantee_flashback_database for a30 col db_unique_name for a15 select a.name db_name, a.db_unique_name, b.instance_name, b.instance_role, a.database_role, a.open_mode, a.protection_level, a.fs_failover_status, a.dataguard_broker, a.log_mode, a.force_logging, a.flashback_on from gv$database a, gv$instance b; select name, scn, time, guarantee_flashback_database, storage_size, database_incarnation# from gv$restore_point; 2) If the standby database is a RAC setup then we need to shutdown all the instances except one on which we will be using the conversion c
Read more

Flashback Database to Restore Point in Primary-Standby Environment

-
Flashback Database to Restore Point in Primary-Standby Environment: When we have a Data Guard environment (Primary RAC and Standby Standalone Databases) and we want Flashback database to restore point. We need to follow below steps. a) Always flashback the primary database first. Then follow below step for Standby. b) On the primary, connect using RMAN and list the incarnations. c) On the standby, cancel the recovery and flashback the standby to restore point created earlier. d) On the standby, connect using RMAN and list the incarnations. e) If there is a mismatch in incarnation between primary and standby then need to reset the incarnation of standby and start recovery (Details not available in this DOC). 1)    Disable Log Transport Services to the Standby Database for the Destination serving the Standby Database on all Primary Instances: $ dgmgrl sys/<Password>@<PRIM/STDBY> DGMGRL>  show database 'PRIM '; edit database '
Read more