Why you should Deploy Delphix Now

Yadda, Yadda, Yadda

We are all tired of hearing about enterprise software which is

“Cost reducing, revenue expanding, investment returning, risk avoiding, cloud enabling, breath taking, productivity improving, agility accelerating, complexity taming, career enhancing, …”

We already have so much of that stuff we should be making money in spite of ourselves,  … wait a minute.

All customers have a finite budget, finite resources and an infinite to do list, which means that everyone has to prioritize.   For some customers, access to data without delay has made it onto the high priority, must do next, list.  For all other customers it seems like it would be beneficial but there are bigger fish to fry right now.

Brace yourselves, here comes the sales pitch

Delphix hits the ground running, from day one you will start releasing resources to then attack your highest priorities.    Delphix will automate tasks that currently consume valuable operational time allowing members of those teams to focus on what’s more important for your company right now.

Delphix is a fully automated data provisioning system and is packaged to be easily and quickly deployed.  Here are the steps.

1.    Import Delphix Virtual Machine into Hypervisor

2.    Allocate a network address to Delphix

3.    Allocate around 10-20% of the total non-production storage you would typically need (without Delphix)

4.    Register production or standby source servers with Delphix.

5.    Instruct Delphix to ingest selected databases, this starts a fully automated, policy driven, continuous synchronisation process

6.    Register non-production dev and test database servers with Delphix.

7.    Create and assign virtual database copies for your dev and test community in minutes

8.    Finished

All non-production database provisioning, versioning, refreshing, rewinding, achiving and general manipulation requests can now be delegated to Delphix.

Delphix without Delay

When trying to fix a complex problem, a key technique is to break down the problem into problems you can fix.  Deploying Delphix will fix your data access issues, but more importantly if your IT priorities lie elsewhere you can use Delphix to free up capacity to focus on those priorities.

Deploy Delphix Now

 

Delphix Use Case: Oracle Instance Consolidation

Non-Production Database Server Capacity

Delphix solves the problem of provisioning as many full copy databases as required, however often the next bottleneck is having sufficient database server capacity to run multiple databases concurrently.

This problem is worse when a single application requires a set of databases to be running concurrently.   Now each user who wants to have a private copy of the entire application dataset requires to run multiple database instances.

You can squeeze more database instances on a single server by reducing the database initialization parameters to a minimal specification depending on the intended use.  However this still means that each database has its own SGA and a full set of around 50 background processes.  The Oracle solution to this problem is Oracle 12c Multitenant.  Oracle Multitenant is an effective solution but it is expensive, is quite complicated and requires 12c.

For an excellent comparison of database consolidation options see Tim Hall’s blog article Oracle Database Consolidation Comparison.

A simple and more cost effective alternative to Multitenant is schema consolidation and this is made even easier when schemas are contained in transportable tablespaces.   To create a consolidated instance using transportable tablespaces you start with a stub or empty database and import the required set of tablespaces from the source databases.   Relevant schema objects that are stored in the SYSTEM tablespaces can be copied across using a meta-data only export.  You will have to take care of namespace collisions and realign synonyms and database links but you probably have that capability already for provisioning your UAT or pre-production test environments.

The consolidated database will be tied to a specific Oracle database version however you can transport tablespaces from different platforms, those using a different endian format will require an RMAN conversion step.

Are my tablespaces transportable?

It is quite easy to check if the tablespaces you want to consolidate are transportable.

SQL> EXEC SYS.DBMS_TTS.TRANSPORT_SET_CHECK(

        ts_list => 'TTS1, TTS2',

        incl_constraints => TRUE,

        full_check => TRUE);

PL/SQL procedure successfully completed.

SQL> select * from transport_set_violations;

no rows selected

Often violations are caused by references to objects in other tablespaces.  These can be corrected but would require moving the dependent object. 

This is much easier if you have already ingested all your source databases into Delphix as you can make these changes safely in a Delphix Virtual Database (VDB).

How does Delphix help?

You can build your consolidated database instance using a Delphix Virtual Database (VDB).  You use the same process as you would for a physical copy however when you import into a VDB you immediately get compression.  If you repeat the process you also get de-duplication and version control.  Not only that but you can create virtual database copies from a master consolidated VDB.

As mentioned above dealing with any transportable tablespace rule violations are also easier managed if the source databases have already been virtualized.

What’s the recipe?

The first two steps below are just to allow us to create an empty VDB that we will then populate using transportable tablespaces.

1.     Create a stub or empty Oracle physical database.

2.     Ingest the stub database as a Delphix dSource (stub)

3.     Create a virtual database (vcons) from dSource (stub)

4.     Import transportable tablespace meta data directly into VDB (vcons)

5.     Copy the datafiles that make up the transportable tablespaces directly into Delphix under the appropriate VDB mount point.

For example, if my VDB mount point is /home/delphix/vdb, my vcons VDB datafiles will reside under a folder named /home/delphix/vdb/vcons/datafile.

Delphix compresses the copied datafiles on the way into the Delphix mounted storage.  If the files are being overwritten then deduplication takes place between the file versions.

6.     If you have schema related objects including stored procedures that reside in the source database SYSTEM tablespace, export and import those objects into vcons.

