墨墨导读:本文介绍了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.trc
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
Build label:    RDBMS_12.2.0.1.0_LINUX.X64_170125
ORACLE_HOME:    /u01/app/oracle/product/12.2.0.1/dbhome_1
System name:    Linux
Node name:      ractest1
Release:        2.6.32-431.el6.x86_64
Version:        #1 SMP Sun Nov 10 22:19:54 EST 2013
Machine:        x86_64
Instance name: RAC122011
Redo thread mounted by this instance: 1
Oracle process number: 96
Unix 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:00
DUMP OF CONTROL FILES, Seq # 233771 = 0x3912b
V10 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:46
DB Name "RAC12201"
Database flags = 0x10406001 0x00001200 0x00000082
Controlfile Creation Timestamp  03/31/2019 23:47:47
Incmplt recovery scn: 0x0000000000000000
Resetlogs scn: 0x0000000000157e2e Resetlogs Timestamp  03/31/2019 23:47:49
Prior resetlogs scn: 0x0000000000000001 Prior resetlogs Timestamp  01/26/2017 13:52:29
Redo Version: compatible=0xc200100
#Data files = 28, #Online files = 25
Database checkpoint: Thread=1 scn: 0x0000000002a1699e
Threads: #Enabled=2, #Open=2, Head=1, Tail=2
enabled  threads:  01100000 00000000 00000000 00000000 00000000 00000000
.......
Max log members = 3, Max data members = 1
Arch list: Head=1, Tail=9, Force scn: 0x00000000029c57a6scn: 0x0000000000000000
Activation ID: 1217928802
Snapshot Controlfile filename   name #31: +DATA/snapcf_rac12201.f
Snapshot Controlfile checkpoint scn: 0x00000000026d24dd 05/25/2019 22:40:30
SCN compatibility 1
Auto-rollover enabled
Controlfile Checkpointed at scn:  0x0000000002a231ff 05/30/2019 09:15:32
thread: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:54
low cache rba:(0x13c.ec78.0) on disk rba:(0x13c.edda.0)
on disk scn: 0x0000000002a232bc 05/30/2019 09:15:37
resetlogs scn: 0x0000000000157e2e 03/31/2019 23:47:49
heartbeat: 1009031373 mount id: 1222276307

控制文件还有跟多其它记录,大家可以转储出来仔细阅读接下来的每个条目。
接下来我们看看PostgreSQL控制文件都记录了什么。

PostgreSQL控制文件内容

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

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

[postgres@lsl-test1 ~]$ /usr/pgsql-11/bin/pg_controldata  -D /pg/pg11/data
pg_control version number:            1100
Catalog version number:               201809051
Database system identifier:           6691945724594983959
Database cluster state:               in production
pg_control last modified:             Thu 30 May 2019 03:20:03 PM CST
Latest checkpoint location:           0/60001E8
Latest checkpoint's REDO location:    0/60001E8
Latest checkpoint's REDO WAL file:    000000010000000000000006
Latest checkpoint's TimeLineID:       1
Latest checkpoint's PrevTimeLineID:   1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:          0:1048576
Latest checkpoint's NextOID:          10000
Latest checkpoint's NextMultiXactId:  65536
Latest checkpoint's NextMultiOffset:  52352
Latest checkpoint's oldestXID:        2296015872
Latest checkpoint's oldestXID's DB:   0
Latest checkpoint's oldestActiveXID:  0
Latest checkpoint's oldestMultiXid:   65536
Latest checkpoint's oldestMulti's DB: 0
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
Time of latest checkpoint:            Thu 30 May 2019 03:20:03 PM CST
Fake LSN counter for unlogged rels:   0/1
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_prepared_xacts setting:           0
max_locks_per_xact setting:           64
track_commit_timestamp setting:       off
Maximum data alignment:               8
Database block size:                  8192
Blocks per segment of large relation: 131072
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:        1996
Size of a large-object chunk:         2048
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:            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来说,当控制文件损坏无备份的情况下,可以通过手工重建控制文件的方法来恢复控制文件。

具体命令如下图:

详细信息可以查看官方文档:

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/sqlrf/CREATE-CONTROLFILE.html#GUID-9B389F28-C4D0-405D-BFE6-48237E8BD791https://docs.oracle.com/en/database/oracle/oracle-database/12.2/admin/managing-control-files.html#GUID-98A05D29-DD80-4D87-9615-76CBCF8FE694

PostgreSQL控制文件重建


pg9.6前使用 pg_resetxlog,pg10之后使用pg_resetwal清理wal日志或重置控制文件中一些控制信息。

命令详细介绍可以查看官方文档:

https://www.postgresql.org/docs/11/app-pgresetwal.html

[postgres@lsl-test1 ~]$  /usr/pgsql-11/bin/pg_resetwal -n -D /pg/pg11/data
pg_resetwal: lock file "postmaster.pid" exists
Is a server running?  If not, delete the lock file and try again.
[postgres@lsl-test1 ~]$ ./pg_resetwal --help
pg_resetwal resets the PostgreSQL write-ahead log.  Usage:  pg_resetwal [OPTION]... DATADIR Options:    -c, --commit-timestamp-ids=XID,XID set oldest and newest transactions bearing  commit timestamp (zero means no change)
[-D, --pgdata=]DATADIR          data directory -e, --epoch=XIDEPOCH           set next transaction ID epoch   -f, --force                    force update to be done  -l, --next-wal-file=WALFILE    set minimum starting location for new WAL   -m, --multixact-ids=MXID,MXID  set next and oldest multitransaction ID -n, --dry-run                  no update, just show what would be done  -o, --next-oid=OID             set next OID    -O, --multixact-offset=OFFSET  set next multitransaction offset    -V, --version                  output version information, then exit    -x, --next-transaction-id=XID  set next transaction ID --wal-segsize=SIZE         size of WAL segments, in megabytes  -?, --help                     show this help, then exit

下面看下命令各个参数具体含义:

-c参数有两个参数值,一个最旧的事务号,一个最新的事务号。最旧的事务号的安全值,可以在pg_commit_ts目录查询最小的文件名;最新事务ID的安全值,可以在pg_commit_ts目录查询最大的文件名。文件名都是16进制。实际测试在11的版本pg_commit_ts目录下未发现文件。

[postgres@lsl-test1 data]$ cd pg_commit_ts/
[postgres@lsl-test1 pg_commit_ts]$ ls -l
total 0

-e参数是设置事务号的新纪元(epoch),除了pg_resetwal设置的字段之外,事务ID新纪元实际上并不存储在数据库的任何位置。您可能需要调整此值,以确保Slony或者Skytools等复制系统能够正确工作。如果是这样的话,应该可以从下游复制数据库的状态获得适当的值。

-l 参数通过指定下一个WAL段文件的名称,手动设置WAL启动位置。该选项使用WAL文件名,而不是LSN。下一个段的名字应该大于当前存在pg_wal目录下的任何WAL段文件名。

[postgres@lsl-test1 pg_commit_ts]$ cd ../pg_wal/
[postgres@lsl-test1 pg_wal]$ ls -l
total 32768
-rw-------. 1 postgres postgres 16777216 May 30 17:26 000000010000000000000007
-rw-------. 1 postgres postgres 16777216 May 30 17:26 000000010000000000000008
drwx------. 2 postgres postgres        6 May 17 17:22 archive_status

这些名称也是十六进制的,文件名包含三部分 ,第一部分时间线号(timeline ID) ,第二部分逻辑日志号 ,第三部分日志段号。

-m参数也是两个值,一个是下一个多事务号,一个是最旧的多事务号。

下一个多事务号的安全值,可以在目录pg_multixact/offsets查找数值最大的文件名,加1然后乘以65536(0x10000)。

最旧的多事务号的安全值可以通过查询目录下数值最小的文件名乘以65536。文件名都是十六进制。

[postgres@lsl-test1 pg_wal]$ cd ../pg_multixact/offsets/
[postgres@lsl-test1 offsets]$ ls -l
total 8
-rwx------. 1 postgres postgres 8192 May 17 18:04 0000

-o参数是设置下一个OID(OID,object 是pg内部使用,作为系统表的主键),我们恢复时可以不设置这个参数,因为设置一个超过数据库中最大值OID没有好的办法。

