{
  "date": "2015-06-12T10:12:07",
  "slug": "flame-graph-for-quick-identification-of-oracle-bug",
  "link": "https://www.dbi-services.com/blog/flame-graph-for-quick-identification-of-oracle-bug/",
  "title": {
    "rendered": "Flame Graph for quick identification of Oracle bug"
  },
  "content": {
    "rendered": "<h2>By Franck Pachot</h2>\n<p>.<br />\nMost of my performance stores start with a screenshot of <a href=\"http://orachrome.com/en/index.html\">Orachrome Lighty</a> my preferred tool to have a graphical view of the database performance, in Standard and Enterprise Edition without any options:</p>\n<p><a class=\"easyblog-thumb-preview\" title=\"CaptureHighParse.JPG\" href=\"http://dbi-services.com/blog/images/easyblog_images/139/CaptureHighParse.JPG\"><img decoding=\"async\" title=\"b2ap3_thumbnail_CaptureHighParse.JPG\" src=\"https://www.dbi-services.com/blog/wp-content/uploads/sites/2/2022/04/b2ap3_thumbnail_CaptureHighParse.jpg\" alt=\"b2ap3_thumbnail_CaptureHighParse.JPG\" /></a></p>\n<p>I&#8217;m investigating a long running query. That query obeys to the most important rule in Oracle performance: parce once (CPU) &#8211; execute many (IO+CPU) &#8230; except that the parse time is a bit too long here (2 hours)</p>\n<p>How to know what happens ? ASH is there if you have Diagnostic Pack:</p>\n<pre><code>\nMIN(SAMPLE_TIME)  MAX(SAMPLE_TIME)  COUNT(*) PLAN_LINE_ID SESSION_STATE IN_PARSE IN_SQL_EXECUTION\n----------------- -------------------------- ------------ ------------- -------- ----------------\n10.06.15 04:26:43 10.06.15 05:29:41     3773              ON CPU        Y        N\n10.06.15 05:21:26 10.06.15 06:37:43     4078              ON CPU        Y        Y\n10.06.15 06:37:44 10.06.15 10:14:54       34           26 WAITING       N        Y\n10.06.15 06:37:53 10.06.15 10:15:38      707           32 WAITING       N        Y\n10.06.15 06:38:49 10.06.15 10:15:46      106           33 WAITING       N        Y\n10.06.15 06:38:57 10.06.15 10:15:42       18           28 ON CPU        N        Y\n10.06.15 06:38:59 10.06.15 09:44:13        5           25 ON CPU        N        Y\n</code></pre>\n<p>and this is where I know that those 2 hours on CPU are for parsing. No SQL_PLAN_LINE_ID at parse phase. I&#8217;ve no explanation yet about the hour that is accounted both as parse and execution. Comments below are there for ideas 😉</p>\n<p>Ok, it&#8217;s in CPU. Then let&#8217;s go to flame graphs:</p>\n<pre><code>\nperf record -e cpu-cycles -o /tmp/perf.out -g -p 3708\n^C\n[ perf record: Woken up 1207 times to write data ]\n[ perf record: Captured and wrote 301.689 MB /tmp/perf.out (~13180986 samples) ]\nperf script -i /tmp/perf.out | ./FlameGraph-master/stackcollapse-perf.pl &gt; /tmp/perf.folded\n./FlameGraph-master/flamegraph.pl /tmp/perf.folded &gt; /tmp/perf.folded.svg\ncp /tmp/perf.folded.svg .\n</code></pre>\n<p>Here is the .svg opened with a browser:</p>\n<p><a class=\"easyblog-thumb-preview\" title=\"CaptureHighParseFlame.JPG\" href=\"http://dbi-services.com/blog/images/easyblog_images/139/CaptureHighParseFlame.JPG\"><img decoding=\"async\" title=\"b2ap3_thumbnail_CaptureHighParseFlame.JPG\" src=\"https://www.dbi-services.com/blog/wp-content/uploads/sites/2/2022/04/b2ap3_thumbnail_CaptureHighParseFlame.jpg\" alt=\"b2ap3_thumbnail_CaptureHighParseFlame.JPG\" /></a></p>\n<p>&nbsp;</p>\n<p>When the parsing time is in hours, we are obvously encountering a bug. So let&#8217;s search on MOS for: kghalf kghalp kokqopdup and bingo &#8211; several bugs about high CPU usage. Workaround is to disable Simple View Merging.</p>\n<p>I have a workaround now &#8211; disabling simple view merging. Parse time is short. But query is still running for one hour&#8230;</p>\n<p>This blog post was about using perf and flame graphs to get the stack from several samples, rather than taking few stack dumps. Those are great tools.</p>\n",
    "protected": false
  }
}