proNovell

Ничего не понимаю. При прогоне DSREPAIR на консоли сервера (Unuttended full repair) почему-то каждый раз работа заканчивается сообщением

Код: Выделить всё

Temporary DIB set replacing NDS working DIB set.
ERROR: Operation or update failed with Error: -807

WARNING: The current dib set name is set to: NDT
NOTICE: Successfully set current dib set to: NDS

Repair process aborted

Примерно то же самое происходит при попытке сделать в DSREPAIR "Repair local DS database" с включенной опцией "Use temporary NDS database during repair?" - вроде бы проходит успешно, но потом задаётся вопрос о желании сохранить результат, так при выборе "Yes, save the repaired database" появляется вот это:

Код: Выделить всё

ERROR: Unable to rename DIB from NDT to NDS. Error: -807

Program execution cannot continue normally.

    - Press ESCAPE To Continue -

Причём это проявляется на двух серверах сразу (на обоих - реплики RW), на третьем (с Master-репликой) всё в порядке. Ещё наблюдение: при работе через NDS Manager с рабочей станции (Partition continuity -> Repair local database) вроде бы всё проходит без ошибок.

Все сервера - NetWare 5.1sp7, кроме одного (с RW-репликой) - там sp8, везде NDS8 (8.82, на том, который с SP8 - 8.85c).

Единственное, что нашёл на http://support.novell.com по этому коду ошибки - это TID10061374, где говорится про нехватку места; но это явно не мой случай - на всех серверах на томе SYS: имеется, по крайней мере, по паре Гиг свободного пространства. Вот и думаю - во-первых, с чего бы это, а во-вторых - мне нужно на ещё один новый сервер (NW5.1sp8, DS 8.85c) реплику положить, сомневаюсь - можно ли - или сначала с этим разобраться...

Во-первых, проверь в статистике тома SYS нет ли после purge all and subdirectories не пропурженных данных (типа не пуржится _netware)
Во-вторых, таки стоит поставить SP8 (и 8.85с соответсвенно)
В-третьих, у тебя база может быть занята каким-нибудь пользователем или процессом. Сделай unload ds, а потом запускай dsrepair...

Я б еще посмотрел на атрибуты и перенес в др место dib.
dsrepair -rc как?

Владимиру:
DSREPAIR -RC проходит успешно, создаёт файл SYS:SYSTEM\DSR_DIB\00000000.$DU размером 14 Мегабайт. При повторном прогоне - так же успешно его обновляет.

Павлу:
3) я пробовал перегружать DS.NLM (unload, затем load, затем снова DSREPAIR) - не помогает. Запускать DSREPAIR прямо с выгруженным DS, честно говоря, не пробовал.
2) я понимаю, что саппорт-пак лучше накатить, просто сервер-то будет выводиться из эксплуатации (новый с SP8, о котором я упоминал - как раз ему на замену). Да и беспроблемный (пока ещё? - тьфу, тьфу!) сервер с мастер-репликой - тоже с SP7 & NDS 8.82, в то время как один из проблемных - с SP8 & NDS 8.85c, т.е. складывается впечатление, что дело не в этом.
1) дело осложняется тем, что сервера в клуглосуточной работе, трудно остановить для профилактических работ. Вот в субботу останусь - попробую повозиться с этим делом: прогоню VREPAIR на том SYS: с пуржем всех удалённых файлов, накачу саппорт-паки...

Ещё наблюдение: в принципе, Repair local DS database через Advanced Options menu проходит успешно, если параметр Use temporary NDS database during repair? оставлять в NO. Однако, после этого Unuttended full repair всё равно вылетает с ошибкой - правда, уже с другой:

Код: Выделить всё

** Automated Repair Mode **
Repairing Local Database
Start:  Wednesday, July 5, 2006  11:09:54 am Local Time

Structure and Index Check
ERROR: Operation or update failed with Error: -168

Repair process aborted

** Automated Repair Mode **
Finish:  Wednesday, July 5, 2006  11:10:21 am Local Time
Total repair time: 0:00:26

Народ, как вы думаете - помещать реплики на новый сервер (NW5.1sp8, NDS 8.85c) в такой ситуации можно или лучше сначала с этим разобраться? В принципе, мне всё равно нужно будет с одного из "проблемных" серверов реплики переносить на новый; просто не очень ясно, в какой последовательности это делать.

помнится была утилитка purge_nw, может попробовать?

Владимир Горяев писал(а):помнится была утилитка purge_nw, может попробовать?

