应该是文件夹权限的问题吧 前面有几个警告信息 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无法访问
磁盘访问的话有两种可能,一是连接有问题,而是权限问题 如果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.
前面有几个警告信息
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).确保所有RAC节点服务器的防火墙都是关闭状态。
3).确保所有RAC节点都能够正常的连接存储,且对存储相应的设备有正常的访问权限,例如,存储表决磁盘和ocr的设备所有者应该是oracle:oinstall
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一样再试一试
如果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>
磁盘访问的话有两种可能,一是连接有问题,而是权限问题
如果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.
刚才没注意看,是在up进程的时候报错的,找找对应进程启动的日志