Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Gather IO stats

Re: Gather IO stats

From: Charles Hooper <hooperc2000_at_yahoo.com>
Date: 30 Jul 2006 14:30:46 -0700
Message-ID: <1154295046.244923.159250@i3g2000cwc.googlegroups.com>


Sybrand Bakker wrote:
> I see, you are actually re-inventing the wheel...
> The functionality you are building is available in 10g, and in several
> other products.
> Obviously using the commercial alternative is cheaper than you
> reinventing the wheel.
> Probably someone should tell you to stop reinventing the wheel, and
> make sure you spend your employer's time no longer on exercises in
> futility.
>
> Sybrand Bakker, Senior Oracle DBA

Available in 10g? Some of the information can be viewed in 10g, with the additional cost Database Diagnostics Pack that can only be added to the Enterprise Edition of Oracle. The Active Session History capabilities in 10g would be nice to have also - yes the ASH information is recorded in the database even when the Database Diagnostics Pack is not enabled.

What I described about the program is roughly 5% of its capabilities - those capabilities provide a direct indication of why Statspack reports are not sufficient. The program also parses 10046 trace files at level 8 (I could send the trace files to Hotsos, but why should I do that), builds data dictionaries, analyzes the database for various problems, etc.

Its not about reinventing the wheel. Rather, it is about understanding the system, why it behaves as it does, where are the bottlenecks, and when is the database instance responsible for less than 1% of the time to perform an activity that takes far too long to complete. An analogy: assume that the employees where you work call to report that the ERP software that they use can no longer access the Oracle database. Do you: #1 pay an outside consultant (pre-existing software) to come in and fix the problem for the short term, #2 restart the server because that seems to fix all problems, #3 dig into the details of what is happening in the system in order to build your knowledge base rather than calling in outside help or ignoring the problem (restarting the server), you are able to attack the problem at its source to either prevent the problem or minimize the chances of its recurrence. I would guess that the majority of the people in this group would want to investigate the problem.

This has been an interesting discussion.

Charles Hooper
PC Support Specialist
K&M Machine-Fabricating, Inc. Received on Sun Jul 30 2006 - 16:30:46 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US