3. 交付物体系设计
数据库项目验收中最常见的争议，不是“系统能不能跑”，而是“交付物是否齐全、版本是否一致、配置是否可追溯”。交付物体系设计的核心目标，是让验收方能够沿着一条清晰的证据链，从安装介质一直追溯到运行中的数据库实例，并确认每一个环节都有对应的文档、脚本、报告或配置基线作为支撑。本节围绕 Oracle 数据库项目从安装部署到运维移交的完整生命周期，梳理各阶段应产出的交付物类型、内容要求与相互关系。
一、交付物体系的四个层次
交付物并非简单的文件堆叠，而是按“证据强度”和“使用场景”分为四个层次。第一层是基线类交付物，包括安装介质清单、数据库参数基线、表空间与用户规划、字符集与NLS设置等，它们定义了“系统应该是什么样”。第二层是过程类交付物，包括安装部署脚本、建库脚本、补丁应用记录、数据迁移脚本等，它们记录了“系统是如何被构建出来的”。第三层是验证类交付物，包括安装检查报告、参数比对报告、连接测试记录、性能基线报告等，它们证明“系统确实达到了预期状态”。第四层是运维类交付物，包括备份恢复手册、日常巡检脚本、监控指标清单、故障处理预案等，它们支撑“系统交付后如何持续运行”。
这四层之间不是并列关系，而是逐层依赖：基线类定义目标，过程类实现目标，验证类确认目标，运维类延续目标。验收时如果只看到过程类脚本而缺少验证类报告，就无法判断脚本执行结果是否正确；如果只有验证报告而缺少基线定义，则无法判断验证标准是否合理。
二、各阶段交付物的具体内容与验收要点
安装部署阶段的交付物重点在于“可复现”。安装介质清单应记录Oracle版本号（如19.3.0）、平台（Linux x86-64）、补丁集（如19.19 RU）以及每个文件的MD5校验值。安装脚本应包含响应文件（response file）和静默安装命令，例如：
./runInstaller -silent -responseFile /u01/soft/db_install.rsp \
-ignorePrereq -waitforcompletion
验收时需核对安装日志中是否出现“Successfully Setup Software”字样，并检查$ORACLE_HOME/OPatch/opatch lspatches输出是否与补丁清单一致。建库脚本应包含CREATE DATABASE语句、表空间创建语句、用户与权限分配语句，并明确字符集（如AL32UTF8）和NLS参数。验收要点是：脚本能在干净环境中完整执行，且执行后SELECT name, open_mode FROM v$database返回“READ WRITE”。
配置基线阶段的交付物核心是“参数快照”。建议使用CREATE PFILE FROM SPFILE导出参数文件，并整理为基线表。以下为示例参数基线（教学示例，非实测值）：
| 参数名 | 基线值 | 说明 |
|---|---|---|
| sga_target | 4G | 根据物理内存与并发量设定 |
| pga_aggregate_target | 1G | 排序与哈希运算内存 |
| db_recovery_file_dest_size | 50G | 归档日志空间上限 |
| log_archive_dest_1 | LOCATION=/arch | 归档路径 |
| processes | 500 | 最大进程数 |
| nls_characterset | AL32UTF8 | 字符集 |
验收时使用SHOW PARAMETER或查询v$parameter逐项比对，差异项需在报告中说明原因。例如，若实际sga_target为3G而基线为4G，需确认是否因物理内存不足而调整，并记录审批人。
验证阶段的交付物应形成“测试—记录—结论”的闭环。连接测试需覆盖监听状态（lsnrctl status）、TNS解析（tnsping ORCL）、本地登录（sqlplus / as sysdba）和远程登录（sqlplus user/pass@ORCL）。性能基线报告可采集AWR快照，记录关键SQL的响应时间与执行计划。验收判断依据是：所有测试项通过，且性能指标不低于预设阈值（如简单查询响应时间小于200ms）。
运维移交阶段的交付物需具备“可操作性”。备份恢复手册应包含RMAN全备与增量备份脚本、恢复演练步骤、归档日志清理策略。巡检脚本应覆盖表空间使用率、无效对象、告警日志错误、备份作业状态等检查项。监控指标清单应明确阈值，例如表空间使用率超过85%触发告警。故障处理预案应针对常见场景（如ORA-00257归档满、ORA-01555快照过旧）给出排查路径与处置命令。
三、交付物之间的追溯关系
交付物体系的价值不仅在于“有”，更在于“可追溯”。建议建立一张交付物追溯矩阵，将基线项、过程脚本、验证报告和运维文档关联起来。例如，参数基线中的db_recovery_file_dest_size=50G，对应安装脚本中的参数设置语句、验证报告中的参数比对记录、以及运维手册中的归档空间监控项。当验收方抽查某一项时，能够沿着矩阵快速定位到所有相关交付物。
实际操作中，可使用简单的表格维护追溯关系：左侧列出基线项编号，右侧列出对应的脚本文件名、报告章节和运维文档页码。这样在验收会议中，任何一项质疑都能在几分钟内找到证据，而不是临时翻找文件。
综上，交付物体系设计的关键在于：以基线定义目标，以过程记录实现，以验证确认结果，以运维延续保障。四层交付物相互支撑，形成完整的证据链，才能让数据库项目验收从“口头确认”走向“文件可查、状态可验、责任可追”。