Oracle数据库上线运行之后，真正决定长期稳定性的往往不是初始参数和建表语句，而是有没有一套固定频率的维护动作。统计信息过期会让优化器选错索引，备份文件不验证可能在恢复时才发现损坏，表空间满会导致业务直接中断。下面这份清单从统计信息、备份恢复、空间治理和日志巡检四个方向展开，每项任务都尽量给出可以直接在数据库里运行的SQL或命令。
一、统计信息收集与执行计划稳定
Oracle优化器依赖数据字典里的统计信息来判断走全表扫描还是索引扫描。如果一张表从几万行增长到几百万行，统计信息还停留在建表初期，优化器很可能继续选择全表扫描，导致SQL执行时间成倍增加。定期收集统计信息的核心不是简单执行一次DBMS_STATS，而是要根据表的变更频率设置不同策略。比如核心交易表每天凌晨低峰期收集，历史归档表可以每周收集一次，极少变化的配置表则可以锁定统计信息，避免重新收集后执行计划发生意外变化。
适合大多数系统的做法是使用自动统计信息收集任务，默认工作日的夜间窗口已经能够覆盖多数场景。但自动任务在分区表和超大表上有时不够及时，建议额外对关键业务Schema创建定时收集脚本。下面这段PL/SQL可以按Schema收集统计信息，并且并行度设置为4，适合低峰期执行：
BEGIN
DBMS_STATS.GATHER_SCHEMA_STATS(
ownname => 'SCOTT',
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
method_opt => 'FOR ALL COLUMNS SIZE AUTO',
cascade => TRUE,
degree => 4
);
END;
/
收集完成后，需要检查统计信息是否有异常。可以查询DBA_TAB_STATISTICS和DBA_INDEX_STATISTICS确认LAST_ANALYZED时间，重点留意超过7天未更新的核心表。对于某些SQL执行计划非常稳定的场景，可以导出当前统计信息作为基线，例如用DBMS_STATS.CREATE_STAT_TABLE保存一份历史版本，在优化器行为异常时快速恢复。统计信息维护不是越频繁越好，过于频繁的收集会增加字典表的DML压力，关键是覆盖数据变更比例较大的对象。
二、备份有效性验证与恢复演练
只配置RMAN备份任务并不等于数据安全。备份脚本可能因为归档日志断档、磁盘权限变化或通道配置错误而静默失败，即使备份成功，也不代表备份集一定可以用于恢复。定期任务清单里必须包含三类动作：备份状态检查、备份集完整性验证和恢复路径预演。
备份状态检查可以查询V$BACKUP_SET、V$BACKUP_PIECE和V$BACKUP_ARCHIVELOG_DETAILS，确认最近一次全量备份和归档备份的完成时间。更可靠的做法是使用RMAN的VALIDATE命令，它会实际读取备份片并检查物理损坏：
rman target / RMAN> VALIDATE DATABASE; RMAN> VALIDATE ARCHIVELOG ALL;
验证通过后，还要定期执行RESTORE DATABASE PREVIEW来确认RMAN能找到恢复需要的所有备份片和归档日志。很多运维人员等到故障发生才第一次执行恢复预览，结果发现某个归档日志已经被定时任务删除，这是典型的维护盲区。
rman target / RMAN> RESTORE DATABASE PREVIEW;
条件允许的情况下，建议每季度在测试环境做一次完整恢复演练。演练不是简单打开备份文件，而是模拟控制文件丢失、数据文件损坏等场景，按真实步骤执行RESTORE DATABASE和RECOVER DATABASE。恢复演练能暴露备份策略中的时间窗口问题，例如归档日志只保留三天，但全量备份是每周一次，一旦周三发生故障，恢复到周二状态可能缺少足够的归档日志。
三、表空间、归档日志与对象空间治理
表空间使用率是Oracle日常巡检中最直接的指标。临时表空间或系统表空间满会直接导致事务无法继续，UNDO表空间满会触发ORA-01555相关错误。维护清单不应只在收到告警后才去看空间，而应每月分析一次增长趋势，提前扩容或启动回收。可以通过DBA_DATA_FILES和DBA_FREE_SPACE计算表空间使用率，重点监控使用率超过80%的对象。
归档日志的管理同样重要。开启归档模式后，如果log_archive_dest指向的目录没有及时清理，数据库会停止归档并挂起所有写操作。建议设置归档删除策略，例如要求备份完成后才可以删除归档，并在RMAN脚本中加入删除过期归档的逻辑：
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK; DELETE NOPROMPT OBSOLETE;
表和索引的空间回收也不能忽略。频繁删除数据的表可能占用大量高水位线以下的空间，导致全表扫描变慢。可以用ALTER TABLE ... SHRINK SPACE或在允许锁表时使用MOVE操作回收空间，但要注意操作后索引会失效，需要重建。索引是否需要重建不能只看BLEVEL和LEAF_BLOCKS，对于顺序插入的主键索引，即使树叶块较多，结构也未必松散；而对于频繁更新和删除的索引，才更需要关注碎片程度。
四、AWR、ASH与告警日志巡检
即便没有用户投诉，定期查看AWR报告也能提前发现性能隐患。AWR报告里最值得关注的不是单一SQL的耗时，而是等待事件分布、负载曲线和Top SQL的变化趋势。例如数据库平时以db file sequential read为主，某周突然出现大量log file sync，通常说明提交过于频繁或日志磁盘出现延迟。每周固定生成一次AWR快照对比，能够为性能问题留下判断基线。
告警日志alert.log是所有运维人员最容易忽略却最危险的信息源。ORA-00600、ORA-07445等内部错误可能只出现一次，但往往预示着底层存储、内存或Bug问题。建议把告警日志接入日志采集平台，并针对ORA-00060、ORA-01555、ORA-01653、ORA-01654等常见错误设置即时告警。同时检查监听日志是否出现异常断连，尤其是与连接池配合的应用，监听日志能反映应用侧是否存在频繁重连。
对于已经发生过的性能问题，可以使用ASH报告定位具体时刻的会话活动。ASH按照秒级采样，比AWR更细粒度，适合复盘瞬时卡顿。维护任务里可以加入一条：每月从V$ACTIVE_SESSION_HISTORY中筛选等待时间排名前20的SQL，结合执行计划判断是否需要调整索引或统计信息。
把这些动作拆成每日、每周、每月三张清单后，Oracle数据库的维护就不再依赖个人经验。每日检查归档和表空间使用率，每周检查统计信息与告警日志，每月执行备份验证和空间趋势分析，每季度做一次恢复演练。清单本身可以随着系统规模不断调整，但核心逻辑不变：让风险在监控和验证阶段暴露，而不是等到业务中断后再处理。
