Oracle Instance

曾经也学习过oracle 逻辑结构的知识。但用的不多好多都是有点概念，近期做到一个跨instance工作流。全部抽点时间温习了一下相关知识。把网上看到的感觉讲的还比較明了。全面的文章汇总一下

instance = 内存结构(SGA,system global area) +后台进程

内存结构 = 共享池+数据快速缓存+重做日志缓冲区+其它

后台进程 = DBWn(database writer n个)+LGWR(log writers)+SMON(system monniter)+PMON(progress moniter)+CKPT(checkpoint)+……

PGA（Program Global Area)= server进程+后台进程

以下分别介绍各部分：

共享池

1、共享池用于存放近期运行的SQL语句和数据字典信息，其尺寸由初始化參数SHARED_POOL_SIZE定义。

共享池主要由库快速缓存和数据字典快速缓存两部分组成。

库快速缓存用于存放近期运行的SQL语句信息。包含SQL语句文本，解析代码值及其运行计划。运行计划是SQL语句的内部操作步骤。

比如：当运行select name from students where grade=90时，假设grade列上不存在索引，运行计划将採用全表扫描；假设有索引。运行计划将使用索引和ROWID定位数据。

如上图所看到的。库快速缓存包括很多上下文区，每一个上下文区都有对应的SQL语句运行计划，这些上下文区又被称为共享游标。当client运行SQL语句时，server进程首先检查共享游标是否存在，若存在则依照运行计划直接运行就可以；若不存在则生成SQL语句运行计划，并将运行计划存放到对应的上下文区中。然后运行SQL语句。共享游标减少了SQL语句解析的次数。提高了运行性能。

另外，语句1和语句2因为文本不同，所以占用不同的上下文区，而对于文本全然同样的语句1来说能够共享上下文区。

所谓的文本全然同样指的是：语句文本同样；大写和小写和长度同样；赋值变量同样。

数据字典快速缓存用于存放数据字典的信息，包含表、列的定义以及权限信息。

最后，库快速缓存和数据字典快速缓存的尺寸是能够变化的。动态改变共享池的尺寸：alter system set shared_pool_size = 60M;

数据快速缓存

数据快速缓存用于存放近期訪问的数据块信息，它由很多小缓冲区组成。

数据快速缓存採用LRU(least recently used)算法管理数据快速缓存。

数据快速缓存的结构：分为三部分。各自是脏缓冲区、空暇缓冲区、忙缓冲区。脏缓冲区是指内容与对应数据块不一致的缓冲区。空暇缓冲区是指内容与对应数据块一致或者不包括数据的缓冲区；忙缓冲区是指服务进程正在存取的缓冲区。

重做日志缓冲区

重做日志缓冲区用于记载instance的变化。

后台进程

后台进程是指oracle server隐含运行的进程。

启动instance时不仅会分配SGA。还会启动后台进程；关闭intance时不仅释放SGA所占的内存空间。并且会释放后台进程所占用的CPU和内存资源。

以下介绍一下经常使用的后台进程：

SMON（System Monitor)：用于运行intance恢复、合并空间碎片并释放暂时段。

PMON(Process Monitor)用于监视server进程的运行。而且在server进程失败时清除该server进程。

--================================================================================

Oracle内存结构

Oracle内存结构主要能够分共享内存区与非共享内存区，共享内存区主要由SGA（System Global Area）组成。非共享内存区主要由PGA（Program Global Area）组成（见图1-1）。

从图1-1中能够看到，Oracle共享内存区主要包含数据缓冲区（Data buffer）、共享池（Shared pool）及一些其它的结构。而PGA则主要包含会话的一些信息及排序区，Hash join区域等。以下分别介绍这些内容。

SGA

系统全局区（SGA，System Global Area）事实上是一块巨大的共享内存区域，包括了Oracle的数据缓冲及众多的控制结构。这里的数据能够被Oracle的各个进程共用。假设有相互排斥的操作。如锁定一个内存对象，则须要通过Latch与Enqueue来控制。

每一个Oracle实例（instance）仅仅能启动一个SGA，除非通过RAC等一些特殊的全局管理方式。否则不同的实例仅仅能訪问自己的SGA区域。通过例如以下的方式就能够查看SGA大小：

10gR2  Piner>show sga
Total System Global Area 8877225568 bytes
Fixed Size                  755296 bytes
Variable Size              486539264 bytes
Database Buffers         8388608000 bytes
Redo Buffers                1323008 bytes

以上结果是一个典型的OLTP环境中的SGA的分配情况，我们能够看到四个大的部分。

Fixed Size，包含了一些数据库与实例的控制信息、状态信息、字典信息等，启动的时候就固定在SGA中。并且不会改变。

Variable Size，包括了shared pool、large pool、java pool、streams pool、游标区和其它结构等，合计450MB左右。

Database buffers，有时候也叫Data buffer，它是数据库中数据块缓冲的地方，数据块在内存中就缓存在这里。所以。在OLTP环境中，Data buffer是SGA中最大的缓冲区，是数据库性能高低的关键所在。

Redo buffers，它是为了加快日志写进程的速度而设立的缓冲区，在一般OLTP环境中。由于提交非常频繁。所以一般不会非常大。

SGA的大小信息也能够从v$sga中获得。与show sga的结果一样。

另外，v$sgastat记录了SGA的一些统计信息。v$sga_dynamic_components则保存了SGA中能够动态调整的区域的一些动态或者手工调整记录。

