企业官网建设流程全解析

简介：一份关于Oracle数据库运维实战的案例课件，面向需要掌握RAC集群故障诊断与排除的数据库管理员和运维工程师。课件以一次真实的生产环境故障为背景，围绕错误日志中的IPC Send timeout现象展开，详细解读了LMS与LMD锁管理进程的通信机制，以及Oracle RAC在检测到不一致实例成员资格后触发脑裂判定、驱逐异常节点并抛出ORA-29740错误的完整过程。同时，借助netstat采集到的网络包重组失败数据，分析了丢包与网络拥塞对实例间消息传递的影响，并结合CPU、内存、I/O资源占用情况给出了系统性的排查思路。内容覆盖日志分析、网络连通性检查、资源监控、版本补丁核查与故障排除法等多个环节，能够帮助读者建立从现象到根因的闭环分析能力。资源包共包含1个pptx演示文稿，整个压缩包仅1.83MB，体量紧凑但要点全面，已有133人学习下载，适合在遇到类似RAC节点驱逐问题时快速查阅参考。

1. Oracle 数据库运维：一份案例集是如何把经验变成解决方案的

夜班被告警震醒、登录数据库发现归档日志目录 100% 占满、业务全部挂起，这种事在 Oracle 运维的日常里排得上前三名。真正让人头疼的不是问题本身，而是第一次遇到时没有参照——查半天文档、试了多个命令，最后才发现一个ALTER DATABASE就能解决。这份《Oracle数据库运维案例介绍.pptx》就是干这个用的：它不是讲理论和架构的教材，而是把生产环境里高频出现的故障、误操作、性能瓶颈整理成一份份「事发现场 + 解决方案」的案例集，覆盖归档日志满、表空间爆、RMAN 备份失败、监听器连接异常、AWR 性能分析等典型场景。适合刚接手 Oracle 运维、正在搭建巡检 SOP 的工程师，也适合被救火救烦了、想把手里的排查经验沉淀成标准化流程的团队。

读这份 PPT 的正确方式不是从头翻到尾，而是把它当一本「故障字典」：先定位自己当前最痛的问题，找到对应案例，照着解决，再反向补充自己环境里的边界参数。接下来我就按「这份资源里到底有什么 → 怎么把案例转成自己的 SOP → 性能类案例怎么深挖 → 最容易踩的坑在哪 → 怎么把案例变成自动化脚本」这条线拆开讲。

2. 案例结构拆解：这份 PPT 到底收录了什么

2.1 案例分类与内容框架：从故障现场到解决方案的编排逻辑

打开这份 PPT，第一眼看到的是案例清单。常规的 Oracle 运维培训资料是按知识点组织的——先讲体系结构，再讲备份恢复，最后讲调优；但运维案例类资源不同，它按「故障场景」组织，每个案例都是一条完整的链路：现象描述 → 初步诊断 → 根因分析 → 解决方案 → 预防措施。

以我经手过的运维团队常用的归类方式，这类案例集通常会覆盖下面几个大类：

这张表的价值在于：团队新人拿到后能快速判断「我遇到的事属于哪一类」，然后直接跳到对应章节，不用从头把 PPT 看一遍。我一般会建议团队成员把这份 PPT 的目录做成一张速查卡贴在自己的运维笔记里，遇到问题时先归类，再查案例。

2.2 从案例到 SOP：为什么说案例只是「药材」，解决方案才是「药方」

看这份 PPT 时最容易犯的一个错误是「只抄命令，不抄思路」。比如归档日志满的案例，PPT 里给出了一条清理命令，但如果直接照抄，很可能踩进「删了还在使用的归档、导致 RMAN 恢复失败」的坑里——这件事我在第 5 章会专门展开。

正确的读法是：把每个案例拆成「诊断步骤」和「解决步骤」两层。诊断步骤解决的是「怎么判断是这个原因」，解决步骤解决的是「怎么处理」。举例来说，归档日志满这个案例，PPT 里如果只是给出了rm删除命令，那这个案例的参考价值就只值 20%；如果它讲了如何通过v$archived_log和v$recovery_area_usage判断归档日志的状态、如何区分「可安全删除」和「仍被 Data Guard 或备份流程引用」的归档，那这个案例就值 80%。

