Comments on: Tracking the bind value

By: Plans gone AWRy – an invASHtigation « OraStory

Plans gone AWRy – an invASHtigation « OraStory — Tue, 29 Dec 2009 16:37:50 +0000

[...] other ASH / AWR resources: Tracking the bind variable – Dion Cho Doug’s AWR tagged posts Doug’s ASH tagged posts Possibly related posts: (automatically [...]

By: Dion Cho

Dion Cho — Wed, 29 Jul 2009 07:45:25 +0000

Petr.

Yes, I know that.
But that’s not what I’m describing in this post. “Can we get the bind values used in the “select ..” query by session 146 10PM of last night?” – that’s the question here.

By: Petr

Petr — Wed, 29 Jul 2009 07:38:37 +0000

Hallo Dion,

I supposed that peeked binds in OTHER_XML in v$sql_plan and dba_hist_sqlplan are the binds which were used when the statement was parsed.

By: Dion Cho

Dion Cho — Tue, 28 Jul 2009 11:16:43 +0000

Petr

It’s technically impossible to get the bind values from shared v$ views and/or dictionary views. Bind values have meaning only at the session level(PGA), not the system level(SGA). This is why we have only 2 ways available to capture 100% of the bind values

auditing
10046 trace

What you get from V$SQL_PLAN and DBA_HIST_SQLPLAN(and any other views) are the bind values of one specific session of one specific time.

By: Petr

Petr — Tue, 28 Jul 2009 10:48:39 +0000

Bind values can be found together with other info in column OTHER_XML in V$SQL_PLAN or DBA_HIST_SQLPLAN in row with ID=0. They can by displayed (if available) with the option ADVANCED from

V$SQL_PLAN:
select * from table(dbms_xplan.display_cursor(‘&SQL_ID’,&child,’ADVANCED’));

AWR:
select * from table(dbms_xplan.display_awr(‘&SQL_ID’,NULL,NULL,’ADVANCED’));

By: Denis

Denis — Wed, 27 May 2009 19:06:17 +0000

Thanks Tanel. I tested your method today: http://oracle-study-notes.blogspot.com/2009/05/oradebug-dump-errorstack-and-bind.html it should be helpful. Next time, if same situation occurs, I will give a try.

FGA may work for 10g, but for 9i only SELECT is supported.

By: Tanel Poder

Tanel Poder — Wed, 27 May 2009 12:21:16 +0000

IF your problem is still ongoing, meaning that the “bad” long-running statement is still running, the errorstack dump at level 2 would give you bind variable value as well (as I explained here: http://www.freelists.org/post/oracle-l/Tx-row-lock-contention-after-implementing-transaction-management-in-application-server,6 )

By: Dion Cho

Dion Cho — Wed, 20 May 2009 01:16:01 +0000

@Denis

In that case, FGA(Fine Grained Auditing) seems to be the solution.

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:5967736255722

http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28419/d_fga.htm#CDEIECAG

By: denis

denis — Tue, 19 May 2009 14:36:54 +0000

Thanks. I will read the doc whenever having chances. My situation is I support a 9i database, which from time to time has blocker/waiter sessions (long enough to cause application slow down significantly). We are able to show dev team the sql of the blocking sessions. But they asked can you give us the bind values in those sqls? Then we lost. From your post, it seems possible to turn on audit on a table, then we can get bind value of the sql on it. Is it true? If so, looks to me better than turning on sql_trace, which is nearly impossible – we don’t know which and when a session will be blocking.

By: Dion Cho

Dion Cho — Tue, 19 May 2009 02:19:40 +0000

@Denis

Oracle has built up fantastic document on this.

http://download.oracle.com/docs/cd/B28359_01/server.111/b28337/tdpsg_auditing.htm