Oracle 数据库架构

1. 控制文件、数据文件、SGA 和 PGA

当 Oracle 数据库运行时，操作系统上有一部分内存空间被分配给Oracle， 我们称为共享全局区 (SGA) 。同时，Oracle也启动了一些后台进程，以满足数据库的需求。Oracle 实例由 SGA + 后台进程组成。下图精美地展示了 Oracle 数据库架构。我将通过这张图片解释所有的概念。

Control File: 控制文件是一个扩展名为 .ctl 的文件，它物理存储在操作系统上，这是 Oracle 数据库所必需的。该文件还充当我们 Oracle 数据库的大脑。当 Oracle 数据库启动时，它会读取名为 SPFILE 或 PFILE 的参数文件并了解控制文件的位置。因为Control文件是我们数据库的大脑，数据库需要找到这个文件才能工作。如果找不到控制文件，Oracle 数据库将不会启动并会报错。这就是为什么控制文件以 2 个副本存储在生产数据库中的原因。Oracle 的推荐配置是我们在不同的磁盘上存储 3 个副本。我们说过控制文件很重要。那么为什么重要，控制文件中有哪些信息。

• 数据库名称存储在此文件中。打开数据库时，它会在读取此文件后了解数据库的名称。
• 它包含物理存储数据的数据文件文件的位置。
• 它包含联机重做日志文件（事务存储在此文件中）和归档日志文件（重做日志文件的归档）的物理位置。
• 它包含 RMAN 备份信息。因此，如果您在不备份控制文件的情况下进行完整备份，则此备份将无效。它无法恢复。因此，在进行备份时，还必须备份控制文件。
• 数据库操作期间使用的 SCN（系统更改号）编号的当前版本也存储在控制文件中。SCN 是提交事务后生成的数字。SCN 是按顺序递增的唯一值。
  它包含检查点信息。我将解释更多关于 Checkpoint 的信息。
• 数据库创建日期也存储在此文件中。
• 它包含存储事务的日志文件的序列号。

从我提到的项目中可以看出，Control文件对于我们的Oracle数据库来说是必不可少的。这就是为什么 Oracle DBA 必须知道，当他/她进行备份时，也必须备份控制文件。如果我们如下配置 RMAN，控制文件的自动备份将处于活动状态。

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

我们可以查询控制文件在哪里，如下：

bash-4.1$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Thu Oct 3 11:47:59 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> show parameter control_file;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_files                        string      /oracle/data/TESTDB/control01.ctl, /oracle/data/TESTDB/control02.ctl
SQL>

Data Files: 这些是扩展名为 dbf 的物理文件，由 Oracle 数据库存储在操作系统上。您可以在操作系统上看到这些文件为 * .dbf。首次创建 Oracle 数据库时，默认创建 System、sysaux、undo、user 和 temp 数据文件。当用户发起事务时，Oracle 首先尝试在数据库缓冲区高速缓存中查找搜索到的数据。如果它找不到它，它将被定向到数据文件以查找此数据。我们可以使用以下查询查看属于数据库的所有数据文件。

bash-4.1$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Thu Oct 3 13:26:26 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> set lines 800
SQL> select FILE_NAME,FILE_ID,TABLESPACE_NAME,BYTES,BLOCKS,MAXBYTES,ONLINE_STATUS from dba_data_files;

FILE_NAME     FILE_ID TABLESPACE_NAME                     BYTES     BLOCKS   MAXBYTES ONLINE_
------------------------------------------------------------------------------------------------------------------
/oracle/data/TESTDB/system01.dbf   1 SYSTEM                          734003200      89600 3.4360E+10 SYSTEM
/oracle/data/TESTDB/sysaux01.dbf   2 SYSAUX                          744488960      90880 3.4360E+10 ONLINE
/oracle/data/TESTDB/undotbs01.dbf   3 UNDOTBS1                        519045120      63360 3.4360E+10 ONLINE
/oracle/data/TESTDB/users01.dbf    4 USERS                             5242880        640 3.4360E+10 ONLINE
/oracle/data/TESTDB/fda01.dbf   5 FDA                            1073741824     131072          0 ONLINE

SQL>

SGA: Oracle 实例启动时，Oracle 从操作系统分配最多达到安装阶段指定的 SGA 值的内存区域。该内存区域称为系统全局区域。该内存空间从物理服务器的 RAM 中分配，直到 Oracle 实例关闭。当实例关闭时，此内存空间将返回给操作系统。

我们在创建Oracle 数据库时就确定了SGA 值，该值的正确和优化配置将直接影响oracle 的性能。我们可以查看为 Oracle 数据库保留的 SGA 值，如下所示。

bash-4.1$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Thu Oct 3 15:31:32 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> show parameter sga

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 512M
sga_target                           big integer 512M
SQL>

PGA (Program Global Area): 这是在服务器上的 Oracle 实例上启动进程时从服务器物理内存分配的内存空间。该内存空间一直使用到与 Oracle 相关的进程终止。当进程完成时，这个内存空间被释放。您可以在数据库中查询该内存空间的指定值，如下所示。

bash-4.1$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Fri Oct 4 14:56:59 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> show parameter pga

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 2635M
SQL>

Shared Pool: 共享池是绝大多数数据库操作中使用的重要内存区域。因为所有事务的查询、它们的执行计划（工作计划）、解析和编译的PL/SQL代码总是存储在这个内存区域中。共享池区由以下组件组成。

Library Cache: 这是共享池中最重要的区域之一。 因为当一个 SQL 子句进入 Oracle 数据库时，Oracle 首先通过查看库缓存来检查它是否已经被执行。 如果查询之前已经执行过，Oracle 会使用之前的执行计划而不解析这条 SQL。这个过程称为软解析。 如果查询之前没有执行过，oracle 会解析执行的 SQL 并将其保存到库缓存中的 Shared SQL Area 中。 这个过程称为硬解析。

DBA 最重要的任务之一是识别和修复数据库中不必要的硬解析操作。

不必要的硬解析操作的最重要原因之一是：相同的 SQL 语句存在大小写差异：

1 nolu sorgu: select * from hr.personel;
2 nolu sorgu: select * from hr.Personel;

另一种用作解决方案的方法是对相同的查询类型使用绑定变量：

SQL> select name,surname,phone from hr.personel where id=1;

在上面的查询中，请求的是 id 值为 1 的个人信息。想象一下，这个查询总是用不同的 id 值请求。即使查询相同，Oracle 也会在库缓存中重复解析此查询。因此，不是进行软解析，消耗比 Cpu 源更少的资源，而是进行硬解析并消耗不必要的 CPU 资源。此时，我们为 id 列分配“绑定变量”值，以确保查询对每个不同的传入 id 值使用相同的执行计划。上述查询与绑定变量的使用如下。

SQL> variable person_id number
SQL> exec :person_id : =180251;
SQL> select name,surname,phone from hr.personel where id :=person_id;

如果我们使用 Bind 变量，即使查询中的 id 值发生变化，Oracle 也会使用相同的执行计划。

Dictionary Cache: 这个内存空间存储我们数据库的元数据。
即以下信息存储在字典缓存中：

• 谁有权访问表
• 表空间信息
• 表的列信息

解析查询时经常使用此内存空间。

2. Buffer Cache、Redolog Buffer、Onlinelog 和Archivelog

Database Buffer Cache: 由用户或应用程序启动的事务数据存储在此内存空间中。

例如： 当对表执行插入、更新或删除操作时，相应的更改不会直接写入数据文件。它在缓冲区缓存中存储一​​段时间（这种数据称为脏数据）。

数据库中最常用、最新的数据都存储在这里，这个内存空间是所有用户共有的。存储在 Buffer 缓存中的数据会在一段时间后写入数据文件。

您可以使用以下查询刷新缓冲区缓存中的数据：

alter system flush buffer_cache;

但是，除非需要，否则不应在生产系统中执行上述命令。因为当缓冲区缓存被清空时，所有的查询或事务都会从物理磁盘进行 I/O，这意味着我们的查询会变慢。

Redo Log Buffer: Oracle 数据库存储每个事务的记录。当用户或应用程序启动事务时，事务最初会写入重做日志缓冲区。LGWR 进程会定期将重做日志缓冲区中的记录写入在线重做日志文件。当实例崩溃时，需要存储事务记录以进行恢复。

Online Redo log Files: 这些文件是操作系统上存储数据库中所有事务的物理文件。这些文件存储了数据库中的所有更改，而正如我上面提到的，Redo Log Buffer 中累积的记录会定期记录在这里。如果数据库处于存档模式，则这些文件将作为切换操作的结果定期存档。

数据库必须处于存档模式才能在联机模式下进行备份。如果数据库损坏，从备份返回时还需要存档文件。

如果不应用存档日志，您将无法始终如一地打开数据库。一旦应用了相应的归档日志，就可以应用在线重做日志来恢复数据，直到最后一次。

在存储重做日志文件的数据库上有逻辑重做日志组，每个组有 2 个相同的文件。这是冗余和一致性所必需的。当文件损坏时，数据库使用重做日志组的其他成员继续工作。您还可以为重做日志组创建 2 个以上的成员。重做日志缓冲区中的信息同时写入重做日志组的所有成员。如果任何联机重做日志组已满，则新日志将写入另一个组。此过程称为日志切换。

您可以使用以下查询查看数据库上的联机重做日志：

bash-4.1$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Thu Oct 3 16:54:27 2013
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> set lines 600
SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ ---------
         1          1      18622   52428800        512          1 YES ACTIVE                12514027 03-JAN-13     12514404 03-OCT-13
         2          1      18623   52428800        512          1 NO  CURRENT               12514404 03- JAN -13   2.8147E+14
         3          1      18621   52428800        512          1 YES INACTIVE              12513648 03- JAN -13     12514027 03-OCT-13

Archivelog: 如果您有一个以归档日志模式运行的 Oracle 数据库，则在日志切换后重做日志文件将被复制到归档日志文件中。
存档文件是一致恢复实例所需的文件。此外，您可以使用存档日志文件将数据库恢复到特定时间。

您可以使用以下查询检查存档日志文件：

bash-4.1$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Thu Oct 3 17:12:20 2013
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> set lines 900
SQL> select NAME,DEST_ID,THREAD#,SEQUENCE#,CREATOR,APPLIED from v$archived_log where rownum<3;

NAME     DEST_ID    THREAD#  SEQUENCE# CREATOR APPLIED
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------- ---------- ---------- ------- ---------
/oracle/ARCH/1_15266_821030721.arc   1          1      15266 ARCH    NO
/oracle/ARCH/1_15267_821030721.arc   1          1      15267 ARCH    NO

SQL>

3. SMON、PMON、DBWR、CKPT 和 LGWR 进程

SMON（System Monitor）： 负责恢复Oracle Instance的重要进程。如果此进程不起作用，则数据库已关闭。

此进程确保实例打开一致，在数据库打开期间使用联机重做日志文件，当 Oracle 数据库不一致关闭时。此进程还允许恢复突然终止的事务。

我们可以通过操作系统看到这个进程，如下所示。

bash-4.1$ ps -ef | grep smon
oracle    9055     1  0 13:38 ?        00:00:00 ora_smon_TESTDB
oracle    9250  8803  0 14:24 pts/0    00:00:00 grep smon
bash-4.1$

当我们通过操作系统杀死这个进程时，数据库会突然关闭，如下所示。

bash-4.1$ ps -ef | grep smon
oracle    9055     1  0 13:38 ?        00:00:00 ora_smon_TESTDB
oracle    9258  8803  0 14:28 pts/0    00:00:00 grep smon
bash-4.1$ kill -9 9055
bash-4.1$ ps -ef | grep smon
oracle    9260  8803  0 14:29 pts/0    00:00:00 grep smon
bash-4.1$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Fri Oct 4 14:29:08 2013
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Connected to an idle instance.
SQL>

PMON (Process Monitor): 此进程释放已失败或突然终止的进程所使用的系统资源，并将这些资源还给服务器。

它还允许 Oracle 实例与侦听器通信。

我们可以在操作系统上看到这个进程如下。

bash-4.1$ ps -ef | grep pmon
oracle    9423     1  0 14:37 ?        00:00:00 ora_pmon_TESTDB
oracle    9559  8803  0 14:37 pts/0    00:00:00 grep pmon
bash-4.1$

RECO (Recoverer Process): 这个过程可以完成未完成的操作。

DBWn（Database Writer）： DBW进程是一个在Datafiles和Database Buffer Cache之间穿梭的进程。也就是说，当一个事务开始时，如果相应的块不在缓冲区缓存中，DBW 会将这些块从数据文件移动到缓冲区缓存中。同理，将应该写入Datafiles的脏块从Buffer缓存写入Datafiles。

bash-4.1$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Fri Oct 4 13:39:44 2013
Copyright (c) 1982, 2011, Oracle.  All rights reserved. 
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> show parameter db_writer_process

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_writer_processes                  integer     1
SQL>

当发生以下事件时，这些进程开始工作，并将缓冲区缓存中的更改块写入数据文件。

• 当数据库缓冲区缓存中的内存空间已满时，这些块将从该内存区域中最旧的块开始写入数据文件。
• 如果触发检查点进程。
• 当表空间设置为只读模式时。
• 当表空间脱机时。
• 当任何表被删除或截断时。

以下代码可用于将缓冲区缓存中的数据手动写入数据文件。

SQL> Alter system checkpoint;

LGWR (Log Writer Process): 该进程是将缓冲存储器中的数据写入物理文件的进程，类似于DBW进程。此过程在重做日志缓冲区和联机重做日志文件之间运行。将重做日志缓冲区中的事务信息分别写入在线重做日志文件。当以下情况发生时，LGWR 进程将重做日志缓冲区中的数据写入在线重做日志文件。

• 当发生提交操作时
• 当发生日志切换时
• 每 3 秒
• 平均，当重做日志大小为 1 mb 时。
• 当1/3的Redo log缓冲区已满时

CKPT (Checkpoint Process): 当这个进程被触发时，数据库写入器（DBW）进程将数据库缓冲区缓存中的脏块写入数据文件。它还更新数据文件的头信息。

如果此过程以非常频繁的时间间隔触发，则数据库会变慢，因为磁盘 I/O 会增加。

如果很少触发，当Oracle数据库实例突然崩溃时，需要一些时间来恢复实例。因为更改块不会写入数据文件，并且更改块的数量是累积的。因此，在恢复过程中，在线重做日志写入数据文件的块数会更多。

由于上述原因，确定触发此过程的频率很重要

ARCn ( archiver process ): 这是一个在数据库处于归档模式时被激活的进程。当联机重做日志组已满时，此过程会在日志切换操作期间将重做日志文件的副本复制到存档文件中。此过程的另一个任务是在灾难恢复场景中将重做日志文件发送到“灾难/备用”服务器。