9.1 安装配置与日常运维

9.1 安装配置与日常运维

本节摘要：装库是运维的成人礼：容量规划、参数基线、归档与备份的初始配置，装的时候一步到位，能省掉之后几年的还债。本节给一套可复制的安装清单与初始化脚本，再用"日巡检、周保养、月演练"三个节律把日常运维钉成自动化流程。

一、装库这件事为什么值得单写一节

很多人觉得安装是"下一步下一步"的事——图形化向导确实全程可点。但生产安装的难点从来不在把软件装上，而在装对：内存给多少、块大小选什么、归档开不开、备份排不排、审计配不配——向导的默认值是给"能跑"设计的，不是给"能活"设计的。装完再补这些配置的库，和装时就配齐的库，两年后的运维成本差出一个量级。本节的清单按"装前规划、装中决策、装后基线"三段展开，全程假设最常见场景：Linux 上单实例或 RAC、生产规格。

装前规划三件事。 其一，容量与布局：数据磁盘容量按"现有数据量乘 2 起步"预留，重做日志与归档独立磁盘组（2.3 与 6.3 讲过的分居原则），快速恢复区容量按"一次全量备份加七到十四天归档"估。其二，内存预算：按机器物理内存的 60% 到 75% 给 SGA 目标、其余留给 PGA 与系统，别让内核 OOM 杀进程。其三，字符集与块大小：新库统一 AL32UTF8（后续接入别的系统不受字符集拖累）、块大小默认 8K——这两个是"装了基本改不了"的决策，值得多想十分钟。

装中与装后。 向导跑完后，基线配置一步不落：

# 装后基线：SQL*Plus 以 SYSDBA 执行的初始化包
sqlplus / as sysdba <<'EOF'
-- 归档模式：备份体系的前提（新库第一时间开）
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
-- 强制日志记录与密码校验函数
ALTER DATABASE FORCE LOGGING;
@?/rdbms/admin/utlpwmg.sql
-- 参数基线：内存自动管理、会话与进程、审计
ALTER SYSTEM SET memory_max_target = 48G SCOPE = SPFILE;
ALTER SYSTEM SET memory_target = 48G SCOPE = SPFILE;
ALTER SYSTEM SET processes = 1500 SCOPE = SPFILE;
ALTER SYSTEM SET audit_trail = 'DB' SCOPE = SPFILE;
-- 默认口令全部过期锁定：逼着按清单重建账号
@?/rdbms/admin/securecmddb.sql
EOF
# 验证：归档模式与强制日志已生效
sqlplus / as sysdba @"SELECT log_mode, force_logging FROM v$database;"
​

装完的第一周还要补两件"向导不管"的事：RMAN 的首次 0 级备份与保留策略（5.1 的脚本）、以及一份基线快照（AWR 基线，性能对比的参照系）——没有基线，半年后"系统变慢了"就无从对证。

二、日常运维的三个节律

运维的稳定性来自节律，不来自英雄主义。每日巡检查四类红灯：备份完成状态、表空间与归档区水位、锁等待与异常会话、失败作业。每周保养做三件：过期对象清理（统计信息的年龄复查、审计轨迹归档）、性能趋势比对（本周 AWR 与上周基线对比）、容量趋势预测（按增长率预估触发扩容的时间点）。每月演练一轮小的：备份恢复抽检（5.1）、补丁前置检查、故障切换彩排（5.4 的日历）。三个节律全部脚本化、进调度，结果推送到值班群——靠人记的巡检必漏，自动化才是可靠的同义词。

图 9-1：安装基线与运维节律全景

巡检脚本包的其余三段与备份同构：空间段查 dba_free_space 水位与告警线（85% 提醒、92% 告警）、锁段跑 3.2 的阻塞链查询（等待超过 5 分钟即报）、作业段查 dba_scheduler_job_run_details 的失败条目。四段脚本配一个调度作业，输出拼成每日值班日报——这套东西一天就能写完，价值能吃很多年。

三、案例：新值班员的第一周复盘

背景。 小陈的一周：周一装测试环境、周三接了 3 条告警、周五走第一轮完整巡检。周五复盘会上导师让他回答一个问题：这周哪些事印证了前面章节的知识？

操作与结果。 小陈的清单：装库时按 2.3 的分居原则划了磁盘组，归档没有和数据文件同盘——印证第 2 章；周三的告警之一是表空间 92%，他用 1.2 的五层楼查询定位到是某个报表中间段膨胀，扩张了事并留了增长监控——印证第 1 章；另一条告警是批量作业锁等待，他按 3.2 的三连查五分钟解套——印证第 3 章；周五巡检发现备份作业有一次静默失败，核对后补跑并给备份作业加了完成校验——印证第 5 章。

解读。 复盘的结论值得写进任何团队的值班培训：新人的上手速度不取决于背了多少参数，取决于告警与前章知识之间的映射表熟不熟——水位类告警找第 1、2 章，阻塞类找第 3 章，性能类找第 6 章，备份类找第 5 章。这张映射表也是本册目录的另一种读法。变式。 若新人接手的是多租户或云托管环境，映射表要加两行：全容器异常找 8.1 的共享边界分析、平台侧告警先分清责任边界再动手（8.2 的责任表）——架构形态变了，映射表的行数跟着变。

四、常见问题

问题一：测试环境与生产的差异清单该长什么样？ 一张两列的表：左列"生产必有"，右列"测试豁免"，每行注明豁免理由与风险承接人。归档、备份、审计通常是生产必有；测试豁免的往往是 license 约束下的诊断包、真实规模的负载。清单的存在不是为了对齐，而是为了把"不一样"从隐患变成明账。

问题二：多套环境的配置漂移怎么管？ 基线配置进版本管理（参数导出与脚本同仓），每次变更走同一套评审，每月跑一次配置比对把漂移暴露出来。工具可以很朴素——两份参数导出做 diff 就能抓住八成的漂移。漂移不可怕，看不见的漂移才可怕。

问题三：巡检发现的灰区问题怎么归类？ 设一个"待观察"状态并配观察期限：比如表空间 80% 水位未到告警线但增速陡峭，进待观察清单、两周后复查。灰区问题最大的风险不是恶化，而是每次巡检都重新讨论一遍——有状态、有期限，它才会要么升级成工单、要么正式解除。

问题四：装库后的第一天还有哪三件事？ 除了正文里的备份与基线，补上这三件：把新库纳入监控与告警清单（不然它是一个没人看的孩子）、记录一份完整的参数与拓扑快照（日后对证的原始档案）、给值班群发一条入库通告（写清用途、责任人、变更流程）——三个动作不到一小时，省掉的是数月的悬案。

⚠️ 常见坑：测试环境随便装、生产环境照抄测试。测试库不归档、不备份、审计关掉，图省事；最怕的是"生产安装时照着测试的 checklist 走"——归档忘了开、备份没排上，等发现时库已经跑了一年。两套环境可以有不同规格，但基线清单的差异项要显式列出，而不是默认一致。

本节要点回顾

• 装对而非装上：归档、内存、字符集、磁盘布局在安装时就定对，两年后的成本差一个量级。
• 三段清单：装前规划容量与布局、装后基线配置与首次备份、附赠一张 AWR 基线作日后对证的参照。
• 三个节律自动化：日巡检红灯清单、周保养趋势比对、月演练抽检彩排——脚本与调度是可靠性的本体。
• 新人映射表：告警分类对应章节知识，上手速度取决于这张表熟不熟。

工具备齐了手册也立住了，最后一节清点装备：官方工具、第三方补位与开发接口。