RE: ASM rebalancing
Date: Fri, 19 Jun 2015 16:14:53 +0100
Message-ID: <EC65ECF8123FEE4D8FC5B212637C304001674730152B_at_EXCH1.morrisonsplc.co.uk>
Very interesting post Mark. My exposure to block movement is with HPs 3PAR Adaptive Optimisation. No doubt Mladen will comment on anything I say as he works for them but here goes anyway.
In our environments we have 3 tier storage - SSD , fibre channel and nearline/SATA disk disks which should be aligned to fastest/fast/not so fast
I have a few problems with the AO method of working. It is reactive - it looks at a days activity notes the busy blocks and then moves them up a level. That means on a system that does most of its work processing a daily workload it is always behind the curve. It works on blocks only. From a change control and management perspective I want to know if a file has been moved between tiers of storage, not some blocks. There is no reporting I am aware of that can tell which file blocks have come from and even if there is that would not help me. If performance of a process has deteriorated then I really would like to be able to tell if it is because of any AO changes but my experience tells me that is not possible.
Therefore I see the principle of ADO as being interesting but like Mark suggests I don’t necessarily want it from ASM
John
www.jhdba.wordpress.com
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mark W. Farnham
Sent: 24 May 2015 18:05
To: oracle-l_at_freelists.org
Subject: RE: ASM rebalancing
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
Wm Morrison Supermarkets Plc is registered in England with number 358949. The registered office of the company is situated at Gain Lane, Bradford, West Yorkshire BD3 7DL. This email and any attachments are intended for the addressee(s) only and may be confidential.
If you are not the intended recipient, please inform the sender by replying to the email that you have received in error and then destroy the email. If you are not the intended recipient, you must not use, disclose, copy or rely on the email or its attachments in any way.
This email does not constitute a contract in writing for the purposes of the Law of Property (Miscellaneous Provisions) Act 1989.
Our Standard Terms and Conditions of Purchase, as may be amended from time to time, apply to any contract that we enter into. The current version of our Standard Terms and Conditions of Purchase is available at: http://www.morrisons.co.uk/gscop
Although we have taken steps to ensure the email and its attachments are virus-free, we cannot guarantee this or accept any responsibility, and it is the responsibility of recipients to carry out their own virus checks.
†Ûiÿü0ÁúÞzX¬¶Ê+ƒü n– {ú+iÉ^ Received on Fri Jun 19 2015 - 17:14:53 CEST