Skip to main content

Cloning an Oracle Home 11.2.0.4

Perform the following to clone an Oracle home:
  1. Verify that the installation of Oracle Database to clone is successful.
    You can do this by reviewing the installActionsdate_time.log file for the installation session, which is typically located in the /orainventory_location/logs directory.
    If you install patches, then check their status using the following:
    $ cd $ORACLE_HOME/OPatch
    
    Include $ORACLE_HOME/OPatch in $PATH
    $ opatch lsinventory
    
  2. Stop all processes related to the Oracle home. See "Stopping Existing Oracle Processes" for more information about stopping the processes for an Oracle home.
  3. Create a ZIP file with the Oracle home (but not the Oracle base) directory.
    For example, if the source Oracle installation is in the /u01/app/oracle/product/11.2.0/dbhome_1, then you zip the dbhome_1 directory by using the following command:
    # zip -r dbhome_1.zip /u01/app/oracle/product/11.2.0/dbhome_1
    
    Do not include the admin, fast_recovery_area, and oradata directories that are under the Oracle base directory. These directories are created in the target installation later, when you create a new database there.
  4. Copy the ZIP file to the root directory of the target computer.
  5. Extract the ZIP file contents by using the following command:
    # unzip -d / dbhome_1.zip
    
  6. Repeat steps 4 and 5 for each computer where you want to clone the Oracle home, unless the Oracle home is on a shared storage device.
  7. On the target computer, change the directory to the unzipped Oracle home directory, and remove all the .ora (*.ora) files present in the unzipped $ORACLE_HOME/network/admin directory.
  8. From the $ORACLE_HOME/clone/bin directory, run the clone.pl file for the unzipped Oracle home. Use the following syntax:
    $ORACLE_HOME/perl/bin/perl clone.pl ORACLE_BASE="target_oracle_base" ORACLE_HOME="target_oracle_home"
    OSDBA_GROUP=OSDBA_privileged_group OSOPER_GROUP=OSOPER_privileged_group -defaultHomeName
    
    1. For example:
    1. $ORACLE_HOME/perl/bin/perl clone.pl ORACLE_BASE="/u01/app/oracle/" ORACLE_HOME="/u01/app/oracle/product/11.2.0/dbhome_1" OSDBA_GROUP=dba OSOPER_GROUP=oper -defaultHomeName
    2. The following configuration scripts need to be executed as the "root" user.
      /u02/u02/app/oracle/product/11.2.0.4/dbhome_1/root.sh
      To execute the configuration scripts:
          1. Open a terminal window
          2. Log in as "root"
          3. Run the scripts
      Example as below
  9. Oracle Universal Installer starts, and then records the cloning actions in the cloneActionstimestamp.log file. This log file is typically located in /orainventory_location/logs directory.
  10. To configure the connection information for the new database, run Net Configuration Assistant:
    $ cd $ORACLE_HOME/bin
    $ ./netca
    
  11. To create a new database for the newly cloned Oracle home, run Database Configuration Assistant:
    $ cd $ORACLE_HOME/bin
    $ ./dbca
    

Comments

Popular posts from this blog

How To Create LVM Using vgcreate in Linux

Logical Volume Management (LVM) creates a layer of abstraction over physical storage, allowing you to create logical storage volumes. With LVM in place, you are not bothered with physical disk sizes because the hardware storage is hidden from the software so it can be resized and moved without stopping applications or unmounting file systems. You can think of LVM as dynamic partitions. For example, if you are running out of disk space on your server, you can just add another disk and extend the logical volume on the fly. Below are some advantages of using Logical volumes over using physical storage directly: •Resize storage pools: You can extend the logical space as well as reduce it without reformatting the disks. •Flexible storage capacity: You can add more space by adding more disks and adding them to the pool of physical storage, thus you have a flexible storage capacity. •Use of striped, mirrored and snapshot volumes: Striped logical volume that stripes data across two or ...

EBS Standby Role Tranistion using standby database and standby application Tier

 Role Transitions A database can operate in either a primary or standby role - these roles are mutually exclusive. Oracle Data Guard enables you to change these roles dynamically by issuing SQL commands, and supports the following transitions: Switchover Allows the primary database to switch roles with one of its standby databases. There is no data loss during a switchover. After a switchover, each database continues to participate in the Oracle Data Guard configuration with its new role. Failover Changes a standby database to the primary role in response to a primary database failure. The following role transitions are discussed: 6.1 Performing a Switchover 6.2 Performing a Failover 6.3 Performing a Switchback to the Primary Following A Switchover/Failover Each of these three transitions requires some application configuration to be performed. Most of the application configuration step...
TRANSPARENT APPLICATION FAILOVER FOR RAC RAC provides near-continuous availability by hiding failures from end-user clients and application server clients. This provides continuous, uninterrupted data access. Transparent Application Failover (TAF) is what applications use to sync up with Oracle RAC availability. TAF in the database reroutes application clients to an available database node in the cluster when the connected node fails. Application clients do not see error messages describing loss of service. if the users connection to Node 1 dies, their transaction is rolled back but they can continue work without having to manually reconnect. To get a good understanding of how the TAF architecture works, it is helpful to walk through a failover scenario where a user is querying the database to retrieve 1000 rows from the database. Assume that the user is connected to Node 1/ Instance 1. 1.      The heartbeat mechanism between the various nodes...