facebook_button-30.pngtwitter_button-25.pngemail_button-30.pnglinkedin_button-30.png

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 :

  1. Traditional database refreshes are taking too long
  2. Database backup windows and recoveries are pretty high.
  3. As the data is growing into Oracle database , performance is hitting rock bottom hence the jobs are taking long time.

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:

 

  • Inline always on compression: As data flows into XtremIO it is automatically compressed (after it’s been deduplicated). On average Oracle customers experience 2X compression which means a 10TB database compresses down to 5TB.
  • Inline always on deduplication: In terms of creating database copies this feature is huge. In XtremIO the initial database copy takes no space thanks to inline deduplication and is maintained as metadata. As you might have guessed because no data is written the copy creation is instantaneous regardless of the size of the database or number of copies the DBA team creates.

 

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:

  • Time to create database copies
  • Time to create a database copy for backup
  • Data growth impacting database performance

 

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:

abc1.png

Figure 1 : Conditions for the creation of initial Snapshots

 

abc2.png

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:

  • Create read-only snapshots (as demonstrated in Figure 2)
  • Create writeable snapshots
  • Create read-only snapshots from which to provision writeable snapshots
  • Create writeable snapshots from which to provision more writeable snapshots

 

abc3.png

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.

abc4.png

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.

abc5.png

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.

 

abc6.png

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.

  • Provides immediate Recover Time Objective (RTO).
  • Very simple to operate with few clicks. Need not to be DB or storage expert to do refreshes. All complexities are taken care internally by the GUI
  • No change in the SCSI ID (NAA) even after restore. Hence, remapping or Rescanning on the host is not required. Less complexity in performing refreshes.
  • Enables recovery of data from read-only snapshots.
  • The restore time is minimal compared with the traditional oracle restores.
  • Allow restore from snapshots that are direct decedent.
  • Can perform the DB restores in the running state. Hence, requires no downtime for DBs.
  • Saves substantial $$ for the organization as we can create space-efficient writable snapshots with practically no change in configuration like SCSI ID (NAA).

 

Follow us on Twitter:


EMCOracle.png

Tweet this document:


Want to know how to restore database snapshots with XtremIO 4.0?

Click here to learn more:

store_open.png

facebook_button-30.pngtwitter_button-25.pngemail_button-30.pnglinkedin_button-30.png