An excellent article on using Oracle with thin provisioning

vSphere has been getting a lot of attention this week for its inclusion of thin provisioning. It was a great validation that this important technology has made it into the maintream.  Of course, mileage with different thin provisioning implementations does indeed vary and we are always happy to show customers what makes 3PAR's so good. 

James Koopman at DCIG wrote an excellent short piece on preparing an existing Oracle database for running on thinly provisioned storage.

Here's a taste:

Recognize that the SHRINK command only compresses database objects and does not compress within table spaces or data files. As such, it may be beneficial, depending on how table spaces are being managed within Oracle, to look at the ALTER TABLESPACE...COALESCE and ALTER DATABASE DATAFILE...RESIZE commands for table spaces and data files respectively to eliminate all free space within Oracle data files before a migration.

Readers interested in understanding the performance of Oracle databases on highly utilized storage might want to read this white paper from Oracle's site.  Wide striping and thin provisioning together can be combined to get excellent performance and capacity results. In fact, when used with hardware assisted RAID 5, customers can get even better leverage of their capacity at a fairly small performance penalty, as the graphic below shows.  (from the Oracle/3PAR white paper)

Using RAID 5 (5+1) generates 85% of the performance of using RAID 10, but with a 20% capacity overhead - as opposed to a 100% overhead.  As you can see, there are a lot of ways to use 3PAR storage with Oracle databases to meet an organization's cost and performance objectives.

Comments

[John F.]

Hi Marc,

Interesting read. What did the IO patterns really look like. What's the read/write mix in the workload? How much of the improvement over a straight Oracle on RAID 5 can be attributed to ARM, and how much can be attributed to 3Par RAID ASICs and/or chunklets?

I do like the way that scaling isn't linear; the degradation at 3 spindles is 9% and by 9 spindles is 19%; nice. Someone's doing something right. How large can the RAID groups be? How does rebuild time impact performance and how does that scale with RAID group size? Inquiring minds want to know.

John F.

[marc farley]

Thanks John, I'll try to talk to some of the people involved in the tests to get more details for you. It was a joint white paper, but I think I can dig up most of them.

[nate]

Hey Marc - I was wondering if you guys would ever consider performing some SPC benchmarks with RAID 5 along side RAID 10 just to show the performance of the system.

I was just reviewing the latest F400 SPC results, and comparing against the Pillar results released a few months ago where the Pillar CEO(I think?) tried to slam 3PAR for having such an expensive solution(T800). Doing a cost per usable TB, the F400 not only trounces the Pillar configuration which is almost 3x more expensive($57k/TB vs $20k/TB), but also in performance as well(93k IOPS vs 64k IOPS). It may be higher still since the Pillar pricing assumes a 35% discount, I'm not sure what sort, if any discount the F400 pricing in the SPC report assumes.

There's a lot of folks out there(like me!) who use RAID 5.

On that note any idea why SPC benchmarks can't throw in the executive summary a quick cost per usable TB number? Sure it's a performance benchmark but it takes all of 10 seconds to do the math, and I think it is an important data point.

[marc farley]

Hi Nate,

As you know, almost all our benchmarks are run with RAID 10 to get the maximum results, but I agree it would be good to have RAID 5 results too. Its been discussed internally and its something we know people want to see. As far as posting the SPC cost per usable TB - I'm checking in with our benchmarking people. I agree it would be useful to have a $ per ASU number posted under the $ per IOPS.