sharepool深入分析笔记.doc

共享池shared pool的概念 用户提交的命令：解析、执行 用户命令的解析： 解析的过程是一个相当复杂的过程，它要考虑各种可能的异常情况，比如SQL语句涉及到的对象不存在、提交的用户没有权限等等。而且，还需要考虑如何执行SQL语句，采用什么方式去获取数据等。解析的最终结果是要产生oracle自己内部的执行计划，从而指导SQL的执行过程。可以看到，解析的过程是一个非常消耗资源的过程。因此，oracle在解析用户提交的SQL语句的过程中，如果对每次出现的新的SQL语句，都按照标准过程完整的从头到尾解析一遍的话，效率太低，尤其随着并发用户数量的增加、数据量的增加，数据库的整体性能将直线下降。 Library cache+dictionay cache Library cache是重点，所有信息都放在dictionary cache 数据获取方式：全表/索引；表是如何连接 代码共享-》执行计划共享 SQL语句静态部分和动态部分 oracle对SQL语句进行了概括和抽象，将SQL语句提炼为两部分，一部分是SQL语句的静态部分，也就是SQL语句本身的关键词、所涉及的表名称以及表的列等。另一部分就是SQL语句的动态部分，也就是SQL语句中的值（即表里的数据）。很明显的，整个数据库中所包含的对象数量是有限的，而其中所包含的数据则是无限的。而正是这无限的数据导致了SQL语句的千变万化，也就是说在数据库运行的过程中，发生的所有SQL语句中，静态部分可以认为数量是有限的，而动态部分则是无限的。而实际上，动态部分对解析的影响相比静态部分对解析的影响来说是微乎其微，也就是说通常情况下，对于相同的静态部分的SQL语句来说，不同的动态部分所产生的解析结果（执行计划）基本都是一样的。这也就为oracle提高解析SQL语句的效率提供了方向。 Select。。。。From。。。。静态 Where。。。。动态 通过参数解决动态没有绑定变量的问题 共享池 oracle会将用户提交来的SQL语句都缓存在内存中。每次处理新的一条SQL语句时，都会先在内存中查看是否有相同的SQL语句。如果相同则可以减少最重要的解析工作（也就是生成执行计划），从而节省了大量的资源；反之，如果没有找到相同的SQL语句，则必须重新从头到尾进行完整的解析过程。这部分存放SQL语句的内存就叫做共享池（shared pool）。当然，shared pool里不仅仅是SQL语句，还包括管理shared pool的内存结构以及执行计划、控制信息等等内存结构。 Oracle通过内存结构管理 绑定变量 当oracle在shared pool中查找相同的SQL语句的过程中，如果SQL语句使用了绑定变量（bind variable），那么就是比较SQL语句的静态部分，前面我们已经知道，静态部分是有限的，很容易就能够缓存在内存里，从而找到相同的SQL语句的概率很高。如果没有使用绑定变量，则就是比较SQL语句的静态部分和动态部分，而动态部分的变化是无限的，因此这样的SQL语句很难被缓存在shared pool里。毕竟内存是有限的，不可能把所有的动态部分都缓存在shared pool里，即便能够缓存，管理这样一个无限大的shared pool也是不可能完成的任务。不使用绑定变量导致的直接结果就是，找到相同的SQL语句的概率很低，导致必须完整的解析SQL语句，也就导致消耗更多的资源。从这里也可以看出，只有我们使用了绑定变量，才真正遵循了oracle引入shared pool的哲学思想，才能够更有效的利用shared pool 共享池：库缓存+字典缓存 shared pool的大小由初始化参数shared_pool_size决定。10g以后可以不用设定该参数，而只需要指定sga_target，从而oracle将自动决定shared pool的大小尺寸。在一个很高的层次上来看，shared pool可以分为库缓存（library cache）和数据字典缓存（dictionary cache）。Library cache存放了最近执行的SQL语句、存储过程、函数、解析树以及执行计划等。而dictionary cache则存放了在执行SQL语句过程中，所参照的数据字典的信息，包括SQL语句所涉及的表名、表的列、权限信息等。dictionary cache也叫做row cache，因为这里面的信息都是以数据行的形式存放的，而不是以数据块的形式存放的。对于dictionary cache来说，oracle倾向于将它们一直缓存在shared pool里，不会将它们交换出内存，因此我们不用对它们进行过多的关注。而library cache则是shared pool里最重要的