目录一、为什么需要管理控制文件1.1.管理的核心原因1.2.不管理的后果真实事故场景后果1数据库无法启动后果2RAC节点被强制驱逐1.3.管理最佳实践1.3.1.多路复用至少2份推荐3份1.3.2.定期备份控制文件自动或手动1.3.3.使用RMAN快照控制文件RAC中需放在共享存储二、为什么需要管理日志文件组Redo Log2.1.管理的核心原因2.2.不管理的后果真实事故场景后果1性能雪崩后果2数据丢失最严重后果3恢复失败2.3.如何管理日志组文件2.3.1.查查看日志组与成员2.3.2.增添加日志组或成员2.3.3.改修改日志大小2.3.4.删删除日志组或成员2.4.管理最佳实践2.4.1.多成员复用每个日志组至少2个成员放在不同磁盘2.4.2.合理规划日志组数量和大小OLTP系统建议每组500M-2G3-5组2.4.3. 监控日志切换频率每小时不超过4次为佳2.4.4.在RAC中为每个实例独立分配日志线程2.4.5.手动强制切换日志组三、RAC环境下的特殊管理考量四、总结Oracle对控制文件和日志文件组进行管理不是为了“让数据库跑起来”而是为了“让数据库在出事后能活下来并且数据分毫不差”。在Oracle RAC集群环境中这两类文件的管理直接决定了数据库的高可用性和数据零丢失。下面我会从为什么需要管理、不管理的后果以及最佳实践三个层面来详细说明。一、为什么需要管理控制文件首先需对控制文件有一个基本的认识在Oracle的世界中控制文件是其“大脑中枢”记录了数据库的物理结构所有数据文件、日志文件的位置、当前的SCN系统变更号-System Change Number、检查点信息等元数据。如果控制文件损坏或丢失数据库将无法启动所以控制文件需要进行多副本备份。1.1.管理的核心原因管理目的具体说明防止单点故障控制文件一旦损坏数据库立即crash崩溃且无法MOUNT必须使用备份恢复或重建恢复时间极长RTO极高业务中断时间。防止脑裂Split-Brain在RAC中所有节点共享的控制文件记录了集群的“共识状态”。如果控制文件不一致可能导致集群分裂成两个独立运行的子集群造成数据损坏。支持数据库重命名/迁移当需要修改数据库名称、移动数据文件路径时必须重建或修改控制文件通过CFREATE CONTROLFILE或RMAN。记录备份与恢复元数据RMAN的备份信息会记录在控制文件中。如果控制文件丢失RMAN将无法识别有哪些备份可用恢复操作会变得极其复杂。1.2.不管理的后果真实事故场景后果1数据库无法启动SQL STARTUPORA-00205: error in identifying control file, check alert log for more info此时如果没有控制文件的多路复用Multiplexing只能从冷备或RMAN备份中恢复可能需要数小时甚至数天。后果2RAC节点被强制驱逐如果某个节点的控制文件I/O超时或损坏CSSCluster Synchronization Services会认为该节点“失联”将其从集群中踢出节点驱逐影响业务连续性。1.3.管理最佳实践1.3.1.多路复用至少2份推荐3份SHOW PARAMETER control_files;-- 结果应为DATA/control01.ctl, FRA/control02.ctl下图为测试环境示例1.3.2.定期备份控制文件自动或手动ALTER DATABASE BACKUP CONTROLFILE TO /backup/control.bak;-- 或通过RMAN自动备份RMAN CONFIGURE CONTROLFILE AUTOBACKUP ON;1.3.3.使用RMAN快照控制文件RAC中需放在共享存储CONFIGURE SNAPSHOT CONTROLFILE NAME TO DATA/SNAPSHOT/snapcf_orcl.f;二、为什么需要管理日志文件组Redo Log日志文件组记录了数据库的所有变更操作Redo Records是实例恢复Instance Recovery和介质恢复Media Recovery的数据来源。它的核心目标是保证不丢数据零数据丢失。Oracle 日志组Redo Log Group的增删改查核心操作都围绕 ALTER DATABASE 和 ALTER SYSTEM 命令展开。2.1.管理的核心原因管理目的具体说明保证实例恢复能力当实例崩溃如节点宕机下次启动时Oracle会应用Redo日志中的所有已提交事务并将未提交事务回滚确保数据库一致性。没有Redo就无法恢复。防止日志写入瓶颈如果日志组数量不足或日志文件太小会导致频繁的日志切换Log Switch引发“日志缓冲区等待”如log file switch completion严重降低数据库性能。确保归档连续性如果数据库处于ARCHIVELOG模式日志切换后会触发归档。如果日志组被写满且归档未完成数据库会挂起等待导致业务中断。防止“日志组丢失”如果一个日志组的所有成员都损坏磁盘损坏且该日志组尚未归档则已提交的事务永久丢失数据库可能需要进行不完全恢复Point-in-Time Recovery。2.2.不管理的后果真实事故场景后果1性能雪崩-- 等待事件出现大量log file switch completionSELECT event, total_waits FROM v$system_event WHERE event LIKE log file%;原因日志组数量太少或日志文件太小导致DBWR进程来不及写入LGWR频繁切换。上图状态显然没有这种情况后果2数据丢失最严重如果某个日志组的所有成员都在同一块损坏的磁盘上且该日志组尚未归档那么该日志组中的已提交事务将永久丢失只能恢复到这个时间点之前。后果3恢复失败如果控制文件中记录的日志文件路径与实际不符如ASM磁盘组被删除数据库在恢复时会报错ORA-00312: online log 1 thread 1: DATA/redo01.logORA-27037: unable to obtain file status2.3.如何管理日志组文件首先我们需要了解日志组的日常管理无非就是增删改查四个大方面的内容2.3.1.查查看日志组与成员日常巡检或排查日志切换卡住时先看这两个视图-- 查看日志组状态GROUP#、成员数、大小、状态 SELECT group#, thread#, sequence#, members, bytes/1024/1024 AS size_mb, status, archived FROM v$log; -- 查看日志组成员的物理路径 set lines 400; col member format a50; SELECT group#, member, status FROM v$logfile ORDER BY group#, member;V$LOG.STATUS的常见值CURRENT当前正在写、ACTIVE活动但非当前可能还在归档、INACTIVE可被覆盖、UNUSED;2.3.2.增添加日志组或成员添加一个新的日志组建议同时指定大小RAC 环境需在各实例分别执行或加 SID*ALTER DATABASE ADD LOGFILE GROUP 5 (/u01/app/oracle/oradata/ORCL/redo05a.log, /u02/app/oracle/oradata/ORCL/redo05b.log) SIZE 200M;为已有组添加成员多路复用提升安全性ALTER DATABASE ADD LOGFILE MEMBER /u03/app/oracle/oradata/ORCL/redo01c.log TO GROUP 1;2.3.3.改修改日志大小Oracle没有 直接ALTER LOGFILE .... RESIZE 的官方命令。要调整日志大小标准做法是“新增替换、删除旧组”1.添加一个或多个新大小的日志组如上面“增”的示例。2.强制日志切换让新组投入使用ALTER SYSTEM SWITCH LOGFILE;3.确认旧组状态变为INACTIVE且已归档如果开了归档再删除旧组。2.3.4.删删除日志组或成员删除整个日志组ALTER DATABASE DROP LOGFILE GROUP 5;删除某个日志成员ALTER DATABASE DROP LOGFILE MEMBER /u03/app/oracle/oradata/ORCL/redo01c.log;2.4.管理最佳实践2.4.1.多成员复用每个日志组至少2个成员放在不同磁盘ALTER DATABASE ADD LOGFILE MEMBER FRA/redo01b.log TO GROUP 1;如下示例每个日志组Group都包含了2个成员Members也就是做了镜像分布在不同的磁盘或故障组上。符合高可用架构的要求防止单点故障导致日志丢失。set linesize 400;col file_path format a50;SELECTa.group#,a.member AS file_path,a.status AS file_status,b.status AS group_status,b.bytes/1024/1024 AS size_mbFROMv$logfile a,v$log bWHEREa.group# b.group#ORDER BYa.group#, a.member;2.4.2.合理规划日志组数量和大小OLTP系统建议每组500M-2G3-5组SELECT group#, bytes/1024/1024 MB, members, status FROM v$log;2.4.3. 监控日志切换频率每小时不超过4次为佳SELECT TO_CHAR(first_time, YYYY-MM-DD HH24) hour, COUNT(*) switches FROM v$log_history GROUP BY TO_CHAR(first_time, YYYY-MM-DD HH24) ORDER BY 1 DESC;下图示例是比较正常的状态2.4.4.在RAC中为每个实例独立分配日志线程ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 10 SIZE 1G;ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 11 SIZE 1G;2.4.5.手动强制切换日志组一般如果数据库正常的话日志写满之后自动切换到其它日志组成员Oracle 内部机制一般出现一下两种情况会出现切换写满触发当当前正在使用的日志组状态为 CURRENT被写满时Oracle 会自动切换到下一个状态为 INACTIVE 或 UNUSED 的日志组。归档卡住如果数据库开启了归档模式但归档进程ARCn因为空间满或其他原因无法将旧日志归档当所有日志组都写满时数据库会挂起Hang直到归档成功腾出可用日志组。但是日常维护或测试中比如手动切换DGFSFO或者备份前的准备常常需要手动切换日志。SQL 命令ALTER SYSTEM SWITCH LOGFILE;效果数据库立即停止写入当前日志组强制切换到下一个可用日志组并触发归档。这个命令在单机或 RAC 环境下都适用。三、RAC环境下的特殊管理考量对比项单实例RAC集群控制文件存放在本地磁盘或共享存储必须放在共享存储ASM所有节点共享同一套控制文件日志文件组所有日志组属于同一线程每个实例有自己独立的日志线程ThreadThread 1 属于节点1Thread 2 属于节点2故障切换无节点故障时该节点的日志线程由存活节点接管需配置DB——RECOVERY_FILE_DEST恢复复杂度相对简单需要恢复特定线程的日志并使用RMAN的RESTORE DATABASE ... THREAD语法四、总结管理控制文件和日志文件组本质上是在管理数据库的“生命线”控制文件管的是“数据库能不能启动”日志文件组管的是“数据库能不能恢复”。文件类型出问题后果管理目标控制文件数据库无法MOUNT/OPEN无法识别数据文件多路复用 定期备份 放在共享存储日志文件组数据丢失 性能瓶颈 恢复失败多成员复用 合理组数/大小 归档路径冗余