怎样优化Oracle 11g在SSD上的I/O性能_通过调整disk_asynch_io参数

disk_asynch_io=true是必要但不充分条件，SSD上真正卡性能的是filesystemio_options需设为setall、fs.aio-max-nr需调大至3145728以上、db_cache_size需充足以避免物理读抵消异步优势。

disk_asynch_io 设为 true 是必须的，但光开它没用——ssd 上真正卡性能的，是 filesystemio_options 和内核异步 i/o 资源限制。

为什么 disk_asynch_io=true 在 SSD 上可能不生效

Oracle 11g 的 disk_asynch_io 参数只是“总开关”，它只控制 DBWR、LGWR 等后台进程是否尝试发起异步 I/O 请求。但它不决定底层是否真能异步执行——这取决于操作系统是否支持、文件系统配置、以及内核资源是否足够。

在 SSD 环境下常见现象：

• 查 v$iostat_file 发现 ASYNCH_IO 列全是 DISABLED，哪怕 disk_asynch_io=true
• IO 校准（DBMS_RESOURCE_MANAGER.CALIBRATE_IO）报 ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O
• 即使启用了，db file parallel write 平均等待时间没下降，说明异步没真正跑起来

filesystemio_options 必须配对设置（尤其用文件系统时）

如果你的数据文件放在 ext4 或 xfs 文件系统上（不是 ASM），disk_asynch_io 实际被 filesystemio_options 覆盖。这个参数有四个值：none、setall、directIO、asynch，而 SSD 场景下唯一合理的选择是 setall。

• setall = 同时启用 direct I/O + asynchronous I/O —— 绕过 OS page cache，又允许并发提交多个 I/O 请求，这对低延迟 SSD 最友好
• asynch 单独设会导致 buffered I/O + 异步，反而因 double-buffering（OS cache + Oracle buffer cache）浪费内存和 CPU
• directIO 单独设是同步直写，无法发挥 SSD 并发能力
• ASM 环境下该参数无效，不用管；但文件系统部署必须显式设为 setall

Linux 内核参数 fs.aio-max-nr 必须调大

SSD 高并发 I/O 会快速耗尽默认的异步 I/O 事件槽位。Oracle IO 校准失败或 DBWR 频繁 fallback 到同步模式，往往就是这个原因。

• 默认值通常是 65536 或 1048576，对现代 SSD（尤其是 NVMe）完全不够
• 建议值：至少 3145728（3M），高负载 RAC 或多实例环境可设到 6291456
• 修改方式：echo "fs.aio-max-nr = 3145728" >> /etc/sysctl.conf && sysctl -p
• 注意：该参数是全局限制，不是 per-process；改完需重启数据库实例才生效（因为 DBWR 初始化时就申请一批 AIO context）

SGA 分配要跟上 direct I/O 的节奏

启用 setall 意味着 OS cache 被绕过，所有读都得靠 Oracle 自己的 buffer cache 满足。如果 db_cache_size 还按老习惯设得很小，就会导致大量物理读直接打到 SSD，抵消掉异步优势。

• 观察 v$sysstat 中 physical reads 和 db block gets 的比值，若 > 0.3，说明 cache 命中率不足
• SSD 虽快，但物理读仍是毫秒级，远慢于逻辑读（纳秒级）；必须把热数据尽可能留在 db_cache_size 里
• 建议：在总内存充裕前提下，将 db_cache_size 设为物理内存的 40%~60%，并关闭自动内存管理（AMM），用 ASMM 更精细控制
• 别忘了检查 db_flash_cache_size（11gR2+ 支持）——如果配了 PCIe SSD 作闪存缓存，它能进一步降低主存储压力

真正决定 SSD 上 Oracle I/O 效率的，从来不是单个参数开关，而是 disk_asynch_io、filesystemio_options、fs.aio-max-nr 和 db_cache_size 四者的协同。漏掉任意一环，异步就只是纸上谈兵。