Cloning

g Oracle Databases

Author: Randy Cunningham,

Cunningham OCP
 What is Cloning?

Cloning is a term applied to any of several

methods used to duplicate
p a database, on
the same host system, or a different host
system.

Ordinarily, this is accomplished by making a

physical copy of the database datafiles.

The original database must be unaffected –

and often
often, uninterrupted – by the cloning
procedure.
What is Cloning Used For?

Benefits for both DBA and organization:

Production Support
Application Test
Upgrade/patch testing
Audit or information “freeze” requirements
Dedicated Reporting Database
Rehosting
What Else Is Cloning Used For?

The principles of cloning underlie the principles of

standbyy databases and ORACLE DataGuard.

Once you understand cloning, you understand

the key
ke principles of standby
standb databases
databases.

However,, cloning
g is not – by
y itself – a disaster
recovery solution.
Cloning Compared to…

… DataPump, exp and imp:

Requires
i a fflat fi
file, or UNIX pipes
i
New object numbers and timestamps created
Indexes are created anew:
Structure may differ
Performance might differ
Statistics are created from scratch – could
change query execution plans
Destination database may be better
better, or may be
worse than original… it won’t be the same!
Cloning Compared to…

… Database replication:

Significant
i ifi setup required
i on the source
database
Significant setup required on the destination
database
Not all object types are handled
Potential for performance impact affecting the
source database
Cloning Compared to…

… Oracle Streams:

Requires advance setup on source and

destination databases
Requires object instantiation on the destination
database
More oriented to continuous propagation than
one-time duplication
Potentially works hand-in-hand with cloning
Cloning Compared to…

… Transportable tablespaces

Conceptually and mechanically

i similar
i i to cloning
i
Source tablespaces must be read only…
compromising source database availability
Complex rules for what can be transported
Can’t transport
p SYSTEM and undo tablespaces
p
Cloning vs. Other Methods

- Cloning can have prodigious storage

requirements
- Architectures and software releases must be
identical
- Cloning can require considerable skill

+ Cloning is faster (per GB) than any other

replication
li ti method
th d
+ Cloning is most faithful to the original
+ C
Cloningg requires
q no existing
g database as its target
g
Planning to Clone

Cloning is not an ad hoc activity…

Same or different host computer?
Same or different database name?
H t or cold
Hot ld clone?
l ?
Is there sufficient storage for the target?
Specific point-in-time,
point in time or simply current?
What are the source media?
What method or tool will be used? …
Methods of Cloning

Conventional OS and SQL commands

Hot or Cold
Manual or scripted

RMAN DUPLICATE command

Hot or Cold

S lit Mi
Split Mirror Cl
Cloning
i
Hot or Cold
Using OS Commands & SQL

Advantages:
Best way to learn mechanics of cloning
Ability to implement customized functions
Ability
y to integrate
g host-to-host copying
py g

Disadvantages:
Requires ongoing maintenance
Might be less reliable than other methods
RMAN Duplicate Command

Advantages:
Documented and supported by Oracle Corp.
Corp
Lowest maintenance solution
Quickest implementation
p
Extensive error checking

Disadvantages:
Does not move data from host to host
Requires backup media to perform cloning
Split Mirror Cloning

Mirror 1 New DB

Mirror 2

Mirror 3 Mounted
Mirror 3
Split Mirror Cloning

Advantages:
Ordinarily quickest way to clone a database
Ordinarily,
Minimizes performance impact on database host
systems

Disadvantages:
Requires system administration rights (root)
Complex scripting, using vendor proprietary
commands
Cloning: Step by Step

Prepare destination (first time clone only):

Create directories (administrative and data)
Build a pfile (init.ora)
Create a p password file ((using
g orapwd)
p )
Enable network connectivity (using netca)
STARTUP NOMOUNT (to confirm instance)
SHUTDOWN ABORT
Optionally, create an spfile:
CREATE SPFILE=‘?/dbs/spfilemydb
SPFILE= ?/dbs/spfilemydb.ora
ora’ FROM PFILE;
Cloning: Step by Step

Prepare destination controlfile or script:

You can simply copy the source controlfile to the
destinations controlfile(s) when:
The source and destination are on different hosts;
Th source and
The d destination
d ti ti database
d t b will
ill h
have th
the same
name (at least initially)
Otherwise, you will need to create a control file
generation script. From the source data-base,
connected as SYSDBA, run this:
ALTER SESSION SET TRACEFILE_IDENTIFIER = ‘CCF’;
;
ALTER DATABASE BACKUP CONTROLFILE TO TRACE RESETLOGS;
Cloning: Step by Step

Prepare destination controlfile script:

Find a recent file with “CCF” in its name in the

source database UDUMP directory.

Copy it to the destination database directory:

$ORACLE_BASE/admin/<db>/create/ccf.sql

Edit the copied file with a text editor….

Cloning: Step by Step

Edit the create controlfile script (ccf.sql):

Remove prologue text from the file
Change comments from “#” to “- -” (9i only)
Add the word “SET” to the CREATE line:
CREATE CONTROLFILE REUSE SET DATABASE "RCDB" RESETLOGS…

