RE: ASM rebalancing

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Sun, 24 May 2015 13:05:29 -0400
Message-ID: <241101d09643$d6cc41b0$8464c510$_at_rsiz.com>



Evaluation of "hot spots" often has a different meaning than what Automatic Data Optimization (ADO) is concerned with in the longer term. I would say that ADO is more concerned with finding the cold spots.

For the long haul ADO is well coupled with advanced compression and handles the idea of the large fraction of databases that are often less busy as they age (or for other reasons, but primarily, I'll claim, for being older). Then if you have defined storage that is (probably less expensive and great for large acreage) ADO figures out what can be moved to "lower" classes of storage. At this minute I'd say the classes generally available are 1) True RAM SSD, 2) Highly RAM cached flash SSD arrays, 3) uncached flash SSD arrays, 4) Hybrid arrays (some percentage cached in flash SSD by the hardware of a larger total acreage on spinning rust), 5) traditional spinning rust arrays, 6) jbod spinning rust, 7) tape robots (which may include spinning rust cache for the ribbon rust).

This is a bit of over simplification because any of these might be available in vendor arrays with varying software and amounts of array cache. Most installations only have 1, 2, or 3 "classes" installed and tape might not be automated (it would be a bad choice to put database volumes on non-robotic fully automatic tapes).

The idea is that if you can put the bulk of your storage on something much cheaper without affecting the usual latency on stuff frequently needed urgently, then there is a good chance you can save money (and possibly use some of that savings to buy a faster grade of the sites "first class" storage).

Avoding "Hot spots" in my career are what the software developed by Terascape (later purchased lock, stock, and barrel by EMC) was designed to do: Find the actual Oracle segments creating a high fraction of the i/o demand per acre of storage required so you could arrange to manually move them to a special class of faster, more expensive hardware and thus "de-heat" the rest of your disk farm. That was a bit trickier back in the day before Oracle even reported individual segment i/o.

ASM is primarily a volume manager designed so an Oracle DBA does not need to learn the esoteric details of each possible piece of storage hardware and vendor or OS supplied volume manager. In my opinion adding hot spot analysis to ASM would be a mistake since ASM should be as lean, simple, and bulletproof as possible as it stands in a layer of the architecture that is fundamentally an operating system utility.

mwf

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mladen Gogala (Redacted sender "mgogala_at_yahoo.com" for DMARC) Sent: Sunday, May 24, 2015 1:40 AM
To: oracle-l_at_freelists.org
Subject: Re: ASM rebalancing

On 05/22/2015 11:17 AM, Seth Miller wrote:
> Malcolm,
>
> What you're asking about does exist, it just exists in the database
> (Automatic Data Optimization) itself instead of ASM.

Hi Seth,
Automatic data optimization is a 12c feature which requires an advanced compression option. Regards,

--
Mladen Gogala
Oracle DBA
http://mgogala.freehostia.com

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l
Received on Sun May 24 2015 - 19:05:29 CEST

Original text of this message