-O参数是设置下一个多事务偏移量。查找pg_multixact/members目录下数值最大的文件名,+1乘以52352 (0xCC80),可以计算出偏移量的安全值。目录下文件的文件名也是十六进制的。

[postgres@lsl-test1 offsets]$ ls -l ../members/
total 8
-rwx------. 1 postgres postgres 8192 May 17 17:22 0000

--wal-segsize参数设置新的WAL段大小 。

-x参数是手工设置下一个事务ID,pg_xact目录下可以查看数值最大的文件名,+1乘以 1048576 (0x100000),获取安全值。文件名也是十六进制。

[postgres@lsl-test1 offsets]$ ls -l ../../pg_xact/
total 16
-rwx------. 1 postgres postgres 8192 May 17 18:04 0000
-rw-------. 1 postgres postgres 8192 May 30 17:26 0001

PostgreSQL控制文件恢复测试

测试过程如下(基于PostgreSQL 11.2) :

1. 新建测试数据, 用到with oids的表, 因为OID无法确定, 看看是否会有异常

postgres=# create table lsl_oid1(id int primary key) with oids;
CREATE TABLE
postgres=#  insert into lsl_oid1 select generate_series(1,100000);
INSERT 0 100000
postgres=# select min(oid),max(oid) from lsl_oid1 ;    min  |  max
-------+--------
16400 | 116399
(1 row)

2. 关闭数据,记录下控制文件信息

[postgres@lsl-test1 bin]$ /usr/pgsql-11/bin/pg_ctl  stop -D /pg/pg11/data
waiting for server to shut down.... done
server stopped

## 记下pg_controldata信息, 方便修复后进行比对

[postgres@lsl-test1 bin]$ /usr/pgsql-11/bin/pg_controldata  -D /pg/pg11/data
pg_control version number:            1100
Catalog version number:               201809051
Database system identifier:           6691945724594983959
Database cluster state:               shut down
pg_control last modified:             Thu 30 May 2019 05:26:41 PM CST
Latest checkpoint location:           0/79E9888
Latest checkpoint's REDO location:    0/79E9888
Latest checkpoint's REDO WAL file:    000000010000000000000007
Latest checkpoint's TimeLineID:       1
Latest checkpoint's PrevTimeLineID:   1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:          0:1048585
Latest checkpoint's NextOID:          116400
Latest checkpoint's NextMultiXactId:  65536
Latest checkpoint's NextMultiOffset:  52352
Latest checkpoint's oldestXID:        561
Latest checkpoint's oldestXID's DB:   13878
Latest checkpoint's oldestActiveXID:  0
Latest checkpoint's oldestMultiXid:   1
Latest checkpoint's oldestMulti's DB: 13878
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
Time of latest checkpoint:            Thu 30 May 2019 05:26:40 PM CST
Fake LSN counter for unlogged rels:   0/1
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_prepared_xacts setting:           0
max_locks_per_xact setting:           64
track_commit_timestamp setting:       off
Maximum data alignment:               8
Database block size:                  8192
Blocks per segment of large relation: 131072
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:        1996
Size of a large-object chunk:         2048
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:            0000000000000000000000000000000000000000000000000000000000000000    

3. 模拟控制文件故障,直接删除控制文件

[postgres@lsl-test1 global]$ pwd
/pg/pg11/data/global
[postgres@lsl-test1 global]$ rm -rf pg_control

4. 启动数据库,模拟控制文件丢失场景

[postgres@lsl-test1 global]$ /usr/pgsql-11/bin/pg_ctl  start
waiting for server to start....postgres: could not find the database system
Expected to find it in the directory "/pg/pg11/data",
but could not open file "/pg/pg11/data/global/pg_control": No such file or directory
stopped waiting
pg_ctl: could not start server
Examine the log output.

下面开始正式重建控制文件,使得数据库可以正常启动。

5. 首先创建一个名为pg_control的空文件

[postgres@lsl-test1 global]$ touch $PGDATA/global/pg_control

6. 使用pg_resetwal修复pg_control

确认pg_resetwal参数值。

首先确认-c参数,上面参数详细分析发现目录下为空,因此暂时忽略此参数。

-e参数是设置下一个事务号的新纪元,我们测试环境没有其它复制系统因此也可以忽略。

-l参数,查看pg_wal下文件文件名,大于文件名最大值即可。

[postgres@lsl-test1 ~]$ cd /pg/pg11/data/pg_wal[postgres@lsl-test1 pg_wal]$ ls -ltotal 32768-rw-------. 1 postgres postgres 16777216 May 30 17:26 000000010000000000000007-rw-------. 1 postgres postgres 16777216 May 30 17:26 000000010000000000000008drwx------. 2 postgres postgres        6 May 17 17:22 archive_status之类要大于最大值,因此我们可以去-l=000000010000000000000009-m参数取pg_multixact/offsets目录下最大值加1然后乘以65536(0x10000)和最小值 乘以65536(0x10000)[postgres@lsl-test1 pg_commit_ts]$ cd ../pg_multixact/offsets/[postgres@lsl-test1 offsets]$ ls -ltotal 8-rwx------. 1 postgres postgres 8192 May 17 18:04 0000

因此-m可以取0x10000,0x00000。

-o参数不确定时,由于测试没有复制软件因此可以暂时忽略。

-O  查找pg_multixact/members目录下数值最大的文件名,+1乘以52352 (0xCC80)。

[postgres@lsl-test1 offsets]$ cd ../members/
[postgres@lsl-test1 members]$ ls -l
total 8
-rwx------. 1 postgres postgres 8192 May 17 17:22 0000

因此-O=0xCC80。

-x参数查找pg_xact目录下可以查看数值最大的文件名,+1乘以 1048576 (0x100000)。

[postgres@lsl-test1 members]$ cd ../../pg_xact/
[postgres@lsl-test1 pg_xact]$ ls -l
total 16
-rwx------. 1 postgres postgres 8192 May 17 18:04 0000
-rw-------. 1 postgres postgres 8192 May 30 17:26 0001

因此-x=0x200000。

不加-f参数时可以查看要写入控制文件中的参数内容。

[postgres@lsl-test1 pg_xact]$ /usr/pgsql-11/bin/pg_resetwal   -l 000000010000000000000009 -m  0x10000,0x00000  -O  0xCC80  -x 0x200000 -D /pg/pg11/data
pg_resetwal: oldest multitransaction ID (-m) must not be 0
[postgres@lsl-test1 pg_xact]$ /usr/pgsql-11/bin/pg_resetwal   -l 000000010000000000000009 -m  0x10000,0x00001  -O  0xCC80  -x 0x200000 -D /pg/pg11/data
pg_resetwal: pg_control exists but is broken or wrong version; ignoring it
Guessed pg_control values:
pg_control version number:            1100
Catalog version number:               201809051
Database system identifier:           6696828635748080009
Latest checkpoint's TimeLineID:       1
Latest checkpoint's full_page_writes: off
Latest checkpoint's NextXID:          0:3
Latest checkpoint's NextOID:          10000
Latest checkpoint's NextMultiXactId:  1
Latest checkpoint's NextMultiOffset:  0
Latest checkpoint's oldestXID:        3
Latest checkpoint's oldestXID's DB:   0
Latest checkpoint's oldestActiveXID:  0
Latest checkpoint's oldestMultiXid:   1
Latest checkpoint's oldestMulti's DB: 0
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
Maximum data alignment:               8
Database block size:                  8192
Blocks per segment of large relation: 131072
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:        1996
Size of a large-object chunk:         2048
Date/time type storage:               64-bit integers
Float4 argument passing:              by value
Float8 argument passing:              by value
Data page checksum version:           0 Values to be changed:
First log segment after reset:        000000010000000000000009
NextMultiXactId:                      65536
OldestMultiXid:                       1
OldestMulti's DB:                     0
NextMultiOffset:                      52352
NextXID:                              2097152
OldestXID:                            2297064448
OldestXID's DB:                       0
If these values seem acceptable, use -f to force reset.
[postgres@lsl-test1 pg_xact]$ cd ../global/
[postgres@lsl-test1 global]$ ls -l pg_control
-rw-r--r--. 1 postgres postgres 0 May 30 17:36 pg_control

7. 启动数据库

确认控制文件参数无误后加上-f会写入到控制文件里。

