共 4 篇相关文章
这篇讲的是一个常见的异构容灾场景：很多企业只有一台昂贵的Exadata机器，但为了数据安全，会用一台普通的非Exadata服务器通过Data Guard来搭建备库。官方宣传的EHCC高级压缩特性是否还能正常使用？作者通过实测给出了答案。 测试环境是Oracle 11g，作者在Exadata主库上分别创建了使用BASIC、OLTP以及各种EHCC（Query Low/High， Archive Low/High）压缩的表。关键发现在于，当Data Guard备库是非Exadata环境时，主库的EHCC压缩效率会显著下降。测试数据显示，此时所有EHCC压缩表的数据块大小都膨胀到了接近无压缩的水平，其压缩效果甚至不如简单的OLTP压缩。 作者分析，这很可能是Exadata的一种智能降级机制：当检测到备库不支持EHCC时，主库会牺牲自身的存储性能（高压缩效率）来确保数据在备库的可读性与安全性。因此，在这种异构DG架构下，使用Oracle自带的OLTP压缩或许是更优选择，既能保证容灾，也能获得更好的整体效率。
这篇讲的是如何在 Oracle 11g 数据库中，利用基于 SCN 的增量备份策略来实现精准、高效的数据库恢复。 在生产环境中，数据恢复的核心挑战往往在于备份策略的选择。传统的全量恢复虽然可靠，但耗时漫长，可能影响业务连续性。文章针对这一痛点，详细介绍了利用系统变更号 (SCN) 作为精确恢复点的方法。作者从 Oracle 11g 企业版的环境出发，展示了如何使用 RMAN 工具，通过指定特定的 SCN 来执行增量恢复操作。 这种方法的核心在于，它允许管理员将数据库状态精确地恢复到全量备份之后的某个关键时间点，而无需回放全部的归档日志。摘要中体现了文章的具体技术点，比如基于 SCN 的恢复命令和操作逻辑，其巧妙之处在于将恢复粒度从“时间点”细化到了“事务点”，极大地减少了数据丢失窗口，并提升了恢复速度。最终，这种技术方案为需要灵活应对各类数据误操作或逻辑错误的 DBA 提供了一种强有力的保障工具。
这篇讲的是Oracle MAA（最大可用性架构）的全景式解读。作者从一个核心问题出发：如何设计数据库系统，才能在硬件故障、数据中心灾难等各种场景下，依然保持服务可用甚至不中断？ 文章没有堆砌枯燥的理论，而是将MAA架构拆解为几个关键维度来剖析——从本地高可用的RAC，到数据保护的Data Guard，再到云环境下的综合方案。它把Oracle多年来围绕高可用、容灾和性能优化推出的一系列“武器”清晰地串联了起来，点明了每个组件适合解决什么问题，以及它们如何协同工作形成完整的防护网。 对于正在规划数据库架构或评估容灾方案的工程师来说，这种结构化的梳理非常实用。它帮你快速建立起从单机到集群、从本地到异地的完整认知框架，理解各种技术选择背后的权衡与定位。
这篇讲的是 Oracle 11G 数据库一个相当隐蔽的坑。作者在实际运维中发现，当主库对一张表执行了 truncate 操作后，去物理备库上查询这张表，有时会令人困惑地抛出 `ORA-08103: object no longer exists` 错误。明明对象还在数据字典里，查询却报不存在，这让日常的数据核对和报表生成工作很头疼。 问题的根源被定位到 Oracle 11G 版本中，与实时查询（Active Data Guard）功能相关的一个已知 bug。在特定的操作序列下，备库未能正确同步主库的元数据变更，导致查询时内部检查失败。 解决这个问题主要有两条路：要么为数据库打上官方提供的补丁，要么退而求其次，暂时将 standby 数据库激活为独立库再进行查询。文章点明了这个 bug 的具体表现和应对之策，对于还在维护 11G 系统、并使用 Data Guard 架构的 DBA 来说，是一个需要提前规避的雷区。
