第17章SharedPool原理与性能分析.PDFVIP

17 第17章 Shared Pool原理及性能分析 hared Pool 是 Oracle SGA 设置中最复杂也是最重要的一部分内容，Oracle 通过 Shared Pool S 来实现SQL 共享、减少代码硬解析等，从而提高数据库的性能。在某些版本中，如果设置不当， Shared Pool可能会极大地影响数据库的正常运行。 本章就 Shared Pool 的原理及性能问题进行深入探讨，并通过几个具体案例介绍相关性能问 题的诊断及解决方法。 17.1 Shared Pool的基本原理 在 Oracle 7之前，Shared Pool 并不存在，每个 Oracle连接都有一个独立的Server 进程与 之相关联，Server 进程负责解析和优化所有SQL和PL/SQL 代码。典型的，在 OLTP环境中，很多 代码具有相同或类似的结构，反复的独立解析浪费了大量的时间以及资源，Oracle最终认识到这 个问题，并且从 PL/SQL 开始尝试把这部分可共享的内容进行独立存储和管理，于是 Shared Pool 作为一个独立的 SGA 组件开始被引入，并且其功能和作用被逐渐完善和发展起来。 在这里注意到，Shared Pool 最初被引入的目的，也就是它的本质功能在于：实现共享。如 果系统代码是完全异构的（假设你的代码从不绑定变量，从不反复执行），那么会发现，这时候 Shared Pool 完全就成为了一个负担，它在徒劳无功地进行无谓的努力：保存代码、执行计划等 期待重用，并且客户端要不停的获取 Latch，试图寻找共享代码，却始终一无所获。如果真是如 此，那这是我们最不愿看到的情况，Shared Pool 变得有害无益。当然这是极端，可是在性能优 化中会发现，大多数性能低下的系统都存在这样的通病：代码极少共享，缺乏或从不实行变量绑 定。优化这些系统的根本方法就是优化代码，使代码（在保证性能的前提下）可以充分共享，减 少无谓的反复硬/软解析。 实际上，Oracle 引入 Shared Pool 就是为了帮助实现代码的共享和重用。了解了这一点之后， 开发人员在应用开发的过程中，就应该有意识地提高自己的代码水平，以期减少数据库的压力。 这也应该是对开发人员的最初和最基本的要求。 17.2 Shared Pool的设置说明 Shared Pool的大小通过初始化参数 shared_pool_size 设置。 第17 章 Shared Pool原理及性能分析 233 对于Shared Pool 的设置，一直以来是最具有争议的一部分内容。一方面很多人建议可以把Shared Pool 设置得稍大，以充分Cache代码和避免 ORA-04031 错误的出现；另一方面又有很多人建议不能把 Shared Pool 设置得过大，因为过大可能会带来管理上的额外负担，从而会影响数据库的性能。 至于哪一种说法更为准确，这个管理上的额外负担究竟指什么，这并不是一句话就能予以定 论的，下面试图通过一些内部分析，从内部原理来回答这个问题。 17.2.1 基本知识 下面用到了Shared Pool的转储，所以首先了解一下与其相关的命令。 可以通过以下命令转储 Shared Pool 共享内存的内容： SQL alter session set events immediate trace name heapdump level 2; Session altered. 本测试中引用的两个trace 文件: 9i: SQL @gettrcname TRACE_FILE_NAME /opt/oracle/admin/hsjf/udump/hsjf_ora_24983.trc 8i: SQL @gettrcname TRACE_FILE_NAME /usr/oracle8/admin/guess/udump/guess_ora_22038.trc 其中alter session set events immedia