при запуске gbak застывает на start transaction

Ремонт и восстановление баз данных InterBase, Firebird, Yaffil

Модераторы: kdv, Alexey Kovyazin

Ответить
Naidenov
Сообщения: 59
Зарегистрирован: 18 янв 2005, 17:38

при запуске gbak застывает на start transaction

Сообщение Naidenov » 15 сен 2005, 16:07

Доброго времени суток, ув. гуру IBase.
При запуске gbak "застывает" на start transaction и не подаёт никаких признаков жизни в течении 2-ух часов. Я так понимаю, что он не может получить размер страницы файла БД. Или я ошибаюсь? В чём причина такого поведения, подскажите.

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

Сообщение kdv » 15 сен 2005, 17:21

на чем застывает - на бэкапе или ресторе? какая версия сервера? операционка?

Гость

Сообщение Гость » 15 сен 2005, 18:52

kdv писал(а):на чем застывает - на бэкапе или ресторе? какая версия сервера? операционка?
застывает на бэкапе; версия сервера FB 1.5.2 классик; ОС ASP Server 4; hardware: CPU Dual Xeon 2,4, RAID1 SCSI, DDR 2 Gb.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 15 сен 2005, 21:24

А другие программы работают ?
gstat -h что говорит ?

Гость

Сообщение Гость » 16 сен 2005, 11:09

hvlad писал(а):А другие программы работают ?
Другие работают. Статистику не собирал, но вот при запуске gfix -v -f по истечению 3 мин. (БД - 1,6 Гб) выдаёт сообщение:
Numbers: 3710 error pages.
Смотрю лог по gfix - абсолютно для ВСЕХ страниц: Page "ХХХХХ" is an orphan. На сколько я знаю, ошибка - безвредная (пустые страницы).

Следовательно вопрос №1: чем объяснить такое поведение?

Далее, беру копию файла БД за предыдущий день и пытаюсь для неё сделать B/R( gbak -b -v ). Процесс бэкап стартует успешно, но не завершается, т.е. на том же сервере (сервер выделен только для обслуживания БД и ночью никакие другие процессы, кроме B/R на нём не запускаются) с 18.00 до 8.00 дойдя до центральной таблицы в системе бэкап замирает: в лог пишет writing data for table "ХХХХ" "ХХХХ" records written и всё. Причём до этой строчки процесс доходит практически моментально, а далее - никаких признаков жизни. Таблица содержит 60 полей, большая часть из которых имеет тип NUMERIC(16,2) (что-то вроде глобальной таблицы-связки), 27 индексов и 1 000 000 записей. gbak с вышеуказанными ключами замирает,после того, как уже упаковал в gbk - файл 500 000 записей из этой таблицы. Снимаю задачу и перезапускаю gbak для этого же файла, но уже с ключами gbak -b -v -g. Всё отлично и полный цикл ( вместе с рестор ) выполняется за 11 мин. После чего размер файла БД уменьшается с 1,6 Гб до 1,1 ГБ. Общаюсь с пользователями и разработчиками, они говорят, что в течении недели никаких "массовых" изменений (одновременное удаление/вставка.изменение большого кол-ва записей не было) над этой таблицей не производится, т.е. версии записей не должны расти как на дрожжах. До этого случая процесс B/R выполнялся каждый день с последующей подменой файла БД по схеме: gbak -b -v => gbak -c -v. Т.е. накопление мусора не должно было быть.

Следовательно вопрос №2: как объяснить такую работу gbak?

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

Сообщение kdv » 16 сен 2005, 11:31

после "зависания" gbak сервак целиком перезагружали?
подозрительная у тебя ситуация. как бы не глюки железа.

про застревание gbak без ключа -g понятно - видать какая то сбойная версия записи в базе есть, но опять же, непонятно почему он не пишет об ошибке, а "висит".

Naidenov
Сообщения: 59
Зарегистрирован: 18 янв 2005, 17:38

Сообщение Naidenov » 16 сен 2005, 12:03

kdv писал(а):после "зависания" gbak сервак целиком перезагружали?
Нет, сервак целиком не перегружал. После того, как он ночь провисел на строке start transaction, так и не определив размер страницы файла БД, я с утра( коннектов к БД не было ) снял задачу и перезапустил firebird по stop/start. И снова попробовал запустить gbak -b -v. На этот раз процесс стартовал успешно, но дойдя до вышеописанной таблицы снова встал как вкопанный.

Я так понимаю, что аказия с замиранием на строке с start transaction вызвана либо каким-то сбоем в работе firebird, либо собственно самого сервера. Что более вероятно?
kdv писал(а):про застревание gbak без ключа -g понятно - видать какая то сбойная версия записи в базе есть, но опять же, непонятно почему он не пишет об ошибке, а "висит".
Ну насчёт сбойной версии записи я тоже догадывался, только вот главный вопрос, который меня тревожит: если это так, то почему gfix -v -f об этом ничего не сообщает и вдобавок gbak -b -v дойдя до этой записи тоже молчит, как рыба об лёд? Может быть собрать статистику по данной таблице, да только вот разве это поможет понять почему утилиты то молчат!?

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

Сообщение kdv » 16 сен 2005, 12:24

Я так понимаю, что аказия с замиранием на строке с start transaction вызвана либо каким-то сбоем в работе firebird, либо собственно самого сервера.

подозрение на сбой менеджера блокировок.
я не уверен, что он у тебя по стоп-старт рестартанул. Может быть и в ОС что-то заглючило.
Может быть собрать статистику по данной таблице
вряд ли она соберется. для gstat -a -r наверняка встанет на сбойной версии, как gbak.