Это, вроде, был батник с оптимизированными SET-параметрами.

Иван Левшин aka Ivan L. писал(а):

Владимир Горяев писал(а):помнится была утилитка purge_nw, может попробовать?

Это, вроде, был батник с оптимизированными SET-параметрами.

Неа. Оне проверяло атрибуты всякие и очищало _NETWARE.

так как она будет генериться с мастер-реплики, а у тея с ней все в порядке.
А SP все-же стоить накатить.
Если dsrepair без создания временной копии проходит нормально, то с самой NDS все в порядке. Я все же подозреваю, что ее кто-то держит. В этом случае unload ds помогает.

Сегодня первые проблемы начали проявляться уже наглядно: на одной из проблемных реплик запортились объекты Profile, в которых хранились назначенные пользователям логин-скрипты (в NetWare Administrator-е стали отображаться жёлтым кружком со знаком вопроса, у пользователей, соответственно, диски не мапились). При этом на двух других серверах - всё в порядке.

Владимир Горяев писал(а):

Иван Левшин aka Ivan L. писал(а):

Владимир Горяев писал(а):помнится была утилитка purge_nw, может попробовать?

Это, вроде, был батник с оптимизированными SET-параметрами.

Неа. Оне проверяло атрибуты всякие и очищало _NETWARE.

Спасибо, частично помогло. Т.е. что-то оно таки подчистило:

Loading module PURGE_NW.NLM
Netware File System API unit tests (Build 24 SP)
Version 3.20 June 23, 2003
Copyright 1987-2003 Novell, Inc. All Rights Reserved.


Welcome to PURGE_NW. This utility fixes the file attributes for SYS:_NETWARE
and purges any deleted files contained by it.
-----------------------------------------------------------------------------

File Attributes for SYS:_NETWARE are incorrect.
The attributes are currently = 0x00000010
Modifying the attributes to be = 0x00010016
File Attributes for SYS:_NETWARE were correctly modified

Purging all deleted files from SYS:_NETWARE
339 file(s) purged from SYS:_NETWARE

Легче, правда, пока что стало ненамного (Unuttended full repair всё равно ошибку выдаёт, правда, теперь уже с кодом -168 - столь же информативным, что и изначальный -807), но, по крайней мере, хоть с логин-скриптами, кажется, устаканилось.

Меня всё подмывает просто удалить проблемную реплику со старого сервера и поместить вместо неё на новый (тем более, что на сервере с мастер-репликой всё ОК). Однако, поскольку до сих пор не понимаю причин этой ситуации, то опасаюсь делать лишние телодвижения, чтобы не усугубить положение. Может ли кто-нибудь посоветовать - можно это делать сейчас или нет?

Константин Ошмян писал(а):Ничего не понимаю. При прогоне DSREPAIR на консоли сервера (Unuttended full repair) почему-то каждый раз работа заканчивается сообщением

Код: Выделить всё

Temporary DIB set replacing NDS working DIB set.
ERROR: Operation or update failed with Error: -807

WARNING: The current dib set name is set to: NDT
NOTICE: Successfully set current dib set to: NDS

Repair process aborted

У меня была ситуация один в один, на двух RW серверах одновременно. Мастер работал нормально, правда в то время у меня был еще NW5.1 SP6.
Вылечил сносом всех RW реплик, после этого на всех серверах прогнал dsrepair. Через часок все вернул назад - проблема ушла.

Всем спасибо, особенно - Владимиру Горяеву и Павлу Гарбару! Проблема решена. Отчитываюсь о проделанной работе.

1. В субботу накатил-таки последний (т.е. восьмой) саппорт-пак и постфиксы (slp213, tcp587i, tsa5up19) на все критичные серверы. Версия NDS на всех серверах с репликами, а также новом сервере (пока ещё без реплик) стала 8.85c. Серверы при этом, естественно, перегружались; однако после перезагрузки проблема не исчезла - DSREPAIR продолжал вести себя как и раньше.

2. Добавил реплики на новый сервер (прошло успешно), через некоторое время убрал реплики с одного из "проблемных" серверов, который будет выводиться из эксплуатации. Делал это через ndsmgr32, он показал, что всё в порядке - по крайней мере, Partition Continuinity и Synchronization были в норме. После этого DSREPAIR на всех трёх серверах с репликами (пропатченный сервер с мастер-репликой, новый сервер и один из прежних серверов, на котором ошибка была, несмотря на наличие последнего саппорт-пака) стал проходить успешно. Ура! Т.е. похоже, что какой-то сбой был всё-таки именно на том сервере, который нужно было вывести из эксплуатации - как с него сняли реплику, так на всех остальных серверах стало хорошо.

