晚间迁移数据库后，第二天下午来调优，发现CPU占用达到惊人的99%，如下：
分析15:00-16:00期间AWR报告，发现SQL硬解析严重，如下：
每秒硬解析达到69.9次，library hit%太低86%，如下：
此时的共享池达到了13G，如下：
可见有66次自动增大调整共享池的操作，由大量的SQL解析占用内存造成。
显然，这是因为应用没有合理使用绑定变量导致。
鉴于几年累积的大量应用难以短时间优化、修改SQL语句，因此决定修改数据库默认参数cursor_sharing，由EXACT修改为FORCE：
alter system set cursor_sharing=FORCE SCOPE=spfile SID='*';
晚间重启数据库，效果满意，CPU占用同期降到了30%以下，SQL硬解析大大降低为每秒0.5次，library hit%达到了理想的99.9%，如下：
共享池也大大降低为7G左右，如下：
以下为优化调整前后CPU占用走势图，红色区域为调整前99%，绿色区域为调整后30%：
因此，你能想象，这个绑定变量对系统整体性能的影响会如此之大吗？
但反过来想一下，这个症状如此简单的问题，是否说明oracle数据库本身的设计很弱智？
文章评论