По для ремонта firebird

DataExpress

Конструктор приложений баз данных

• Темы пользователя
  • >в конференции
  • >>в форуме

• Сообщения пользователя
  • >в конференции
  • >>в форуме
  • >>>в теме

Полезное: Редакторы баз данных Firebird

Полезное: Редакторы баз данных Firebird

Сообщение vovka3003 » 09 июн 2016, 22:08

Парочка GUI-оболочек для разработки и администрирования баз данных InterBase и Firebird. Обе «Freeware».

1. Рецепт от SoftAce: IBExpert

2. Нарыл случайно, протестировал — показалась даже несколько «дружелюбнее» чем IBExpert: Database Browser Portable

Описание и инструкции (источник: google )
IBExpert, Database Browser Portable

Re: Полезное: Редакторы баз данных Firebird

Сообщение Пользователь » 10 июл 2016, 01:26

DBeaver — бесплатный универсальный кроссплатформенный SQL клиент

Сообщение Frost » 08 май 2018, 13:35

О DBeaver кратко: много возможностей, небольшой вес, портабельность, свободное ПО.

Из основных особенностей прграммы можно выделить:

Удобный структурированный интерфейс, основан на OpenSource фреймворке c большой подборкой мощных плагинов;
Небольшой вес — 50Мб;
Свободное программное обеспечение;
Мультиплатформенность (работает под Linux, MacOS, Windows, Solaris, AIX, HPUX);
Поддержка большого количества разных Баз Данных;
Умеет делать тунеллирование через SSH (встроенный функционал, очень удобно);

Список поддерживаемых баз данных:

MySQL, Oracle, PostgreSQL, IBM DB2, Microsoft SQL Server, Sybase, ODBC, Java DB (Derby), Firebird (Interbase) , HSQLDB, SQLite, Mimer, H2, IBM Informix, SAP MAX DB, Cache, Ingres, Linter, Teradata, Vertica, MongoDB, Cassandra, Любой JDBC совместимый источник

Небольшой список того что умеет DBeaver:

Обзор и правка метаданных: таблички, колонки, ключи, индексы
Выполнение SQL запросов и скриптов
Подсветка синтаксиса для SQL (специфичная для разных типов БД)
Функция авто-дополнения в SQL редакторе
Просмотр и редактирование данных в таблицах
Поддержка BLOB/CLOB (просмотр и редактирование)
Экспорт данных (таблици, результаты запросов)
Менеджмент транзакций
Поиск объектов в базе данных (таблици, колонки, процедуры и т.п.)
Генерация диаграмм для структур БД
Закладки для запросов и объектов в БД
Менеджмент удаленных и локальных подключений
Экспорт и Импорт в/из БД/файл
Поиск данных в базе
И многие другие возможности.

Оф. сайт: https://dbeaver.io

Личный опыт:

Для подключения к файлу базы данных (программой DBeaver) мне потребовалось установить FireBird сервер;
При настройке подключения использовал данные по умолчанию логин: SYSDBA и пароль masterkey ;
Для отображения кирилицы вместо кракозябр в полях данных таблиц использовал запуск программы с ключом -vmargs -Dfile.encoding=UTF8 . Прописывается в ярлыке программы. (Спасибо selfexile с форума xbit, где в своем топике он дает ответ на свой же вопрос. Почему может происходить подобная ситуация с программами на JAVA можно прочесть в статье на хабре.
При запуске с выше упомянутым ключом, программа не открывает базу с кирилицей в полном имени (пути к файлу), поэтому файл размещаем в папка с латинским наименованием.

Благодаря Edward Grech я узнал, что в документации JVM ™ Tool Interface написано примерно следующее:

IBExpert. Официальная бесплатная версия.

Сообщение Frost » 19 май 2018, 10:48

Не скачивайте IBExpert ни с каких других ресурсов! Не ведитесь на якобы кряки и патчи! IBExpert и так бесплатен, пользуйтесь только официальными ссылками!

1. Ссылка для скачивания с официального сайта: http://www.ibexpert.net/downloadcenter.

Перейдя по ссылке видим форму (Fig_1.png). Нажимаем [Register]. Открывается форма для заполнения (Fig_2.png). Заполняем поля:
Email, Name, Zip+City+State, Country.

Источник

Восстановление поврежденной базы данных Interbase или Firebird

Войдите в каталог Bin в папке, куда был установлен сервер Interbase/Firebird/Yaffil. Для того, чтобы не работать с «голым» окном командной строки, рекомендуется использовать любую файловую утилиту вроде Far или Total Commander.

Проверим базу данных на наличие повреждений:

вместо gdbase.gdb укажите полный путь к своему файлу базы данных (хорошая идея: для того чтобы не обременять себя вводом длинного пути, скопировать файл базы данных непосредственно в каталог BIN). Имя сервера указывать не надо!

Если утилита отработала и не выдала ничего на экран, то с базой все нормально.

Если есть повреждения, то попытаемся исправить их:

Проверим, исправились ли все повреждения:

Если повреждения остались, то запишем информацию в Bak-файл, а потом восстановим в другой новой базе данных. Для этого последовательно выполним команды:

Здесь применены следующие ключи:

• -b — создавать архивную копию базы;
• -v — выводить на экран подробный лог;
• -ig — игнорировать ошибки в данных;
• -g — запретить сборку мусора при чтении из базы.

Обратите внимание, что при указании имени базы данных необходимо указать имя сервера и через двоеточие полный путь к файлу базы данных на сервере (обратите внимание, что если вы даже скопировали файл базы данных в одну папку с утилитой резервного копирования все равно необходимо указать полный путь к файлу). При указании имени архива следует указать только полный путь к файлу без указания имени сервера.

При серьезных повреждениях базы данных в некоторых таблицах могут пропасть записи из-за чего не восстановятся внешние ссылки на эти таблицы. Или наоборот, появятся «фантомные» записи, нарушающие условия уникальности первичного ключа. В таких случаях на стадии восстановления базы данных из архива на экране будут отображены сообщения об ошибках и процесс восстановления прервется.

Спасти базу можно следующим образом: сначала восстановить ее без внешних ссылок (индексов) с помощью команды:

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

Если база повреждена настолько, что одной деактивации индексов недостаточно, то можно попробовать ключи -n (отключение проверок целостности данных) и -o (комит данных после каждой таблицы при восстановлении).

Пример команды с вышеупомянутыми ключами:

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

Источник

Восстановление поврежденной базы данных Firebird

В одной из программ (Суперокна), работающих на СУБД FireBird стала возникать ошибка: BLOB NOT FOUND. Тестирование и исправление встроенными средствами программы результата не дало. Пришлось воспользоваться утилитами Firebird gfix.exe (проверка и исправление ошибок) и gbak.exe (создание и восстановление из резервной копии).

Как восстановить поврежденную БД Firebird

1. Выключаем сервер Firebird. Для этого останавливаем службу Firebird Server
2. Копируем нужный файл базы данных. Лучше временно скопировать файл в папку с установленным Firebird. В моем случае это была папка C:\Program Files\Firebird\Bin
3. Включаем сервер Firebird
4. Запускаем командную строку с правами администратора. и переходим в папку с установленным Firebird (при помощи команды cd Имя папки)

Проверяем базу данных на повреждения
gfix.exe -v -full -user sysdba -password masterkey base.fdb

В параметре -user указываем имя пользователя БД , а в параметре –password пароль пользователя. Эти параметры нужно указывать для всех команд по восстановлению БД

Если в отчете есть ошибки, то исправляем их командой
gfix.exe –mend -user sysdba -password masterkey base.fdb

Повторно проверяем на повреждения базу данных
gfix.exe -v -full -user sysdba -password masterkey base.fdb

Если ошибки сохранились то делаем резервную копию БД
gbak -b -v -ig -g -user sysdba -password masterkey base.fdb backup.fbk

base.fdb – поврежденный файл базы данных
backup.fbk – файл резервной копии

-ig – ошибки контрольных сумм будут игнорироваться
-g – запрет сборки мусора во время резервирования

Восстанавливаем базу данных из резервной копии
gbak -c -v -user sysdba -password masterkey backup.fbk newbase.fdb

Проверяем новую базу на ошибки

После проделанных операций удалось восстановить работу базы данных Firebird и избавиться от ошибки BLOB NOT FOUND.

Источник

Причины повреждений баз данных. Как починить базу данных InterBase или Firebird?

KDV, 03.09.2002, исправления и дополнения – 25.01.2003, 06.02.2003, 15.04.2003, 16.05.2003, 02.09.2003, 26.11.2003, 03.02.2004, 06.09.2004, 17.02.2005, 05.07.2007 11.10.2007, 2015.10.11.

Если Вам нужно действительно починить БД Firebird

Самый быстрый и надежный способ починить серъезно поврежденную БД относительно небольшого размера (до 65Гб) – это использовать инструмент IBSurgeon FirstAID, который может починить практически все повреждения БД и спасти оставшиеся данные.

Загрузить FirstAID

Содержание

Первый закон Чизхолма: Все, что может испортиться, портится.
Следствие: Все, что не может испортиться, портится тоже.

Введение

На эту тему можно было бы процитировать половину законов Мэрфи. Вместо этого я процитирую начало статьи в журнале Intelligent Enterprise

Установлено, что большинство предприятий, переживших крупную необратимую потерю корпоративных данных, прекращают свое существование в течение трех лет после такого инцидента. Мысль о возможной катастрофе неприятна для ИТ- и бизнес-менеджеров, поэтому они часто не принимают серьезных предупредительных мер.

Когда я читал эту статью, меня больше всего потрясло именно второе предложение в этом абзаце. К сожалению, это грубая правда жизни. И здесь под «предупредительными мерами» ни в коем случае нельзя понимать «покупку техники brand-name». Как показала дискуссия в конференции epsylon.public.interbase, «брэнды» тоже ломаются, иногда даже чаще чем «самосборные машины». Поэтому «предупредительные меры» – это не только качественное «железо», но и планирование резервного копирования данных.

Планирование-планированием, но вот еще одна цитата, уже из письма:

«. днем сдох IBM-ер у моих «ну очень уважаемых клиентов», а вместе с ним и БД акционерок и акционеров, с общим объемом уставных фондов около полуярда гривень (около 100 млн вечно-зеленых гульденов). Резервация ее делалась на RW-диск, отформатированный под UDF. Но кто-то (никто не признался) вставил вместо него неотформатированную RW. И так она пролежала там на протяжении последнего месяца. Как раз в октябре/ноябре у них шел сплошной поток обновлений в БД. «

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

>1Гб базу (имеется в виду размер архива zip или rar, конечно) данных специалистам по email или на ftp. И нужно знать, что бывают случаи, когда базу данных восстановить не удастся никаким образом. Поэтому никогда не забывайте своевременно делать backup, а также проводить «контрольный» restore! (Разумеется, никогда нельзя делать restore на место оригинальной базы данных, т. е. с ключом -r. Вы рискуете остаться без базы данных).

Для ознакомления – перечень наиболее частых ситуаций, для которых компания iBase осуществляет платный ремонт БД. (Это не означает, что можно починить все – недавно базу со сбоем N2 починить не смогли, т. к. оказались затертыми не только половина данных, но и информация в системных таблицах о структуре записей). Если gfix не чинит базу данных, то в 70% случаев простых повреждений может помочь утилита IBSurgeon FirstAid. Для оценки повреждений БД имеет смысл сначала проверить БД с помощью бесплатного режима (с возможностью предпросмотра данных) FirstAID и прислать лог (в zip) на support@ibase.ru, т. к. может оказаться, что ваш случай попадает в худшие 30%. В любом случае не стоит надеяться на появление инструмента, который из любой самой убитой базы данных сможет вытащить ваши данные.

Если база убита, а есть только backup, и он тоже поврежден, или по иным причинам нужно извлечь из backup только часть данных – к вашим услугам инструмент IBBackupSurgeon. (FirstAid и IBBackupSurgeon – платные. Их можно купить).

Повреждения базы данных

Отключение питания сервера

Самый частый случай повреждения базы данных это отключение питания на сервере. Такие ситуации нужно пытаться предотвращать, используя аппаратные средства (UPS, RAID-контроллеры с батарейками). InterBase имеет два режима записи страниц – синхронный и асинхронный. Для всех версий до 6.0 создаваемые базы данных имели по умолчанию синхронный режим (Firebird v1.0 также имеет этот режим включенным по умолчанию). Для изменения режима можно воспользоваться утилитой gfix.

Включение синхронного режима:

Дефекты оборудования

Память

Диски

Контроллеры

Другие программы

Сбои самого сервера

Разумеется, InterBase (Firebird, Yaffil) как и любое другое ПО не является идеальной программой. Идеальной, конечно, в смысле отсутствия ошибок. Если «железо» работает нормально, сервер может сам «сломаться» и либо просто перестать работать, либо испортить базу данных. Конкретный случай последних 1.5-2-х лет – превышение размера в 4 гигабайта файлом базы данных при использовании старых версий InterBase (или ранних версий Firebird на определенных платформах). Раньше, и в том числе в 5.x (1997-2000 годы), код сервера содержал вызов обычной функции позиционирования по файлу БД (seek), которая не могла адресовать более 4-гигабайт (в те далекие времена просто не было файловых систем, которые поддерживали файлы больше 4-х гигабайт). Когда в функцию передавалось такое большое число, оно обрезалось по старшим разрядам. Происходила такая ситуация при операции расширения файла БД, т. е. при записи новых страниц, а следовательно файл БД оказывался «затертым» новой информации с самого начала, т. е. с нулевой страницы (страница заголовка БД). Если новых страниц к записи было много, то уничтожалась начальная часть БД, где как правило содержатся системные таблицы, страницы информации о транзакциях и т. п. Причем борьба с пресловутым размером файла в 4 гигабайта дольше всего велась на Linux, что связано не только с кодом СУБД, но и с поддержкой файлов таких размеров самой операционной системой и ее файловыми системами. Firebird исправил эту проблему окончательно только в версии 1.0.2, причем 1.0.2 выпускался как в старом варианте, так и с 64bit-IO. Borland также не миновала чаша сия, и для IB 7 выпущен патч (7.0.1), который исправлял проблему с размером файла для Linux. Firebird для FreeBSD поддерживает файлы более 4 гигабайт начиная с версии 1.5.

На Windows в IB7, Firebird и Yaffil этой проблемы уже нет, т. е. файл БД может иметь размер и 10, и 20 и больше гигабайт.

В любом случае, при работе на Unix или Windows следует внимательно изучить возможности ядра и конкретной (используемой) файловой системы – способны ли они работать с файлами больше 4-х гигабайт, а также проверить версию IB/FB/YA, чтобы быть уверенным в корректной работе с такими файлами, или наоборот, сразу предусмотреть разбиение БД на многофайловую, например, «кусками» по 2-3 гигабайта.

В отношении файловых систем Windows известна следующая особенность: на FAT32 поддерживаются файлы размером не более 4 гигабайт (чаще всего указанное повреждение БД и происходит при использовании этой, фактически уже устаревшей, файловой системы). Допустим, размер вашей БД достиг 3-х гигабайт, и вы хотите перенести ее на NTFS, чтобы избежать ограничения в 4 Гб. Проблема в том, что с FAT32 на NTFS скопируется только 2 гигабайта из 3-х, из-за особенностей Windows. Это еще раз подчеркивает необходимость знания ограничений используемых файловых систем и их взаимодействия на одном компьютере. На текущий момент все последние версии InterBase, Firebird и Yaffil не имеют ограничений по размеру файла БД, для любых операционных систем. В остальных случаях, одной из характерных ошибок, которую наблюдают разработчики, является «cannot continue after bugcheck(xxx)» с любым номером ошибки. Это означает, что сервер во время работы перешел в такое состояние, что дальнейшая работа с базой данных может ее повредить. При этом рекомендуется рестартовать сервер, после чего желательно проверить базу данных утилитой GFIX.

Остановка во время сборки мусора

Повреждения индексов

Повреждения индексов могут происходить как по всем вышеперечисленным причинам, так и из-за ряда багов сервера при работе с индексами (исправлены в Firebird 1.5, Yaffil). Поскольку индексы не являются 100% необходимым видом объектов для функционирования базы данных, их повреждения обнаруживаются значительно позже (если администратор смотрит в interbase.log), чем повреждения других объектов БД (например, данных таблиц). И клиентские приложения могут продолжать функционировать в такой ситуации как и прежде.

Однако, при повреждении индексов возможно искажение данных, получаемых приложениями. Если в индексе повреждено несколько ключей, и сервер не выдал сообщения об ошибке при выполнении запроса, использующего такой индекс, в результат запроса не попадут записи, на которые ссылаются те самые поврежденные ключи. То есть, часть записей может «пропасть». Обнаружить разницу в выдаваемом количестве записей можно только используя запросы с полным перебором записей

где FIELD – столбец, по которому есть возможно поврежденный индекс, а > 0 – условие, которое однозначно будет выбирать все записи.
(разумеется, лучше этого не делать, а при подозрении на «пропадание записей» сразу посмотреть в interbase.log, перестроить те индексы, о повреждениях которых там сообщается.

В interbase.log пишутся только порядковые номера индексов (а не их имена) для конкретных таблиц, как это и указано в rdb$indices). Процесс backup поврежденные или неповрежденные индексы (за исключением повреждений индексов по системным таблицам) не интересуют, т. к. индексы в backup хранятся только в виде описания в системных таблицах (restore создает индексы по этим описаниям в самом конце процесса restore). Backup считывает записи в натуральном порядке и индексы не использует, поэтому все существующие (committed) записи обязательно попадут в backup. Однако, если поврежден уникальный индекс, то в определенных условиях существует вероятность повторной вставки записи в таблицу с уже существующим (уникальным) значением столбца. Эта ситуация может привести к невосстановимому backup, т. е. процесс restore остановится в момент создания уникального индекса, обнаружив дубликат уникального значения в восстановленных записях. Но такая проблема также не является катастрофической – процесс создания индексов выполняется самым последним, т. е. после того как абсолютно все объекты БД уже восстановлены в базе данных процессом restore. Если вдруг обнаружена проблема неуникальных данных при создании индекса, можно попробовать найти такую запись (и затем удалить лишнюю) запросом

Повреждения таблиц

Нормальная база данных – это не набор отдельных таблиц. Таблицы между собой могут быть достаточно сильно взаимосвязаны, вплоть до циклических ссылок. Поэтому даже один и тот же тип и объем повреждения может иметь разные последствия, в зависимости от того, с какой таблицей это произошло. Типичный пример: таблица CLIENTS – справочная, а ORDERS – оперативная. Если пропадет часть записей из ORDERS, то после починки БД будет нормально функционировать. Если же будет повреждена CLIENTS, то после починки в ORDERS будут записи, ссылающиеся на несуществующих клиентов. Таким образом БД вроде бы будет отремонтирована, но логическая целостность данных будет нарушена. Бороться с этой ситуацией никак невозможно, разве что чаще делая backup (поскольку справочники меняются реже, чем оперативные данные). Подобная ситуация (с повреждением master-таблицы) может возникнуть даже в том случае, если все записи пакета master-detail вставляются в одной транзакции, а Forced Write выключен (off) – страницы с записями detail могут быть записаны на диск операционной системой из кэша раньше, чем соответствующие им записи таблицы master. Это не приводит к «невосстановимому backup», но после restore придется или добавлять недостающие master-записи, или удалять «осиротевшие» detail-записи (в зависимости от сложности триггеров, обрабатывающих вставку в master или удаление в detail. Возможно, такие триггеры на время ремонта данных нужно будет отключить).

Также, в подобной ситуации, при restore отремонтированной базы данных могут оказаться неактивными (rdb$indices.rdb$index_inactive = 1) индексы по Foreign Key соответствующих связей master-detail. Активировать их можно после упомянутых вставок или удалений master/detail, путем установки rdb$indices.rdb$index_inactive в 0. О повреждениях системных таблиц см. дальше.

Ремонт БД

Повреждения баз данных могут быть исправлены как при помощи только gfix, так и одновременно gfix и gbak. Открываем консольное окно (cmd на W2K, или command на Win9x, или терминальное на Linux)

Лично я предпочитаю при операциях backup/restore всегда сохранять вывод в файл ключами -v -y outfile.txt. При обычном выводе на консоль «вывод» может потеряться, и тогда придется процедуру backup/restore повторять. Кроме того, в файле лога можно легко найти список объектов, которые успешно восстановлены.

1. Установите системные переменные, чтобы облегчить себе жизнь и не вводить постоянно для gfix/gbak параметры -user SYSDBA -pass masterkey

4. Проверьте базу данных на повреждения

gfix при проверке БД на наличие повреждений выводит информацию о повреждениях в interbase.log или firebird.log (подробно) и на экран (суммарно). Поэтому чтобы посмотреть на подробное описание повреждений, перед запуском команды ремонта БД следует переименовать interbase/firebird.log (например, firebird1.log, firebird20071010.log и т. д.), чтобы уже хранимая там информация не мешала дополнительному выводу gfix. Когда сервер не обнаружит лог-файл, он его создаст заново.

Невосстанавливаемый backup

Получить backup, который не пройдет restore («невосстанавливаемый» или «невосстановимый») вполне возможно по ряду причин и без сбоев сервера или оборудования. Для минимизации потраченного времени на поиск мест, где эти ошибки происходят, всегда нужно делать restore с ключом -v, и еще лучше – с выводом в файл (gbak . -v -y rest_log.txt). Если с починкой не сможете справиться сами, то тогда как минимум сможете предъявить в news-конференции или службе технического сопровождения точное сообщение об ошибке.

Существует утилита IBBackupSurgeon, которая позволяет вытащить из бэкапа БД необходимую информацию, даже в случае повреждения файла бэкапа. Также его можно использовать для нормальных или поврежденных бэкапов с целью извлечения из них только части хранимой информации (данных, структур и т. п.).

Проблемы с индексами

Как известно, восстановление базы данных из бэкапа происходит следующим образом:

1. gbak дает команду серверу создать новую БД с параметрами из бэкапа,
2. gbak копирует в новую базу пользовательские метаданные из бэкапа,
3. gbak копирует в новую базу пользовательские данные из бэкапа,
4. gbak активирует (создает) все индексы.

Пункт 4, то есть создание индексов, не случайно выполняется после восстановления всех данных. Если бы индексы были активны сразу после пункта 2, то заливка данных в БД была бы очень медленной.Соответственно, раз индексы создаются в самом конце процесса restore, ошибки при их создании не являются фатальными для функционирования БД, разве что без индексов запросы будут работать очень медленно. Во всех версиях InterBase и Firebird (кроме Firebird 2.x) при первой же ошибке создания индекса дальнейшее создание индексов прекращается. В Firebird 2.x ошибка создания индекса сообщается, но создание других индексов продолжается, что позволяет легко идентифицировать неактивные индексы по окончании restore.

В данном случае считать базу «невосстановленной» нельзя. Но понятно, что из-за неактивности некоторых индексов определенные запросы будут работать медленнее, и ссылочная целостность по этим FK проверяться не будет.

Дубликаты в уникальных индексах

Как уже было упомянуто в начале статьи, повреждения индексов обычно незаметны. Более того, повреждения уникальных индексов (ограничения Primary Key, Unique или просто уникальный индекс) могут привести к появлению неуникальных дубликатов записей в таблице. Во время работы это заметно не будет, однако при попытке restore базы данных может быть выдано сообщение о невозможности создать конкретный индекс.Интересно, что пользователи InterBase 7.x/2007, 2009, XE могут вообще не обнаруживать эту проблему, т. к. gbak в InterBase 7.x и выше по умолчанию не проверяет при restore следующие ограничения – not null, check, primary, unique, foregin key. То есть база может пережить много циклов сохранения-восстановления без обнаружения данной проблемы. Данное поведение полезно только в том случае, когда вам нужно восстановить именно невосстанавливаемый с данными проверками бэкап. Для принудительного контроля логической целостности при restore настоятельно рекомендуется добавлять ключ -validate .

У Firebird наоборот, по умолчанию ограничения проверяются, а выключить их проверку можно указав ключ -no_validity. Соответственно, при наличии дубликатов в уникальном индексе нужно эти дубликаты найти, а затем удалить. После чего проверить логическую целостность БД через бэкап-рестор.

Отсутствующие записи по Foreign key

Этот тип логической нецелостности данных также был описан в первой части статьи. Бороться с этой проблемой можно как на оригинальной базе данных, так и на восстановленной из бэкапа. Нужно выполнить запрос, который покажет имеющиеся в детали и отсутствующие в мастере идентификаторы.

Затем можно или записи с этими идентификаторами удалить из таблицы деталей, либо добавить соответствующие записи в таблицу-мастер (первое быстро, но с потерей данных; второе – долго, зато данные остаются). После исправления несоответствий в мастер-детали можно пересоздать (или активировать индекс) Foreign key.

Добавленный столбец NOT NULL

Изменение типа столбца

То же самое, что и предыдущий случай. Допустим, у таблицы есть строковый столбец. Его потребовалось заменить на столбец типа integer. IB допускает такую операцию (alter table alter column в IB6 и выше), но не пытается в момент изменения типа столбца преобразовать данные. Если хоть в одной записи в таком столбце случайно оказался символ, который невозможно преобразовать в число, restore не пройдет.

Помните, что исправить ситуацию повторным изменением типа столбца с integer на строку не удастся! В таких случаях обязательно надо перед изменением типа столбца проверять его на последующую читаемость операцией

и просмотром всех записей возвращаемых этим запросом в любом инструменте. Если при просмотре всей таблицы не произошло ошибок вроде «transliteration . overflow. «, то тип столбца можно смело менять. Если же ошибка была, нужно искать «проблемную» запись, и менять ее значение на допустимое для преобразования.То же самое относится и к случаю уменьшения длины строк. Операция alter, допустимая в IB 6 и выше, не даст уменьшить длину строкового столбца, т. к. данные могут оказаться длиннее нового размера столбца. Поэтому более безопасным способом (и для изменения типа столбца) является добавление нового столбца с нужным типом, копирование данных в него (update table set oldfield=newfield), удаление старого столбца и переименование нового в старое имя.

Однако такой способ часто не подходит, если на столбец есть масса ссылок из других объектов БД (например, таблиц), или объем данных очень велик. Изменить длину столбца или его тип в этом случае остается возможным только через системные таблицы. Но опять же, лучше заранее проверить максимальную длину данных (используя udf strlen в любой библиотеке udf, не из ib_udf) – select max(strlen(field)) from table.

Check constraint, не соответствующий хранимым данным

Cмысл проблемы состоит в том, что при restore сначала восстанавливаются метаданные, а потом уже сами данные. Исправить ситуацию можно используя при restore gbak с ключом -n, однако при этом не будут восстановлены ВСЕ check constraints у всех таблиц.

Данная ситуация также может возникнуть, например, если в для проверки столбца используется select. Если база данных была повреждена, и вы сделали gfix -mend, часть данных может пропасть (оказаться поврежденными и не попасть в backup). А раз часть данных пропала, ею могут оказаться как раз те данные, которые проверяли столбец по select. Также, в самых первых версиях InterBase 6.0 была ошибка, при которой check constraints проверяли данные до срабатывания триггеров. Таким образом, забыв о контроле check constraint можно было написать такой триггер, который изменял бы данные в противоречивое с check constraint состояние. Например, check constraint проверяет значение столбца > 0 и CHECK(STUFF IN (SELECT STUFF FROM STUFFHOLDER WHERE STUFF_ID=100))

такая конструкция может сделать невосстановимым бэкап дважды:

1. если структура таблицы X будет восстанавливаться раньше таблицы STUFFHOLDER
2. если данные таблицы X будут восстанавливаться раньше данных таблицы STUFFHOLDER

Кроме этого, весьма странно устанавливать зависимость метаданных таблицы от конкретных значений данных совсем другой таблицы. В такой ситуации лучше и намного безопаснее создать триггер с указанной проверкой (а кроме того заменить IN на EXISTS. Еще правильнее вообще так не делать, а сделать нормальный Foreing Key на STUFFHOLDER).

Еще одна ошибка, которая связана с check constraint, но не с данными, уже давно исправлена в Firebird и Yaffil. Это использование русских букв в default для строковых столбцов. При restore такая БД выдаст сообщение «arithmetic exception, numeric overflow, or string truncation» еще на этапе восстановления метаданных. При наличии оригинальной базы данных необходимо удалить такой default, и сделать backup повторно. При отсутствии БД следует попытаться использовать ключ gbak -n.

Процедуры и триггеры

Здесь ситуация с невосстановимым backup может произойти при модификации (alter) процедур, которые вызываются другими триггерами или процедурами. Если меняется только тело процедуры, то проблем не будет. А если меняется количество или типы параметров процедуры, то в этом случае при restore (да и при alter вызывающих процедур) будет выдаваться сообщение о том, что список параметров процедуры не соответствует используемому.

Проблема там же, где и всегда – при реконструировании метаданных объекты строятся в памяти один за другим, образуя целые «гирлянды» из взаимосвязанных объектов. При этом код этих объектов (текст процедур или триггеров) не перекомпилируется. Но список параметров процедур хранится отдельно, в rdb$procedure_parameters, поэтому несоответствие используемомого и хранимого наборов становится камнем преткновения для restore. Борьба с этой ситуацией возможна фактически только при наличии оригинальной БД. Сейчас можно удалить или изменить процедуру, которая вызывает другую с измененным количеством параметров, однако в предыдущих версиях InterBase и Firebird это не было возможным. Единственный способ исправить проблему приведен в документе. Однако, с триггерами, вызывающими такие процедуры, ситуация похуже, потому что сервер не даст возможности обновить blr триггера. Поэтому остаются только «хакерские» приемы, вроде создания «пустой» процедуры с нужным количеством и типами параметров, и изменению blr триггера при помощи hex-editor.

В общем, к подобным изменениям нужно относиться более тщательно, используя инструменты, которые показывают зависимости между объектами (IBExpert), и комментируя вызовы процедур перед изменением количества или типов их параметров.

Повреждения системных таблиц

Разумеется, при повреждении системных таблиц информация о некоторых объектах будет потеряна, и backup не сможет сохранить данные этих объектов. Однако, если сами данные в системных таблицах целы, а индексы системных таблиц повреждены, backup может неверно сохранить информацию об объектах.

Происходит это потому, что backup выполняет запросы к системным таблицам, а эти запросы могут использовать индексы. Если индекс поврежден, то запрос может вернуть неверную информацию (меньше записей, чем их есть на самом деле). Таким образом или часть объектов просто не попадет в backup, или при restore будут серьезные проблемы из-за несоответствия информации в связанных между собой системных таблицах.

Поэтому, если вы в interbase.log наблюдаете информацию о поврежденных индексах на системных таблицах, то делать backup надо только после удаления таких индексов. Поврежденные индексы можно особо не выискивать, а удалить все целиком в rdb$indices, у которых rdb$relation_name начинается с префикса RDB$. Все равно индексы по системным таблицам относятся к системным таблицам, и создаются gbak при restore автоматически, независимо от содержимого backup.

Есть еще один случай повреждения базы данных, который относится к правам на объекты (таблицы, процедуры и т. п.). Проявляется это повреждение как ошибка в процессе restore с сообщением об отсутствии объекта, на который существуют назначенные права (в самом конце процесса restore). Как следует из кода restore.e, данная проверка является избыточной, т. к. если объекта нет, то и права на него восстанавливать не надо. Однако, код restore.e в таком случае выдает не предупреждение, а сообщение об ошибке, в результате чего процесс restore не доходит до завершения.

В конкретном случае были попытки определить несоответствие в rdb$user_privileges и остальных таблицах (rdb$relations и т. п.), однако таковых найдено не было. Ситуацию удалось решить компиляцией специального варианта restore.e (gbak.exe), в котором при отсутствии объекта, на который выдаются права, просто ничего не делается (не выдается никаких сообщений). Остается надеяться, что в новых версиях IB/FB/YA эта ситуация будет исправлена.

Пока что для обнаружения подобных проблем можно воспользоваться следующим способом – при правильном backup/restore всегда оставляют оригинальную БД (см. невосстанавливаемый backup). Для проверки существования в восстановленной базе данных всех объектов можно извлечь скрипты из обоих БД (например isql-ом), и сравнить их утилитой Database Comparer (info, download). Если отличий найдено не будет, значит структуры обоих БД идентичны. Если нет – найти поврежденный индекс и саму системную таблицу очень легко, зная в каких системных таблицах какие объекты хранятся (Language Reference.pdf).

Проблемы оборудования

Проблемы «железа» тоже могут сделать бэкап невосстанавливаемым. Я сам столкнулся со случаем, когда пользователь сообщил о том, что при попытке restore ошибки выдаются в разных местах. Было сделано предположение о дефективном HDD или RAM. Последнее предположение подтвердилось.В таких случаях хорошо, если проблемы оборудования проявили себя на этапе restore, а не backup. Если бы память (RAM) начала сбоить в момент backup, никто бы не узнал о проблемах вплоть до момента restore, и наверняка файл backup был бы поврежден так, что его нельзя было бы восстановить никаким образом. Причем никакими средствами вроде «контрольных сумм backup» предотвратить эту ситуацию невозможно, т. к. в файл данные пишутся именно операционной системой из памяти.

Поэтому позволю себе дать несколько банальных советов: не используйте модули RAM разных производителей в одном компьютере
старайтесь для сервера выбирать motherboard и память, поддерживающие ECC.

Дополнительные способы ремонта БД

Backup после этой операции прошел успешно.

То же самое можно проделывать в отношении «дефектных» записей (или их версий), при чтении которых выдается сообщение об ошибке. Основная трудность состоит в том, что физически на диске записи неотсортированы, и придется несколько раз выполнять запросы, выбирающие записи с разных «сторон» таблицы, чтобы найти примерно запись с какими данными (первичным ключом) не может быть прочитана. Пример кода, который производит копирование записей из «дефектной» таблицы в другую БД.

После нахождения такой записи ее можно попытаться удалить, или при помощи любых средств копирования данных перенести записи таблицы в другую БД, исключая поврежденную запись.

Внутри val.c есть кусочек документации, описывающий что и как делает gfix. Вот перевод этого куска. (Ни один другой файл исходного текста не содержит подобной «документации»).

Database Validation and Repair

Deej Bredenberg
March 16, 1994
Updated: 1996-Dec-11 David Schnepper

I. Терминология

II. Опции командной строки

Вот все ключи командной строки, которые используются при починке базы gfix-ом:

ключ	константа dbp
-validate	isc_dpb_verify	Выполняет проверку и починку БД. Все другие ключи модифицируют действие этого ключа.
-full	isc_dpb_records	Проверяет все записи. Без этого ключа проверяются только структуры страниц.
-mend	isc_dpb_repair	Пытается починить базу данных, чтобы она хотя бы могла быть читаема. Не гарантирует восстановления испорченных данных.
-no_update	isc_dpb_no_update	Указывает, чтобы осиротевшие страницы не освобождались, а занятые не помечались как используемые, если обнаружится что они на самом деле свободны. Не совсем корректное название ключа, потому что при его употреблении с -mend база будет чиниться, а если -mend не указан и указано -no_update, никаких изменений в БД сделано не будет.
-ignore	isc_dpb_ignore	Выключает подсчет контрольных сумм при выборке страниц. Проверка все равно будет сообщать контрольные суммы. Рекомендуется к использованию. Замечание: ODS 8.0 не имеет контрольных сумм на страницах. ODS 9.0 вообще не имеет контрольных сумм.

III. Как это работает

Проверка БД работает только при эксклюзивном доступе к базе данных, чтобы в момент починки не было никаких посторонних изменений. При подключении к БД происходит попытка поставить эксклюзивную блокировку на файл базы данных. Если обнаружены другие коннекты к БД, выдается сообщение: «Lock timeout during wait transaction — Object «database_filename.gdb» is in use»

ЗАМЕЧАНИЕ: Обычно, когда процесс получает эксклюзивный доступ к БД, все активные транзакции помечаются как dead в Transaction Inventory Pages. Это поведение выключено при проверке БД.

IV. Фазы проверки

A. Просмотр страниц

B. Сборка мусора

V. Фаза просмотра

A. Выбор страниц

B. Проверка таблиц

Проверяются все таблицы в базе данных. Для каждой таблицы выбираются все индексы, и все страницы указателей и данных (см. дальше). Но вначале, сканируются метаданные в RDB$RELATIONS для определения формата таблицы. Если эта информация утеряна или повреждена, таблица не может быть поверена. Если любые ошибки бнаружены в момент проверки, выдается сообщение: «bugcheck during scan of table xxx ()» После этого любая дальнейшая проверка таблицы прекращается.
ЗАМЕЧАНИЕ: Для views производится только проверка метаданных.

C. Проверка индексов

D. Страницы указателей

Проверяются все страницы указателей для таблицы. При их проходе проверяются все дочерние страницы (см. дальше). Если страница указателей не может быть найдена, выдается сообщение: «Pointer page (sequence xxx) lost». Если страница указателей оказалась не той таблицы, которую мы проверяем, или она не помечена в правильной последовательности, выдается сообщение: «Pointer page xxx is inconsistent». Для каждой страницы указателей, которая не указывает на следующую страницу указателей в соответствии с столбцом RDB$PAGE_SEQUENCE в RDB$PAGES, выдается ошибка: «Pointer page (sequence xxx) inconsistent».

E. Страницы данных

Проверяется каждая страница данных, на которую указывает страница указателей. Если найдены повреждения на уровне страницы, и указан ключ -mend, то страница удаляется со страницы указателей. Это приводит к потере данных, которые располагались на этой странице данных. Если страница данных повреждена на уровне страницы, и не помечена как часть проверяемой таблицы, или не помечена в правильной последовательности, выдается сообщение: «Data page xxx (sequence xxx) is confused».

F. Проверка слотов

Проверяется каждый слот на странице, и на ней обновляется количество хранимых записей. Если слот не нулевой, то выбирается фрагмент записи по указанному смещению. Если запись начинается перед концом массива слотов, или продолжается за пределами страницы, выдается сообщение: «Data page xxx (sequence xxx), line xxx is bad», где «line» означает номер слота.
ЗАМЕЧАНИЕ: Если обнаруживается такое условие, страница данных считается поврежденной на уровне страницы, и в результате будет удалена со страницы указателей, если указан ключ -mend.

G. Проверка записей

Проверяется запись в каждом слоте, независимо от указания ключа -full. Фрагмент записи может быть опознан как
1. Обратная версия
Если фрагмент помечен как «обратная» версия, то он пропускается. Он будет выбран как часть записи.
2. Поврежденный
Если обнаруживается, что фрагмент поврежден любым образом, и указан ключ -mend, то в заголовке запись помечается как «поврежденная».
3. Помеченный как поврежденный
Если фрагмент уже помечен как поврежденный в результате предыдущей проверки, то выдается сообщение: «Record xxx is marked as damaged», где xxx является номером записи.
4. От неверной транзакции
Если запись имеет номер транзакции больше, чем номер самой последней транзакции в базе данных, выдается сообщение: «Record xxx has bad transaction xxx».

H. Проверка записей

Если указан ключ -full, и фрагмент является первым фрагментом логической записи, то запись в соответствующем номере слота выбирается целиком. Это приводит к выборке всех версий, и всех фрагментов для каждой версии. Другими словами, запись извлекается целиком.
1. Обратные версии
Если есть обратные версии, то они в этот момент проверяются. Если обратная версия находится на другой странице, то страница выбирается, но не проверяется пока она не будет проверена отдельно (проверкой страниц). Если номер слота обратной версии больше количества записей на странице, или нет записи в таком номере слота, или это blob, или это фрагмент записи, или фрагмент поврежден, выдается сообщение: «Chain for record xxx is broken».
2. Неполные
Если заголовок записи имеет пометку «неполный», это означает что для выборки записи нужно обратиться к другим фрагментам – запись оказалась слишком большой, чтобы поместиться в один слот. Для фрагментированных записей все фрагменты выбираются для всех версий записей. Если любой из фрагментов не обнаруживается в ожидаемом месте, или имеет неверную длину, выдается сообщение: «Fragmented record xxx is corrupt». Как только запись выбрана целиком, проверяется длина формата, в соответствии с ожидаемым в RDB$FORMATS (номер формата хранится в заголовке записи, представляя точную структуру таблицы на тот момент, когда запись была сохранена на диск). Если длина реконструированной записи не соответствует длине, получаемой из формата, выдается сообщение: «Record xxx is wrong length». Для версий записей, которые представляют собой результат действия оператора update, данная проверка не производится.

I. Проверка блобов

Если слот на странице данных указывает на запись blob, то blob выбирается (даже без -full). При этом возникает ряд вариантов, в соответствии с различными уровнями blob (см. документацию «Особенности ядра»). (KDV: документация с названием Engine Internals (Особенности ядра) не опубликована до сих пор). Действия в зависимости от уровня
—— ——————————————————————
0 Данные blob находятся тут же, на странице данных. Дополнительные проверки не производятся.
1 Все страницы, на которые указывает запись blob, выбираются и проверяются.
2 Все страницы, на которые указывают страницы указателей blob, выбираются и проверяются..
3 Страница blob является указателем на страницы blob. Все дочерние страницы выбираются и проверяются. Для каждой найденной страницы blob производятся проверки. Если страница не указывает обратно на страницу-источник, то выдается сообщение: «Warning: blob xxx appears inconsistent» где xxx это номер записи blob. Если любая из страниц blob не отмечена в последовательности, как это ожидается, выдается сообщение: «Blob xxx is corrupt» Tip: сообщение для такой же ошибки, но на уровнях 2 и 3, немного отличается: «Blob xxx corrupt». Если потеряна любая из страниц blob в последовательности, выдается сообщение: «Blob xxx is truncated». Если обнаруживается, что выбираемый blob поврежден одной из вышеуказанных причин, и указан ключ -mend, то запись blob помечается как поврежденная. (KDV: иногда маркировка как «damaged» не помогает. Т. е. сообщение blob xxx corrupt выдается при backup независимо от того, как и с какими ключами производилась починка БД gfix. См. пример ручного исправления ситуации в начале статьи).

J. Проверка индексов

K. Проверка таблиц

VI. Дополнительные замечания

A. Поврежденные записи

B. Поврежденные Blob

Заключение

Третий закон Чизхолма: Любые предложения люди понимают иначе, чем тот кто их вносит.
Следствие 1: Даже если ваше объяснение настолько ясно, что исключает всякое ложное толкование, все равно найдется человек, который поймет вас неправильно.

Источник