控制文件作为 UXDB 数据库核心元数据存储载体，记录了数据库运行的关键信息，是保障数据库实例正常启动、恢复及运行的核心文件之一。本文将从控制文件的作用、查看方法、内容解析等维度，对数据库控制文件进行全面且细致的解读。

1 控制文件的作用

控制文件核心作用是存储数据库的关键元数据，涵盖数据库唯一标识（System Identifier）、检查点（Checkpoint）信息、实例运行状态、WAL（Write-Ahead Log）相关配置、备份恢复关键点位等，是数据库启动、故障恢复、主备同步的重要依据。

2 查看控制文件内容的方法

通过 ux_controldata 命令可直接读取控制文件中的完整内容，命令执行格式及示例如下：

a. 进入程序目录

[uxdb@localhost ~]$ cd /opt/uxdbinstall/dbsql/bin
[uxdb@localhost bin]$

b. 查看当前版本

[uxdb@localhost bin]$ ./ux_controldata --version
ux_controldata (UXsinoDB) 2.1.2.4A

c. 读取控制文件


[uxdb@localhost bin]$ ./ux_controldata -D /opt/uxdbinstall/dbsql/data/dbhome_1
ux_control version number:            1300
Catalog version number:               202209061
Database system identifier:           7143575905525845440
Database cluster state:               in production
ux_control last modified:             Thu 15 Sep 2022 08:03:08 PM CST
Latest checkpoint location:           0/17FF160
Latest checkpoint's REDO location:    0/17FF160
Latest checkpoint's REDO WAL file:    000000010000000000000001
Latest checkpoint's TimeLineID:       1
Latest checkpoint's PrevTimeLineID:   1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:          0:490
Latest checkpoint's NextOID:          13549
Latest checkpoint's NextMultiXactId:  1
Latest checkpoint's NextMultiOffset:  0
Latest checkpoint's oldestXID:        483
Latest checkpoint's oldestXID's DB:   1
Latest checkpoint's oldestActiveXID:  0
Latest checkpoint's oldestMultiXid:   1
Latest checkpoint's oldestMulti's DB: 1
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
Time of latest checkpoint:            Thu 15 Sep 2022 08:02:58 PM CST
Fake LSN counter for unlogged rels:   0/3E8
Minimum recovery ending location:     0/0
Min recovery ending loc's timeline:   0
Backup start location:                0/0
Backup end location:                  0/0
End-of-backup record required:        no
wal_level setting:                    replica
wal_log_hints setting:                off
max_connections setting:              100
max_worker_processes setting:         8
max_wal_senders setting:              10
max_prepared_xacts setting:           0
max_locks_per_xact setting:           64
track_commit_timestamp setting:       off
Maximum data alignment:               8
Database block size:                  32768
Blocks per segment of large relation: 32768
WAL block size:                       8192
Bytes per WAL segment:                16777216
Maximum length of identifiers:        64
Maximum columns in an index:          32
Maximum size of a TOAST chunk:        8140
Size of a large-object chunk:         8192
Date/time type storage:               64-bit integers
Float4 argument passing:              by value
Float8 argument passing:              by value
Data page checksum version:           0
Mock authentication nonce:            eea5d8363f889b0461a3138e00ccdd60b8494d9817789fa78d43f7ae78277c32
Case insensitive:                     off
Ignore Case:                          off
Running Mode:                         standard
SecurityCluster:                      off
Full Database encryption:             off
Audit data encryption:                off

3 控制文件内容解析

3.1 数据库版本与平台适配相关信息

此类信息决定了数据库的运行环境适配性、对象存储规则，是数据库版本升级、跨平台迁移的核心参考依据：

ux_control version number: 控制文件自身的版本号，控制文件格式变更时该值会更新；

