kazak81может какие-нить команды типа updatevg, updatelv???


Для начала нужно все продиагностировать.

lspv - список физических томов.

проверить наличие и доступность путей к физ. томам
lspath
Нужно добиться, что бы для физического тома был хотябы один живой путь.

lsattr -El hdiskNN
Там можно увидеть все детали по физ тому, LUN со стораджа & WWN

посмотреть WWN адрес адаптера
lscfg -vl fcsX

После этого сверять конфигурацию.

Если винда успела прописать свои сигнатуры на тома, то думаю вам нужно искать бекап.

kazak81почитаю конечно...ошибка была такая когда пытались сделать varryon
0516-013 The volume group cannot be varied on because there are no good copies of the descriptor area
была идея сделать зеркало для logicalvolume, но не знаю... поможет ли.


Кстате, а что говорит по этому поводу errpt -a ?

Поискал в инете ,где пишут про 0516-013 , в большенстве случаев проблема возникает
когда физ. том принадлежащий vg недоступен.

Проверяйте зонинг и наличие всех путей как описано выше.

kazak81hdisk1 -- это метаимя, так ведь? Где гарантия что оно ассоциировано с тойже самой lun на сторедже что и до перезагрузки?


Если сначала сделать exportvg потом перепутать номера hdisk, то LVM при importvg и указания одного любого hdisk принадлежащего группе, разберется, и подключит все без проблем, проверено.
Я таким образом vg с одного сервера на другой пертаскивал, никаких проблем небыло .

Без експорта не пробовал, востанавливать с бэкапа дороже.


kazak81
не знаю. я не такой спец. в сторадже этот диск может иметь номер луна хоть 10. а еще фишка в том, что если мапить диск в другую группу - то я так понимаю вообще алис капут какой-то.по крайней мере для меня точно. там спрашивается какой номер назначать.. и соответственно в ОС придется заново настраивать LVM. (я так понимаю)


Нихрена не понял, у вас не получится подкинуть физ. том в другую группу без ключика -f
и читайте внимательно предупреждения, там написано что данные старой группы будут потеряны.


kazak81
lsvg -l lotusvg
lotusvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
lvlotus jfs2 256 256 1 open/syncd /lotus
loglv01 jfs2log 1 1 1 open/syncd N/A


lspv -l hdisk#
bash-2.05a# lspv -l hdisk7
hdisk7:
LV NAME LPs PPs DISTRIBUTION MOUNT POINT
lvlotus 256 256 40..108..108..00..00 /lotus
loglv01 1 1 00..00..00..00..01 N/A

lspv
hdisk0 005cf90a48c85a7d rootvg active
hdisk1 005b3b6c6a5dfb0d None
hdisk3 005b3b6c6a5dfd45 None
hdisk5 005b3b6c6a5dff8f None
hdisk6 005b3b6c6f087304 oraasvg active
hdisk7 005cf90adc9e87bc lotusvg active
hdisk9 005b3b6ca34bc070 None
hdisk10 none None
hdisk11 none None
hdisk12 005cf90aa36f00f4 lotusbigvg active
hdisk13 none None
hdisk14 none None
hdisk15 none None
hdisk16 none None


fget_config -Av

---dar0---

User array name = 'FastT600'
dac0 ACTIVE dac1 ACTIVE
dac1-hdisk1 RAID1_0
dac1-hdisk3 RAID1_1
dac1-hdisk4 RAID1_2
dac1-hdisk5 RAID1_3
dac0-hdisk6 RAID1_4
dac0-hdisk7 RAID1_5
dac1-hdisk8 RAID1_2
dac0-hdisk9 BACKP
dac1-hdisk10 ARCHLOG
dac0-hdisk11 BCKPAS
dac1-hdisk12 LOTUS (9)
dac0-hdisk13 ORATEST (10)
dac1-hdisk14
dac0-hdisk15 STBYPBS (12)
dac1-hdisk16 LINUXTST (13)

в скобках я написал номера лунов в сторадже

покажите lsvg -p <имя группы> для все имеющихся групп.

кстате я был ошибся lspath показывает только MPIO пути fastt работает по другому
протоколу(RDAC кажись называется) для него должна быть другая команда как пути смотреть.

kazak81

сейчас то пока все работает. этой ошибки пока нет. она появится после перезагрузки.
зоннинг настроили.но уже после подключения винды. так что она точно насрала в диски.


