Shared Pool Tuning
目标是提高命中率, 以减少 I/O 操作
shared pool : 是由 library cache, data dictionary cache 两部分组成. 由于 data dictionary cache 在内存中的时间比 library cache 时间长, 所以就命中率来说, 只要 library cache 命中了, 那么 data dictionary cache 肯定也命中, 所以我们要提高 library cache 命中率.
注意, 提高library cache 是我们调优时最优先考虑的, 因为向后的调优, 都是建立在SQL已经在内存中的情况, 而没有命中的话, SQL就不在内存中(需要再调入内存), 所以向后的调优就无从谈起.
那么如何调优 library cache, 希望 SQL 命中呢 ?
1. Make sure that users can share statements, 能够各个用户之间尽可能的共享 SQL statement
- As much generic code as possible, 这句话没有理解, 什么叫 generic 呢？
- Bind varibales rather than constants
2. Prevent statements from being aged out by allocating enough space. 说白了就是增大些内存而保证在里的SQL statement 不会过期.
因为oracle内存调度采用的是 LRU (least recently used, 最近被使用原则, 所以如果某个SQL长时间没有被使用, 另外Share pool 内存还不够的话, 这个SQL就会被移出)
3. Avoid invalidations that induce reparsing
造成 SQL invalidations 目前知道的原因是, 比如你一个SQL已经解析了, 随后这个SQL所引用的 schema object 发生了变化, 比如表被 anylse, 或者重新编译了plsql等,
这样, 之前解析完成的SQL statement 就变成 invalidation, 即便你又提交了一个一样的 SQL 语句给 ORACLE, 也需要再重新解析一遍.
这里有 3 个术语:
Gets: (Parse) The number of lookups for objects of the newspace (在解析阶段, 需要的资源)
Pins: (Execution) The number of reads or executions of the objects of the newspace(在执行阶段, 需要的资源)
Reloads: (Reparse) The number of library cache misses on the execution step, causing implicit reparsing of the statement and block.
( 注意, 这个内容是, 已经在执行阶段了, 然后发现解析的有问题, 比如 schema object 发生了变化, 然后重新解析, 看来这种是最伤的 )
另外还有一些重要视图, 在 oracle SG 中有罗列, 不知道是否有用, 这里不写了.
Execution plan
解析后, 真正的执行步骤, 调优SQL十分重要, 因为ORACLE的解析过程, 我们是不知道的, 只能通过解析完后真正的执行计划, 来修改SQL语句, 调优, 这样会得到新的 execution plan, 注意这个过程中的oracle是如何解析的, 我们还是不知道(记得编译原理中的什么词法分析, 语法分析, 等等吧), 新的执行计划所付出的代价, 我们是否可以接受.
The main benefit of this (execution plan) is better diagnosis of query performance. v$sql_plan 这里保存了这个执行计划(PLAN_TABLE 有跟这个视图类似的内容)