注册
【与达梦同行】达梦数据库生产环境业务表误删恢复实战
技术分享/ 文章详情 /

【与达梦同行】达梦数据库生产环境业务表误删恢复实战

Brant 2022/12/29 1657 1 1

测试场景

在日常运维过程中,经常会遇到用户误操作导致的数据被删除,表被意外删除的情况,本次实验模拟生产环境表被误删的情况进行数据恢复。

生产环境为:达梦8主备集群
模拟业务场景:
1、每天晚上有备份
2、备份以来有业务
3、一张业务表被误删除,局部业务受影响
4、其他业务正常运行,不能中断其他业务


一、模拟环境构造

1.创建测试业务表

# 创建一张数据库表 SQL> create table test12(id int,name varchar(64)); 操作已执行 # 做一笔业务 已用时间: 7.033(毫秒). 执行号:600. SQL> insert into test12 values(1,'abcd'); 影响行数 1 已用时间: 0.690(毫秒). 执行号:601. SQL> commit; 操作已执行 已用时间: 1.362(毫秒). 执行号:602.

2.模拟定时全备

SQL> backup database backupset '/dm8/backup/1229'; 操作已执行 已用时间: 00:00:04.719. 执行号:603.

3.模拟业务操作

SQL> insert into test12 values(2,'bcde'); 影响行数 1 已用时间: 0.297(毫秒). 执行号:604. SQL> insert into test12 values(3,'cdef'); 影响行数 1 已用时间: 0.426(毫秒). 执行号:605. SQL> commit; 操作已执行 已用时间: 1.093(毫秒). 执行号:606. SQL> select * from test12; 行号 ID NAME ---------- ----------- ---- 1 1 abcd 2 2 bcde 3 3 cdef 已用时间: 0.642(毫秒). 执行号:729.

4.模拟表被误删除

SQL> drop table test12; 操作已执行 已用时间: 16.602(毫秒). 执行号:607.

二、判断还原点

表被删除后,首先需要确定误操作发生的时间点,需要精确的定位到操作时间才能够保证还原数据的完整性,以下通过两种方式判断误操作的发生时间。

1.归档日志挖掘

使用日志挖掘,数据库必须开了逻辑附加日志(RLOG_APPEND_LOGIC 不等于0 ),否无法挖掘到内容。

SQL> SP_CREATE_SYSTEM_PACKAGES (1,'DBMS_LOGMNR'); SQL> DBMS_LOGMNR.ADD_LOGFILE('/dm8/data/DM01/arch/ARCHIVE_LOCAL1_0x77F2DAFD_EP0_2022-12-29_11-03-32.log'); DMSQL 过程已成功完成 已用时间: 0.503(毫秒). 执行号:734. SQL> DBMS_LOGMNR.START_LOGMNR(OPTIONS=>2048); DMSQL 过程已成功完成 已用时间: 24.503(毫秒). 执行号:735. SQL> SELECT SCN,START_SCN,COMMIT_SCN,TIMESTAMP,START_TIMESTAMP,COMMIT_TIMESTAMP,SQL_REDO FROM V$LOGMNR_CONTENTS where sql_redo like 'drop%'; 行号 SCN TIMESTAMP SQL_REDO ---------- -------------------- -------------------- -------------------- 1 1000053 2022-12-29 12:04:11.045000 drop table test12;

2.sql日志分析

如果没有开启逻辑附加日志,也可以通过sql执行日志进行定位误操作发生时间

[dmdba@localhost log]$ cat dmsql_DMSVR02_20221229_120139.log |grep drop 2022-12-29 12:04:11.037 (EP[0] sess:0x7fbe44016050 thrd:2552 user:SYSDBA trxid:2133553 stmt:0x7fbe4403a048 appname:disql ip:::1) [ORA]: drop table test12; 2022-12-29 12:04:11.037 (EP[0] sess:0x7fbe44016050 thrd:2552 user:SYSDBA trxid:2133553 stmt:0x7fbe4403a048 appname:disql ip:::1) [DDL] drop table test12; 2022-12-29 12:04:11.052 (EP[0] sess:0x7fbe44016050 thrd:2552 user:SYSDBA trxid:0 stmt:0x7fbe4403a048 appname:disql ip:::1) [DDL] drop table test12; EXECTIME: 9(ms). [dmdba@localhost log]$

