Re: awr history

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

http://gavinsoorma.com/2009/07/exporting-and-importing-awr-snapshot-data/<http://www.google.com/url?q=http%3A%2F%2Fgavinsoorma.com%2F2009%2F07%2Fexporting-and-importing-awr-snapshot-data%2F&sa=D&sntz=1&usg=AFrqEzetysh686_DwbbjYufMLXmTzyRZ9w>

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
http://dboptimizer.com





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:
> http://www.pythian.com/documents/ExtendingOracleEnterpriseManager10g.pdf
>
> http://jhdba.wordpress.com/2010/09/03/using-grid-to-display-database-cpu-usage/
> http://jhdba.wordpress.com/2010/06/21/producing-a-grid-report/
> http://oracleobserver.com/?q=node/23
> http://lianggang.wordpress.com/category/grid-control/
> http://coskan.wordpress.com/2009/06/11/how-to-use-sysman-schema-without-em/
>
> 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 (http://karlarao.tiddlyspot.com/#%5B%5BPerformance%20Formulas%5D%5D) 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 (
> http://goo.gl/wUhF4).
>
> BTW, Thanks Kellyn!
>
>
> --
> Karl Arao
> karlarao.wordpress.com
> karlarao.tiddlyspot.com
>

Other related posts: