Comments on: Identify the SQL statement causing those WAIT #X lines in a (top-truncated) sql tracefile http://blog.tanelpoder.com/2009/07/09/identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile/?utm_source=rss&utm_medium=rss&utm_campaign=identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile Oracle, Exadata, Performance, Troubleshooting - Mobile Life and Productivity. Wed, 08 Feb 2012 08:03:50 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: shenglin http://blog.tanelpoder.com/2009/07/09/identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile/comment-page-1/#comment-3302 shenglin Mon, 07 Dec 2009 05:40:02 +0000 http://blog.tanelpoder.com/2009/07/09/identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile/#comment-3302 That's great it doesn't take any locks on shared resources. It's really useful to trace the bind variables of running SQL. I tried to test errorstate in product database with over 5000 tps. It take a few seconds to run, but no impact to others. I also tried processdump again, this time I could find the cursor info and related bind variables. Errorstack dump more info than Processstate. Thanks again for sharing this great article. Thanks Shenglin That’s great it doesn’t take any locks on shared resources. It’s really useful to trace the bind variables of running SQL. I tried to test errorstate in product database with over 5000 tps. It take a few seconds to run, but no impact to others. I also tried processdump again, this time I could find the cursor info and related bind variables. Errorstack dump more info than Processstate.

Thanks again for sharing this great article.

Thanks
Shenglin

]]> By: Tanel Poder http://blog.tanelpoder.com/2009/07/09/identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile/comment-page-1/#comment-3290 Tanel Poder Sun, 06 Dec 2009 16:50:20 +0000 http://blog.tanelpoder.com/2009/07/09/identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile/#comment-3290 Errorstack and processstate dumps affect only the target process where you connect with oradebug. It doesn't block others as it doesn't take any locks on shared resources (for example, a heapdump level 2 can hang your whole instance for a while as it takes shared pool latches). Errorstack and processstate dumps affect only the target process where you connect with oradebug. It doesn’t block others as it doesn’t take any locks on shared resources (for example, a heapdump level 2 can hang your whole instance for a while as it takes shared pool latches).

]]> By: shenglin http://blog.tanelpoder.com/2009/07/09/identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile/comment-page-1/#comment-3286 shenglin Sun, 06 Dec 2009 11:20:12 +0000 http://blog.tanelpoder.com/2009/07/09/identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile/#comment-3286 Hi Tanel, Thanks for sharing this useful info. I have two questions about this: 1. Is it safe to run ERRORSTACK and processstate in the database with high activities? Does that block others? 2. I tried to use processstate with level to trace the bind varialbes with one running session, which is waiting for 'db file sequential read'. I can find the SQL in the trace file, but I can't find out the cursor info. So I can't find the bind variables. Are there anything else to control that? Thanks Shenglin Hi Tanel,

Thanks for sharing this useful info. I have two questions about this:

1. Is it safe to run ERRORSTACK and processstate in the database with high activities? Does that block others?

2. I tried to use processstate with level to trace the bind varialbes with one running session, which is waiting for ‘db file sequential read’. I can find the SQL in the trace file, but I can’t find out the cursor info. So I can’t find the bind variables. Are there anything else to control that?

Thanks
Shenglin

]]> By: ASWATH RAO http://blog.tanelpoder.com/2009/07/09/identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile/comment-page-1/#comment-2377 ASWATH RAO Thu, 27 Aug 2009 01:37:02 +0000 http://blog.tanelpoder.com/2009/07/09/identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile/#comment-2377 Tanel, Very nicely written article. I learnt a lot from the article. Thanks Aswath Rao Tanel,

Very nicely written article. I learnt a lot from the article.

Thanks
Aswath Rao

]]> By: Blogroll Report 03/07/2009 – 10/07/2006 « Coskan’s Approach to Oracle http://blog.tanelpoder.com/2009/07/09/identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile/comment-page-1/#comment-2055 Blogroll Report 03/07/2009 – 10/07/2006 « Coskan’s Approach to Oracle Fri, 10 Jul 2009 18:41:23 +0000 http://blog.tanelpoder.com/2009/07/09/identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile/#comment-2055 [...] Tanel Poder – Identify the SQL statement causing those WAIT #X lines in a (top-truncated) sql tracefile [...] [...] Tanel Poder – Identify the SQL statement causing those WAIT #X lines in a (top-truncated) sql tracefile [...]

]]> By: How to detect when a cursor was closed from SQL trace output? | Tanel Poder's blog: Core IT for Geeks and Pros http://blog.tanelpoder.com/2009/07/09/identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile/comment-page-1/#comment-2018 How to detect when a cursor was closed from SQL trace output? | Tanel Poder's blog: Core IT for Geeks and Pros Thu, 09 Jul 2009 11:50:13 +0000 http://blog.tanelpoder.com/2009/07/09/identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile/#comment-2018 [...] Randolf’s comment on my last post about identifying cursor SQL text from sql trace file I think one thing needs [...] [...] Randolf’s comment on my last post about identifying cursor SQL text from sql trace file I think one thing needs [...]

]]> By: Tanel Poder http://blog.tanelpoder.com/2009/07/09/identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile/comment-page-1/#comment-2016 Tanel Poder Thu, 09 Jul 2009 11:16:52 +0000 http://blog.tanelpoder.com/2009/07/09/identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile/#comment-2016 Hi Randolf, Yes, that's why I mentioned "as long as the cursor of interest is still open" in my post. I have highlighted that sentence now and will an update into the end of the post elaborating this a bit. Hi Randolf,

Yes, that’s why I mentioned “as long as the cursor of interest is still open” in my post. I have highlighted that sentence now and will an update into the end of the post elaborating this a bit.

]]> By: Randolf Geist http://blog.tanelpoder.com/2009/07/09/identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile/comment-page-1/#comment-2015 Randolf Geist Thu, 09 Jul 2009 11:07:14 +0000 http://blog.tanelpoder.com/2009/07/09/identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile/#comment-2015 Tanel, correct me if I'm wrong but if the cursor of interest was already closed (therefore you say "as long as the cursor is still open") then the result could be misleading since the slots can get re-used and therefore a CURSOR#2 as of now not necessarily reflects the CURSOR#2 identified in the trace file. Regards, Randolf Tanel,

correct me if I’m wrong but if the cursor of interest was already closed (therefore you say “as long as the cursor is still open”) then the result could be misleading since the slots can get re-used and therefore a CURSOR#2 as of now not necessarily reflects the CURSOR#2 identified in the trace file.

Regards,
Randolf

]]>