Copy Data Management with Delphix on Exadata
I’ve been busy reading and testing everything I can with Delphix, whenever I get a chance. I’m incredibly fascinated by copy data management and the idea of doing this with Exadata is nothing new, as Oracle has it’s own version with sparse copy. The main challenge is that Exadata’s version of this is kind of clunky and really doesn’t have the management user interface that Delphix offers.
There is a lot of disk that comes with an Exadata, not just CPU, network bandwidth and memory. Now you can’t utilize offloading with a virtualized database, but you may not be interested in doing so. The goal is to create a private cloud that you can use small storage silos for virtualized environments. We all know that copy data management is a huge issue for IT these days, so why not make the most of your Exadata, too?
With Delphix, you can even take and external source and provision a copy in just a matter of minutes to an Exadata, utilizing very little storage. You can even refresh, roll back, version and branch through the user interface provided.
I simulated two different architecture designs for how Delphix would work with Exadata. The first was with standard hardware, with Virtual Databases, (VDBs) on the Exadata and the second having both the Dsource and the VDBs on another Exadata.
VDBs On A Second Exadata
- Production on EXADATA,
- Standard RMAN sync to Delphix
- VDBs hosted on EXADATA DB compute nodes
- 10Gb NFS is standard connectivity on EXADATA
VDBs on Standard Storage, Source on Exadata
- Production on EXADATA, standard RMAN sync to Delphix
- VDBs hosted on commodity x86 servers
How Does it All Work
Now we need to capture our gold copy to use for the DSource, which will require space, but Delphix does use compression, so it will be considerably smaller than the original database it’s using for the data source.
If we then add ALL the VDBs to the total storage utilized by that and by the Dsource, then you’d see that they only use about the same amount of space as the original database! Each of these VDBs are going to interact with the user independently, just as a standard database copy would. They can be at different points in time, track different snapshots, have different hooks, (pre or post scripts to be run for that copy) with different data, (which is just different blocks, so that would be the only additional space outside of other changes.) Pretty cool if you ask me!
Hi Kellyn,
Very interesting post, some questions however:
How does Delphix manage source databases with HCC?
An other point, do you have any feedback regarding licensing? I know some customers having pretty good consolidation ratios compared to commodity (x3 and x6), wouldn’t the second case create licensing problems?
Thanks
HD
Good Morning Herve,
The following short explanation in this doc, does a good job of explaining, since these are VDBs, no impact to HCC occurs, https://docs.delphix.com/plugins/servlet/mobile#content/view/15499411
As for licensing, each VDB instance must be licensed as any Oracle instance would require and are subject to Oracles licensing requirements.
The huge savings is storage consumption, fast deployment and refreshes on copies of existing environments, making copy data management simple and efficient.
Thank you for reaching out,
Kellyn
Thank you Kellyn for the details.
One point though, do you have real life examples of of the size of HCC tables and the same once decompressed and recompressed on DxFS? That would be great to understand the impacts in terms of process duration and disk space. (HCC compression ratio can be very good and I don’t see how DxFS could compress more).
About licensing, this is a subject customers must understand indeed.
A last thought: when you say “Now you can’t utilize offloading with a virtualized database, but you may not be interested in doing so.”. First I think Exadata customers have bought it because of this feature among others (not mentioning IORM…). I can see some use cases where the DB model relies on Storage Indexes and thus basic indices have been removed (or just not created). Then back on commodity x86, this would mean to recreate them? (imagine non regression tests with huge performance impacts while doing tons of full table scans). Could you please elaborate about real life feedback? (usual size of Delphix managed VDBs…). Indeed, the size of databases will grow more and more and this is especially true with the Multitenant architecture.
Don’t blame me, I’m just trying to understand the impacts J
Thanks
HD
If we were to compare, 10 databases using HCC vs. 1 HCC database with a D source compressed and 9 VDBs, are you trying to claim the former will consume less space??
No. Not even with the most aggressive compression, no.
Next, most copies are used for development and test. High end performance features used around 15% of the time shouldn’t be required.
I’m also confused why multitenant would grow more than any other database? User data growth is user data growth…
Thanks
Kellyn