Re: limited trial version of Delphix for instant database cloning
- From: Chris Taylor <christopherdtaylor1994@xxxxxxxxx>
- To: kylelf@xxxxxxxxx, Tim Gorman <tim@xxxxxxxxx>
- Date: Wed, 29 Oct 2014 13:49:53 -0500
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@xxxxxxxxx> 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/dbmaestro-delphix-partner-for-agile-data-development/
>
> Best
> Kyle
>
>
> On Wed, Oct 29, 2014 at 11:27 AM, Tim Gorman <tim@xxxxxxxxx> 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@xxxxxxxxx> 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/ 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
>>>
>>> A video of an exercise using cloning is here
>>> https://vimeo.com/106979766
>>>
>>> Best Wishes
>>> Kyle Hailey
>>> http://kylehailey.com
>>>
>>>
>
Other related posts:
