I’ve seen plenty of blog posts and discussions over the years about the need to increase the default AWR retention period beyond the default value of 8 days. Experienced Oracle folk understand how useful it is to have a longer history of performance metrics to cover an entire workload period so that we can, for example, compare the acceptable performance of the last month end batch processes to the living hell of the current month end. You’ll often hear a suggested minimum of 35-42 days and I could make good arguments for even more history for trending and capacity management.<\/p>\n
That subject has been covered well enough, in my opinion. (To pick one example, this post<\/a> and it’s comments are around 5 years old.)\u00a0 Diagnostics Pack customers should almost always increase the default AWR retention period for important systems, even allowing for any additional space required in the SYSAUX tablespace.<\/p>\n However, I’ve found myself talking about the best default AWR snapshot *interval* several times over recent months and years and realising that I’m slightly out of step with the prevailing wisdom on the subject, so let’s talk about intervals.<\/p>\n I’ll kick off by saying that I think people should stick to the default 1 hour interval, rather than the 15 or 30 minute intervals that most of my peers seem to want. Let me explain why.<\/p>\n Initially I was influenced by some of the performance guys working in Oracle and I remember being surprised by their insistence that one hour is a good interval, which is why they picked it. Hold on, though – doesn’t everyone know that a 1 hour AWR report smoothes out detail too much? <\/p>\n Then I got into some discussions about Adaptive Thresholds<\/a> and it started to make more sense. If you want to compare performance metrics over time and trigger alerts automatically based on apparently unusual performance events or workload profiles, then comparing specific hours today to specific hours a month ago makes more sense than getting down to 15 minute intervals which would be far too sensitive to subtle changes. Adaptive Thresholds would become barking mad if the interval granularity was too fine. But when nobody used Adaptive Thresholds too much even though they seemed like a good idea (sorry JB 😉) this argument started to make less sense to me.<\/p>\n However, I still think that there are very solid reasons to stick to 1 hour and they make more sense when you understand all of the metrics and analysis tools at your disposal and treat them as a box of tools appropriate to different problems.<\/p>\n Let’s go back to why people think that a 1 hour interval is too long. The problem with AWR, Statspack and bstat\/estat is that they are system-wide reporting tools that capture the difference (or deltas) between the values of various metrics over a given interval. There are at least a couple of problems with that that come to mind.<\/p>\n 1) Although a bit of a simplification, almost all of the metrics are system-wide which makes them a poor data source for analysing an individual users performance experience or an individual batch job because systems generally have a mixture of different activities running concurrently. (Benchmarks and load tests are notable exceptions.)<\/p>\n 2) Problem 1 becomes worse when you are looking at *all* of the activity that occurred over a given period of time (the AWR Interval), condensed into a single data set or report. The longer the AWR period you report on, the more useless the data becomes. What use is an AWR report covering a one week period? So much has happened during that time and we might only be interested in what was happening at 2:13 am this morning.<\/p>\n In other words, AWR reports combine a wide activity scope (everything on the system) with a wide time scope (hours or days if generated without thought). Intelligent performance folks reduce the impact of the latter problem by narrowing the time scope and reducing the snapshot interval so that if a problem has just happened or is happening right now, they can focus on the right 15 minutes of activity1<\/sup>.<\/p>\n Which makes complete sense in the Statspack world they grew up in, but makes a lot less sense since Oracle 10g was released in 2004! These days there are probably better tools for what you’re trying to achieve.<\/p>\n But, as this post is already getting pretty long, I’ll leave that for Part 2.<\/p>\n 1<\/sup>The natural endpoint to this narrowing of time scope is when people use tools like Swingbench for load testing and select the option to generate AWR snapshots immediately before and after the test they’re running. Any AWR report of that interval will only contain the relevant information if the test is the only thing running on the system. At last year’s Openworld, Graham Wood<\/a> and I also covered the narrowing of the Activity scope by, for example, running the AWR SQL report (awrrpt.sql) to limit the report to a single SQL statement of interest. It’s easy for people to forget – it’s a *suite* of tools and worth knowing the full range so that you pick the appropriate one for the problem at hand.<\/p>\n","protected":false},"excerpt":{"rendered":"