《Oracle8开发使用手册》第3章：物理数据库设计、硬件与相关问题

来源：阿里云盘 /田浩然上传的资料/电子书/Oracle/oracle8开发使用手册/03.pdf（11页，文本型PDF）。本书为 Oracle 8 时代（约1999年前后）的 DBA 手册，硬件/平台细节已过时，但物理设计的通用原则至今有效。

核心观点

物理数据库设计 = “预调整”（adjustment in advance），是性能调整的第二阶段（逻辑设计是第一）。物理设计原则与性能调整原则本质相同，只是发生在数据库创建之前/期间而非之后。

类型	特征	关键度量
OLTP 联机事务处理	繁重 DML（更新为主），高并发；经典例子：航空/酒店预订	并发用户数、每秒事务数、响应时间
DSS 决策支持系统	大型只读历史库，固定/特别查询；常演化为 VLDB/DM/DW	每时间单位可读字节数
批作业处理	非交互自动应用，繁忙 DML，低并发	经过时间、并发程序数

次要类型：OLAP（分析服务，常与 MDD 配对，GIS 常与其集成）、VCDB 可变基数数据库（表行数在处理期间大幅增减，如安全授权库）。

事务分析（量化分析）：并发用户/响应时间/事务数/读写字节数的最小·平均·最大值，且必须绑定时间段（每秒事务数 >> 累积事务数）。
筛分分析（sizing）：n行 × b字节/行 ≥ 最小存储空间；经验 DBA 会乘 120% 裕量。估算值是”可用空间”而非”裸盘空间”——格式化可吃掉约 15%（4GB 盘实剩 3.4GB），买盘时需反推。
建议把 sizing 公式做成电子表格模板一次做好，以后只换输入参数。

铁律：除非有非常好的理由否则不要做。性能调整是第一步，非标准化是最后手段。“预判会有不良性能”不是理由，实际存在的不良性能也不是立即放弃标准化的理由。
典型手法与代价：
- 预先联合总是一起用的 3 个表 → 需要自己写应用级完整性控制，且副本同步是苦役。
- 非标准化视图 → 性能与原始三表相同或更差，仅接口简单；此时 Oracle 聚簇可能更合适。
- 时间序列是唯一常见且通常必要的场景：时间是主键一部分导致其他主键列大量重复（卫星数据例：每小时100行×8小时=800次重复卫星ID）。解法：行转列（100个时戳列，800行→8行），扫描行数大减、查询提速；代价是表变非标准、外键约束失效，只能靠检查约束/触发器/应用完整性补。教训：为性能放弃标准化，必然在完整性管理上付出代价。

关键思想：机电劣势（electromechanical disadvantage）——任何有马达运动件的介质天然慢于纯电子设备。金字塔：CPU寄存器/缓存 → 内存 → 快速磁盘 → RAID → SCSI 慢盘 → 磁带/光盘（联机→脱机）。越往上越快、越贵、容量越小。
HSM 分层存储管理：旧数据放慢盘/磁带，有软件按需调回。
RAID 正名：I（廉价）不实——RAID 盘从不真便宜且需专门软硬件。要点：
- 靠**数据条（stripping，条带）**并行降 I/O 时间，条带是磁盘 I/O 最小单位（通常 512 字节倍数）。
- RAID 0 = 纯条带无校验（只求速度）；RAID 1 = 镜像/双工（写可能变慢、读可并行加速）；RAID 3 = 条带+单一专用校验盘（校验盘是单点故障）；RAID 5 = 校验分布所有盘、无单点。3/5 都救不了双盘失效。2/4/6 因校验数学量太大基本没人实现。
- 应用建议：RDBMS/OS 手工条带能做的 RAID 都能做且更好（精密条带、虚拟文件系统单接口、超大文件、磁盘失效容忍）；只在不需要可用性保障时才考虑手工条带。

旧观念”DBMS 是 I/O 受限”对 DSS/VLDB/DW 仍成立（查询移动 GB 级数据）；OLTP/OLAP 常是内存或 CPU 受限。瓶颈与应用类型相关。
客户/服务器架构中网络常是全系统最慢组件（比硬盘还慢）——应用分段要合理、网络不能超载。
多处理器：SMP（共享内存，当时已达 64 CPU）vs MPP（不共享、类似盒内局域网，数百~数千 CPU）。多线程 RDBMS：Sybase/Informix 完全多线程；Oracle 需 MTS 选项才是”伪多线程”。

分而治之——分区/分段/并行；前提是各块数据无关（Oracle 并行查询即此：拆分查询分跑再汇总）。
预分配和预编译——提前静态分配资源，避免软件动态分配的额外计算与 I/O；可重用过程驻存内存（Oracle KEEP 池）。
前摄——20/80 规则，预测引起 80% 麻烦的 20% 问题并设计在系统外（例：大事务批处理要预备至少一个超大回滚段，别让回滚数据挤爆 SYSTEM 表空间）。
批量、块和批处理——大量传送：同源同终点的 I/O 合并；大表连续存放+加大逻辑缓存+DB_BLOCK_SIZE 设到平台上限（当时 NT 上 8K）。根源：机电系统启动耗费（seek latency）巨大。
合理分割应用——显示归客户、数据事件归数据库（触发器/存储过程），考虑客户-网络-服务器相对能力。