带你慢慢摸索Oracle归档模式那些不太好说清楚的细节和用法

很多人刚接触Oracle数据库时,都会学到数据库有两种模式：非归档模式（NOARCHIVELOG）和归档模式（ARCHIVELOG），书本上会说，非归档模式只能做完全恢复（比如恢复到上次备份的点），而归档模式可以做不完全恢复（比如恢复到某个时间点），并且能实现零数据丢失，这个道理听起来简单，但实际操作和深入理解时，会遇到一些书本上不太强调、但又很关键的细节。

第一个不太好说清楚的细节是：开启归档模式的最佳时机和它带来的“静默”变化。

理论上,你可以在数据库创建后的任何时候开启归档模式，但老DBA通常会建议在数据库建好之初、还没投入正式业务使用前就把它打开，为什么呢？因为一旦数据库跑着重要的业务，再想从非归档模式切换到归档模式，你需要先关闭数据库，然后以“mount”状态（而不是“open”状态）启动，再执行切换命令，最后重新打开数据库，这个过程中数据库是不可用的，虽然时间不长，但对于7x24小时运行的业务系统来说，安排一次停机窗口可能很麻烦。

更关键的是那个“静默”变化：开启归档模式本身只是一瞬间的事，但它意味着数据库的后台行为发生了根本性改变，在非归档模式下，当重做日志文件（Redo Log File）写满后，LGWR（日志写入进程）会切换到下一个日志文件，而被写满的那个文件，其内容可以被直接覆盖重用，你可以想象成一个循环使用的录音带，但在归档模式下，当LGWR进程要切换到一个已经被写满的日志文件时，数据库会“刹车”，它会等待，直到ARCn（归档进程）把这个写满的日志文件完整地复制一份到指定的归档日志目的地之后，才允许LGWR覆盖这个旧文件，这个等待是必须的，因为它保证了所有历史的数据库变更记录都被永久保存了下来，如果你不小心把归档目的地设置成一个空间不足的磁盘，这个等待就会一直持续，导致数据库事务完全挂起，这是生产环境一个非常严重的故障点，开启归档不仅仅是开个开关，更是背上了一个需要持续维护的“甜蜜的负担”。

第二个细节是关于归档日志的命名和管理的“琐碎烦恼”。

Oracle会自动生成归档日志的文件名,默认通常包含日志的序列号、线程号等信息，这看起来很规范，但问题就出在管理上，这些文件会源源不断地产生，一天下来可能就有几十GB甚至更大，你需要确保归档目的地有足够的空间，否则我们上面提到的“数据库挂起”就会发生。

这时就会引出一个核心操作：备份归档日志并删除已备份的日志，这是DBA日常工作中非常重要的一环，很多新手会问：“我直接用操作系统命令rm删掉不行吗？” 答案是：强烈不建议！因为Oracle的控制文件里记录着所有产生过的归档日志的信息，如果你手动删除，控制文件并不知道，它会认为那些文件还存在，当你使用RMAN（Oracle的备份恢复工具）进行恢复时，RMAN会去控制文件里查清单，然后去找对应的文件，如果找不到，恢复就会失败。

正确的做法是使用RMAN命令来删除。RMAN> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7'; 这个命令的意思是删除所有7天前生成的归档日志，RMAN在执行删除前，会先更新控制文件，标记这些日志为已删除，这样后续的恢复操作就不会再试图寻找它们了，还有一种更常见的做法是在执行备份时，直接加上DELETE INPUT或DELETE ALL INPUT选项，RMAN> BACKUP ARCHIVELOG ALL DELETE INPUT; 这条命令会备份所有归档日志，并在备份成功后自动删除它们，一气呵成，这种“琐碎”的管理，恰恰是保证归档模式能持续健康运行的关键。

第三个细节是很多人对“恢复”理解的偏差，尤其是时间点恢复。

大家都知道归档模式能恢复到过去某个时间点,但这个“时间点”到底是什么？它不仅仅是钟表上的时间，在RMAN命令中，你可以用多种方式指定这个点：

• 直到某个具体时间：UNTIL TIME "TO_DATE('2023-10-27 15:30:00','YYYY-MM-DD HH24:MI:SS)'"
• 直到某个日志序列号：UNTIL SEQUENCE 12345 （你知道在序列号12345之后发生了误操作）
• 直到某个SCN（系统变更号）：UNTIL SCN 8848 （这是数据库内部最精确的变更顺序标识）

这里容易混淆的是,我们常说的“恢复”其实包含两个步骤：RESTORE（还原）和RECOVER（恢复）。RESTORE 是用之前的备份文件（数据文件备份）覆盖当前的数据文件，相当于把数据文件“倒带”到备份的那个时间点，而 RECOVER 才是真正发挥归档日志威力的地方：它会把从备份点之后产生的所有归档日志（以及可能还有的在线重做日志）重新应用（Reapply）到数据文件上，让数据文件一步步“快进”到你指定的那个时间点、序列号或SCN。

一个典型的时间点恢复操作是：先RESTORE DATABASE UNTIL TIME ...，RECOVER DATABASE UNTIL TIME ...，很多人会忽略这两个命令的协作关系，以为一个命令就搞定了。

第四个细节是关于“闪回”技术和归档模式的关系。

Oracle的闪回数据库（Flashback Database）功能非常强大，它能快速将整个数据库回退到几分钟、几小时甚至几天前的状态，速度通常比传统恢复快得多，它是不是取代了归档模式？恰恰相反，闪回数据库功能必须依赖于归档模式才能工作！

你可以把闪回数据库理解成一种“超级撤销”，它在后台会定期将数据文件的变化块（映像）记录下来，形成“闪回日志”，当执行闪回时，它并不是去应用归档日志，而是反向应用这些闪回日志，闪回日志并不能保证覆盖所有的时间范围，而且它的开启和有效，前提条件是数据库必须处于归档模式，闪回技术和传统的归档日志恢复是互补的：对于近期的、快速的回退，用闪回；对于更早的、或者需要精确到某个SCN的恢复，还是得用归档日志，它们共同构成了Oracle数据库强大的数据保护伞。

归档模式绝不是一个简单的理论概念,从开启时机的选择到日常的空间管理，从对恢复过程的深入理解到与现代功能（如闪回）的协同工作，里面充满了需要亲手实践才能深刻体会的细节，忽视这些细节，可能会让归档模式从一个数据保护神，变成一个随时可能引爆的“炸弹”。