« Why thin provision does not work for Oracle data | Main | To RAC or not to RAC? That is the question. »

August 28, 2007

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)

The comments to this entry are closed.

Powered by TypePad
View Jeff Browning's profile on LinkedIn

disclaimer: The opinions expressed here are my personal opinions. I am a blogger who works at EMC, not an EMC blogger. This is my blog, and not EMC's. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC.