1. 归档模式到底解决了什么问题从一次数据库故障说起做Oracle DBA这些年我遇到过不少因为没开归档模式而把团队逼到墙角的场景。印象最深的一次是刚接手某套业务系统时凌晨三点接到电话说数据库起不来了检查发现控制文件和联机重做日志全部损坏。因为这套库一直跑在非归档模式最后一次全备还是两个月前做的也就是说恢复出来会丢掉整整两个月的业务数据。当时那种头皮发麻的感觉到现在都记得。这就是归档模式的价值所在——它解决的是数据库文件不幸全坏之后数据究竟能找回多少的问题。非归档模式下数据库只保留当前正在使用的联机重做日志Online Redo Log日志切换后会直接覆盖旧日志历史操作记录根本存不下来。一旦数据文件损坏你手里的恢复介质只有之前做过的全量备份备份之后的所有变更全部丢失。而开启归档模式后系统会将每次切换出来的联机日志完整复制到指定目录形成连续的归档日志Archive Log。配合全量备份你可以在任何时间点把数据库恢复到过去的某个状态丢失窗口被压缩到几乎为零。简单说归档模式就是给数据库的操作流水账加了一份永不删除的备份。这份流水账既用于介质恢复也支撑DataGuard容灾构建、逻辑误操作找回、基于时间点的恢复等关键场景。对那些数据是核心资产的企业这几乎等于保险单。对个人学习者来说理解并掌握归档模式的操作也是从会装数据库迈向会管数据库的必经之路。这篇文章我会从实际运维视角出发手把手讲清楚三件事当前数据库处于什么模式、如何安全开启归档模式、开启后还要配套做好哪些设置和监控。最后再把我在实际环境中踩过的一些坑和排查思路一并整理出来。2. 登录数据库先看三处判断当前是否处于归档模式在动手做任何配置之前第一步永远是确认现状。Oracle判断实例是否处于归档模式主要通过三个途径来查看结果是一致的但适用场景略有不同。2.1 用archive log list命令快速确认这是最直接、最快的方式。以sysdba身份登入数据库执行sqlplus / as sysdba SQL archive log list;正常情况下输出类似这样Database log mode No Archive Mode Automatic archival DISABLED Archive destination /u01/app/oracle/oradata/ORCL/archive Oldest online log sequence 10 Next log sequence to archive 12 Current log sequence 12重点看第一行和第二行。Database log mode显示No Archive Mode说明当前是非归档模式如果显示Archive Mode则说明已经开启。Automatic archival一栏对应的是数据库是否启用了自动归档生产环境必须保持ENABLED状态否则即使开了归档模式日志切换时也不会自动生成归档文件等于白开。这一命令的本质是读取控制文件里的数据库属性和当前日志状态所以它不需要数据库处于open状态也能执行在mount阶段同样可用。这给后续开启归档过程中的反复确认提供了很大便利。2.2 查询v$database视图确认模式如果你习惯用SQL来确认可以查询SQL select name, log_mode, open_mode from v$database; NAME LOG_MODE OPEN_MODE --------- ------------ ------------ ORCL ARCHIVELOG READ WRITELOG_MODE字段只有两种取值ARCHIVELOG和NOARCHIVELOG分别对应归档模式和非归档模式。OPEN_MODE用来辅助确认库当前的打开状态——做归档切换操作时数据库必须处于MOUNTED状态才算进入可变更阶段这个等下讲开启步骤时会详细展开。v$database视图查询有个小细节通常只是select log_mode的话普通用户也能执行但如果是整个视图全字段查询部分版本会要求具备足够权限。实际使用中如果遇到用户权限不足的报错直接用sys用户查即可。2.3 检查后台进程和归档文件目录还有一个辅助确认手段查看是否存在归档后台进程。非归档模式下数据库不会有ARC0之类的归档进程开启归档后通常能看到类似ora_arc0_ORCL的进程在运行。ps -ef | grep ora_arc | grep -v grep如果没有任何输出大概率还是非归档模式。另外也可以顺带看一眼归档目录里有没有已生成的.arc或.dbf格式的归档日志文件。目录位置受log_archive_dest或db_recovery_file_dest参数控制后文会专门展开说明。这三种方式本质上是从控制文件、动态性能视图、操作系统进程三个不同视角去确认同一个事实。日常巡检我习惯先跑archive log list因为它信息量最全、最快如果需要写脚本做自动化检测则用v$database视图更规范当怀疑归档进程异常时结合进程检查能更快定位问题。3. 从非归档切到归档的完整操作关键一步是重启到mount状态确认当前是非归档模式之后开启归档的过程并不复杂但操作顺序一旦错乱轻则报错重则影响可用性。完整流程分为四步关闭数据库、启动到mount状态、切换归档模式、打开数据库。下面逐步拆解。3.1 第一步干净地关闭数据库实例执行开启归档操作前需要先关闭数据库实例。这里必须用干净关闭clean shutdown方式也就是SQL shutdown immediate;shutdown immediate会回滚未提交事务、断开所有会话连接、关闭实例整个过程不会产生实例恢复动作数据文件、控制文件完全一致。不建议用shutdown abort因为那相当于强制断电下次启动会走崩溃恢复流程虽然数据不会丢但会让下面的操作多出很多不确定性。如果数据库中还有活跃的长时间事务shutdown immediate可能会等待事务回滚完成耗时较长。这时可以通过v$session视图查看哪些会话还没断开必要时与业务方确认是否可以强制终止会话。生产环境做这种操作前一定要提前发变更通知避免业务侧不知情的情况下连接被掐断。3.2 第二步启动到mount状态让实例读取控制文件数据库关闭后执行SQL startup mount;这一步的作用是启动实例并装载数据库但没有打开数据文件。mount阶段下Oracle可以访问控制文件从而识别数据库结构但这个状态下业务无法访问数据。开启归档模式本质上是修改控制文件中记录的数据库持久化属性所以必须在这个阶段操作。直接以open状态尝试执行alter database archivelog一定会报ORA-01126之类的错误。startup mount执行成功后可以用之前的archive log list再次确认一遍当前还是非归档状态顺便注意Current log sequence这个数值方便后续对比。3.3 第三步执行alter database archivelogmount状态下执行SQL alter database archivelog;这一条命令是整个过程的核心。它的作用是把数据库的日志模式从非归档切换为归档模式并同步更新控制文件里对应的属性。执行成功后再跑一次archive log list会看到Database log mode Archive Mode Automatic archival ENABLED到这里归档模式已经开启。注意此时数据库还处于mount状态业务还不能访问需要继续下一步把数据库打开。3.4 第四步打开数据库并做基本验证执行SQL alter database open;数据库正常打开后建议做一轮验证确认归档链路是真的通的执行archive log list确认模式为Archive ModeAutomatic archival为ENABLED。手动触发一次日志切换观察归档文件是否真的生成SQL alter system switch logfile;查看归档目录确认新生成的文件时间戳是刚才切换的而不是老旧的遗留文件。这三步做完才算真正完成了归档模式的开启。很多初学者执行完alter database archivelog就以为大功告成结果忘了检查Automatic archival是否为ENABLED或者忘了确认归档文件实际落盘等到需要恢复时才发现归档链路根本没通那时候就非常被动了。整个操作流程对库里数据没有任何影响挂载和打开的过程也不会触发数据搬迁时长主要取决于shutdown immediate的收尾速度。对正常业务库而言整个过程一般在几分钟内就能完成但前提是提前做好业务停机窗口的沟通。4. 开启归档后的首选配置归档路径、格式与闪回区规划很多文章讲完alter database archivelog就收笔了但以我的运维经验来看真正拉开新手和熟手差距的恰恰是归档开启之后这一堆配套参数。归档模式只是给了你一颗种子怎么把归档日志这个东西管好让它既安全又不撑爆磁盘才是后续运维的重头戏。4.1 归档路径参数log_archive_dest与log_archive_dest_nOracle归档日志要写到哪个目录并不是自动分配的而是由参数决定。最经典的参数是log_archive_dest指定一个本地目录SQL alter system set log_archive_dest/u01/arch/orcl scopeboth;生产环境我强烈建议用log_archive_dest_n系列参数它可以同时配置多个归档路径实现冗余SQL alter system set log_archive_dest_1location/u01/arch/orcl mandatory scopeboth; SQL alter system set log_archive_dest_2location/u02/arch_backup optional scopeboth;其中mandatory表示这个归档路径是强制的日志必须成功归档到这里否则日志切换会被阻塞optional表示可选路径归档失败不影响日志切换。为了数据安全主路径建议设置成mandatory备份路径设置为optional这样既能保证核心归档一定落盘又不至于因为备份盘故障拖累整个库。需要留意一点如果设置了多个归档路径Oracle要求至少有一个路径标记为mandatory。如果全部是optional系统会隐式将其中一个视为强制路径但这种隐式行为容易产生误解不如显式配置来得清晰。4.2 归档文件命名格式log_archive_formatlog_archive_format参数控制归档日志的文件名格式。默认格式在不同版本里略有差异但常见形式类似arch_%t_%s_%r.arc其中%t代表线程号RAC环境多个实例时为1、2、3...%s代表日志序列号%r代表resetlogs ID。建议保持默认不要轻易改动。这里重点提醒如果数据库发生过不完全恢复并使用了resetlogs日志序列号会重置%r能让你区分不同世代的同序列号日志这对恢复路径的选择至关重要。4.3 闪回恢复区db_recovery_file_dest_size的合理性归档日志既可以写到log_archive_dest指定的路径也可以写到数据库的快速恢复区Fast Recovery Area后者由db_recovery_file_dest和db_recovery_file_dest_size两个参数控制SQL alter system set db_recovery_file_dest/u03/fra scopeboth; SQL alter system set db_recovery_file_dest_size512G scopeboth;这里有个非常经典的坑默认情况下如果设置了快速恢复区那么log_archive_dest即使配置了归档日志也可能优先写到快速恢复区。准确说在Oracle 10g之后如果不显式指定log_archive_dest_n归档日志的默认落点就是快速恢复区。很多DBA只设置了db_recovery_file_dest没设置db_recovery_file_dest_size或者大小设置得过小结果归档日志写满恢复区后整个数据库直接hang住任何提交操作都动不了。这是我见过最多的开完归档后库突然卡死的原因没有之一。所以我的建议是要么完全走log_archive_dest_n指定独立目录要么完全走快速恢复区并做好db_recovery_file_dest_size的空间规划。规划时不能只看当前库有多大数据量要按一天产生多少日志量 × 预期保留天数去估算。举个例子如果业务高峰期每小时产生10GB日志一天就是240GB保留三天至少需要720GB此时设置db_recovery_file_dest_size1024G并配合定时备份清理才合理。快速恢复区里的空间是共享的不仅归档日志会占控制文件自动备份、RMAN备份集都可能占用所以预留空间时一定要留出至少30%的余量。另外还有一个容易被忽略的参数db_flashback_retention_target。如果数据开启了闪回数据库Flashback Database功能快速恢复区还需要额外承载闪回日志。这部分空间需求和归档日志相互叠加配置时需要一并考虑。4.4 归档空间满了会发生什么理解LGWR的阻塞机制关于归档空间满这个问题值得多说几句。很多刚接触Oracle的人会有一个错误认知归档目录满了最多就是归档不写而已数据库还能正常跑。实际情况完全不是这样。当mandatory归档路径写不进去时LGWR进程在日志切换时无法完成归档确认这时日志切换会被阻塞然后又因为日志无法复用整个数据库的DML操作会被卡住表现为所有写事务全部挂起只有读操作还勉强能执行。这个状态非常危险因为一旦出现连正常的shutdown immediate都可能因为活跃事务挂起而无法顺利完成。因此开启归档模式后监控归档空间使用率是第一优先级的事情。常见的监控手段是查询v$archive_dest视图看归档目标的状态结合操作系统层面的磁盘空间监控双管齐下SQL select destination, status, error from v$archive_dest where statusVALID;当磁盘使用率达到80%以上时就要着手清理超过90%时必须介入处理。清理手段包括用RMAN删除已备份的归档日志、调整归档保留策略、扩容磁盘或增加新的归档路径。具体做法后面第六部分会详细说。5. 归档模式上线后的维护清单监控、清理与备份策略把归档模式开起来只是第一步真正的挑战在于日复一日地维护它。归档日志这个文件类型比较特殊——它永远在产生而且只增不减如果不做清理再大的磁盘也会有被写满的一天。这里列一份我个人日常维护归档环境的清单照着做基本不会出大问题。5.1 监控归档生成速率与空间消耗归档生产速率的监控可以结合两个层面来查一个是基础视图一个是操作系统层面。在Oracle里归档日志的生成记录存在v$archived_log视图中可以按天统计生成量select trunc(completion_time) day, count(*) cnt, round(sum(blocks*block_size)/1024/1024/1024,2) gb from v$archived_log group by trunc(completion_time) order by day desc;另外v$log_history视图记录了每一次日志切换的历史信息通过对比first_time的间隔可以评估日志切换频率。如果切换频率异常高比如每几分钟就切一次可能导致归档文件碎片化严重还会加大数据库的检查点压力。正常情况下建议日志切换间隔至少在15到30分钟以上如果切换过于频繁就要考虑增大联机日志文件的大小或者检查是否存在业务量暴增、某些操作反复刷日志的问题。5.2 定时清理归档日志的两种稳妥做法清理归档日志的手段主要有两种一种是手工用RMAN删除已经安全备份的归档文件另一种是配置归档日志删除策略让数据库更自动化地去管理。这里我重点强调一个原则清理归档日志必须以已经被备份或已被DataGuard端同步为前提绝不能无脑按时间或数量删除。手工清理的典型RMAN命令RMAN delete archivelog all completed before sysdate - 7;这条命令会删除7天之前的全部归档日志。风险在于如果这7天内的全备或增量备份还没做删除之后就失去了基于时间点恢复的能力。更稳妥的写法是RMAN delete noprompt archivelog all backed up 2 times to device type disk completed before sysdate - 3;它只删除已经被备份过至少2次、而且生成时间在3天之前的归档。注意backed up 2 times是RMAN备份记录如果从来没做过RMAN备份这个条件不会匹配也就不会误删任何文件。如果配置了快速恢复区还可以使用Oracle的归档日志删除策略RMAN configure archivelog deletion policy to backed up 1 times to device type disk;配置了删除策略后当快速恢复区空间不足时Oracle会按照策略自动选择可删除的归档文件优先清理已备份的副本减轻人工干预压力。这对7x24的生产系统非常友好。5.3 归档日志与RMAN备份的节奏配合开了归档模式后RMAN备份的核心思想就变成了全量增量归档日志的组合拳。一套比较通用的备份策略大致如下每周日凌晨做一次0级全备level 0每天晚上做一次1级增量备份level 1每30分钟或1小时备份一次归档日志backup archivelog备份动作完成后按策略删除已备份的归档这样做的好处是一旦数据文件损坏可以先恢复最近的全备再应用增量备份最后追补最后的归档日志实现数据库恢复到故障前一刻。没有归档日志支撑的RMAN备份只能恢复到备份完成的时间点两者能力差距天差地别。如果你在搭建DataGuard环境归档日志的传递是主备同步的根基。主库的归档进程需要将日志传到备库节点备库再通过MRP进程应用日志。这种场景下主库归档日志的清理策略还要考虑备库是否已经接收到对应日志通常可以用delete archivelog all completed before sysdate - 1结合备库同步校验来操作避免主库日志清得太快备库还没来得及拉走。5.4 定期做一次真实恢复演练无论配置多完善没有经过验证的备份和归档链路在真正出故障时都不敢保证能用。我的习惯是每季度找一台测试机做一次完整的恢复演练先用RMAN把最近的全备恢复到测试环境再应用最近的增量备份最后追补归档日志打开数据库对比生产环境的关键数据记录是否一致。这个流程看着简单但一旦实际执行经常能发现备份脚本里路径写错、归档日志有缺失、参数文件不完整等平时根本暴露不出来的问题。归档模式的开启只是给数据安全提供了一个基础设施只有当恢复链路全程畅通时这个基础设施才真正有意义。6. 归档开启过程中常见的三个坑与排查思路我接触过的Oracle环境五花八门从11g到19c都有开启归档模式的操作大同小异但踩坑的姿势几乎总是那么几个。这里把我遇到频率最高、也最容易让人困惑的三种情况整理出来每个都给到完整的排查思路。6.1 第一个坑ORA-00265错误实例恢复需要被强制执行这个报错长这样ORA-00265: instance recovery required, cannot set ARCHIVELOG mode出现这个错误的场景通常是数据库上次不是正常关闭的比如环境断电或执行过shutdown abort重新启动后发现要做实例恢复此时直接startup mount再执行alter database archivelogOracle会阻止你切换。发生原因也很简单数据库处于需要实例恢复的状态控制文件记录的日志应用进度还没走完直接改归档模式会让恢复过程变得不干净。正确的操作方式是先正常打开数据库一次SQL startup;Oracle会自动执行崩溃恢复等库正常open后再shutdown immediate然后走标准的mount切换流程。如果startup因为其他原因起不来则要结合alert.log定位具体阻塞点。6.2 第二个坑归档路径没有提前建好或者权限不对日志切换归档时如果归档目录不存在或Oracle用户没权限写入会出现ORA-19504或ORA-16038系列错误比如ORA-16038: log 1 sequence# 100 cannot be archived ORA-19504: failed to create file /u01/arch/orcl很多人执行完alter system set log_archive_dest/u01/arch/orcl之后没有在操作系统层面手动创建这个目录也没有授权给Oracle用户结果日志一切换就直接报错。这是开启归档后最早可能出现的问题之一。排查思路很简单确认目录是否存在ls -ld /u01/arch/orcl确认属主和权限目录须属于oracle用户或oinstall组并且有写权限如果是ASM磁盘组路径则需要确认磁盘组已挂载且有足够空间正确的姿势是在配置参数前就把目录建好mkdir -p /u01/arch/orcl chown oracle:oinstall /u01/arch/orcl chmod 750 /u01/arch/orcl我对这种问题的态度是宁可事前多敲三条命令不要事后半夜查告警。创建目录、授权、再配置参数这个顺序别反过来。6.3 第三个坑归档日志切换失败数据库hang住不动这个属于严重事故级别的坑了症状是整个库写操作全部挂起操作日志里全是等待事件的堆积。根本原因基本就是归档目录满了或者归档目标路径不可用导致日志切换阻塞。此时LGWR无法完成日志切换所有提交都悬着。遇到这种情况正确的排查链路是第一步查看归档目标状态SQL select dest_id, destination, status, error from v$archive_dest;如果status不是VALID且error列有内容说明归档目标异常。第二步查看操作系统磁盘空间df -h如果空间满了立即清理。清理方式是在确认归档日志已经安全备份之后删除部分归档文件腾出空间。一旦释放空间数据库通常会自动恢复日志切换不一定要重启实例。第三步如果归档目录空间充足但归档进程异常考虑手动重启归档进程SQL alter system archive log stop; SQL alter system archive log start;这一步会强制重新初始化归档进程。执行完后再手动切换一次日志SQL alter system switch logfile;确认归档日志能正常生成数据库的hang住状态即可解除。这里我还要额外提醒一句如果在RAC环境下操作归档参数和目录必须在所有节点上保持一致包括创建的目录和权限配置。我曾经见过一个双节点RAC只在一个节点上建了归档目录另一个节点日志切换时找不到路径结果整个集群写事务全部被拖垮。RAC环境的操作一定要养成所有节点同步执行的习惯。7. 我个人的生产环境实操建议最后把我这些年在生产环境里总结的一些操作习惯分享出来。比如在变更脚本里我习惯先把整个操作过程写入一个文本文件每执行一步记录一步尤其对生产库做模式切换这种变更留一份可追溯的操作痕迹会方便很多。团队协作时把归档模式的检查项纳入日常巡检脚本里每天自动跑一遍能尽早发现隐患。开启归档时还有一个细节值得注意如果库是要长期接受归档日志、配合容灾或数据分析系统使用建议在切换归档模式的同时顺带和网络、存储团队确认一下归档目录所在磁盘的I/O能力。日志写入是顺序写为主的负载机械磁盘通常也能应付但如果业务并发很高、日志量很大归档盘I/O会成为新的瓶颈必要时得考虑SSD或独立存储。另外在完成归档模式开启后我哪天都不会急着把旧的全备文件删掉。正常情况下开归档不影响已有数据文件但为了应对万一出现开启操作后存在不可预期的问题需要恢复到开启前状态的极端情况保留一份开启前的全备或至少保留开启前的那几个联机日志能让自己始终有退路。从实际运维角度来看归档模式本身只是一个开关真正的功夫在开关之后的设计与维护。日志空间规划、清理策略、恢复链路验证、日常监控告警这些环节环环相扣。数据库出问题不可怕可怕的是出问题时发现自己没有退路。把归档模式开好、管好就是给自己和团队留一条最可靠的退路。