广告
返回顶部
首页 > 资讯 > 数据库 >从Oracle到PostgreSQL:最全控制文件
  • 750
分享到

从Oracle到PostgreSQL:最全控制文件

2024-04-02 19:04:59 750人浏览 泡泡鱼
摘要

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

原文:

oraclepostgresql:最全控制文件(上) 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来说,当控制文件损坏无备份的情况下,可以通过手工重建控制文件的方法来恢复控制文件。

具体命令如下图:



从Oracle到PostgreSQL:最全控制文件
您可能感兴趣的文档:

--结束END--

本文标题: 从Oracle到PostgreSQL:最全控制文件

本文链接: https://www.lsjlt.com/news/48528.html(转载时请注明来源链接)

有问题或投稿请发送至: 邮箱/279061341@qq.com    QQ/279061341

本篇文章演示代码以及资料文档资料下载

下载Word文档到电脑,方便收藏和打印~

下载Word文档
猜你喜欢
  • 从Oracle到PostgreSQL:最全控制文件
    原文: 从Oracle到PostgreSQL:最全控制文件(上) https://www.enmotech.com/web/detail/1/770/1.html 从Oracle到PostgreS...
    99+
    2022-10-18
  • Oracle 11g重建控制文件——控制文件全部丢失,从零开始
    控制文件(control file)是一个相当小的文件(最多能增长到64M左右),其中包含Oracle需要的其他文件的一个目录。参数文件告知实例控制文件的位置,控制文件则告知示例数据库和在线重做日志文件...
    99+
    2022-10-18
  • Oracle 从ASM复制文件到文件系统
    工作中,有时需要把文件从ASM中复制到文件系统中或者反过来,做一些维护操作,本文介绍了4种复制文件的的方法:ASMCMD中的cp命令(11g)dbms_file_transfer包rman的convert或...
    99+
    2022-10-18
  • Oracle手工不完全恢复(一):使用当前控制文件
    实验环境 操作系统:CentOS 7.1 数据库:Oracle 11.2.0.4 目录 示例一:基于SCN或时间点的恢复----恢复过去某个时间误删除的表 ...
    99+
    2022-10-18
  • oracle快速拿到重建控制文件语句的方法有哪些
    本篇内容介绍了“oracle快速拿到重建控制文件语句的方法有哪些”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所...
    99+
    2022-10-18
软考高级职称资格查询
编程网,编程工程师的家园,是目前国内优秀的开源技术社区之一,形成了由开源软件库、代码分享、资讯、协作翻译、讨论区和博客等几大频道内容,为IT开发者提供了一个发现、使用、并交流开源技术的平台。
  • 官方手机版

  • 微信公众号

  • 商务合作