Oracle的CURRENT REDO丢失，数据丢失风险分析

消失在人海中2026-06-04 22:01

这一:问题说明: Oracle数据库 和 达梦数据库，每天都有定时物理备份，如果分别将Oracle和达梦的所有REDO LOG FILE删除，并关闭实例，为什么Oracle有数据丢失风险，而达梦没有？

Oracle数据库 和 达梦数据库，每天都有定时物理备份，如果分别将Oracle和达梦的所有REDO LOG FILE删除，并关闭实例，为什么Oracle有数据丢失风险，而达梦没有？

二:原因分析:

因为Oracle和达梦在 REDO、归档 处理机制上有根本区别:

达梦数据库：采用"边写边归档"的策略，日志在写入在线日志的同时，也被实时写入归档日志。

Oracle数据库：采用"写满切换再归档"的策略，归档完全依赖于在线日志文件成功切换，是异步进行的。

这就导致了:

达梦：归档日志包含至故障发生前最后一刻的所有事务，可实现零数据丢失。

Oracle：当前在线日志文件损坏，其内容直接丢失，其中记录的所有事务数据永 久丢失。

三:实验验证:

1.达梦数据库启动归档:

SQL> select PARA_NAME,PARA_VALUE,DEFAULT_VALUE from v$dm_ini where para_name LIKE '%ARCH_INI%';

行号 PARA_NAME PARA_VALUE DEFAULT_VALUE

1 ARCH_INI 0 0

已用时间: 7.122(毫秒). 执行号:603.

SQL> Select * from varchstatus;未选定行已用时间:0.809(毫秒).执行号:604.SQL>ALTERDATABASEMOUNT;操作已执行已用时间:2.126(毫秒).执行号:0.SQL>ALTERDATABASEARCHIVELOG;操作已执行已用时间:7.726(毫秒).执行号:0.SQL>ALTERDATABASEADDARCHIVELOG′DEST=/dm8/arch,TYPE=LOCAL,FILESIZE=200,SPACELIMIT=10240′;操作已执行已用时间:1.377(毫秒).执行号:0.SQL>ALTERDATABASEOPEN;操作已执行已用时间:10.472(毫秒).执行号:0.SQL>Select∗fromvarch_status; 未选定行 已用时间: 0.809(毫秒). 执行号:604. SQL> ALTER DATABASE MOUNT; 操作已执行 已用时间: 2.126(毫秒). 执行号:0. SQL> ALTER DATABASE ARCHIVELOG; 操作已执行 已用时间: 7.726(毫秒). 执行号:0. SQL> ALTER DATABASE ADD ARCHIVELOG 'DEST=/dm8/arch, TYPE=LOCAL, FILE_SIZE=200, SPACE_LIMIT=10240'; 操作已执行 已用时间: 1.377(毫秒). 执行号:0. SQL> ALTER DATABASE OPEN; 操作已执行 已用时间: 10.472(毫秒). 执行号:0. SQL> Select * from varchstatus;未选定行已用时间:0.809(毫秒).执行号:604.SQL>ALTERDATABASEMOUNT;操作已执行已用时间:2.126(毫秒).执行号:0.SQL>ALTERDATABASEARCHIVELOG;操作已执行已用时间:7.726(毫秒).执行号:0.SQL>ALTERDATABASEADDARCHIVELOG′DEST=/dm8/arch,TYPE=LOCAL,FILESIZE=200,SPACELIMIT=10240′;操作已执行已用时间:1.377(毫秒).执行号:0.SQL>ALTERDATABASEOPEN;操作已执行已用时间:10.472(毫秒).执行号:0.SQL>Select∗fromvarch_status;

行号 ARCH_TYPE ARCH_DEST ARCH_STATUS ARCH_SRC

1 LOCAL /dm8/arch VALID CJC

已用时间: 1.014(毫秒). 执行号:605.

2.检查REDO信息:

SQL> select GROUP_ID,FILE_ID,PATH from v$rlogfile;

行号 GROUP_ID FILE_ID PATH

1 2 0 /dm8/redo/dm_redo01.log

2 2 1 /dm8/redo/dm_redo02.log

已用时间: 1.034(毫秒). 执行号:601.

SQL> host ls -lrth /dm8/redo/

total 512M

-rw-r--r-- 1 dmdba dinstall 256M May 22 10:19 dm_redo02.log

-rw-r--r-- 1 dmdba dinstall 256M May 22 10:58 dm_redo01.log

