[20220811]奇怪的隐式转换问题(12c补充测试).txt
–//生产系统遇到一个奇怪的隐式转换问题，问题在于没有发生隐式转换，前面已经做了一些分析增加12c下的测试情况.
–//我当时的猜测如下：
–//也许oracle 19c版本支持这样的操作，当带入日期类型参数是timestamp类型时，如果秒后面的值全部是0，可以当作date类型使用。
–//导致不会发生隐式转换，我估计oracle估计遇到这样的情况有点多，做了这样的改进，规避了这个问题，在执行时探测绑定变量，避
–//免了隐式转换的发生。
–//后记:测试的结果说明我有点想当然了，实际上从12.2版本开始，oracle就支持这样的情况，当使用绑定变量时，带入的绑定变量参
–//数是timestamp类型时，不再存在隐式转换。即使秒后面的值非0!!
–//我看了我以前写的[20191219]oracle timestamp数据类型的存储.txt=>
–//如果秒后面的值是0，存储占用7个字节。
–//在家里仅仅有12c的环境，做一些补充测试：
1.环境：
SCOTT@test01p> @ ver1
PORT_STRING VERSION BANNER CON_ID
13 3pdjz4fgwwfj2 SELECT /+ test1 / COUNT() FROM EMPX WHERE HIREDATE = :B1
13 0juh2dbyx948s SELECT /+ test2 / COUNT() FROM EMPX WHERE HIREDATE = :B1
13 f04fd6q8z7n9w SELECT /+ test3 / COUNT() FROM EMPX WHERE HIREDATE = :B1
13 f3gx0d2rfn9sb SELECT /+ test4 / COUNT() FROM EMPX WHERE HIREDATE = :B1
$ echo 3pdjz4fgwwfj2 0juh2dbyx948s f04fd6q8z7n9w f3gx0d2rfn9sb | tr ‘ ‘ ‘\n’ | xargs -IQ sqlplus scott/btbtms@test01p @ dpc Q ” ” | egrep I_EMPX_HIREDATE
| 2 | INDEX RANGE SCAN| I_EMPX_HIREDATE | 1 | 8 | 1 (0)| 00:00:01 |
| 2 | INDEX RANGE SCAN| I_EMPX_HIREDATE | 1 | 8 | 1 (0)| 00:00:01 |
| 2 | INDEX RANGE SCAN| I_EMPX_HIREDATE | 1 | 8 | 1 (0)| 00:00:01 |
| 2 | INDEX RANGE SCAN| I_EMPX_HIREDATE | 1 | 8 | 1 (0)| 00:00:01 |
–//恩，真心彻底颠覆我的认知,12c下就可以避免这种形式的隐式转换.并且4种timestamp形式都可以,只要使用绑定变量就ok。
SCOTT@test01p> @ dpc f3gx0d2rfn9sb ” ”
PLAN_TABLE_OUTPUT
SELECT /+ test4 / COUNT() FROM EMPX WHERE HIREDATE = :B1
Plan hash value: 3602029756
| 0 | SELECT STATEMENT | | | | 1 (100)| |
| 1 | SORT AGGREGATE | | 1 | 8 | | |
| 2 | INDEX RANGE SCAN| I_EMPX_HIREDATE | 1 | 8 | 1 (0)| 00:00:01 |
1 – SEL$1
2 – SEL$1 / EMPX@SEL$1
Peeked Binds (identified by position):
2 – access(“HIREDATE”=:B1)
SCOTT@test01p> @ bind_cap f3gx0d2rfn9sb ”
SQL_ID CHILD_NUMBER WAS NAME POSITION MAX_LENGTH LAST_CAPTURED DATATYPE_STRING VALUE_STRING C30
0
SCOTT@test01p> @dpc ” ” ”
PLAN_TABLE_OUTPUT
select count() from empx where hiredate = timestamp ‘1980-12-17
00:00:00.000001001’
Plan hash value: 36332186
| 0 | SELECT STATEMENT | | | | 3 (100)| |
| 1 | SORT AGGREGATE | | 1 | 8 | | |
| 2 | TABLE ACCESS FULL| EMPX | 1 | 8 | 3 (0)| 00:00:01 |
1 – SEL$1
2 – SEL$1 / EMPX@SEL$1
Predicate Information (identified by operation id):
Bind#0
oacdty=180 mxl=11(11) mxlc=00 mal=00 scl=00 pre=00
oacflg=11 fl2=8000000 frm=00 csi=00 siz=16 off=0
kxsbbbfp=33849e88 bln=11 avl=11 flg=05
value=1980-12-17 00:00:00.
–//value后面有1个小数点.
…
Peeked Binds
Bind variable information
position=1
datatype(code)=180
datatype(string)=TIMESTAMP
max length=11
…
4.打开statistics_level = all看看:
@ dpc f3gx0d2rfn9sb ” ”
..
SQL_ID f3gx0d2rfn9sb, child number 1
| Id | Operation | Name | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time | A-Rows | A-Time |
–//buffers列都没有，也就是逻辑读应该为0，这样的情况连索引都没有探察。
SCOTT@test01p> @ dpc 3pdjz4fgwwfj2 ” ”
PLAN_TABLE_OUTPUT
SELECT /+ test1 / COUNT() FROM EMPX WHERE HIREDATE = :B1
Plan hash value: 3602029756
| 0 | SELECT STATEMENT | | 1 | | | 1 (100)| | 1 |00:00:00.01 | 1 |
| 1 | SORT AGGREGATE | | 1 | 1 | 8 | | | 1 |00:00:00.01 | 1 |
| 2 | INDEX RANGE SCAN| I_EMPX_HIREDATE | 1 | 1 | 8 | 1 (0)| 00:00:01 | 1 |00:00:00.01 | 1 |
8 drk7cbdh2c24u SELECT /+ test5 / COUNT(*) FROM EMPX WHERE HIREDATE = :B1
SCOTT@test01p> @ 10053x drk7cbdh2c24u 0
PL/SQL procedure successfully completed.
–//检查跟踪文件发现如下内容:
Peeked values of the binds in SQL statement
Original: https://www.cnblogs.com/lfree/p/16581342.html
Author: lfree
Title: [20220811]奇怪的隐式转换问题(12c补充测试).txt
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/606238/
转载文章受原作者版权保护。转载请注明原作者出处！