位置：首页-资讯-数据库

从Oracle到PostgreSQL：最全控制文件

2024-04-02 19:55

短信预约 -IT技能 免费直播动态提醒

原文:

从Oracle到PostgreSQL：最全控制文件（上） https://www.enmotech.com/web/detail/1/770/1.html

从Oracle到PostgreSQL：最全控制文件（下） https://www.enmotech.com/web/detail/1/771/1.html

导读：本文介绍了Oracle和PostgreSQL控制文件基本内容，对如何重建PostgreSQL控制文件进行了详细描述并进行了恢复测试。

控制文件内容

Oracle控制文件内容

从官方文档上可以知道控制文件保存着下列信息：

数据库名以及数据创建时间等
相关数据文件和重做日志文件的名称和位置
表空间信息
重做日志线程、文件信息
备份集及备份文件信息
检查点及SCN信息等
12c增加了PDB的信息

由于控制文件是个二进制文件，无法直接打开查阅，可以将控制文件内容转储出来便于查看，可以使用以下命令来做转存。

SQL> alter session set events 'immediate trace name controlf level 8';Session altered.SQL> select value from v$diag_info where name='Default Trace File';VALUE--------------------------------------------------------------------------------/u01/app/oracle/diag/rdbms/rac12201/RAC122011/trace/RAC122011_ora_24813.trc

注意，从11g开始可以通过v$diag_info获得当前会话转储文件的名称。

打开跟踪文件可以清晰的看到控制文件的内容，最开始的一段是关于数据库ID、名称等的概要信息：

Trace file /u01/app/oracle/diag/rdbms/rac12201/RAC122011/trace/RAC122011_ora_24813.trcOracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit ProductionBuild label: RDBMS_12.2.0.1.0_LINUX.X64_170125ORACLE_HOME: /u01/app/oracle/product/12.2.0.1/dbhome_1System name: LinuxNode name: ractest1Release: 2.6.32-431.el6.x86_64Version: #1 SMP Sun Nov 10 22:19:54 EST 2013Machine: x86_64Instance name: RAC122011Redo thread mounted by this instance: 1Oracle process number: 96Unix process pid: 24813, image: oracle@ractest1 (TNS V1-V3)*** 2019-05-30T09:15:38.980823+08:00 (CDB$ROOT(1))*** SESSION ID:(59.49876) 2019-05-30T09:15:38.980878+08:00*** CLIENT ID:() 2019-05-30T09:15:38.980885+08:00*** SERVICE NAME:(SYS$USERS) 2019-05-30T09:15:38.980891+08:00*** MODULE NAME:(sqlplus@ractest1 (TNS V1-V3)) 2019-05-30T09:15:38.980897+08:00*** ACTION NAME:() 2019-05-30T09:15:38.980903+08:00*** CLIENT DRIVER:(SQL*PLUS) 2019-05-30T09:15:38.980908+08:00*** CONTAINER ID:(1) 2019-05-30T09:15:38.980914+08:00DUMP OF CONTROL FILES, Seq # 233771 = 0x3912bV10 STYLE FILE HEADER: Compatibility Vsn = 203424000=0xc200100 Db ID=1217928546=0x48981d62, Db Name='RAC12201' Activation ID=0=0x0 Control Seq=233771=0x3912b, File size=1216=0x4c0 File Number=0, Blksiz=16384, File Type=1 CONTROL

接下来是数据条目的详细信息，包括了数据的名称、数据文件及日志文件的数量、数据库的检查点及SCN信息等：

***************************************************************************DATABASE ENTRY***************************************************************************(size = 316, compat size = 316, section max = 1, section in-use = 1, last-recid= 0, old-recno = 0, last-recno = 0)(extent = 1, blkno = 1, numrecs = 1)03/31/2019 23:47:46DB Name "RAC12201"Database flags = 0x10406001 0x00001200 0x00000082Controlfile Creation Timestamp 03/31/2019 23:47:47Incmplt recovery scn: 0x0000000000000000Resetlogs scn: 0x0000000000157e2e Resetlogs Timestamp 03/31/2019 23:47:49Prior resetlogs scn: 0x0000000000000001 Prior resetlogs Timestamp 01/26/2017 13:52:29Redo Version: compatible=0xc200100#Data files = 28, #Online files = 25Database checkpoint: Thread=1 scn: 0x0000000002a1699eThreads: #Enabled=2, #Open=2, Head=1, Tail=2enabled threads: 01100000 00000000 00000000 00000000 00000000 00000000.......Max log members = 3, Max data members = 1Arch list: Head=1, Tail=9, Force scn: 0x00000000029c57a6scn: 0x0000000000000000Activation ID: 1217928802Snapshot Controlfile filename name #31: +DATA/snapcf_rac12201.fSnapshot Controlfile checkpoint scn: 0x00000000026d24dd 05/25/2019 22:40:30SCN compatibility 1Auto-rollover enabledControlfile Checkpointed at scn: 0x0000000002a231ff 05/30/2019 09:15:32thread:0 rba:(0x0.0.0)enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000.......

再接下来是检查点记录信息，这部分内容包含了Low Cache RBA 和 On Disk RBA信息，在执行数据库实例恢复时，前者是恢复的起点，后者是恢复的终点，其分别指向了日志文件中的确定地址：

***************************************************************************CHECKPOINT PROGRESS RECORDS***************************************************************************(size = 8180, compat size = 8180, section max = 35, section in-use = 0, last-recid= 0, old-recno = 0, last-recno = 0)(extent = 1, blkno = 2, numrecs = 35)THREAD #1 - status:0x2 flags:0x0 dirty:54low cache rba:(0x13c.ec78.0) on disk rba:(0x13c.edda.0)on disk scn: 0x0000000002a232bc 05/30/2019 09:15:37resetlogs scn: 0x0000000000157e2e 03/31/2019 23:47:49heartbeat: 1009031373 mount id: 1222276307

控制文件还有跟多其它记录，大家可以转储出来仔细阅读接下来的每个条目。

接下来我们看看PostgreSQL控制文件都记录了什么。

PostgreSQL控制文件内容

相比Oracle的控制文件，PostgreSQL控制文件内容就少了很多，主要分为是三部分，初始化静态信息、WAL及检查点的动态信息、一些配置信息。

我们可以用过pg_controldata命令直接读取PostgreSQL控制文件内容：

[postgres@lsl-test1 ~]$ /usr/pgsql-11/bin/pg_controldata -D /pg/pg11/datapg_control version number: 1100Catalog version number: 201809051Database system identifier: 6691945724594983959Database cluster state: in productionpg_control last modified: Thu 30 May 2019 03:20:03 PM CSTLatest checkpoint location: 0/60001E8Latest checkpoint's REDO location: 0/60001E8Latest checkpoint's REDO WAL file: 000000010000000000000006Latest checkpoint's TimeLineID: 1Latest checkpoint's PrevTimeLineID: 1Latest checkpoint's full_page_writes: onLatest checkpoint's NextXID: 0:1048576Latest checkpoint's NextOID: 10000Latest checkpoint's NextMultiXactId: 65536Latest checkpoint's NextMultiOffset: 52352Latest checkpoint's oldestXID: 2296015872Latest checkpoint's oldestXID's DB: 0Latest checkpoint's oldestActiveXID: 0Latest checkpoint's oldestMultiXid: 65536Latest checkpoint's oldestMulti's DB: 0Latest checkpoint's oldestCommitTsXid:0Latest checkpoint's newestCommitTsXid:0Time of latest checkpoint: Thu 30 May 2019 03:20:03 PM CSTFake LSN counter for unlogged rels: 0/1Minimum recovery ending location: 0/0Min recovery ending loc's timeline: 0Backup start location: 0/0Backup end location: 0/0End-of-backup record required: nowal_level setting: replicawal_log_hints setting: offmax_connections setting: 100max_worker_processes setting: 8max_prepared_xacts setting: 0max_locks_per_xact setting: 64track_commit_timestamp setting: offMaximum data alignment: 8Database block size: 8192Blocks per segment of large relation: 131072WAL block size: 8192Bytes per WAL segment: 16777216Maximum length of identifiers: 64Maximum columns in an index: 32Maximum size of a TOAST chunk: 1996Size of a large-object chunk: 2048Date/time type storage: 64-bit integersFloat4 argument passing: by valueFloat8 argument passing: by valueData page checksum version: 0Mock authentication nonce: 0000000000000000000000000000000000000000000000000000000000000000

