Lots of good insights and responses in this thread. But I have a question:
Why do so few people copy database metric data to a non-production
machine? (And AWR is just a start.)
Shouldn't every DBA and/or DBA team have a DBA's data warehouse? Why
use production cpu cycles to analyze anything but real time or near
real time concerns?
Why wonder about year-over-year trends when you can know? Wouldn't
improved ability to make a capacity plan based on actual data more
than pay for any associated costs?
mwf
------------------------------------------------------------------------
*From:* oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Carol Dacko
*Sent:* Friday, June 25, 2010 5:10 PM
*To:* mark.teehan@xxxxxxxxxxxxxxxxx
*Cc:* oracle-l@xxxxxxxxxxxxx
*Subject:* Re: Long term AWR retention
Mark,
We use 6 month retention with 15 minute snapshots. No problems! It
has been very helpful to have the history available to us.
Carol Dacko
University of Michigan
On Thu, Jun 24, 2010 at 10:24 PM, Teehan, Mark
<mark.teehan@xxxxxxxxxxxxxxxxx <mailto:mark.teehan@xxxxxxxxxxxxxxxxx>>
wrote:
I am considering increasing AWR retention from the default 7 days to
a longer period; possibly 60 days. A longer cycle fits in better with
systems that have monthly reporting cycles. Apart from increased
space use in sysaux, leading to longer full backup times; I cannot
think of any other negative effects. All AWR base tables are range
partitioned; and I trust that all queries accessing them are
configured to partition prune properly.
I cannot find any evidence in MOS or the interwebs that this could be
a bad thing to do: has anyone been burned by this before?
Thanks!
Mark Teehan
Singapore
==============================================================================
Please access the attached hyperlink for an important electronic
communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================
