tag:blogger.com,1999:blog-8884584404576003487.post6515067680002202482..comments2024-02-29T09:43:12.251-05:00Comments on ORACLENERD: SQL Developer + MR Traceoraclenerdhttp://www.blogger.com/profile/12412013306950057961noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-8884584404576003487.post-41039145220751911112011-02-03T11:15:21.348-05:002011-02-03T11:15:21.348-05:00Thank you so much for this.
If you want "Her...Thank you so much for this.<br /><br />If you want "Here is your response time, all of it" in color, with drill-down detail, that's where our <a href="http://method-r.com/testimonials/65-profiler/129-tonyaponte2" rel="nofollow">Method R Profiler</a> comes in. If you want text-based answers to just about any question you can think of, that's <a href="http://method-r.com/software/mrtools" rel="nofollow">MR Tools</a>.<br /><br />Yesterday, I did this:<br /><br />- I used an exprimental tool called mrtimfix that fixes trace file time values messed up by bug 7522002. So far, the experiment is going well.<br /><br />- With mrskew, I found out where all my 'SQL*Net message from client' calls with response times greater than 1.0 second are, so I could examine whether these are end-user think time, or actual system processing time (e.g., on a Java tier).<br /><br />- Then I "removed" those calls using a pre-beta tool called mrcallrm, which compresses the calls I didn't want, adjusting the time values throughout the file appropriately. Now I can do some <i>real</i> work.<br /><br />- I used the Profiler to show me a color rendition of where all the time had gone in two similar sessions executed on two different systems. The Profiler showed the recursive relationships among SQL statements and exactly how much time each consumed, both inclusive of and exclusive of its recursive progeny.<br /><br />- I compared subroutine call response times across files by grouping mrskew response time output by a concatenation of file name and (db|sys)call name. This showed me the high-level difference between the response times in the two files.<br /><br />- I grouped response times in mrskew by file name and SQL hash value to do a direct side-by-side comparison of response time by SQL statement.<br /><br />- I drilled into each SQL statement that I wanted to analyze with mrskew by using the hash value in my --where expression and subroutine call name in the --group expression.<br /><br />- I saw the complete progression of every database call and syscall executed for each SQL statement by using the hash value in the --where expression and the line number concatenated to the call name in the --group expression, and I used the --sort expression to sort numerically, which gave me control flow of a statement's processing with response time reporting.<br /><br />- I could have (but didn't need to) checked out the skew in read call durations by using mrskew's --name='db.*read' and then drilled down by grouping by file id (and block id if I wanted, to see if there are any hot devices) and looked at response time by call size by grouping by the #blocks value.<br /><br />- I looked at only the statements at recursive depth 1 (because there was a weird problem identified in the Method R Profiler output of there being <i>way</i> too much recursive SQL) by using mrskew --group='$hv' --where='$dep==1'. I drilled down from there, using appropriate --where='$hv eq "x"' values.<br /><br />That's the tip of the iceberg.Cary Millsaphttps://www.blogger.com/profile/16697498718050285274noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-59473309089972163322011-02-02T16:06:32.751-05:002011-02-02T16:06:32.751-05:00I do not know any tool which gives you red/yellow/...I do not know any tool which gives you red/yellow/green in a useful way.<br />I'd suggest you take one particular trace file and try it out with as much tools as you can. <br />I prefer TVD$XTAT - if it's not needed to be integrated: <br /> http://antognini.ch/2008/10/introduce-tvdxtat/ <br />or you can try Alberto Dell'Eras xtrace: <br /> http://www.adellera.it/xtrace/index.html <br />Then choose the one which fits your needs best.Martin Bergerhttps://www.blogger.com/profile/16504572924713610305noreply@blogger.com