3. ...а вот ещё и не конец истории. Снова начались проблемы с логин-скриптами на рабочих станциях, у которых в клиенте в качестве Preferred Server был указан "старый" сервер. При ближайшем рассмотрении оказалось, что он по-прежнему считает, что на нём лежат все реплики! Т.е. запущенный на нём DSREPAIR в Advanced Options в разделе Replica and partition operations отображал обе реплики, при просмотре Replica ring для каждой из них показывал три сервера (включая себя, но не включая новый сервер), в отношении Repair local DS database либо Unattended full repair вёл себя тоже по-прежнему. Т.е. запорченные объекты с логин-скриптами располагались именно на этом сервере, и он, ничтоже сумняшеся, раздавал это добро рабочим станциям - несмотря на то, что все остальные серверы уже давно договорились о том, что данный сервер в кольце реплик отсутствует!

4. Попробовал удалить с этого сервера реплики через DSREPAIR -a -> Advanced options menu -> Replica and partition operations -> реплика -> Destroy the selected replica on this server. Что любопытно: одна реплика (корневая) удалилась, другая (того контейнера, где "жил" сам сервер) - осталась, но сменила тип на Subordinate Reference. Но, что характерно, DSREPAIR корректно работать так и не начал! Т.е. при попытке сделать Unattended full repair он всё равно пытался что-то репэйрить (на его экране пробегал список всех объектов дерева), после чего выдавал те же самые ошибки!

5. Кардинально проблема с этим сервером решилась только путём выноса его из дерева вообще (NWCONFIG -> Directory Options -> Remove Directory Services from this server), перезагрузки (после этого DSREPAIR, наконец, заработал как ожидается) и установки обратно в дерево (тем же путём, Install Directory Services onto this server). По пути, правда, потерял права на файловую систему (я не понял в какой момент - наверное, уже после повторного ввода в дерево: он там что-то очень долго проверял на томе) - я этого не ожидал, ну да и ладно (что нужно, у меня было сохранено утилитой TRUSTEE.NLM).

6. Так и осталось неясным, отчего такая проблема возникла. Проблем с оборудованием (диски, RAID-контроллер, электропитание и т.п.) не было, VREPAIR тома SYS тоже ничего не нашёл. Было, правда, однажды зависание этого сервера (с выключением "кнопкой"), но это было давно (более года назад).

Ну вот, кто дослушал - молодец

P.S. Кстати, а как закрыть тему - несмотря на то, что я её автор, кнопки "закрыть" не вижу.

Костя, привет! Это реально сервер плющился! Я такое проходил - в NDS Manager'e реплики удаляешь, а на сервере она продолжает как-то жить и всем мешает... Удаляется она через dsrepair с проблемного сервера...
На всякий случай предлагаю проверить с помощью dsrepair на каждом сервере какие он видит реплики - будут "лишние" - удалять безжалостно!

Павел Гарбар писал(а):Костя, привет! Это реально сервер плющился! Я такое проходил - в NDS Manager'e реплики удаляешь, а на сервере она продолжает как-то жить и всем мешает... Удаляется она через dsrepair с проблемного сервера...
На всякий случай предлагаю проверить с помощью dsrepair на каждом сервере какие он видит реплики - будут "лишние" - удалять безжалостно!

Привет, Павел!
Спасибо за моральную поддержку

Ну, остальные серверы я проверил первым делом - тьфу, тьфу, на них всё нормально показывает. Реально проблемным только один оказался; то, что на нём "залипшие" реплики остались, я обнаружил уже после того, как проверил все остальные серверы. Странно, что DSREPAIR на этом проблемном сервере так и не смог ничего исправить (вернее, это я не смог исправить с его помощью, хотя и пытался - см. предыдущее описание ).

В итоге, поскольку были живые-здоровые реплики на других серверах, я с этим сервером решил проблему кардинальным образом: снёс с него NDS вообще, выведя из дерева. Это помогло - после обратного ввода в дерево проблем больше нет; единственный побочный эффект, как я говорил - удаление прав с файловой системы (я этого просто не ожидал), но в моей конкретной ситуации это не страшно, т.к. сервер всё равно выводился из эксплуатации и я в любом случае собирался отбирать все права на него, чтобы никто случайно на него не забрёл вместо нового сервера.