通过以上两种方式,我们就可以定位到误操作发生时间为:2022-12-29 12:04:11.037,对应的LSN号为:1000053


三、新实例进行数据还原

因为生产环境业务还在运行,不能够直接还原到生产库。一是不能够停库,二是直接在生产库还原会导致其他的正常的业务数据被覆盖,我们需要在服务器上临时重新初始化一个新的实例进行还原。

1.初始化一个新的实例

生产端口是5236,在5237端口重新初始化一个实例,参数与生产环境相同

[dmdba@localhost bin]$ ./dminit path=/dm8/data1/ DB_NAME=DM02 INSTANCE_NAME=DMSVR02 PORT_NUM=5237 page_size=16 extent_size=32 CASE_SENSITIVE=1 log_size=500 initdb V8 db version: 0x7000c file dm.key not found, use default license! License will expire on 2023-06-30 Normal of FAST Normal of DEFAULT Normal of RECYCLE Normal of KEEP Normal of ROLL log file path: /dm8/data1/DM02/DM0201.log log file path: /dm8/data1/DM02/DM0202.log write to dir [/dm8/data1/DM02]. create dm database success. 2022-12-29 14:15:45 # #前台启动数据库,确认实例是否初始化正常。 [dmdba@localhost bin]$ ./dmserver /dm8/data1/DM02/dm.ini #退出实例准备数据还原

2.数据库还原

进行还原操作,recover 操作中可以使用基于时间也可以使用基于LSN,LSN相对更加精确,能获取到LSN优先使用LSN。
UNTIL TIME ‘2022-12-29 12:04:11’;
UNTIL LSN 1000050;

注意归档日志的路径是生产环境的归档日志路径,不要写成新初始实例的归档路径。

./dmrman restore database '/dm8/data1/DM02/dm.ini' from backupset '/dm8/backup/1229'; recover database '/dm8/data1/DM02/dm.ini' WITH ARCHIVEDIR '/dm8/data/DM01/arch' UNTIL LSN 1000050; recover database '/dm8/data1/DM02/dm.ini' update db_magic;

3.确认还原情况

[dmdba@localhost bin]$ ./disql SYSDBA/DM01SYSDBA@localhost:5237 服务器[localhost:5237]:处于主库配置状态 登录使用时间 : 3.802(ms) disql V8 SQL> alter database normal; 操作已执行 已用时间: 40.975(毫秒). 执行号:0. SQL> alter database open; 操作已执行 已用时间: 28.563(毫秒). 执行号:0. SQL> select * from test12; 行号 ID NAME ---------- ----------- ---- 1 1 abcd 2 2 bcde 3 3 cdef 已用时间: 0.801(毫秒). 执行号:500. SQL> exit

四、还原到生产环境

1.从新实例导出数据

[dmdba@localhost bin]$ ./dexp SYSDBA/DM01SYSDBA@localhost:5237 file='test12.dmp' DIRECTORY=/dm8 TABLES=TEST12; dexp V8 ----- [2022-12-29 14:35:44]导出表:TEST12 ----- 导出模式下的对象权限... 表TEST12导出结束,共导出 3 行数据 整个导出过程共花费 0.264 s 成功终止导出, 没有出现警告

2.导入数据到生产环境

导入前如果生产环境已经生成了表,建议对表进行备份后再进行导入。

[dmdba@localhost bin]$ ./dimp SYSDBA/DM01SYSDBA file='test12.dmp' DIRECTORY=/dm8 TABLE_EXISTS_ACTION=APPEND dimp V8 本地编码:PG_UTF8, 导入文件编码:PG_GB18030 ----- [2022-12-29 14:42:19]导入表:TEST12 ----- 创建表 TEST12 ... 导入表 TEST12 的数据:3 行被处理 整个导入过程共花费 0.107 s 成功终止导入, 没有出现警告

3.生产环境确认验证

[dmdba@localhost bin]$ ./disql SYSDBA/DM01SYSDBA 服务器[LOCALHOST:5236]:处于主库打开状态 登录使用时间 : 3.185(ms) disql V8 SQL> select * from test12; 行号 ID NAME ---------- ----------- ---- 1 1 abcd 2 2 bcde 3 3 cdef 已用时间: 0.979(毫秒). 执行号:1100. SQL>

到此数据还原成功

评论
后发表回复

作者

文章

阅读量

获赞

扫一扫
联系客服