Search

Join this Blog for direct reference of any post into your inbox. To join just click on "Join this Site" under "Follower" then Login with your Email.*** DECLARATION: I Maintain this Blog for Helping Myself While at Work and Welcome any body Needing Help!!!.*** CAUTION: Using any of the script from this Blog may contain at Own Risk. These scripts May or May not have been Tested.***

Saturday, 12 May 2012

Planning to Clone or Duplicate Database

Here are some of the most important considerations before cloning or duplicating a database:

Same or Different Host Computer?
Cloning a database to the same host as the source requires specific steps to change the name of the database, as well as the path names of all files cloned, while cloning to a different host requires you to consider which method will be used to migrate files to that host.  In general, the source and destination computing systems must be architecturally identical and must be running essentially identical operating systems.
Same or Different Database Name?
If the database is duplicated to a different host system, you have a choice of whether or not to rename the database and whether file names will be identical to or different from those in the source database.
Note: Same database name and file structure. Be careful you cannot use same RMAN catalog to take the backup of duplicate database as the DBID is same as of Primary database DBID.
Hot (Online) Backup or Cold (Offline) Backup Clone?
If it is a requirement that the source database be cloned while it is up (hot cloning), then it is absolutely essential that the source database be operating in archivelog mode.  If the copy is being made from a hot backup, all applicable archived logs must be accounted for and must be available on the destination host system.
Sufficient storage? 
Very simply, the clone database requires exactly the identical quantity of storage as its source. The logical storage contiguity (All the tablespace storage Capacity of Production database) footprint must be adequate to accommodate each datafile object to be copied.
SELECT SUM(BYTES)/(1024*1024*1024) "SIZE IN GB" FROM DBA_DATA_FILES;
select t.tablespace, t.totalspace as " Totalspace(MB)", round((t.totalspace-fs.freespace),2) as "Used Space(MB)", fs.freespace as "Freespace(MB)", round(((t.totalspace-fs.freespace)/t.totalspace)*100,2) as "% Used", round((fs.freespace/t.totalspace)*100,2) as "% Free" from (select round(sum(d.bytes)/(1024*1024)) as totalspace, d.tablespace_name tablespace from dba_data_files d group by d.tablespace_name) t, (select round(sum(f.bytes)/(1024*1024)) as freespace, f.tablespace_name tablespace from dba_free_space f group by f.tablespace_name) fs where t.tablespace=fs.tablespace order by t.tablespace;
The above query will help to estimate the size of primary database:
Specific point-in-time or simply current time? 
If it is a requirement that the database copy be “as of” a specific point in time, consideration must be given to the availability of a sufficiently old backup and the availability of all archived logs needed to perform point-in-time recovery.
Source Media?
DUPLICATION can be undertaken from the database itself (either while running or while down), or it can be performed from full database backups stored on disk or tape.
Methods or Technique to be used? 
Surveyed below are three different techniques for cloning an Oracle database.  Each of them provides the same end result; each of them can be customized according to specific installation requirements. We can Select the method as per minimum interaction of original database and more reliable or secure.
  1. Conventional OS and SQL commands (manual or scripted)
The best way to learn the mechanics of database duplication is to perform all of the steps using operating system commands and SQL commands available to DBAs. Initially, you might want to try this with a non-critical database on a development system.  Scripting your work minimizes typographical errors and promotes functional repeatability.
Advantages
Best way to learn the mechanics of database duplication ability to implement customized functions, such as partial cloning and merge cloning ability to implement your choice of host-to-host copying function into scripts
Disadvantages
Requires ongoing maintenance
Might prove to be less reliable than other methods, especially when used unattended RMAN dup1licate Command, Split Mirror Cloning

  1. RMAN duplicate Command
