{SOS} FB DataGuard: после проверки БД теперь не онлайнится!

Обсуждение FBDataGuard, IBFirstAid, FBFirstAid, IBBackupSurgeon, IBUndelete и других инструментов IBSurgeon/iBase.ru

Модераторы: Oleg_M, kdv

Ответить
p519446
Сообщения: 5
Зарегистрирован: 27 ноя 2009, 13:40

{SOS} FB DataGuard: после проверки БД теперь не онлайнится!

Сообщение p519446 » 01 дек 2009, 02:17

hi all

FB 2.1.3, Linux.

Назначили ФБ датагарду проверку БД по расписанию (ежедневно в 23:00 - как у него в "штатном" виде записано).
Он перевёл сегодня (точнее, уже вчера) базу в оффлайн и начал проверять.
Нашёл ошибку и прислал письмо с темой "DataGuard [MALFUNCTION]: Restore test failed. (backup@[ server-0000 / db-0002 ])"
и содержанием:
Restore test failed.
Restore test ( [~/HyperFirebird/output/server-0000/db-0002/backup/backup_20091130_11-00.fbk] -> [~/HyperFirebird/output/server-0000/db-0002/backup/restore.fdb.tmp]) failed: Error in log: gbak: ERROR:invalid request BLR at offset 1642
gbak: ERROR: column END_TIME is not defined in procedure A_1302830_GET_LIST
gbak:Exiting before completion due to errors

Restore test failed;

Затем еще одно:
Error(s) during restore: null.
Error during test restore means that created backup is corrupted or backup/restore was made improperly. It requires careful attention of database administrator.

А затем вот это вот:
Job active-users@[ server-0000 / db-0002 ] malfunction
Unexpected job active-users@[ server-0000 / db-0002 ] error: Could not open JDBC Connection for transaction; nested exception is org.firebirdsql.jdbc.FBSQLException: GDS Exception. 335544345. lock conflict on no wait transaction
database /var/db/firebird/kunt_srv.fdb shutdown
Reason: lock conflict on no wait transaction
database /var/db/firebird/kunt_srv.fdb shutdown
GDS Exception. 335544345. lock conflict on no wait transaction
database /var/db/firebird/kunt_srv.fdb shutdown
Reason: lock conflict on no wait transaction
database /var/db/firebird/kunt_srv.fdb shutdown

It is something, we're not ready to, so the only advice is to bid a bead and roll up the sleeves. And don't forget your favorite tambourine!

И теперь при попытке поднять базу:
gfix -online -user SYSDBA -password myPassW0rd моя_бедная_упавшая_база.fdb
получаю:
lock conflict on no wait transaction
-database /var/db/firebird/моя_бедная_упавшая_база.fdb shutdown

Как теперь её поднять ? Чем обусловлено появление этой ошибки, ведь коннектов к ней никаких (вроде бы) быть не может, он (ФБ датагард) перевёл её предварительно в shutdown, так ведь ?

kdv
Forum Admin
Сообщения: 6575
Зарегистрирован: 25 окт 2004, 18:07
Контактная информация:

Re: {SOS} FB DataGuard: после проверки БД теперь не онлайнится!

Сообщение kdv » 01 дек 2009, 17:26

DG тут совершенно ни при чем. смотрите gstat -h состояние базы, и переведите ее в онлайн gfix-ом.

И вообще, для бэкапа базу в оффлайн переводить не надо, и ДГ этого не делает. Я вообще сомневаюсь, что ДГ умеет базу в оффлайн переводить.

Lucefer
Сообщения: 8
Зарегистрирован: 08 дек 2004, 11:34
Откуда: N56°21.36' E41°18.36'
Контактная информация:

Re: {SOS} FB DataGuard: после проверки БД теперь не онлайнится!

Сообщение Lucefer » 01 дек 2009, 18:22

А поднять в онлайн через gfix не получается?
параметры соответственно:

-shut {normal | multi | single | full}
-online {normal | multi | single | full}

Firebird 2.0 and later: New shutdown modes:
NORMAL: Database is active and online
MULTI: Only connection from SYSDBA and the Database Owner will be allowed (compatible mode with Firebird 1.0/1.5)
SINGLE: Only one SYSDBA or Database Owner connection will be allowed
FULL: Exclusive shutdown: Database is completely offline, no connections will be allowed (it is now possible to access the database file safely on a file basis, e.g. for backups)

Use -shut to "go down" the scale of shutting down and -online to "go up" that scale.

Lucefer
Сообщения: 8
Зарегистрирован: 08 дек 2004, 11:34
Откуда: N56°21.36' E41°18.36'
Контактная информация:

Re: {SOS} FB DataGuard: после проверки БД теперь не онлайнится!

Сообщение Lucefer » 01 дек 2009, 18:28

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

gfix -user SYSDBA -password masterkey dbserver:/db/mydb.fdb -online normal
>Я вообще сомневаюсь, что ДГ умеет базу в оффлайн переводить.
Датагвард умеет это делать, как раз джобом валидации базы данных.
К сожалению не могу этот джоб протестировать. Так как при попытке его запуска получаю ошибку:
Job validate-db@[ 2.1.2.18118 / RIZ ] startup failed: GDS Exception. 515. No message for code 515 found.
null
О чем создан соответствующий тикет: http://my-trac.assembla.com/DataGuard/ticket/363

Руслан сейчас что-то поправил, но я не собирал новую сборку. Да и у Олега наверняка старая версия. Так что баги возможны.

Lucefer
Сообщения: 8
Зарегистрирован: 08 дек 2004, 11:34
Откуда: N56°21.36' E41°18.36'
Контактная информация:

Re: {SOS} FB DataGuard: после проверки БД теперь не онлайнится!

Сообщение Lucefer » 01 дек 2009, 18:40

PS. В связи с ограничениями и нестыковками в кодировках символов при доступе из командной строки (ОЕМ кодировка) и из винды (анси или юникод), категорически нежелательно называть базу нелатинскими символами или допускать их присутствие в пути к базе.
-database /var/db/firebird/моя_бедная_упавшая_база.fdb shutdown

p519446
Сообщения: 5
Зарегистрирован: 27 ноя 2009, 13:40

Re: {SOS} FB DataGuard: после проверки БД теперь не онлайнится!

Сообщение p519446 » 02 дек 2009, 14:46

Тот случай, увы, повторился на следующий день: ФБ датагард снова смог перевести базу в оффлайн, но не смог её поднять :-(
Мне мои коллеги сказали, что утром след. дня линуксовый TOP показывал тучу zombie-коннектов, которые висели на ФБ.
После того, как их грохнули, база поднялась.

В общем, как я понял, простой перевод в оффлайн на ФБ 2.1.3 (Linux) недостаточен - надо после этого еще искать мертвяков и грохать их. Ранее на скл.ру я создавал топик примерно на эту же тему, hvlad мне ответил, что ФБ до версии 2.5 коннекты НЕ убивает, а "не даёт им работать" (С) -- http://sql.ru/forum/actualthread.aspx?t ... 05#7972044
В связи с этим, наш скрипт, который мы юзаем для гарантированного перевода БД в оффлайн и отсоединения юзеров содержит не только gfix -shut -force 0, но и команду убиения мертвых коннектов.
Как я понял, ФБ датагард делает ТОЛЬКО первое - просто gfix -shut -force 0.
В результате получается, что на автопилоте (в виде задания, выполняемого ежедневно) валидацию базы включать нельзя - пока это только manual-режим.

p519446
Сообщения: 5
Зарегистрирован: 27 ноя 2009, 13:40

Re: {SOS} FB DataGuard: после проверки БД теперь не онлайнится!

Сообщение p519446 » 02 дек 2009, 14:48

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

Ответить

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость