Oracle DB 管理数据库存储结构

概述

一个Oracle数据库由物理和逻辑结构组成。物理结构可以从操作系统上被看到并操作，比如储存数据的磁盘文件。逻辑结构是DB建立并识别的，操作系统无法理解。DB、表空间中的主要逻辑结构包含物理文件。他们之间的关系如下图所示

结构管理的大部分可以由DB自动完成。EM提供了一个BUI来使用户可以简单的管理和监控DB。

控制文件

控制文件跟踪DB的物理组件。他是用来寻找所有DB使用的其他文件的根文件。正是由于这种重要性，Oracle建议把控制文件设置为多份。如果任何控制文件出了问题，DB就不可用。这时，如果有拷贝的话，可以关闭DB然后用拷贝重新生成失效的控制文件，重启DB。或者，从CONTROL_FILES初始化参数中删除这个控制文件，然后使用剩余的控制文件来重启DB

在线重做日志文件

每个DB有一组（2个或多个）在线重做日志文件。一个重做日志由重做单元组成，也被称为重做记录。
在线重做日志文件储存了应用于数据的改动的一个拷贝。当失败发生时，恢复的数据文件上丢失的临近的数据改动，可以通过在线重做日志文件获得。在线重做日志文件用于应对由硬件、软件或媒介错误带来的失败。而为了保护在线重做日志文件本身，DB可以保留多份在线重做日志文件。一个DB的在线重做日志由多组在线重做日志文件（带s）构成。每组由一个在线重做日志文件和多个拷贝组成。每个同样的拷贝都被认为是那个组的成员。每个组都被定义了一个数字，比如组1。
下图展示了一个DB配置，它拥有3个在线重做日志文件组，每组两个成员。每组的成员都分别位于不同的磁盘上，保证了最大的可用性。

DB日志写进程（LGWR）从内存缓冲区把重做记录写进日志组，知道日志文件到达大小限制，或者用户请求了日志切换操作。这是LGWR写到下一个日志组，如是循环，直到最老的组被重新覆盖使用。

归档重做日志文件

当激活归档时，DB会在在线重做日志文件（复数）被覆盖之前，把他们复制到另一个地方，这些复制品被称作归档重做日志文件。用户可以归档到多个地方。

数据文件

数据文件是DB中储存数据的操作系统文件。这些数据是Oracle特有方式写入的。临时文件是特殊的数据文件，只和临时表空间相关联。数据文件可以细分为下述组件：

段 - Segment
段包含特定类型DB对象。比如一个表存储在一个表段，一个索引存储在一个索引段。一个数据文件可以包含多个段。同时，段可以跨越多个数据文件

扩展区 - Extent
一个扩展区是一个段内一组连续的数据块扩展区，是逻辑上连续的数据块，在单次分配中获得，用于存储特定类型的信息。DB为段分配扩展区的空间，当一个段的现有扩展区满的时候，DB会分配新的扩展区。

数据块 - Data block
数据块，也叫DB块，是DB存储的最小I/O单元。一个扩展区由多个连续的数据块构成。DB在创建时设定缺省块大小。
DB一旦建立，缺省块大小就不能更改了，除非重建DB。但是可以创建具有不同块大小的表空间。

表空间

DB被切分成一种叫做表空间的逻辑存储单元，把相关逻辑结构分成组，例如表、视图等。例如，所有的应用对象可以分到一个单独的表空间以便维护。一个表空间由一到多个数据文件组成。DB建立时就存在了一些表空间，比如SYSTEM和SYSAUX。
比如下面的这些表空间:

名称	描述
SYSTEM	自动生成，用于管理数据库本身。包含了数据字典以及用于管理DB的表和视图。位于SYS模式，并且只能被SYS用户以及具有相关权限的用户访问。
SYSAUX	辅助SYSTEM，包含了一些组件和产品的数据，减轻SYSTEM表空间的负载。DB10.1以及之后的版本都有这个表空间。把SYSAUX作为默认的组件包括Automatic Workload Repository, Oracle Streams, Oracle Text, and Database Control Repository
UNDOTBS1	存储重做信息
USERS	存储永久用户对象和数据。类似TEMP，每个DB应该有一个表空间来存储分配给用户的永久用户数据。否则，用户数据将被建立在SYSTEM表空间，这种方式是不推荐的。
TEMP	存贮处理SQL语句时产生的临时数据
EXAMPLE	包含一些示例模式。

本地管理的表空间

表空间的空间管理包括跟踪可用的以及已用的空间，以便在数据插入和删除时可以有效操作。“本地管理的表空间”把空间分配信息存储在表空间自身，而不是数据字典，从而提供了更好的性能。默认情况下，DB会对创建的表空间应用这种方式，附带自动段管理，一种进一步提升性能的技术。

表空间的类型

永久型：用户存储用户和应用的数据。DB用其来存储永久数据，例如系统数据。每个用户会被分配一个默认的永久表空间。
撤销型（UNDO）：运行在自动UNDO管理模式的DB，在undo表空间中自动的建立并且管理undo数据，用来回退事务，提供读一致性，帮助DB恢复，提供闪回等特性。一个实例只能有一个活动的undo表空间。
临时型：用于存储临时数据，例如当SQL执行排序操作时。

表空间有以下状态：读写（默认）；只读；脱机。另外还可以设置一个表空间为自动扩容，或者是加密的。

其他存储结构

初始化参数文件：在启动时，被DB实例用于确定运行时属性和资源。某些属性可以运行时设置或更改，其他的需要重启生效。
口令文件：用户对拥有SYSDBA或SYSOPER连接权限的管理员用户进行授权。当需要远程以SYSDBA或SYSOPER连接到DB时需要这个文件，从而DBA可以启动、关闭数据库或执行其他高级别管理任务。口令文件是独立于DB本身的，所以即使是DB没有启动时也可以起作用。DBCA会建立口令文件，包含SYS用户，当授权SYSDBA给一个用户时，会自动添加这个用户到口令文件。
备份文件：技术上说，备份文件不属于DB，仅仅是DB在某种形式上的复制，用于恢复DB

管理联机重做日志

这是DB恢复时的关键组件。DB中的每个事务都会更新重做日志，不管归档是否启用。

多路复用联机重做日志

这种方式提供了更好的数据保护，是推荐的方式。用户需要对每个联机重做日志组添加成员。

切换日志文件

当日志切换发生时，日志写进程（LGWR）会把日志写入下一个重做日志组，当前的日志组就变为非活动状态。用户可以强制请求一次日志切换，来进行必要的日志维护操作。

管理undo数据

从11g开始，默认的DB会自动管理undo数据，DBA无需在意。然而，如果安装使用了闪回操作，用户可能会需要进行一些必要的管理。

当一个事务更改数据时，DB会把原始的数据复制一份，称为undo数据，这么做是为了：
1. 撤销没有提交的改动。
2. 提供读一致性。
3. 实现闪回特性，用户可以查看或者恢复到之前的一个时间点的数据。

undo保留期

DB本身会保证活动事务使用的undo数据不会被覆盖，知道事务被提交。事务提交之后，对应的undo数据就可以被重用或者覆盖了。然而，即使事务提交之后，保留对应的undo数据同样是有用的，比如为了保证闪回操作的成功，或是长请求的读一致性。所以，DB维护并且自动设置undo保留期。年龄小于这个保留期的提交的undo数据会被保留。

管理undo数据

DB会自动的管理undo数据，但是为了更好地支持闪回操作：
1. 为自动伸缩表空间设置最小undo保留期，尽可能的适应闪回操作。（设置初始化参数UNDO_RETENTION）
2. 把undo表空间设置为固定大小。