Oracle挂载NFS必须加nolock，因其自身实现文件级锁机制，与Linux内核NFS lockd服务冲突，导致ORA-27086错误；加nolock可禁用rpc.lockd，交由Oracle自主管理锁，且仅适用于NFSv3（需配vers=3）。
Oracle 不能直接用默认 NFS 挂载方式写数据文件，必须显式加 nolock，否则会报 ORA-27086: unable to lock file - already in use。
为什么 Oracle 挂载 NFS 必须加 nolock
Oracle 自身实现了文件级锁机制（如 datafile、controlfile 的并发控制），而 Linux 内核的 NFS 客户端默认启用 lockd（NFS 文件锁服务）。两者冲突：Oracle 尝试加锁时，lockd 返回 No locks available（错误 37），导致建表空间、恢复、RMAN 写入等操作失败。
加 nolock 并不是“禁用所有锁”，而是禁用 NFS 协议层的 rpc.lockd，把锁交给 Oracle 自己管 —— 这是 Oracle 官方支持且要求的模式（尤其在非 RAC 单实例 + NFS 场景下）。
- 不加
nolock：挂载成功，但CREATE TABLESPACE或RESTORE DATABASE会立即报ORA-27086 - 加了
nolock后仍报错？检查服务端/etc/exports是否漏了no_root_squash或权限不足（如chmod 777未生效） -
nolock仅对 NFSv3 有效；NFSv4 默认内置锁管理，不兼容 Oracle Direct NFS，所以必须强制用vers=3
mount 命令必须带的关键参数
客户端挂载命令不能只写 mount -t nfs server:/path /mnt。Oracle 生产环境需至少包含以下参数组合：
-
nolock：绕过内核锁服务，必须项 -
vers=3：强制使用 NFSv3 协议（NFSv4 不被 Oracle Direct NFS 支持） -
hard：保证 I/O 不丢数据，断连后重试而非静默失败 -
bg：挂载失败时后台重试，避免启动卡住 -
rsize=32768,wsize=32768：提升单次读写块大小，减少 RPC 调用次数 -
timeo=600：超时设为 600 分钟（单位是 1/10 秒），避免短时网络抖动触发硬错误 -
tcp：强制走 TCP，比 UDP 更可靠（尤其跨子网或高延迟链路）
完整示例：mount -t nfs -o nolock,vers=3,hard,bg,rsize=32768,wsize=32768,timeo=600,tcp 192.168.2.3:/u01/nfs_storage /u01/nfs_oradata
服务端 /etc/exports 配置陷阱
即使客户端参数全对，服务端配置错一个字母也会导致权限拒绝或挂载后不可写：
- 导出目录权限必须开放：服务端执行
chmod 777 /u01/nfs_storage（或至少确保oracle用户有读写权） -
no_root_squash必须存在：否则客户端 root 用户映射为 nobody，Oracle 以 root 启动时无法写入 - 避免用
sync：它强制每次写都落盘，严重拖慢 Oracle 日志写入；改用async（仅限可信局域网） - 不要写
insecure_locks：该选项在较新内核已废弃，反而可能触发 exportfs 解析失败 - 正确写法示例：
/u01/nfs_storage *(rw,async,no_root_squash)
Oracle 启动前必须确认的三件事
挂载完不等于 Oracle 能用。以下检查缺一不可：
- 确认挂载点归属和权限：
ls -ld /u01/nfs_oradata输出中用户组应为oracle:oinstall，且有写权限 - 确认
oracle用户能实际创建文件：sudo -u oracle touch /u01/nfs_oradata/testfile，失败则回溯服务端权限或no_root_squash - 如果要用 Oracle Direct NFS（推荐），需在数据库启动前执行：
cd $ORACLE_HOME/rdbms/lib && make -f ins_rdbms.mk dnfs_on，并确认 alert 日志出现Direct NFS: channel id [0] ... is UP
最常被忽略的是：挂载后没改目录属主，或服务端 /etc/exports 没 reload（exportfs -rv 必须执行，改完文件不会自动生效）。
