oracle11.2.0.4 rac搭建中的crs-4000錯誤
在操作系統(tǒng)為CentOS 7.8的環(huán)境上安裝GI時,運行腳本報錯:
ASM created and started successfully.
Disk Group VOTE mounted successfully.
clscfg: -install mode specified
clscfg: EXISTING configuration version 5 detected.
clscfg: version 5 is 11g Release 2.
Successfully accumulated necessary OCR keys.
clscfg: Arguments check out successfully.
NO KEYS WERE WRITTEN. Supply -force parameter to override.
-force is destructive and will destroy any previous cluster
configuration.
Failed to create voting files on disk group VOTE.
Change to configuration failed, but was successfully rolled back.
CRS-4000: Command Replace failed, or completed with errors.
Voting file add failed
查看日志有這樣的提示:ORA-15303:?Voting files could not be created in diskgroup VOTE due to small Allocation Unit size
查看仲裁盤塊大小,發(fā)現(xiàn)問題:
[root@test1 queue]# more *block_size
::::::::::::::
logical_block_size
::::::::::::::
512
::::::::::::::
physical_block_size
::::::::::::::
4096
究其原因是它表現(xiàn)出不同的邏輯和物理塊大小。對于大多數(shù)的情況下,物理和邏輯塊的大小是相同的“512”。
查詢ORACLE的官方網(wǎng)站,給出的解決方案是:
1. Oracle bug 11780656 is already fixed in 11.2.0.3 with compatible.asm = 11.2.0.3 but OUI does not allow to specify "compatible.asm" attribute to create OCRVOTE diskgroup.
- Bug 11780656 - ASM MANAGED VOTING FILES CANNOT BE MORE THAN 64X AU SIZE
2. Oracle bug 13999609 indicates that ASMLib driver only works with the expectation that logical block size and physical block size are 512/512 bytes.
- Bug 13999609 - PHYSICAL BLOCK SIZE REPORTED CAN CAUSE ISSUES WITH 10G DATABASES
SOLUTION
1] Possible workaround is to use '/dev/oracleasm/disks/*' path instead of "ORCL:*" when creating OCRVOTE diskgroup in OUI.
OR
2] Install the new “oracleasm-support-2.1.8-1” ASMLIB RPM package (which contains the permanent fix) as described in note 1500460.1
根據(jù)以上提示,我們可以在安裝oracleasm-support-2.1.8-1的包,或者也可以在選擇ASM盤時,改用
/dev/oracleasm/disks/*的路徑來解決此問題。
若根據(jù)上述方法進行處理還是沒能解決。建議查看是否是使用的NETapp存儲,NETapp的官網(wǎng)有此問題的CASE案例。給出如下解決方案:
For details and caveats regarding this workaround, see the Oracle Alert.
Additionally, Oracle has provided a patch and configuration parameter to enable ASMlib to continue to function using the correct logical block size.
#
ORACLEASM_USE_LOGICAL_BLOCK_SIZE: 'true' means use the logical block size
# reported by the underlying disk instead of the physical. The default
# is 'false'
Netapp has also provided a workaround in versions 8.0.5, 8.1.3 and 8.2 of Data ONTAP 7-Mode. The workaround allows specified LUNs to continue to not report the logical blocks per physical block value. This work around should only be applied to LUNs used by Oracle ASMlib with the symptoms described in this article.
From the Data ONTAP 7-Mode CLI, enter the following commands:
> lun set report-physical-size <path> disable(netapp存儲設(shè)置)
進入/etc/sysconfig目錄,修改其下的oracleasm文件,將其中的
[oracle@rac1 ~]$ cat /etc/sysconfig/oracleasm
...
# ORACLEASM_USE_LOGICAL_BLOCK_SIZE: 'true' means use the logical block size
# reported by the underlying disk instead of the physical. The default
# is 'false'
ORACLEASM_USE_LOGICAL_BLOCK_SIZE=false
將ORACLEASM_USE_LOGICAL_BLOCK_SIZE=false改為true,并對應修改NETapp上的存儲設(shè)置參數(shù)
