Delphix 4.0 -Faster, Better (II)

I posted a blog last week talking about some of the performance improvements we made

I posted a blog last week talking about some of the performance improvements we made in Delphix 4.0. In this post I will talk about improvements we made to another feature, LogSync.


One of the key differences of VDBs from physical copies of DBs (or other storage based cloning solutions) is the ease with which a VDB can be refreshed, rolled forward or backward to any point in time. SnapSync creates a crash consistent snapshot of the DB within Delphix from which a VDB can be provisioned.

LogSync is the feature that allows provisioning between any two such snapshots. LogSync non-intrusively fetches change logs from the production database using standard DB techniques. Once the logs are in the Delphix Engine, customers can provision a VDB to any point in time.

The graphic below shows such a timeline of change or "Timeflow" for a single source database. The ability to efficiently provision a VDB from any point in time without any overhead enables adoption of AGILE processes for database application development.

timeline of timeflow

Delphix UI screenshot showing timeflow for a dSource

log sequence

Number of Log Sequences the dSource is behind the production DB. In order to stay in sync with the source DB, LogSync has to identify the logs that are created and transport them to Delphix at the same rate the logs are created. For especially active DBs with high redo, this becomes non-trivial.

In 4.0, we improved the algorithms used for LogSync, and added more configurability to the workflow. Customers can now configure LogSync to aggressively fetch the logs or stay on the back burner without consuming any resources. In our lab environment, we were able to keep Delphix in sync with a highly active database, with unique change of 8 TB per day.

We created a scenario where a log switch happens every few seconds making it difficult for the redo apply to keep up. The chart above shows the number of log sequences LogSync is behind the source database.

The source database in this case is running at approximately 100MB/sec (8.2TB/day) of redo. Under these conditions LogSync in 3.2 is unable to keep up, but the 4.0 version (blue) is able to stay in sync with the source database.

I will talk about the improvements we made in V2P and DxFS in my next post. Please stay tuned for that.