Re: DBA_HIST_SYSMETRIC_HISTORY and metric I/O Megabytes per Second
- From: LS Cheng <exriscer@xxxxxxxxx>
- To: Robin Moffatt <Robin.Moffatt@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 13 May 2011 19:56:28 +0200
Hi
The 1200MB, 1400MB throughput is constant, this is a real time DWH. In fact
my snaps to v$sysmetric shows this data.
Also DBA_HIST_SYSMETRIC_HISTORY suppose to show data per minute which is
even better the snaps I programmed (every 5 minutes)
But anyway anyone has access to a production db with decent load and can
query this data for me :-?
Will be great
Thanks!
On Fri, May 13, 2011 at 12:56 PM, Robin Moffatt <
Robin.Moffatt@xxxxxxxxxxxxxxxxxx> wrote:
> I think it depends on the period over which you’re taking the average
> number
>
>
>
> Unless you’ve got a sustained load at the rate you are observing in an
> instant, then you won’t see this in the AWR averaged figure. So the 1200MB/s
> that you cite, for how long of the AWR snapshot period was it at 1200MB/s?
>
>
>
>
> http://rnm1978.wordpress.com/2010/09/14/the-danger-of-averages-measuring-io-throughput/discusses
> this, and also includes a link to a script by Kevin Closson which
> is good for recording throughput data at a lower time granularity so you can
> see the actual demand on the IO system, not an average.
>
>
>
>
>
> Thanks,
>
>
>
> Robin
>
> --
>
> http://rnm1978.wordpress.com
>
>
>
>
>
> *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
> oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *LS Cheng
> *Sent:* 13 May 2011 08:19
> *To:* dmann99@xxxxxxxxx
> *Cc:* oracle-l@xxxxxxxxxxxxx
> *Subject:* Re: DBA_HIST_SYSMETRIC_HISTORY and metric I/O Megabytes per
> Second
>
>
>
> Hi
>
> I am using ASM.
>
> I am measuring database I/O bandwith throughput, I had a script whcih snaps
> v$sysmetric every 5 minutes, I was thinking to stop using it and instead
> query this metric but it doesnt seem correct numbers!
>
> Thanks
>
> --
> LSC
>
> On Fri, May 13, 2011 at 4:33 AM, David Mann <dmann99@xxxxxxxxx> wrote:
>
> >Hi all
> >Anyone know if the metric I/O Megabytes per Second is valid in
> >DBA_HIST_SYSMETRIC_HISTORY at version 11gR1?
> >I am checking some I/O throguhput in a pretty loaded system (around
> >1200MB/sec) and this metric shows some really low value like 6MB/sec!
>
> How is the storage with your datafiles attached? I was looking for
> similar information in OEM to match up with iostat numbers I was
> observing on some NFS mounts... but at least in this case OEM only
> 'knew' about locally attached drives, not the NFS mounts where the
> real action was happening. So I observed something similar, busy
> database but OEM was only telling me about the light activity going on
> locally (Oracle binaries and OS activity). Maybe we are seeing
> something similar?
>
> -Dave
>
> --
> Dave Mann
> www.brainio.us
> www.ba6.us - Database Stuff - http://www.ba6.us/rss.xml
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
> ______________________________________________________________________
> 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.
> ______________________________________________________________________
>
Other related posts:
