共 2 篇相关文章
本文记录了一次硬件故障后Oracle数据库数据文件大小异常的故障处理案例。硬件恢复后，dbv工具报DBV-00102错误，检查v$datafile_header发现USERS02-USERS05表空间文件头记录大小约8GB，但实际恢复文件仅4GB。初步排查RAID5配置正常，判断为文件系统层面损坏。采用自研OraScan碎片扫描工具从磁盘提取数据块，重建数据文件并通过dbv验证。替换原文件后执行recover database成功，但alter database open时因redo日志序列冲突报错ORA-03113。分析alert日志发现ora-00314错误，显示redo组不一致；鉴于recover已完成，清除异常redo组后数据库正常打开，最终导出数据。此过程突出了Oracle数据文件头检查、碎片扫描技术及redo日志管理在灾难恢复中的关键作用，为硬件故障后数据文件修复提供了实用方案。
这篇讲的是在ORACLE数据库中部署高性能存储设备Fusion-io时，需要权衡的几类关键技术方案。 文章从Fusion-io与SSD的核心差异切入——它采用PCI-E接口，访问路径更短，性能远超传统SSD，但无法使用硬件RAID。作者围绕**数据冗余、存放和高可用**这三个部署核心，逐一拆解了可行方案。在数据冗余部分，对比了从无冗余到RAID10+1等多种基于ASM或LVM的软RAID模式，并坦率分析了各自在成本、可靠性与复杂度上的取舍。 数据存放方案部分尤为实用，不仅讨论了将所有数据、临时文件或重做日志放在ioDrive上的利弊，还重点分析了将ioDrive作为Flashcache的思路。作者指出ORACLE原生Flashcache是安全的读缓存，而Facebook等方案采用的写回模式性能更好但风险更高，并明确将Flashcache视为一个“过渡技术”。 在高可用方面，文章探讨了在RAC架构中结合iSCSI与Infiniband网络的可能性，指出了传统以太网延迟的瓶颈。整体来看，作者没有给出单一“最佳”答案，而是提供了一套决策框架：如果空间足够，全盘存放性能最佳；若热点明确，手动分层更可控；而Flashcache等技术的采用则需谨慎评估系统复杂度与风险。
