Linux平台达梦数据库V7之物理架构

一 前言

DM 数据库使用了磁盘上大量的物理存储结构来保存和管理用户数据。典型的物理存储结构包括：用于进行功能设置的配置文件；用于记录文件分布的控制文件；用于保存用户实际数据的数据文件、重做日志文件、归档日志文件、备份文件；用来进行问题跟踪的跟踪日志文件等。

二 物理架构图

三 物理文件介绍

3.1 配置文件

配置文件是 DM 数据库用来设置功能选项的一些文本文件的集合，配置文件以 ini 为扩展名，它们具有固定的格式，用户可以通过修改其中的某些参数取值来达成如下两个方面的目标：

1. 启用/禁用特定功能项；
2. 针对当前系统运行环境设置更优的参数值以提升系统性能。
   主要的配置文件如下：

   3.1.1 DM数据库服务配置文件

   1）dm.ini
   每创建一个 DM 数据库，就会自动生成 dm.ini 文件。dm.ini 是 DM 数据库启动所必须的配置文件，通过配置该文件可以设置 DM 数据库服务器的各种功能和性能选项,其详细配置项请参考官方手册，关于该文件后面会单独用一个文档进行详细介绍。
   参数属性分为三种：静态、动态和手动。
   静态，可以被动态修改，修改后重启服务器才能生效。
   动态，可以被动态修改，修改后即时生效。动态参数又分为会话级和系统级两种。会话级参数被修改后，新参数值只会影响新创建的会话，之前创建的会话不受影响；系统级参数的修改则会影响所有的会话。
   手动，不能被动态修改，必须手动修改 dm.ini 参数文件，然后重启才能生效。
   动态修改是指 DBA 用户可以在数据库服务器运行期间，通过调用系统过程SP_SET_PARA_VALUE()、SP_SET_PARA_DOUBLE_VALUE()和SP_SET_PARA_STRING_VALUE()对参数值进行修改。
   2）dmmal.ini
   dmmal.ini 是 MAL 系统的配置文件。需要用到 MAL环境的实例，所有站点 dmmal.ini 需要保证严格一致，其详细配置项请参考官方手册。
   3）dmarch.ini
   dmarch.ini 用于本地归档和远程归档,其详细配置项请参考官方手册。
   相关说明

   1. 归档类型 ARCH_TYPE 有以下几种：
      本地归档 LOCAL（一台主库最多配 8 个）
      远程实时归档 REALTIME（一台主库最多配 8 个）
      远程异步 归档 ASYNC（一台主库最多配 8 个）
      即时归档 TIMELY（一个主库最多配 8 个）
      远程归档 REMOTE（一个主库最多配 8 个）
   2. 配置名[ARCHIVE_*]表示归档名，在配置文件中必须唯一。
   3. 不能存在相同实例名的不同归档；
   4. 不能存在 DEST 相同的不同归档实例；
   5. ARCH_TIMER_NAME 为定制的定时器名称，定时器配置见 dmtimer.ini；
   6. ARCH_SPACE_LIMIT 表示归档文件的磁盘空间限制，如果归档文件总大小超过这个值，则在生成新归档文件前会删除最老的一个归档文件。
      4）dm_svc.conf
      DM 安装时生成一个配置文件 dm_svc.conf，在 Windows 操作平台下此文件位于%SystemRoot%\system32 目录，在 Linux 平台下此文件位于/etc 目录。
      dm_svc.conf 文件中包含 DM 各接口及客户端需要配置的一些参数，具体的配置项请参考官方文档。
      dm_svc.conf 配置文件的内容分为全局配置区和服务配置区。全局配置区在前，服务配置区在后，以“[服务名]”开头，可配置除了服务名外的所有配置项。服务配置区中的配置优先级高于全局配置区。
      下面是一个 dm_svc.conf 的例子：

      以#开头的行表示是注释

      全局配置区

      O2000=(192.168.0.1:5000,192.168.0.2:5236)
      O3000=(192.168.0.1:5236,192.168.0.3:4350)
      TIME_ZONE=(+8:00)
      LOGIN_ENCRYPT=(0)
      DIRECT=(Y)

      服务配置区

      [O2000]
      TIME_ZONE=(+9:00)
      LOGIN_MODE=(2)
      SWITCH_TIME=(3)
      SWITCH_INTERVAL=(10)
      需要说明的是，如果对 dm_svc.conf 的配置项进行了修改，需要重启客户端程序，修
      改的配置才能生效。
      5）sqllog.ini
      sqllog.ini用于sql日志的配置。当把INI参数SVR_LOG置为1，才会打开SQL日志。如果在服务器启动过程中，修改了sqllog.ini文件。修改之后的文件，只要调用过程SP_REFRESH_SVR_LOG_CONFIG() 就会生效。
      其详细配置项请参考官方文档。
      注意：只有把 INI 参数 SVR_LOG 置为 1，且 SVR_LOG_NAME 为 SLOG_ALL 时，
      sqllog.ini 中名称为 SLOG_ALL 的配置块才会生效。
      例如：下面是一个 SVR_LOG_NAME 为 SLOG_ALL 的 sqllog.ini 的例子：
      BUF_TOTAL_SIZE = 10240 #SQLs Log Buffer Total
      Size(K)(1024~1024000)
      BUF_SIZE = 1024 #SQLs Log Buffer Size(K)(50~409600)
      BUF_KEEP_CNT = 6 #SQLs Log buffer keeped count(1~100)
      [SLOG_ALL]
      FILE_PATH = ..\log
      PART_STOR = 0
      SWITCH_MODE = 0
      SWITCH_LIMIT = 0
      ASYNC_FLUSH = 0
      FILE_NUM = 0
      ITEMS = 0
      SQL_TRACE_MASK = 0
      MIN_EXEC_TIME = 0
      USER_MODE = 0
      USERS =

      3.1.2 复制配置文件

      1）dmrep.ini
      dmrep.ini 用于配置复制实例，具体内容请见“数据复制”章节,具体配置项请参考官方文档。
      2）dmllog.ini
      dmllog.ini 用于配置逻辑日志，具体内容请见“数据复制”章节,具体配置项请参考官方文档。
      3）dmtimer.ini
      dmtimer.ini 用于配置定时器，用于数据守护中记录异步备库的定时器信息或数据复制中记录异步复制的定时器信息, 具体配置项请参考官方文档。

      3.2 控制文件

      每个 DM 数据库都有一个名为 dm.ctl 的控制文件。控制文件是一个二进制文件，它记录了数据库必要的初始信息，其中主要包含以下内容：