Catalog version number: 系统表的版本号，例如，数据库的系统表版本为 202209061。若数据库系统表结构发生变更（如新增字段、调整表结构），则系统表的版本号需发生变化
Maximum data alignment: 数据结构最大对齐值，影响内存中数据的存储效率；
Database block size: 数据块基础大小，本文示例中为 32768 字节（32KB）；
Blocks per segment of large relation: 大表分段存储时单个数据文件的最大数据块数，示例中为 32768 块，结合数据块大小可知单文件最大为 1GB（32KB×32768），用于规避文件系统单文件大小限制；
WAL block size: WAL 日志块大小，示例中为 8192 字节（8KB）；
Bytes per WAL segment: 单个 WAL 日志文件的大小，示例中为 16777216 字节（16MB）；
Maximum length of identifiers: 数据库对象名称（表名、索引名、用户名等）的最大长度，示例中为 64 个字符；
Maximum columns in an index: 单个索引支持的最大列数，当前上限为 32 列；
Maximum size of a TOAST chunk: TOAST（超大字段存储技术）块的最大长度，TOAST 用于存储超出数据块容量的字段（如长文本、大二进制数据），示例中为 8140 字节；
Size of a large-object chunk: 大对象（Large Object）存储的 chunk 大小，示例中为 8192 字节；
Date/time type storage: 日期 / 时间类型的存储方式，示例中为 64 位整数存储（不同类 UNIX 平台可能采用浮点数存储）；
Float4 argument passing/Float8 argument passing: 单精度（Float4）、双精度（Float8）浮点型参数的传递方式，示例中均为「传值」（by value），也可配置为「传引用」；
Data page checksum version: 数据块 checksum 的版本，值为 0 表示未启用数据块校验功能；只有运行 initdb 命令时加了 -k 参数，uxdb 才会开启数据块校验
Ignore Case: 大小写敏感初始化集群属性，用于控制数据库对象名称（表名、字段名等）的大小写识别规则。值为 off 表示未启用大小写不敏感模式；仅在执行 initdb 命令时添加 --ignore-case 参数，该功能才会生效；
Running Mode: 实例初始化运行模式，定义数据库的兼容语法与行为模式，支持初始化为标准模式、Oracle 兼容模式、MySQL 兼容模式三类；
SecurityCluster: 安全数据库实例标识，用于区分当前数据库实例的类型。值为 on 表示当前为安全增强版数据库实例，值为 off 则为标准版数据库实例；
Full Database encryption: 全库加密属性，用于标识数据库是否开启全量数据加密功能。示例中值为 off，表示当前未启用全库加密；
Audit data encryption：审计加密属性，用于标识数据库是否开启审计数据加密功能。示例中值为 off，表示当前未启用全库加密；

3.2 数据库唯一标识（Database system identifier）

数据库系统标识是一个 64 位整数，格式示例如下：

Database system identifier:           7143575905525845440

该标识由数据库初始化（initdb）时的时间戳和进程 ID（PID）计算生成，确保全球唯一，计算逻辑如下

gettimeofday(&tv, NULL);
sysidentifier = ((uint64) tv.tv_sec) << 32;
sysidentifier |= ((uint64) tv.tv_usec) << 12;
sysidentifier |= getpid() & 0xFFF;

通过该标识可反推数据库的创建时间，示例 SQL 如下：

uxdb=# SELECT to_timestamp(((7143575905525845440>>32) & (2^32 -1)::bigint));
      to_timestamp      
------------------------
 2022-09-15 20:02:56+08
(1 row)

3.3 数据库实例运行状态

Database cluster state 字段标识实例当前运行状态，不同状态对应数据库不同的运行阶段，具体说明如下：

状态值	含义说明
starting up	数据库启动中（当前版本未实际使用该状态）
shut down	主库（非备库）正常关闭后的状态
shut down in recovery	备库正常关闭后的状态
shutting down	主库正常停止过程中（执行 Checkpoint 时的中间状态，Checkpoint 完成后会转为 shut down）
in crash recovery	数据库异常停止后，重启时的故障恢复状态
in archive recovery	备库正常启动后的运行状态
in production	主库正常启动后的运行状态（备库无此状态）

