今天下午发现服务器的load很高，开始处理
1.select * from v$session_wait where wait_class<>'Idle' 发现db file sequential read
2.sselect * from v$session_longops order by last_update_time desc 发现有几个time_remaining>3000的纪录
3.select * from v$sqlarea where sql_id='4ufyrydd1xsra' 找到sql，绑定变量
4.测试sql的执行计划ok，找了几个正常情况下的值赋上执行ok，找了些特殊值测试还是ok
5.google发现eagle的文章http://www.dbafan.com/blog/?p=267 “通过ERRORSTACK找出正在运行的SQL中的绑定变量值”
6.照做
SQL> oradebug setospid 29397
Oracle pid: 58, Unix process pid: 29397, image: oracle@qadb17 (TNS V1-V3)
SQL> oradebug dump errorstack 3
Statement processed. (这里是copy过来的，我实际执行的语句被cat的时候覆盖了)
cat db2_ora_31978.trc | grep value 发现原来确实是特殊值的问题
calling call entry argument values in hex
location type point (? means dubious value)
application name: JDBC Thin Client, hash value=0
value="敏感词汇"
value="N/A"
某个字段的default value='N/A'， 数据量估计在上千万，赶快kill掉并联络开发人员限制'N/A'的出现。
1.select * from v$session_wait where wait_class<>'Idle' 发现db file sequential read
2.sselect * from v$session_longops order by last_update_time desc 发现有几个time_remaining>3000的纪录
3.select * from v$sqlarea where sql_id='4ufyrydd1xsra' 找到sql，绑定变量
4.测试sql的执行计划ok，找了几个正常情况下的值赋上执行ok，找了些特殊值测试还是ok
5.google发现eagle的文章http://www.dbafan.com/blog/?p=267 “通过ERRORSTACK找出正在运行的SQL中的绑定变量值”
6.照做
SQL> oradebug setospid 29397
Oracle pid: 58, Unix process pid: 29397, image: oracle@qadb17 (TNS V1-V3)
SQL> oradebug dump errorstack 3
Statement processed. (这里是copy过来的，我实际执行的语句被cat的时候覆盖了)
cat db2_ora_31978.trc | grep value 发现原来确实是特殊值的问题
calling call entry argument values in hex
location type point (? means dubious value)
application name: JDBC Thin Client, hash value=0
value="敏感词汇"
value="N/A"
某个字段的default value='N/A'， 数据量估计在上千万，赶快kill掉并联络开发人员限制'N/A'的出现。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/10341434/viewspace-622241/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
越来越觉得自己啰嗦!
下一篇：
不要急躁! 注意聆听!
请登录后发表评论
登录
全部评论