实操中我会把这份 PPT 的每个案例转成一张标准作业卡，格式固定：

1. 触发条件：什么告警、什么现象出现时才用这个方案。
2. 诊断命令：按顺序执行的查询语句，每条的预期输出是什么。
3. 解决命令：执行的操作，标注哪些是危险的、哪些可逆。
4. 验证方法：做完后怎么确认问题真的解决了。
5. 预防项：往后怎么避免同样的事再发生。

这套转法有个额外好处：它可以直接作为后续自动化巡检脚本的设计蓝本，也就是第 6 章要讲的方向。团队里就算有人没看过 PPT、没经历过现场，照这张卡走一遍也能把故障处理掉，虽然不一定处理得最漂亮，但至少不会犯方向性错误。

3. 把高频运维案例转成可复制的操作 SOP

3.1 归档日志满导致数据库挂起：定位、清理与预防

归档日志满是最常见的 Oracle 运维故障之一，现象非常典型：应用报 ORA-00257，数据库看起来还活着，但任何写入操作都不响应，因为 LGWR 无法切换日志。如果是单机环境还好，如果是 Data Guard 环境，归档满了还可能连带主库和备库同时出问题。

先看空间使用情况：

-- 查看快速恢复区的使用率 SELECT name, space_limit/1024/1024/1024 AS limit_gb, space_used/1024/1024/1024 AS used_gb, space_used/space_limit*100 AS used_pct FROM v$recovery_area_usage; -- 查看归档日志的序列号和是否已被备份 SELECT sequence#, name, deleted, status FROM v$archived_log ORDER BY sequence# DESC FETCH FIRST 10 ROWS ONLY;

第一条命令用来判断快速恢复区（Fast Recovery Area）是否真的满了，第二条用来确认哪些归档日志已经被备份过、可以安全删除。判断依据是deleted字段和status字段：deleted='YES'表示已标记删除，status='A'表示可用。执行第二条命令前要注意，如果数据库开了 Data Guard，不能只看本地备份状态，还要确认备库已经应用了这些归档，否则删了会导致备库断档。

确认哪些归档可以删之后，用 RMAN 清理而不是直接rm：

rman target / RMAN> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7';

这条命令删除 7 天前且已经被备份过的归档日志，COMPLETED BEFORE的含义是归档日志的完成时间在指定时间点之前。它比DELETE ARCHIVELOG ALL更安全，因为带了时间边界，误删范围可控。如果连备份都没有、纯手工环境，那就别用这条，直接按v$archived_log里的序列号范围精准删：

DELETE ARCHIVELOG FROM SEQUENCE 100 UNTIL SEQUENCE 200;

把序列号换成自己查到的区间，这条命令的好处是精确可控，但前提是你已经确认这些日志对 DG 和备份流程都不再需要。

预防措施是给归档设置有效期，让数据库自动清理：

-- 开启归档自动删除策略，保留 3 天 CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK;

这条策略的意思是「至少被备份一次的归档才能被删除」，比纯按时间删除多一层保护。执行后可以通过SHOW ARCHIVELOG DELETION POLICY验证。我一般还会顺手加上文件系统层的告警——用df -h监控归档目录，到 80% 就告警，而不是等满了数据库自己挂起。

3.2 表空间爆满：从告警到扩展再到自动管理

表空间不足的告警几乎每个 Oracle 运维都收过。先看使用率，定位是哪个表空间、哪些数据文件快满了：

SELECT a.tablespace_name, ROUND((b.bytes_used)/1024/1024/1024, 2) AS used_gb, ROUND((b.bytes_total)/1024/1024/1024, 2) AS total_gb, ROUND((b.bytes_total - b.bytes_used)/1024/1024/1024, 2) AS free_gb, ROUND((b.bytes_used / b.bytes_total) * 100, 2) AS used_pct FROM dba_tablespaces a, (SELECT tablespace_name, SUM(bytes) bytes_used, SUM(max_bytes) bytes_total FROM dba_data_files GROUP BY tablespace_name) b WHERE a.tablespace_name = b.tablespace_name AND b.bytes_used / b.bytes_total > 0.85 ORDER BY used_pct DESC;

这个查询把使用率超过 85% 的表空间列出来，SUM(max_bytes)取的是每个数据文件的MAXSIZE，如果没设置自动扩展上限，这个值可能不准。判断思路：先用这张表定位目标表空间，再用下一步精确看单个数据文件的增长情况。

