Добрый день!

Работаю с Oracle уже 25 лет и вот, наконец попал в тупик. До сих пор как то удавалось разбираться самому.

Поставил зачем-то кластер самой современной версии, 12.2.0.1. Работал кластер плохо, непонятно и в конце концов, после отказа сервера загнулся окончательно. При старте не видит "vote дисков".

2019-03-27 18:42:14.944 : SKGFD:5398: Execute glob on the string /dev/rhdiskp*
2019-03-27 18:42:14.944 : SKGFD:5398: running stat on disk:/dev/rhdiskpower0
2019-03-27 18:42:14.944 : SKGFD:5398: running stat on disk:/dev/rhdiskpower1
2019-03-27 18:42:14.944 : SKGFD:5398: running stat on disk:/dev/rhdiskpower2
2019-03-27 18:42:14.945 : SKGFD:5398: running stat on disk:/dev/rhdiskpower3
2019-03-27 18:42:14.945 : SKGFD:5398: running stat on disk:/dev/rhdiskpower4
2019-03-27 18:42:14.945 : SKGFD:5398: running stat on disk:/dev/rhdiskpower5
2019-03-27 18:42:14.945 : SKGFD:5398: Fetching UFS disk :/dev/rhdiskpower5:
2019-03-27 18:42:14.945 : CLSF:5398: Ignoring 0-byte file /dev/rhdiskpower5
2019-03-27 18:42:14.945 : SKGFD:5398: Fetching UFS disk :/dev/rhdiskpower4:
2019-03-27 18:42:14.945 : CLSF:5398: Ignoring 0-byte file /dev/rhdiskpower4
2019-03-27 18:42:14.945 : SKGFD:5398: Fetching UFS disk :/dev/rhdiskpower3:
2019-03-27 18:42:14.945 : CLSF:5398: Ignoring 0-byte file /dev/rhdiskpower3
2019-03-27 18:42:14.945 : SKGFD:5398: Fetching UFS disk :/dev/rhdiskpower2:
2019-03-27 18:42:14.945 : CLSF:5398: Ignoring 0-byte file /dev/rhdiskpower2
2019-03-27 18:42:14.945 : SKGFD:5398: Fetching UFS disk :/dev/rhdiskpower1:
2019-03-27 18:42:14.945 : CLSF:5398: Ignoring 0-byte file /dev/rhdiskpower1
2019-03-27 18:42:14.945 : SKGFD:5398: Fetching UFS disk :/dev/rhdiskpower0:
2019-03-27 18:42:14.945 : CLSF:5398: Ignoring 0-byte file /dev/rhdiskpower0
2019-03-27 18:42:14.945 : SKGFD:5398: OSS discovery with :/dev/rhdiskp*:
2019-03-27 18:42:14.946 : CSSD:5398: clssnmvDiskVerify: Successful discovery of 0 disks
2019-03-27 18:42:14.946 : CSSD:5398: clssnmCompleteInitVFDiscovery: Completing initial voting file discovery
2019-03-27 18:42:14.946 : CSSD:5398: clssnmvFindInitialConfigs: No voting files found
2019-03-27 18:42:14.946 : CSSD:5398: clssnmInitDummyConfig: Rimhub misscount 30
2019-03-27 18:42:14.946 : CSSD:5398: clssnmCompleteVFDiscovery: Completing voting file discovery


Устройства которые они пробегает естественно существуют, на них выданы соответтсвующие права:

-bash-4.4$ ls -l /dev/rhdiskp*
crw-rw---- 1 grid asmadmin 43, 0 Oct 20 2017 /dev/rhdiskpower0
crw-rw---- 1 grid asmadmin 43, 1 Oct 20 2017 /dev/rhdiskpower1
crw-rw---- 1 grid asmadmin 43, 2 Oct 20 2017 /dev/rhdiskpower2
crw-rw---- 1 grid asmadmin 43, 3 Oct 20 2017 /dev/rhdiskpower3
crw-rw---- 1 root system 43, 4 Oct 20 2017 /dev/rhdiskpower4
crw-rw---- 1 root system 43, 5 Oct 20 2017 /dev/rhdiskpower5


но за каким то лешим теперь они "0-byte". То есть проблема на стыке ОС и базы, в какую сторону рыть не понимаю...
Может есть у кого база на подобных дисках, это PowerPath от EMC вроде. Подскажите пожалуйста.

SalXpek,

по CRS-1714 первое что гуглится

https://www.hhutzler.de/blog/crs-doesnt-start-due-to-crs-1714-error/

гельмут этот глубоко копал кластерварь, так что может что-то полезное в его статьях обнаружится.

так у вас какая ОС? и потом, это на одном узле, а что с другими?


Это я уже видел. Там как минимум не совпадают команды, имена устройств и схемы их расположения... Думаю это все по 11 версии.
ОС AIX. Другой узел тоже не поднимается, но детально анализ я стал вести на одном узле. Думаю на другом та же ситуация.

Пока есть подозрение что после ремонта сервера нарушились связи в ОС между устройствами hdisk - hdiskpower, hdisk пересоздались заново, а конфигурация powerpath не увидела это. Буду удалять-создавать все /dev/hdisk* заново...

flexgenПочему owner дисков 4 и 5 system а не asmadmin? Какой именно диск был определен как voting при установке GRID? Что в файле /proc/partitions? Сколько серверов в кластере?

Потому что не нужно. Это boot-диски для операционных систем, там базе искать нечего. Диски для базы именно 0-3

Сейчас кластер починить удалось. Действительно, после жесткой иннициализации сервера после ремонта нарушились связи между /dev/hdisk* в операционной системе и псевдоустройствами hdiskpower*

Пришлось все чистить и конфигурить заново. В конечном итоге hdiskpower заново подхватил реальные диски и кластер их увидел. Печально что "zero-byte file" - это все что можно добиться от системы, дальше приходится гадать. Естесвенно, эти устройства никакой не нулевой длины, все нормально. Но вот так видит все это Oracle...

Последнее обо что я споткнулся - это chdev -l hdisk* -a reserve_policy=no_reserve . В доках это есть, но если пересоздать пути устройств, то данный атрибут сбрасывается.

Если это забыть восстановить, то стартует только одна нода.

CrazyCatа зачем пялили прослойку от EMC? вроде как AIX сам прекрасно умеет мультипас.

да, тут я неправ. Эта ерунда была ни к чему, но куплена.