标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (102)
- 数据库 (1,670)
- DB2 (22)
- MySQL (73)
- Oracle (1,532)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (21)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (14)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (65)
- Oracle Bug (8)
- Oracle RAC (52)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (560)
- Oracle安装升级 (91)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (78)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- ORA-600 krse_arc_complete.4
- Oracle 19c 202410补丁(RUs+OJVM)
- ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复
- .mkp扩展名oracle数据文件加密恢复
- 清空redo,导致ORA-27048: skgfifi: file header information is invalid
- A_H_README_TO_RECOVER勒索恢复
- 通过alert日志分析客户自行对一个数据库恢复的来龙去脉和点评
- ORA-12514: TNS: 监听进程不能解析在连接描述符中给出的SERVICE_NAME
- ORA-01092 ORA-00604 ORA-01558故障处理
- ORA-65088: database open should be retried
- Oracle 19c异常恢复—ORA-01209/ORA-65088
- ORA-600 16703故障再现
- 数据库启动报ORA-27102 OSD-00026 O/S-Error: (OS 1455)
- .[metro777@cock.li].Elbie勒索病毒加密数据库恢复
- 应用连接错误,初始化mysql数据库恢复
- RAC默认服务配置优先节点
- Oracle 19c RAC 替换私网操作
- 监听报TNS-12541 TNS-12560 TNS-00511错误
- drop tablespace xxx including contents恢复
- Linux 8 修改网卡名称
标签归档:pg_filedump
PostgreSQL恢复系列:pg_filedump批量处理
pg_filedump工具使用起来比较麻烦,主要存在问题:
1. 需要人工一个个枚举各个列类型无法实现批量恢复,参考以前写的PostgreSQL恢复系列:pg_filedump基本使用
2. 特别是在pg库无法正常运行的情况下,如果没有业务提供表创建语句,恢复基本上无法正常进行.
基于这两个问题,在以前的文章中写过PostgreSQL恢复系列:pg_filedump恢复字典构造,为了解决上述的两个,弄了一个pg_filedump_batch脚本实现批量恢复需求
在测试的pg库中创建了一些测试表,并查看部分表数据,便于对比后续恢复效果
postgres=# \d List of relations Schema | Name | Type | Owner --------+----------------+-------+---------- public | t_tbs | table | postgres public | t_xff | table | postgres public | t_xff2 | table | postgres public | t_xff3 | table | postgres public | t_xff4 | table | postgres public | t_xifenfei | table | postgres public | tab_attribute | table | postgres public | tab_class | table | postgres public | tab_database | table | postgres public | tab_namespace | table | postgres public | tab_tablespace | table | postgres public | tab_type | table | postgres (12 rows) postgres=# select * from tab_database; oid | datname | datdba | encoding | datcollate | datctype | datistemplate | datallowconn | datconnlimit | datlastsysoi d | datfrozenxid | datminmxid | dattablespace -------+-------------+--------+----------+-------------+-------------+---------------+--------------+--------------+------------- --+--------------+------------+--------------- 14187 | postgres | 10 | 6 | en_US.UTF-8 | en_US.UTF-8 | f | t | -1 | 1418 6 | 479 | 1 | 1663 16403 | db_xff | 10 | 6 | en_US.UTF-8 | en_US.UTF-8 | f | t | -1 | 1418 6 | 479 | 1 | 1663 1 | template1 | 10 | 6 | en_US.UTF-8 | en_US.UTF-8 | t | t | -1 | 1418 6 | 479 | 1 | 1663 14186 | template0 | 10 | 6 | en_US.UTF-8 | en_US.UTF-8 | t | f | -1 | 1418 6 | 479 | 1 | 1663 16407 | db_xifenfei | 16405 | 6 | en_US.UTF-8 | en_US.UTF-8 | f | t | -1 | 1418 6 | 479 | 1 | 16406 (5 rows) postgres=# select count(1) from tab_class; count ------- 407 (1 row) postgres=# select *from pg_tablespace; oid | spcname | spcowner | spcacl | spcoptions -------+--------------+----------+--------+------------ 1663 | pg_default | 10 | | 1664 | pg_global | 10 | | 16406 | tbs_xifenfei | 16405 | | (3 rows)
使用pg_filedump_bath脚本来实现批量恢复
[root@xifenfei tmp]# ./pg_filedump_batch recover --database-oid=14187 \ --output-directory=/data/recovery --pgdata=/var/lib/pgsql/12/data Recover tables in database with oid: 14187 LOG: starting to process table tab_attribute LOG: starting to process table tab_class LOG: starting to process table tab_database LOG: starting to process table tab_namespace LOG: starting to process table tab_tablespace LOG: starting to process table tab_type LOG: starting to process table t_tbs LOG: starting to process table t_xff LOG: starting to process table t_xff2 LOG: starting to process table t_xff3 LOG: starting to process table t_xff4 LOG: starting to process table t_xifenfei Check dumps in /data/recovery
参考数据恢复
[root@xifenfei tmp]# cd /data/recovery/ [root@xifenfei recovery]# ls -ltr total 156 -rw-r--r-- 1 root root 82797 Apr 18 20:35 recovered-14187-tab_attribute.csv -rw-r--r-- 1 root root 31129 Apr 18 20:35 recovered-14187-tab_class.csv -rw-r--r-- 1 root root 343 Apr 18 20:35 recovered-14187-tab_database.csv -rw-r--r-- 1 root root 118 Apr 18 20:35 recovered-14187-tab_namespace.csv -rw-r--r-- 1 root root 50 Apr 18 20:35 recovered-14187-tab_tablespace.csv -rw-r--r-- 1 root root 7907 Apr 18 20:35 recovered-14187-tab_type.csv -rw-r--r-- 1 root root 0 Apr 18 20:35 recovered-14187-t_tbs.csv -rw-r--r-- 1 root root 38 Apr 18 20:35 recovered-14187-t_xff.csv -rw-r--r-- 1 root root 38 Apr 18 20:35 recovered-14187-t_xff2.csv -rw-r--r-- 1 root root 38 Apr 18 20:35 recovered-14187-t_xff3.csv -rw-r--r-- 1 root root 38 Apr 18 20:35 recovered-14187-t_xff4.csv -rw-r--r-- 1 root root 38 Apr 18 20:35 recovered-14187-t_xifenfei.csv [root@xifenfei recovery]# cat recovered-14187-tab_database.csv 14187 postgres 10 6 en_US.UTF-8 en_US.UTF-8 f t -1 14186 479 1 1663 16403 db_xff 10 6 en_US.UTF-8 en_US.UTF-8 f t -1 14186 479 1 1663 1 template1 10 6 en_US.UTF-8 en_US.UTF-8 t t -1 14186 479 1 1663 14186 template0 10 6 en_US.UTF-8 en_US.UTF-8 t f -1 14186 479 1 1663 16407 db_xifenfei 16405 6 en_US.UTF-8 en_US.UTF-8 f t -1 14186 479 1 16406 [root@xifenfei recovery]# cat recovered-14187-tab_class.csv|wc -l 407 [root@xifenfei recovery]# cat recovered-14187-tab_tablespace.csv 1663 pg_default 1664 pg_global 16406 tbs_xifenfei
把pg_class恢复数据导入库中进行对比,证明恢复的数据完全正确
postgres=# COPY tab_class_new FROM '/data/recovery/recovered-14187-tab_class.csv'; COPY 407 postgres=# select count(1) from tab_class; count ------- 407 (1 row) count ------- 407 (1 row) postgres=# select count(1) from tab_class_new; count ------- 407 (1 row) postgres=# select * from tab_class_new postgres-# EXCEPT postgres-# select * from tab_class; oid | relname | relnamespace | reltype | reloftype | relowner | relam | relfilenode | reltablespace | relpages | reltuples | rel allvisible | reltoastrelid | relhasindex | relisshared | relpersistence | relkind -----+---------+--------------+---------+-----------+----------+-------+-------------+---------------+----------+-----------+---- -----------+---------------+-------------+-------------+----------------+--------- (0 rows) postgres=# select * from tab_class postgres-# EXCEPT postgres-# select * from tab_class_new; oid | relname | relnamespace | reltype | reloftype | relowner | relam | relfilenode | reltablespace | relpages | reltuples | rel allvisible | reltoastrelid | relhasindex | relisshared | relpersistence | relkind -----+---------+--------------+---------+-----------+----------+-------+-------------+---------------+----------+-----------+---- -----------+---------------+-------------+-------------+----------------+--------- (0 rows)
通过上述操作证明:
1. 在没有人工列出列类型的情况下实现批量pg_filedump恢复功能
2. 在pg库没有启动的情况下直接解析字典实现恢复功能
3. 实现pg数据库的批量恢复
如果有PostgreSQL的数据库故障,自行无法解决,请联系我们提供专业数据库恢复技术支持:
电话/微信:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
PostgreSQL恢复系列:pg_filedump基本使用
当PostgreSQL遇到重大故障,使用各种方法都无法直接启动数据库,可以考虑使用类似oracle dul工具,直接离线方式读取文件进行恢复.这个工具为pg_filedump
pg_filedump安装
[root@xifenfei ~]# yum install pg_filedump_14.x86_64 Loaded plugins: langpacks, ulninfo Resolving Dependencies --> Running transaction check ---> Package pg_filedump_14.x86_64 0:14.1-1.rhel7 will be installed --> Finished Dependency Resolution Dependencies Resolved ====================================================================================================================== Package Arch Version Repository Size ====================================================================================================================== Installing: pg_filedump_14 x86_64 14.1-1.rhel7 pgdg14 43 k Transaction Summary ====================================================================================================================== Install 1 Package Total download size: 43 k Installed size: 81 k Is this ok [y/d/N]: y Downloading packages: pg_filedump_14-14.1-1.rhel7.x86_64.rpm | 43 kB 00:00:02 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : pg_filedump_14-14.1-1.rhel7.x86_64 1/1 Verifying : pg_filedump_14-14.1-1.rhel7.x86_64 1/1 Installed: pg_filedump_14.x86_64 0:14.1-1.rhel7 Complete! -bash-4.2$ pg_filedump Version 14.1 (for PostgreSQL 8.x .. 14.x) Copyright (c) 2002-2010 Red Hat, Inc. Copyright (c) 2011-2022, PostgreSQL Global Development Group Usage: pg_filedump [-abcdfhikxy] [-R startblock [endblock]] [-D attrlist] [-S blocksize] [-s segsize] [-n segnumber] file Display formatted contents of a PostgreSQL heap/index/control file Defaults are: relative addressing, range of the entire file, block size as listed on block 0 in the file The following options are valid for heap and index files: -a Display absolute addresses when formatting (Block header information is always block relative) -b Display binary block images within a range (Option will turn off all formatting options) -d Display formatted block content dump (Option will turn off all other formatting options) -D Decode tuples using given comma separated list of types Supported types: bigint bigserial bool char charN date float float4 float8 int json macaddr name numeric oid real serial smallint smallserial text time timestamp timestamptz timetz uuid varchar varcharN xid xml ~ ignores all attributes left in a tuple -f Display formatted block content dump along with interpretation -h Display this information -i Display interpreted item details -k Verify block checksums -o Do not dump old values. -R Display specific block ranges within the file (Blocks are indexed from 0) [startblock]: block to start at [endblock]: block to end at A startblock without an endblock will format the single block -s Force segment size to [segsize] -t Dump TOAST files -v Ouput additional information about TOAST relations -n Force segment number to [segnumber] -S Force block size to [blocksize] -x Force interpreted formatting of block items as index items -y Force interpreted formatting of block items as heap items The following options are valid for control files: -c Interpret the file listed as a control file -f Display formatted content dump along with interpretation -S Force block size to [blocksize] Additional functions: -m Interpret file as pg_filenode.map file and print contents (all other options will be ignored) Report bugs to <pgsql-bugs@postgresql.org>
创建测试表
-bash-4.2$ psql psql (14.3) Type "help" for help. postgres=# create table pg_xifenfei(id int,name varchar(100)); CREATE TABLE postgres=# insert into pg_xifenfei values(1,'www.xifenfei.com'); INSERT 0 1 postgres=# insert into pg_xifenfei values(2,'xienfei_pg_recovery'); INSERT 0 1 postgres=# select * from pg_xifenfei; id | name ----+--------------------- 1 | www.xifenfei.com 2 | xienfei_pg_recovery (2 rows) postgres=#
pg_filedump恢复数据
-bash-4.2$ pg_filedump /var/lib/pgsql/14/data/base/14487/16384 ******************************************************************* * PostgreSQL File/Block Formatted Dump Utility * * File: /var/lib/pgsql/14/data/base/14487/16384 * Options used: None ******************************************************************* Block 0 ******************************************************** <Header> ----- Block Offset: 0x00000000 Offsets: Lower 32 (0x0020) Block: Size 8192 Version 4 Upper 8096 (0x1fa0) LSN: logid 0 recoff 0x16299cf0 Special 8192 (0x2000) Items: 2 Free Space: 8064 Checksum: 0x0000 Prune XID: 0x00000000 Flags: 0x0000 () Length (including item array): 32 <Data> ----- Item 1 -- Length: 45 Offset: 8144 (0x1fd0) Flags: NORMAL Item 2 -- Length: 48 Offset: 8096 (0x1fa0) Flags: NORMAL *** End of File Encountered. Last Block Read: 0 *** -bash-4.2$ pg_filedump -D int,charn /var/lib/pgsql/14/data/base/14487/16384|grep COPY COPY: 1 www.xifenfei.com COPY: 2 xienfei_pg_recovery -bash-4.2$ pg_filedump -D int,charn /var/lib/pgsql/14/data/base/14487/16384|grep COPY > |awk '{$1=null;print $0}'>/tmp/pg_xifenfei_rec -bash-4.2$ sed -i 's/^[ ]*//g' /tmp/pg_xifenfei_rec
导入数据验证
postgres=# truncate table pg_xifenfei; TRUNCATE TABLE postgres=# select * from pg_xifenfei; id | name ----+------ (0 rows) postgres=# copy pg_xifenfei from '/tmp/pg_xifenfei_rec'(DELIMITER ' '); COPY 2 postgres=# select * from pg_xifenfei; id | name ----+--------------------- 1 | www.xifenfei.com 2 | xienfei_pg_recovery (2 rows)
通过上述简单测试证明,在PG数据库出现极端情况下,可以使用该方法进行最后的数据恢复,减少因为数据丢失带来的损失.