Deploy a HANA Production Copy in Under 4 Minutes

Data provisioning is a significant challenge for large organizations, and the goal of superior data provisioning is trusted and timely data delivery. Unfortunately many data provisioning processes have been designed and built with complexities and inefficiencies, posing significant challenges to application developers, who must spend time writing code to access and transform data, rather than writing business logic.

So how can you leverage the right technology to deliver data from disparate sources into meaningful, trusted information and make it available when, where and how it is needed for your critical business initiatives?

With a DataOps platform like Delphix, you can provision a multi-terabyte SAP S/4HANA database for your analytics, dev or QA teams in just 4 minutes flat, a fixed duration that doesn’t increase with size.

You can also rewind your copy of data to a point in time or refresh from production to get the latest changes - all with a click of a button or scripting it via our API. Is this tool SAP HANA tenant aware? You bet. We can mix and match tenant databases from different sources and spin-off copies anywhere on demand.

It gets better. The first copy of your SAP HANA tenant is recovered, just like normal. However, the copies of that recovered image any time after are tracked by block changes, so the initial storage cost of the converged copies is a few kB. Obviously, as your users work on their copies and the delta increases, the storage footprint grows. Block sharing in conjunction with compression tailored to the needs of HANA means your teams get production copies with lightning speed and a storage footprint that is a fraction of what would generally be required.

There is competition in this space. Many storage vendors can snapshot a filesystem, which is all fine and dandy, but it just means you transport the whole system, including a systemDB and all its tenants. You may want only one tenant, and you may want to place that single tenant alongside a different tenant on a new target host. Storage copies and snapshotting won't help you there. They are not tenant aware, and they represent an all-or-nothing, blunt-force approach with a fair degree of inflexibility reverberating all through the SAP stack.

Outside of storage vendors, there are other ventures suggesting various levels of I/O interception. Again, these approaches know nothing of the HANA systemDB that binds together all the tenants, so in these other examples you, the customer, end up being asked to stage your copies somewhere and then thin out what you captured so the DevOps team or the intended recipient does not have more access than they should.

This means you incur a cost in terms of the added infrastructure, such as a staging server, and not to mention the time this operation may take. Wherever you work in an organization, think for just a moment about how how big a deal reducing friction associated with HANA deployments could be.

Register for a demo and learn how you can start your HANA DevOps transformation today.