RE: Accessing ASH is slow
- From: John Hallas <John.Hallas@xxxxxxxxxxxxxxxxxx>
- To: "mwf@xxxxxxxx" <mwf@xxxxxxxx>, 'ORACLE-L' <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 29 Jul 2013 08:20:41 +0100
I have just presented a talk at a UKOUG SIG about how we built our AWR
repository and the benefits we have achieved.
There are two main points that I would make
It can be cost neutral - you don't need a multi-CPU server, most of the time
you will be running single queries and you wont have many users who can logon.
More importantly disk can be tier 3 and by compressing the loaded AWR (and ASH)
data along with reducing the retention of production to 7 or 14 days then no
additional disk is required.
Secondly, once you have the repository it can be used for a number of reasons -
holding performance test data, comparing performance pre-release with
post-release, capturing OEM unix data and storing that etc etc.
John
jhadba.wordpress.com
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Mark W. Farnham
Sent: 22 July 2013 20:00
To: 'ORACLE-L'
Subject: RE: Accessing ASH is slow
I defy anyone to state a useful operational definition of "best practice"
that is not self-contradictory. (For starters, knowing that something is
"best" requires either a logical construct with agreed premises that proves
no other practice can be better, or else an enumeration of all possible
practices and agreement that each of them is inferior. I suggest you try for
perpetual motion first.) That pet peeve out of the way:
I personally think it is a bad practice to consume production RDBMS cycles
doing ad hoc analysis of metrics.
Rather, I would suggest that such data should be copied (meaning some data
transport, but reading any given window of data only once) into a
datawarehouse for the DBA.
The destination schema would of course *NOT* be sys, Gormanesque scaling to
infinity is plausible, and you can feel free on your DBA datawarehouse to
add indexes and aggregates to your heart's content.
Note that I have not opined on standard reports that pretty much scan
everything once occasionally (like ADDM) as regards consuming production
resources, nor on the expense of collection of the standard metrics now
built into Oracle. If you're licensed to use them, it seems likely the
collection of such metrics is worthwhile, even if only for the insurance
value that they exist. (If you're not licensed to use them that is a
financial statement on the value of performance to your organization. Since
your question involves ASH, it seems likely you have the appropriate
licenses.)
IF Oracle provided an option to deposit metric collection results in a
destination other than the production database, I tend to think that would
work out nicely in conserving overall throughput (though there is
potentially a network traffic argument if the repository is off of the
physical host of the production database.)
Of course if the resources to set up a warehouse for the DBA are not
available, then you're stuck on the production database. Whether pulling SYS
contents you want to repeatedly analyze into a different schema you can
safely manipulate is an effective strategy probably varies from case to
case.
mwf
______________________________________________________________________
Wm Morrison Supermarkets Plc is registered in England with number 358949. The
registered office of the company is situated at Gain Lane, Bradford, West
Yorkshire BD3 7DL. This email and any attachments are intended for the
addressee(s) only and may be confidential.
If you are not the intended recipient, please inform the sender by replying to
the email that you have received in error and then destroy the email.
If you are not the intended recipient, you must not use, disclose, copy or rely
on the email or its attachments in any way.
This email does not constitute a contract in writing for the purposes of the
Law of Property (Miscellaneous Provisions) Act 1989.
Our Standard Terms and Conditions of Purchase, as may be amended from time to
time, apply to any contract that we enter into. The current version of our
Standard Terms and Conditions of Purchase is available at:
http://www.morrisons.co.uk/gscop
Although we have taken steps to ensure the email and its attachments are
virus-free, we cannot guarantee this or accept any responsibility,
and it is the responsibility of recipients to carry out their own virus checks.
______________________________________________________________________
--
//www.freelists.org/webpage/oracle-l
Other related posts:
