redo日志丢失的恢复

最新推荐文章于 2025-02-26 17:05:13 发布
翻译 最新推荐文章于 2025-02-26 17:05:13 发布 · 404 阅读 · 0
文章标签：

#database #数据库 #sql #oracle #system #character

方法一：用命令清空日志组方法

1 正常关闭数据库

SQL> shutdown

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

2 删除所有的重做日志文件

3 启动数据库

SQL> startup

ORACLE 例程已经启动。

Total System Global Area  167772160 bytes

Fixed Size                  1247876 bytes

Variable Size              67110268 bytes

Database Buffers           92274688 bytes

Redo Buffers                7139328 bytes

数据库装载完毕。

ORA-00313: 无法打开日志组 1 (用于线程 1) 的成员

ORA-00312: 联机日志 1 线程 1:

'E:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO01.LOG'

4查看当前日志状态

SQL> select * from v$log;

 

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS

---------- ---------- ---------- ---------- ---------- --- ---------------

FIRST_CHANGE# FIRST_TIME

------------- --------------

         1          1          0   52428800          1 YES UNUSED

       543031 19-5月 -10

 

         3          1          0   52428800          1 YES CLEARING

       519887 18-5月 -10

 

         2          1         50   52428800          1 NO  CURRENT

       563367 19-5月 -10

 

(1)     由于redo01.log不是当前日志，可以对这类非当前日志直接clear，系统会重新自动生成一个重做日志文件

SQL> alter database clear logfile group 1;

数据库已更改。

 

5 继续启动数据库

 

SQL> alter database open;

alter database open

*

第 1 行出现错误:

ORA-00313: 无法打开日志组 2 (用于线程 1) 的成员

ORA-00312: 联机日志 2 线程 1:

'E:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02.LOG'

(2)     发现redo02.log也得恢复，因为redo02.log是当前重做日志文件，尝试直接clear，失败

SQL> alter database clear logfile group 2;

alter database clear logfile group 2

*

第 1 行出现错误:

ORA-00350: 日志 2 (实例 orcl 的日志, 线程 1) 需要归档

ORA-00312: 联机日志 2 线程 1:

'E:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02.LOG'

 

尝试alter database clear unarchived logfile group 2，失败

 

SQL> alter database clear unarchived logfile group 2;

alter database clear unarchived logfile group 2

*

第 1 行出现错误:

ORA-00313: 无法打开日志组 2 (用于线程 1) 的成员

ORA-00312: 联机日志 2 线程 1:

'E:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02.LOG'

ORA-27041: 无法打开文件

OSD-04002: 无法打开文件

O/S-Error: (OS 2) 系统找不到指定的文件。

(3)     从有效的备份中拷贝过来一个redo02.log后

SQL> alter database clear unarchived logfile group 2;

 

数据库已更改。

 

SQL> alter database open;

 

数据库已更改。

 

结论： (1)非当前(current)的未归档日志文件恢复都可以直接alter database clear logfile group n来重新生成，非当前的归档日志文件恢复可以用alter database clear unarchived logfile group n来重新生成；对于当前日志，  归档日志文件恢复必须从有效的备份中复制一个，然后用alter database clear unarchived logfile group n;

 

方法二：用cancel模式恢复数据库

1 关闭数据库

SQL> shutdown

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

2 删除所有重做日志文件

SQL> startup

ORACLE 例程已经启动。

 

Total System Global Area  167772160 bytes

Fixed Size                  1247876 bytes

Variable Size              67110268 bytes

Database Buffers           92274688 bytes

Redo Buffers                7139328 bytes

数据库装载完毕。

ORA-00313: 无法打开日志组 1 (用于线程 1) 的成员

ORA-00312: 联机日志 1 线程 1:

'E:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO01.LOG'

3 用recover命令

SQL> recover database until cancel;

完成介质恢复。

SQL> alter database open;

alter database open

第 1 行出现错误:

ORA-01589: 要打开数据库则必须使用 RESETLOGS 或 NORESETLOGS 选项

 

SQL> alter database open resetlogs;

数据库已更改。

resetlogs是根据控制文件让系统自动重新生成重做日志文件，如果noresetlogs的话，就不会重新生成redo，缺少了文件，数据库无法启动。

 

方法三 通过重新生成控制文件来恢复redo

1 关闭数据库

SQL> shutdown

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

删除所有重做日志文件

2

SQL> startup

ORACLE 例程已经启动。

 

Total System Global Area  167772160 bytes

Fixed Size                  1247876 bytes

Variable Size              67110268 bytes

Database Buffers           92274688 bytes

Redo Buffers                7139328 bytes