确认数据文件后，扩展有两种做法：手动扩容和开启自动扩展。

-- 手动扩展数据文件，增加 10G ALTER DATABASE DATAFILE '/u01/app/oracle/oradata/ORCL/users01.dbf' RESIZE 32G; -- 开启自动扩展并设置上限为 64G ALTER DATABASE DATAFILE '/u01/app/oracle/oradata/ORCL/users01.dbf' AUTOEXTEND ON NEXT 512M MAXSIZE 64G;

RESIZE是直接把文件扩大，适合文件系统空间足够的情况；AUTOEXTEND ON是让 Oracle 在空间不够时自动按NEXT指定的增量扩展，直到MAXSIZE上限。注意NEXT 512M这个参数，增量太小会导致频繁扩展、产生不必要的 I/O 和空间分配开销；增量太大又可能一次性占满文件系统，我一般是在 512M 到 1G 之间选。MAXSIZE一定要设，否则小文件表空间（SMALLFILE TABLESPACE）的单数据文件最大只能到 32G（取决于db_block_size），到了上限还是会爆，而且爆的时候你连扩展的余地都没有——这是我在第 5 章会再提的一个坑。

如果空间需求是长期的，更好的做法是加数据文件而不是无限扩大单个文件：

ALTER TABLESPACE users ADD DATAFILE '/u01/app/oracle/oradata/ORCL/users02.dbf' SIZE 16G AUTOEXTEND ON NEXT 512M MAXSIZE 32G;

加数据文件的好处是让 I/O 分布到多个文件上，减少单文件的争用。做完任何一步，都回查一次 3.2 的第一条 SQL，确认使用率已经降下来。如果降不下来，说明是数据真的在快速增长，不是空间碎片问题，这时候要去看是不是有异常的 SQL 在批量写入或者有表设计缺陷导致的行迁移。

3.3 用户密码过期与账号锁定：Profile 的口令管理陷阱

用户密码过期是个看起来小、杀伤力却很大的问题。现象是应用突然连不上数据库，报 ORA-28001 the password has expired。很多运维第一反应是「重置密码就行了」，但这只是治标——如果应用连接串里密码没同步改，改完密码依然连不上；如果没找到根因，过一段时间又会过期。

先查到底是谁的 Profile 把密码有效期设成了限制：

-- 查看所有用户的 profile 和密码过期时间 SELECT username, profile, expiry_date FROM dba_users WHERE account_status NOT IN ('OPEN', 'LOCKED') OR expiry_date < SYSDATE + 30; -- 查看 profile 的密码有效期设置 SELECT profile, resource_name, limit FROM dba_profiles WHERE resource_name IN ('PASSWORD_LIFE_TIME', 'PASSWORD_GRACE_TIME') ORDER BY profile;

第一条查出所有「状态不是正常打开」的用户，第二条查 Profile 里和密码有效期相关的两个参数。PASSWORD_LIFE_TIME是密码最大使用天数，PASSWORD_GRACE_TIME是到期后的宽限期天数。默认的DEFAULTProfile 在许多版本里是PASSWORD_LIFE_TIME=180，意味着每半年密码过期一次。

解决方案分两层。如果是应用账号，最务实的做法是取消有效期限制：

ALTER PROFILE app_profile LIMIT PASSWORD_LIFE_TIME UNLIMITED; ALTER USER app_user PROFILE app_profile; ALTER USER app_user IDENTIFIED BY new_password;

UNLIMITED表示永久有效，ALTER USER ... IDENTIFIED BY重置密码并解除过期状态。注意改完密码后，应用连接串里也要同步更新，否则会出现「数据库端密码改了、应用端还是旧密码」的二次故障。

如果是人力运维的账号，不建议取消限制，而是设置一个合理的周期并配合密码管理工具自动轮换。还要加一条：如果系统要求所有用户密码每 90 天改一次，那PASSWORD_GRACE_TIME别设成默认的 7 天，改成 0，让密码一过期立刻锁定，而不是给 7 天缓冲——缓冲期里用户还能登录，但每登录一次就弹一条警告，很多人根本不看，直到最后一天才炸。

账户被锁定的情况也常遇到：

