RE: Accessing ASH is slow
Date: Mon, 29 Jul 2013 08:20:41 +0100
Message-ID: <EC65ECF8123FEE4D8FC5B212637C304001662454DE1F_at_EXCH1.morrisonsplc.co.uk>
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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] 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.
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Jul 29 2013 - 09:20:41 CEST