Comments on: Tracking Parameter Changes

By: osborne

osborne — Tue, 26 Jan 2010 17:42:41 +0000

Interesting. Thanks for your comments.

Kerry

By: Fred Habash

Fred Habash — Tue, 26 Jan 2010 16:44:33 +0000

How many snaps do you include in the weekly baselines?
Since baselines are primarily used for trending and capacity planning (vs. specific incident troublshooting), we wanted to represent a typical work day, so we chose Mondays between 7:00 and 17:00.

By: osborne

osborne — Tue, 26 Jan 2010 16:19:52 +0000

Fred,

Ah, makes sense. One hour snapshots seem to work well for me during normal steady state operations. I have increased to 15 minutes when dealing with troublesome systems, but only for short periods of time. But it makes sense to use baselines with that volume. How many snaps do you include in the weekly baselines?

Kerry

By: Fred Habash

Fred Habash — Tue, 26 Jan 2010 14:48:43 +0000

I thought I can also add this remark based on our experience. Initially, we opted to go with the default of 1 hour, but we found out that it is not providing us the resolution we needed to zoom in on brief and sporadic performance issues. We now set our snapshots to occur every 15 minutes. This is another reason we decided to go with baselines since our snapshots are too granular as compared to the default.

By: osborne

osborne — Tue, 26 Jan 2010 00:05:19 +0000

Fred,

Baselines are a good idea, although they have been a bit flakey for me, at least in 10.2. I really think a year is not unreasonable for a large database though, maybe with quarterly baselines of a couple of days going back another year. I don’t think too many people are familiar with AWR Baselines as I rarely see them. Thanks for the input.

Kerry

By: Fred Habash

Fred Habash — Mon, 25 Jan 2010 21:44:18 +0000

One other option I’ve been exercising is keep awr data for 90 days. In addition to that, we generate weekly awr baselines which are excluded from awr purging. We keep these baselines for 3 years. This is a nice balance between allocating too much storage and wanting to keep a longer history.

By: Gord Irish

Gord Irish — Thu, 31 Dec 2009 21:15:48 +0000

Kerry

I agree, something like a year would be reasonable. Right now, I’d like to be able to compare Dec 2009 with Dec 2008 to see what’s different but of course Dec 2008 is long gone. ( Unless I can convince a UNIX admin to pull some old backups and load them onto another system.)
Currently I only keep 30-60 days like you do. After the Christmas break I’m going to look into uping that to something like 365-400 days. For the big 100GB+ systems it should not be a big issue but some of these databases serve manufacturing processes and only hold a small amount of data in flight. For those I really can’t store any more statspack data but these are the ones with the most interesting performnace issues of course. I’ll have to try some sort of centralized scheme like I was talking about, I’ll have to get working on that…

Gord

By: osborne

osborne — Tue, 29 Dec 2009 17:09:55 +0000

Gord,

After looking into how much space is required by the data, I am in favor of keeping a much larger window of data than I was previously. For the past few years I have pushed for 30-60 days of history. But I’m thinking now that a year is not at all unreasonable. I like your idea of combining the data from multiple databases into a centralized location. I have not seen anyone do that either.

Kerry

By: Plans gone AWRy; an invASHtigation; OraStory

Plans gone AWRy; an invASHtigation; OraStory — Tue, 29 Dec 2009 16:49:50 +0000

[...] Post discussing bind variable peeking issue and the uses of AWR/ASH data to help resolve them [...]

By: Gord Irish

Gord Irish — Tue, 29 Dec 2009 02:31:20 +0000

I was just working on something that involved AWR (or Statspack ) retention. I was given about 75 statspack reports and asked to work up some Excel graphs of anything I found significant. At first I thought that I would have to copy all that data off the reports and into Excel to do the analysis and graphng. Groan. Lucky for me, in this case, the statapack data was still on the database so I was able to run some queries to extract what I needed into Excel.

But what if I had been given this task for data that had aged out of the statspack tables? Then I would have been stuck. At the same time, I can see the value in the types of analysis that could be done with a few years of AWR/statspack data. It could be useful to track paramter changes over time, it could useful to compare performance this month with the same month last year, etc, etc. But a lot of us don’t want to store all that statspack data in our production systems.

Which leads me to wonder about using some data warehousing techniques to extract this data to a data warehouse. The data ought to be easy to extract as it is all keyed by snap_id. As you show, by data warehouse standards, it is also not a large amount of data so even a modest DW server could hold a few years worth. I believe all the AWR/statspack data is actually keyed by db_id/snap_id so it should be possible to store this data from multiple databases in one DW and so some cross-system analysis, which might also be interesting.

It also seems to me that someone else has already done this but so far I haven’t found any references to it.