Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: To use SAME or NOT for High End Storage Setup ?

RE: To use SAME or NOT for High End Storage Setup ?

From: Kevin Closson <>
Date: Thu, 11 May 2006 08:45:11 -0700
Message-ID: <>


>> Do vol mgr's nowadays have the ability to "rebalance" the volumes ala ASM to avoid this? And if so, presumably you're still up for a nasty IO spike whilst it occurs ?

Great question. Sadly, few will read this response.

The challenge of accommodating "adding a few more disks" to a huge diskfarm is valid, but the topic was S.A.M.E. I say any technology that addresses the need to occasionally add some disks and rebalance (ODDR) should do so...while maintaining the SAME methodology.

ODDR (online dynamic data re-distribution) and any associated "rebalancing" I/O spike is not a fundamental problem with is an implementation detail. It seems the only ODDR technology you have exposure to is ASM. If you aren't happy with how ASM does it, just be happy that ASM can't do ODDR for, say, Petabytes of flat files ala bio-informatics, seismic, etc...

Do volume managers do rebalancing? They always have, at least all the ones I've worked with. You change the geometry of one of the mirror plexes and resilver, but that is crude. However, while it may be crude, it works for ANY and ALL data and ASM doesn't. Some people have mentally ascended to accept the fact that not all of the worlds data goes into any (more less Oracle) RDBMS. In fact, by good estimate, only 15% of it does.

Solving the problem of ODDR is not an Oracle problem. If you choose the ASM approach to solving this problem, you will eventually have to figure out how to do it for all the other data in your datacenter. That is why a general purpose approach is better in the end.

I'll use our products as an example. We support online volume growth and online filesystem growth. Our upcoming release will support ODDR and much more storage QOS technology than ODDR. ODDR is a hammer when a scalpel is more often needed. I'll explain (chirp chirp, you can hear a cricket chirp, the room is silent and empty).

If you have data in a 100 disk volume and add 5, you have added 5% capacity (provided all are the same size), but did you add 5% bandwidth? Most likely not. The 5 disks are likely behind the same overloaded array controller so you really are just talking about 5% more round-brown capacity. The question becomes whether it is actually smart to redistribute for the sake of 5% capacity addition. What if, on the other hand, the 5% capacity you added was from some newer generation storage or device type that was, say, 300% faster than the old 100 drives? Do you want to do a generic ODDR? Or pick out the hardest hit data and ODDR it?

It goes like this, just because ASM has some RAID characteristics, that doesn't make it a volume manager. Likewise, just because it stores "files" that doesn't make it a filesystem. Finally, just because it has rudimentary ODDR, it is not storage QOS.

PolyServe QOS will not be done in the volume manager anyway. Storage QOS is best implemented in the filesystem level. Ours will certainly support ODDR, but more importantly it will support adding different storage speeds to an existing volume and the ODDR action will be to redistribute data that actually would benefit by being redistributed. And, all this for all files. Not just thingies that comprise an Oracle database.

Received on Thu May 11 2006 - 10:45:11 CDT

Original text of this message