3. 数据库名称；
4. 数据库服务器模式；
5. OGUID 唯一标识；
6. 数据库服务器版本；
7. 数据文件版本；
8. 数据库的启动次数；
9. 数据库最近一次启动时间；
10. 表空间信息，包括表空间名，表空间物理文件路径等，记录了所有数据库中使用的表空间，数组的方式保存起来；
11. 控制文件校验码，校验码由数据库服务器在每次修改控制文件后计算生成，保证控制文件合法性，防止文件损坏及手工修改。
    在服务器运行期间，执行表空间的 DDL 等操作后，服务器内部需要同步修改控制文件内容。如果在修改过程中服务器故障，可能会导致控制文件损坏，为了避免出现这种情况，在修改控制文件时系统内部会执行备份操作。备份策略如下：
     策略一 在修改 dm.ctl 之前，先执行一次备份，确定 dm.ctl 修改成功后，再将备份删除，如果 dm.ctl 修改失败或中途出现故障，则保留备份文件。
     策略二 在修改 dm.ctl 成功之后，根据 dm.ini 中指定的CTL_BAK_PATH/CTL_BAK_NUM 对最新的 dm.ctl 执行备份，如果用户指定的CTL_BAK_PATH 是非法路径，则不再生成备份文件，在路径有效的情况下，生成备份文件时根据指定的 CTL_BAK_NUM 判断是否删除老的备份文件。
    注意：
     如果 dm.ctl 文件存放在裸设备上，则【策略一】不会生效。
     如果指定的 CTL_BAK_PATH 是无效路径，则【策略二】也不会生效。
     如果【策略一】和【策略二】的条件都满足，则都会生效执行，否则只执行满足条件的备份策略，如果都不满足，则不会再生成备份文件。
     如果是初始化新库，在初始化完成后，会在“SYSTEM_PATH/CTL_BAK”路径下对原始的 dm.ctl 执行一次备份。
    [root@dm3 TEST]# cat dm.ini |grep CTL_BAK_PATH
    CTL_BAK_PATH = /usr/appsoft/dmdbms/data/TEST/ctl_bak #dm.ctl backup path
    [root@dm3 TEST]# cat dm.ini |grep CTL_BAK_NUM
    CTL_BAK_NUM = 10 #backup number of dm.ctl, allowed to keep one more backup file besides specified number.
    [root@dm3 TEST]#

    3.3 数据文件

    数据文件以 dbf 为扩展名，它是数据库中最重要的文件类型，一个 DM 数据文件对应磁盘上的一个物理文件，数据文件是真实数据存储的地方，每个数据库至少有一个与之相关的数据文件。在实际应用中，通常有多个数据文件。
    当 DM 的数据文件空间用完时，它可以自动扩展。可以在创建数据文件时通过 MAXSIZE参数限制其扩展量，当然，也可以不限制。但是，数据文件的大小最终会受物理磁盘大小的限制。在实际使用中，一般不建议使用单个巨大的数据文件，为一个表空间创建多个较小的数据文件是更好的选择。
    数据文件在物理上按照页、簇和段的方式进行管理，详细结构请参考第一章的内容。
    数据文件按数据组织形式，可以分为如下几种：
    1. B树数据
    行存储数据，也是应用最广泛的存储形式，其数据是按 B 树索引组织的。普通表、分区表、B 树索引的物理存储格式都是 B 树。
    一个 B 树包含两个段，一个内节点段，存放内节点数据；一个叶子段，存放叶子节点数据。其 B 树的逻辑关系由段内页面上的记录，通过文件指针来完成。
    当表上没有指定聚簇索引时，系统会自动产生一个唯一标识 rowid 作为 B 树的 key 来唯一标识一行。
    2. 堆表数据
    堆表的数据是以挂链形式存储的，一般情况下，支持最多 128 个链表，一个链表在物理上就是一个段，堆表采用的是物理 rowid，在插入过程中，rowid 在事先已确定，并保证其唯一性，所以可以并发插入，插入效率很高，且由于 rowid 是即时生成，无需保存在物理磁盘上，也节省了空间。
    3. 列存储数据
    数据按列方式组织存储，每个列包含 2 个段，一个段存放列数据，一个段存放列的控制信息，读取列数据时，只需要顺序扫描这两个段。在某些特殊应用场景下，其效率要远远高于行存储。
    4. 位图索引
    位图索引与 B 树索引不同，每个索引条目不是指向一行数据，而是指向多行数据。每个索引项保存的是一定范围内所有行与当前索引键值映射关系的位图。
    数据文件中还有两类特殊的数据文件：ROLL 和 TEMP 文件。
    1). ROLL文件
    ROLL 表空间的 dbf 文件，称为 ROLL 文件。ROLL 文件用于保存系统的回滚记录，提供事务回滚时的信息。回滚文件整个是一个段。每个事务的回滚页在回滚段中各自挂链，页内则顺序存放回滚记录。
    2). TEMP 文件
    TEMP.DBF 临时数据文件，临时文件可以在 dm.ini 中通过 TEMP_SIZE 配置大小。
    当数据库查询的临时结果集过大，缓存已经不够用时，临时结果集就可以保存在TEMP.DBF 文件中，供后续运算使用。系统中用户创建的临时表也存储在临时文件中。

    3.4 重做日志文件

    重做日志，又叫 REDO 日志，指在 DM 数据库中添加、删除、修改对象，或者改变数据，DM 都会按照特定的格式，将这些操作执行的结果写入到当前的重做日志文件中。重做日志文件以 log 为扩展名。每个 DM 数据库实例必须至少有 2 个重做日志文件，默认两个日志文件为 DAMENG01.log、DAMENG02.log，这两个文件循环使用。
    重做日志文件主要用于数据库的备份与恢复。理想情况下，数据库系统不会用到重做日志文件中的信息。然而现实世界总是充满了各种意外，比如电源故障、系统故障、介质故障，或者数据库实例进程被强制终止等，数据库缓冲区中的数据页会来不及写入数据文件。这样，在重启 DM 实例时，通过重做日志文件中的信息，就可以将数据库的状态恢复到发生意外时的状态。
    重做日志文件对于数据库是至关重要的。它们用于存储数据库的事务日志，以便系统在出现系统故障和介质故障时能够进行故障恢复。在 DM 数据库运行过程中，任何修改数据库的操作都会产生重做日志，例如，当一条元组插入到一个表中的时候，插入的结果写入了重做日志，当删除一条元组时，删除该元组的事实也被写了进去，这样，当系统出现故障时，通过分析日志可以知道在故障发生前系统做了哪些动作，并可以重做这些动作使系统恢复到故障之前的状态。

    3.5 归档日志文件

    日志文件分为联机日志文件和归档日志文件。DM 数据库可以在归档模式和非归档模式下运行。只有当数据库处于归档模式下，才将联机日志文件中的内容保存到硬盘中，形成归档日志文件。
    重做日志文件就是联机日志文件。联机日志文件指的是系统当前正在使用的日志文件，创建数据库时，联机日志文件通常被扩展至一定长度，其内容则被初始化为空，当系统运行时，该文件逐渐被产生的日志所填充。对日志文件的写入是顺序连续的。然而系统磁盘空间总是有限，系统必须能够循环利用日志文件的空间，为了做到这一点，当所有日志文件空间被占满时，系统需要清空一部分日志以便重用日志文件的空间，为了保证被清空的日志所保护”的数据在磁盘上是安全的，这里需要引入一个关键的数据库概念——检查点。当产生检查点时，系统将系统缓冲区中的日志和脏数据页都写入磁盘，以保证当前日志所“保护”的数据页都已安全写入磁盘，这样日志文件即可被安全重用。
    归档日志文件，就是在归档模式下，重做联机日志被连续拷贝到归档日志后，所生成了归档日志文件。归档日志文件以归档时间命名，扩展名也是 log。但只有在归档模式下运行时，DM 数据库在重做联机日志文件时才能生成归档日志文件。
    采用归档模式会对系统的性能产生影响，然而系统在归档模式下运行会更安全，当出现故障时其丢失数据的可能性更小，这是因为一旦出现介质故障，如磁盘损坏时，利用归档日志，系统可被恢复至故障发生的前一刻，也可以还原到指定的时间点，而如果没有归档日志文件，则只能利用备份进行恢复。
    归档日志还是数据守护功能的核心，数据守护中的备库就是通过重做日志来完成与主库的数据同步的。

    3.6 逻辑日志文件

    如果在 DM 数据库上配置了复制功能，复制源就会产生逻辑日志文件。逻辑日志文件是一个流式的文件，它有自己的格式，且不在第一章所述的页，簇和段的管理之下。
    逻辑日志文件内部存储按照复制记录的格式，一条记录紧接着一条记录，存储着复制源端的各种逻辑操作。用于发送给复制目的端。详细内容请看“数据复制”章节。

    3.7 备份文件

    备份文件以 bak 为扩展名，当系统正常运行时，备份文件不会起任何作用，它也不是数据库必须有的联机文件类型之一。然而，从来没有哪个数据库系统能够保证永远正确无误地运行，当数据库不幸出现故障时，备份文件就显得尤为重要了。
    当客户利用管理工具或直接发出备份的 SQL 命令时，DM Server 会自动进行备份，并产生一个或多个备份文件，备份文件自身包含了备份的名称、对应的数据库、备份类型和备份时间等信息。同时，系统还会自动记录备份信息及该备份文件所处的位置，但这种记录是松散的，用户可根据需要将其拷贝至任何地方，并不会影响系统的运行。

    3.8 跟踪日志文件

    用户在dm.ini中配置SVR_LOG和SVR_LOG_SWITCH_COUNT参数后就会打开跟踪日志。跟踪日志文件是一个纯文本文件，以“dm_commit_日期_时间”命名，默认生成在 DM安装目录的 log 子目录下面，管理员可通过 ini 参数 SVR_LOG_FILE_PATH 设置其生成路径。
    跟踪日志内容包含系统各会话执行的 SQL 语句、参数信息、错误信息等。跟踪日志主要用于分析错误和分析性能问题，基于跟踪日志可以对系统运行状态有一个分析，比如，可以挑出系统现在执行速度较慢的 SQL 语句，进而对其进行优化。
    系统中 SQL 日志的缓存是分块循环使用，管理员可根据系统执行的语句情况及压力情况设置恰当的日志缓存块大小及预留的缓冲块个数。当预留块不足以记录系统产生的任务时，系 统 会 分 配 新 的 用 后 即 弃 的 缓 存 块 ， 但 是 总 的 空 间 大 小 由 ini 参 数SVR_LOG_BUF_TOTAL_SIZE 控制，管理员可根据实际情况进行设置。
    打开跟踪日志会对系统的性能会有较大影响，一般用于查错和调优的时候才会打开，默认情况下系统是关闭跟踪日志的。若需要跟踪日志但对日志的实时性没有严格的要求，又希望系统有较高的效率，可以设置参数SQL_TRACE_MASK和SVR_LOG_MIN_EXEC_TIME 只记录关注的相关记录，减少日志总量；设置参数 SVR_LOG_ASYNC_FLUSH 打开 SQL 日志异步刷盘提高系统性能。

    3.9 事件日志文件

    DM 数据库系统在运行过程中，会在 log 子目录下产生一个“dm_实例名_日期”命名的事件日志文件。事件日志文件对 DM 数据库运行时的关键事件进行记录，如系统启动、关闭、内存申请失败、IO 错误等一些致命错误。事件日志文件主要用于系统出现严重错误时进行查看并定位问题。事件日志文件随着 DM 数据库服务的运行一直存在。
    事件日志文件打印的是中间步骤的信息，所以出现部分缺失属于正常现象。

    3.10 数据重演文件

    调用系统存储过程 SP_START_CAPTURE 和 SP_STOP_CAPTURE，可以获得数据重演文件。重演文件用于数据重演，存储了从抓取开始到抓取结束时，DM 数据库与客户端的通信消息。使用数据重演文件，可以多次重复抓取这段时间内的数据库操作，为系统调试和性能调优提供了另一种分析手段。