3.备份数据库

启动DMAP

root@cjc-db-11 \~# /dm8/dbms/bin/service_template/DmAPService start

Starting DmAPService: Last login: Fri May 22 10:59:21 CST 2026 on pts/2

OK

备份:

SQL> backup database backupset '/dm8/bak/full/20260522';

操作已执行

已用时间: 00:02:39.236. 执行号:615.

4.创建测试数据

SQL> create table cjc.t0522(id int,name varchar(10));

操作已执行

已用时间: 8.151(毫秒). 执行号:616.

SQL> insert into cjc.t0522 values(1,'x');

影响行数 1

已用时间: 0.868(毫秒). 执行号:617.

SQL> commit;

操作已执行

已用时间: 1.036(毫秒). 执行号:618.

SQL> select * from cjc.t0522;

行号 id name

1 1 x

已用时间: 0.897(毫秒). 执行号:619.

5.模拟误删除

dmdba@cjc-db-11 redo$ ls -lrth

total 512M

-rw-r--r-- 1 dmdba dinstall 256M May 22 10:19 dm_redo02.log

-rw-r--r-- 1 dmdba dinstall 256M May 22 14:30 dm_redo01.log

dmdba@cjc-db-11 redo$ rm -f dm_redo0*.log

6.影响范围

短时间内，还可以正常读写数据。

SQL> select * from cjc.t0522;

行号 id name

1 1 x

已用时间: 0.897(毫秒). 执行号:619.

SQL> select * from cjc.t0522;

行号 id name

1 1 x

已用时间: 0.527(毫秒). 执行号:620.

SQL> insert into cjc.t0522 values(2,'y');

影响行数 1

已用时间: 0.517(毫秒). 执行号:621.

SQL> commit;

操作已执行

已用时间: 1.017(毫秒). 执行号:622.

SQL> select * from cjc.t0522;

行号 id name

1 1 x

2 2 y

已用时间: 0.293(毫秒). 执行号:623.

检查文件

SQL> sp_file_sys_check();

DMSQL 过程已成功完成

已用时间: 4.271(毫秒). 执行号:624.

告警日志:

2026-05-22 14:32:56.335 ERROR database P0000002785 T0000000000000003338 EID:49fil_sys check file /dm8/redo/dm_redo01.log fail, Can't find file

2026-05-22 14:32:56.335 ERROR database P0000002785 T0000000000000003338 EID:49fil_sys check file /dm8/redo/dm_redo02.log fail, Can't find file

此时仍然可以读写数据

SQL> select * from cjc.t0522;

行号 id name

1 1 x

2 2 y

已用时间: 0.264(毫秒). 执行号:626.

SQL> insert into cjc.t0522 values(3,'z');

影响行数 1

已用时间: 0.530(毫秒). 执行号:627.

SQL> commit;

操作已执行

已用时间: 1.081(毫秒). 执行号:628.

SQL> select * from cjc.t0522;

行号 id name

1 1 x

2 2 y

3 3 z

已用时间: 0.311(毫秒). 执行号:629.

如果实例没有关闭，可以使用文件句柄进行恢复:

dmdba@cjc-db-11 redo$ ps -ef|grep dms|grep -v grep

dmdba 2785 1 0 12:08 pts/0 00:00:10 /dm8/dbms/bin/dmserver path=/dm8/data/CJC/dm.ini -noconsole

dmdba@cjc-db-11 redo$ ls -lrth /proc/2785/fd|grep dele

lrwx------ 1 dmdba dinstall 64 May 22 10:19 9 -> /dm8/redo/dm_redo02.log (delted)

lrwx------ 1 dmdba dinstall 64 May 22 10:19 8 -> /dm8/redo/dm_redo01.log (delted)

本次主要讲解，实例已经关闭，并且无法启动，通过备份进行恢复

关闭数据库

SQL> shutdown immediate;

操作已执行

已用时间: 1.038(毫秒). 执行号:0.

启动数据库，启动失败

dmdba@cjc-db-11 \~$ DmServiceCJC start

Starting DmServiceCJC: FAILED

后台报错:

026-05-22 14:38:16.108 FATAL database P0000005274 T0000000000000005274 /dm8/redo/dm_redo01.log not exist,can not startup

7.恢复:

覆盖前，备份

dmdba@cjc-db-11 dm8$ cp -r data/ data_bak

还原

RMAN> restore database '/dm8/data/CJC/dm.ini' from backupset '/dm8/bak/full/20260522';

