при запуске gbak застывает на start transaction
Модераторы: kdv, Alexey Kovyazin
при запуске gbak застывает на start transaction
Доброго времени суток, ув. гуру IBase.
При запуске gbak "застывает" на start transaction и не подаёт никаких признаков жизни в течении 2-ух часов. Я так понимаю, что он не может получить размер страницы файла БД. Или я ошибаюсь? В чём причина такого поведения, подскажите.
При запуске gbak "застывает" на start transaction и не подаёт никаких признаков жизни в течении 2-ух часов. Я так понимаю, что он не может получить размер страницы файла БД. Или я ошибаюсь? В чём причина такого поведения, подскажите.
Другие работают. Статистику не собирал, но вот при запуске gfix -v -f по истечению 3 мин. (БД - 1,6 Гб) выдаёт сообщение:hvlad писал(а):А другие программы работают ?
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?
Нет, сервак целиком не перегружал. После того, как он ночь провисел на строке start transaction, так и не определив размер страницы файла БД, я с утра( коннектов к БД не было ) снял задачу и перезапустил firebird по stop/start. И снова попробовал запустить gbak -b -v. На этот раз процесс стартовал успешно, но дойдя до вышеописанной таблицы снова встал как вкопанный.kdv писал(а):после "зависания" gbak сервак целиком перезагружали?
Я так понимаю, что аказия с замиранием на строке с start transaction вызвана либо каким-то сбоем в работе firebird, либо собственно самого сервера. Что более вероятно?
Ну насчёт сбойной версии записи я тоже догадывался, только вот главный вопрос, который меня тревожит: если это так, то почему gfix -v -f об этом ничего не сообщает и вдобавок gbak -b -v дойдя до этой записи тоже молчит, как рыба об лёд? Может быть собрать статистику по данной таблице, да только вот разве это поможет понять почему утилиты то молчат!?kdv писал(а):про застревание gbak без ключа -g понятно - видать какая то сбойная версия записи в базе есть, но опять же, непонятно почему он не пишет об ошибке, а "висит".
Я так понимаю, что аказия с замиранием на строке с start transaction вызвана либо каким-то сбоем в работе firebird, либо собственно самого сервера.
подозрение на сбой менеджера блокировок.
я не уверен, что он у тебя по стоп-старт рестартанул. Может быть и в ОС что-то заглючило.
вряд ли она соберется. для gstat -a -r наверняка встанет на сбойной версии, как gbak.Может быть собрать статистику по данной таблице
А если по подробней, почему именно такие подозрения (ну, я имею ввиду каие соображения тебя натолкнули на эту мыслю)? В firebird.config насколько я знаю есть множество параметров, влияющих на работу менеджера блокировок. С момента установки сервера этот файл не редактировался (т.е. все параметры - умалчиваемые). Может быть есть идеи по поводу того, что там имеет смысл поправить?kdv писал(а):подозрение на сбой менеджера блокировок.
А как же тогда гарантировать перезапуск этого менеджера?kdv писал(а):я не уверен, что он у тебя по стоп-старт рестартанул.
У меня тоже такая мысль скользнула. Я сейчас поднял журналы событий в ОС. Посмотрю там, но это долго и наверное быстро эти подозрения я не развею.kdv писал(а):Может быть и в ОС что-то заглючило.
а что еще в классике может блокировать доступ к определенным ресурсам? Правда, если там все окривело так, что даже gbak стартовать транзакцию не может, то никто тоже стартовать транзакции не сможет.А если по подробней, почему именно такие подозрения (ну, я имею ввиду каие соображения тебя натолкнули на эту мыслю)
я вообще не понял, о каком "старт-стопе" идет речь при работе с Classic.А как же тогда гарантировать перезапуск этого менеджера?
Да нет, насчёт "окривело" это ты погорячился...kdv писал(а):Правда, если там все окривело так...
[/quote]
я вообще не понял, о каком "старт-стопе" идет речь при работе с Classic.[/quote]
Вообщем я побщался с системными админами и понял, что всё совсем не так, как я себе представлял. Скрипт, который выполняется для перезапуска firebird на самом деле не убивает по маске все процессы ему принадлежащие, а всего лишь после перезапуска xined прописывает соответственно в свойстве disable нужное значение (yes, no). Т.е. перезапуском здесь и не пахнет!
Я попробовал и, о чудо, она собралась!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
И вот это прервало сборку мусора и наплодило кучу orphan pages.Naidenov писал(а):Нет, сервак целиком не перегружал. После того, как он ночь провисел на строке start transaction, так и не определив размер страницы файла БД, я с утра( коннектов к БД не было ) снял задачу и перезапустил firebird по stop/start.
Мусор собирать началNaidenov писал(а):И снова попробовал запустить gbak -b -v. На этот раз процесс стартовал успешно, но дойдя до вышеописанной таблицы снова встал как вкопанный.
Потому что нет никакой сбойной версииNaidenov писал(а):Ну насчёт сбойной версии записи я тоже догадывался, только вот главный вопрос, который меня тревожит: если это так, то почему gfix -v -f об этом ничего не сообщает
Мусор собираетNaidenov писал(а):и вдобавок gbak -b -v дойдя до этой записи тоже молчит, как рыба об лёд?
Да, gstat -r -t TABLENaidenov писал(а):Может быть собрать статистику по данной таблице, да только вот разве это поможет понять почему утилиты то молчат!?
Это была не та таблица Попробуй следующую - gbak сначала выполняет действие, а потом пишет в лог, IIRCNaidenov писал(а):Я попробовал и, о чудо, она собралась!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
Нет...Как я уже говорил, доходит до вышеозначенной таблицы и всё... поминай как звали. И сообщений об ошибке не выдаёт и в лог ничего о успешных действиях не пишет. Я его на ещё дольшее время оставлял (сутки + 11 часов), а изменений всё равно нет: упаковал 480000 записей в gbk - файл по этой таблице и "замер как вкопанный"kdv писал(а): бэкап то заработал?
Да глубина-то скорее всего тут совершенно ни причём. Просто я подумал, что возможно был повреждён один(или несколько) индексов(для этого, собственно, и получил статистику по индексам) для этой таблицы и когда gbak пытается получить по нему сведения, он входит в какой-то бесконечный цикл или ещё что-то такое происходит и поэтому этот процесс длится "вечно". А может быть причина совершенно в другом...Есть идеи?kdv писал(а):при чем тут глубина индексов....