In my last post I covered some settings to ensure you get the best performance from your XtremIO when running an Oracle workload.  When running any type of workload on XtremIO it’s a given that it will perform well, but what about helping us manage capacity as well? XtremIO offers inline deduplication, which we can leverage to save capacity without sacrificing performance.

Any lun created on XtremIO will be thin provisioned at a 4k-granularity level.  That’s all well a good, but we know Oracle and thin provisioning aren’t exactly best friends so this won’t buy us a lot. XtremIO, however, does have an inline global deduplication that we can leverage to our benefit. Like thin provisioning this feature also operates at a 4k-granularity.  What that’s means is only unique 4k blocks consume physical capacity. How can we best use that to our benefit? The short answer is multiple copies of the same data. These copies can be use for backup/recovery, testing, development, or anything else you may need.

Since we’re talking Oracle we’ll first talk about Oracle Recovery Manager or RMAN. RMAN is Oracle’s native tool for backing up and recovering an Oracle database. RMAN’s default behavior is to create a backup on disk using something called a “backup set”.  A backup set is just a grouping of backups of datafiles, control files, server parameters, and archived redo logs.  These files are written to disk in RMAN’s native format, which causes us a problem. This format means the data is completely different, so XtremIO inline deduplication will not provide cost savings for.  In order for RMAN to play well with XtremIO we need to deviate from the default settings.

RMAN’s image copy option is literally an exact copy of a single datafiles, archived redo log, and control files. Executing an RMAN image copy is the same copying a file using normal operating system commands. The resulting bit-by-bit copy of the database files which will consume no additional physical capacity on the XtremIO.  If you were to look at the XtremIO GUI after writing a image copy backup, you’ll see a deduplication ratio slightly above 2:1.  What that means is we were able to create an exact recoverable copy of our Oracle database without the additional consumption of physical storage!

That’s great an for backup, but lets say you need a second or third (or more!) copy of the database for development/testing. In order to make space efficient clones of the database we’ll be using the same RMAN image copy as before.  Presuming the RMAN image copy is already writing to XtremIO we’ll already have a deduplication ration of 2:1.  So when we add a 3rd copy, we’ll be at a ration of 3:1.  This clone can be housed on the same server as the source database or an entirely different server.

After allocating XtremIO ASM disk groups to the server we can easily make this new database. To make a clone of DBSRC as a new database called DBCOPY first need to add an entry to /etc/oratab similar to “DBCOPY:/oracle/product/11.1.0/dbhome_1:N” to allow it proper environmental variables to be via the “oraenv”.  Next you’ll need to make a copy of the parameters files for SBSRC in ORACLE_HOME/dbs for DBCOPY. You’ll need to modify the new parameters files to account for the new file destination, file names, and database name. You’ll also need to make the adump, cdump, and trace directories from the newly modified server parameters.

Next you need to start DBCOPY in a “no mount” state, which means Oracle reads/verifies the parameters files, allocates the memory areas, and starts background processes. At this point all that is left to do is perform your RMAN tasks: connect to the auxiliary COPYDB, create a connection to the source, and initiate the clone (duplicate) process.  Once the duplicate process is complete, check the XtremIO GUI and you’ll see a 3:1 deduplication ratio.

I’ve been able to push over 230k IO/s on a single XtremIO brick,  which is more than enough performance to handle many copies of many database instances. With proper use of RMAN not only can we gain a huge boost in Oracle performance with XtremIO, but also better manage our capacity using space efficient clones.