oracle体系结构详解

　　对于一门技术的学习，尤其是像oracle database这种知识体系极其庞杂的技术来讲，从宏观上了解其体系结构是至关重要的。同时，个人认为，未必是专业dba人员才需要了解其体系结构（固然对于专业人员来讲，这些都是必备知识了），一般的技术人员如果对其有较深入的了解，也是大有益处的，毕竟技术思想很多时候都是相通的嘛。本文就从不同维度，如oracle的内存结构，进程结构，存储结构等方面做相应描述。

目录

　　一、什么是oracle数据库？

　　二、交互流程　　

　　三、实例内存结构和进程结构

　　四、oracle存储结构

　　五、总结

首先我们来说说基础的概念吧

一、什么是oracle数据库？

　　众所周知，oracle database是一款关系型数据库管理（不了解何谓关系型数据库的童鞋自行google，baidu），同类的产品还有mysql，sqlserver等，很多时候，我们会把那个承载我们核心数据的系统笼统地成为数据库服务器，但从严格意义上来讲oracle database是由两个部分组成:　　

　　实例：实例是数据库启动时初始化的一组进程和内存结构

　　数据库：数据库则指的是用户存储数据的一些物理文件

　　正因为如此我们一般才会说 关闭和启动实例，加载卸载数据库，就是这个道理。

　　从实例和数据库的概念上来看，我们能知道，实例暂时的，它不过是一组逻辑划分的内存结构和进程结构，它会随着数据库的关闭而消失，而数据库它其实就是一堆物理文件（控制文件，数据文件，日志文件等等），它是永久存在的（除非磁盘损坏）。数据库和实例通常是一对一的，这种结构我们成为单实例体系结构；当然还有一些复杂的分布式的结构，一个数据库可以对多个实例，像oracle的rac（有兴趣的童鞋可以了解下）。

二、交互流程

　　下面是从网上找的一张图，描述了单实例体系结构大致的交互流程　　　　

　

 

　　1.用户和用户进程交互

用户进程可以是一般的客户端软件，像oracle的sqlplus，sql developer,或者是一些驱动程序等等都属于用户进程。

2.用户进程和服务器进程交互

　　服务器进程有时会称为前台进程，当然是相对于后台进程（后面会提到的数据库写入器，日志写入器等）来说的，服务器进程的主要作用就是处理连接到当前实例的用户进程的请求，对客户端发来的sql进行执行并返回执行结果。在专有服务器结构中，用户进程和服务器进程是一对一的，也就是说，当监听程序监听到客户端来了一个请求，会为其分配一个对应的服务器进程。还有一种结构为共享服务器，这种结构就不是一个用户进程对应一个服务器进程了，会通过调度程序进行协调处理，关于共享服务器连接，本文就不在赘述了。

3.服务器进程和实例进程交互

4.实例和数据库进程交互

上面描述了一些我们在进行数据库连接操作的时候，大致的交互流程是什么样的。下面，我们就来看看oracle 的实例内存结构

三、实例内存结构和进程结构

　　（由于内存结构和进程结构关系较紧密，进程会作用到对应的内存区域，比如数据库写入器作用到数据库缓冲区缓存中，日志写入器会作用到日志缓冲区，所以内存结构和进程结构会相互配合地进行描述）

　　oracle实例内存结构由两部分组成sga(系统全局区)和pga(用户全局区)组成，sga是一块共享的内存区域，也是最大的一块内存区域；pga则是用户会话专有的内存区域，每个会话在服务器端都有一块专有的内存区域就是pga。本文主要对sga进行分析描述。sga组成如下

 

　　

数据库缓冲区缓存&数据库写入器

　　缓冲区缓存 是oracle用来执行sql 的工作区域，在更新数据时，用户会话不会直接去更新磁盘上的数据，想想，如果允许这么做，那么频繁的磁盘io对于系统性能的影响是毁灭性的。所以，实际的处理流程是这样的：

1	selectename,salaryfromempwherename=’东方不败’;

　　

　　我们来看这么一条简单的查询语句，oracle是如何处理的。首先，当用户提交了该条sql语句，由对应的用户进程（比如我们常用的sql developer）将其发送给服务器，监听程序监听到该条请求，会为其建立一个对应的服务器进程，然后服务器进程会先扫描缓冲区中有没有包含关键行（”东方不败”）的数据块，如果有，这就算一次缓存命中了，然后相关行会传输到pga进行进一步处理，最终经过格式化后展示给用户；如果没有命中，那么服务器进程会首先将对应行复制到缓冲区内，然后再返回给客户端。

　　dml（insert，update，delete）操作同理，加入用户发送一条update语句，服务进程依然先去扫描缓冲区，如果缓存命中，则直接更新，数据变脏；如果没有命中，由服务器进程将对应数据块先从磁盘上复制到缓冲区内，再进行更新操作。

脏缓冲区

　　如果缓冲区存储的块和磁盘上的块不一致，该缓冲区就叫做“脏缓冲区”，脏缓冲区最终会由数据库写入器（dbwn）写入到磁盘中去。

数据库写入器（dbwn）

　　数据库写入器是oracle的一个后台进程，所谓后台进程是相对于前台进程（服务器进程）来讲的。dbwn的”n”意味着一个实例是可以有多个数据库写入器的。

　　作用：简而言之，dbwn的作用就是将变脏了的缓冲区从数据库缓冲区缓存中写入到磁盘中的数据文件中去。

　　数据库缓冲区缓存这块内存区域和数据库写入器这块是比较重要的概念，别的数据库产品像mysql也都有对应的实现，只不过叫法不一样罢了。了解这块的时候，要时刻意识到会话是不会直接更新磁盘数据的，会话的更新，插入，删除包括查询等都是先作用到缓冲区上，随后，dbwn会将其中的脏缓冲区转储到磁盘上去。　

　　dbwn什么时候写入？

dbwn是个比较懒的进程，它会尽可能少的进行写入，在以下四种情况它会执行写入：

a.没有任何可用缓冲区（不得不写啊）

b.脏缓冲区过多

c.3秒超时（最晚3秒会执行一次写入）

d.遇到检查点，即checkpoint（检查点），检查点是个oracle事件，遇到检查点，dbwn会执行写入。比如实例有序关闭的时候会有检查点，dbwn会将所有脏缓冲区写入到磁盘上去的，这很容易理解，要保持数据文件的一致性。

　　　　注意：

　　从上述dbwn的几个写入时机，我们能意识到，dbwn的写入不是直接依赖于会话的更新操作的。不是一有脏缓冲区，它就执行写入。而且，dbwn执行写入跟commit操作也没有任何关系，不要以为commit操作的影响结果会实时流入到磁盘中去。

　　dbwn采用极懒算法进行写入，原因我们应该要清楚：频繁的磁盘io对系统的压力很大，如果dbwn很积极地去写入磁盘，那对系统性能的影响就太大了，换个角度想，如果dbwn很勤快的写磁盘，那么数据库缓冲区存在的意义也就不大了。

　　当然，讲到这儿，我们可能会意识到一个问题，dbwn如此懒地进行数据转储，如果在某一时刻，数据库缓冲区缓存内存在着大量的脏缓冲区（生产环境中，这是常态），也就是有大量的未commit和已commit的数据还在内存中，没有持久化到磁盘中，然后突然系统断电了，这种情况下，数据是不是就丢掉了？数据当然不会丢失，这就引出了重做日志（redo log）的概念，接下来，我们就来谈谈对应重做日志的内存结构和后台进程。

日志缓冲区&日志写入器

　　当我们执行一些dml操作（insert,update,delete），数据块发生改变了，产生的变更向量则会写入到重做日志文件中去。有了这些记录，当系统由于断电等因素突然宕掉，数据库缓冲区缓存内的大量脏数据还没来得及写入到数据文件中去，在重新启动的时候，会有一个实例恢复的过程，在此过程中就应用了重做日志记录来使数据保持一致；或者数据库遭遇了物理损坏，比如磁盘损坏了，此时可以通过oracle的备份恢复工具（如rman）进行数据恢复，原理就是 提取备份集–>应用重做日志文件中的变更记录。

　　　　日志缓冲区

日志缓冲区是一块比较小的内存区域，它是用来短期存储将写入到磁盘中的重做日志文件中的变更向量的。

日志缓冲区存在的意义依然是为了减少磁盘io，减少用户的等待时间，试想下，如果每一次用户dml操作都要进行等待重做记录被写入到磁盘中去，体验会有多差劲。

　　　　日志写入器（lgwr）

顾名思义，日志写入器（lgwr）就是把日志缓冲区内的内容写入到磁盘的重做日志文件中去，相比数据库写入器（dbwn），日志写入器就勤快多了。

以下三种情况lgwr会执行写入：

a.commit时写入

　　前面提过，dbwn的写入和commit没有任何关系，如果commit时数据库没有任何记录，那数据就真的丢失了，oracle 的重做日志就是为了保证数据安全而存在的，commit时，会话会先挂起，等待lgwr将这些记录写入到磁盘上的重做日志文件中，才会通知用户提交完成。所以，lgwr在commit时执行写入，是为了确保事务永不丢失。

b.日志缓冲区的占用率达到1/3。

c.dbwn要写入脏缓冲区前

这个写入是为了数据回滚考虑的。dbwn完全可能写入还没提交的事务（参照上面提到的写入时机），那如何保证事务回滚呢？

　　首先要知道，dbwn除了写入实际的数据，还会写入撤销数据（不了解的同学可参考我的另一篇博文中对于撤销段的描述oracle闪回技术详解。）简单说，事务回滚需要撤销数据，在写入撤销数据前，会先写入针对撤销数据的日志记录（有点绕），若用户要进行事务回滚，就可以应用这些日志记录来构造撤销数据，然后进行回滚。

我们对这两块最重要的内存区域和对应的后台进程做个总结：

　　数据库缓冲区缓存和日志缓冲区都是为了提高性能，避免频繁io而存在的。日志缓冲区相比数据库缓冲区缓存要小的多，并且不能进行自动管理，对于日志缓冲区的修改需要重启实例，数据库缓冲区缓存可进行自动管理。作用在数据库缓冲区缓存上的dbwn进程，为了避免频繁的磁盘io导致系统性能下降，会尽可能少地执行写入，且dbwn的写入和commit操作没有任何关系；

　　而作用在日志缓冲区上的lgwr进程，则会非常积极地进行写入，一般情况下，它几乎是实时地将重做日志记录转储到磁盘中去。lgwr是oracle体系结构中最大的瓶颈之一。dml的速度不可能超过lgwr将变更向量写入磁盘的速度。

　　我们在来看下其他的内存区域和后台进程

共享池

共享池是最复杂的sga结构，它有许多子结构，我们来看看常见的几个共享池：

　　1.库缓存：库缓存这块内存区域会按已分析的格式缓存最近执行的代码，这样，同样的sql代码多次执行的时候，就不用重复地去进行代码分析，可以很大程度上提高系统性能。

　　2.数据字典缓存：存储oracle中的对象定义（表，视图，同义词，索引等数据库对象），这样在分析sql代码的时候，就不用频繁去磁盘上读取数据字典中的数据了

　　3.pl/sql区：缓存存储过程、函数、触发器等数据库对象，这些对象都存储在数据字典中，通过将其缓存到内存中，可以在重复调用的时候提高性能。

大池：大池是个可选的内存区域，前面我们提到专有服务器连接和共享服务器连接，如果数据库采用了共享服务器连接模式，则要使用到大池；rman(oracle的高级备份恢复工具)备份数据也需要大池。

java池

　　oracle 的很多选项使用java写的，java池用作实例化java对象所需的堆空间

流池

　　从重做日志中提取变更记录的进程 和 应用变更记录的进程会用到流池（如实例不正常关闭，譬如断电导致实例关闭，在重启时，oracle会自动执行实例恢复过程，在此过程需要提取重做日志记录和应用重做日志两个动作）

以上列举了oracle常见的内存结构，要注意的是，上面列举的内存区域，除了日志缓冲区是固定的，不能动态调整也不能进行自动管理外，其他内存区域都可以进行动态调整，也可以进行自动管理。

 

在说说oracle 的几个后台进程（dbwn和lgwr较重要，前面已做了了解，在此不再赘述）

smon(system monitor):安装和打开数据库，实例恢复也是由此进程完成的

pmon(process monitor):进程监视器，主要监视服务器进程。前面提到过，专有服务器体系模式下，用户进程和服务器进程是一对一的关系，如果某个会话发生异常，pmon会销毁对应的服务器进程，回滚未提交的事务，并回收会话专有的pga内存区域。

ckpt(checkpoint process):ckpt负责发起检查点信号，手动设置检查点的语法:

1	sql>altersystemcheckpoint;

　　检查点可强制dbwn写入脏缓冲区，当数据库崩溃后，由于大量脏缓冲区未写入数据文件，在重新启动时，需要由smon进行实例恢复，实例恢复需要提取和应用重做日志记录，提取的位置就是从上次检查点发起的位置开始的（检查点之前的数据已经被强制写入到数据文件中去了），这个位置称为rba(redo byte address)，ckpt会不断将这个位置更新到控制文件中去（以确定实例恢复需要从哪儿开始提取日志记录）。

mmon(manageability monitor)

　　数据库的自我监视和自我调整的支持进程。实例在运行中，会收集大量有关实例活动和性能的统计数据，这些数据会收集到sga中，mmon定期从sga中捕获这些统计数据，并将其写入到数据字典中，便于后续对这些快照进行分析。（默认情况，mmon每隔一个小时收集一次快照）

arcn（archiver）

　　归档进程，这个进程是可选的，如果数据库配置为归档模式，这个进程就是必须的。所谓归档，就是将重做日志文件永久保存（生产库一般都会配置为归档模式）到归档日志文件中。归档日志文件和重做日志文件作用是一样的，只不过重做日志文件会不短被重写，而归档日志文件则保留了关于数据更改的完整的历史记录。

 

至此，oracle基础的内存结构和进程结构我们已大概了解，来看下完成的进程和内存的交互情况，可以根据前面的理解将整个交互流程串联一下。

四、oracle存储结构

　　针对oracle存储结构将分别从物理存储结构和逻辑存储结构两个维度来进行阐述。

物理存储结构

 

　　　　

　　

所谓外部文件，意味着这些文件从严格意义上来讲并不属于oracle数据库的一部分。

控制文件：

　　控制文件虽小，但作用重大，它包含指向数据库其余部分的指针（包括重做日志文件，数据文件，归档日志文件等的位置），存储重要的序列号和时间戳，存储rman备份的详细信息。控制文件一旦受损，那实例会立马终止，一般对数据文件的保护采用多路复用机制，就是冗余多份在不同物理位置。

重做日志文件

　　重做日志文件的作用在讲解内存和进程结构的时候有提到过，重做日志按时间顺序存储应用于数据库的一连串的变更向量（包含联机重做日志文件和归档日志文件）。由smon在数据库启动时自动执行的实例恢复 和 磁盘损坏所要求的提取备份恢复都会应用到重做日志进行相应的数据恢复

　　重做日志文件也建议进行多路复用，一个数据库至少要有两组重做日志文件。一组供lgwr进行写入，日志文件是固定大小，业务高峰期会很快写满，写满之后会切换到第二组上，在配置为归档模式的数据库中，这时由归档进程（arcn）开始将第一组的内容进行归档备份，如此循环地进行写入和归档。需要注意的是，在归档进程还未对当前组的日志归档完毕前，是不允许lgwr对其进行重写的。

数据文件

　　数据文件存储着实际的数据，dbwn会将数据库缓冲区中的内容写入到这类文件中去，数据文件的大小和数量是不受限制的。oracle从10g开始，创建一个数据库至少需要两个数据文件，一个用于system表空间，该表空间用来存储数据字典；一个用于sysaux表空间，这个表空间用来存储一些数据字典的辅助数据。

　　数据文件由一个个的oracle块组成，这是oracle的i/o基础单元，与操作系统块是不同的概念，oracle块要比操作系统块大，这当然有处于性能的一些考虑，但我们考虑这样一种情况，当用户使用操作系统命令进行数据文件的备份的时候（假设1个oracle块=8个操作系统块），已经复制了4个操作系统块，然后cpu被dbwn抢占了，dbwn又重新对这个oracle块进行了更新，这时，当复制命令又得到了cpu时间去复制剩余的4个块的时候，就造成了整个oracle块的数据不一致，所以，这也是在执行这种备份（用户自行备份）的时候，需要做一些额外处理，比如将表空间置为备份模式的原因。当然，使用rman是不存在这样的问题的，rman的备份机制是肯定可以得到数据一致的块的。（这块内容作了解即可）

　　对于数据文件的保护，一般可进行定期备份，或者使用raid也可以。

实例参数文件

　　这个文件存储了数据库所需的一些参数设置，比如各个内存区域的大小，可允许的最大进程数，最大会话数，控制文件的位置，数据库的名称等等，参数文件也是实例启动时首先要加载的文件。

口令文件

　　一般称为外部口令文件。一般的用户名和口令是存放在数据字典中，不会存放在这个文件中。在一些特殊场景下，比如实例还未启动，这时，我可能需要以管理员的身份登入系统去执行一些恢复或者启动操作，然而此时，数据字典由于实例还没启动是不存在的，这时就需要外部口令文件进行用户身份的验证。

归档日志文件

　　arcn将联机重做日志文件会备份归档到这类文件中去，归档日志文件保留了数据更改的完整历史信息。

逻辑存储结构

　　oracle将其物理结构从逻辑存储结构中抽象出来，物理机构是系统管理员能看到的，逻辑结构则是用户所能感知到的。比较典型的逻辑结构就是 “段”和”表空间”。

　　段：

　　段就是包含所有数据的逻辑结构，比较典型的段就是”表”，称为表段，还有索引段，撤销段等等。

　　表空间

　　　　表空间从逻辑上是多个段的结合，在物理上是多个数据文件的集合，相当于在段和数据文件的对应中加入了一个中间层来解决这种多对多的关系。

　　在早期的一些中，段和数据文件是一对一的关系，一个段一个数据文件，这种设计有很多弊端，首先，段的数量是不固定的，有可能一个系统中上千张表，那就得需要上千个数据文件，系统管理员要管理这么多文件肯定会抓狂的；还有一种情况就是某些历史表可能特别大，大到底层系统对单个文件的限制，用一个数据文件去承载的话肯定是不行的。表空间则完美解决了这样的问题。

　　还有一些逻辑结构如区间和oracle块（oracle块前面有提到过，区间则为块的集合），下面通过一张图对oracle的存储结构进行整体的宏观的认识，进一步加深些理解

　　　

五、总结

　　本文博主对oracle的体系结构做了相对全面的介绍，包括内存结构，进程结构，存储结构等等，相信大家对其全貌也有了基本的了解。由于本人觉得对于体系结构的学习一览全貌即可，未必要深入到每一个点，故对某些概念没有做特别深入的解读，还有一些如实例恢复的过程，数据库启动的各个阶段，动态参数和静态参数等等也未提及，后续有时间会追加上的。谢谢捧场。