数据库中高级诊断理论与实战第3讲 - 理解SGA中最重要的shared pool 及library cache lock案例

 这是中高级诊断课程第3节，今天主要讲Oracle SGA结构最为重要和复杂的Shared pool。之前有同学反馈每次能加入awr案例分享就更好了，因此本文最后给大家分享一个library cache lock极高的实战案例，供大家参考！

 首先我们来简单回顾一下shared pool的历史（实际上我发现很多数据库目前目前都没有shared pool这个内存结构）。

1. shared pool 的历史

Shared pool 是Oracle 7 引入的一个内存结构。在之前的版本中，每个进程的所有SQL都是需要进行全部解析的，高并发环境，是无法支持的。最开始shared pool是一个整体，虽然从结构上来讲，在oracle 7时就包含字典cache和library cache等结构，然后从oracle 9i开始，shared pool做了一个较大的改进，即将整个shared pool 划分为多个sub pool。每个sub pool的结构完全一致。如下图所示：

这是Oracle 7~8的情况。Oracle 9i以及之后的版本，你看到的情况应该是这样：

注意，其中的vector buffer是Oracle 23 AI最新版才引入的内存结构。

1. shared pool的结构组成

shared pool的结构主要包含2部分，library cache和dictionary  cache（row cache）。

1） Oracle 中的SQL语句的执行情况

   当用户发起SQL语句后,该SQL会进入library cache,首先Oracle会从row cache中去寻找跟该SQL 中涉及对象相关的信息,比如表名称,column 信息,权限信息等等.
  假设找不到需要的信息,那么Oracle 会从disk上进行取得,并读取到buffer cache中,然后存到row cache中(当然这其实是递归操作). 存在row cache后会构造出
  类似dc_segments,dc_columns,dc_users等数据字典信息. 最后再把需要的信息读取到library cache中。

   接着才是解析SQL，生成执行计划，执行SQL的过程。

复制

2） library cache