磁盘慢，数据库就慢。Oracle I/O 一旦踩坑，CPU 再强也白搭。下面 这些问题，带你直抵Oralce数据库存储底层真相，让“等待 I/O”不再是 AWR 报告里的头号罪犯。
问：什么是 I/O 受限（I/O-bound）应用？ 答：指 CPU 大量时间花在等待磁盘 I/O 完成，系统吞吐量受磁盘速度而非 CPU 制约的应用。
问：Oracle 建议在数据库文件存储上优先使用哪种技术？为什么？ 答：优先使用 Oracle ASM（Automatic Storage Management），因为它集成条带化、镜像、在线重平衡和托管文件管理，简化运维并提升性能。
问：I/O 设计时必须同时考虑哪三大要素？ 答：存储容量（最小磁盘空间）、可用性（7×24 或业务时段）、性能（I/O 吞吐量与响应时间）。
问：条带深度（stripe depth）与条带宽度（stripe width）分别指什么？ 答：条带深度是单个条带单元大小；条带宽度=条带深度×条带化集中磁盘数量，代表一次并行 I/O 可跨的磁盘数。
问：在顺序读取场景下，推荐的最小条带深度如何计算？ 答：最小条带深度 ≥ 2 × DB_FILE_MULTIBLOCK_READ_COUNT × DB_BLOCK_SIZE，以避免单个逻辑 I/O 被拆成多次物理 I/O。
问：OLTP 高并发小 I/O 场景应选粗粒度还是细粒度条带化？ 答：应选粗粒度条带化（较大条带深度），让多块磁盘同时服务大量并发请求，提升总体吞吐量。
问：为什么表和它的索引通常可以放在同一磁盘而不必人为分离？ 答：事务访问顺序是先索引后表，I/O 顺序发生，不会在同一时刻争用同一块磁盘，因此除非 I/O 速率极高，无需特意分离。
问：重做日志文件应如何放置以减少 LGWR 的争用？ 答：将每组重做日志放在独立磁盘，避免与其他文件共存；同一组多成员需跨磁盘与控制器做镜像；避免使用 RAID 5。
问：为什么不推荐对重做日志使用 RAID 5？ 答：RAID 5 （需读-改-写），而重做日志是顺序写，对延迟极敏感，RAID 5 会显著拖慢 LGWR。
问：Oracle Managed Files（OMF） 的三大管理优势是什么？ 答：自动命名与删除文件，减少人为错误；统一目录管理，简化测试/开发；可与用户管理文件混用，平滑过渡。
问：选择 8 KB 作为默认数据块大小的主要理由是什么？ 答：8 KB 在 OLTP 与 DSS 之间取得平衡，既减少随机访问的块争用，又能容纳中等规模行与索引，适用于大多数混合负载。
问：小数据块（如 4 KB）的两大缺点是什么？ 答：块头比例高导致空间浪费；大行易产生行链接/迁移，增加额外 I/O。
问：大数据块（如 16 KB 以上）在 OLTP 索引块上的主要风险是什么？ 答：增大索引叶块，造成并发更新时的块争用（buffer busy waits），降低并发性能。
问：运行 DBMS_RESOURCE_MANAGER.CALIBRATE_IO 有哪三项先决条件？ 答：1) 用户具有 SYSDBA；2) timed_statistics=TRUE；3) 数据文件已启用异步 I/O（FILESYSTEMIO_OPTIONS=SETALL）。
问：I/O 校准输出的 max_iops 与 max_mbps 分别对应哪类工作负载？ 答：max_iops（8 KB 随机读）对应 OLTP；max_mbps（1 MB 随机读）对应 DSS/数据仓库。
问：在高并发随机 I/O 场景下，如何设置条带深度以避免单个逻辑 I/O 触发多次物理 I/O？ 答：条带深度 ≥ 2 × DB_BLOCK_SIZE，并保证条带宽度足够大，使并发小请求落到不同磁盘。
问：若系统无 LVM 条带化，手动分配 I/O 的核心原则是什么？ 答：依据各文件的 I/O 速率而非文件类型进行分布，将高 I/O 文件均匀拆分至不同磁盘，持续监控并调整。
问：将归档日志移到独立磁盘的好处有哪些？ 答：顺序归档写入不会抢占数据盘带宽；归档盘响应时间恶化不影响业务 I/O；可按归档生成速率独立扩容。
问：何时应考虑将 TEMP 表空间数据文件单独隔离？ 答：当 SQL 优化后仍无法降低磁盘排序 I/O，且 TEMP 文件的 I/O 速率持续成为系统瓶颈时。
问：使用 Orion 进行离线 I/O 测试与在数据库内运行 CALIBRATE_IO 有何本质区别？ 答：Orion 无需安装 Oracle 实例即可模拟 Oracle I/O 模型，适合上线前验证硬件；CALIBRATE_IO 则在已有实例上运行，结果更贴近真实数据文件布局与缓存行为。
把 这些坑一次填平，I/O 曲线立刻变平。下次有人抱怨“数据库卡”，你可以淡定回一句：磁盘已经没问题，去看看别的吧。
