Monday, August 09, 2010

Mr Trace...

This looks interesting

I always like software that comes with a free trial too - I always hesitate to try something out that costs a couple of dollars, even if the amount is small - because I might not like it and then what.

So, no risk really - if you try it - and have an opinion about it - feel free to post your comments either way...

I guess I should qualify that "post your comments". How about - post your informed, backed up with some points, comments :)


Anonymous Anonymous said....

Toad trace analyzer is so much better than this...

Mon Aug 09, 03:32:00 PM EDT  

Blogger Thomas Kyte said....


and my mom is better than your mom.

so there.

How about you say why - and open up a discussion.

Mon Aug 09, 03:48:00 PM EDT  

Blogger Kelloggsville said....

I am that DBA the developers have to come crawling to when they want their trace files and I don't like it as much as they don't! anything that helps them has to be good. I'm going to send them the link so they can have a play and I'll have a shufty too. I also tend to use Toad but I am lucky I have a license. $50 is considerably cheaper than a Toad license if you are only looking to get help with tracing. I'm sure I recall using a trial databee tool for a while. I'll try this and let you know how it goes :0)

Mon Aug 09, 04:52:00 PM EDT  

Blogger Connor McDonald said....

nice tool, but putting my pessimist hat on - if you've got developers that want to access/process trace files, then you're already a long way ahead of the game...

My experience is that the challenge is not locating a tool to fetch/identify trace files, but getting developers to have an interest in performance at all...

Tue Aug 10, 01:39:00 AM EDT  

Blogger tnourse said....

@Connor -- AMEN! Most don't give a darn figuring "build it first, tune it later" as if there is a magical /*+ RUN AS TUNED */ hint somewhere, or the mythical, Tom Kyte described, non-entity /*+ FAST=TRUE */ hint :)
God I love this site! If only Tom's books were mandatory reading in colleges and universities...

Tue Aug 10, 08:41:00 AM EDT  

Blogger Belly said....

@Connor & tnourse

Sorry guys, but I'm afraid that in my experience there's a lot of developers (though not nearly enough, I admit) that do care about performance.
Problem is that too often you dba's and us developers think in terms of you and us.

a lot of dba's consider themselves god on the database. And every tool or permission that is given to a developer makes that developer more godlike and the dba more common.
And apart from that, the stupid developers do not know sh** about performance so let's not have them make wrong decisions based on data only a dba can understand. Right?

Just installed the tool at the site I'm working at right now.
a script needs to be run as SYS to create a directory and grant a couple of rights.
The local god refuses to run this script for vague reasons.

In stead of calling each other names, saying developers do not care about performance and dba's only exist to make a developers work harder, maybe 'you' and 'us' should start to realize that we are all in it for the same reason: building and maintaining a database which allows a company to do it's work.
We both have our own specialities, but that does not mean we do not know anything about the area of expertise of the other.
Just as dba's know how to write some plsql, a developer knows about performance.
It's just that we both know more about one aspect then the other.

I'll get this tool installed om my own machine and give it a spin.

Tue Aug 10, 12:50:00 PM EDT  

Blogger Joel Garry said....


Having been on both sides of this divide, often at the same time, there is at least one major difference in performance view: the developer only cares about performance from the single point of view, while the dba looks at it from the db point of view, which means a lot of possibly opposing points of view. Tom and Cary have addressed this expertly in their writings, Tom explaining how Oracle handles concurrency and such things different than other engines (including the kind of myths developers may bring from there), and Cary pointing out how to find bottlenecks of the summation of transaction load and the importance of response time to the user when defining if there even is a business problem.

A dba in a production system must necessarily guard against all the random things developers want to do. Developers on a test system need to emulate a production load, but rarely can. So tracing is used for a number of things, from single-user to multi-user. It's the latter on a production system that has a territorial problem. The dba has to trust that the mysterious outside entity who created the tool won't create a whole new class of problems.

Do you trust random code from the internet? Can you really give it a fair test on your own system?

Now, people reading this are going to be familiar with Cary and Tom, so they would be more likely to trust the tool. Personally, I'd wonder about any dba "god" who isn't familiar with them, though I've certainly run into those.

Yes, we can all get along, but there's tension built into the system.

word: foxonis

Wed Aug 11, 05:29:00 PM EDT  

Anonymous Anonymous said....

MR Trace works as documented. Useful for anyone interested in tuning, whether DBA or developer. So far I did not see any issues in testing. Very easy to use and a very minimal and functional utility.

Thu Aug 12, 01:48:00 PM EDT  

Anonymous Anonymous said....

@Thomas Kyte
toad brings together ftp, trcsess, tkprof. mr trace is just another file browser integrated into sqldev.

trace file browser enables real time tkprof sorting, filtering, grouping and more. this is where true time-saving takes place.

Fri Aug 13, 01:40:00 AM EDT  

Blogger Thomas Kyte said....


If the tool needs FTP access, that tool isn't going to be used by the vast majority of the planet. To have FTP installed these days is rare, to have developers have FTP access to the Oracle trace area - unheard of.

and execute on dbms_system? I don't think so.

The goal here was to provide easy access to trace files - the toad tool opens up more security risks than most people would even begin to be comfortable with. It (that tool) would be a reason DBA's would cut off access. FTP to the srever??? *FTP*!!!! Access to DBMS_SYSTEM - with other neat procedures that can do some interesting things - I'm not thinking that is wise.

Fri Aug 13, 01:54:00 AM EDT  

Anonymous Anonymous said....

Actually MR Trace also grants execute on dbms_system.


Fri Aug 13, 01:45:00 PM EDT  

Blogger Thomas Kyte said....


and it is also documented as being quite optional (the grant on dbms_system). It is not necessary for the running of the utility, they use it to write to the alert log - not a mandatory bit of functionality.

Fri Aug 13, 06:24:00 PM EDT  

Blogger Connor McDonald said....

Belly - you've jumped to a conclusion - I consider myself more a developer than DBA.

Don't get me wrong - I've been fortunate enough to work at places where development staff have worked tirelessly to build tools to utilise all the goodies at their disposal (trace file retrieval, ASH, dbms_xplan, dbms_monitor and the like), including even including trace file analysis as a prerequisite for the promotion of code into Test or QA environments.

My point is - they are scarce, especially in this modern world of middle tier centric apps, with the database as a "black box".


Sun Aug 15, 02:50:00 AM EDT  

Anonymous Mark Brady said....

While what Joel said is true, I have to agree with Belly even more. DBA's look at the overall, developers just their app. But Developers are beholden to DBA's for access and the reverse is not true. As a result most DBA's have a 'not invented here' attitude that even though thousands of people around the world do something successfully, this place is unique and needs to be fully vetted (which in theory is fine) BUT we don't have the resources to do the vetting so you'll have to wait until, well forever, or until you stop asking, in which case we'll tell the DBA manager that you obviously no longer want it.

Mon Aug 16, 12:55:00 PM EDT  

Anonymous Anonymous said....

To Whom It May Concern:
It's DBAs; not DBA's.

Thank you.

Tue Aug 17, 10:03:00 AM EDT  

Anonymous Anonymous said....

I am a DBA. When the database server CPU goes 100% at 10:00 AM and queries are doing million buffer gets per execution, no one can log in, a thousand people can't get the information they need, guess whose head is on the chopping block, the developers' who wrote the SQLs and who might be enjoying a cup of coffee at that precise moment or the DBA who carries a pager 24x7?

Who has responsibility, has the power. I am tired of everyone saying that DBAs act like Gods. Yes we do. These are the Gods everyone turns to when database goes down or there are performance issues. We provide 24x7 support, not the developers. We are expected to maintain database up time, not the developers. We will do everything to protect our turf. If a non-DBA causes downtime, it is we who have to bear the brunt.

Learn to deal with the fact that DBAs are more powerful in database management hierarchy. Developer quits, a new one can be hired next day. DBA quits, the entire operation is at risk.

Query tuning is everyone responsibility and it starts with the developer who writes it. Unfortunately, I have never seen any developer do any tuning that is worth anything. Developers who can actually tune queries are very rare and they don't come cheap. Most places cannot afford them unless on a brief contractual basis.

Enough of rant, getting back to real DBA work now.

Wed Aug 18, 09:56:00 AM EDT  

Blogger Thomas Kyte said....


DBA quits, the entire operation is at risk.

Only if you let your DBAs be demagogue of sorts. Under "normal" circumstances - well documented procedures, standard installation, well developed team - replacing a DBA should be no harder than replacing a good developer.

And - there are good developers, many of them. Some of them would be much much harder to replace than a DBA.

It depends.

But if replacing a DBA puts a company at risk, then the company is at fault and they need to correct that before the DBA gets hit by the number 2 bus going home some night.

Wed Aug 18, 02:44:00 PM EDT  

Anonymous Anonymous said....

Haha. The above rant is hillarious between the geeks (dba & developer).

Let me tell you something real - nobody cares about you both :-)

Tue Aug 24, 04:34:00 PM EDT  

Anonymous Anonymous said....

When you are standing in line at the supermarket, the cash registers are down and your ice cream is melting... when your checks start bouncing because your bank didn't deposit your paycheck... when the ambulance can't come because your phone doesn't work... when the hospital can't check you in because your insurance company is down... you'll care.

word: impepr

Tue Aug 24, 06:01:00 PM EDT  

Anonymous Artmast said....

I have found MR Trace to be really easy to use and overall a very handy tool..

Thu Aug 26, 07:05:00 PM EDT  

Anonymous Anonymous said....

Is this like Sparky 2.0?

Mon Aug 30, 09:07:00 AM EDT  

Anonymous Anonymous said....

"And - there are good developers, many of them. Some of them would be much much harder to replace than a DBA."

Only if there's a world-wide shortage of pigs' bladders on sticks!

Thu Sep 02, 04:27:00 AM EDT  

Blogger Kevin said....

So, is it pronounced "Mister Trace"?

Did someone already ask that? I didn't see....

Fri Sep 17, 10:46:00 AM EDT  

Blogger Cary Millsap said....

Kevin, we call it "Mister Trace." Of course, the "MR" stands for "Method R". See and for more information.

Wed Sep 22, 11:47:00 PM EDT  


<< Home