[postgres@lsl-test1 global]$ /usr/pgsql-11/bin/pg_resetwal   -l 000000010000000000000009 -m  0x10000,0x00001  -O  0xCC80  -x 0x200000 -D /pg/pg11/data  -f
pg_resetwal: pg_control exists but is broken or wrong version; ignoring it
Write-ahead log reset

启动数据库。

[postgres@lsl-test1 global]$ /usr/pgsql-11/bin/pg_ctl  start -D /pg/pg11/data/
waiting for server to start....2019-05-30 22:42:50.946 CST [2471] LOG:  listening on IPv6 address "::1", port 5432
2019-05-30 22:42:50.946 CST [2471] LOG:  listening on IPv4 address "127.0.0.1", port 5432
2019-05-30 22:42:50.949 CST [2471] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2019-05-30 22:42:50.961 CST [2471] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2019-05-30 22:42:50.987 CST [2471] LOG:  redirecting log output to logging collector process
2019-05-30 22:42:50.987 CST [2471] HINT:  Future log output will appear in directory "log".
done
server started

8. 查看测试数据是否正常,然后插入新数据看数据库是否可用。

[postgres@lsl-test1 global]$ psql
psql (11.2)
Type "help" for help.
postgres=# select min(oid),max(oid),count(*) from lsl_oid1 ;       min  |  max   | count
-------+--------+--------
16400 | 116399 | 100000
(1 row)
postgres=# insert into lsl_oid1 select generate_series(100001,200000);
INSERT 0 100000
postgres=#  select min(oid),max(oid),count(*) from lsl_oid1 ;      min  |  max   | count
-------+--------+--------
16384 | 116399 | 200000
(1 row)

数据库可以正常访问。

至此,本文关于Oracle和PostgreSQL的控制文件内容介绍到这里。

原创:李思雷

编辑:肖悦

扩展阅读


  1. 《PostgreSQL 指南:内幕探索》之基础备份与时间点恢复(上)

  2. 《PostgreSQL 指南:内幕探索》之基础备份与时间点恢复(下)

  3. 史上最全PostgreSQL体系结构

  4. “王者对战”之 MySQL 8 vs PostgreSQL 10

  5. 大象起舞:用PostgreSQL解海盗分金问题

  6. 解读年度数据库PostgreSQL:如何巧妙地实现缓冲区管理器

  7. 解读年度数据库PostgreSQL:如何处理并发控制(一)

  8. 数据和云,半年文章精选(文末赠书)

数据和云

ID:OraNews

如有收获,请划至底部,点击“在看”,谢谢!

资源下载

关注公众号:数据和云(OraNews)回复关键字获取

help,30万+下载的完整菜单栏

2019DTCC,数据库大会PPT

2018DTCC , 数据库大会PPT

2018DTC,2018 DTC 大会 PPT

ENMOBK,《Oracle性能优化与诊断案例》

DBALIFE,“DBA 的一天”海报

DBA04,DBA 手记4 电子书

122ARCH,Oracle 12.2体系结构图

2018OOW,Oracle OpenWorld 资料

产品推荐

云和恩墨Bethune Pro2 企业版,集监控、巡检、安全于一身,你的专属数据库实时监控和智能巡检平台,漂亮的不像实力派,你值得拥有!

云和恩墨zData一体机现已发布超融合版本和精简版,支持各种简化场景部署,零数据丢失备份一体机ZDBM也已发布,欢迎关注。

云和恩墨大讲堂 | 一个分享交流的地方

长按,识别二维码,加入万人交流社群

请备注:云和恩墨大讲堂

