解决方案 »

  1.   

    应该是文件夹权限的问题吧
    前面有几个警告信息
    WARNING: directory '/opt/ora10g/product/10.20.0' is not owned by root
    WARNING: directory '/opt/ora10g/product' is not owned by root
    WARNING: directory '/opt/ora10g' is not owned by root
    这几个文件夹root无法访问
      

  2.   

    1).确保所有的网络(包括私有网络、公共网络)都能够正常的ping通。
    2).确保所有RAC节点服务器的防火墙都是关闭状态。
    3).确保所有RAC节点都能够正常的连接存储,且对存储相应的设备有正常的访问权限,例如,存储表决磁盘和ocr的设备所有者应该是oracle:oinstall
      

  3.   

    1).确保所有的网络(包括私有网络、公共网络)都能够正常的ping通。
    2).确保所有RAC节点服务器的防火墙都是关闭状态。
    3).确保所有RAC节点都能够正常的连接存储,且对存储相应的设备有正常的访问权限,例如,存储表决磁盘和ocr的设备所有者应该是oracle:oinstall
    我的网络配置如下:
    [root@RAC1 ~]# cat /etc/hosts
    # Do not remove the following line, or various programs
    # that require network functionality will fail.
    127.0.0.1               localhost.localdomain localhost
    ::1             localhost6.localdomain6 localhost6
    192.168.23.140 RAC1
    192.168.23.141 RAC2
    192.168.23.201 RAC1-vip
    192.168.23.202 RAC2-vip
    10.10.17.221 RAC1-priv
    10.10.17.222 RAC2-priv
    下面是我在两个节点互ping都是同的,在RAC1上ping RAC2结果如下:
    [root@RAC1 ~]# ping 192.168.23.141
    PING 192.168.23.141 (192.168.23.141) 56(84) bytes of data.
    64 bytes from 192.168.23.141: icmp_seq=1 ttl=64 time=16.2 ms
    64 bytes from 192.168.23.141: icmp_seq=2 ttl=64 time=0.480 ms
    64 bytes from 192.168.23.141: icmp_seq=3 ttl=64 time=0.392 ms
    64 bytes from 192.168.23.141: icmp_seq=4 ttl=64 time=0.404 ms--- 192.168.23.141 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3001ms
    rtt min/avg/max/mdev = 0.392/4.392/16.293/6.871 ms
    [root@RAC1 ~]# ping 10.10.17.222
    PING 10.10.17.222 (10.10.17.222) 56(84) bytes of data.
    64 bytes from 10.10.17.222: icmp_seq=1 ttl=64 time=2.57 ms
    64 bytes from 10.10.17.222: icmp_seq=2 ttl=64 time=0.400 ms
    64 bytes from 10.10.17.222: icmp_seq=3 ttl=64 time=0.415 ms
    64 bytes from 10.10.17.222: icmp_seq=4 ttl=64 time=0.215 ms--- 10.10.17.222 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3000ms
    rtt min/avg/max/mdev = 0.215/0.900/2.570/0.967 ms
    下面是RAC2 上面ping RAC1的结果如下:
    [root@RAC2 ~]# ping 192.168.23.140
    PING 192.168.23.140 (192.168.23.140) 56(84) bytes of data.
    64 bytes from 192.168.23.140: icmp_seq=1 ttl=64 time=0.384 ms
    64 bytes from 192.168.23.140: icmp_seq=2 ttl=64 time=0.184 ms
    64 bytes from 192.168.23.140: icmp_seq=3 ttl=64 time=0.712 ms--- 192.168.23.140 ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2000ms
    rtt min/avg/max/mdev = 0.184/0.426/0.712/0.218 ms
    [root@RAC2 ~]# ping 10.10.17.221
    PING 10.10.17.221 (10.10.17.221) 56(84) bytes of data.
    64 bytes from 10.10.17.221: icmp_seq=1 ttl=64 time=0.465 ms
    64 bytes from 10.10.17.221: icmp_seq=2 ttl=64 time=0.425 ms
    64 bytes from 10.10.17.221: icmp_seq=3 ttl=64 time=0.380 ms--- 10.10.17.221 ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 1999ms
    rtt min/avg/max/mdev = 0.380/0.423/0.465/0.038 ms
    下面查看防火墙设置:
    RAC1的防火墙关闭:
    [root@RAC1 ~]# service iptables status
    Firewall is stopped.
    RAC2的防火墙关闭
    [root@RAC2 ~]# service iptables status
    Firewall is stopped.
    你说的第三条我不知道我列出的对不对但是两个节点缺失有不一样的:
    RAC1的节点的存储:
    [root@RAC1 ~]# ls -l /dev/raw
    total 0
    crw-r--r-- 1 oracle oinstall 162, 1 Oct 22 19:23 raw1
    crw-r----- 1 root   oinstall 162, 2 Oct 22 17:54 raw2
    crw-r----- 1 oracle oinstall 162, 3 Oct 22 14:25 raw3
    crw-r----- 1 oracle oinstall 162, 4 Oct 22 14:25 raw4
    RAC2的节点的存储:
    [root@RAC2 ~]# ls -l /dev/raw
    total 0
    crw-r--r-- 1 oracle oinstall 162, 1 Oct 22 18:04 raw1
    crw-r--r-- 1 oracle oinstall 162, 2 Oct 22 20:01 raw2
    crw-r----- 1 oracle oinstall 162, 3 Oct 22 14:25 raw3
    crw-r----- 1 oracle oinstall 162, 4 Oct 22 14:25 raw4
    请问问题是不是出在RAC1的raw2这个上面啊是不是把它改成和RAC2一样再试一试
      

  4.   

    这个问题应该不在网络,重点关注磁盘。确定在rac2上,是用root用户操作的,且root用户对raw1,raw2有操作权限
      

  5.   

    怎么知道root用户对raw1,raw2有没有操作权限
      

  6.   

    磁盘访问的话有两种可能,一是连接有问题,而是权限问题
    如果raw1,raw2在同一个物理共享磁盘上,可以拿别的没用的分区来用dd做试验,如果可以操作,则排除第一种可能
    权限配置如下
    chown root:oinstall <OCR device>
    chmod 640 <OCR device>chown oracle:oinstall <Voting device>
    chmod 644 <Voting device>
      

  7.   

    磁盘访问的话有两种可能,一是连接有问题,而是权限问题
    如果raw1,raw2在同一个物理共享磁盘上,可以拿别的没用的分区来用dd做试验,如果可以操作,则排除第一种可能
    权限配置如下
    chown root:oinstall <OCR device>
    chmod 640 <OCR device>chown oracle:oinstall <Voting device>
    chmod 644 <Voting device>
    磁盘访问的话有两种可能,一是连接有问题,而是权限问题
    如果raw1,raw2在同一个物理共享磁盘上,可以拿别的没用的分区来用dd做试验,如果可以操作,则排除第一种可能
    权限配置如下
    chown root:oinstall <OCR device>
    chmod 640 <OCR device>chown oracle:oinstall <Voting device>
    chmod 644 <Voting device>
    首先我用的是虚拟机,还有我从新执行过一次start_udev成功后ls -l /dev/raw
    结果是
    root@RAC1 oracle]# ls -l /dev/raw
    total 0
    crw-r----- 1 oracle oinstall 162, 1 Oct 23 13:20 raw1
    crw-r----- 1 oracle oinstall 162, 2 Oct 23 13:20 raw2
    crw-r----- 1 oracle oinstall 162, 3 Oct 23 13:20 raw3
    crw-r----- 1 oracle oinstall 162, 4 Oct 23 13:20 raw4
    但是我在此执行root.sh后来就变成这样
    [root@RAC1 crs_1]# ls -l /dev/raw
    total 0
    crw-r--r-- 1 oracle oinstall 162, 1 Oct 23 14:26 raw1
    crw-r----- 1 root   oinstall 162, 2 Oct 23 13:20 raw2
    crw-r----- 1 oracle oinstall 162, 3 Oct 23 13:20 raw3
    crw-r----- 1 oracle oinstall 162, 4 Oct 23 13:20 raw4
    我觉得是raw2的问题,还有我能加下你qq吗,我没有别的意思只想解决这个问题还有我在MOS上看了一下
    This particular case is caused by the OSinit system does not working." Failure at final check of Oracle CRS stack.
    10" 
    means CRS daemon did not startup during 600 seconds period. In the root.sh script, it adds CRS relatedentry in /etc/inittab, run "init q" and expect 3 CRS related daemonprocesses to start, eg:init.cssd
    init.crsd
    init.evmd With init system problem, none of thesedaemon processes are spawned, this causes CRS process startup failure as theyrely on the CRS daemon processes to start first.
    --这里说明是init system problem 出现问题,导致进程无法启动。可以通过以下方法验证这个问题:
    This can be verified by adding a simple entry in /etc/inittab:test:2:once:/usr/bin/echo "HELLOTEST" > /tmp/test.log
    run "init q" as root user. If the init is working, then there shouldbe a file /tmp/test.log generated. 
    Solution --MOS上仅给出了AIX上的解决方案,如下:Please consult with system administrator tofix initissue.Here the solution is only valid for AIXplatform:1. Starting the script install_assist (AIXGUI utility Installation Assistance)
    2. Updating for example the date, then exit install_assist properly
    3. Reboot the system
    After that daemon process in /etc/inittab started, CRS installation completed.
      

  8.   

    上班期间用不了QQ。root.sh执行过后,权限发生改变,这是正常的
    刚才没注意看,是在up进程的时候报错的,找找对应进程启动的日志