On Oracle-L this week is a discussion about buying Dynatrace vs. Oracle Enterprise Manager. Both tools work harmoniously together, but there’s a third choice you should consider, too: Method R Workbench. Our Workbench helps you mine unbelievable detail from Oracle trace files, even if you’re getting thousands of trace files at a time. Workbench works harmoniously with both Dynatrace and OEM and fills a gap that no other tool can fill.
Last week, a Method R Workbench customer was having a hard time downloading Oracle trace files from Amazon RDS. The code that Amazon recommends doesn’t quite work right; it fails to copy trace file lines that are longer than 400 characters. So I wrote a replacement fetcher for him. This method should work for any Oracle implementation that permits you to access your trace data.
A few months ago, we received two trace files representing two executions of the same program. One execution took almost 14 times longer than the other. The cause of the difference was dominantly the number of “db file sequential read” calls made by the two executions. Why would two executions of the same program, processing approximately the same amount of data, present radically different “db file sequential read” call counts? One guess is that it’s pressure on the database buffer cache that’s causing the problem, but how can you prove it?
Today, I had the honor of speaking online to the Chicago Oracle Users Group in their “20 in 2020” webinar series. In this presentation, I talk about why it’s OK to trace everything on your system and how to do it safely, and I explain why you’d want to do that in the first place.
Earlier, Mark Williams showed us how in Java to clear the session handle attributes to enable our code to be more easily traced. Because I had not seen the trace data produced when using his method, I decided to construct a test to see the trace data produced when the code does and does not execute the
It really is OK to trace everything—even your whole database if you want to. But you have to do it right. This session explains how to safely trace anything you want, and why you’d want to trace your programs in the first place. This is a Dallas Oracle Users Group (DOUG) webinar presentation, recorded on 7 May 2020.
New Method R Workbench features are always inspired by needs discovered on real projects. Two new features of the soon-to-be-released Workbench 9—the radically faster mrskew utility, and a new trace file cropping utility called mrcrop—make it faster and easier than ever to shred through millions of lines of Oracle trace data to find exactly what you need. In this video, I tell the story of how to get to the bottom of a pesky, intermittent performance problem within just a couple minutes of receiving your trace files.
From Oracle Database 12.1 onward, the JDBC driver provides a convenient method called
setClientInfo to set user session handle attributes in the database. There are three user session handle attributes that are useful when instrumenting your application so that it identifies itself and exposes its actions in Oracle Database (such as in the
Last month (June 2018), I presented at Kscope the story of how to make it easy to collect Oracle extended SQL trace data, so you can measure exactly how an Oracle-based application consumes its user’s time. The slides are available at SlideShare.net.
One of the more challenging types of performance problem is the dreaded scenario in which the problem occurs only intermittently and is difficult to trap with your performance measurement tools. In such a situation, trace data can be an irreplaceable ally, allowing you to understand even phenomena that you’ve not yet actually measured.