-- 查看账户锁定状态和锁定时间 SELECT username, lock_date, account_status FROM dba_users WHERE lock_date IS NOT NULL; -- 解锁并重置密码 ALTER USER app_user ACCOUNT UNLOCK; ALTER USER app_user IDENTIFIED BY temp_password;

注意解锁前先确认是不是被暴力猜测密码导致锁定的，如果是，大概率是连接串信息泄露或有人恶意尝试，这时候光解锁没用，要配合监听器日志看来源 IP，该封的封。

4. 性能类案例：从 AWR 报告到参数调整

4.1 AWR 报告批量生成：把性能分析从「凭感觉」变成「看数据」

PPT 里性能类案例的价值在于：它往往给出了一条完整的分析路径——先拍快照，再生成 AWR 报告，然后按等待事件和 Top SQL 定位问题。这套流程在真正的生产环境里最大的痛点是「报告生成太慢、太麻烦」，尤其是多个实例要一起分析时，手工一个个跑 SQL 能折腾一上午。

批量生成 AWR 报告可以写成一段 SQL 脚本，配合 Shell 循环：

#!/bin/bash # 生成指定时间窗口的 AWR 报告 # 参数：实例名、开始快照 ID、结束快照 ID ORACLE_SID=$1 START_SNAP=$2 END_SNAP=$3 OUTPUT_DIR=/tmp/awr_reports mkdir -p ${OUTPUT_DIR} for inst_id in 1 2; do sqlplus -s / as sysdba <<EOF SET PAGESIZE 0 SET LINESIZE 300 SET FEEDBACK OFF SET TRIMSPOOL ON SPOOL ${OUTPUT_DIR}/awr_${ORACLE_SID}_inst${inst_id}_${START_SNAP}_${END_SNAP}.html SELECT output FROM TABLE(dbms_workload_repository.awr_report_html( ${inst_id}, ${START_SNAP}, ${END_SNAP} )); SPOOL OFF EOF done

这个脚本的思路是调用dbms_workload_repository.awr_report_html函数生成 HTML 格式的 AWR 报告，按实例 ID 循环输出到文件。三个参数的含义：inst_id是 RAC 环境下的实例编号，单机环境写 1 就行；START_SNAP和END_SNAP是快照 ID，可以从dba_hist_snapshot查。脚本跑完后，/tmp/awr_reports目录下会有按实例和时间段命名的 HTML 文件，浏览器打开就是完整的 AWR 报告。

拿到报告先看三段：Top 10 Foreground Wait Events看等待事件分布，SQL ordered by Elapsed Time看最耗时的 SQL，Instance Activity看关键指标。等待事件里如果db file sequential read占比很高，大概率是索引有问题或 SQL 做了大量单块读；如果是log file sync很高，问题出在提交频率或 redo 日志写入性能上。

4.2 内存与连接参数调整：sga_target、pga_aggregate_target 与 processes

PPT 里的性能案例如果涉及参数调整，通常绕不开三个参数：sga_target、pga_aggregate_target和processes。这三个参数分别控制共享内存、排序/哈希内存和最大连接进程数，是 Oracle 性能调整里最常被动的三个旋钮。

