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 四者的协同。漏掉任意一环，异步就只是纸上谈兵。
