今天应用测试的时候发现一个语句执行很慢，通过session找出sql_Id，看了下执行计划，一个小表对一个大表做nl关联，而且大表是全表扫描，不用问，执行计划的问题，于是查看对象是否做表分析，发现表分析20刚做过，通过v$sql_plan发现执行计划是上午10点生成的，看来是由于表分析之前解析错误导致的，于是用dbms_shared_pool.purge来purge这个cursor，执行purge之后，一直等待，查看等待事件，是 cursor: pin x wait s，
没办法，只有kill掉在跑的session，等了一会，purge完了，再让应用调用，发现速度恢复正常了。
当然方法很多，表分析，grant等等都可以，不过这种方法的影响是最少的，只针对这个cursor
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/16158219/viewspace-628938/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
最新文章
- 10.2和以上版本的pga动态工作区管理
- database records an archived log in the control file
- When RMAN Performs Control File Autobackups
- Planning an Incremental Backup Strategy
- Multiple Copies of RMAN Backups
- 关于flashback log
- maximum control file size？？
- Renaming a Datafile in the Primary Database
- Duplicate Database fails with Rman-5001 [ID 334588.1]
- Oracle backup fails with error RMAN-06056: could not access datafile