-- 查看当前值和修改记录 SELECT name, value, isdefault, issys_modifiable FROM v$parameter WHERE name IN ('sga_target', 'pga_aggregate_target', 'processes', 'sessions'); -- 修改参数（动态生效） ALTER SYSTEM SET sga_target=8G SCOPE=BOTH; ALTER SYSTEM SET pga_aggregate_target=2G SCOPE=BOTH; ALTER SYSTEM SET processes=1500 SCOPE=SPFILE; ``` `SCOPE` 参数有三个可选值，这里特意用了不同的写法来展示它们的差别：`SCOPE=BOTH` 表示立即生效并写入 spfile，适合可以动态调整的参数，比如 `pga_aggregate_target`；`SCOPE=SPFILE` 表示只写入 spfile、下次重启生效，适合 `processes` 这类无法动态调整的参数。如果用了 `SCOPE=BOTH` 修改 `processes`，会报 ORA-02096，这就是参数类型的边界。 `processes=1500` 意味着最多允许 1500 个并发进程，注意 Oracle 默认还会按 `processes` 计算 `sessions`，两者不是独立关系。改 `processes` 时如果同时有大量连接池在跑，建议 `sessions` 也相应调大，否则连接数到了上限还是会报 ORA-00020。判断连接数是否到底的方式： ```sql SELECT COUNT(*) FROM v$session; SELECT value FROM v$parameter WHERE name = 'processes'; ``` 如果 `v$session` 里的总数接近 `processes` 值，说明连接池已经顶到天花板了，这时候加参数只是治标——真正该做的是排查是否有连接泄漏，即应用里拿了连接不释放。 ### 4.3 监听器与连接排查：从 lsnrctl 到 tnsnames 再到客户端工具 连接类故障在日常工单里的占比非常高，尤其是「应用突然连不上」「新装的客户端连不上」「开发说数据库挂了但 DBA 一看数据库活得好好的」。这类问题排查有一套固定顺序：先确认数据库活着，再看监听器状态，再看网络层和客户端配置。 ````bash # 确认数据库进程和监听器状态 ps -ef | grep pmon | grep -v grep lsnrctl status ``` `lsnrctl status` 的输出重点看三块：监听器是否 `READY`，注册的服务里有没有目标实例名，`Services Summary` 里列出的实例和状态。如果数据库活着但监听器列表里没有实例，说明动态注册失败了，常见原因是 `local_listener` 参数没配对。 排查客户端连接问题时，先分清是「连不上」还是「连上但认证失败」——两者报错完全不同。连不上的报错通常是 ORA-12514（监听器当前无法识别连接描述符中请求的服务）或 ORA-12541（无监听程序），认证失败则是 ORA-01017 或 ORA-28001。 用最朴素的 `tnsping` 测试网络层和解析层： ```bash tnsping orcl ``` 如果 `tnsping` 通了说明网络和 tnsnames 解析没问题，问题在监听器服务注册或数据库端；如果 `tnsping` 都不通，优先检查 tnsnames.ora 里的 host/port/service_name 是否写对。 日常管理里，团队常用的客户端工具是 dbeaver 和 navicat。用 dbeaver 连接 Oracle 时最容易踩的坑是缺少驱动——Oracle 的 JDBC 驱动要手动下载 ojdbc8 或 ojdbc11 放进 DBeaver 的驱动管理器里，不是装完 DBeaver 就能直接连 Oracle。配置时数据库地址、端口、服务名三项必须和 `tnsnames.ora` 里完全一致，别把 SID 和 SERVICE_NAME 混用。navicat 的 Oracle 连接也类似，但它自带驱动相对完整，更常见的问题是连接时选了错误的连接类型（Basic 和 TNS 两种模式的区别）。 ## 5. Oracle 运维踩坑实录：五个高频翻车点与排查路径 ### 5.1 手工删除归档日志导致 Rman 备份失败 **现象**：归档目录快满，DBA 直接 `rm` 删了一批归档日志文件，当天告警确实消失了，但第二天 RMAN 备份报错，提示找不到归档日志文件，备份直接失败。 **原因**：`rm` 只删了文件系统上的文件，没有同步更新控制文件和恢复目录中的归档记录。RMAN 在备份或者做恢复校验时，会去检查这些「有记录但文件不存在」的归档日志，找不到就报错。更严重的是，如果这些归档是 Data Guard 备库还没有应用的，删除后主备同步直接断档。 **解决**：永远用 RMAN 删除归档日志，不用文件系统层的 `rm`。已经误删的情况下，用下面的方式让 Oracle 重新同步记录： ```sql -- 验证归档日志状态，找出文件缺失的记录 SELECT sequence#, name, status FROM v$archived_log WHERE name IS NOT NULL AND status = 'A'; -- 对缺失文件对应的归档记录做交叉检查 RMAN> CROSSCHECK ARCHIVELOG ALL; RMAN> DELETE EXPIRED ARCHIVELOG ALL; ``` `CROSSCHECK` 的作用是把控制文件里的记录和实际文件系统做比对，标出「记录存在但文件不存在」的归档为 expired；`DELETE EXPIRED` 再把这些失效记录清掉。从那以后，我每次处理归档空间问题都会强制走一遍这个顺序：先 RMAN 检查备份状态，再交叉检查，最后删除。 ### 5.2 表空间数据文件用了 AUTOEXTEND ON 但没设 MAXSIZE **现象**：表空间使用率显示 99%，数据文件明明开了 `AUTOEXTEND ON`，却没有继续增长，应用报 ORA-01653 无法扩展表空间。 **原因**：`AUTOEXTEND ON` 只是允许 Oracle 自动扩展，但每个数据文件有自身的 `MAXSIZE` 约束。小文件表空间（Smallfile Tablespace）下，单数据文件默认块大小 8K 时最大 32G，如果没设 `MAXSIZE`，默认值就是这个上限。到了 32G 后哪怕文件系统还剩一堆空间，Oracle 也不会继续扩。 **解决**：定位具体是哪个文件触顶，然后重新调整 `MAXSIZE` 或者加新文件： ```sql SELECT file_name, bytes/1024/1024/1024 AS current_gb, maxbytes/1024/1024/1024 AS max_gb FROM dba_data_files WHERE tablespace_name = 'USERS'; ALTER DATABASE DATAFILE '/u01/app/oracle/oradata/ORCL/users01.dbf' AUTOEXTEND ON MAXSIZE 64G; ``` 设置 `MAXSIZE` 时要确认文件系统空间是否足够，而且给表空间留出文件系统本身的 buffer，不要把 `MAXSIZE` 顶到和磁盘一样大——数据文件增长是逐步的，但磁盘上还有其他文件也在写。 ### 5.3 修改系统参数后没重启，会话级生效重启后丢失 **现象**：运维人员执行了 `ALTER SYSTEM SET sga_target=8G SCOPE=BOTH`，当前实例运行正常，内存也确实扩了。但下个月实例重启后，`sga_target` 又变回了旧值，调整失效。 **原因**：`SCOPE=BOTH` 对某些参数并不真正生效。Oracle 的参数分为动态参数和静态参数，动态参数里又分「立即生效」和「仅新会话生效」两类。`sga_target` 在某些版本里虽然是动态参数，但如果同时涉及 `sga_max_size` 的约束，重启后 Oracle 会根据 `sga_max_size` 重新计算 `sga_target`，旧值被覆盖。 **解决**：改参数前先查 `v$parameter` 的 `issys_modifiable` 字段，值为 `IMMEDIATE` 的可以用 `BOTH`，值为 `DEFERRED` 的只对新会话生效，值为 `FALSE` 的必须 `SCOPE=SPFILE` 并重启。改完后用 `SHOW PARAMETER` 复核，还要用 `ALTER SYSTEM` 把关联参数一并检查——比如改 `sga_target` 前确认 `sga_max_size` 是否已经给到了足够的上限值。 ### 5.4 用 DROP TABLE 释放空间失败，高水位线问题 **现象**：业务表 200G，开发说「这表不要了」，DBA 执行 `DROP TABLE` 后查表空间使用率，发现空间几乎没降，归档日志倒是爆了一堆。 **原因**：`DROP TABLE` 会释放表占用的空间，但它的空间释放是「逻辑释放」，依赖于段的空间管理方式。如果是 ASSM（自动段空间管理）表空间，`DROP` 后空间会标记为空闲，但高水位线（High Water Mark）以下的空间不会主动收缩回表空间，所以 `dba_segments` 里的空间统计已经变了，但表空间文件本身没缩。更常见的情况是，表其实只是被 `TRUNCATE` 过但段还在，或者 `DROP` 的是分区表的一个分区，段空间没有被完全回收。 **解决**：取决于目标：如果是确认表不再需要，用 `DROP` 后用 `ALTER TABLESPACE ... COALESCE` 或 `ALTER DATABASE DATAFILE ... RESIZE` 收缩文件；如果只是清数据但保留表结构，用 `TRUNCATE` 而不是 `DROP`，`TRUNCATE` 会把高水位线直接降到段起始位置，空间释放更彻底。 ```sql -- 收缩数据文件到合理大小 ALTER DATABASE DATAFILE '/u01/app/oracle/oradata/ORCL/users01.dbf' RESIZE 32G; ``` 注意收缩文件前确认该数据文件内的段已经释放了足够空间，否则会把活跃数据截断，这种操作要在维护窗口做，并且先做一次备份。 ### 5.5 巡检结束当天晚上数据库就宕了，检查项不完整 **现象**：白天刚做完全面巡检，各项指标看起来都正常，结果当天晚上数据库告警宕机，翻巡检报告发现所有指标都是绿色。 **原因**：巡检报告「正常」不代表没有隐患——巡检往往只看了当前值是否在阈值范围内，没看趋势、没看历史同期对比、没做资源预留评估。典型例子：巡检时 CPU 使用率 60%，看着不高，但如果是业务晚高峰前的 60%、而历史上晚高峰会涨到 95%，这就是隐患。另一个例子是归档空间——巡检时可用空间 30%，看着够，但如果归档生成速度是每小时 5G，30% 只够撑 6 小时。 **解决**：巡检要加「趋势项」和「速度项」。归档空间不只查当前剩余，还要查近 24 小时归档生成速率、估算剩余可用时长；CPU 和内存要看过去 7 天同一时段的历史曲线，设置同比告警。做完这些补充，才能说巡检真正覆盖了「未来一两天不会出事」这一层。 ## 6. 把案例集变成自动化巡检脚本：从手工救火到提前预防 前面第 3、4 章里的那些 SQL 和命令，单独用是救火工具，串起来就是一套巡检系统。最实用的演进路径是：先把常见检查项写成 SQL 脚本，再包一层 Python 或 Shell，最后挂到定时任务里。 我常用的是 Python 加 `cx_Oracle`（新版叫 `python-oracledb`），把前面所有手查的 SQL 收集到一个小脚本里，定时跑一次，输出一个纯文本格式的巡检摘要： ```python import oracledb conn = oracledb.connect(user='system', password='***', dsn='host:1521/orcl') checks = [ ("表空间使用率", """ SELECT tablespace_name, ROUND((used_bytes / total_bytes) * 100, 2) AS used_pct FROM (SELECT tablespace_name, SUM(bytes) used_bytes FROM dba_segments GROUP BY tablespace_name) seg, (SELECT tablespace_name, SUM(bytes) total_bytes FROM dba_data_files GROUP BY tablespace_name) df WHERE seg.tablespace_name = df.tablespace_name AND used_bytes / total_bytes > 0.85 """), ("归档日志剩余", """ SELECT name, space_used / space_limit * 100 AS usage_pct FROM v$recovery_area_usage """), ("异常等待事件", """ SELECT event, time_waited FROM v$system_event WHERE event NOT LIKE '%idle%' AND time_waited > 1000000 """), ] for title, sql in checks: cursor = conn.cursor() cursor.execute(sql) rows = cursor.fetchall() if rows: print(f"[{title}] 存在异常项:") for row in rows: print(" ", row) else: print(f"[{title}] 正常") ``` 脚本的核心逻辑是注册一组检查项，每个检查项只查「有问题才返回行」的 SQL，无返回就是正常，有返回就把明细打出来。`time_waited > 1000000` 这个阈值按实际环境调整，单位是厘秒（cs），100 万厘秒约等于 2.8 小时——如果某个等待事件在统计周期内累计等待超过这个值，就该引起注意。再往下走，还可以集成 Ansible，把这套脚本分发到所有 Oracle 服务器上批量执行，输出的结果收回来统一比对，这就是从「单机救火」往「批量运维」跨出的第一步。 回头说这份 PPT 最值得借鉴的地方：它给的从来不是「标准答案」，而是「当时那个现场是怎么处理的」。案例看多了会发现一个规律——生产环境的问题十有八九不是技术深奥，而是边界条件太多。版本不同、参数配置不同、周边架构不同，同一个命令在这里是好药，换个环境就是毒药。从那以后，我每次拿到新的运维案例或者技术资料，都强制走一遍「反推边界」的流程：这个方案在什么条件下成立、在什么条件下会失效、失效时有什么可回退的手段。只有这样，案例里的命令才算是真正变成了自己手里的工具，而不是复制粘贴的一段文字。希望这份 PPT 的案例拆解思路也能帮到你——下次再遇到数据库告警，别急着动手，先把自己正在执行的操作放在「它成立的前提」这个框里想一遍。 <p> <a href="https://download.csdn.net/download/njbaige/32740126" style="color:#ec7500;font-size:14px;"> 本文还有配套的精品资源，点击获取 </a> <img alt="menu-r.4af5f7ec.gif" src="https://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif" style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;"> </p>