Re: limited trial version of Delphix for instant database cloning

At its core Delphix provides backup synchronization for source databases and storage management for target databases, with the secret sauce being that the same blocks on disk are used for both purposes. This means that a source database is synced with Delphix where it is compressed and stored at the block level, and when a VDB is provisioned (or multiple VDBs are provisioned) they use those blocks as their storage basis for the virtual files - resulting in a full sized read-write VDB that doesn’t use any additional disk space except for changed blocks (which are also stored back on Delphix, compressed). If you query v$datafile on a VDB it will show full-sized datafiles, but within Delphix you can see the actual “virtualized” size.

So to answer this question, if you spin up a new VDB the size of the VDB is a handful of megabytes due to changed blocks in SYSTEM and SYSAUX at provision time. But Oracle will think the files are all full-sized.

To answer your other question, integrating logical change capture/replay or comparison replay would certainly be cool but it would kind of be reinventing the wheel. Since Delphix virtualizes data at the storage level, it would basically be either doing logical comparisons just like tools Kyle mentioned, or some form of replication like Streams, GoldenGate, Dvbisit, etc. One thing Delphix does have is a framework for pre/post-refresh hooks, which could allow post-refresh compare/apply scripts to be run if there is a means to do so at the script level.

Hope this helps! Also feel free to ask questions on the Delphix community forum at http://community.delphix.com/ <http://community.delphix.com/> as there are some very helpful folks there as well And if you’re interested in playing with Delphix yourself please reach out to Kyle!

Regards,

Steve Karam
OracleAlchemist.com <http://oraclealchemist.com/>

> On Oct 29, 2014, at 2:49 PM, Chris Taylor <christopherdtaylor1994_at_gmail.com> wrote:
>
> So, let me ask another question to make sure I'm clear on something.
>
> When we spin up the new VDB (QA1 - for example) from our Prod data source, the size of our QA VDB is NOT the same size as Production, is that true? That was my understanding but I wanted to make sure.
>
> Thanks!
> Chris
>
>
> On Wed, Oct 29, 2014 at 1:35 PM, kyle Hailey <kylelf_at_gmail.com <mailto:kylelf_at_gmail.com>> wrote:
> Hi Chris,
>
> As Tim noted Delphix tracks changes at the storage level, which for Oracle databases amounts to tracking data block changes, thus we don't know what SQL command were run to modify the database, only that some blocks were changes and we track the before and after in order to support many clones off the same underlying shared data.
>
> For tacking changes at the SQL layer, a good tool is DB Maestro and DB Maestro and Delphix have done a number of webinars together to explain how the technologies are complimentary:
>
> http://www.oraclerealworld.com/version-controlled-databases-and-data/ <http://www.oraclerealworld.com/version-controlled-databases-and-data/>
> http://www.oraclerealworld.com/dbmaestro-delphix-partner-for-agile-data-development/ <http://www.oraclerealworld.com/dbmaestro-delphix-partner-for-agile-data-development/>
>
> Best
> Kyle
>
>
> On Wed, Oct 29, 2014 at 11:27 AM, Tim Gorman <tim_at_evdbt.com <mailto:tim_at_evdbt.com>> wrote:
> Chris,
>
> First, some background to clarify things...
>
> Production is the "source" database. Let's say that PROD is initially loaded into Delphix while it is at code release x.x.2. Once that occurs, QA is cloned as a "virtual database" or VDB from the "dSource" of PROD. Once a VDB is created, it is an independent branch from its dSource.
>
> So, QA is gradually modified from code release x.x.2 to x.x.3 in the normal course of events, which doesn't affect the dSource of PROD at all. The dSource of PROD is constantly in synch with the source database PROD, and any new VDBs created from the dSource of PROD will initially be x.x.2 as well, but then become independent branches in their own right.
>
> Eventually, code release x.x.3 within QA is declared ready for production, and the deployment into the source database PROD occurs, so those changes are recorded and propagated into the dSource of PROD within Delphix. No problems. The existing VDBs are not affected by these changes, including QA.
>
> As you mention, QA has progressed to x.x.3.y, which doesn't affect anything around it. The upgrade of PROD to x.x.3 does not affect QA. The propagation of any changes in PROD to the dSource of PROD in Delphix does not affect QA. Everything is independent of one another.
>
> Now, to answer your questions...
>
> Q1. How can we preserve the differences in the QA environment when we want to create a new QA VDB and replace the prior one - that is, does Delphix provide that capability to generate a set of differences scripts to be replayed after the new VDB is created to bring the objects up to speed with the latest changes, OR would that be a function of the DBA/Dev teams to capture the changes prior to creating the VDB and replaying them manually?
>
> A1. Delphix does not generate a "differences script" as you describe. However, there are a variety of tools (such as TOAD) that do compare two databases and produce such a script. Delphix can maintain the QA database at code release x.x.3.y, and Delphix can create a new VDB (named QA1) from the current dSource at code release x.x.3. A DBA can point TOAD at the two VDBs to generate the differences script.
>
> Q2: How does Oracle licensing fit into this with VDBs?
>
> A2: Delphix only virtualizes storage (i.e. datafiles, tempfiles, redo logfiles, archivelogs, control files, spfiles/pfiles, etc). Oracle licenses by CPU or named-user. This means that Delphix has no direct impact on Oracle licensing. As far as any indirect impact is concerned, it can be said that by creating VDBs more quickly using less storage, Delphix can have the effect of causing more Oracle licenses to be consumed, because it will become easier to generate more databases. However, this is purely a local choice, as DBAs could simply cram more database instances onto existing servers to preserve licenses.
>
> Hope this helps!
>
> Thanks!
>
> -Tim
>
>
>
> On 10/29/14 11:14, Chris Taylor wrote:

>> Given the following scenario, can you share some answers/ideas to the questions that follow.  This should be "on topic" I believe as related to leveraging this as a support function of the Oracle DBA group - or working in conjunction with a development/change management group.
>> 
>> QA Environment at code release x.x.3
>> Production at code release x.x.2
>> 
>> Production is updated to x.x.3
>> 
>> Some additional changes still reside in QA however that are not in Prod.
>> 
>> 1. How can we preserve the differences in the QA environment when we want to create a new QA VDB and replace the prior one - that is, does Delphix provide that capability to generate a set of differences scripts to be replayed after the new VDB is created to bring the objects up to speed with the latest changes, OR would that be a function of the DBA/Dev teams to capture the changes prior to creating the VDB and replaying them manually?
>> 
>> 2.  How does Oracle licensing fit into this with VDBs?  
>> 
>> Sincerely!
>> Chris Taylor
>> 
>> 
>> On Wed, Oct 29, 2014 at 11:02 AM, kyle Hailey <kylelf_at_gmail.com <mailto:kylelf_at_gmail.com>> wrote:
>> 
>> If you are interested in early access to the first publicly downloadable version of Delphix, email me back and send me your linkedin profile URL. I'll send you the download info back via Linkedin. 
>> 
>> At OOW we launched the public access to Delphix called #CloneAttack (like #RacAttack) and ran it at the OTN lounge. Now we are rolling it out on a limited download basis.
>> 
>> Delphix allows you to clone data, especially databases notably Oracle, in minutes no matter the size for hardly any storage . see http://blog.delphix.com/kyle/2014/delphix/ <http://blog.delphix.com/kyle/2014/delphix/> for more info
>> 
>> Now we running a limited download program. We have a trial version of Delphix and hands on lab that include 3 virtual machine OVAs. One VM is a Linux source with an Oracle database. Another VM is a Linux target for creating clones. And the 3rd is a Delphix VM that creates the clones.  
>> 
>> A video of the lab install is here https://vimeo.com/106979766 <https://vimeo.com/106979766>
>> 
>> A video of an exercise using cloning is here https://vimeo.com/106979766 <https://vimeo.com/106979766>
>> 
>> Best Wishes
>> Kyle Hailey
>> http://kylehailey.com <http://kylehailey.com/>
>> 

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