Oracle 11g R2 Cloning

New Cloning Features Available in Oracle 11g R2

Agenda

Types of Database Clones
Reasons for Cloning
Challenges
Cloning enhancements in 11g
Active DataGuard
Snapshot Standby
Clonedb
Edition Based Redefinition

Types of Database Clones

Full Copy Clone
• The source database is copied
• The copy is restored to a new environment
• The copied database is opened for use
• RMAN Duplicate is an example of a Full Copy Clone
Delta Clone
• A baseline of the database is created
• The baseline and special files containing deltas are used
together to display database content
Code Only Clone
• Only VIEWS, TRIGGERS, and PL/SQL Objects are cloned

Reasons for cloning

Reporting environments
• Many reporting tools require read / write access to the
database
Development Environments
• Developers want and sometimes require fresh data for
effective unit testing
QA environments
• Effective integration and performance testing require recent
copies of production data
Environment Management
• Test build scripts against production data

Challenges with environment cloning

Cloning can be time consuming and expensive
• Large databases take a long time to duplicate
• Enterprise Disk is expensive
– Enterprise Class Storage
!= Best Buy Hard drive
– Justifying the disk budget
for a full development
copy can be difficult.

Challenges with environment cloning

Different teams have different development
requirements
• Development, QA, Reporting, and Environment
Management all have different needs requiring
environments.
– If multiple development projects run
concurrently there is a need for even more
environments
Development Requirements …
QA Requirements …
Reporting Requirements …
Environment Management Requirements …

Cloning enhancements available in 11g

Three new ways to create a clone environment in 11g
• Full Copy Clone
– Active Data Guard
– Snapshot Standby
• Delta Clone
– Direct NFS and clonedb
• Code Only Clone
– Edition Based Redefinition

Active Data Guard, What it is

A physical Standby database that can be Queried while being recovered
• Read only
• Requires an additional license (Active Data Guard)
• Great for report offload
Active Data Guard has other benefits
• Automatic Block Repair
• Fast Incremental Backups
Best used for leveraging existing DR instances
• ODS
• Reporting Environment
• Backup Offload

Active Data Guard, How it works

Extends Oracle’s standard CR technology
• No ‘dirty reads’ for queries on the standby
• Repeatable Reads available
• Data Dictionary Caches are kept up to date
• In short ACID properties not compromised
• Query guaranteed to return the same result it would have returned on the primary at a given SCN.

 Active Data Guard Use Cases

Active Data Guard is good choice for
• Reporting databases
• Read only applications
• Leveraging existing DR investment without comprising RTO / RPO SLAs
Active Data Guard is not a good choice for
• Reporting Environments that require writes
• Development Environments (obviously)
• Reporting Environments that need a static data set

Snapshot Standby What it is

A set of commands to change a physical standby database into a read write database and back again
• Does not require additional licenses beyond EE for standby environment
• Database is read write
• Recovery is stopped while database is open
• Technology to create Flashback standby is available in 10g
– 11g automates the process via DGMGRL or OEM  Leverages Flashback database
• Guaranteed Restore Point created
• Database Opened Read Write
• Archive Logs continue to ship but are not applied
• To re-instantiate standby:
– Flashback to restore point
– ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
– Resume Archive Log application
• Snapshot Standby databases can be refreshed from incremental backups as well as Archive Logs.

 Snapshot Standby Use Cases Snapshot Standby is good for:

• Reporting environments that require DML/DDL access
– Discoverer
– Micro Strategies
• Reporting environments that need a consistent and static data set
– All reports assume data as of midnight Snapshot standby should not be used if:
• Opening the database jeopardizes the RTO SLA for the environment
– Flashback can take a long time
– Log application can take a long time

 DNFS Clonedb; what it is

A sparsely documented new feature available as of 11.2.0.2
• Requires Oracle Direct NFS
• Uses a Datafile copy for its base data set
• Creates separate delta datafiles to hold block changes
• Uses Copy on Write (COW) to write changes to the delta files instead of the base backup files
• Metalink Note: 1210656.1 is the only Oracle documentation I have found on this feature.

Clonedb; How it works

Clonedb leverages Oracle Direct NFS
• Datafile copies are placed on disk accessible to the server where the clone will be created
(local,SAN,NFS,DNFS)
• A mount that supports Direct NFS is used to hold changes to blocks
• Changes are stored in sparse files. Bitmaps in the files show what blocks live where
• Oracle uses Copy on Write to write changes to the delta files instead of the base
• Oracle silently merges the base with the changes in the delta files during queries.

Clonedb; uses

Clonedb is good for:
• Providing one or more non production environments from a single set of backup datafiles
• Creating an environment to test build scripts for releases
• Leveraging existing backups for non produciton environments Clonedb is not ideal for:
• Performance testing*
• Environments that do not use NAS storage

Edition Based Redifinion; what it is

An 11g feature that allows several versions of the same code to exist in the same schema
• A new level of granularity:
– Schema
» Object Name
– Edition
• Stored code can have several versions
– Ora$base
» R2
– R3

Edition Based Redefinition; how it works

EBR gives a new level of granularity for certain objects
• Views, Stored PL/SQL objects, Types, and Synonyms are all editionable
• Tables and Materialized Views are not
• Two new objects are used with EBR
– Editioning Views
– Cross Edition Triggers
• Editioning Views and Cross Edition Triggers compensate for object types that are not editionable.

Edition Based Redefinition; Use Cases EBR is good for:

• Hot Code Upgrades in production
• Providing a quick fallback to prior code base
• Multiple development environments using the same data but different versions of editionable objects
• Beta version of code in production
EBR is not:
• EBR is not a true clone
• The underlying data is shared amongst all editions

********************************END*********************************************