Re: Oracle Exadata - Clone for test/uat

Jack,

Disclaimer:  I work for Delphix.

Not all cloning features are equal.  Some products have more extensive features than others, rather like comparing the features for SQL in Oracle to features for SQL in PostgreSQL.  For example, both Oracle and PostgreSQL have SELECT statements, but Oracle SQL provides many more capabilities in its SELECT than PostgreSQL does.

Focusing specifically on Exadata cloning features...

Exadata cloning with sparse grid disk groups involve creating a database copy called a "test master" which serves as the source object for all of the thin-provisioned clones.  "Test masters" are a full-size copy of the source database, and thin-provisioned clones are provisioned only from the current point-in-time in the "test master".

On Delphix, the corollary for a "test master" is called a "dSource".  A "dSource" is compressed/deduplicated to about 1/3rd the size of the source database, so Delphix never keeps a full-size copy of the database for any reason, as Oracle does.  Also, thin-provisioned clones (called "virtual databases" or VDBs) can be provisioned from *any* point-in-time on the "dSource", not just the latest point-in-time.

Exadata clones are not read-write until 12cR2 (12.2);  Delphix VDBs have always been read-write in all versions of Oracle from 10.1 to 12.2.

Exadata introduces "hierarchical snapshots" starting in 12cR2 (12.2), so you can now create clones from clones, but you can only go one level deep.  That is, you cannot create clones from clones from clones, or clones from clones from clones from clones, etc.  On the other hand, the depth of "recursive cloning" in Delphix is essentially infinite, although in practical terms nobody ever goes more than 2-3 levels deep.

Oracle's hierarchical snapshots also cause the "parent" clone to become read-only and frozen;  making any changes to the "parent" clone is not permitted until all "child" clones are destroyed.  On the other hand, creating VDBs from VDBs in Delphix never impacts the availability of the "parent" VDBs;  they are always fully read-write no matter how many dependent levels of clones are made from them.

Exadata cloning features are only available for recent versions (12.1, 12.2) of Exadata, while Delphix features support all Oracle versions (10.1 and up), SQL Server (2003 and up), SAP ASE (12.5 and up), SAP HANA (1.0), DB2 (10 and 11), and "flat files" on UNIX/Linux and Windows.

Long story short:  if you're looking at cloning capabilities, due diligence must include Delphix.

Hope this helps,

-Tim

On 12/12/17 16:06, Mladen Gogala wrote:
> On 12/12/2017 05:08 PM, Fairlie Rego wrote:
>> Hi Jack
>>
>> I have used the sparse grid disk feature on Exadata to clone
>> environments and haven't seen any major issues
>>
>> Perhaps the below documents will help
>>
>> http://www.oracle.com/technetwork/database/exadata/learnmore/exadata-database-copy-twp-2543083.pdf
>>
>> https://docs.oracle.com/cd/E80920_01/SAGUG/exadata-storage-server-snapshots.htm#SAGUG20386
>>
>>
>> Ta
>>
>> Fairlie
>>
> Hi Fairlie,
>
> Please correct me if I'm wrong, but those features are used to migrate
> FROM Exadata, not TO Exadata. I agree that an alligator snappin'
> database is the way to go, but it doesn't look that way in this
> particular case.
>
> --
> Mladen Gogala
> Oracle DBA
> http://mgogala.freehostia.com

--
http://www.freelists.org/webpage/oracle-l