Naidenov
Сообщения: 59
Зарегистрирован: 18 янв 2005, 17:38

Сообщение Naidenov » 16 сен 2005, 12:48

kdv писал(а):подозрение на сбой менеджера блокировок.
А если по подробней, почему именно такие подозрения (ну, я имею ввиду каие соображения тебя натолкнули на эту мыслю)? В firebird.config насколько я знаю есть множество параметров, влияющих на работу менеджера блокировок. С момента установки сервера этот файл не редактировался (т.е. все параметры - умалчиваемые). Может быть есть идеи по поводу того, что там имеет смысл поправить?
kdv писал(а):я не уверен, что он у тебя по стоп-старт рестартанул.
А как же тогда гарантировать перезапуск этого менеджера?
kdv писал(а):Может быть и в ОС что-то заглючило.
У меня тоже такая мысль скользнула. Я сейчас поднял журналы событий в ОС. Посмотрю там, но это долго и наверное быстро эти подозрения я не развею.

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

Сообщение kdv » 16 сен 2005, 14:10

А если по подробней, почему именно такие подозрения (ну, я имею ввиду каие соображения тебя натолкнули на эту мыслю)
а что еще в классике может блокировать доступ к определенным ресурсам? Правда, если там все окривело так, что даже gbak стартовать транзакцию не может, то никто тоже стартовать транзакции не сможет.
А как же тогда гарантировать перезапуск этого менеджера?
я вообще не понял, о каком "старт-стопе" идет речь при работе с Classic.

Гость

Сообщение Гость » 16 сен 2005, 15:29

kdv писал(а):Правда, если там все окривело так...
Да нет, насчёт "окривело" это ты погорячился...
[/quote]
я вообще не понял, о каком "старт-стопе" идет речь при работе с Classic.[/quote]
Вообщем я побщался с системными админами и понял, что всё совсем не так, как я себе представлял. Скрипт, который выполняется для перезапуска firebird на самом деле не убивает по маске все процессы ему принадлежащие, а всего лишь после перезапуска xined прописывает соответственно в свойстве disable нужное значение (yes, no). Т.е. перезапуском здесь и не пахнет!

Naidenov
Сообщения: 59
Зарегистрирован: 18 янв 2005, 17:38

Сообщение Naidenov » 16 сен 2005, 15:38

kdv писал(а):вряд ли она соберется. для gstat -a -r наверняка встанет на сбойной версии, как gbak.
Я попробовал и, о чудо, она собралась!

Primary pointer page: 1324, Index root page: 1325
Average record length: 161.55, total records: 918498
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 10156, data page slots: 10156, average fill: 99%

Как тогда можно объяснить вышеописанное поведение gbak?

P.S. глубина всех индексов для данной таблицы = 2

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 16 сен 2005, 15:56

Naidenov писал(а):Нет, сервак целиком не перегружал. После того, как он ночь провисел на строке start transaction, так и не определив размер страницы файла БД, я с утра( коннектов к БД не было ) снял задачу и перезапустил firebird по stop/start.
И вот это прервало сборку мусора и наплодило кучу orphan pages.
Naidenov писал(а):И снова попробовал запустить gbak -b -v. На этот раз процесс стартовал успешно, но дойдя до вышеописанной таблицы снова встал как вкопанный.
Мусор собирать начал
Naidenov писал(а):Ну насчёт сбойной версии записи я тоже догадывался, только вот главный вопрос, который меня тревожит: если это так, то почему gfix -v -f об этом ничего не сообщает
Потому что нет никакой сбойной версии
Naidenov писал(а):и вдобавок gbak -b -v дойдя до этой записи тоже молчит, как рыба об лёд?
Мусор собирает
Naidenov писал(а):Может быть собрать статистику по данной таблице, да только вот разве это поможет понять почему утилиты то молчат!?
Да, gstat -r -t TABLE

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 16 сен 2005, 16:03

Naidenov писал(а):
kdv писал(а):вряд ли она соберется. для gstat -a -r наверняка встанет на сбойной версии, как gbak.
Я попробовал и, о чудо, она собралась!

Primary pointer page: 1324, Index root page: 1325
Average record length: 161.55, total records: 918498
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 10156, data page slots: 10156, average fill: 99%

Как тогда можно объяснить вышеописанное поведение gbak?

P.S. глубина всех индексов для данной таблицы = 2
Это была не та таблица ;) Попробуй следующую - gbak сначала выполняет действие, а потом пишет в лог, IIRC

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

Сообщение kdv » 19 сен 2005, 10:45

при чем тут глубина индексов.... бэкап то заработал?

Naidenov
Сообщения: 59
Зарегистрирован: 18 янв 2005, 17:38

Сообщение Naidenov » 19 сен 2005, 13:40

kdv писал(а): бэкап то заработал?
Нет...Как я уже говорил, доходит до вышеозначенной таблицы и всё... поминай как звали. И сообщений об ошибке не выдаёт и в лог ничего о успешных действиях не пишет. Я его на ещё дольшее время оставлял (сутки + 11 часов), а изменений всё равно нет: упаковал 480000 записей в gbk - файл по этой таблице и "замер как вкопанный"
kdv писал(а):при чем тут глубина индексов....
Да глубина-то скорее всего тут совершенно ни причём. Просто я подумал, что возможно был повреждён один(или несколько) индексов(для этого, собственно, и получил статистику по индексам) для этой таблицы и когда gbak пытается получить по нему сведения, он входит в какой-то бесконечный цикл или ещё что-то такое происходит и поэтому этот процесс длится "вечно". А может быть причина совершенно в другом...Есть идеи?

Ответить