ORA-19735报错控制文件和数据文件SCN不匹配，远程帮忙修复思路分享

ORA-19735报错控制文件和数据文件SCN不匹配，远程帮忙修复思路分享

当数据库同事或客户在远程寻求帮助，告知遇到了ORA-19735错误时，这通常意味着一个比较紧急的情况，这个错误的本质是Oracle数据库在启动或恢复过程中，发现控制文件里记录的某个数据文件的SCN（系统变更号，可以理解为数据库的一个时间戳）与数据文件头里记录的SCN对不上，就是数据库的“大脑”（控制文件）和“身体部件”（数据文件）在“时间线”上不一致了，数据库因此无法确认数据的一致性,从而拒绝启动。

面对这种情况，远程协助的关键在于冷静分析，逐步排查，并选择风险最小的方案，由于无法直接操作服务器，清晰的沟通和准确的指令传递至关重要,以下是一套常见的远程排查和修复思路。

第一步：确认错误详情与环境信息

不能只听一个错误代码就开始操作,需要请求对方提供更详细的信息。

1. 获取完整的错误信息：ORA-19735通常会伴随其他错误，比如ORA-01110、ORA-01122等，让对方提供在startup命令后屏幕上显示的全部错误文本，这能精确指出是哪个数据文件（通过文件编号和文件名）出了问题。
2. 了解操作背景：询问在报错之前进行了什么操作？是服务器意外断电重启？是做了不完全恢复尝试？还是误删了文件后从备份恢复？操作背景是判断问题根源的最重要线索，如果是断电导致的，很可能是文件写入不完整；如果是恢复操作失误,则可能是文件版本混用。
3. 确认备份情况：立即询问是否有可用的有效备份？包括但不限于：
   • 控制文件备份：是否有通过alter database backup controllerile to trace生成的脚本或多路复用的控制文件副本？
   • 数据文件备份：是否有近期的RMAN（Oracle的备份恢复工具）备份或冷备份（数据库关闭状态下的文件拷贝）？
   • 归档日志：归档日志是否连续且完整？这对于恢复至关重要。

第二步：尝试无损的检查与修复

在确认有备份兜底的前提下,可以先尝试一些相对安全的操作。

1. 尝试使用备份的控制文件：如果怀疑当前控制文件已损坏或不一致，并且有多路复用的副本，可以指导对方在数据库nomount状态下，用其中一个副本来替换当前有问题的控制文件，然后再次尝试recover database和alter database open,有时一个完好的控制文件副本就能解决问题。
2. 使用recover命令进行自动修复：很多时候，Oracle的恢复机制可以自动解决这种SCN差异，可以指导对方执行以下命令序列：

   SQL> shutdown immediate;
   SQL> startup mount; （将数据库启动到挂载状态，但不打开）
   SQL> recover automatic database; （让数据库自动应用归档日志和重做日志来进行恢复）

   如果恢复过程成功应用了所有必要的日志，最后会提示“Media recovery complete”，这时再执行alter database open;，很可能就成功了,这是最理想的情况。

第三步：当自动恢复失败时的进阶处理

如果上述recover命令失败或无法完成，说明SCN差距较大或日志不完整,需要更深入的操作。

1. 基于取消的恢复：如果错误是由于意外的事务中断导致文件头SCN落后，可以尝试让数据文件“穿越”到与控制文件一致的SCN，这需要使用recover database until cancel命令，但这种方法需要谨慎，因为它会丢失一些数据。仅在确认丢失的数据可接受时使用，操作后，需要用resetlogs方式打开数据库，这会重置日志序列,并需要立即进行全备份。
2. 从备份中恢复数据文件：如果确定是某个数据文件本身损坏或版本不对（误用了旧的备份文件），最稳妥的方法是从有效备份中恢复这个特定的数据文件，使用RMAN的流程大致是：
   • RMAN> target /
   • `RMAN> sql 'alter database datafile <文件编号> offline';' （将问题数据文件脱机）
   • RMAN> restore datafile <文件编号>; （从备份还原该文件）
   • RMAN> recover datafile <文件编号>; （应用归档日志,前滚这个文件）
   • `RMAN> sql 'alter database datafile <文件编号> online';' （将文件重新联机） 完成后，数据库就可以正常打开了,这种方法能保证数据最大程度不丢失。

第四步：最后的手段——重建控制文件

如果以上方法都无效，尤其是控制文件本身问题很大且没有完好副本时，就需要考虑重建控制文件,这是风险较高的操作。

1. 获取重建脚本：如果之前有通过alter database backup controllerile to trace生成过跟踪文件，可以在udump或diag目录下找到它，这个脚本包含了重建控制文件所需的全部信息（数据文件、日志文件列表等）,指导对方找到并使用这个脚本。
2. 手动创建脚本：如果没有跟踪文件，就需要根据当前的数据文件和日志文件列表，手动编写CREATE CONTROLFILE命令，这需要对方提供所有数据文件、重做日志文件的绝对路径，命令中可以使用RESETLOGS或NORESETLOGS选项，通常先尝试NORESETLOGS。
3. 执行重建：在数据库nomount状态下，运行重建控制文件的脚本，成功后，必须按照提示以resetlogs方式打开数据库，并立即进行全库备份。

远程协助的注意事项

在整个过程中,远程协助者要时刻注意：

• 指令清晰：每一步SQL命令或系统命令都要准确无误地传达,并让对方复述确认。
• 备份优先：在执行任何有潜在风险的操作（尤其是resetlogs）前，再三确认对方是否已备份了所有当前的文件（数据文件、控制文件、日志文件）,以备回滚。
• 记录操作：要求对方记录下执行的每一条命令和输出结果,便于分析。
• 管理预期：明确告知对方每种方案的可能结果和风险，特别是可能的数据丢失情况,让客户或同事做出知情选择。

处理ORA-19735错误是一个需要耐心和细心的过程，远程协助的核心在于通过有效沟通，像侦探一样根据有限的信息拼凑出问题全貌，然后按照从简到繁、从安全到冒险的顺序进行尝试,最终目标是让数据库在保证数据损失最小的前提下重新提供服务。