Most modern SAN units have diagnostic/monitoring software available. Sometimes
it is an extra-cost option, but whoever manages the SAN should be able to check
and potentially use the software to determine the health of the disk farm.
Also on many systems the administrator just identifies they want a chunk, such
as 1T, and the SAN unit takes care of where (which disks) are used to allocate
the space. So when you say "unit" did you mean an actual disk or the entire
SAN (in case where you have more than one)?
Mark Powell
Database Administration
(313) 592-5148
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> on behalf
of dmarc-noreply@xxxxxxxxxxxxx <dmarc-noreply@xxxxxxxxxxxxx>
Sent: Friday, April 12, 2019 10:23:57 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: System stats
Can you recommend any sort of monitoring to identify when a SAN is getting
overloaded? In our case it only became apparent when an app started
experiencing latency at the same time for 5-10 minutes every day and we tracked
it down to a batch job which was running on an entirely different cluster but
which shared the same storage unit. Storage denied it was their problem right
up until the point we proved it was.
It would have been nice to have known that before the problems started showing
up. Getting a new storage unit is a slow process.
Jay Miller
Sr. Oracle DBA
201.369.8355
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Neil Chandler
Sent: Tuesday, March 26, 2019 10:35 AM
To: Chris Taylor
Cc: gogala.mladen@xxxxxxxxx; ORACLE-L
Subject: Re: System stats
In the majority of places I have worked - 5 clients last year - the SANs were
overloaded in 4 of them. They are too frequently sized for capacity and not
throughput/response time. The response time was inevitably variable and System
Stats would not have been helpful on the systems they have. In one of the
clients, some of the critical DB's have dedicated storage but changing the
system stats would have had little to no effect on those systems due to other
measures having been put in place (including using a low optimizer index cost
adj on one system, meaning lots of index use. Just not necessarily the right
indexes.)
The optimizer tries to be all things to all people, and there's lots of
parameters to try to twist it into the shape that you want. The problem is
frequently the abuse of those parameters - especially the global ones - via
googling a problem, believing a silver bullet blog, and the lack of time to
prove the solution so we just throw the fix into the system. It can be
enlightening to strip the more extreme parameters back to their defaults and
see how the system copes.
As an aside, did you run your systems with the default parameters, discover
notable problems and then use the 2 sets of system stats to correct those
problems, or did you put them in from the start and everything was good?
There's a case to be made for using system stats, but I just don't think that
is something that should be used frequently.
Neil.
________________________________
From: Chris Taylor <christopherdtaylor1994@xxxxxxxxx>
Sent: 26 March 2019 12:59
To: Neil Chandler
Cc: gogala.mladen@xxxxxxxxx; ORACLE-L
Subject: Re: System stats
As far as the workload, I used 2 workload stats and swapped between them - one
for the day where the business hours and the off-business hours had their own
personalities (for lack of a better word).
As far as the SAN goes, if enough systems are hitting the SAN enough to cause
the IO rate/throughput to become affected, then its *probably* time for a new
SAN.
Chris
DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia
22102, USA.
DXC Technology Company -- This message is transmitted to you by or on behalf of
DXC Technology Company or one of its affiliates. It is intended exclusively for
the addressee. The substance of this message, along with any attachments, may
contain proprietary, confidential or privileged information or information that
is otherwise legally exempt from disclosure. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient
of this message, you are not authorized to read, print, retain, copy or
disseminate any part of this message. If you have received this message in
error, please destroy and delete all copies and notify the sender by return
e-mail. Regardless of content, this e-mail shall not operate to bind DXC
Technology Company or any of its affiliates to any order or other contract
unless pursuant to explicit written agreement or government initiative
expressly permitting the use of e-mail for such purpose. --.