从Oracle到PostgreSQL:最全控制文件相关推荐

  1. oracle 控制文件在哪里设置_从Oracle到PostgreSQL:最全控制文件

    原文: 从Oracle到PostgreSQL:最全控制文件(上) https://www.enmotech.com/web/detail/1/770/1.html 从Oracle到PostgreSQL ...

  2. ORACLE基础学习-RMAN应用-控制文件恢复

    在NOCATALOG模式下,RMAN创建的备份信息都将保存在目标数据库的控制文件中,所以一旦控制文件丢失,不仅目标数据库崩溃,连RMAN的备份信息也尽数丢失,这种情况下,如果您有控制文件备份,那还有救 ...

  3. Oracle 在 Linux 下移动控制文件步骤

    ①.查看控制文件 [oracle@dbserver ~]$ sqlplus / as sysdba SQL>desc v$controlfile SQL>select * from v$c ...

  4. oracle参数文件备份,备份的控制文件和新的数据文件

    备份的控制文件和新的数据文件 继续上一节的介绍: 我们可以想象,如果控制文件是从备份中恢复的,那么数据库在open过程中又将如何呢? 首先备份控制文件,打开数据库,增进检查点: [oracle@jum ...

  5. oracle断电故障,ORACLE服务器异常断电,控制文件故障的处理步骤

    这里只是简单的记录操作步骤,以做备忘.本步骤由同事邹启健(问心)完成 一.版本 SQL> select * from v$version; BANNER -------------------- ...

  6. Oracle的控制文件

    一.控制文件 oracle的控制文件是极其重要的文件,它是一个较小的二进制文件. 记录了当前数据库的结构信息,同时也包含数据文件及日志文件的信息以及相关的状态,归档信息等等  在参数文件中描述其位置, ...

  7. oracle 控制文件在哪里设置_oracle的controlfile控制文件

    参数文件中定义控制文件位置及个数,建议控制文件放在不同位置,最多可以创建8个,多个控制文件间是镜像的关系. 控制文件包含: 数据库名字及标识 数据库创建的时间戳 表空间名字 数据文件和联机重做日志文件 ...

  8. oracle00214,oracle添加控制文件,ORA-00214: 错误

    今天学习oracle添加控制文件,控制文件是一个二进制文件,记录了物理数据库的当前状态,每一个数据文件只属于一个数据库,为了防止文件损坏丢失等情况,一个数据库不止一个控制文件.一个数据库的控制文件中的 ...

  9. oracle 控制文件在哪里设置_更改Oracle默认的控制文件设置

    环境:Windows XP SP2 32位 Oracle 9.2.0.1 32位 创建数据库后,Oracle默认的3个控制文件都在c:/oracle/oradata/SID/下,3个鸡蛋都在一个篮子里 ...

最新文章

  1. 大规模业务服务器开发总结
  2. AI理论知识基础(22)-逻辑斯蒂映射-伪随机数
  3. python入门之前面内容拾遗
  4. 快速入门MyBatis-Plus,看这一篇就够了。
  5. xampp里mysql的环境变量配置_XAMPP集成环境中MySQL数据库的使用
  6. linux中c表示字符设备文件符号
  7. POJ3348 Cows
  8. python爬虫音乐犯法么_Python爬虫实战之爬取QQ音乐数据!QQ音乐限制太多了
  9. java如何调用webservice_Java如何调用WebService接口
  10. 遇到没有exe文件的驱动
  11. 智能创新引导工具软件——工作量分配和里程碑安排
  12. 基尼不纯度(Gini impurity)
  13. 焦距换算倍率(Focal length ratio)
  14. YOLOv6:又快又准的目标检测框架开源啦
  15. 学长冷月带你怒刷LeetCode之反转链表
  16. 【jQuery】 # jQuery选择器
  17. js插件动态加载js、css解决方案
  18. idea的英文翻译插件安装(Translation)
  19. R语言使用lm函数构建线性回归模型、使用lrtest包的dwtest函数执行残差自相关检验Durbin–Watson检验(p值大于alpha,不存在残差自相关)
  20. 28、无界资本:互联网+时代的资本重生之路

热门文章

  1. 哪种编程语言好找工作_哪种编程语言可以工作? 为了周末?
  2. swift ... .._Swift 2.0是开源的,ApacheCon:大数据,还有更多开源新闻
  3. 组织文化运营_组织可以从开放文化和技术中学到什么
  4. 什么是openstack_谁是OpenStack大使?
  5. python彩票结果分析_天啦噜!Python多线程居然是骗人的?
  6. mysql 存储过程 批量导入数据_sql 利用存储过程批量导入数据
  7. 白盒测试方法_软件测试的种类:白盒测试和黑盒测试
  8. win定时关机_如何让电脑定时自动关机
  9. linux rabbitmq 远程登录
  10. 自定义的plot函数参数date坐标模型[x,y]的使用建议