IO_DISK_ASYNCH_IO 并非 Linux 内核参数，而是误传；真实需调优的是 Oracle 的 disk_asynch_io 与 filesystemio_options 配合 libaio 或 io_uring，辅以 aio-max-nr 设置、文件系统挂载选项及权限配置。
IO\_DISK\_ASYNCH\_IO 是什么，它根本不存在于 Linux 内核
linux 内核没有 io_disk_asynch_io 这个参数。这是常见误传，通常源于把 oracle 数据库的初始化参数 disk_asynch_io、filesystemio_options 和 linux 的异步 i/o 机制（如 io_uring 或 libaio）混为一谈。
真实场景中，用户想调优的是：Oracle 在 Linux 上是否启用异步磁盘 I/O，以及底层文件系统和内核是否支持、是否生效。
- Oracle 的
disk_asynch_io=TRUE仅在使用裸设备或开启filesystemio_options=ASYNCH时才可能触发 Linux 层的异步 I/O 调用 - 现代 Linux（5.1+）默认启用
io_uring，但 Oracle 19c 及更早版本仍主要依赖libaio（即传统的aio_read/aio_write） -
/proc/sys/fs/aio-max-nr控制的是整个系统的 AIO 请求并发上限，不是“开关”
检查并调大 AIO 并发限制（aio-max-nr）
Oracle 启动时若发现可用 AIO slots 不足，会静默降级为同步 I/O —— 这是性能骤降却无明显报错的最常见原因。
确认当前值：
cat /proc/sys/fs/aio-max-nr
典型问题现象：ORA-27091: unable to queue I/O 或数据库日志中出现 Asynchronous I/O disabled。
- 临时生效（重启失效）：
echo 1048576 > /proc/sys/fs/aio-max-nr - 永久生效：在
/etc/sysctl.conf中添加fs.aio-max-nr = 1048576，再执行sysctl -p - 注意：该值不是越大越好；过大会占用内核内存，建议按实例并发写线程数 × 2～3 倍估算（如 512 个 DBWR 进程 → 设为 2097152）
文件系统挂载选项影响 AIO 实际行为
即使 disk_asynch_io=TRUE，若文件系统以 noatime,nobarrier,commit=60 等方式挂载，AIO 可能被内核绕过或退化为同步路径，尤其在 ext4/xfs 上。
关键点：
- xfs 推荐启用
inode64和logbufs=8，避免 inode 分配锁争用影响 AIO 提交 - ext4 必须禁用
data=journal模式（该模式强制同步元数据，使 AIO 失效） - 所有文件系统都应避免挂载时加
sync选项 —— 它直接关闭块层异步能力 - 验证是否生效：
mount | grep $ORACLE_HOME，确认不含sync、data=journal
Oracle 如何真正启用异步 I/O（非数据库参数层面）
光设 disk_asynch_io=TRUE 不够。必须满足三个条件，AIO 才真正走内核异步路径：
- 数据库使用文件系统（而非裸设备）时，
filesystemio_options必须设为ASYNCH或SETALL（SETALL同时启用 direct I/O + async I/O） - Oracle 用户需有
sys_admin或cap_sys_admin权限（libaio要求），否则aio_setup系统调用失败 - 确认
libaio已安装：rpm -q libaio（RHEL/CentOS）或dpkg -l libaio1（Debian/Ubuntu） - 验证运行时行为：用
strace -p $PID -e trace=aio_read,aio_write,io_submit观察 Oracle 进程是否真在调用异步接口
容易被忽略的是权限问题：容器化部署时，--cap-add=SYS_ADMIN 缺失会导致 AIO 初始化失败，但 Oracle 日志里只写 “async I/O not available”，不提权限。
