Re: awr history

  • From: kyle Hailey <kylelf@xxxxxxxxx>
  • To: Karl Arao <karlarao@xxxxxxxxx>
  • Date: Thu, 13 Jan 2011 11:24:26 -0800

Awesome list on GC queries. GC data is something I've been meaning to look
into for a while, though not so much because I want to harness it but more
because I want to understand GC's data limitations.

OEM made the bizarre decision to recreate a data repository for GC, and
recreate it in what I consider an emaciated  inefficient way , instead of
extending AWR into GC.  AWR is  architected for multidatabase use. Here is
an example blog on exporting and importing AWR<>

AWR (including ASH) is a wealth of information and I would personally
concentrate on mining AWR for data and working on a system for centralizing
AWR data.

- Kyle

On Thu, Jan 13, 2011 at 9:00 AM, Karl Arao <karlarao@xxxxxxxxx> wrote:

> Hi Ed,
> Interestingly, just last week I was talking to a friend who has worked with
> Oracle on the Capacity and Performance management team.
> They were mainly doing predictive analysis, workload addition/reduction
> analysis, server consolidation type of engagements for hundreds of clients
> and thousands of servers. So to have an accurate analysis and be able to
> apply models they need to keep data samples and all sorts of metrics, and
> according to him they have a custom java app that collects data directly
> from the "em agent daemons" either from EMGC or Database Control and stores
> it on its own database that has around 3years of retention. For graphing and
> modeling purposes, they just get the of data they need (particular workload
> periods) where the web based interface will output it in xls format.
> Well I didn't know of that em agent trick... and from the collection
> perspective I think that is efficient. Interesting, but I have to know what
> are those underlying tables, the kind of data, and how I could make sense of
> it..
> A quick search got me to the links below:
> As for the AWR scripts, the underlying tables are the same tables that the
> usual AWR reports pull data from. I just derived and presented the relevant
> data ( in
> a time series manner and you can also build a central data store of this
> perf data but the difference is you are not bringing it all over, you
> already have the summarized output ready for the reports (
> BTW, Thanks Kellyn!
> --
> Karl Arao

Other related posts: