Oracle物理体系总结

Oracle物理体系结构图：/article/10934195.html

一、概述

1.Oracle由实例和数据库组成

2.实例是由共享内存区SGA(System Global Area)和一系列后台进程组成，其中SGA最主要被划分为共享池(shared
pool) 、数据缓冲区(db cache)和日志缓冲区(log buffer)三类。后台进程包括PMON、SMON、LCKn、RECO、CKPT、DBWR、LGWR、ARCH等进程。

3.数据库是由数据文件、参数文件、日志文件、控制文件、归档文件等系列文件组成，其中归档文件可能被转移到新的存储介质中，用于备份恢复使用。

4.PGA(Program Global Area)区，也是一块开辟出来的内存区，和SGA的最明显差别是，PGA不是共享内存，是私有不共享的。用户对数据库发起的无论查询还是更新的任何操作，都是在PGA进行预处理，然后接下来才进入实例区域，由SGA和系列后台进程共同完成用户发起的请求。

PGA的预处理主要有三点：

保存用户的连接信息，如会话属性、绑定的变量等。
保存用户权限等重要信息，当用户进程与数据库建立会话时，系统会将这个用户的相关权限查询出来，然后保存在这个会话区域内。
当发起的指令需要排序时，如果PGA这个排序区，可以在内存中放下排序的尺寸，则在PGA内存中完成，如果放不下，超出的部分就在临时表空间中完成排序，也就是在磁盘中完成排序。

5.用户发起请求经历的顺序一般是PGA→SGA→DATABASE，或者PGA→SGA

二、Select 查询原理

用户执行执行一条简单的查询语句select objectid_name from t where object_id=29;，当发出一条SQL指令后，该SQL语句先从PGA进行准备工作，该SQL会立即匹配成一条唯一的HASH值

接下来该SQL指令进入SGA区进行处理，首先会敲开SGA区共享池的大门，该SQL会在共享池这个房间内查询是否有什么地方有存储过这个SQL指令的身份证(即唯一的HASH值)，如果没有，那就要辛苦了，首先查询自己的语句语法是否正确(比如from是否写成了form)、语义是否正确(比如id字段根本不存在)、是否有权限，在这些都没问题的情况下生成这条语句的身份证，这个SQL的唯一HASH值就被存储下来。接下来开始进行解析，确定使用代价低的执行计划。接下来这个执行计划立即被存储起来，并且和之前存储的该SQL的身份证(HASH值)对应在一起。

接下来，该SQL的指令好比钦差大臣一样，手持"执行计划和要读的数据"这个圣旨，继续往前走，直奔“数据缓冲区”府内宣读圣旨

数据缓冲区开门迎接跪谢天恩后，立即根据执行计划去t表中查找object_id值为29的宝物，但是所要的东西府内找不到，怎么办？数据缓冲区府只好传令下去，八百里加急赶去偏远的Database军营的数据文件区查找皇上要的东西。如果查到了，就带回数据缓冲区府，并由钦差大臣展现给皇上(前台用户)，如果找不到，也只有就此复命。

接下来做一个查询

--执行一条select语句
SQL> select object_name from t where object_id=29;

Elapsed: 00:00:00.03

Statistics
----------------------------------------------------------
4  recursive calls
0  db block gets
1306  consistent gets
1239  physical reads
0  redo size
532  bytes sent via SQL*Net to client
520  bytes received via SQL*Net from client
2  SQL*Net roundtrips to/from client
0  sorts (memory)
0  sorts (disk)
1  rows processed

--再次执行该语句
SQL> select object_name from t where object_id=29;

Elapsed: 00:00:00.01

Statistics
----------------------------------------------------------
0  recursive calls
0  db block gets
1243  consistent gets
0  physical reads
0  redo size
532  bytes sent via SQL*Net to client
520  bytes received via SQL*Net from client
2  SQL*Net roundtrips to/from client
0  sorts (memory)
0  sorts (disk)
1  rows processed

对比发现，2次虽然执行同一条语句，但是执行时间，递归调用等都有一定程度的不一样。

1.用户首次执行该SQL该指令，该指令从磁盘中获取用户连接信息和相关权限信息权限，并保存在PGA里。当用户再次执行该命令时，由于Session之前未被断开重连，连接信息和相关权限信息就可以在PGA内存中直接获取，避免了物理读。

2.首次执行该SQL指令结束后，SGA内存区的共享池里保存了该SQL唯一指令HASH值，并保留了语法语意及执行计划等相关解析动作的劳动成果，当再次执行该SQL时，由于该SQL指令的HASH值和共享池里保存的相匹配，所以之前的硬解析动作也就无需再做，不仅跳过了相关语法语意检查，对于该选择哪种执行计划也无需考虑，直接拿来主义就好

3.首次执行该SQL命令时，数据一般不在SGA的数据缓存区里(除非被别的SQL读入内存)，只能从磁盘中获取，不可避免的产生了物理读，但是由于获取后会保存在数据缓冲区里，再次执行就直接从数据缓冲区里获取了，完全避免了物理读。

三、Update原理

sql语句：update t set object_id=92 where object_id=29;

1.如果该用户并没有退出原链接去新建立一个连接，PGA区的用户连接信息和权限判断等诸多动作依然不用做，否则需要完成用户连接信息和权限判断等诸多动作。

2.如果该语句是第一次执行，在共享池里依然需要完成语法语意分析及解析，update t set object_id=92 where object_id=29指令中想匹配到object_id=29的记录既可以用索引读，也可以用全表扫描，到底选用哪种执行计划需要根据代价的大小来判断

3.接下来进入数据缓冲区，首次执行该数据不一定在缓冲区内，要先从磁盘中获取到缓冲区中。

以上三点和之前的select objectid_name from t where object_id=29描述几乎没有任何本质区别，差异在于查询语句做完这三步后，返回数据结果给用户，就收工回家休息了。而更新语句的工作还要继续。

4.在数据缓冲区内将object_id=29的记录修改成object_id=92，修改完数据后，会启用DBWR进程，完成更新的数据从数据内存中刷入到磁盘，将磁盘中的

object_id=29的值更新成92。因为磁盘才是真正存储数据的地方，否则一断电，数据在内存中就灰飞烟灭了。

四、日志缓冲区(log buffer)

日志缓冲区保存了数据库相关操作的日志，记录了这个动作，然后由LGWR后台进程将其从日志缓冲区这个内存区写进磁盘的日志文件中，目的是为了便于将来出现异常情况时，可以根据日志文件中记录的动作，再继续执行一遍，从而保证数据的安全。LGWR是连接日志缓冲区和日志文件的辛勤工作者。

当对Update语句进行Commit操作后，数据并不会立即输入到磁盘中的，而是进行批量刷出的。Oracle中一旦发生Commit时，日志缓冲区会把操作的动作(并非结果)写入到磁盘的日志文件中，这样Oracle就不一定非要将数据从数据缓冲区写入到磁盘中了。磁盘的日志文件不是内存中的日志缓冲区，是永久保存不怕断电的，断电以后会依据磁盘的日志文件重新操作一次，把刚才的数据缓冲区丢失的数据恢复。因此数据缓冲区批量刷出的效率和安全是可以保证的。

数据库在运行过程中，批量刷出的数据占数据缓冲区的比例越大，效率一般来说是越高，而且不用担心断电后的恢复问题。但是这样数据库断电重启后的恢复数据动作必须需要更长，因此存在一个平衡的问题：批量刷出的量越小，Oracle性能就会降低，但是断电后开机恢复的时间就更短，反之批量刷出的量越大，Oracle性能就更高，但是断电后恢复的时间就越长，因此引入一个后台进程的新成员：CKPT

五、检查点(CKPT)

数据缓冲区数据写到磁盘的动作正是由进程CKPT来出发的，CKPT触发DBWR写出。这是一个相当重要的进程，我们可以通过设置参数来调整控制CKPT的出发时间，

硬解析(hard prase)和软解析([b]soft prase)[/b]：

在执行和获取结果前，数据库系统对此sql将进行几个步骤的处理过程：

1、语法检查(syntax check)

检查此sql的拼写是否语法。

2、语义检查(semantic check)

诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。

3、对sql语句进行解析(prase)

利用内部算法对sql进行解析，生成解析树(parse tree)及执行计划(execution
plan)。

4、执行sql，返回结果(execute and return)

其中，软、硬解析就发生在第三个过程里。

　　数据库利用内部的hash算法来取得该sql的hash值，然后在library
cache里查找是否存在该hash值。假设存在，则将此sql与cache中的进行比较。假设“相同”，就将利用已有的解析树与执行计划，而省略了优化器的相关工作。这也就是软解析的过程。

　　诚然，如果上面的2个假设中任有一个不成立，那么优化器都将进行创建解析树、生成执行计划的动作。这个过程就叫硬解析