Method R Profiler is a software tool for measuring Oracle user response times. Version 6 is our biggest upgrade in ten years. You’re going to love what we’ve done.
If you use Oracle and you care about performance, then you need a profiler for Oracle. This video, created and narrated by Cary Millsap, explains why.
Do you have SQL in your system that doesn’t use placeholders, like this?
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.
Many Oracle educators teach that reducing the number of PIO (“physical” I/O) calls should be the top priority of SQL optimization. However, in our field work, we commonly eliminate 50% or more of the response time from slow Oracle applications, even after they’ve been tuned to execute no PIO calls. The secret is that Oracle LIO calls are more expensive than many people understand.
This paper describes how to use an Oracle Database tracing feature to write better, faster Oracle-based applications, regardless of whether your code is Java, PHP, C#, Ruby, Python, Perl, C, or something else.
Among many of my Oracle database administrator (DBA) friends, “agile” is widely regarded as a dirty word, a synonym for “sloppy.” However, adopting the principles of the Agile Manifesto (specifically, the implementation of the Agile Manifesto called Extreme Programming, or XP) has radically improved the commercial and technical success of projects that I’ve worked on.
Oracle’s extended SQL trace data stream contains a linear sequential record of every database call and every operating system call that the Oracle kernel executes in response to the code that you write.
When I wrote Optimizing Oracle Performance with Jeff Holt back in 2003, my goal was to define a reliable, teachable method for fixing software performance problems. After a few months of contentment having finishing the project, I began to notice a trend in how people were responding to it. Many of the questions coming in had started to repeat themselves: “Sure, fixing problems is important, but how can I prevent them?” “The book was fun, but of course I didn’t read the chapter on queueing theory; is that stuff really important, anyway?” “Where does capacity planning fit in?” …And, sadly, I continued to see people make some of the same mistakes that we had tried to warn people about in the book.
“Measure Twice, Cut Once” is a reminder that careful planning yields better gratification than going too quickly into operations that can’t be undone. Often, however, it’s better to Measure Once, Cut Twice.