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?
If you do it right, the overhead incurred by Oracle tracing is imperceptible, so more sites than ever are using trace data as a source for detailed performance data. But what can you do when you end up with thousands of trace files? With Method R Workbench, it’s not a problem.
This is article number seven in the Method R Oracle® Performance Monograph series. I hope you’ll enjoy it.
It’s easy these days to mine interesting user experiences out of enormous trace data collections. But there’s still value in being able to trace that one user or that one program, right when you need it.
This is article number five in the Method R Oracle® Performance Monograph series. I hope you’ll enjoy it.
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.
How confident are you that those new features you’re adding to your production application will be fast and efficient? What if they’re not? You need a process that finds inefficient code earlier, and a process to fix the inefficiencies that evade early detection. One process can accomplish both goals.
This is article number two in the Method R Oracle® Performance Monograph series. I hope you’ll enjoy it.
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.
On January 27, my dear friend Mogens Nørgaard hosted me for a 1:39:13 chat, which he flatteringly called “Cary Millsap—the master thinker of application performance and more.” It’s a long, wandering conversation that I really enjoyed.
How do you solve production performance problems? The method you use may be structurally incapable of helping you find certain types of performance problems. Changing how you look at your system makes all the difference.
Over the past few weeks, I’ve been writing some short articles in a new series that I’m calling the Method R Oracle® Performance Monograph series. Today, I am releasing the first monograph, called “Solving the Unsolvable Performance Problem.” It’s a fast introduction to understanding why my team and I do what we do. I hope you’ll enjoy it.
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.
Creating “high performance” as an attribute of complex software is extremely difficult business for developers, technology administrators, architects, system analysts, and project managers. However, by understanding some fundamental principles, performance problem solving and prevention can be made far simpler and more reliable.