In my last post, I explained why I think thin provisioning is fairly useless for most Oracle database environments. I have been taking a bit of heat for this post, mostly from my good friend Barry Burke (AKA The Storage Anarchist). Given the respect and affection I have for Barry, I thought it might be worthwhile to put up a clarifying post, pointing out some of the areas where Barry believes thin provisioning is a really, really good thing for many usages cases he commonly sees. I think he makes some reasonably good points.

Bear in mind that I work in the Commercial program within EMC. That’s the set of customers who have revenues of between $25 million and $1 billion. These are most definitely low-end to mid-range customers. Barry works for the Symmetrix group, which largely address what we call the Enterprise customers (revenues of greater than $1 billion). This is a vastly different type of customer from mine. Admittedly, in my defense, the Commercial space accounts for the vast majority of business activity and technology spending in this country. So I have a bit of a bias here. However, EMC has traditionally served the Enterprise customer base more, and thus our customers are clustered in that direction. And there is also no question that Barry’s customers are the more well-heeled, household name type customers. In other words, most of the global financial services, telecommunications, insurance and manufacturing companies you probably know and love.

So let’s examine the usage cases between the two sets of customers. Taking the Commercial space first since that is what I am most familiar with. These customers have some of following characteristics:

1. Small IT organizations with minimal politics and bureaucracy
2. Limited budget
3. Smaller allocations of storage due to cost constraints
4. Granularity of the typical database space allocation is a significant percentage of the total space on the array 

Take an example of an application where the DBA has requested 100 GB of space, and has stated he or she will need 500 GB of space eventually. The storage administrator in a thin provisioning context would tend to allocate space as shown in the following graphic:

In this graphic, you see that the storage administrator has given the DBA a thinly provisioned LUN of 500 GB in size. On an array with a few TB, that’s a significant amount of storage. I see that kind of allocation all the time. The DBA has created a database on the LUN with 100 GB of datafiles, again not an atypical size. The thinly provisioned LUN is backed up by 150 GB of space.

On the next occasion where the DBA needs additional storage, he or she would tend to do something like the following:

Here, the DBA has allocated an additional 100 GB of space, probably by creating one or more datafiles. This pushes the thinly provisioned LUN over the edge. The storage administrator must now add storage to the LUN. Further, the DBA’s request to create files has been denied, much to his or her chagrin. After all, the DBA thinks he or she has 500 GB of space.

This is the dark side of thin provisioning. Like I said, thin provisioning is lying. Sometimes you get caught. The times you get caught are the times when the granularity of the additional space required by the user (in this case the DBA) is a very significant fraction of the total space in the LUN. Since Commercial DBAs tend to do that, that makes thin provisioning a risky proposition at best, and of questionable value, since the DBA will end up interfacing with the storage administrator in this case anyway. No saving in terms of administration here.

Now let’s look at a usage case that Barry pointed out to me where thin provisioning works very well for a large Enterprise customer. These customers have the following characteristics:

1. Large IT organizations with lots of politics and bureaucracy
2. Larger budgets with less stringent cost constraints
3. Larger amounts of storage available on larger arrays
4. Granularity of the space demanded by the DBA for a typical Oracle database space allocation (as in creating a new datafile) is a small percentage of the total space on the array

Point 4 is the key. In my first post, I said that thin provisioning works very well for file systems with unstructured data where the size of the marginal file is a small percentage of the array. In the case of an Enterprise class customer, the array is so huge that even a database allocation looks like a file on a file system. Let’s look at one such scenario, as illustrated by the following graphic:

In this scenario, we have many, potentially hundreds, of apps being stored on the array. Each app has far greater provisioned space than they have utilized space. They are being stored on a fairly huge pool of physical storage as well. These may be testing or development databases, where careful configuration of the physical storage is less important. Further, the marginal granularity of each additional database space allocation is tiny compared to the total magnitude of the storage available. In this case, thin provisioning actually works very well, and provides some important benefits. In large organizations where the lead time to get additional space allocated is very long, it will save the DBA lots of time and headaches. Further, where there is a lot of political issues and the storage and database groups do not like or trust each other, this will significantly smooth the way for the DBA in getting storage for his or her database. Another benefit is free space pooling. While the apps each grow, they grow at different, somewhat unpredictable, rates. Giving them each a big thin provisioned LUN allows them to grow somewhat unfettered. As they grow physically, they are able to share the free space. This improves utilization significantly. This is the real main thrust of thin provisioning.

Thus, the critical issue is the size of the average additional space allocation from the DBA compared with the size of the array. If this is a small percentage, then thin provisioning works well, and provides important benefits. This tends to be true with larger customers who have larger arrays. In smaller customers, thin provisioning may be of less benefit.

Comments

[Greg]

Please keep posting...

This is very interesting reading.

I'm currently involved in making an EMC purchase...

If you have any Linux tips then post those as well

Thanks

[Neil Greene]

The analysis of store provisioning is very accurate. And it gets worse. The DBA reacts to business and in early stages of a project is going by developer or some business analysis guesstimates on storage requirements which are always wrong. Bad data in, bad data out. The issue here is the bad data trickles over into other disciplines, or in the case of a large enterprise company, other departments with different budgets and mangers with different targets.

What happens today? Someone sizes an environment. Then, someone guesses at what is going to be needed based on phase 1 of the rollout. Project slips, requirements change. Have you ever seen any project go back through the process of the "sizing" spreadsheets. No. Those things are a joke. Sizing spreadsheets are a waste of time and come no where to reality. Now the DBA provisions storage based on the initial projections. Which were either vastly wrong, way off or now changed due to implementation needs. Point being, it is all guesswork. And the use of filesystems and databases management leaves a lot of room for error in this methodology.

So, part of the issue has to do with managing storage at a database level and not an enterprise level. Which can roll up to a department's budget if they bought their server and storage. At the enterprise level you can gain economies of scale and use in pre-production environments by using Oracle10g's Automatic Storage Management(ASM).

With ASM you could provision storage as a pool for the databases across single instance or RAC configured databases. By pooling the storage, and using ASM you align the usage of the resource, in this case storage, with the allocation, performance and management of the resource. And unlike datafiles and filesystems, the overhead management at the host level goes away and it becomes easier to manage the needed storage volume. All you worry about now is the "enterprise" or "pooled" usage of the volume groups. And this includes RMAN backup sets, flash recovery, datafiles, archivelogs and redologs. RAC or Non-RAC, 1 instance or several instances.

This one feature aligns the usage and management of storage with the business needs that dynamically change. This is irrespective of Commercial or account over $1b. They all, small and medium sized business to the largest global company are working with the same issues. Now, there is no need for a strategy for Commercial IT vs. Strategic IT, it is all the same.

ASM has its own hurdles. Luckily for me, I am knowledge in the area of storage management, volume managers and databases. Larger companies, will have different teams managing all of these components. So, the thought that the DBA now manages their storage is very new to chew on. And rightfully so, some DBAs should not be managing storage at this level. (Sorry fellow DBAs)