If the clone database will have a different name,

change all occurrences of the name.
name
Change any data file locations, as required.
Change g any y other options,
p as needed.
Save your work.
Cloning: Step by Step

Determine copy method:

Locally:
Use appropriate OS copy command
Use RMAN backups
Use RMAN to BACKUP COPY OF DATAFILE
Remotely:
FTP
Use rcp or scp
NFS mounted filesystems
Windows file shares
Use RMAN backups
Cloning: Step by Step

Ensure hot copying is done properly!

If p
possible, use RMAN for hot copying:
py g
RMAN> BACKUP COPY OF DATAFILE
‘/db1/oradata/test/system01.dbf’ format
‘/db7/oradata/nudb/system01.dbf’;
Otherwise,
Oth i place
l th
the database
d t b (i
(individual
di id l
tablespaces in 9i) into “hot backup mode:”
SQL> ALTER DATABASE BEGIN BACKUP;
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
SQL> HOST rcp /db1/oradata/test/system01.dbf
remote:/db1/oradata/replica/system01.dbf
…
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
SQL> ALTER DATABASE END BACKUP;
Cloning: Step by Step

Copying caveats!

Ensure that destination has sufficient storage.

Ensure that adequate permissions exist.
Ensure largefile support is enabled.
Manage file name changes carefully.
D nott copy tempfiles
Do t fil or online
li redo
d logs;
l those
th
will be created later.
Cloning: Step by Step

Prepare for recovery of the clone:

Identify archived logs that will be required for
recovery (if any) using V$ARCHIVED_LOG.
Copy the archived log(s) to the destination,
ideally to its log_archive_dest and using its
log_archive_format. Note the highest
NEXT_CHANGE# among g the archived logs.
g
Edit the ccf.sql file, changing RECOVER
DATABASE to add the SCN to recover to:
RECOVER AUTOMATIC DATABASE UNTIL CHANGE 5049397 USING
BACKUP CONTROLFILE;
Cloning: Step by Step

Create controlfile & open the new database:

Ensure that the destination instance is shut down.
down
Connected as SYSDBA on the destination, run the
ccf.sql file to create the controlfile, recover the
database files, and open the new database. For
example:
C:\
\ sqlplus
q p / as sysdba
y
SQL> spool ccf.lst
SQL> @ccf.sql
Cloning: Step by Step

Verify and finalize the new database:

Confirm that the new database is complete
p and
intact by examining:
DBA_DATA_FILES
DBA TEMP FILES
DBA_TEMP_FILES
V$LOG
If the new database will be backed up using an
RMAN repository,
it change
h th
the d
database
t b ID using
i
the DBNEWID (nid) utility
Rename the database internally:
ALTER DATABASE RENAME GLOBAL_NAME TO NEWDB;
RMAN Duplicate: Upside

Many details are handled automatically

File renaming is managed automatically
Extensive error checking is performed
Can be run from either source or destination host
computer system
Much less error-prone solution for duplicating
stable databases
RMAN Duplicate: Downside

Counter-intuitive terminology:
Database being g copied
p is called “target”
g
Destination database is called “auxiliary”
Only duplicates from backup media, not directly
from database to database.
database
Does not perform host-to-host transport.
Recovery from failures can be daunting.
daunting
Read-only, and especially transportable,
tablespaces require special handling and care, or
duplication operation will fail.
Split Mirror Cloning

Probably will need administrative rights to use

vendor’s storageg management
g utilities and to
make storage visible to the system.
Possibly will have to quiesce I/O on database:
ALTER DATABASE SUSPEND
<split mirror here>
ALTER DATABASE RESUME
Incremental sync can save lots of time
Be sure to split redo logs last in sequence!
Cloning Pitfalls

Issue: Running out of space during transport

Solution: Verify adequate space ahead of time
Issue: Archived logs missing during recovery
Solution: Ensure all required logs are copied
Issue: Once operational clone script now bombs
Solution: Structural changes to the database must
be reflected in updates to the script
Issue: RMAN indicates clone is not registered
g
Solution: Run nid and register the database
Cloning Pitfalls

Issue: Temporary tablespace is empty

Indication: ORA
ORA-25153
25153
Solution: Add all required tempfiles after cloning

Issue: File errors when DB opened/recovered

Indication: ORA-01111, ORA-01116, ORA-01141,
ORA 01179
ORA-01179
Solution: Verify copied filenames and confirm that
each file copy completed.
Cloning Pitfalls

Issue: Errors from transportable tablespaces and

read-only y tablespaces
p
Indication: ORA-01159, ORA-01177, ORA-01189,
ORA-01190, ORA-0120x
SSolution:
l ti Bi
Bring read-only
d l ttablespaces
bl on-line
li only
l
after all database recovery is complete

Issue: Recovery errors

Indication: ORA-01194, ORA-01195, ORA-01208
S l ti
Solution: U BEGIN/END BACKUP command,
Use d or use
RMAN to hot copy datafiles.
 Q
Questions
ti

info@sagelogix.com