源码中实例状态通过枚举类型 DBState 定义：

typedef enum DBState
{
    DB_STARTUP = 0,
    DB_SHUTDOWNED,
    DB_SHUTDOWNED_IN_RECOVERY,
    DB_SHUTDOWNING,
    DB_IN_CRASH_RECOVERY,
    DB_IN_ARCHIVE_RECOVERY,
    DB_IN_PRODUCTION
} DBState;

3.4 故障恢复与物理备份核心信息

此类信息是数据库异常重启后前滚恢复、备库同步的关键，核心字段示例如下：

Latest checkpoint location:           0/17FF160
Latest checkpoint's REDO location:    0/17FF160
Latest checkpoint's REDO WAL file:    000000010000000000000001
Latest checkpoint's TimeLineID:       1
Latest checkpoint's PrevTimeLineID:   1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:          0:490
Latest checkpoint's NextOID:          13549
Latest checkpoint's NextMultiXactId:  1
Latest checkpoint's NextMultiOffset:  0
Latest checkpoint's oldestXID:        483
Latest checkpoint's oldestXID's DB:   1
Latest checkpoint's oldestActiveXID:  0
Latest checkpoint's oldestMultiXid:   1
Latest checkpoint's oldestMulti's DB: 1
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
Time of latest checkpoint:            Thu 15 Sep 2022 08:02:58 PM CST
Fake LSN counter for unlogged rels:   0/3E8
Minimum recovery ending location:     0/0
Min recovery ending loc's timeline:   0

1. 故障恢复逻辑

数据库异常停止后重启，会从 WAL 日志中找到最后一次 Checkpoint 点位（Latest checkpoint location），读取该点位之后的 WAL 日志并重新应用，完成实例前滚恢复，确保数据一致性。

2. 备库同步关键字段

Minimum recovery ending location 是备库同步的核心字段：备库在重放 WAL 日志过程中，若有脏数据刷盘，会将生成该脏数据的最新 WAL 日志位置记录到该字段。

备库异常停机重启后，必须重放 WAL 日志至超过该位置，才能对外提供只读服务（或激活为主库），否则可能读取到不一致的脏数据。

3.5 热备份相关信息

热备份相关字段记录了备份的起始 / 结束 WAL 点位，是备库恢复的关键依据：

Backup start location：备份起始 WAL 日志位置；
Backup end location：备份结束 WAL 日志位置；
End-of-backup record required：是否需要备份结束记录（示例中为 no）。

热备份流程与控制文件交互逻辑：

1. 主库执行备份启动命令：

uxdb=# SELECT ux_start_backup('uxdbtag001'::text);
 ux_start_backup 
-----------------
 0/5000028
(1 row)

2. 主库数据目录生成 backup_label 文件，记录备份关键信息（示例）：

START WAL LOCATION: 0/4000028 (file 000000010000000000000004)
CHECKPOINT LOCATION: 0/4000060
BACKUP METHOD: ux_start_backup
BACKUP FROM: master
START TIME: 2022-09-15 19:44:23 CST
LABEL: uxdbtag001

3. 拷贝主库数据文件（包含 backup_label）至备库；备库启动时读取该文件，从备份起始点位开始恢复，并将该点位写入控制文件的 Backup start location。

4.Backup end location 和 End-of-backup record required 记录备库恢复过程中的中间状态，保障备份恢复的完整性。

4 总结

数据库控制文件是承载核心元数据的「核心账本」，其内容涵盖了数据库运行的全生命周期关键信息。理解控制文件各字段的含义与作用，不仅能帮助运维人员快速定位数据库故障、优化备份恢复策略，也是深入掌握数据库底层运行机制的关键。在实际运维中，需重点关注 Checkpoint、实例状态、备份点位等核心字段，确保数据库的稳定运行与高效恢复。

UXDB 控制文件解析