Thank you for the link and feedback!

-Mark

That sounds like a great idea.

Yes, with most any monitoring method there is the potential for not only influencing the performance of what you intend to monitor, but also the performance of the entire database instance. Some types of monitoring, such as enabling a 10046 trace for a session, will have a small impact on the session being monitored, but little impact on the rest of the sessions. Other types of monitoring may significantly increase the competition for various scarce resources, such as the shared pool latch, library cache latch, and available CPU time. It is important to determine if it is worth wasting some of those scarce resources to help determine the root cause of a performance problem – in most cases it probably will be worthwhile (a phrase in Tom Kyte’s book comes to mind – what is the performance impact of the extensive instrumentation in Oracle Database – it has a *negative* performance impact) until approach the tipping point of what would commonly be called “compulsive tuning disorder”.

My monitoring tools do not directly connect to the SGA – for the most part they use the Oracle provided “free” performance views that are queried using a custom developed program. If you take a look at the “VBS” section of the blog archive for this site, you will find several articles were I almost reproduce some of the output of my Toy performance tool using simple scripts and a web browser:
http://hoopercharles.wordpress.com/archived-blog-articles/

Thanks again.

My toy project runs on a client PC running the Windows platform and connects to an Oracle database running on Unix, Linux, or Windows using ADO, and logs performance data to either a Microsoft Access compatible database that is created on the fly, or text files.

Because it is a client-side application, I had a bit wider choice of languages. When I started developing the program in 2002, I selected Visual Basic 6 as the programming language, tapping into the Windows API as needed. VB was selected because it allowed me to quickly build the user interface, and execute SQL statements that were then output to Microsoft Excel, a grid/table control on screen, or a custom developed chart control. Once compiled, the program is nearly as fast as a native C++ program, so performance is not much of an issue. It could be worse – I could have tried to use COBOL.

I have been using Visual Basic since 1994 (starting with the DOS version and VB 2.0) and wrote my first program in BASIC way back in 1982 on a computer that offered less memory than what is now the standard block size for Oracle databases.

Good luck with your project. My project also started out as a quick way for executing various “DBA 1.0″ scripts.

I currently have an Apex Application that I created for real-time troubleshooting. All of my “DBA 1.0″ scripts have been integrated into custom reports or PL/SQL that outputs HTML… I point it to any one of our 400+ databases and fire off the screens that I need to zero in on a problem.

I am working on a 10046 parser in Java that produces a graphical representation of SQL statement execution and wait times. Still have a bit of hacking to get it to the not-embarrassed-to-show-people-stage but hopefully it will be producing some useful output here soon.

Not trying to get into any language wars but I am curious, what language or environment did you write your tool in?
In the interest of easiness-to-deploy I try to stick with the Perl version that comes with Oracle … or a generic JRE since I can wrap everything needed for the utility into 1 jar file.

I have noticed that a lot of my fellow DBAs that are more operations oriented are loathe to take on a Python or TCL/TK install. Also I am currently working in Healthcare and software installed on our systems is tightly controlled so I could never get a recent Perl build with CPAN packages installed