Interbase: убили негра

[x77]

база на филиале. дорваться до неё не могу, объём порядка 2,5 гигов, всё приходится разруливать по телефону. симптоматика следующая: медленно работает, виснет на резервировании (каждый раз в разных местах: то при записи таблиц, то индексов). проверка со включенными Check Database, Validate, ValidateFull показывает нарушений на уровне записей - 2, страниц - 11, индексов - 55.  Субд - жарптица 1.3., ОС - 2000 сервак на NTFS.

требуется её всё-таки зарезервировать. последующее восстановление, по идее, ошибки почистит само. только вот как?

[Oldy]

gfix - пробовали?
Приведите ключи у gbak

[x77]

Oldy, шутите, какой там gbak. матрёна, которая там админом, с экспертом едва справляется. а в эксперте ключи были, как я указал.

Oldy, она мне звонит как-то, и грит: я вот пароль набираю, а у меня вместо букв - звёздочки. что мне делать? с тех пор звёздочки она уже одолела, но сажать её за досовские тулзы...  хотя придётся, видимо.

gfix не пробовал. спасибо за идею, завтра проверим. что посоветуешь? -mend?

[Oldy]

x77,

матрёна, которая там админом

Они везде  .

что посоветуешь? -mend?

Как вариант на копии базы.

[x77]

видимо, да...

1. делаем копию.
2. gfix ... -two_phase
3. делаем вторую копию
3. пробуем резервирование на второй копии, если обламываемся -
4. gfix ... -mend на первой копии

план Маршалла, мля...

альтернативы могут быть?

[Oldy]

1. Делаем копию
2. gfix -v -full копии (полный список проблем)
3. gfix -mend копии
4. gfix -v -full копии
5. gbak -b -v -ig копии (подробно о backup)
и 6.gbak -b -v -ig -g если ошибки в пункте пять

Как альтернатива? :?

[x77]

смысла в валидации я не вижу, покажет то же, что и IBExpert. единственное, что - это запускаться будет с коммандной строки. ibexpert сам по себе отнюдь не безгрешен, и при выводе отчёта о быкапе 2-х с половиной гиговой базы виснуть может именно он. этого я тоже не учитывал, хотя должен был бы.

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

[Oldy]

x77,

смысла в валидации я не вижу,

Ну в общем-то да.

чем тебе двухфазное восстановление не нравится?

Почему не нравится, при наличии лимбо транзакций самое то.
Я привел как альтернативу рекомендованное здесь http://www.ibase.ru/devinfo/db_repair.htm#gfix

[x77]

Oldy, во. объясни мне толком, что такое лимбо-транзакции? не завершённые? если базу принялись архивировать, она зависла, задачу сняли, итогом будут лимбо-транзакции?

[Oldy]

x77, да, незавершенные транзакции. Могли возникнуть при "зависании" базы. (при наличии многопользовательского доступа)

[x77]

x77,  а там такое повторяется уже не первый день.

ладно, бум лечить. потом расскажу, чем дело кончилось.

спасибо

[x77]

о, сам с собой заговорил.

[Oldy]

Эт я все пытался мысли яснее выразить. Вот и помешал.

[Oldy]

x77,

x77, да, незавершенные транзакции. Могли возникнуть при "зависании" базы. (при наличии многопользовательского доступа)

Прошу прощение за неверное определение limbo

Вот верное

Limbo: Транзакция, стартовавшая в режиме 2PC (two phase commit) вызовом процедуры Prepare. Эта транзакция может быть живой или нет. В любой момент такая транзакция может возобновиться и запросить подтверждение или отмену. Изменения, произведенные транзакцией, оставшейся в состоянии in limbo не могут быть приняты или игнорированы, соответственно они не могут быть удалены из БД.

[x77]

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

[x77]

написал этой дуре:

gfix forsec.gdb -v -full -user sysdba -password masterkey > 1.txt
gfix forsec.gdb -mend -user sysdba -password masterkey > 2.txt
gfix forsec.gdb -v -full -user sysdba -password masterkey > 3.txt

