It’s finally here: Method R Trace for Oracle SQL Developer version 4. That’s right, Oracle SQL Developer version 4.

This was a tough one. The SQL Developer extension architecture changed so profoundly from version 3 to version 4 that Method R Trace was a near total rewrite, but now it’s ready. Now you’ll be able to create perfect Oracle 10046 trace files right on your workstation from the latest version of Oracle SQL Developer.

Our prior version, Method R Trace version 2, had two key features: (1) create perfect trace files on your workstation from SQL or PL/SQL you run in the Worksheet, and (2) copy other people’s trace files from the database server to your workstation. In the newest Method R Trace, we’ve included only feature 1. We just haven’t cracked the code on getting feature 2 to work with the Oracle SQL Developer version 4 architecture.

We hate to leave out feature 2, but we decided that releasing feature 1 today without feature 2 was a lot better of an option than waiting several more months to release them both. We think it’s the right compromise, because the important business of creating perfect trace files on your workstation from SQL or PL/SQL you run in the Oracle SQL Developer 4 worksheet is, at long last, mission accomplished.

If you are a Method R Trace, Method R Tools, or Method R Workbench customer, visit the Method R Trace web page for details on how to upgrade. I hope you enjoy.

Do you have SQL in your system that doesn’t use placeholders, like this?

[3r3dhkb0z824v] select stuff from t where id=18432...
[5wamvs45j6nh4] select stuff from t where id=4286...
[ih5x9lgg492nk] select stuff from t where id=329971...

Statements like these are generated dynamically by procedural programs written in Java, PHP, C#, etc. (or even PL/SQL if you work really hard). Programs that generate SQL statements like these create a lot of performance problems:

  • They spend too much CPU time on database parse calls;
  • They serialize on library cache and shared pool latches, which diminishes your application’s scalability;
  • They abuse the library cache, causing your application to consume way more memory than it ought to;
  • And they create unnecessary network congestion.

It’s easy to detect this kind of a problem in your trace files with the mrskew utility in the Method R Tools package.

Guest post from our friend, Lasse Jenssen

After removing think time (or idle SQL*Net message from client) from a trace file (see a description), an unwanted line of “unaccounted for between dbcalls” dominated my MethodR profiler report. After an e-mail to MethodR support, Cary Millsap & Jeff Holt, found a way to neutralize this unwanted line. In this post I’ll show how. Thanks to Cary Millsap & Jeff Holt!

Guest post from our friend, Lasse Jenssen

One important task when working with Oracle trace is to distinguish between idle and significant “SQL*Net message from client” waits. Default, MethodR defines waits above 1 second as “think time”. These waits are usually identified as idle waits. For instance – in an application using a connection pool, the sessions will be waiting for a client thread to grab a connection. These waits are truly not tied to the application response times, but is idle waits. In this article I’ll show how these waits easily can be “removed” or neutralized by using the MethodR utilities.

Connection pools help solve a big performance problem, but they also make using trace data more difficult. Method R Tools, part of the Method R Workbench software package, makes it easier to measure individual user response time experiences on connection pooling systems. Now you can look at performance problems the way you’ve always wanted to see them.