共 3 篇相关文章
本文详细记录了一次因断电引发的Oracle数据库故障恢复全过程。数据库在断电后异常，现场恢复未能成功打开库。作者接手后，尝试recover操作报ORA-16433错误，分析alert日志发现此前有强制OPEN RESETLOGS操作，但导致redo日志缺失并触发ORA-600 2662内部错误，该错误与系统变更号（SCN）不一致相关。恢复步骤包括：首先重建控制文件，但再次recover时遇到redo日志损坏（ORA-00353），媒体恢复失败。鉴于正常恢复路径受阻，决定强制打开数据库，并使用Patch_SCN工具调整SCN值至特定数值以解决ORA-600 2662问题。调整后数据库成功打开。随后在数据导出阶段，expdp命令遇到硬件错误，为安全起见切换至只读模式下使用exp工具，最终成功导出所有数据，完成恢复任务。此案例展示了处理断电导致的Oracle复杂故障的关键技术，包括日志分析、控制文件重建、SCN调整和数据导出等步骤。
本文记录了Oracle数据库断电后因第三方恢复操作导致现场混乱的实战恢复过程。通过Oracle Database Recovery Check工具初步分析，发现数据库被强制resetlogs，三个数据文件丢失，数据文件头SCN不一致且在非归档模式下。恢复团队使用obet工具的get_dbinfo功能解析磁盘上所有.dbf文件头，识别出文件号重复，结合文件大小和SCN信息判断正确文件，确认两个丢失文件为undotbs1表空间文件，另一个为112k的小文件。文章通过SQL实验验证Oracle数据文件最小为16个block。恢复步骤包括：修改正常文件SCN，重建控制文件（丢弃损坏的undo文件），设置undo为manual管理并屏蔽回滚段，强制打开数据库时遇到ORA-600 2662错误，使用Patch_SCN工具调整SCN后成功打开数据库。最后，新建undo表空间、添加temp文件、删除旧undo对象，并导出数据完成恢复。案例突出了工具辅助、文件头分析和错误处理在复杂数据库恢复中的关键作用。
这篇讲的是，在使用了ASM自动存储管理的Oracle数据库环境中，如何避免因默认只创建一个控制文件而带来的潜在风险。对于使用ASM存储的数据库，如果初始仅创建了一个ASM磁盘组，控制文件会默认只有一个副本，这违背了多副本冗余保障数据库安全的最佳实践。 作者从这一常见配置问题出发，指出了其中的安全隐患。文章的核心在于提供一套具体的配置方法，指导读者如何在ASM磁盘组中，将控制文件配置为多个独立的物理副本。这涉及到对ASM存储特性的理解和相应的管理操作。 通过遵循文中所述的操作步骤，管理员能够轻松地在ASM环境下为控制文件建立多重保护。这确保了即使某个控制文件所在的磁盘组或文件发生损坏，数据库依然能够依靠其他副本保持稳定运行，有效提升了系统的可用性与容灾能力。