у неё все три файла оказались пустыми, а на экран выдались те же сообщения об ошибках. то ли она дура, то ли для gbak'а перенаправление вывода не работает. в чём я сильно сомневаюсь. уродство

[Oldy]

x77, Не ругайтесь. GBAK действительно не перенаправляет вывод по >.
Есть опция -y [file | supress_output].

[x77]

о , чёрт. Спасибо, Oldy. ну а gfix? там таких опций нет

завтра буду опять бороться. на данный момент факт в том, что gfix -mend практически ничего не дал. кажется, остаётся попробовать gbak с игнорированием check-sum'ов, лимбо и пр.

[Oldy]

Вроде-бы опций нет. Удачи.

[x77]

ото ж.

ладно, прорвёмся. на крайняк - буду писать прогу для копирования данных в другую базу. идиотизм, конечно, но не вижу вариантов. отказать от базы - нереально, объяснить ей, как вылить данные в external tables и потом залить заново - нереально в принципе.

[Never]

Алле, народ! А что такое

Транзакция, стартовавшая в режиме 2PC (two phase commit)

этот самый режим?

[Oldy]

Never,  

Еще одна особенность транзакций IB кроме разных комбинаций параметров, это двухфазный коммит (2PC). Двухфазная транзакция IB, в отличие от других серверов, не требует дополнительного программирования, и может быть выполнена над любым количеством серверов (или баз данных), причем независимо от их платформы. Смысл двухфазного коммита состоит в том, что в отличие от обычного старта и завершения транзакции в нее вводится фаза проверки, когда ядро IB должно убедиться в том, что все сервера, участвующие в транзакции, могут ее завершить. Таким образом, если в какой-то из моментов между серверами, участвующими в двухфазной транзакции, оборвали провода, то всегда есть возможность выяснить, на каком этапе это произошло. И соответственно, произвести либо commit либо rollback после восстановления соединения.
(С) www.ibase.ru

Это и другое о 2PC транзакции, а так-же вообще о транзакциях в IB посмотрите здесь:
http://www.ibase.ru/devinfo/ibtrans.htm

[Oldy]

x77, Простите мне мой склероз (доканал он меня ). gfix свои сообщения выводит в firebird.log
(interbase.log).

[Never]

Oldy, cпасибо, это интересно.

[x77]

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

Oldy, если надо, могу скинуть. отличие от тулзов типа datapump, котороми, в принципе, тоже можно обойтись, в том, что на экран выводяться все копируемые записи. так что если что-то гнётся, видно, на какой конкретно записи это произошло.

[x77]

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

[Oldy]

никакого упоминания о работе gfix в логах я не нашёл

Чудеса да и только.  
Специально перепроверил на заведомо убитой базе - все ошибки в firebird.log
есть.  FireBird 1.5 W1-V6.3.0.4290 на WinNT4WS, NTFS.

пришлось за два часа наваять прогу, ... если надо, могу скинуть.

Если только вас это не обременит. Спасибо.

[x77]

у меня fb1.03, логи его живут в interbase.log. и там пусто. странно, действительно.

[x77]

Если только вас это не обременит. Спасибо.

Oldy, я почту за честь только отправлю чуть позже, возможно, - завтра, я там переделал кое-что, хочу причесать код и проверить всё сегодня вечером.

сдуру сделал сначала на стандартных компонентах. они кладут записи в буфер для отображения на экране, скроллинга и т.д. на тестовой пол-гиговой базе с таблицами по полтора миллиона записей тормоза получились дикие - расчётное время копирования по 15-20 часов. переделал чтение на однонаправленный режим доступа - те же таблицы стали копироваться меньше, чем за час. всё-таки насколько тормозит эта дельфя со своей буферизацией, это вилы просто. стандартный BDE-шный подход для работы с базами - это просто клиника в некоторых ситуациях: когда таблицу достаточно просто читать, без всяких db-aware контролов, на порядки быстрее делать всё руками через родное апи.