restore database '/dm8/data/CJC/dm.ini' from backupset '/dm8/bak/full/20260522';

Normal of FAST

Normal of DEFAULT

Normal of RECYCLE

Normal of KEEP

Normal of ROLL Percent:100.00%Speed:0.00M/sCost:00:00:53Remaining:00:00:00

restore successfully.

time used: 00:00:53.936

可以看到 restore database会将redo文件还原回来，也就是达梦的backup database会备份redo log file:

dmdba@cjc-db-11 \~$ ls -lrth /dm8/redo/

total 512M

-rw-r--r-- 1 dmdba dinstall 256M May 22 15:12 dm_redo01.log

-rw-r--r-- 1 dmdba dinstall 256M May 22 15:12 dm_redo02.log

8.恢复，这里是完全恢复，和Oracle不同:

RMAN> recover database '/dm8/data/CJC/dm.ini' with archivedir '/dm8/arch';

recover database '/dm8/data/CJC/dm.ini' with archivedir '/dm8/arch';

Database mode = 2, oguid = 0

Normal of FAST

Normal of DEFAULT

Normal of RECYCLE

Normal of KEEP

Normal of ROLL

EP0's cur_lsn770990721, file_lsn770990721 Percent:100.00%Speed:0.00PKG/sCost:00:00:00Remaining:00:00:00

recover successfully!

time used: 655.023(ms)

更新db_magic:

RMAN> recover database '/dm8/data/CJC/dm.ini' update db_magic;

recover database '/dm8/data/CJC/dm.ini' update db_magic;

Database mode = 2, oguid = 0

Normal of FAST

Normal of DEFAULT

Normal of RECYCLE

Normal of KEEP

Normal of ROLL

EP0's cur_lsn770996956, file_lsn770996956

recover successfully!

time used: 00:00:01.181

9.启动数据库:启动成功

dmdba@cjc-db-11 \~$ DmServiceCJC start

Starting DmServiceCJC: OK

10.检查数据:数据没有丢失

dmdba@cjc-db-11 \~$ sh conn.sh

服务器LOCALHOST:5238:处于普通打开状态

登录使用时间 : 6.457(ms)

disql V8

SQL> select * from cjc.t0522;

行号 id name

1 1 x

2 2 y

3 3 z

已用时间: 1.297(毫秒). 执行号:501.里写自定义目录标题)

quenceDiagram.html

相关推荐
掉头发的王富贵2 小时前
【StarRocks】极限十分钟入门StarRocks
数据库·sql·mysql
Nturmoils3 小时前
WHERE 条件别凭习惯写，常用查询先跑一遍
数据库
Databend1 天前
在 AWS 中国峰会逛了一天，我在 Databend 展台看到了 Agent 数据基础设施的新思路
数据库·人工智能·agent
ClouGence2 天前
Oracle 数据同步为什么会出现数据不一致？长事务是常被忽略的原因
数据库·后端·oracle
飞将2 天前
从零实现数据库（2）——HashIndex + IndexManager
数据库
Nturmoils3 天前
订单列表慢查询，先看 WHERE、ORDER BY 和 LIMIT
数据库
渣波3 天前
拒绝 SQL 焦虑！手把手带你用 NestJS + Prisma + DTO 写出“防弹”级后端代码
javascript·数据库·后端
倔强的石头_4 天前
KingbaseES 新版MySQL 兼容版体验：旧版迁移 + 功能实测
数据库
倔强的石头_7 天前
《Kingbase护城河》——数据库存储空间全景探测与精细化瘦身实战
数据库
冬奇Lab8 天前
每日一个开源项目（第134篇）：Zvec - 阿里开源的嵌入式向量数据库，向量搜索界的 SQLite
数据库·人工智能·llm
热门推荐
012026年6月AI大模型全景报告：GPT-5.6、Claude Opus 4.8、Gemini 3.5，中美AI三足鼎立谁主沉浮？022026年6月AI行业全景：从百模大战到Agent元年，这30天发生了什么？032026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf04【AI】2026 年具身智能模型和世界模型总结05Claude Code、Codex、Cursor三分天下：2026年AI编程Agent生态全景剖析06飞书长连接_事件订阅（接收消息，审批任务状态变更）07【AI总结】2026年6月 主流国内外大模型总结08GitHub 镜像站点09Trae国际版与国内版深度测评：AI原生IDE的双生花10AI科技热点日报 | 2026年6月1日