数据库装载完毕。

ORA-00313: 无法打开日志组 1 (用于线程 1) 的成员

ORA-00312: 联机日志 1 线程 1:

'E:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO01.LOG'

3

SQL> alter database backup controlfile to trace;

 

数据库已更改。

4

SQL> shutdown immediate

ORA-01109: 数据库未打开

已经卸载数据库。

ORACLE 例程已经关闭。

5修改备份的控制文件中的脚本，如下，保存在E:/create.sql

STARTUP NOMOUNT

CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS  ARCHIVELOG

    MAXLOGFILES 16

    MAXLOGMEMBERS 3

    MAXDATAFILES 100

    MAXINSTANCES 8

    MAXLOGHISTORY 292

LOGFILE

  GROUP 1 'E:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO01.LOG'  SIZE 50M,

  GROUP 2 'E:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02.LOG'  SIZE 50M,

  GROUP 3 'E:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO03.LOG'  SIZE 50M

-- STANDBY LOGFILE

DATAFILE

  'E:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/SYSTEM01.DBF',

  'E:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/UNDOTBS01.DBF',

  'E:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/SYSAUX01.DBF',

  'E:/ORACLE/PRODUCT/10.2.0/ORCL/TEST.DBF'

CHARACTER SET ZHS16GBK

;

6 执行create.sql

SQL> @E:/create.sql

ORACLE 例程已经启动。

 

Total System Global Area  167772160 bytes

Fixed Size                  1247876 bytes

Variable Size              67110268 bytes

Database Buffers           92274688 bytes

Redo Buffers                7139328 bytes

 

控制文件已创建。

7用resetlogs打开数据库

SQL> alter database open resetlogs;

数据库已更改。

 

方法四 修改系统参数方法

 

SQL*Plus: Release 10.2.0.1.0 - Production on 星期三 5月 19 22:44:14 2010

 

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

 

SQL> conn sys/admin as sysdba

已连接。

SQL> conn test/test

已连接。

SQL> select * from test;

 

        ID

----------

         1

         2

         3

         4

         5

         6

 

已选择6行。

 

SQL> insert into test values(7);

 

已创建 1 行。

 

SQL> commit;

 

提交完成。

 

SQL> conn sys/admin as sysdba

已连接。

SQL> shutdown abort;

ORACLE 例程已经关闭。

1 在initorcl.ora里加入_allow_resetlogs_corruption=true

2指定pfile启动数据库到mount

 SQL> startup mount pfile='E:/oracle/product/10.2.0/admin/orcl/pfile/initorcl.ora';

ORACLE 例程已经启动。

 

Total System Global Area  167772160 bytes

Fixed Size                  1247876 bytes

Variable Size              62915964 bytes

Database Buffers           96468992 bytes

Redo Buffers                7139328 bytes

数据库装载完毕。

SQL> alter database open;

alter database open

*

第 1 行出现错误:

ORA-01589: 要打开数据库则必须使用 RESETLOGS 或 NORESETLOGS 选项

 

 

SQL> alter database open resetlogs;

 

数据库已更改。

3 检验数据是否丢失

 

SQL> select * from test.test;

 

        ID

----------

         1

         2

         3

         4

         5

         6

 

已选择6行。

由于执行了shutdown abort，这时候对数据的修改还没有保存到数据文件中，虽然执行了commit，这个时候数据还在联机日志中，等待CKPT触发数据库写进程将数据写入数据文件，redo被删除后，数据也丢失

