redo在线日志被误删这大概是在Oracle 12c数据库运维里最能让人瞬间清醒的事故之一。我这些年处理过的类似case不算少最常见的原因是DBA在清理/u01这类目录下的历史日志文件时把redo01.log、redo02.log当成了普通日志顺手删掉。接下来剧情几乎都一样alert日志里开始刷ORA-00313、ORA-00312日志切换卡住应用侧批量写入全部悬停。这篇文章围绕这个标题做一次完整复盘——从redo被删后的故障表现、诊断方法到各种状态下怎么安全恢复把12c多租户和RAC环境里的特殊坑也一并讲清楚。1. 事故背景redo日志被删后数据库到底在慌什么1.1 redo日志在12c体系里的角色定位redo log在Oracle数据库里的作用可以用一个很朴素的类比来解释数据文件就像是账房的余额登记本而redo日志就是流水账。你每做一笔操作会计先往流水账上记一笔然后才去改余额。这样即使某天余额本被撕了只要流水账还在我们就能从最近一次完整备份往后一笔一笔重放把余额恢复到崩溃前的状态。在12c里这个逻辑没有本质变化但多租户架构让负担变重了一个CDB容器里挂着多个PDB所有PDB产生的事务redo全都写到CDB实例的在线redo里。也就是说redo一旦出问题影响的不是一个模块而是容器里所有租户的全部写操作。RAC环境下更麻烦每个实例有自己的redo thread一个节点上的redo被删可能只挂掉那一个节点但整个集群的健康检查、负载均衡都会陷入混乱。1.2 redo文件被删后的三种典型现场redo日志被误删后数据库并不一定立刻崩溃表现取决于被删的日志组当时处于什么状态我归纳出三种最常见现场。第一种数据库还在正常运行只是某个非当前日志组的数据文件丢了。这种最轻查询、更新暂时不出错但日志切换一到那组就会开始报错归档进程也可能异常整体上是个“慢性病”。第二种日志切换过程中卡死所有写事务全部挂起。通常是因为某一组redo被删后LGWR尝试切换到该组或归档进程尝试读取该组时失败事务无法继续。这种属于“急性病”业务完全等不了必须马上处理。第三种数据库已经因为其他原因关闭再次启动时发现某个redo成员不存在。这种最危险尤其是被删的那组是CURRENT状态时实例恢复可能直接无法完成数据库处于无法open的状态处置难度直线上升。这三种现场对应的恢复思路完全不同。所以我一直跟团队强调听到“redo被删”之后的第一反应不应该是慌乱而是先搞清楚被删的日志组在v$log里面的状态再看数据库当前是mount还是open状态。2. 先别急着恢复用10分钟认清redo丢失的真实状态2.1 从alert日志和动态视图里锁定线索拿到事故现场我习惯按下面顺序摸情况。先看alert日志通常路径在$ORACLE_BASE/diag/rdbms/{dbname}/{SID}/trace/alert_{SID}.log搜索ORA-00312、ORA-00313、ORA-16038、ORA-00318这类关键字。这些错误会直接告诉我们哪个日志组、哪个member文件有问题。接着登录数据库执行最重要的两条查询SQL SELECT group#, thread#, sequence#, bytes, status, archived FROM v$log; SQL SELECT group#, thread#, member, status FROM v$logfile;v$log的status字段是判断危险等级的关键。CURRENT表示LGWR当前正在写的日志组被删了就等于账本正在记的那一页被撕掉了影响最大ACTIVE表示该日志组里还有未完成checkpoint的数据信息实例恢复或介质恢复时可能还需要用到它INACTIVE表示已经被安全checkpoint不再需要参与恢复删除后的处置难度相对最低。v$logfile里的status则更偏向物理文件层面如果某个member显示INVALID或空白而操作系统层面ls也看不到文件基本可以实锤就是它了。2.2 判断数据库处于open还是mount状态第二个关键变量是数据库当前是开着的还是已经关了。如果数据库还处于open状态哪怕日志切换已经卡住我们的操作空间也大很多至少可以通过添加新日志组、强制切换、清理无效组的方式把数据库“扶正”大多数场景能做到不停机恢复。如果数据库已经处于shutdown状态尤其是不干净关闭之后实例启动到open阶段时需要读取redo完成实例恢复这时候少了关键redo直接无法open。这时候就要区分数据库之前是否是正常关闭如果是正常shutdown数据文件已经保持一致我们走重建控制文件并resetlogs的路线如果是abort或宕机redo又是必需的那就只能依靠备份和归档做恢复了。这一步判断决定了整个恢复策略我建议把它写进故障预案不要到现场再临时想。2.3 查看归档状态和备份可用性redo被删之后归档状态同样重要。在open状态下执行SQL ARCHIVE LOG LIST; SQL SELECT thread#, sequence#, archived, status FROM v$log;如果某个日志组对应的归档文件缺失后续恢复时会出现“断档”。这时需要查一下最近的物理备份情况RMAN LIST BACKUP OF DATABASE; RMAN CROSSCHECK BACKUP;知道最后一刻的全备、增量备份、归档备份在哪里恢复的上限和下限就基本画清楚了。没有备份兜底的话恢复策略会激进很多风险和代价都要向业务方讲明白。3. 数据库还在跑在线重建与“挪走”损坏日志组3.1 丢失的是非当前日志组的稳妥处理如果v$log查询结果里被删的日志组状态是INACTIVE而数据库还open这是最理想的情况。我的处理顺序是强制做一次全库checkpointSQL ALTER SYSTEM CHECKPOINT;确认该组已经是INACTIVESQL SELECT group#, status FROM v$log;直接删掉这个坏日志组SQL ALTER DATABASE DROP LOGFILE GROUP 1;在原来的位置或新的磁盘路径上重建同编号的日志组SQL ALTER DATABASE ADD LOGFILE GROUP 1 (/u01/oradata/orcl/redo01a.log, /u02/oradata/orcl/redo01b.log) SIZE 200M;这里有个操作细节日志组编号可以复用但drop之后要确保所有member文件都物理消失再重新add否则可能出现ORA-00362等残留问题。成员文件最好配置两组以上并且放到不同磁盘避免再次一锅端。3.2 丢失的是ACTIVE日志组时先让它变成INACTIVE如果v$log里显示被删的组是ACTIVE不能直接drop。ACTIVE意味着虽然LGWR已经不写它了但数据文件里还有一部分脏块尚未写入spfile或控制文件里记录了它需要用于实例恢复。这时不要慌先做checkpointSQL ALTER SYSTEM CHECKPOINT;checkpoint的作用就是把redo里记录的脏数据全部写到数据文件完成后LGWR就不再依赖该日志组状态会从ACTIVE变成INACTIVE。然后按上面的流程继续走drop和add。如果checkpoint命令执行时因为日志切换卡住而hang住可以先手动触发一次日志切换SQL ALTER SYSTEM SWITCH LOGFILE;但要注意如果日志文件在操作系统层面已经被删掉LGWR可能根本切换不了。这种情况我一般先添加一组全新的日志组让LGWR有可用的新“草稿本”然后连续手工切换把业务流量尽快从坏组上挪开SQL ALTER DATABASE ADD LOGFILE GROUP 4 (/u01/oradata/orcl/redo04a.log, /u02/oradata/orcl/redo04b.log) SIZE 200M; SQL ALTER SYSTEM SWITCH LOGFILE;多次switch logfile之后原有坏组通常会被轮换到INACTIVE状态再执行checkpoint和drop就顺利很多。3.3 丢失的是CURRENT日志组但实例还活着怎么争分夺秒CURRENT状态的日志被删是最棘手的在线场景。LGWR手里正在写的那本“流水账”被撕了数据库表现常常是大量写事务堆积、日志切换报错、实例接近假死。在Linux这类文件系统上有一种常见但微妙的局面如果删除命令发生时LGWR进程还持有这个文件的句柄文件虽然从目录里消失了但进程还在往这个“幽灵文件”里写数据数据库短时间内还能继续运行。遇到这种情况我的建议是千万不要重启实例先以最快速度做一次日志切换让这个损坏组脱离CURRENT状态SQL ALTER SYSTEM SWITCH LOGFILE; SQL ALTER SYSTEM CHECKPOINT;然后立刻查询v$log如果CURRENT已经落到其他正常的组上原有的坏组变成ACTIVE或INACTIVE就按前面的方式drop掉再重建。如果文件句柄已经失效LGWR报错无法继续写切换也做不动那就不能犹豫了。我的处理是尝试添加新日志组并强制切换这条也无效就只能考虑受控的shutdown abort然后走下一章的实例恢复流程。这里要特别提醒shutdown abort是有代价的redo一旦缺失实例恢复可能无法完成必须在心里有备份方案兜底的前提下做。3.4 只是丢了一个成员文件补回来就行有时候被删的不是整组redo而是一组中的某一个member。比如redo01.log组本来有两个member被误删了其中一个。这种损伤很小v$logfile里会显示某个member状态为INVALID或者直接消失。处理办法很简单在mount或open状态下给该日志组补一个成员SQL ALTER DATABASE ADD LOGFILE MEMBER /u02/oradata/orcl/redo01b.log TO GROUP 1;补充完成后LGWR会自动重新初始化该文件随便观察几轮日志切换确认成员状态恢复正常即可。需要留意的是如果原路径目录因为磁盘故障不可写就把新成员加到其他目录多路复用本来就是防单点故障的。4. 数据库已经“趴窝”从启动失败到实例恢复4.1 冷启动报错怎么读ORA-00313与ORA-00312的组合数据库关闭后再次启动如果要恢复无法进行常见报错是这个样子ORA-00313: requested failed operation to open file for redo log thread 1 ORA-00312: online log 1 thread 1: /u01/oradata/orcl/redo01.log这种情况说明控制文件里记录的redo路径找不到了。再往下翻可能还有ORA-27037、ORA-00314、ORA-00316等细节不同但本质都是实例open阶段需要加载在线日志而相应文件已经不存在或严重损坏。看到组合报错后不要急着反复startup而是先执行startup mount确认数据库能不能进入mount状态。mount只需要控制文件和数据文件头部信息可读不涉及redo所以通常是可以挂上去的。挂上去之后立刻查v$log看看各个日志组的状态。如果之前是正常关闭的数据文件本身是一致的日志组的status可能是UNKNOWN或CLEARING之类的不健康状态。4.2 正常关闭后丢失redo的恢复重建控制文件加resetlogs如果事故前数据库是正常shutdown的那么数据文件已经完成同步此时我们其实并不需要旧的redo内容来做实例恢复。问题是控制文件仍然指向那些已经不存在的redo文件导致open阶段过不去。我的做法是重建控制文件让数据库“忘记”旧日志组用新的登录日志组重新开门。第一步先把mount状态下能拿到的元数据备份下来SQL ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS /tmp/controlfile_trace.sql; SQL ALTER DATABASE BACKUP CONTROLFILE TO /backup/control01.ctl;第二步查看trace文件修改其中的LOGFILE段。trace文件里默认会列出原有日志组路径我们把路径改成新规划的路径比如从/u01/oradata/orcl/redo01.log改为/u02/oradata/orcl/redo01.log并确保新路径对应的目录存在且可写。第三步关闭实例后以nomount方式启动执行重建控制文件的脚本STARTUP NOMOUNT; CREATE CONTROLFILE REUSE DATABASE ORCL NORESETLOGS NOARCHIVELOG MAXLOGFILES 32 MAXLOGMEMBERS 4 MAXDATAFILES 1024 MAXINSTANCES 16 MAXLOGHISTORY 2048 LOGFILE GROUP 1 ( /u02/oradata/orcl/redo01a.log, /u02/oradata/orcl/redo01b.log ) SIZE 200M, GROUP 2 ( /u02/oradata/orcl/redo02a.log, /u02/oradata/orcl/redo02b.log ) SIZE 200M DATAFILE /u01/oradata/orcl/system01.dbf, /u01/oradata/orcl/sysaux01.dbf, /u01/oradata/orcl/undotbs01.dbf, /u01/oradata/orcl/users01.dbf CHARACTER SET AL32UTF8;然后open数据库SQL ALTER DATABASE OPEN RESETLOGS;这里要特别说明NORESETLOGS还是RESETLOGS取决于数据文件是否完全一致。正常关闭后数据文件一致用NORESETLOGS重建控制文件后理论上可以直接open但实际中重新定义在线日志路径后使用RESETLOGS更省事可以重置日志序列号并强制让数据库接受新的日志状态。执行RESETLOGS之后所有历史日志序列会被清零重来之前所有归档立即失效务必马上做全备。4.3 非正常关闭且redo缺失只能走备份恢复路线如果数据库不是正常关闭而是宕机、停电、abort之后发现redo被删事情就严重了。因为数据文件本身是不一致的系统要完成实例恢复必须读取旧的redo而redo已经被删这等于撕掉了恢复的关键线索。这种情况下除非有物理备用库或DG可以切换否则恢复思路基本只有一条从最近一次完整备份开始恢复。标准流程用RMAN来做RMAN STARTUP MOUNT; RMAN RESTORE DATABASE; RMAN RECOVER DATABASE UNTIL CANCEL; RMAN ALTER DATABASE OPEN RESETLOGS;RECOVER DATABASE UNTIL CANCEL会在缺失的redo阶段停下来我们手动输入CANCEL结束恢复。这样做本质上属于不完全恢复会丢失从备份点到故障点之间不能通过归档补全的部分数据业务侧必须确认可接受的数据丢失窗口。执行之前先把所有可用的归档备份和增量备份收集齐用crosscheck确认它们没有被刷掉。恢复完成后同样要立即做全备。如果遇到RMAN恢复时找不到某个归档文件可以在不全的sequence位置cancel损失的只是那个时间点到故障点之间的事务。4.4 恢复之后的验证流程不管用哪种方式把数据库拉起来后续验证都马虎不得。我习惯按下面顺序检查确认实例状态SQL SELECT instance_name, status FROM v$instance; SQL SELECT name, open_mode FROM v$database;查看所有PDB是否正常打开12c里很容易出现CDB正常但某个PDB处于MOUNTED或RECOVER状态SQL SELECT con_id, name, open_mode FROM v$pdbs; SQL ALTER PLUGGABLE DATABASE ALL OPEN;检查日志组是否全部健康SQL SELECT group#, status, archived FROM v$log; SQL SELECT group#, member, status FROM v$logfile;做几次日志切换观察是否能正常归档SQL ALTER SYSTEM SWITCH LOGFILE; SQL SELECT sequence#, archived, status FROM v$log;业务侧抽几个关键事务确认数据读写的正确性。做完这些才能算故障处理真正结束。恢复后当天不要立刻撤掉现场备件至少保留全备和日志一段时间。5. 容易踩坑的诱因场景归档卡死、RAC线程与PDB范围5.1 日志切换hang住被redo缺失连带拖垮redo文件被删后最直接的连带反应就是日志切换卡死。LGWR想要切换到下一个日志组时发现下一个组里可能有active事务或归档失败于是整个写入链路被堵死。数据库的表现为等待事件出现log file switch、log file sync大量会话堆积在insert/update上。此时即便我们清楚坏组是哪一个也不能直接drop因为drop不能影响正在被使用或者尚未归档的日志组。我的处理顺序是先查v$log把所有组的状态拉出来按照“添加新日志组-手工切换-强制checkpoint-清理坏组”的顺序来解开死结。如果某个组因为不能归档而卡住比如归档日志目标目录满了还要先处理归档空间否则清完redo组也没用。SQL SELECT destination, status, error FROM v$archive_dest; SQL SELECT name, space_limit, space_used FROM v$recovery_file_dest;如果是闪回恢复区满了扩容或者调整归档策略把可用的日志组轮换出来事情很快就解开。5.2 RAC环境里redo thread被删是另一套逻辑RAC环境比单实例复杂的地方在于每个实例有自己独立的redo thread。v$log查询结果里会出现多个thread编号而被误删的日志组可能只属于某一个节点。这时候如果一个实例的CURRENT redo丢失该实例可能直接宕掉而另一个实例还活着。处理要分两步第一步先让活着的实例接管业务必要时设置service在当前可用节点运行。第二步在故障节点上恢复redo。RAC下添加日志组要指定threadSQL ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 10 (DATA/orcl/redo10a.log, RECO/orcl/redo10b.log) SIZE 200M;删日志组时也要注意thread归属不能用一个实例的会话去删另一个实例的redo thread通常需要连接到对应线程名称的实例或者使用类似以下的写法SQL ALTER DATABASE DROP LOGFILE GROUP 10;这里有一个容易忽略的地方ASM磁盘组里删除文件不能用传统的rm命令很多人是在ASMCMD或RMAN里把redo文件误删的。操作方向不一样但处理逻辑通用——查控制文件、查当前状态、按状态推进恢复。如果故障节点的redo缺失严重到无法自己启动可以把该实例的redo thread重建出来再做实例级恢复。RAC场景下我强烈建议平时就把所有实例的redo文件用OMF或ASM来管理路径统一排查时能省一半时间。5.3 12c多租户架构之下PDB视角的连带麻烦12c的redo日志是CDB级的PDB无法单独配置自己的在线日志。这就带来一个很微妙的问题某个PDB的活跃事务可能正在使用redo而redo被删会波及所有PDB某几个PDB可能瞬间变得不可用。恢复方案上一律在CDB层操作不需要去改任何PDB的redo配置。但因为一个PDB可能有大量业务数据恢复后要重点检查PDB的打开状态和数据一致性。SQL SELECT con_id, name, open_mode, total_size FROM v$pdbs; SQL ALTER PLUGGABLE DATABASE pdb1 OPEN;如果PDB无法打开多半还需要执行PDB级别的恢复操作。这时DBA通常会在CDB里用以下命令SQL ALTER PLUGGABLE DATABASE pdb1 CLOSE IMMEDIATE; SQL ALTER PLUGGABLE DATABASE pdb1 OPEN RECOVER;有一类场景特别容易忽略redo被删后数据库被还原到某个时间点PDB的恢复点可能晚于CDB的导致PDB无法正常打开。遇到这种情况不要反复强制open先检查PDB的undo和状态必要时通过快照或备份单独恢复目标PDB。6. 常见错误速查与DBA的几条保命经验6.1 错误代码速查表我把redo丢失场景中出现频率最高的错误整理成一张表方便现场对照。错误代码含义常见处理方向ORA-00313无法打开指定redo日志文件确认文件路径、检查OS层文件是否存在ORA-00312在线日志组及路径信息常伴随ORA-00313出现结合v$logfile定位丢失的memberORA-00314日志文件头部信息损坏通常需要clear或重建该日志组ORA-00316日志文件类型不对多为控制文件信息与redo不匹配重建控制文件ORA-00321日志无法更新检查文件权限、磁盘空间ORA-00327日志状态与文件实际内容不符大概率需要执行clear unarchivedORA-16038日志无法归档检查归档目标、闪回恢复区空间ORA-19809恢复区空间超限清理过期备份或扩大DB_RECOVERY_FILE_DEST_SIZEORA-27037物理文件不存在OS层面确认文件是否丢失ORA-19588RESETLOGS与备份不匹配执行全备或将备份时间点对齐看到任何一个错误码第一时间先不要急着操作回到v$log和v$logfile去定位具体是哪个thread、哪个group、哪个member坏了再对照本文章的处置方法。6.2 现场自救的几条铁律第一条铁律没有做完整备份评估之前不要做任何破坏性操作。包括drop logfile、clear logfile、resetlogs每一步都要想好“如果这一步失败下一步怎么办”。第二条铁律优先保住控制文件。控制文件是数据库的“目录总索引”redo丢了还有救控制文件也丢了恢复难度直接指数级上升。平时定期把控制文件备份到trace绝对是成本最低的保险。SQL ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS /backup/control_trace_YYYYMMDD.sql;第三条铁律执行CLEAR LOGFILE之前想清楚归档后果。下面这条命令会把日志组标记为不再归档SQL ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 2;这意味着这一段redo对应的数据差异将无法通过备份来恢复。如果业务对数据完整性要求很高这一步必须经过业务方确认。第四条铁律操作完成后马上做全备。任何一次用resetlogs打开数据库都会让此前的日志序列失效旧备份直接不可用不赶紧做全备相当于把自己再次置于无备份的裸奔状态。6.3 我踩过一次最深的坑有一次我按网上资料对一个ACTIVE状态的日志组执行clear logfile结果直接报错ORA-01624: log X needed for crash recovery。这条错误的意思是日志组虽然状态不是CURRENT但实例恢复还需要它不能clear。后来才真正理解决断一个日志组能不能drop或clear不能只看status字段还得看它是否涉及crash recovery。稳妥做法是先ALTER SYSTEM CHECKPOINT把恢复位置前移减少对旧日志组的依赖。如果还是不能clear继续添加日志组并切换直到它彻底脱离关键路径。那次之后我给自己定了一条死规矩处理redo故障时所有影响动作的顺序永远是——先加新组、再切换、再checkpoint、再drop或clear绝不允许跳到第一步。这个顺序看起来笨但每次都能把风险压到最低。现在回顾redo被删这类事故其实最考验DBA的不是SQL命令背得有多熟而是能否冷静判断当前状态、按顺序推进操作。误删文件这种坑谁都不敢保证一辈子不踩但只要我们能把日志组冗余做好、控制文件备份做到位、恢复流程写进预案真遇到时就能把一场灾难变成一个普通的运维日。
redo在线日志被误删这大概是在Oracle 12c数据库运维里最能让人瞬间清醒的事故之一。我这些年处理过的类似case不算少最常见的原因是DBA在清理/u01这类目录下的历史日志文件时把redo01.log、redo02.log当成了普通日志顺手删掉。接下来剧情几乎都一样alert日志里开始刷ORA-00313、ORA-00312日志切换卡住应用侧批量写入全部悬停。这篇文章围绕这个标题做一次完整复盘——从redo被删后的故障表现、诊断方法到各种状态下怎么安全恢复把12c多租户和RAC环境里的特殊坑也一并讲清楚。1. 事故背景redo日志被删后数据库到底在慌什么1.1 redo日志在12c体系里的角色定位redo log在Oracle数据库里的作用可以用一个很朴素的类比来解释数据文件就像是账房的余额登记本而redo日志就是流水账。你每做一笔操作会计先往流水账上记一笔然后才去改余额。这样即使某天余额本被撕了只要流水账还在我们就能从最近一次完整备份往后一笔一笔重放把余额恢复到崩溃前的状态。在12c里这个逻辑没有本质变化但多租户架构让负担变重了一个CDB容器里挂着多个PDB所有PDB产生的事务redo全都写到CDB实例的在线redo里。也就是说redo一旦出问题影响的不是一个模块而是容器里所有租户的全部写操作。RAC环境下更麻烦每个实例有自己的redo thread一个节点上的redo被删可能只挂掉那一个节点但整个集群的健康检查、负载均衡都会陷入混乱。1.2 redo文件被删后的三种典型现场redo日志被误删后数据库并不一定立刻崩溃表现取决于被删的日志组当时处于什么状态我归纳出三种最常见现场。第一种数据库还在正常运行只是某个非当前日志组的数据文件丢了。这种最轻查询、更新暂时不出错但日志切换一到那组就会开始报错归档进程也可能异常整体上是个“慢性病”。第二种日志切换过程中卡死所有写事务全部挂起。通常是因为某一组redo被删后LGWR尝试切换到该组或归档进程尝试读取该组时失败事务无法继续。这种属于“急性病”业务完全等不了必须马上处理。第三种数据库已经因为其他原因关闭再次启动时发现某个redo成员不存在。这种最危险尤其是被删的那组是CURRENT状态时实例恢复可能直接无法完成数据库处于无法open的状态处置难度直线上升。这三种现场对应的恢复思路完全不同。所以我一直跟团队强调听到“redo被删”之后的第一反应不应该是慌乱而是先搞清楚被删的日志组在v$log里面的状态再看数据库当前是mount还是open状态。2. 先别急着恢复用10分钟认清redo丢失的真实状态2.1 从alert日志和动态视图里锁定线索拿到事故现场我习惯按下面顺序摸情况。先看alert日志通常路径在$ORACLE_BASE/diag/rdbms/{dbname}/{SID}/trace/alert_{SID}.log搜索ORA-00312、ORA-00313、ORA-16038、ORA-00318这类关键字。这些错误会直接告诉我们哪个日志组、哪个member文件有问题。接着登录数据库执行最重要的两条查询SQL SELECT group#, thread#, sequence#, bytes, status, archived FROM v$log; SQL SELECT group#, thread#, member, status FROM v$logfile;v$log的status字段是判断危险等级的关键。CURRENT表示LGWR当前正在写的日志组被删了就等于账本正在记的那一页被撕掉了影响最大ACTIVE表示该日志组里还有未完成checkpoint的数据信息实例恢复或介质恢复时可能还需要用到它INACTIVE表示已经被安全checkpoint不再需要参与恢复删除后的处置难度相对最低。v$logfile里的status则更偏向物理文件层面如果某个member显示INVALID或空白而操作系统层面ls也看不到文件基本可以实锤就是它了。2.2 判断数据库处于open还是mount状态第二个关键变量是数据库当前是开着的还是已经关了。如果数据库还处于open状态哪怕日志切换已经卡住我们的操作空间也大很多至少可以通过添加新日志组、强制切换、清理无效组的方式把数据库“扶正”大多数场景能做到不停机恢复。如果数据库已经处于shutdown状态尤其是不干净关闭之后实例启动到open阶段时需要读取redo完成实例恢复这时候少了关键redo直接无法open。这时候就要区分数据库之前是否是正常关闭如果是正常shutdown数据文件已经保持一致我们走重建控制文件并resetlogs的路线如果是abort或宕机redo又是必需的那就只能依靠备份和归档做恢复了。这一步判断决定了整个恢复策略我建议把它写进故障预案不要到现场再临时想。2.3 查看归档状态和备份可用性redo被删之后归档状态同样重要。在open状态下执行SQL ARCHIVE LOG LIST; SQL SELECT thread#, sequence#, archived, status FROM v$log;如果某个日志组对应的归档文件缺失后续恢复时会出现“断档”。这时需要查一下最近的物理备份情况RMAN LIST BACKUP OF DATABASE; RMAN CROSSCHECK BACKUP;知道最后一刻的全备、增量备份、归档备份在哪里恢复的上限和下限就基本画清楚了。没有备份兜底的话恢复策略会激进很多风险和代价都要向业务方讲明白。3. 数据库还在跑在线重建与“挪走”损坏日志组3.1 丢失的是非当前日志组的稳妥处理如果v$log查询结果里被删的日志组状态是INACTIVE而数据库还open这是最理想的情况。我的处理顺序是强制做一次全库checkpointSQL ALTER SYSTEM CHECKPOINT;确认该组已经是INACTIVESQL SELECT group#, status FROM v$log;直接删掉这个坏日志组SQL ALTER DATABASE DROP LOGFILE GROUP 1;在原来的位置或新的磁盘路径上重建同编号的日志组SQL ALTER DATABASE ADD LOGFILE GROUP 1 (/u01/oradata/orcl/redo01a.log, /u02/oradata/orcl/redo01b.log) SIZE 200M;这里有个操作细节日志组编号可以复用但drop之后要确保所有member文件都物理消失再重新add否则可能出现ORA-00362等残留问题。成员文件最好配置两组以上并且放到不同磁盘避免再次一锅端。3.2 丢失的是ACTIVE日志组时先让它变成INACTIVE如果v$log里显示被删的组是ACTIVE不能直接drop。ACTIVE意味着虽然LGWR已经不写它了但数据文件里还有一部分脏块尚未写入spfile或控制文件里记录了它需要用于实例恢复。这时不要慌先做checkpointSQL ALTER SYSTEM CHECKPOINT;checkpoint的作用就是把redo里记录的脏数据全部写到数据文件完成后LGWR就不再依赖该日志组状态会从ACTIVE变成INACTIVE。然后按上面的流程继续走drop和add。如果checkpoint命令执行时因为日志切换卡住而hang住可以先手动触发一次日志切换SQL ALTER SYSTEM SWITCH LOGFILE;但要注意如果日志文件在操作系统层面已经被删掉LGWR可能根本切换不了。这种情况我一般先添加一组全新的日志组让LGWR有可用的新“草稿本”然后连续手工切换把业务流量尽快从坏组上挪开SQL ALTER DATABASE ADD LOGFILE GROUP 4 (/u01/oradata/orcl/redo04a.log, /u02/oradata/orcl/redo04b.log) SIZE 200M; SQL ALTER SYSTEM SWITCH LOGFILE;多次switch logfile之后原有坏组通常会被轮换到INACTIVE状态再执行checkpoint和drop就顺利很多。3.3 丢失的是CURRENT日志组但实例还活着怎么争分夺秒CURRENT状态的日志被删是最棘手的在线场景。LGWR手里正在写的那本“流水账”被撕了数据库表现常常是大量写事务堆积、日志切换报错、实例接近假死。在Linux这类文件系统上有一种常见但微妙的局面如果删除命令发生时LGWR进程还持有这个文件的句柄文件虽然从目录里消失了但进程还在往这个“幽灵文件”里写数据数据库短时间内还能继续运行。遇到这种情况我的建议是千万不要重启实例先以最快速度做一次日志切换让这个损坏组脱离CURRENT状态SQL ALTER SYSTEM SWITCH LOGFILE; SQL ALTER SYSTEM CHECKPOINT;然后立刻查询v$log如果CURRENT已经落到其他正常的组上原有的坏组变成ACTIVE或INACTIVE就按前面的方式drop掉再重建。如果文件句柄已经失效LGWR报错无法继续写切换也做不动那就不能犹豫了。我的处理是尝试添加新日志组并强制切换这条也无效就只能考虑受控的shutdown abort然后走下一章的实例恢复流程。这里要特别提醒shutdown abort是有代价的redo一旦缺失实例恢复可能无法完成必须在心里有备份方案兜底的前提下做。3.4 只是丢了一个成员文件补回来就行有时候被删的不是整组redo而是一组中的某一个member。比如redo01.log组本来有两个member被误删了其中一个。这种损伤很小v$logfile里会显示某个member状态为INVALID或者直接消失。处理办法很简单在mount或open状态下给该日志组补一个成员SQL ALTER DATABASE ADD LOGFILE MEMBER /u02/oradata/orcl/redo01b.log TO GROUP 1;补充完成后LGWR会自动重新初始化该文件随便观察几轮日志切换确认成员状态恢复正常即可。需要留意的是如果原路径目录因为磁盘故障不可写就把新成员加到其他目录多路复用本来就是防单点故障的。4. 数据库已经“趴窝”从启动失败到实例恢复4.1 冷启动报错怎么读ORA-00313与ORA-00312的组合数据库关闭后再次启动如果要恢复无法进行常见报错是这个样子ORA-00313: requested failed operation to open file for redo log thread 1 ORA-00312: online log 1 thread 1: /u01/oradata/orcl/redo01.log这种情况说明控制文件里记录的redo路径找不到了。再往下翻可能还有ORA-27037、ORA-00314、ORA-00316等细节不同但本质都是实例open阶段需要加载在线日志而相应文件已经不存在或严重损坏。看到组合报错后不要急着反复startup而是先执行startup mount确认数据库能不能进入mount状态。mount只需要控制文件和数据文件头部信息可读不涉及redo所以通常是可以挂上去的。挂上去之后立刻查v$log看看各个日志组的状态。如果之前是正常关闭的数据文件本身是一致的日志组的status可能是UNKNOWN或CLEARING之类的不健康状态。4.2 正常关闭后丢失redo的恢复重建控制文件加resetlogs如果事故前数据库是正常shutdown的那么数据文件已经完成同步此时我们其实并不需要旧的redo内容来做实例恢复。问题是控制文件仍然指向那些已经不存在的redo文件导致open阶段过不去。我的做法是重建控制文件让数据库“忘记”旧日志组用新的登录日志组重新开门。第一步先把mount状态下能拿到的元数据备份下来SQL ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS /tmp/controlfile_trace.sql; SQL ALTER DATABASE BACKUP CONTROLFILE TO /backup/control01.ctl;第二步查看trace文件修改其中的LOGFILE段。trace文件里默认会列出原有日志组路径我们把路径改成新规划的路径比如从/u01/oradata/orcl/redo01.log改为/u02/oradata/orcl/redo01.log并确保新路径对应的目录存在且可写。第三步关闭实例后以nomount方式启动执行重建控制文件的脚本STARTUP NOMOUNT; CREATE CONTROLFILE REUSE DATABASE ORCL NORESETLOGS NOARCHIVELOG MAXLOGFILES 32 MAXLOGMEMBERS 4 MAXDATAFILES 1024 MAXINSTANCES 16 MAXLOGHISTORY 2048 LOGFILE GROUP 1 ( /u02/oradata/orcl/redo01a.log, /u02/oradata/orcl/redo01b.log ) SIZE 200M, GROUP 2 ( /u02/oradata/orcl/redo02a.log, /u02/oradata/orcl/redo02b.log ) SIZE 200M DATAFILE /u01/oradata/orcl/system01.dbf, /u01/oradata/orcl/sysaux01.dbf, /u01/oradata/orcl/undotbs01.dbf, /u01/oradata/orcl/users01.dbf CHARACTER SET AL32UTF8;然后open数据库SQL ALTER DATABASE OPEN RESETLOGS;这里要特别说明NORESETLOGS还是RESETLOGS取决于数据文件是否完全一致。正常关闭后数据文件一致用NORESETLOGS重建控制文件后理论上可以直接open但实际中重新定义在线日志路径后使用RESETLOGS更省事可以重置日志序列号并强制让数据库接受新的日志状态。执行RESETLOGS之后所有历史日志序列会被清零重来之前所有归档立即失效务必马上做全备。4.3 非正常关闭且redo缺失只能走备份恢复路线如果数据库不是正常关闭而是宕机、停电、abort之后发现redo被删事情就严重了。因为数据文件本身是不一致的系统要完成实例恢复必须读取旧的redo而redo已经被删这等于撕掉了恢复的关键线索。这种情况下除非有物理备用库或DG可以切换否则恢复思路基本只有一条从最近一次完整备份开始恢复。标准流程用RMAN来做RMAN STARTUP MOUNT; RMAN RESTORE DATABASE; RMAN RECOVER DATABASE UNTIL CANCEL; RMAN ALTER DATABASE OPEN RESETLOGS;RECOVER DATABASE UNTIL CANCEL会在缺失的redo阶段停下来我们手动输入CANCEL结束恢复。这样做本质上属于不完全恢复会丢失从备份点到故障点之间不能通过归档补全的部分数据业务侧必须确认可接受的数据丢失窗口。执行之前先把所有可用的归档备份和增量备份收集齐用crosscheck确认它们没有被刷掉。恢复完成后同样要立即做全备。如果遇到RMAN恢复时找不到某个归档文件可以在不全的sequence位置cancel损失的只是那个时间点到故障点之间的事务。4.4 恢复之后的验证流程不管用哪种方式把数据库拉起来后续验证都马虎不得。我习惯按下面顺序检查确认实例状态SQL SELECT instance_name, status FROM v$instance; SQL SELECT name, open_mode FROM v$database;查看所有PDB是否正常打开12c里很容易出现CDB正常但某个PDB处于MOUNTED或RECOVER状态SQL SELECT con_id, name, open_mode FROM v$pdbs; SQL ALTER PLUGGABLE DATABASE ALL OPEN;检查日志组是否全部健康SQL SELECT group#, status, archived FROM v$log; SQL SELECT group#, member, status FROM v$logfile;做几次日志切换观察是否能正常归档SQL ALTER SYSTEM SWITCH LOGFILE; SQL SELECT sequence#, archived, status FROM v$log;业务侧抽几个关键事务确认数据读写的正确性。做完这些才能算故障处理真正结束。恢复后当天不要立刻撤掉现场备件至少保留全备和日志一段时间。5. 容易踩坑的诱因场景归档卡死、RAC线程与PDB范围5.1 日志切换hang住被redo缺失连带拖垮redo文件被删后最直接的连带反应就是日志切换卡死。LGWR想要切换到下一个日志组时发现下一个组里可能有active事务或归档失败于是整个写入链路被堵死。数据库的表现为等待事件出现log file switch、log file sync大量会话堆积在insert/update上。此时即便我们清楚坏组是哪一个也不能直接drop因为drop不能影响正在被使用或者尚未归档的日志组。我的处理顺序是先查v$log把所有组的状态拉出来按照“添加新日志组-手工切换-强制checkpoint-清理坏组”的顺序来解开死结。如果某个组因为不能归档而卡住比如归档日志目标目录满了还要先处理归档空间否则清完redo组也没用。SQL SELECT destination, status, error FROM v$archive_dest; SQL SELECT name, space_limit, space_used FROM v$recovery_file_dest;如果是闪回恢复区满了扩容或者调整归档策略把可用的日志组轮换出来事情很快就解开。5.2 RAC环境里redo thread被删是另一套逻辑RAC环境比单实例复杂的地方在于每个实例有自己独立的redo thread。v$log查询结果里会出现多个thread编号而被误删的日志组可能只属于某一个节点。这时候如果一个实例的CURRENT redo丢失该实例可能直接宕掉而另一个实例还活着。处理要分两步第一步先让活着的实例接管业务必要时设置service在当前可用节点运行。第二步在故障节点上恢复redo。RAC下添加日志组要指定threadSQL ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 10 (DATA/orcl/redo10a.log, RECO/orcl/redo10b.log) SIZE 200M;删日志组时也要注意thread归属不能用一个实例的会话去删另一个实例的redo thread通常需要连接到对应线程名称的实例或者使用类似以下的写法SQL ALTER DATABASE DROP LOGFILE GROUP 10;这里有一个容易忽略的地方ASM磁盘组里删除文件不能用传统的rm命令很多人是在ASMCMD或RMAN里把redo文件误删的。操作方向不一样但处理逻辑通用——查控制文件、查当前状态、按状态推进恢复。如果故障节点的redo缺失严重到无法自己启动可以把该实例的redo thread重建出来再做实例级恢复。RAC场景下我强烈建议平时就把所有实例的redo文件用OMF或ASM来管理路径统一排查时能省一半时间。5.3 12c多租户架构之下PDB视角的连带麻烦12c的redo日志是CDB级的PDB无法单独配置自己的在线日志。这就带来一个很微妙的问题某个PDB的活跃事务可能正在使用redo而redo被删会波及所有PDB某几个PDB可能瞬间变得不可用。恢复方案上一律在CDB层操作不需要去改任何PDB的redo配置。但因为一个PDB可能有大量业务数据恢复后要重点检查PDB的打开状态和数据一致性。SQL SELECT con_id, name, open_mode, total_size FROM v$pdbs; SQL ALTER PLUGGABLE DATABASE pdb1 OPEN;如果PDB无法打开多半还需要执行PDB级别的恢复操作。这时DBA通常会在CDB里用以下命令SQL ALTER PLUGGABLE DATABASE pdb1 CLOSE IMMEDIATE; SQL ALTER PLUGGABLE DATABASE pdb1 OPEN RECOVER;有一类场景特别容易忽略redo被删后数据库被还原到某个时间点PDB的恢复点可能晚于CDB的导致PDB无法正常打开。遇到这种情况不要反复强制open先检查PDB的undo和状态必要时通过快照或备份单独恢复目标PDB。6. 常见错误速查与DBA的几条保命经验6.1 错误代码速查表我把redo丢失场景中出现频率最高的错误整理成一张表方便现场对照。错误代码含义常见处理方向ORA-00313无法打开指定redo日志文件确认文件路径、检查OS层文件是否存在ORA-00312在线日志组及路径信息常伴随ORA-00313出现结合v$logfile定位丢失的memberORA-00314日志文件头部信息损坏通常需要clear或重建该日志组ORA-00316日志文件类型不对多为控制文件信息与redo不匹配重建控制文件ORA-00321日志无法更新检查文件权限、磁盘空间ORA-00327日志状态与文件实际内容不符大概率需要执行clear unarchivedORA-16038日志无法归档检查归档目标、闪回恢复区空间ORA-19809恢复区空间超限清理过期备份或扩大DB_RECOVERY_FILE_DEST_SIZEORA-27037物理文件不存在OS层面确认文件是否丢失ORA-19588RESETLOGS与备份不匹配执行全备或将备份时间点对齐看到任何一个错误码第一时间先不要急着操作回到v$log和v$logfile去定位具体是哪个thread、哪个group、哪个member坏了再对照本文章的处置方法。6.2 现场自救的几条铁律第一条铁律没有做完整备份评估之前不要做任何破坏性操作。包括drop logfile、clear logfile、resetlogs每一步都要想好“如果这一步失败下一步怎么办”。第二条铁律优先保住控制文件。控制文件是数据库的“目录总索引”redo丢了还有救控制文件也丢了恢复难度直接指数级上升。平时定期把控制文件备份到trace绝对是成本最低的保险。SQL ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS /backup/control_trace_YYYYMMDD.sql;第三条铁律执行CLEAR LOGFILE之前想清楚归档后果。下面这条命令会把日志组标记为不再归档SQL ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 2;这意味着这一段redo对应的数据差异将无法通过备份来恢复。如果业务对数据完整性要求很高这一步必须经过业务方确认。第四条铁律操作完成后马上做全备。任何一次用resetlogs打开数据库都会让此前的日志序列失效旧备份直接不可用不赶紧做全备相当于把自己再次置于无备份的裸奔状态。6.3 我踩过一次最深的坑有一次我按网上资料对一个ACTIVE状态的日志组执行clear logfile结果直接报错ORA-01624: log X needed for crash recovery。这条错误的意思是日志组虽然状态不是CURRENT但实例恢复还需要它不能clear。后来才真正理解决断一个日志组能不能drop或clear不能只看status字段还得看它是否涉及crash recovery。稳妥做法是先ALTER SYSTEM CHECKPOINT把恢复位置前移减少对旧日志组的依赖。如果还是不能clear继续添加日志组并切换直到它彻底脱离关键路径。那次之后我给自己定了一条死规矩处理redo故障时所有影响动作的顺序永远是——先加新组、再切换、再checkpoint、再drop或clear绝不允许跳到第一步。这个顺序看起来笨但每次都能把风险压到最低。现在回顾redo被删这类事故其实最考验DBA的不是SQL命令背得有多熟而是能否冷静判断当前状态、按顺序推进操作。误删文件这种坑谁都不敢保证一辈子不踩但只要我们能把日志组冗余做好、控制文件备份做到位、恢复流程写进预案真遇到时就能把一场灾难变成一个普通的运维日。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