以下将介绍SGA中最重要的两个对象，共享池（Shared pool）与数据缓冲区（Database buffer）。其它的池。如Streams pool，在介绍Streams的章节时再另外介绍。

共享池（Shared pool）

共享池是SGA中很关键的内存片段。特别是在性能和可伸缩性上。由初始化參数shared_pool_size决定其大小，在Oracle 10g以后。Oracle能够自己主动管理大小。

在典型的OLTP高可用环境中，一个太小的共享池会扼杀性能，导致出现Ora-04031错误，使系统停止执行。可是太大的共享池也将消耗大量的CPU来管理。在数据仓库环境中。由于并发进程的须要。可能会分配比較大的共享池。

提醒：在实际的高可用环境中。有非常大的一部分故障就是由于共享池的原因而导致系统停顿甚至宕机的，如Latch争用、Ora-0431错误、Library cache争用与等待。

不对地使用共享池仅仅会带来灾难性的后果。所以，必须先要了解共享池的作用。

共享池又能够分为SQL语句缓冲区（Library Cache）、数据字典缓冲区（Data Dictionary Cache）及一些控制结构。而数据字典缓冲区与控制结构是用户无法直接控制的，所以，真正与用户有关的事实上就是SQL语句缓冲区。

当一个用户第一次提交一个SQL语句。Oracle会将这句SQL进行硬分析（Hard parse）。这个过程类似于程序编译，会耗费相对较多的时间，由于它要分析语句的语法与语义，获得最佳的运行计划（Sql plan），并在内存中分配一定的空间来保存该语句与相应的运行计划等信息。

由于Oracle总是保存语句的运行信息。当数据库第二次或者多次运行该SQL时。Oracle自己主动跳过这个硬分析过程。变为软分析（Soft parse）或高速软分析（Fast soft parse）。从而降低了系统分析的时间，降低CPU与Latch的消耗。

注意：Oracle中仅仅有全然同样的语句，包含大写和小写、空格、换行都要求一样，才干反复使用曾经的分析结果与运行计划。

图1-2是一个完整的SQL语句的分析过程：

所以，假设大量的，频繁訪问的SQL语句都不採用绑定（Bind）变量。Oracle为了做SQL的硬分析，Shared pool latch将变得严重争用与等待，相同也会耗费大量的CPU，直到机器的资源耗尽。

另外，由于Oracle会从共享池中分配空间来保存刚做完硬分析的SQL语句，也将耗费大量的内存空间。并且，这些被浪费的空间无法被重用。

对于编程者来说，要尽量提高语句的重用率。降低语句的分析时间。一个设计非常差的应用程序能够毁掉整个数据库。为了避免出现这种问题，Oracle从9i開始。还引进了一个新的參数cursor_sharing，只是，由于该參数总是带来非常多其它问题，如bug，所以，在现有的数据库版本号上，还是不建议在高可用的生产环境中使用。

SQL> alter system flush shared_pool;

与共享池相关的视图非常多。这里介绍几个可能在高可用环境中常常须要用到的视图。

v$sqlarea，每条记录都显示了一个SQL语句的具体统计信息，包含历史以来的运行次数、物理读、逻辑读、耗费时间等许多的重要信息。

v$sqltext_with_newlines。由于v$sqlarea仅仅是记录了一个语句或者是一个游标的前1000个字符。假设是比較大的SQL语句，则不能在v$sqlarea中全然显示。

假设通过这个视图，能够获得一个SQL语句的具体信息。在这个视图中。一个SQL语句分为多行保存，通过hash_value来标示语句，通过piece来排序。

v$sql_plan视图保存了被运行的SQL语句的运行计划。能够通过特定的脚本获得曾经运行过的语句的运行计划。在本书的后面章节有这种讨论。

只是。该视图在9i的早些版本号，如9206曾经，存在一些bug，查询该视图。可能会出现600错误，甚至导致数据库崩溃。

v$shared_pool_advice，这个视图会对Oracle的共享池做一些预測。范围可能在当前值的50%~200%之间，优化者能够依据视图显示的信息做优化推断。如又一次调整共享池大小。

当中的字段SHARED_POOL_SIZE_FACTOR说明了预測的共享池大小与如今大小的比例。

对于并发非常多。并且訪问频繁的高可用环境。须要避免例如以下的一些情况。在本书的后面将有具体的案例分析来说明其原因与避免方法：

共享池不够或bug导致的0431错误，该错误可能导致系统无法訪问。

分析数据改变导致运行计划改变，错误的运行计划可能导致系统无法运行。

添加了新的对象，如索引。引起执行计划改变而导致系统无法执行。

改动表导致依赖的存储过程或者是包失效。而无法自己主动编译成功。导致系统崩溃。

错误的操作方法导致严重的Latch争用与等待。
SQL>select * from v$fixed_view_definition t where t.view_name=‘GV$BH‘不同的是。x$bh包括了很多其它的信息，如touch count信息，在Oracle 8i以上作为LRU算法的一个重要的參考信息，表示了一个块的热点程度。touch count信息相应到x$bh的tch字段，而段的data_object_id信息相应到x$bh的obj，或者是v$bh的objd。有了这些基本信息，事实上就非常好确认热点块在哪里了。
不同的是，x$bh包括了很多其它的信息，如touch count信息。在Oracle 8i以上作为LRU算法的一个重要的參考信息，表示了一个块的热点程度。touch count信息相应到x$bh的tch字段，而段的data_object_id信息相应到x$bh的obj，或者是v$bh的objd。有了这些基本信息，事实上就非常好确认热点块在哪里了。