[20200423]防水墙与v$open_cursor.txt --//前几天我跟踪特定sql语句,发现使用防水墙产品会不断调用 begin :con := "TASSETACL"."QUERYACL"(:sn, :on); end; --//链接 : http://blog.itpub.net/267265/viewspace-2686598/ --//我发现实际上仅仅访问的sql语句包含特定的表就会出现这样递归调用。另外我发现一旦访问特定表,该语句的光标就不会进入 --//SESSION CURSOR CACHED.通过测试说明: 1.环境: PPPPP_HHH@xxxx> @ ver1 PORT_STRING VERSION BANNER ------------------------------ -------------- -------------------------------------------------------------------------------- x86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production $ cat voc.sql column SID format 9999 column USER_NAME format a10 column CURSOR_TYPE format a32 column SQL_TEXT format a34 select * from v$open_cursor where sql_id='&&1' and sid=&&2; 2.测试: --//session 1: PPPPP_HHH@xxxx> @ spid SID SERIAL# PROCESS SERVER SPID PID P_SERIAL# C50 ---------- ---------- ------------------------ --------- ------ ------- ---------- -------------------------------------------------- 6414 29699 8395 DEDICATED 127683 668 172 alter system kill session '6414,29699' immediate; --//记下sid=6414. PPPPP_HHH@xxxx> select 8 from zz_yyyy where zyh=1; no rows selected --//其中zz_yyyy是被审计的表。 PPPPP_HHH@xxxx> @ hash HASH_VALUE SQL_ID CHILD_NUMBER HASH_HEX ---------- ------------- ------------ --------- 2731930736 2apy2y6jdbx3h 0 a2d5f470 --//sql_id=2apy2y6jdbx3h --//session 2: SYS@xxxx> @ voc 2apy2y6jdbx3h 6414 no rows selected --//可以发现看不到该语句。 --//session 1: PPPPP_HHH@xxxx> select 8 from zz_yyyy where zyh=1; no rows selected --//session 2: SYS@xxxx> @ voc 2apy2y6jdbx3h 6414 SADDR SID USER_NAME ADDRESS HASH_VALUE SQL_ID SQL_TEXT LAST_SQL_ACTIVE_TIM SQL_EXEC_ID CURSOR_TYPE ---------------- ----- ---------- ---------------- ---------- ------------- ---------------------------------- ------------------- ----------- ----------- 00000012B2D46D10 6414 PPPPP_HHH 00000000D3F4DB20 2731930736 2apy2y6jdbx3h select 8 from zz_yyyy where zyh=1 OPEN --//11g与10g上在这里有一点点不同,当语句执行时该语句的光标不会马上关闭,所以在session 2可以看到光标CURSOR_TYPE='OPEN'.在 --//执行另外语句时关闭。 --//session 1,执行另外语句看看: PPPPP_HHH@xxxx> select 8 from dual; 8 ---------- 8 --//session 2: SYS@xxxx> @ voc 2apy2y6jdbx3h 6414 no rows selected --//再次消失。也就是防水墙要审计的表不会缓存。 3.继续测试: --//session 1: PPPPP_HHH@xxxx> select 8 from dual; 8 ---------- 8 PPPPP_HHH@xxxx> @ hash HASH_VALUE SQL_ID CHILD_NUMBER HASH_HEX ---------- ------------- ------------ --------- 925730553 43jhwwsvkv1rt 0 372d86f9 --//看看sql_id=43jhwwsvkv1rt的情况: --//sesion 2: SYS@xxxx> @ voc 43jhwwsvkv1rt 6414 no rows selected --//嗯这里有点奇怪,不过再次执行没ok了。 --//session 1: select 8 from dual; select 8 from dual; select 8 from dual; --//每次执行完成都在session 2执行@ voc 43jhwwsvkv1rt 6414: SYS@xxxx> @ voc 43jhwwsvkv1rt 6414 SADDR SID USER_NAME ADDRESS HASH_VALUE SQL_ID SQL_TEXT LAST_SQL_ACTIVE_TIM SQL_EXEC_ID CURSOR_TYPE ---------------- ----- ---------- ---------------- ---------- ------------- ---------------------------------- ------------------- ----------- -------------------------------- 00000012B2D46D10 6414 PPPPP_HHH 00000000BF7AFEC8 925730553 43jhwwsvkv1rt select 8 from dual OPEN SYS@xxxx> @ voc 43jhwwsvkv1rt 6414 SADDR SID USER_NAME ADDRESS HASH_VALUE SQL_ID SQL_TEXT LAST_SQL_ACTIVE_TIM SQL_EXEC_ID CURSOR_TYPE ---------------- ----- ---------- ---------------- ---------- ------------- ---------------------------------- ------------------- ----------- -------------------------------- 00000012B2D46D10 6414 PPPPP_HHH 00000000BF7AFEC8 925730553 43jhwwsvkv1rt select 8 from dual DICTIONARY LOOKUP CURSOR CACHED SYS@xxxx> @ voc 43jhwwsvkv1rt 6414 SADDR SID USER_NAME ADDRESS HASH_VALUE SQL_ID SQL_TEXT LAST_SQL_ACTIVE_TIM SQL_EXEC_ID CURSOR_TYPE ---------------- ----- ---------- ---------------- ---------- ------------- ---------------------------------- ------------------- ----------- -------------------------------- 00000012B2D46D10 6414 PPPPP_HHH 00000000BF7AFEC8 925730553 43jhwwsvkv1rt select 8 from dual SESSION CURSOR CACHED --//可以发现防水墙产品改变了光标cache的规则,只要审计的语句中包含要审计的表该光标就不会SESSION CURSOR CACHED。 --//如果你跟踪就可以发现: ===================== PARSING IN CURSOR #140299736370064 len=52 dep=1 uid=131 oct=47 lid=131 tim=1587629118124616 hv=3354287527 ad='257135c60' sqlid='190q1sz3ywrd7' begin :con := "TASSETACL"."QUERYACL"(:sn, :on); end; END OF STMT PARSE #140299736370064:c=0,e=33,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,plh=0,tim=1587629118124615 BINDS #140299736370064: Bind#0 oacdty=01 mxl=4000(4000) mxlc=00 mal=00 scl=00 pre=00 oacflg=03 fl2=0001 frm=01 csi=852 siz=4000 off=0 kxsbbbfp=7f9a13ecfad0 bln=4000 avl=00 flg=05 Bind#1 oacdty=01 mxl=32(10) mxlc=00 mal=00 scl=00 pre=00 oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0 kxsbbbfp=7fffd8c6e17e bln=32 avl=10 flg=09 value="PPPPP_HHH" Bind#2 oacdty=01 mxl=32(07) mxlc=00 mal=00 scl=00 pre=00 oacflg=10 fl2=0001 frm=01 csi=852 siz=32 off=0 kxsbbbfp=7fffd8c6e1b2 bln=32 avl=07 flg=09 value="zz_yyyy" EXEC #140299736370064:c=1000,e=344,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=1,plh=0,tim=1587629118125014 CLOSE #140299736370064:c=0,e=9,dep=1,type=3,tim=1587629118125073 --//在每次执行前都会存在以上的调用。 ===================== PARSING IN CURSOR #140299736136776 len=33 dep=0 uid=103 oct=3 lid=103 tim=1587629118126459 hv=2731930736 ad='d3f4db20' sqlid='2apy2y6jdbx3h' select 8 from zz_yyyy where zyh=1 END OF STMT --//这样对于性能影响并不大,但是会导致大量的sql语句不会软软解析。这也是我上次为什么执行: select * from v$open_cursor where sql_id='&&1'; --//很多时候抓取不到会话sid的情况。 --//同时也就是在学习时要注意这些细节问题。
[20200423]防水墙与v$open_cursor.txt
来源:这里教程网
时间:2026-03-03 15:29:48
作者:
编辑推荐:
下一篇:
相关推荐
-
雷神推出 MIX PRO II 迷你主机:基于 Ultra 200H,玻璃上盖 + ARGB 灯效
2 月 9 日消息,雷神 (THUNDEROBOT) 现已宣布推出基于英
-
制造商 Musnap 推出彩色墨水屏电纸书 Ocean C:支持手写笔、第三方安卓应用
2 月 10 日消息,制造商 Musnap 现已在海外推出一款 Oce
热文推荐
- Oracle 19C+13.4EMCC主机监控
Oracle 19C+13.4EMCC主机监控
26-03-03 - [20200424]跟踪特定sql语句以及v$open_cursor视图(再补充).txt
- Oracle 19C OGG基础运维-05DDL操作同步
Oracle 19C OGG基础运维-05DDL操作同步
26-03-03 - Oracle 19C OGG基础运维-06增加复制表
Oracle 19C OGG基础运维-06增加复制表
26-03-03 - Oracle 19C OGG基础运维-07减少复制表
Oracle 19C OGG基础运维-07减少复制表
26-03-03 - Oracle 19C OGG基础运维-08Error code [942]
- Oracle 19C OGG基础运维-09OGG-15121错误
Oracle 19C OGG基础运维-09OGG-15121错误
26-03-03 - 疫情后时代,招投标形势将如何?
疫情后时代,招投标形势将如何?
26-03-03 - 连载一:Oracle迁移文档大全
连载一:Oracle迁移文档大全
26-03-03 - 串通投标,为何屡禁不止
串通投标,为何屡禁不止
26-03-03