下面详细介绍下各参数含义。

pg_control version number是控制文件版本号。
Catalog version number 是系统表版本号，格式是yyyymmddN。记录系统不兼容性的改变。N是yyymmdd当天改变的次数。具体可以查看源码文件catversion.h。
Database system identifier 数据库系统号这个标识串是一个64bit的整数，其中包含了创建数据库的时间戳和initdb时初始化的进程号，具体初始化方法可查看源码文件xlog.c。

创建时间可以通过to_timestamp转换查看到。

创建时间可以通过to_timestamp转换查看到。postgres=# SELECT to_timestamp(((6691945724594983959>>32) & (2^32 -1)::bigint)); to_timestamp ------------------------2019-05-17 18:47:10+08(1 row)

Database cluster state 记录实例的状态。源码文件中看到数据库的几种状态，源码pg_control.h中可以看到：

starting up：表示数据库正在启动状态。shut down：数据库实例（非Standby）正常关闭后控制文件中就是此状态。shut down in recovery：Standby实例正常关闭后控制文件中就是此状态。shutting down：正常停库时，先做checkpoint，开始做checkpoint时，会把状态设置为此状态，做完后把状态设置为shut down。in crash recovery：数据库实例非异常停止后，重新启动后，会先进行实例的恢复，在实例恢复时的状态就是此状态。in archive recovery：Standby实例正常启动后，就是此状态。in production：数据库实例正常启动后就是此状态。Standby数据库正常启动后不是此状态

Latest checkpoint location数据库异常停止后再重新启动时，需要做实例恢复，实例恢复的过程是从WAL日志中，找到最后一次的checkpoint点，然后读取这个点之后的WAL日志，重新应用这些日志，此过程称为数据库实例前滚，最后一次的checkpoint点的信息记录在Latest checkpont项中。
Latest checkpoint's REDO location 记录数据库日志文件上检查点。
Latest checkpoint's REDO WAL file记录WAL日志名，目录下pg_wal可以查到文件。
Latest checkpoint's NextXID前面是新纪元值，冒号后面是下一个事务号，当前事务号最大值安全值可以在pg_xact目录下通过文件名计算出来。
Latest checkpoint's NextMultiXactId参数，可以通过pg_multixact/offsets文件名计算出来安全值。
Latest checkpoint's NextMultiOffset参数，当恢复控制文件时可以通过pg_multixact/members文件夹下计算出此参数的安全值。
Maximum length of identifiers是指一些数据库对象名称的最大长度，如表名、索引名的最大长度 Maximum columns in an index 表示一个索引最多多少列，目前为32个。
Maximum size of a TOAST chunk是TOAST chunk的最大长度。TOAST是解决当列的内容太长，在一个数据块中存不下时的一种行外存储的方式。类似Oracle的行链接。
Data page checksum version是数据块checksum的版本，默认为0，数据块没有使用checksum。运行initdb时加了-k参数，PG才会在数据块上启用checksum功能。
参数介绍到这里，控制文件各内容定义可以查看源文件pg_control.h。

重建控制文件

如果控制文件损坏或丢失，数据库将运行异常，也无法启动。对于Oracle和PostgreSQL 控制文件同样重要。

Oracle控制文件重建

对于Oracle来说，当控制文件损坏无备份的情况下，可以通过手工重建控制文件的方法来恢复控制文件。

具体命令如下图：