Comments on: Creating Test Scripts With Bind Variables

By: Articles from Kerry Osborne | Chen Guang's Blog

Articles from Kerry Osborne | Chen Guang's Blog — Mon, 21 Mar 2011 23:43:07 +0000

[...] Creating Test Scripts With Bind Variables July 23, 2009, 9:10 am [...]

By: Plan stability through Upgrade to 11G- Building a test case « Coskan’s Approach to Oracle

Mon, 31 Jan 2011 18:16:36 +0000

[...] Used: http://kerryosborne.oracle-guy.com/2009/07/creating-test-scripts-with-bind-variables/ [...]

By: osborne

osborne — Mon, 31 Jan 2011 16:24:35 +0000

Absolutely there are issues with this approach. The variable type issues are the biggest drawback. There is no way in SQL*Plus to mimic a Java timestamp variable for example (at least that I’m aware of).

By: Bernard Polarski

Bernard Polarski — Mon, 31 Jan 2011 15:55:16 +0000

There is a drawback to such types of statement generators: it may works too nicely.

These statement generator may prevents you to reproduce and study implicit conversions. Since Sqlplus converts varchar2 bind to date type using by default the value of NLS_DATE_FORMAT, you will convert nicely the timestamp to a date type, fully enjoying index access and partition pruning on your study while production obviously does not.

The problem comes from the Java representation of date with hours,minutes,seconds which is a timestamp. Sent to Oracle it results into a datatype 180 (timestamp). And for Oracle column type DATE, which has also hour,minutes, seconds, it is the table column which is converted by the optimizer to timestamp and not the reverse(he can’t loose precision). Doing so, you loose partition pruning and index access on those binds. While using statement generator, you see nothing since these binds are nicely converted to type Date, same as column table, hence no problems.

By: osborne

osborne — Mon, 31 Jan 2011 14:03:12 +0000

Hi Bernard,

Thanks for sharing. I’ve also made some changes to mine to deal with data types a little better. When I get some time I’ll have a close look at your version.

Kerry

By: Bernard Polarski

Bernard Polarski — Mon, 31 Jan 2011 11:30:12 +0000

I use this SQL in smenu and a variant of this script from V$SQL and AWR. More work needed in the area of column date mismatched with timestamp.

    set lines 32000 head off trimspool off pages 0
    break on fdate on report
   set trimspool on