The Recovery Manager’s DUPLICATE command provides a convenient, easy-to-use mechanism for database cloning. It is especially advantageous when the clone is to be made from a backup as of a specific point-in-time (“as of” clone).  RMAN quietly takes care of many details of cloning, including thorough error checking and changing the database ID (DBID) so that the cloned database can be registered and managed using an RMAN repository.
Advantages
• Procedure is documented and supported by Oracle Corporation
• Lowest maintenance solution; quickest to implement
• Extensive error checking
Disadvantages
• No built-in capabilities for movement of data from one host system to another.
• Requires availability of backup media in order to perform the clone operation.
Purpose of duplicating Database
To use backups (backup sets or image copies) of the target database to create either of the following:
·         A duplicate database, which is a copy of the target database (or a subset of the target database) with a unique DBID. Because a duplicate database has a unique DBID, it is entirely independent of the primary database and can be registered in the same recovery catalog as the primary database. Typically, duplicate databases are used for testing.
·         A standby database, which is a special copy of the primary database that is updated by applying archived redo logs from the primary database. A standby database does not get a new DBID.
To create a standby database with the DUPLICATE command you must specify the FOR STANDBY option. The DUPLICATE ... FOR STANDBY command creates the standby database by restoring a standby control file, mounting the standby control file, and then restoring and recovering backups of the target datafiles. The standby database is left mounted after duplication is complete.Note that backups of the standby database are interchangeable with backups of the primary database.
When duplicating a database that is currently in NOARCHIVELOG mode, recovery occurs with the NOREDO option. Hence, if incremental backups exist, RMAN applies only these backups to the restored files during recovery. For databases in ARCHIVELOG mode, DUPLICATE recovers by default up to the last archived redo log generated at the time the command was executed, or until a time specified with a SET UNTIL clause.
Restrictions and Usage Notes while duplicating Database
These restrictions apply to all uses of the DUPLICATE command (both for creation of a standby database and creation of a non standby duplicate database):
·         The target SCN for a DUPLICATE command cannot be before the most recent OPEN RESETLOGS. DUPLICATE to previous incarnations is not supported.
·         Issue one or more ALLOCATE AUXILIARY CHANNEL commands before executing the DUPLICATE command, or CONFIGURE automatic auxiliary channels. RMAN uses the channel configuration from the target for auxiliary channels in the following circumstances:
o        You have not manually allocated auxiliary channels.
o        You have not configured auxiliary channels.
o        The automatic target channels do not have CONNECT strings.
The DUPLICATE command does not require non-AUXILIARY channels (that is, normal target database channels).
·         You must be connected to both the target database and auxiliary instance. The auxiliary instance must be started with the NOMOUNT option, and the target database must be mounted or open. The target database cannot be a standby database.
·         If you need to duplicate a database when some backups of the target database do not exist then you must specify SKIP TABLESPACE. If you do not specify SKIP TABLESPACE, then RMAN attempts to duplicate the following:
o        All datafiles in online tablespaces, whether or not the datafiles are online.
o        All tablespaces taken offline with an option other than NORMAL. For example, RMAN attempts to duplicate tablespaces taken offline with the IMMEDIATE option. You cannot duplicate OFFLINE NORMAL tablespaces, although you can add these tablespaces manually after duplication.
If no valid backups exist of any tablespace or file, then the DUPLICATE command fails.
·         You can skip all tablespaces in the target database except the SYSTEM tablespace, undo tablespaces, and tablespaces containing rollback segments. RMAN does not check for completeness. For example, you can duplicate a data tablespace but not the tablespace containing the index for the data, or duplicate a tablespace that contains only one partition of a partitioned table.
·         If the target and duplicate databases reside on the same host, set the CONTROL_FILES parameter appropriately so that the DUPLICATE command does not generate an error because the target control file is in use.
·         If the target and duplicate databases share the same host, set all *_PATH and *_DEST initialization parameters appropriately so that the target database files are not overwritten by the duplicate database files.
·         You cannot set the DB_NAME parameter in the duplicate parameter file to a value different from the database name specified in the DUPLICATE command.
·         You cannot use the same database name for the target and duplicate databases when the duplicate database resides in the same Oracle home as the target. Note that if the duplicate database resides in a different Oracle home from the target, then its database name just has to differ from other database names in that same Oracle home.
·         If the target and duplicate databases reside on different hosts, then you must do one of the following tasks for duplication to be successful:
o        Move backups and disk copies from the target host to the duplicate host to the same location as the target host so that the path names are identical
o        Move backups and disk copies from the target host to the duplicate host to a new location (so that the path names are different), and then CATALOG them.
o        Make sure that all backups and copies (disk or sbt) on the target host are remotely accessible from the duplicate host. Make sure that the archived redo logs are available in the expected location in the new host.
·         Duplication must be done to the same platform as the source database.
·         You cannot recover the duplicate database to the current point in time, that is, the most recent SCN. RMAN recovers the duplicate database up to or before the most recent available archived log: it cannot recover into the online redo logs.
·         Specify new filenames or convert target filenames for the datafiles and online redo logs when the duplicate filenames must be different from the target filenames (as when duplicating to the same host as the primary). If you do not specify filenames for duplicate online redo logs and datafiles, then RMAN reuses the target datafile names.
·         If you want the duplicate filenames to be the same as the target filenames, and if the databases are in different hosts, then you must specify NOFILENAMECHECK.
·         If duplicating a database on the same host as the target database, do not specify the NOFILENAMECHECK option. Otherwise, RMAN may signal this error:
RMAN-10035: exception raised in RPC: ORA-19504: failed to create file 
"/oracle/dbs/tbs_01.f" 
ORA-27086: skgfglk: unable to lock file - already in use 
SVR4 Error: 11: Resource temporarily unavailable 
Additional information: 8 
RMAN-10031: ORA-19624 occurred during call to 
DBMS_BACKUP_RESTORE.RESTOREBACKUPPIECE 

1 comments:

  1. Are you monetizing your exclusive file uploads?
    Did you know Mgcash will pay you an average of $0.50 per link unlock?

    ReplyDelete