在线日志损坏恢复过程
重做日志文件丢失的恢复
重做日志文件丢失的恢复重做日志文件是ORACLE数据库不可缺少的组成部分，Oracle服务器将对数据库所有更改按顺序记录到重做日志缓冲区中，LGWR进程把重做条目从重做日志缓冲区写入联机重做日志文件中，在发生介质故障时，会提供恢复机制，这也是ORACLE数据库保证数据安全的一种手段。
在真实的环境中，可能会因为误删除或其他原因，丢失了重做日志文件，如果数据库在启动时检测到重做日志丢失，数据库将无法启动。
如果数据库在运行时切换日志文件组，检测到下一组或者全部的重做日志丢失，数据库将会崩溃。
所以有必要学习下Oracle重做日志恢复的技巧。
以下是模拟了一些丢失重做日志文件场景恢复过程，以供参考。
丢失非活动日志文件的恢复如果丢失的日志文件组状态为‘INACTIVE’,说明该日志组已经完成检查点，数据库不会发生数据丢失，但是千万不能够忽视，因为当日志切换到该日志组时会发生错误。
恢复的方法有很多种，以下罗列了三种方法：测试环境SQL> select * from v$version;BANNER--------------------------------------------------------------------------------Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - ProductionPL/SQL Release 11.1.0.6.0 - ProductionCORE 11.1.0.6.0 ProductionTNS for Linux: Version 11.1.0.6.0 - ProductionNLSRTL Version 11.1.0.6.0 – ProductionSQL> select group#,members,status from v$log;GROUP# MEMBERS STATUS---------- ---------- ----------------1 2 INACTIVE2 1 CURRENT3 2 INACTIVE模拟故障[oracle@my linux2 ~]$ rm /u01/oradata/orcl/redo01.log当数据库日志切换到该日志组后，发现日志文件不存在，数据库将会崩溃，除了DBA外其他用户都不能连接到数据库。
数据库数据文件和日志文件异常的修复方法
意外 掉 电或 者强 制 关 机 导致 数据 文件 损 坏 ； 件 硬
损坏 造成 数据 文件 写错 误 ； 数据 文件 被误 删 ； 数据
ＢＡＫ ’ Ｗ Ｉ ＴＨ ＮＯ
—
Ｔ Ｕ Ｃ Ｔ ” 进 行 数 据 库 的事 ＲＮＡＥ ，
务 日志备 份 。
文件 被更 改 了名字 或者 后缀 等 等 。 ２ 事 务 日志文 件 问题 导 致 的数 据 库 不 可 用 。 ） 比如 事务 日志 文件 丢失 ； 务 日志文 件被 损坏 ； 事 事 务 Ｅ志文 件被误 删 ； ｌ 事务 日志文件 过 大 ， 致硬 盘 导
损坏 。 １ ）在 查 询 分 析 器 中 执 行 语 句 ： Ｂ Ｃ Ｕ “ＡＫ Ｐ
ＬＯＧ ＺＤＨＧＬ ＴＯ ＤＩ Ｋ ＝ ｆ ｜ Ｓ Ｅ ＤＢ ｜ ＺＤＨＧＬ ＬＯＧ
—
障记 录数 据 库 ｚｈｌ 建 模 拟 环 境 ， 步 一 步 地 ｄｇ 搭 一
将 处 于各种 异 常 的数据库 恢 复至 正常 可用 状态 。 ｌ 数据 库 故障现 象 １ 数 据 文 件 问 题 导 致 的 数 据 库 异 常 。 比 如 ）
志文件被 损 坏或 误删 ， 而导 致 了数 据 库 不能 正常使 用 ， 中给 出 了相 对应 的解 决方 法 。 实践 从 文 证 明这 些 解决 方法安 全 可靠 ， 并且 能够 达 到修 复异 常 Ｓ ＬＳｒｅ ００数据 库 的 目的 。 Ｑ ｅｖｒ ０ ２
关 键词 ： 数据 文件 ； 日志 文件 ； 份 ； 复 备 恢
（ ｑ ｉ ｎ ｅ ａｔ ｅ ｔ ｆ ｉ ａ ｒｎ＆ Ｓｅ ｌ ｏ ， ａｊ ｇ２ ０ ３ Ｅ ｕｐ ｍｅ ｔ ｐｒ ｎ ｏ ｓ ｎＩ Ｄ ｍ Ｍｅ ｈ ｏ ｔ ． Ｎ ｎｉ １０ ９） ｅＣ ｎ
电脑出现文件丢失或损坏如何进行恢复
电脑出现文件丢失或损坏如何进行恢复在我们日常使用电脑的过程中，可能会遇到文件丢失或损坏的情况，这无疑会给我们带来很大的困扰。
无论是工作中的重要文档，还是珍贵的照片、视频等，丢失或损坏都可能造成无法挽回的损失。
那么，当遇到这种情况时，我们应该如何进行恢复呢？首先，我们需要了解文件丢失或损坏的常见原因。
病毒或恶意软件的攻击是其中之一，它们可能会篡改或删除我们的文件。
系统故障，比如突然断电、系统崩溃等，也可能导致正在处理的文件丢失或损坏。
此外，误操作也是一个常见的原因，比如不小心删除了文件、格式化了磁盘等。
当发现文件丢失或损坏后，先不要惊慌失措。
第一步，立即停止对电脑的任何写入操作。
这是因为新的数据写入可能会覆盖掉原本丢失或损坏的文件，从而降低恢复的可能性。
接下来，我们可以尝试从回收站中找回误删除的文件。
打开回收站，查找所需的文件，然后右键点击选择“还原”。
但要注意，如果已经清空了回收站，这种方法就不适用了。
如果回收站中没有找到，我们可以利用系统自带的文件历史记录功能。
在Windows 系统中，打开“控制面板”，找到“文件历史记录”选项。
前提是您之前已经开启了这个功能，并且系统有对文件的备份，就有可能在这里找到丢失或损坏的文件并进行恢复。
对于一些比较重要的文件，我们还可以检查是否有定期的备份。
如果有将文件备份到外部存储设备（如移动硬盘、U 盘）或者云存储服务（如百度网盘、OneDrive 等），那么直接从备份中恢复即可。
如果以上方法都不奏效，我们就需要借助专业的数据恢复软件了。
市面上有很多数据恢复软件可供选择，如 Recuva、EaseUS Data Recovery Wizard、Disk Drill 等。
这些软件的操作方法大致相似，下面以 Recuva 为例进行介绍。
首先，下载并安装 Recuva 软件。
打开软件后，会出现一个向导界面，引导您选择要恢复的文件类型（如文档、图片、视频等）以及文件所在的位置（如硬盘分区、U 盘等）。
数据备份与恢复35562.学习情景5 任务2 日志文件损坏的修复
3
sp_dboption @dbname,'single user','true'
4
dbcc checktable('数据表名称',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable('数据表名称',REPAIR_REBUILD)
5
sp_dboption @dbname,'single user','true'
dbcc checkdb(@databasename,REPAIR_REBUILD)
5
sp_dboption @databasename, N'single', N'false'
6
四、相关知识-用DBCC修复数据表
declare @databasename varchar(255)
1
set @dbname=‘要修复数据表名称'
五、按照工作任务单完成工作任务
一、在SQL Server Management Studio停止数据库服务，因为不停止数据 库的服务，将无法数据文件和日志文件进行拷贝
五、按照工作任务单完成工作任务
二、将需要恢复的数据库文件复制到另外的位置,重新启动数据库服务,再在 SQL Server Management Studio中删除要恢复的数据库
'database_name'代表被检测的数据库实体
名；
NOINDEX指非系统表的非聚族索引不检测； REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST| REPAIR_REBUILD 指直接修复发现的错误， 其中REPAIR_ALLOW_DATA_LOSS代表，若此
MySQL数据库INNODB表损坏修复处理过程分享
MySQL数据库INNODB表损坏修复处理过程分享突然收到MySQL报警，从库的数据库挂了，⼀直在不停的重启，打开错误⽇志，发现有张表坏了。
innodb表损坏不能通过repair table 等修复myisam 的命令操作。
现在记录下解决过程，下次遇到就不会这么⼿忙脚乱了。
⼀遇到报警之后，直接打开错误⽇志，⾥⾯的信息：InnoDB: Database page corruption on disk or a failedInnoDB: file read of page 30506.InnoDB: You may have to recover from a backup.130509 20:33:48 InnoDB: Page dump in ascii and hex (16384 bytes):##很多⼗六进制的代码…………InnoDB: End of page dump130509 20:37:34 InnoDB: Page checksum 1958578898, prior-to-4.0.14-form checksum 3765017239InnoDB: stored checksum 3904709694, prior-to-4.0.14-form stored checksum 3765017239InnoDB: Page lsn 5 614270220, low 4 bytes of lsn at page end 614270220InnoDB: Page number (if stored to page already) 30506,InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 19InnoDB: Page may be an index page where index id is 54InnoDB: (index "PRIMARY" of table "maitem"."email_status")InnoDB: Database page corruption on disk or a failedInnoDB: file read of page 30506.InnoDB: You may have to recover from a backup.InnoDB: It is also possible that your operatingInnoDB: system has corrupted its own file cacheInnoDB: and rebooting your computer removes theInnoDB: error.InnoDB: If the corrupt page is an index pageInnoDB: you can also try to fix the corruptionInnoDB: by dumping, dropping, and reimportingInnoDB: the corrupt table. You can use CHECKInnoDB: TABLE to scan your table for corruption.InnoDB: See also /doc/refman/5.5/en/forcing-innodb-recovery.htmlInnoDB: about forcing recovery.InnoDB: A new raw disk partition was initialized orInnoDB: innodb_force_recovery is on: we do not allowInnoDB: database modifications by the user. Shut downInnoDB: mysqld and edit f so that newraw is replacedInnoDB: with raw, and innodb_force_... is removed.130509 20:39:35 [Warning] Invalid (old?) table or database name '#sql2-19c4-5'从错误⽇志⾥⾯很清楚的知道哪⾥出现了问题，该怎么处理。
web日志故障案例
web日志故障案例Web日志故障案例：1. 网站出现503错误在访问网站时，出现了503错误。
这是一种服务器错误，表示服务器暂时无法处理请求。
造成这个错误的原因可能是服务器过载、维护或升级等。
解决办法可以是等待一段时间后再次尝试访问，或者联系网站管理员寻求帮助。
2. 日志文件丢失在分析网站日志时，发现某些时间段的日志文件丢失了。
这可能是由于文件系统故障、人为删除或被恶意软件删除等原因导致的。
解决办法可以是恢复备份的日志文件，或者尝试使用数据恢复工具来恢复丢失的日志文件。
3. 日志记录异常在分析网站日志时，发现部分日志记录异常，包括记录内容不完整、时间戳错误等。
这可能是由于日志记录系统配置错误、日志文件损坏或其他原因导致的。
解决办法可以是检查日志记录系统的配置，修复损坏的日志文件，或者更新日志记录系统。
4. 日志文件过大在分析网站日志时，发现日志文件过大，超过了系统的处理能力。
这可能是由于日志记录级别设置过高、日志文件没有定期清理等原因导致的。
解决办法可以是调整日志记录级别，定期清理过期的日志文件，或者使用日志切割工具将日志文件拆分为多个较小的文件。
5. 日志记录频率过高在分析网站日志时，发现日志记录频率异常高，可能是每秒钟记录数达到了上万条。
这可能是由于恶意攻击、爬虫行为或其他原因导致的。
解决办法可以是增加服务器的处理能力，限制请求频率，或者使用防火墙等安全措施来阻止恶意行为。
6. 日志记录格式错误在分析网站日志时，发现部分日志记录的格式错误，无法正常解析。
这可能是由于日志记录系统配置错误、日志文件损坏或其他原因导致的。
解决办法可以是检查日志记录系统的配置，修复损坏的日志文件，或者更新日志记录系统。
7. 日志记录缺失在分析网站日志时，发现部分请求的日志记录缺失，无法完整追踪用户行为。
这可能是由于日志记录系统配置错误、日志文件损坏或其他原因导致的。
解决办法可以是检查日志记录系统的配置，修复损坏的日志文件，或者更新日志记录系统。
sql server日志文件丢失的恢复方法
sql server日志文件丢失的恢复方法SQL Server是一种关系型数据库管理系统，它提供了持久化存储数据的功能。
在使用SQL Server时，我们通常会遇到一些问题，例如日志文件丢失。
当日志文件丢失时，我们需要采取一些措施来恢复数据。
本文将一步一步地回答关于SQL Server日志文件丢失的恢复方法。
第一步：检查日志文件丢失的原因在采取任何措施之前，我们首先需要确定日志文件丢失的原因。
有几种可能的原因，例如磁盘损坏、人为删除、数据库服务中断等。
通过了解原因，我们可以更好地选择适当的恢复方法。
第二步：备份数据库在尝试恢复日志文件之前，我们应该确保已经备份了数据库。
这是非常重要的，因为如果在修复日志文件时出现问题，备份可以用来还原数据库至丢失日志文件之前的状态。
在进行任何恢复操作之前，请确保已经备份了数据库，以免造成不可逆的损失。
第三步：运行数据库完整性检查在恢复日志文件之前，我们应该运行数据库的完整性检查。
这可以帮助我们发现数据库中可能存在的一些问题，例如损坏的数据页、磁盘错误等。
通过运行完整性检查，我们可以修复这些问题，以确保数据库的稳定性。
第四步：使用备份日志恢复如果我们的数据库已经定期备份，并且丢失的日志文件在最近的备份中，我们可以使用备份日志来恢复数据库。
我们可以在SQL Server Management Studio中使用“恢复数据库”向导来完成此操作。
首先，我们选择要恢复的数据库，然后选择相应的备份文件和备份日志文件。
然后，我们可以选择恢复模式，例如完整恢复模式或简单恢复模式，并完成向导以恢复数据库。
第五步：使用事务日志恢复如果备份日志中没有包含所需的丢失日志文件，我们可以尝试使用事务日志来恢复数据库。
SQL Server将每个事务的详细信息记录在事务日志中，通过读取事务日志，我们可以逐个事务地恢复数据库。
首先，我们需要创建一个空数据库，并将其设置为恢复模式。
然后，我们可以使用恢复工具或编写T-SQL语句来读取事务日志，并逐个事务地执行以恢复数据库。
redis的数据恢复流程
redis的数据恢复流程Redis是一个高性能的key-value存储系统，它支持多种数据结构，包括字符串、哈希表、列表、集合、有序集合等。
Redis的数据恢复流程是指在Redis数据丢失或损坏的情况下，如何通过备份、日志等手段恢复数据。
本文将详细介绍Redis的数据恢复流程。
一、Redis数据备份Redis支持两种数据备份方式：RDB和AOF。
1. RDB备份RDB是Redis的一种快照备份方式，它会将Redis中的数据保存到一个文件中。
在恢复数据时，只需将该文件复制到Redis的数据目录下即可。
RDB备份的优点是备份速度快、文件大小小，但缺点是备份的数据可能不是最新的。
2. AOF备份AOF是Redis的一种日志备份方式，它会记录Redis执行的所有写操作，包括增、删、改操作。
在恢复数据时，只需重新执行这些操作即可。
AOF备份的优点是备份的数据是最新的，但缺点是备份速度慢、文件大小大。
二、Redis数据恢复Redis数据恢复主要包括以下两种情况：1. Redis数据丢失如果Redis中的数据丢失，可以通过以下步骤进行数据恢复：（1）检查是否存在RDB备份文件或AOF日志文件。
（2）如果存在RDB备份文件，将该文件复制到Redis的数据目录下，并重启Redis服务即可。
（3）如果存在AOF日志文件，可以通过redis-check-aof命令检查日志文件的完整性，然后使用redis-cli命令重新执行日志文件中的写操作。
2. Redis数据损坏如果Redis中的数据损坏，可以通过以下步骤进行数据恢复：（1）检查是否存在RDB备份文件或AOF日志文件。
（2）如果存在RDB备份文件，将该文件复制到Redis的数据目录下，并重启Redis服务。
（3）如果存在AOF日志文件，可以通过redis-check-aof命令检查日志文件的完整性，然后使用redis-cli命令重新执行日志文件中的写操作。
（4）如果以上恢复方法都无法恢复数据，则需要使用Redis的内置工具redis-check-dump来检查RDB备份文件的完整性。
损坏数据文件的恢复方法
损坏数据文件的恢复方法一：非归档模式下丢失或者损坏数据文件A：OS备份恢复方案在非归档模式下损坏或者丢失数据文件，如果有相应的备份，在一定程度上是可以恢复的，但是如果oracle过多的读写操作记录信息而导致redo重写的时候，恢复就会停滞，非归档下系统能自动恢复的仅仅限于redo中存在的记录。
可以成功恢复案例：SQL> startupORACLE instance started.Total System Global Area 235999352 bytesFixed Size 450680 bytesVariable Size 201326592 bytesDatabase Buffers 33554432 bytesRedo Buffers 667648 bytesDatabase mounted.Database openedSQL> create table test(a int);Table created.SQL> insert into test values(1);1 row created.SQL> /1 row created.SQL> /1 row created.SQL> /1 row created.SQL> commit;Commit complete.SQL> exit;[oracle@www oradata]$ cd cicro/[oracle@www cicro]$ lscontrol01.ctl cwmlite01.dbf indx01.dbf redo02.log temp01.dbfusers01.dbf control02.ctl drsys01.dbf odm01.dbf redo03.logtools01.dbf xdb01.dbf control03.ctl example01.dbf redo01.log system01.dbf undotbs01.dbf[oracle@www cicro]$ pwd/opt/oracle/oradata/cicro[oracle@www cicro]$ sqlplus "/as sysdba"SQL> shutdown immediateDatabase closed.Database dismounted.ORACLE instance shut down.SQL>exit;[oracle@www cicro]$ cp ./*.dbf ../[oracle@www cicro]$ sqlplus "/as sysdba"SQL*Plus: Release 9.2.0.1.0 - Production on Tue Jul 25 19:44:31 2006 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. Connected to:Oracle9i Release 9.2.0.1.0 - ProductionJServer Release 9.2.0.1.0 – ProductionConnected to an idle instance.SQL> startupORACLE instance started.Total System Global Area 235999352 bytesFixed Size 450680 bytesVariable Size 201326592 bytesDatabase Buffers 33554432 bytesRedo Buffers 667648 bytesDatabase mounted.Database opened.SQL> insert into test values(3333);1 row created.SQL> /1 row created.SQL> /1 row created.SQL> /1 row created.SQL> commit;Commit complete.SQL> select * from test;A----------1113333333333338 rows selected.SQL> shutdown immediateDatabase closed.Database dismounted.ORACLE instance shut down.SQL>exit;[oracle@www cicro]$ rm –rf ./*.dbf[oracle@www cicro]$ sqlplus "/as sysdba"Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.Connected to an idle instance.SQL> startupORACLE instance started.Total System Global Area 235999352 bytesFixed Size 450680 bytes技术社区Variable Size 201326592 bytesDatabase Buffers 33554432 bytesRedo Buffers 667648 bytesDatabase mounted.ORA-01157: cannot identify/lock data file 1 - see DBWR trace fileORA-01110: data file 1: '/opt/oracle/oradata/cicro/system01.dbf'SQL> quit[oracle@www cicro]$ mv ../*.dbf .[oracle@www cicro]$ lscontrol01.ctl cwmlite01.dbf indx01.dbf redo02.log temp01.dbf users01.dbf control02.ctl drsys01.dbf odm01.dbf redo03.log tools01.dbf xdb01.dbf control03.ctl example01.dbf redo01.log system01.dbf undotbs01.dbf[oracle@www cicro]$ sqlplus "/as sysdba"SQL*Plus: Release 9.2.0.1.0 - Production on Tue Jul 25 17:56:06 2006Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.Connected to:Oracle9i Release 9.2.0.1.0 - ProductionJServer Release 9.2.0.1.0 - ProductionSQL> recover database;Media recovery complete.SQL> alter database open;Database altered.SQL> select * from test;A----------111333333333333333333338 rows selected.至此，恢复成功！不完全恢复的案例基本操作与上面相同，还是首先建立一张表，然后插入数据：1：建表，写入数据,然后关闭数据库SQL> create table gaojf1 as select * from all_objects;T able created.SQL> insert into gaojf1 select * from gaojf1;29614 rows created.SQL> /59228 rows created. (即为现在此表数据有118456列)SQL>commit;SQL>shutdown immediate2：备份所有的数据文件3：启动数据库继续插入数据[oracle@www cicro]$ sqlplus "/as sysdba"SQL*Plus: Release 9.2.0.1.0 - Production on Tue Jul 25 18:07:19 2006 Copyright (c) 1982, 2002, Oracle Corporation.Connected to:Oracle9i Release 9.2.0.1.0 - ProductionJServer Release 9.2.0.1.0 - ProductionSQL> insert into gaojf1 select * from gaojf1;118456 rows created.SQL> /236912 rows created.SQL> /473824 rows created.SQL> /947648 rows created.SQL> commit;Commit complete.SQL> select count(*) from gaojf1;COUNT(*)----------1895296SQL> /1895296 rows created.SQL> /技术社区3790592 rows created.（如果能够完全恢复，此表应该有3790592*2列）SQL> commit;Commit complete.期间，查看日志信息如下：Wed Jul 26 13:02:54 2006Thread 1 opened at log sequence 1Current log# 3 seq# 1 mem# 0: /opt/oracle/oradata/cicro/redo03.log Successful open of redo thread 1.Wed Jul 26 13:03:56 2006Thread 1 advanced to log sequence 2Current log# 1 seq# 2 mem# 0: /opt/oracle/oradata/cicro/redo01.logWed Jul 26 13:05:41 2006Thread 1 advanced to log sequence 3Current log# 2 seq# 3 mem# 0: /opt/oracle/oradata/cicro/redo02.logWed Jul 26 13:09:04 2006Thread 1 advanced to log sequence 4Current log# 3 seq# 4 mem# 0: /opt/oracle/oradata/cicro/redo03.logWed Jul 26 13:09:29 2006Thread 1 advanced to log sequence 5Current log# 1 seq# 5 mem# 0: /opt/oracle/oradata/cicro/redo01.log 可以看到，redo文件在不断的循环重写，当一个redo写完后继续写第二个redo，然后是第三个，当第三个写完后继续回来重写第一个，依此类推。
SQL Server日志损坏造成整个数据库损坏的修复
SQL Server 日志损坏造成整个数据库损坏的修复版本：V1.0作者：知行合一邮箱：409629442@时间：2014/9/29一、问题说明由于用户的数据库某张表比较大，大约有1000万条记录，数据库管理员在非业务时间对这个表进行删除清理，删除操作持续了1个小时左右，到工作时间，仍然没有正常结束。
前端用户反应应用系统比较慢后，数据库管理员对删除操作进行终止，终止时仍然无法正常终止。
最后，数据库管理员不得已对数据库进行重启，重启后发现数据库已经无法正常打开。
由于用户比较急，就用一个比较老的备份进行了恢复。
我们赶赴现场后，原先的数据库已经被删除，但用户已经针对原先的数据库文件和日志文件进行了拷贝。
我们把备份的数据库文件拷贝到异机进行附加，总是报错，提示无法读取日志文件。
具体报错如下：The log cannot be rebuilt because there were open transactions/users when the database was shutdown, no checkpoint occurred to the database, or the database was read-only. This error could occur if the transaction log file was manually deleted or lost due to a hardware or environment failure.Msg 1813, Level 16, State 2, Line 2通过上面的报错可知，数据库的日志文件发生了损坏，这时已经不能通过简单的附加方式进行恢复，也无法通过无日志附加的方式进行附加，因为这时数据库处在一个不一致的状态。
二、环境介绍操作系统：Windows 2008 R2SQL server: SQL Server 2008 SP1数据文件路径：注：数据文件后面为数据文件的file_id,file_id 可以通过sys.master_files进行查看三、处理过程由于这时数据库已经无法正常打开（已经没有对应的数据库，或数据库状态错误，查看不了任何属性信息），所以我们必须重新创建同名的数据库，然后用备份的数据文件覆盖新创建的数据文件。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
ARCH: All Archive destinations made inactive due to error 333
Tue Jan 15 09:26:57 2008
Errors in file /opt/oracle/admin/oadb/udump/oadb_ora_3626.trc:
ORA-00333: redo log read error block 83969 count 2048
ARCH: Archiving not possible: error count exceeded
ARCH: Failed to archive log 2 thread 1 sequence 326
-- 检查v$log , v$logfile
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS ---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- -------------------
1 1 336 104857600 1 NO INVALIDATED
12258187 2008-01-15 00:53:25
2 1 326 104857600 1 NO INACTIVE
10965786 2007-12-28 00:53:16
3 1 335 104857600 1 NO INACTIVE
12185924 2008-01-14 00:50:31
SQL> select * from v$logfile;
GROUP# STATUS TYPE
---------- ------- -------
MEMBER
--------------------------------------------------------------------------------
1 STALE ONLINE
/opt/oracle/oradata/oadb/redo01.log
2 ONLINE
/opt/oracle/oradata/oadb/redo02.log
引用删除oradbHome/ 2008-05-23 16:52:34
1、非归档模式
SQL>startup mount;
SQL>select * from
v$logfile;
如果日志文件丢失了，手工建上相应
的日志文件放在原处
（新建一个文本文件，改为相应的日
志名就可以了）
SQL>Select * from v$log;
查看日志文件当前状态
SQL>alter database clear logfile group N;
(N为非当前状态组号，把所有非当前状态的日志进行恢复)；
(语句的作用是把该日志文件，清空为标准空日志文件)
SQL>recover database until cancel;
(恢复当前日志)
SQL>alter database open resetlogs;
如果是单个日志文件损坏
SQL>startup mount;
SQL>alter database clear logfile group N;
SQL>alter database open;
2、归档模式
与上面操作大致一样如果
如果alter database clear logfile
group N 执行不成功
就改为：alter database clear unarchived logfile group N
特别要注意的：alter database open resetlogs;
Resetlogs:
表示一个数据库逻辑生存期结束和一个数据库逻辑生存期的开始.
每次使用resetlogs时,SCN 计数器不会被重置,oracle会重置其它计数器(如日志序列号),同时还会重置重做日志的内容.
如果当前日志文件损坏无法通过recover database until cancel恢复就用第三种方式处理。
3、当前日志文件损坏的处理办法：SQL>startup mount;
SQL>create
pfile=’d:\orace_test\pfile.txt’ from spfile;
(8i及以前版本直接找到参数文件复制一份就可以了)
SQL>shutdown immediate;
编辑生成的pfile,加入
_allow_resetlogs_corruption=TRUE SQL>startup mount
pfile=’d:\oracle_test\pfile.txt’;
SQL>alter database open resetlogs;
数据库被打开后，马上执行一个full export
shutdown数据库
重建库
import并完成恢复
建议执行一下ANALYZE
TABLE ...VALIDATE STRUCTURE CASCADE;
说明：
1、该恢复方法是没有办法之后的恢复方法，一般情况下建议不要采用，因为该方法
可能导致数据库的不一致
2、该方法也丢失数据，未写入数据文件的已提交或未提交数据。
3、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为
任何数据的丢失对于生产来说都是不容许的。