数据库是否应该过分依赖灾难恢复

数据库管理-第369期 数据库是否应该过分依赖灾难恢复（20250929）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE

10年数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著名社恐（社交恐怖分子）

公众号：胖头鱼的鱼缸
CSDN：胖头鱼的鱼缸（尹海文）
墨天轮：胖头鱼的鱼缸
ITPUB：yhw1809
IFClub：胖头鱼的鱼缸
除授权转载并标明出处外，均为“非法”抄袭

本文以Oracle数据库为例。
当诸位DBA去新接触一套的数据库时，最怕的是什么：

• 是找不到软件路径？但是大多数Oracle数据库的环境变量还是能查到端倪
• 是不知道密码？无论是操作系统还是数据库其实都还有些办法可以处理
• 是不了解参数？其实主要是要去查一下那些被修改过的隐藏参数的意义
• …

在我看来最可怕的事情，莫过于数据库即没有各种形式的备份，也没有开启归档日志（当然开启了归档但没有force logging，附加各种nologging的骚操作也会增加一些上手难度）。回到文章开始既然是新接触的数据库，如果没有问题还好，及时开启归档并配置合理的备份即可（没钱、没资源、无所谓的地方除外），怕的就是正好遇到了数据层的问题或者本就是来应急的，大多数人会无从下手。

实话说，在硬盘级故障通过硬件级恢数据复以外，数据库圈内是有一些大能能够以很多方式尽可能的恢复数据：一些可以想方设法拉起数据库、处理坏块并恢复其余正常数据；有些则可以比肩原厂，数据库拉不拉起来无所谓，仅通过数据文件即可执行数据恢复操作。

当然，这些都是非常极端的情况，作为一个DBA，或者数据库架构的设计者，是要尽可能确保不出现这种情况，或者又非常之法外的应急手段。从Oracle数据库本身来说，可以使用ADG来避免数据层遇到问题，针对坏块主备之间可以互相自动修复；要是主备之间都有问题呢，基于exp/expdp或者RMAN（全量、增量、差异、日志等）的离线备份也是很有必要的，只是真遇到问题需要更久的恢复时间，但是总归有一个可恢复的地方；但如果整个机房甚至整个IDC都出现异常该怎么办，跨IDC容灾、多地备份则能解决（别扯地球毁灭那种污糟事，那种情况下月球有备库也没用）。

除去数据库本身，硬件也能解决不少问题：Oracle提供的RAC集群架构可以通过多台服务器同时提供服务避免数据库服务器的单点故障；但是存储故障带来的爆炸范围还是很恐怖的，不怕存储本身也能双机双活（甚至是跨机房跨IDC，可配合Extended Cluster）；健壮的数据库集群需要稳定的网络，主备交换机配合活动主备、多路聚合、多路多活等网络配置方式是可以提供安全稳定的网络的；怕停电？IDC多路供电、安全隔离的应急电源（最近锂电起火难扑灭的事情太多了）、可持续的发电机都能应对各种突发情况；怕高温和起火？液冷机房和气体灭火了解一下…

怕数据库和数据出问题，需要数据库本身、软硬件架构设计结合日常巡检、监控与维护，避免出现问题或降低出问题的概率，而不是当真出问题的时候，通过一系列看似高超的手法去九转还魂，实则严重影响数据库承载的业务。不出问题永远最好的状态，奈何很多地方一直觉得处理严重故障才能彰显实力。

最后，再扯一下大环境本身：一方面是数据库国产化，众所周知现在的国产数据库大多在各方面还比不过Oracle，遇到棘手问题有时候甚至原厂都不一定能解决，这个还需要整个行业一起努力，短期实现和长期目标来看所谓灾难恢复也就变得不那么重要了；另一方面则是AI的到来，将来一定有不少DBA原有的简单的比如巡检、监控和简单故障处理等操作可以交给AI，DBA可以着重去解决数据库高可用并应对业务带来的问题，这样就更不需要可以的去做灾难恢复了。

最后，既然提到了AI，我最近写文章（特别是非纯技术类的）也利用的AI进行润色，但是本文，我保证全手打，无AI。因此最后，老规矩，不知道写了些啥。