My mistake, I thought Mladen worked for 3 @ar wheras he works for Commvault,
which we also use. Comments welcome either way.
----- Original Message -----
From: John Hallas
To: mwf@xxxxxxxx <mwf@xxxxxxxx>; oracle-l@xxxxxxxxxxxxx <oracle-l@xxxxxxxxxxxxx>
Sent: Fri Jun 19 16:14:53 2015
Subject: RE: ASM rebalancing
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Mark W. Farnham
Sent: 24 May 2015 18:05
To: oracle-l@xxxxxxxxxxxxx
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.
______________________________________________________________________
