环境:
NFS + Oracle database 11.2.0.4,DBCA建库

今天在DBCA建库的时候遇到了错误:
1. DBCA卡在 19%


2. DBCA的trace日志大量出现如题所示的异常,具体如下:
文件路径:/u01/app/oracle/cfgtoollogs/dbca/tuzi/trace.log

关于NFS的权限(用户与组)问题,前面我已经解决了

并且,chmod,应该也是没有问题的:

关于该问题,在11.2.0.4或之前的Oracle中,在RHEL5的平台上有过类似的BUG。
具体如下:
Bug 20352677 : DBCA RUNNING BUT ALWAYS AT 30 % -COPYING DATAFILE

BUG特征如下:

但是该问题已经被修复了。

原因:
关于NFS上的Oracle的这种问题,MOS在另一篇文档中说明了:
ORA-19624 ORA-19870 ORA-19504 ORA-27086 When Creating A Database Using DBCA On NFS (文档 ID 758274.1)

NFS作为网络文件系统,为了防止多个客户端访问同一个数据文件或者数据块,执行不同的操作而产生的问题,设计了文件锁(Lock)的机制。
NFS中,锁可以被定义为服务端的,也可以被定义为客户端的。
定义为服务端的锁意味着所有客户端访问某个数据前,首先会问服务端确认是否有锁,然后才会继续接下来的操作或者无权操作。
但是NFS的锁如果被定义在了客户端,那当某个客户端将文件锁住后,其他的客户端一开始是都不知道的,除非去访问文件后,发现有锁,报错了,才会知道。

而上面,Oracle的问题就是这样出来的。
Oracle访问NFS上的文件,但是发现上面已经被加了锁,而自己又无法解锁,于是就报出了:【Unable to lock file】
注:这不像现实里,摩拜的共享单车有锁了,你还能在锁上面再加个私锁。

解决方法:
既然问题在锁上面,所以我们就需要去NFS的服务端修改锁相关的机制的配置了。

在我的环境里,NFS是由Openfiler提供的,但是除了图形化的配置方式,最后影响的配置文件【/etc/exports】其实对所有的NFS服务都是一样的。

具体如下:

然后,看看Openfiler系统中,NFS配置文件的变化,并重启NFS服务:

关于NFS的选项的详情,如下:

关于NFS的文件锁:
文件锁是保持文件同步的一种手段,当多个用户同时操作同一个文件时,文件锁可以保证数据不发生冲突。NFSv2和NFSv3依靠NLM协议实现文件锁,NFSv4本身实现了文件锁,不需要NLM协同工作了。NFS中的文件锁既可以加在客户端,也可以加在服务器端。如果客户端挂载NFS文件系统时使用了选项nolock,表示在客户端加锁。这种情况下可以保证同一个客户端的多个进程访问同一个文件的过程不发生冲突,但是不同客户端访问同一个文件时还可能发生冲突,因为文件锁加在了客户端,其他客户端不知道这个文件锁的存在。如果客户端挂载NFS文件系统时使用了选项lock,表示在服务器端加锁,这样所有的客户端都可以检查服务器端是否存在文件锁,因此所有客户端访问同一个文件时都不会发生冲突。客户端加锁时和其他文件系统的加锁过程没有什么区别,因此我们只讲解服务器端加锁的情况。

NFS3支持文件记录fcntl和O_EXCL创建文件,但不支持文件锁。NFS的文件锁是通过Network Lock Manager(lockd后台进程)这个独立程序实现的,NFS server本身依旧是无状态的,所有的锁状态均由NLM维护。从NFS4开始,锁协议融入NFS自身的协议中,锁状态由NFS server维护,这意味这NFS4是有状态的,未简化锁设计,采用租赁锁。

NFS客户端,重新挂载:

然后,再操作建库,就没有问题了:

数据库建好后,查看一下:

可以看到,所有数据文件都在共享盘上了。

至此,该问题解决。

——————————————
Done。

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

隐藏
变装