kazak81

hdisk1 005b3b6c6a5dfb0d None
hdisk3 005b3b6c6a5dfd45 None
hdisk5 005b3b6c6a5dff8f None
hdisk9 005b3b6ca34bc070 None
hdisk10 none None
hdisk11 none None
hdisk13 none None
hdisk14 none None
hdisk15 none None
hdisk16 none None


Чии это физ волумы?


А это как понимать? в свете первой цитаты.

kazak81

три Luna восстановили(они состояли из одного phisical volume), а четвертый - не получилось, т.к. он состоял из 4-х phisical volume.




у Вас непрвильно настроен зонинг и раздача томов на сторадже.
Ничего лишнего ( чужого ) AIX видеть не должен.

з.ы. с вами не интересно решать проблему, вы либо сами путаетесь
либо преднамеренно путаете ситуацию.

kazak81А это как понимать? в свете первой цитаты.

kazak81

три Luna восстановили(они состояли из одного phisical volume), а четвертый - не получилось, т.к. он состоял из 4-х phisical volume.



а понимать так, что восстанавливали данные на одной машине, а сейчас необходимо перегрузить вторую машину с совершенно другим набором дисков.

А как востанавливали?
Я сейчас не вижу ни одной группы с 4-я физ волумами.

kazak81вот, смотри
bash-2.05a# lspv
hdisk0 005b3b6c39359489 rootvg active
hdisk1 005b3b6c4c425ef3 rootvg active
hdisk2 005b3b6c1afd5ad3 oradbvg active
hdisk3 005b3b6c1afd5c21 oradbvg active
hdisk4 005b3b6c1afd5d74 oradbvg active
hdisk5 005b3b6c1afd5ec9 oradbvg active
hdisk6 005b3b6c6f087304 None
hdisk7 005cf90adc9e87bc None
hdisk13 none None
hdisk14 none None
hdisk15 005b3b6c1ab548ce orabackupvg active
hdisk16 none None
hdisk17 none None
hdisk18 005cf90aa36f00f4 None
hdisk19 005b3b6c1aa040ae oradbtestvg active
hdisk21 none None
hdisk22 none None
hdisk24 none None
hdisk25 none None
hdisk26 none None
hdisk29 none None
hdisk30 none None

VG oradbvg содержит 4 PV. вот его то мы и не восстановили. с ним были проблемы.


Посмотри сам, на протяжении всего топика еще небыло никакой информации о oradbvg
Как же результат lsvg -p для всех групп, который я просил.
Там тоже нет .

Я уже окончательно запутался что из какого сервера взято и что кому принадлежит.
Телепаты в отпуске :)
Качество ответов на вопросы напрямую зависит от качества предоставляемой информации.

kazak81

второй сервер, КОТОРЫЙ НЕОБХОДИМО ПЕРЕГРУЗИТЬ.



А это что за физ волумы ?
kazak81
bash-2.05a# lspv
hdisk1 005b3b6c6a5dfb0d None
hdisk3 005b3b6c6a5dfd45 None
hdisk5 005b3b6c6a5dff8f None
hdisk9 005b3b6ca34bc070 None
hdisk10 none None
hdisk11 none None
hdisk13 none None
hdisk14 none None
hdisk15 none None
hdisk16 none None

Если вы говорите что лишнего ничего нет , то как это все используется системой ?

второе поле это PV identifier, оно говорит о том что физ волум когдато принадлежал
или принадлежит волум группе, у вас таких 4.
подозреваю что это диски чужого сервера,
или у вас какая то группа уже проэкспортирована и в данный момент недоступна.

Прочие диски никогда небыли членами волум групп, либо они подключены с запасом под создание волум группы , либо это тома используемые другими серверами и зонинг
и выделение групп на сторадже у вас сделан не привильно.

Рекомендую остановить все приложения, проэкспортировать все волум группы
поудалять все физ волумы из системы через rmdev
затем запустить cfgmgr (все доступные физ. волумы появятся снова)
и проимпортировать волум группы.
Тогда у Вас точно не будет ничего лишнего, если зонинг и группы на сторадже созданы правильно.

До того момента пока вы не избавите систему от мусора( старых недоступных дисков) вам влядли кто то вразумительно сможет помочь в вашей ситуации и что либо гарантировать.