select line from (
     select  decode(position, 1,
                                  '-------------------------------------' ||chr(10) ||
                                  '-- Date :'||to_char(LAST_CAPTURED,'YYYY-MM-DD HH24:MI:SS')||chr(10)  ||
                                  '-------------------------------------' ||chr(10)|| chr(10)
                                  || 'alter session set NLS_DATE_FORMAT=''YYYY-MM-DD HH24:MI:SS'' ;' || chr(10)
                               --   || 'alter session set NLS_TIMESTAMP_FORMAT=''YYYY-MM-DD HH24:MI:SS.FFFFFF'' ;' || chr(10)
                              , chr(10)
             )||
            'variable ' ||
             regexp_replace( name,':D*[[:digit:]]*','a')
             ||to_char(position) || ' '
            || case DATATYPE
                       -- varchar2
                 when  1   then 'varchar2(4000)' || chr(10) || 'Exec '||regexp_replace( name,':D*[[:digit:]]*',':a') ||
                                 to_char(position) || ':='''||  value_string || ''';'
                          -- number
                 when  2   then 'number'         || chr(10) || 'exec '||regexp_replace( name,':D*[[:digit:]]*',':a') ||
                                 to_char(position) || ':='  ||  value_string || ';'
                          -- date
                 when  12  then 'varchar2(30)'   || chr(10) || 'exec '|| regexp_replace( name,':D*[[:digit:]]*',':a') ||
                                to_char(position) || ':='''||
                                        decode( value_string, null,
                                                            to_char(anydata.accessdate(value_anydata),'YYYY-MM-DD HH24:MI:SS') )  || ''';'
                           -- char
                 when  96  then 'char(3072)'     || chr(10) || 'exec '||regexp_replace( name,':D*[[:digit:]]*',':a') ||
                                 to_char(position) || ':='''||  value_string || ''';'
                           -- timestamp
                 when  180 then 'varchar2(26)'   || chr(10) || 'exec '||regexp_replace( name,':D*[[:digit:]]*',':a') ||
                                 to_char(position) || ':='''||
                                         decode( value_string, null,
                                                            to_char(anydata.accessTimestamp(value_anydata),'YYYY-MM-DD HH24:MI:SS') ) || ''';'
                                                            --to_char(anydata.accessTimestamp(value_anydata),'YYYY-MM-DD HH24:MI:SS.FFFFFF') ) || ''';'
                           -- timestampTZ
                 when  181 then 'varchar2(26)'   || chr(10) || 'exec '||regexp_replace( name,':D*[[:digit:]]*',':a') ||
                                 to_char(position) || ':='''||
                                         decode( value_string, null,
                                                            to_char(anydata.accessTimestampTZ(value_anydata),'YYYY-MM-DD HH24:MI:SS') ) || ''';'
                                                            --to_char(anydata.accessTimestampTZ(value_anydata),'YYYY-MM-DD HH24:MI:SS.FFFFFF') ) || ''';'
                 when  112 then 'CLOB'           || chr(10) || 'exec '||regexp_replace( name,':D*[[:digit:]]*',':a') ||
                                  to_char(position) || ':='''||  value_string || ''';'
               else
                               'Varchar2(4000)'  || chr(10) || 'exec '|| regexp_replace( name,':D*[[:digit:]]*',':a') ||
                                  to_char(position) || ':='''||  value_string || ''';'
               end line
     from v$sql_bind_capture where sql_id = 'as7xqqa7711zj'  and child_number = '0'
order by last_captured,position, child_number, position )
union all
select  regexp_replace(line,'(:)D*([[:digit:]]*)','1a2')||chr(10)  ||'/' line from (
select  regexp_replace(
          max(sys_connect_by_path (sql_text,'{') ),
          '{','') line
from (
select
        piece,   sql_text
  from v$sqltext_with_newlines where  sql_id='as7xqqa7711zj'
order by 1
)
start with piece=0
connect by  piece  = prior piece + 1
)
/

By: 11.2.0.2 performance stories « Coskan’s Approach to Oracle

11.2.0.2 performance stories « Coskan’s Approach to Oracle — Mon, 17 Jan 2011 12:52:47 +0000

[...] thanks to Kerry Osborne and his amazingly useful (I have no idea how many times it made my day) build_bind_vars script. Normally building a test case for a sql which has 100 bind variables is a nightmare but with that [...]

By: Dave Herring

Dave Herring — Mon, 25 Oct 2010 12:43:40 +0000

You’re absolutely correct, as usual! The problem was thinking EXPLAIN PLAN / AUTOTRACE would peek at bind variables like the CBO. That’s why the shared pool updated stats were different then our manual tests.

Thanks for sharing all your scripts, as they helped identify the problem quickly!

By: osborne

osborne — Fri, 22 Oct 2010 03:51:33 +0000

Dave,

I understand the thought process but I don’t think the bind variable names have anything to do with it.

Here are a couple of thoughts on what might be causing the problem:

1. Are there any environment settings that are different between the production runs (with the bad plan) and the tests you’re doing? Try looking at X$KQLFSQCE for the optimizer settings.

2. Is it possible that data is out running stats? By that I mean, could the query that gets the bad plan have a value that is significantly outside the range of max (or min) that the stats is aware of at the point when the statement is parsed? This could also account for why replying the statement later with the same set of bind variables doesn’t reproduce the bad plan.

3. It’s actually a variation on number 2. Does the bad plan happen on a regular basis (the day after switching to a new partition for example)? Could it be that stats are set to 0 rows and the first day of using the new partition causes bad plans?

By the way, what do you plan to do if you find a combination of bind variables that cause the bad plan to appear? An expedient solution might be to just force the good plan with a SQL Profile, even if it’s only a temporary solution until you figure what’s causing the instability. My create_sql_profile.sql script might be useful for that.

Kerry

By: Dave Herring

Dave Herring — Wed, 20 Oct 2010 19:04:13 +0000

The problem is more likely due to me not fully understanding what’s going on with bind variables.

I’m finding statements with multiple plans, 1 good 1 bad. For the “bad” ones, I retrieve the bind variables used via “SELECT * FROM TABLE(dbms_xplan.display_cursor(‘&sql_id’,&child,’+PEEKED_BINDS’))”, and if that indeed lists peeked bind variables, I go with them. With those values, I use the same method you describe for creating bind variables and run the statement, then check in the shared pool for what plan was used. I always get the “good” plan.

At this moment I’d just like to find out what’s generating the “bad” plan, but I can’t come up with any bind values for it. That’s why I went down the road of thinking I need the exact SQL_ID.

Make sense?