第十一章 Physical Storage Structures（物理内存结构）
本章描述了Oracle数据库的主要物理数据库结构。物理结构在操作系统级是可见的。
本章包括以下章节:
- Introduction to Physical Storage Structures
- Overview of Data Files
- Overview of Control Files
- Overview of the Online Redo Log
11.1 Introduction to Physical Storage Structures（物理存储结构介绍）
RDBMS的一个特性是逻辑数据结构(如表、视图和索引)与物理存储结构的独立性。因为物理结构和逻辑结构是分开的，所以可以在不影响对逻辑结构访问的情况下管理数据的物理存储。例如，重命名数据库文件不会重命名存储在其中的表。
Oracle数据库是一组将Oracle数据存储在持久磁盘存储中的文件。本节讨论在发出CREATE database语句时生成的数据库文件:
- Data files and temp files（数据文件和临时文件）
数据文件是由Oracle数据库创建的磁盘上的物理文件，包含表和索引等数据结构。临时文件是属于临时表空间的数据文件。数据以Oracle专有格式写入这些文件，其他程序无法读取。 - Control files（控制文件）
控制文件是跟踪数据库物理组件的根文件。 - Online redo log files（在线重做日志文件）
联机重做日志是一组文件，其中包含对数据所做更改的记录。
数据库实例是一组管理数据库文件的内存结构。
图11-1显示了实例和它管理的文件之间的关系。
11.1.1 Mechanisms for Storing Database Files（存储数据库文件的机制）
有几种机制可用来分配和管理这些文件的存储。最常见的机制包括:
- Oracle Automatic Storage Management (Oracle ASM)（Oracle自动存储管理）
ASM包含一个专门为Oracle数据库使用而设计的文件系统。 - Operating system file system（操作系统 文件系统）
大多数Oracle数据库将文件存储在文件系统中，文件系统是构建在连续磁盘地址空间中的数据结构。所有操作系统都有文件管理器，用于将磁盘空间分配到文件系统中的文件中。
文件系统允许将磁盘空间分配给多个文件。每个文件都有一个名称，并作为连续地址空间出现在Oracle数据库等应用程序中。数据库可以创建、读取、写入、调整大小和删除文件。
文件系统通常构建在逻辑卷之上，逻辑卷由一个称为逻辑卷管理器(LVM)的软件包构造。LVM允许将多个物理磁盘片段组合成一个连续的地址空间，该地址空间作为一个磁盘出现在更高层次的软件中。 - Raw device（原始设备）
原始设备是没有使用文件系统格式化的磁盘分区或逻辑卷。原始设备的主要好处是能够执行直接I/O和编写更大的缓冲区。在直接I/O中，应用程序直接读写存储设备，绕过操作系统缓冲区缓存。
注意:许多文件系统现在支持数据库和其他管理自己缓存的应用程序的直接I/O。从历史上看，原始设备是实现直接I/O的唯一方法。 - Cluster file system（集群文件系统）
集群文件系统是一种软件，它允许多台计算机共享文件存储，同时保持一致的空间分配和文件内容。在Oracle RAC环境中，集群文件系统使共享存储作为集群环境中许多计算机共享的文件系统出现。对于集群文件系统，集群中计算机的故障不会使文件系统不可用。但是，在操作系统文件系统中，如果计算机通过NFS或其他方式共享文件失败，则文件系统不可用。
数据库使用上述存储机制的组合。例如，数据库可以在传统的文件系统中存储控制文件和在线重做日志文件、原始分区上的一些用户数据文件、Oracle ASM中剩余的数据文件，并将重做日志文件归档到集群文件系统。
11.1.2 Oracle Automatic Storage Management (Oracle ASM)（Oracle自动存储管理）
ASM是针对Oracle数据库文件的高性能、易于管理的存储解决方案。ASM是一个卷管理器，提供了一个专门为数据库使用而设计的文件系统。
相对于传统的文件系统和存储管理器，ASM提供了以下几个优势:
- 简化与存储相关的任务，例如创建和布局数据库以及管理磁盘空间
- 跨物理磁盘分发数据，以消除热点，并提供跨磁盘的统一性能
- 存储配置更改后自动重新平衡数据
要使用Oracle ASM，需要为Oracle数据库分配分区磁盘，并设置条带和镜像的首选项。ASM管理磁盘空间，在所有可用资源之间分配I/O负载，以优化性能，同时不需要手动I/O调优。例如，您可以增加数据库的磁盘大小，或者将数据库的部分移动到新设备，而不必关闭数据库。
Oracle ASM Storage Components（ASM存储组件）
Oracle数据库可以将数据文件作为Oracle ASM文件存储在Oracle ASM磁盘组中，该磁盘组是由Oracle ASM作为一个单元管理的磁盘集合。在磁盘组中，Oracle ASM为数据库文件公开了一个文件系统接口。
图11-2显示了使用Oracle ASM的数据库中存储组件之间的关系。该图描述了Oracle ASM文件和数据文件之间的关系，尽管Oracle ASM可以存储其他类型的文件。鱼尾纹符号表示一对多关系。
图11-2说明了Oracle ASM的以下概念:
- Oracle ASM Disks（Oracle ASM磁盘）
ASM磁盘是分配给Oracle ASM磁盘组的存储设备。ASM磁盘可以是物理磁盘或分区、存储数组中的逻辑单元号(LUN)、逻辑卷或网络附加文件。
可以在数据库运行时从磁盘组添加或删除Oracle ASM磁盘。当您将磁盘添加到磁盘组时，您可以指定磁盘名称，也可以自动为磁盘指定Oracle ASM磁盘名称。 - Oracle ASM Disk Groups（ASM磁盘组）
ASM磁盘组是作为逻辑单元管理的一组ASM磁盘。磁盘组中的数据结构是自包含的，并且消耗磁盘组中的一些磁盘空间。
在磁盘组中，Oracle ASM为Oracle数据库文件公开一个文件系统接口。存储在磁盘组中的文件的内容是均匀分布的，或条带化的，以消除热点，并在磁盘之间提供统一的性能。性能与原始设备的性能相当。 - Oracle ASM文件
ASM文件是存储在Oracle ASM磁盘组中的文件。Oracle数据库通过文件与ASM通信。该数据库可以存储数据文件、控制文件、在线重做日志文件和其他类型的文件作为Oracle ASM文件。当数据库请求时，Oracle ASM创建一个Oracle ASM文件，并为它分配一个完全限定的名称，以加号(+)开头，后面跟一个磁盘组名称，像+DISK1。
注意:ASM文件可以与其他存储管理选项共存，比如原始磁盘和第三方文件系统。该功能简化了将ASM集成到现有环境的过程。 - Oracle ASM Extents（Oracle ASM区段）
ASM区段是用来保存Oracle ASM文件内容的原始存储。ASM文件由一个或多个文件区段组成。每个ASM区段由特定磁盘上的一个或多个分配单元组成。
注意:ASM范围与用于在段中存储数据的范围不同。
- Oracle ASM Allocation Units（Oracle ASM 分配单元）
分配单元是磁盘组中分配的基本单元。分配单元是ASM分配的最小的连续磁盘空间。一个或多个分配单元构成一个ASM范围。
Oracle ASM Instances（ASM实例）
ASM实例是管理ASM磁盘的特殊Oracle实例。ASM和数据库实例都需要共享对ASM磁盘组中的磁盘的访问。ASM实例管理磁盘组的元数据，并向数据库实例提供文件布局信息。数据库实例将I/O直接指向ASM磁盘，而不需要经过ASM实例。
ASM实例构建在与数据库实例相同的技术上。例如，ASM实例具有与数据库实例类似的系统全局区域(system global area, SGA)和后台进程。但是，ASM实例不能挂载数据库，并且执行的任务比数据库实例少。
ASM实例构建在与数据库实例相同的技术上。例如，ASM实例具有与数据库实例类似的系统全局区域(system global area, SGA)和后台进程。但是，ASM实例不能挂载数据库，并且执行的任务比数据库实例少。
图11-3显示了一个单节点配置，其中包含一个Oracle ASM实例和两个数据库实例，每个实例都与一个不同的单实例数据库相关联。ASM实例管理元数据，并为存储两个数据库数据的ASM文件提供空间分配。一个ASM磁盘组有四个ASM磁盘，另一个有两个磁盘。两个数据库实例都可以访问磁盘组。
11.1.3 Oracle Managed Files and User-Managed Files（Oracle 托管文件和用户托管文件）
Oracle托管文件是一种文件命名策略，它允许您根据数据库对象而不是文件名指定操作。例如，您可以创建一个表空间，而不需要指定它的数据文件的名称。通过这种方式，Oracle托管文件消除了管理员直接管理数据库中的操作系统文件的需要。ASM需要Oracle托管文件的功能。
注意:此特性不影响管理文件(如跟踪文件、审计文件和警报日志)的创建或命名。
使用用户管理的文件，您可以直接管理数据库中的操作系统文件。您将决定文件结构和命名。例如，在创建表空间时，设置表空间数据文件的名称和路径。
通过初始化参数，可以为特定类型的文件指定文件系统目录。Oracle托管文件特性确保数据库创建一个惟一的文件，并在不再需要时删除它。数据库内部使用标准文件系统接口为存储在快速恢复区域中的数据文件和临时文件、控制文件以及与恢复相关的文件创建和删除文件。
Oracle托管文件不会消除现有功能。您可以在手动管理旧文件的同时创建新文件。因此，数据库可以包含Oracle托管文件和用户托管文件。
11.2 Overview of Data Files（数据文件概述）
在操作系统级别，Oracle数据库将数据库数据存储在数据文件中。每个数据库必须至少有一个数据文件。
11.2.1 Use of Data Files（数据文件的使用）
第一部分“Oracle关系数据结构”解释了用户存储数据的逻辑结构，其中最重要的是表。每个非分区模式对象和对象的每个分区都存储在自己的段中。
为了便于管理，Oracle数据库在表空间中为用户数据分配空间，表空间类似于逻辑存储结构的段。每个段只属于一个表空间。例如，非分区表的数据存储在一个段中，而这个段又存储在一个表空间中。
Oracle数据库将表空间数据存储在数据文件中。表空间和数据文件密切相关，但有重要的区别:
- 每个表空间由一个或多个数据文件组成，这些文件符合运行Oracle数据库的操作系统。
- 数据库的数据集中存储在数据库每个表空间中的数据文件中。
- 段可以跨一个或多个数据文件，但不能跨多个表空间。
- 数据库必须具有SYSTEM和SYSAUX表空间。Oracle数据库在创建数据库期间自动为系统表空间分配任何数据库的第一个数据文件。
SYSTEM表空间包含数据字典，这是一组包含数据库元数据的表。通常，数据库还有一个undo表空间和一个临时表空间(通常称为TEMP)。
图11-4显示了表空间、数据文件和段之间的关系。
11.2.2 Permanent and Temporary Data Files（永久和临时数据文件）
永久表空间包含持久模式对象。永久表空间中的对象存储在数据文件中。
临时表空间只在会话期间包含模式对象。本地管理的临时表空间有临时文件(临时文件)，这些文件是特殊的文件，用于以散列、排序和其他操作存储数据。当内存中空间不足时，临时文件还存储结果集数据。
临时文件类似于永久数据文件，但有以下例外:
- 永久数据库对象(如表)从不存储在临时文件中。
- Temp文件总是被设置为NOLOGGING模式，这意味着它们从来没有为它们重新生成。媒体恢复不识别临时文件。
- 不能将临时文件设置为只读。
- 不能使用ALTER DATABASE语句创建临时文件。
- 当您创建或调整临时文件的大小时，并不总是保证为指定的文件大小分配磁盘空间。在Linux和UNIX等文件系统上，临时文件被创建为稀疏文件(Sparse files)。在这种情况下，磁盘块不是在文件创建或调整大小时分配的，而是在第一次访问这些块时分配的。
注意:稀疏文件(Sparse files)支持快速创建临时文件和调整大小;但是，稍后访问临时文件时，磁盘可能会耗尽空间。 - 临时文件信息显示在数据字典视图
DBA_TEMP_FILES和动态性能视图V$TEMPFILE中，但不在DBA_TEMP_FILES或V$DATAFILE视图中。
11.2.3 Online and Offline Data File(联机和脱机数据文件)
每个数据文件要么在线(可用)，要么离线(不可用)。您可以通过脱机或联机更改单个数据文件或临时文件的可用性。离线数据文件只有重新联机才能访问。
管理员可能出于多种原因将数据文件脱机，包括执行脱机备份、重命名数据文件或阻止损坏。如果数据库无法写入数据文件，则数据库将自动脱机该数据文件。
与数据文件一样，表空间本身也是离线或在线的。当您在联机表空间中将数据文件脱机时，表空间本身将保持联机状态。通过使表空间本身脱机，可以使表空间的所有数据文件暂时不可用。
11.2.4 Data File Structure(数据文件结构)
磁盘空间加上数据文件头的开销。运行Oracle数据库的操作系统负责在将旧信息分配给数据库之前从文件中清除旧信息和授权。
每个数据文件头包含一个绝对文件号和一个相对文件号。绝对文件号惟一地标识数据库中的数据文件。相对文件号惟一地标识表空间中的数据文件。
但是，数据库保留空间来保存相关表空间的未来段的数据。当数据在表空间中增长时，Oracle数据库使用数据文件中的空闲空间为段分配区段。
图11-5说明了数据文件中不同类型的空间。扩展数据块要么被使用，这意味着它们包含段数据，要么被释放，这意味着它们可以重用。随着时间的推移，更新和删除表空间中的对象可能会创建一些空空间，这些空间单独不够大，无法重新用于新数据。这种类型的空空间称为碎片状的自由空间。
11.3 Overview of Control Files(控制文件概述).
数据库控制文件是一个仅与一个数据库关联的小型二进制文件。每个数据库都有一个唯一的控制文件，尽管它可以维护相同的文件副本。
11.3.1 Use of Control Files（控制文件的使用）
控制文件是Oracle数据库用来查找数据库文件和管理数据库状态的根文件。控制文件包含以下信息:
- 数据库名称和数据库惟一标识符(DBID)
- 数据库创建的时间戳
- 有关数据文件、联机重做日志文件和归档重做日志文件的信息
- Tablespace信息
- RMAN备份
控制文件的用途如下:
- 它包含有关数据文件、在线重做日志文件等信息，这些信息是打开数据库所必需的。
控制文件跟踪对数据库的结构更改。例如，当管理员添加、重命名或删除数据文件或在线重做日志文件时，数据库将更新控制文件以反映此更改。 - 它包含在数据库未打开时必须可访问的元数据。
例如,控制文件包含恢复数据库所需的信息,包括检查点。检查点指示在redo流中SCN,实例恢复将需要开始。检查点SCN之前的每一个更改都保证在数据文件中保存在磁盘上。至少每三秒钟,检查点过程记录控制文件中的信息,在在线重做日志中检查点位置。
在数据库使用期间，Oracle数据库不断地对控制文件进行读写，并且必须在数据库打开时可用。例如，恢复数据库涉及从控制文件中读取数据库中包含的所有数据文件的名称。其他操作，例如添加数据文件，更新存储在控制文件中的信息。
11.3.2 Multiple Control Files（多个控制文件）
Oracle数据库允许同时打开多个相同的控制文件，并为同一个数据库编写这些文件。通过对不同磁盘上的控制文件进行多路复用，数据库可以实现冗余，从而避免单点故障。
注意:Oracle建议您在不同的磁盘上维护多个控制文件副本。
如果控制文件变得不可用，那么当数据库实例尝试访问损坏的控制文件时，它将失败。当存在其他当前控制文件副本时，可以在不进行媒体恢复的情况下重新装载和打开数据库。但是，如果数据库的所有控制文件都丢失，则实例失败，需要进行媒体恢复。如果由于当前副本不可用而必须使用控制文件的旧备份，则媒体恢复并不简单。
11.3.3 Control File Structure （控制文件结构）
有关数据库的信息存储在控制文件的不同部分。每个部分都是一组关于数据库某个方面的记录。例如，控制文件中的一个部分跟踪数据文件并包含一组记录，每个记录对应一个数据文件。每个部分存储在多个逻辑控制文件块中。记录可以跨越一个节中的多个块。
控制文件包含以下类型的记录:
- Circular reuse records（循环重复使用记录）
这些记录包含非关键信息，如果需要，可以覆盖这些信息。当所有可用的记录槽都已满时，数据库要么展开控制文件为新记录腾出空间，要么覆盖最老的记录。示例包括关于归档重做日志文件和RMAN备份的记录。 - Noncircular reuse records（非循环重复使用记录）
这些记录包含不经常更改且不能被覆盖的关键信息。信息的示例包括表空间、数据文件、在线重做日志文件和重做线程。Oracle数据库从不重用这些记录，除非从表空间中删除相应的对象。
正如在第6-5页的“动态性能视图概述”中所解释的，您可以查询动态性能视图，也称为V$视图，以查看存储在控件文件中的信息。例如，您可以查询V$DATABASE来获得数据库名称和DBID。但是，只有数据库可以修改控制文件中的信息。
阅读和编写控制文件块不同于阅读和编写数据块。对于控制文件,Oracle数据库读取并直接从磁盘写入程序全局区域(PGA)。每个过程都分配一定数量的PGA内存,用于控制文件块。
11.4 Overview of the Online Redo Log(在线重做日志概述)
恢复最关键的结构是在线重做日志，它由两个或多个预先分配的文件组成，这些文件在发生更改时存储到数据库中。联机重做日志记录对数据文件的更改。
11.4.1 Use of Online Redo Log（使用在线重做日志）
数据库维护在线重做日志文件，以防止数据丢失。具体来说，在实例失败之后，在线重做日志文件使Oracle数据库能够恢复尚未写入数据文件的提交数据。
Oracle数据库将每个事务同步地写入重做日志缓冲区，然后再将其写入在线重做日志。日志的内容包括未提交的事务、撤消数据、模式和对象管理语句。
Oracle数据库只使用在线重做日志进行恢复。但是，管理员可以通过Oracle LogMiner实用程序中的SQL接口在线查询重做日志文件(参见第18-8页的“Oracle LogMiner”)。重做日志文件是关于数据库活动的历史信息的有用来源。
11.4.2 How Oracle Database Writes to the Online Redo Log（Oracle数据库如何写在线重做日志）
数据库实例的在线重做日志称为重做线程。在单实例配置中，只有一个实例访问数据库，因此只有一个redo线程。然而，在Oracle Real Application Clusters (Oracle RAC)配置中，两个或多个实例同时访问一个数据库，每个实例都有自己的redo线程。每个实例的单独重做线程避免了对一组在线重做日志文件的争用。
在线重做日志由两个或多个联机重做日志文件组成。Oracle数据库至少需要两个文件，以确保一个文件在存档时始终可用(如果数据库处于ARCHIVELOG模式)。
Online Redo Log Switches（线重做日志交换机）
Oracle数据库每次只使用一个在线重做日志文件来存储重做日志缓冲区中写的记录。日志写入器(LGWR)进程正在积极写入的在线重做日志文件称为当前在线重做日志文件。
当数据库停止对一个在线重做日志文件的写入而开始对另一个重做日志文件的写入时，将发生日志切换。通常，当当前在线重做日志文件已满且必须继续写入时，会发生切换。但是，您可以将日志开关配置为定期发生，而不管当前在线重做日志文件是否已被填充，并手动强制执行日志开关。
日志写入器循环地写在线重做日志文件。当日志写入器填充最后一个可用的在线重做日志文件时，进程将写入第一个日志文件，重新启动该循环。
图11-6说明了重做日志的循环写入。
图11-6中的数字显示了LGWR写入每个在线重做日志文件的顺序。当日志开关和日志写入器开始写入时，数据库为每个文件分配一个新的日志***。当数据库重用在线重做日志文件时，该文件将接收下一个可用的日志***。
填写的在线重做日志文件可以根据存档模式重用:
- 如果禁用归档，即数据库处于NOARCHIVELOG模式，则在数据库写入器(DBWn)将记录在其中的更改检查点(写入)到磁盘后，就可以使用一个已填满的在线重做日志文件。
- 如果启用归档，即数据库处于ARCHIVELOG模式，则在对数据文件进行更改并存档后，日志写入器可以使用一个填写完整的在线重做日志文件。
在某些情况下，日志写入器可能无法重用现有的在线重做日志文件。例如，在线重做日志文件可能是活动的(实例恢复需要)，而不是非活动的(实例恢复不需要)。此外，在线重做日志文件可能正在被清除的过程中。
Multiple Copies of Online Redo Log Files( 联机重做日志文件的多个副本)
Oracle数据库可以在不同的位置自动维护两个或多个相同的在线重做日志副本。联机重做日志组由联机重做日志文件及其冗余副本组成。每个相同的副本都是在线重做日志组的成员。每个组由一个数字定义，比如ground1、ground2等等。
维护在线重做日志组的多个成员可以防止重做日志的丢失。理想情况下，成员的位置应该位于单独的磁盘上，这样一个磁盘的故障不会导致整个在线重做日志的丢失
在图11-7中，A_LOG1和B_LOG1是ground1的相同成员，而A_LOG2和B_LOG2是ground2的相同成员。组中的每个成员必须具有相同的大小。LGWR并发地写到ground1(成员A_LOG1和B_LOG1)，然后并发地写到ground2(成员A_LOG2和B_LOG2)，然后并发地写到组1，以此类推。LGWR从不并发地写入不同组的成员。
注意:Oracle建议您对在线重做日志进行多重处理。如果需要恢复，日志文件的丢失可能是灾难性的。当您对联机重做日志进行多重处理时，数据库必须增加它执行的I/O数量。根据您的系统，这个额外的I/O可能会影响整个数据库的性能。
Archived Redo Log Files (存档重做日志文件)
存档的重做日志文件是在线重做日志组中已填充成员的副本。该文件不被认为是数据库的一部分，而是数据库创建的在线重做日志文件的离线副本，并将其写入用户指定的位置。
归档重做日志文件是备份和恢复策略的关键部分。你可以使用存档重做日志文件:
- 恢复数据库备份
- 更新备用数据库
- 使用LogMiner实用工具获取关于数据库历史的信息
归档是生成归档重做日志文件的操作。归档可以是自动的，也可以是手动的，只有当数据库处于ARCHIVELOG模式时才可能进行归档。
存档的重做日志文件包括重做条目和在线重做日志组相同成员的日志***。在图11-7中，文件A_LOG1和b_log1是组1的相同成员。如果数据库处于ARCHIVELOG模式，并且启用了自动归档，那么归档进程(ARCn)将归档其中一个文件。如果A_LOG1损坏，则进程可以归档B_LOG1。存档的重做日志包含启用存档以来创建的每个组的副本。
Structure of the Online Redo Log(在线重做日志的结构)
联机重做日志文件包含重做记录。重做记录由一组更改向量组成，每个更改向量描述对数据块的更改。例如，对employees表中的salary的更新生成一个redo记录，该记录描述对表的数据段块、undo段数据块和undo段事务表的更改。
重做记录包含所有有关更改的元数据，包括以下内容:
- 更改的SCN和时间戳
- 生成更改的事务的事务ID
- 提交事务时的SCN和时间戳(如果提交了)
- 进行更改的操作类型
- 修改后的数据段的名称和类型