lyciswaiting
关注
【数据库管理】④重做日志Redo Log
u011868279的博客
03-31 2472
【数据库管理】④重做日志Redo Log
oracle 重做日志（Redo LogBuffer）
睡不醒的每天
08-27 2062
重做日志文件用于记录事务操作所引起的数据的变化，包括回滚段事务表、回滚块、数据块上的事务槽、数据行的变化等，当执行DDL、DML操作时，有LGWR进程将日志缓冲区中与事务相关的重做记录写入到重做日志文件中。当丢失或损坏数据库中的数据时，Oracle会根据redo文件中的记录 恢复丢失的数据。
oracle修改redo路径,Redo Log之二：迁移redo log到不同的存储路径
weixin_30040925的博客
04-03 943
迁移redo log到不同的存储路径实际运维过程中，我们也经常需要迁移redo log到不同的存储路径，或者修改redo log的大小等等，下面整理了两种迁移redo log的方式。1)方案1:停止数据库实例迁移redo loga、 查询数据redo logSQL> select group#,type,memberfrom v$logfile;GROUP# TYPEMEMBER-----...
redo日志文件丢失分情况恢复
shineboy123456的博客
03-29 3166
redo 日志文件丢失分情况恢复
Redo丢失场景和处理方法
weixin_33782386的博客
06-24 148
Redo丢失场景和处理方法 Type of Failure Status Column of V$LOG Action One member failed in multiplexed group N/A Re-create member All members of group INACTIVE Clear logfile All memb...
oracle redo log恢复,REDO LOG 丢失恢复方法小结
weixin_39839018的博客
04-06 1004
一.在shutdown immediate情况下1.SQL> shutdown immediate数据库已经关闭。已经卸载数据库。ORACLE 例程已经关闭。2.删除所有联机日志文件3.SQL> startupORACLE 例程已经启动。Total System Global Area 135338868 bytesFixed Size 453...
Redo丢失的4种情况及处理方法
weixin_tank88921的博客
07-12 1206
FUZZY等于NO，且数据库的终止SCN等于启动SCN等于数据文件SCN，那么可以认为数据库是正常关闭，且在打开数据库之前不需要执行实例恢复或Crash恢复。FUZYY表示模糊性，意思是，该数据文件处于模糊状态，在最近一次CHECKPOINT后，该文件上的数据可能被修改过了，但没来得及更新到该文件上（或者该文件不知道），需要读取日志信息来判断。非正常关闭的当前日志丢失，可能导致数据库启动后的混乱，并可能造成少量数据的丢失。其他情况不会导致数据的丢失。非正常关闭数据库实例，FUZZY字段的值是YES。
数据库ORA-01196故障-归档日志丢失恢复详解
09-09
数据库ORA-01196错误是Oracle数据库在运行归档模式时可能出现的一种故障，通常与数据文件不一致和归档日志丢失或未正确应用有关。这种情况通常发生在数据库需要介质恢复，即由于硬件故障、操作系统崩溃或者如描述中...
Oracle Redo日志损坏挽救详细攻略
weixin_42329915的博客
02-26 1343
Oracle Redo 日志损坏的恢复方法取决于日志的状态。对于 Unused 和 Inactive 状态的日志，通常可以直接清除；Active 状态的日志需要结合归档日志进行恢复；而 Current 状态的日志损坏最为严重，可能需要基于最新的备份进行完整恢复。合理配置日志管理策略，定期备份数据库，并妥善处理归档日志，可以有效降低因日志损坏导致的数据丢失风险。
40 重新回顾redo日志对于事务提交后，数据绝对不会丢失的意义.pdf
04-15
即使在事务提交后发生故障导致数据没有成功写入数据文件，MySQL也可以在系统重启后通过redo日志中的信息将数据恢复到事务提交时的状态。这种机制确保了即使数据库发生非正常关闭，事务所做的更改也不会丢失，从而...
归档模式redo丢失
weixin_34034670的博客
08-27 173
1，redo member 丢失。2，ACTIVE redo 丢失。3，INACTIVE redo 丢失。4，CURRENT redo 丢失。 数据库版本：SQL*Plus: Release 11.2.0.4.0 1，部分redo member 丢失。 SQL> col member format a50; select group#,member...
关于数据库一致改关闭下redo日志文件丢失的处理办法的总结
fuzhangpeng的专栏
10-08 959
数据库一致性关闭(归档和非归档都行) 1. inactive log  在一致性关闭后删除重启时可以在mount下(不丢失数据) alter database clear logfile group n;  alter database open; 2. active log    在一致性关闭后状态会变成inactive(由ARCn归档) 处理方法如 inactive的方式一
oracle丢失redo文件,Oracle丢失的是所有的redo日志组
weixin_39627430的博客
04-04 488
假设Oracle丢失的是所有的redo日志组，分下列几种情况分别处理：Oracle没开归档，一致性关闭数据库Oracle没开归档，非一致性关闭数据库Oracle开归档，一致性关闭数据库Oracle开归档，非一致性关闭数据库一：Oracle没开归档，一致性关闭数据库我做实验的过程中有一个诡异的情况，我先把redo文件从操作系统层面都删除了，但是数据库正常创建表，insert数据，我理解的是当你com...
归档模式下redo丢失或损坏(current状态)
小伟的博客
12-30 1621
归档模式下current logfile丢失或损坏恢复 +++++Session 1 SQL> set linesize 200 pagesize 2000 SQL> col member format a50 SQL> select * from v$log; GROUP#   THREAD#  SEQUENCE#  BYTES  BLOCKSIZE MEMBERS ARC
oracle丢失redo文件,oracle备份－－redo丢失与恢复
weixin_39845461的博客
04-04 822
oracle备份－－redo丢失与恢复一、先阐述下测试环境系统数据库环境：window＋oracle10g R2＋archive模式；模拟Redo文件丢失，数据库在正常关闭的情况发现Redo丢失了；二、测试(1)、倘若丢了一个或多个redo组的一个成员。这种情况最好处理，直接copy其它目录的成员，重新启动数据库即可。此种情况不作太多的说明；(2)、倘若丢失的是一组或两组甚至全部Redo日志丢失，...
mysql redo日志恢复源码_【恢复，1】redo日志恢复的各种情况
weixin_33900697的博客
02-07 414
Recovering After the Loss of Online Redo Log Files If a media failure has affected the online redo logs of a database, then the appropriate recovery procedure depends on the following considerations: ...
redo丢失的各种情况处理
Du.的博客
11-11 2016
redo丢失的各种情况处理
oracle redo01. log,redo01.log恢复问题
weixin_39725650的博客
04-04 823
背景： 在正常oracle11g正常open状态，我操作系统mv 了redo01.log然后rman不知道该怎么恢复。可是通过下面的脚本居然重建了redo01.log我不知道哪一步能重建的.看哪个日志可以知道呢？ps：操作过程如下：SQL> select member from v$logfile;MEMBER-----------------------------------------...
Oracle归档日志丢失怎么恢复
最新发布
07-24
<think>首先，用户的问题是关于“Oracle 归档日志丢失 数据恢复方法”。我需要基于系统指令来构建我的回答。系统指令包括： 1. 所有行内数学表达式使用$...$格式。 2. 独立公式使用$$...$$格式并单独成段。 3. LaTeX语法正确。 4. 使用中文回答。 5. 生成相关问题。 6. 回答中引用的段落末尾自然地添加引用标识，例如[^1]。 用户可见层的指令是：回答结构清晰，帮助用户逐步解决问题，尽量保证回答真实可靠。 参考的站内引用是： - 引用[1]: Oracle 数据库在线重做日志丢失的恢复方法。包括使用备份恢复、日志挖掘恢复和第三方工具恢复。 - 引用[2]: 使用Oracle归档日志文件进行MySQL数据恢复。但这似乎不直接相关，因为用户的问题是关于Oracle自己的归档日志丢失。 用户意图是查找在Oracle数据库归档日志丢失的情况下如何进行数据恢复的方法。 我的回答需要结构化、清晰。我应该： 1. **介绍问题**：解释归档日志丢失的严重性。 2. **逐步解决方法**：提供具体的恢复方法，基于引用[1]。 3. **添加引用标识**：在引用的段落末尾添加[^1]。 4. **生成相关问题**：在最后添加相关问题部分。 5. **使用LaTeX**：如果有数学表达式，使用$...$或$$...$$。但在这个主题中，可能没有太多数学内容。我可以提到一些概念，比如数据库状态，但可能不需要复杂公式。如果有机会，我可以简单提及，但不要强迫。 例如，如果讨论到数据一致性，我可以说数据库状态的一致性方程，但保持简单。比如，$S_{consistent} = \text{恢复后的状态}$，但这可能不必要。最好只在实际需要时使用。 现在，结构化回答： - **开头**：简要介绍归档日志的作用和丢失的后果。 - **主体**：分步描述恢复方法： - 方法1: 使用备份恢复（从备份还原数据库）。 - 方法2: 使用日志挖掘恢复（如果有可用的日志）。 - 方法3: 使用第三方工具恢复。 基于引用[1]。 - **结尾**：总结建议，并强调及时备份的重要性。 - **相关问题**：生成3-5个相关问题。 引用标识：在描述方法时，如果直接引用内容，添加[^1]。 例如："根据Oracle文档，可以使用备份恢复方法[^1]。" 确保使用中文。 生成相关问题： 1. 如何防止Oracle归档日志丢失？ 2. Oracle归档日志丢失后如何最小化数据损失？ 3. 有哪些第三方工具可用于Oracle数据恢复？ 4. 归档日志和在线重做日志的区别是什么？ 5. 在归档日志丢失的情况下，如何验证数据库的完整性？ 现在，草拟回答。</think>### Oracle 归档日志丢失的数据恢复方法 在 Oracle 数据库中，归档日志（Archived Redo Logs）是用于记录数据库事务历史的关键组件。它们支持数据恢复、备份和故障转移。如果归档日志丢失（例如，由于存储故障或人为错误），数据库可能无法恢复到一致状态，导致数据丢失或系统停机。归档日志丢失的严重性取决于丢失的范围：如果只丢失部分日志，恢复可能可行；如果全部丢失，恢复可能依赖于备份。以下介绍几种可靠的恢复方法，基于 Oracle 官方推荐的最佳实践[^1]。 #### 步骤1: 评估损失情况 在开始恢复前，先确认归档日志丢失的范围： - **检查日志状态**：使用 SQL*Plus 或 RMAN (Recovery Manager) 命令检查日志序列号。例如： ```sql SELECT GROUP#, SEQUENCE#, STATUS FROM V$LOG; ``` 如果状态显示为 "UNARCHIVED"，则归档日志已丢失。 - **确定丢失日志的序列号**：记录缺失的日志文件序列号，以指导恢复操作。 - **备份可用性检查**：确保有最近的数据库备份（如全备或增量备）。如果没有备份，恢复难度增加，可能需要第三方工具。 #### 步骤2: 选择并执行恢复方法 根据损失情况和备份可用性，选择以下方法之一。建议在测试环境先验证，再应用到生产库。 1. **使用备份恢复（推荐方法）** 如果存在完整的数据库备份（包括数据文件和控制文件），这是最可靠的方法。步骤如下： - **恢复备份**：使用 RMAN 还原数据库到备份点。 ```bash RMAN> STARTUP MOUNT; RMAN> RESTORE DATABASE; RMAN> RECOVER DATABASE; ``` 此命令会尝试应用可用的归档日志来恢复数据。如果日志丢失，RMAN 会提示错误，此时需要跳过缺失日志。 - **跳过丢失日志**：如果部分归档日志丢失，使用 `UNTIL` 子句恢复到日志丢失前的点。 ```bash RMAN> RECOVER DATABASE UNTIL SEQUENCE <last_valid_sequence>; ``` 这里，`<last_valid_sequence>` 是最后一个有效的日志序列号。恢复后，数据库会处于一致状态，但可能丢失部分事务[^1]。 - **优点**：简单高效，能保证数据库完整性。 - **缺点**：可能导致数据丢失（从备份点到恢复点之间的数据）。 2. **使用日志挖掘恢复（如果部分日志可用）** 如果归档日志未完全丢失（例如，部分日志文件仍存在），可以使用 Oracle 的 LogMiner 工具从剩余日志中提取事务信息。 - **启用 LogMiner**：首先，配置 LogMiner 分析日志文件。 ```sql EXEC DBMS_LOGMNR.ADD_LOGFILE(LOGFILENAME => '/path/to/archived_log.log', OPTIONS => DBMS_LOGMNR.NEW); EXEC DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG); ``` - **挖掘并应用事务**：查询 `V$LOGMNR_CONTENTS` 视图，提取丢失事务的 SQL 语句，然后手动执行以恢复数据。 ```sql SELECT SQL_REDO FROM V$LOGMNR_CONTENTS WHERE SEG_OWNER = 'YOUR_SCHEMA'; ``` 执行输出 SQL 来重做事务。 - **优点**：能恢复部分数据，减少损失。 - **缺点**：耗时且复杂，需要专业知识；如果日志完全丢失，此方法无效[^1]。 3. **使用第三方工具恢复（作为备选方案）** 如果备份和日志挖掘不可行，考虑专业工具（如 Oracle Data Guard、Quest SharePlex 或第三方恢复软件）。这些工具能扫描存储介质，尝试恢复已删除的日志文件。 - **操作步骤**： - 安装工具（如使用 Oracle Data Guard 创建物理备库）。 - 配置工具扫描归档日志存储路径。 - 如果工具成功恢复日志文件，再用 RMAN 应用日志完成恢复。 - **优点**：可能恢复完全丢失的日志。 - **缺点**：成本高（需购买许可），成功率不保证；仅适用于日志文件未被覆盖的情况[^1]。 #### 步骤3: 恢复后验证与预防措施 - **验证数据库完整性**：恢复后，运行检查命令： ```sql ALTER DATABASE OPEN; SELECT * FROM V$DATABASE_BLOCK_CORRUPTION; -- 检查数据块损坏 ``` 如果输出为空，表示数据库一致。 - **预防措施**：为避免未来丢失： - **启用多重归档**：配置多个归档路径（`LOG_ARCHIVE_DEST_n` 参数）。 - **定期备份日志**：使用 RMAN 备份归档日志到异地存储。 - **监控工具**：部署 Oracle Enterprise Manager 实时监控日志状态。 **总结**：归档日志丢失时，优先使用备份恢复（方法1），因为它高效可靠；如果部分日志可用，尝试日志挖掘（方法2）；第三方工具（方法3）作为最后手段。及时备份是防止数据丢失的关键[^1]。如果操作不确定，请联系 Oracle 支持或专业 DBA。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值