7.     Realign any synonyms and database links.

8.     Run a validation script to make sure everything is in place.

9.     Take a Delphix Snapshot of VDB (vcons) and bookmark it.  This enables labeled versions.

Now you are good to go.  You can configure the SGA for the vcons VDB to an appropriate setup for the intended workload.  You can also create child VDBs of vcons, sharing all the storage and optionally using different SGAs.  If not all child VDBs require access to all the tablespaces in vcons, from a storage perspective it does not matter because the unwanted tablespaces will incur no additional storage, however you can just drop them if desired from the child VDBs without impacting any other copies.

If you are already using Oracle 12c multitenant then Delphix can be used to virtualize your 12c pluggable databases.

Summary

Delphix in combination with Oracle transportable tablespaces can minimize the storage required to provision sets of databases and can also minimize the amount of database server resources required to access those datasets through schema and consequently instance consolidation.

Delphix for Production Support

Production Support is a very strong Delphix use case.  Delphix can minimize the time taken to provision a database copy for investigation and repair of production data problems whether caused accidentally or maliciously.  Although most customers invest in Delphix to accelerate release cycles its surprising how many have found Delphix to have saved the day for Production Support.

Production Outages

Production application outages are often caused by “logical” data corruption as a result of errors including accidental deletion or modification of data, dropping the wrong table, failed batch jobs and bugs that have eluded testing.   In all these cases you want to repair the production database by restoring the affected data to the most recent consistent state and if the failure was caused by an unknown action you want to identify, diagnose, fix, test and repair the cause of the failure.

There are a variety of methods to establish or maintain an up to date replica copy of a production database to allow operational support teams to quickly troubleshoot production faults.  The server infrastructure is usually paired down significantly as the environment is not intended to support full production concurrent activity or for performance related issue resolution or reproduction but it must be a full replica of production from a data standpoint.

The simplest method is to restore from a backup but this introduces a long delay before you can start investigating the fault even from disk based backups.  The next method is to use a standby database, sometimes delaying the synchronization to avoid the data error being replicated to the standby.  More sophisticated is to use database flashback in combination with a standby, this allows the standby to be kept up to date with the ability to temporarily rewind the standby database prior to the point in time of the failure and then open the database for investigation.

Production Support wth Delphix

Delphix provides the simplest solution for provisioning a Production Support environment on demand as Delphix allows customers to start a private, read write full copy database from any point in time in just a few minutes.  Aside from speed and ease of use Delphix leverages its own compressed, de-duplicated copy of the production database, which it also maintains automatically.   That same copy can be shared to provision as many virtual full copy databases as desired whether for production support, development, testing, reporting, etc.

The time taken to provision a virtual database is less dependent on the database size but more on the rate of change.  All point in time provisioning typically involves starting from a known consistent state and rolling forwards to the desired point by applying transaction logs.    So the majority of the time is consumed by the database rolling forward.  Taking frequent consistent snapshots to minimize the volume of transactions logs to roll forward can reduce the recovery time.

Delphix LiveSource

Delphix LiveSource in Action

For Oracle databases Delphix has a capability called LiveSource this provides an alternative method for synchronizing a Delphix database copy (dSource) with a production database.  Typically Delphix synchronises with an Oracle database using incremental backps and transaction log capture.  Delphix LiveSource starts up an Oracle standby database instance using the Delphix dSource data copy directly, now Oracle Data Guard is keeping the Delphix dSource copy synchronised.  LiveSources are also easier to manage in the case where non logged changes occur on production.  Such changes are not applied by the Data Guard mechanism since they are not recorded in the transaction logs.   Delphix can simply take an incremental backup of the changed blocks and apply them to its own copy.  This is a push button or CLI operation.

This solution has some major advantages for Production Support, in particular for very large databases spanning 100s of Terabytes.  The Delphix copy is compressed so you don’t require adequate storage for a full database copy.  A point in time snapshot of a Delphix LiveSource database takes seconds and incurs microscopic storage overhead.   Even for high change rate source databases the transaction log volume that needs to be applied to perform point in time recovery is minimized.

Oracle Database Flashback

FLASHBACK DATABASE TO SCN 123456789;

FLASHBACK DATABASE TO RESTORE POINT my_restore_point;

FLASHBACK DATABASE TO TIMESTAMP SYSDATE-(5/24/60);

Example Oracle Database Flashback Commands

If that is not enough you can also enable Oracle Flashback Database on the LiveSource standby.  The flashback area used by Oracle to store and access flashback logs, which record past versions of changed blocks, can be provisioned by Delphix and hence these flashback logs are also compressed.

The Delphix LiveSource is just a normal Oracle physical standby database, running on ultra efficient storage and hence with Database Flashback you can rewind the standby to the desired point in time to retrieve lost data, investigate root cause and test corrective actions or fixes.

Once the problem has been resolved you can re-enable the LiveSource which will synchronise the Delphix dSource with production changes that have occurred during the investigation.

Summary

Using Delphix LiveSource for Production Support you can start investigations within minutes regardless of database size or change rate.  For extremely high change rate databases you can use Delphix LiveSource in combination with Oracle Flashback Database.  You then have a choice of flashing back or rolling forward, whichever is the quickest.