Last week, I was in one of the ecommerce customer’s POC , one of the biggest ecommerce companies based in India. I was listening to the Oracle DBA team who express their daily challenges in managing databases. Here are problems expressed by the DBAs team in the meeting :
The customer asked my opinion on how they could reduce the time and cost in provisioning and backing up their databases. I believe it’s important to listen to customers and learn their challenges before providing any guidance. While all-flash arrays solve many database challenges they aren’t always the best solution for the application requirements. What was most interesting in listening to the customer is how data growth was lengthening all aspects of operational management.
When the customer first started creating database copies they were fast as the databases were small. Same was true with the time to back-up the databases. However over time data growth started lengthening most all the operational tasks. Now the DBA team was at a critical point in which their Service Level Agreements (SLA) were going to slip because their traditional storage infrastructure couldn’t meet the demands of the larger databases. As a long time DBA, I understand the importance of creating copies of databases. Frequently, we would start the copy process in the evening with the goal of having it completed by the following morning. Array snapshots improved our copy process by reducing the initial cloning time down to minutes. Both the old school copies and array snapshots were the same in respect to capacity planning. The DBA team had to work closely with all owners (application owners and storage administrators) to define if the resources were available to support the refresh or add another copy of the production database. Strong collaboration between teams was critical to operational management and setting expectations with the business. Even so it sometimes took weeks to provision a database application.
This customer was looking for new transformational approach to provisioning databases. We talked about how XtremIO 4.0 is a leader in provisioning copies of databases and everything else. There are two key features of great value to DBA teams:
In a paper that is coming out shortly we show creating a copy of a production database and opening the copy only took 13 seconds with the majority of time devoted the steps required to open the database copy. The copy created initially took no additional space on the array. When unique data is written to a database copy additional storage capacity is used but in the majority of cases is a very small fraction of production. The customer was very interested in XtremIO’s copy functionality because it solved all three challenges:
In this blog I’m going to talk about database provisioning but if you are interested in how all-flash solves database performance challenges please read this blog (by using XtremIO storage with Vblock). One of the DBAs with storage experience asked a very good question, “Does XtremIO create a crash consistent copy of database if multiple LUNs are used for data, redo logs, etc.” An excellent question by the DBA! XtremIO uses consistency groups to enable the DBA team to create a copy of all the LUNs used by the database. This means creating a copy of a database using multiple LUNs is very easy (takes just a few clicks). Below are the steps used to create database copies using XtremIO. On a side note you read below two terms I use interchangeably: snapshots (storage name) and copies (non-storage name). I prefer using the term database copies as it’s more universal.
Here is a screen capture of the XtremIO management console:
Figure 1 : Conditions for the creation of initial Snapshots
Figure 1a : Starting Environment for creating XtremIO Snapshot
As you can see it is a simple click to drop the menu down and create a snapshot. XtremIO offers two choices for greater flexibility to the DBA: Ready-only or writable copy (snapshot) of the database. Many XtremIO customers provision directly from production using writable snapshots because there is no performance tax. The point is the DBA has choice:
Figure 2 : Process for creating Read Only Snapshot
Snapshots can be used for physical database restores. For example, in Figure 3 we see the option to restore from snapshot. This option to restore from snapshot applies to read-only copies.
Figure 3 : Restore from Read-only Snapshots
If you plan on using database copies as part of your protection plan then we recommend placing the database in hot-backup mode for creating a consistent database copy. Remember XtremIO snapshots are instantaneous so placing the database in hot backup mode should only last a matter of seconds. Figure 4 is a bit blurry but shows the ease of restoring a snapshot. In this particular case we are restoring from a read-only copy because we didn’t want our database inadvertently altered as it was part of our protection plan.
Figure 4: Selection of the Snapshot to be restored
You can restore over production or create another copy. Below we show creating a new copy.
Figure 5 : Snapshot created for Restore
Now if we bring the volume online, we will see that we will be able to see all the contents that were there in the original state by using the Restore Option within the XtremIO GUI. Here No rescanning is required as there is no change in the SCSI ID (NAA).
In summary, we get the following benefits by using the XtremIO 4.0 restore feature.