FAQ по Firebird(Yaffil)

[oaken]

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

Список вопросов:

1. Как правильно производить резервное копирование (Backup) БД?
2. Какой размер страницы выбрать для БД?
3. В чем разница между Super и Classic архитектурами?
4. Что такое уборка мусора и как ею управлять?
5. Где хранятся пользователи СУБД?
6. Порядок действий по восстановлению поврежденных файлов БД.
7. Проверка (Validation) БД, что это такое, как ее применять на практике.

[oaken]

Q: 1. Как правильно производить резервное копирование (Backup) БД?

A: Основная задача обслуживания БД состоит в обеспечении наличия максимально свежей версии бекапа на случай аварийных ситуаций. В простейшем случае создание резервных копий можно производить с помощью утилиты gbak.exe на компьютере, где установлен сервер БД. Командная строка может выглядеть так:

Код: [Select]

gbak -b base_file.fdb backup_file.fbk -user SYSDBA -pass masterkeгде base_file.fdb - путь к файлу БД, backup_file.fbk - путь к файлу резервной копии, SYSDBA и masterke - логин и пароль пользователя, обладающего административными правами на сервере, обычно это SYSDBA.

Создание резервных копий можно автоматизировать с помощью доступных скриптовых средств операционной системы или же с помощью специализированных сервисных утилит. В любом случае стоит придерживаться таких рекомендаций:
1. Как можно чаще создавать резервные копии БД. Хранить несколько последних резервных копий, желательно на разных физических машинах.
2. Планировку создания резервных копий производить с таким расчетом, чтобы задачи по созданию бекапов стартовали в моменты наименьшей нагрузки на БД. Ведь задача бекапа это еще одно ресурсоемкое подключение к Вашей базе данных.
3. В момент планируемого отсутствия активности пользователей стартовать задачу резервного копирования с "уборкой мусора" во всех остальных случаях - создавать бекапы без уборки мусора. Уборка мусора по умолчанию включена для утилиты gbak, ее отключение производится с помощью опции -g. Более детально об уборке мусора можно почитать здесь.
4. Производить какие-либо манипуляции с БД до старта операции бекапа не нужно!!! Это значит, что бекап возможно и нужно производить не отключая пользователей от БД. Отключение необходимо только для валидации, а валидация в свою очередь - для определения степени поломки файла поврежденной БД, те в крайних случаях.

[oaken]

Q: 2. Какой размер страницы выбрать для БД?

A: Желательно чтобы размер страницы был равен или больше размера кластера логического диска. При настройке серверного железа с нуля можно отформатировать раздел под БД с размером кластера в 8Кбайт (8192 байт) и такой же размер страницы выбрать дл БД. Такой размер самый оптимальный для современных систем.

Установка размера страницы БД возможна только при создании новой или же при восстановлении (Restore). Утилита командной строки использует для этого параметр -page_size. Пример командной строки для восстановления БД с размером страницы 8Кбайт:

Код: [Select]

gbak -c -page_size 8192 backup_file.fbk database_file.fdb -user SYSDBA -pass masterke
При форматировании логического раздела можно указать размер кластера с помощью опции /A:8192 системной утилиты format.
Узнать размер кластера уже отформатированного диска можно узнать с помощью специализированных утилит. Несколько простых способов сделать это:
1. Запустить утилиту проверки диска CHKDSK С:, где C: - нужный раздел. В конце работы утилита выдаст статистику диска3, одним из показателей которой будет размер кластера.
2. С помощью файлового менеджера FAR, выбрать небольшую по размеру папку на диске, нажать комбинацию Ctrl+Q в открывшемся окне (Quik View) будет информация о размере кластера Cluster size.

[oaken]

Q: 3. В чем разница между Super и Classic архитектурами?

A: Classic (CS) архитектура, в отличие от SuperServer (SS), предусматривает обслуживание каждого пользовательского подключения отдельным процессом. При этом для каждого подключения используется свой кеш данных, что приводит к неоптимальному использованию оперативной памяти. SS для каждого коннекта выделяет отдельный поток, кеш данных для всех потоков общий.

Достоинства CS:
  - надежность, критические сбои какого-либо подключения не приводят в краху всех остальных процессов, в отличие от SS.
  - использование всех ядер многоядерных процессов, ведь каждое подключение в  SS по сути есть отдельная программа. SS тоже может использовать несколько процессорных ядер, для настройки использования нескольких процессоров служит настройка Affinity в файле настройки сервера firebird.conf. Однако распарралелливание между процессорами в SS не такое эффективное как в CS, поэтому по умолчанию эта опция указывает на использование 1-го процессорного ядра. Увеличение количества используемых ядер для архитектуры SS имеет смысл только при обслуживании сервером нескольких физических баз одновременно.

Начиная с версии 2.5, Firebird может работать в режиме SuperClassic Server (SCS). Условно эту архитектуру можно представить как развитие SS. SCS объединяет в себе достоинства SS и CS. В этом режиме также подключения обслуживаются разными потоками в рамках одного процесса, однако менеджер блокировок страниц кардинально переделан, в связи с чем достигается эффективный режим работы на нескольких процессорныъ ядрах. По сравнению с архитектурой SS в SCS несколько уменьшается эффективность использования оперативной памяти.

[oaken]

Q: 4. Что такое уборка мусора и как ею управлять?

A: Общеизвестно, что Firebird - это версионный сервер. Версии записей создаются при update и delete, живут определенное время (пока нужны транзакциям), и убираются как мусор в определенные моменты. Мусор - это версии записей, которые уже не нужны ни одной активной транзакции. Накопление большого количества мусора в базе приводит к ухудшению производительности. Поэтому сервер обладает встроенными механизмами по уборке мусора в своих базах. Существует 3 основных пути уборки мусора:

1. Sweep ручной или автоматический. Ручную уборку мусора можно выполнить с помощью утилиты командной строки такого вида:

Код: [Select]

gfix.exe -sweep database.fdb -user SYSDBA -pass masterkeАвтоматическая уборка мусора стартует при накоплении достаточного количества мусорных записей. Порог срабатывания автоматического sweep регулируется параметром БД SWEEP INTERVAL. Этот параметр можно установить командной строкой такого вида:

Код: [Select]

gfix -housekeeping 0 database.fdb -user SYSDBA -pass masterkeЭта команда устанавливает значение Sweep Interval в ноль, что означает отключение автоматической уборки мусора. Значение по умолчанию этого параметра для новых баз = 20000.

2. Кооперативная уборка мусора. Срабатывает во время чтения конкретной записи из БД, при этом все мусорные версии этой записи удаляются автоматически. Это значит, что при большом количестве мусора в базе, обычные операции на чтение из таблиц могут периодически подтормаживать из за кооперативной уборки мусора.

3. Разновидность кооперативной уборки - уборка мусора во время создания резервных копий. Процесс создания резервной копии можно представить в виде обычной программы, которая стартует транзакцию с уровнем изоляции SNAPSHOT, читает все данные из БД и записывает их в специального формата файл. По умолчанию, во время этого процесса также работает кооперативная уборка мусора. После создания резервной копии в таком случае рабочая база будет очищеня от мусора. Однако бекап с уборкой мусора требует больше времени и ресурсов системы. Поэтому есть возможность отключать уборку мусора при создании бекапов для уменьшения нагрузки на сервер. Для этого служит ключ -g утилиты gbak. Подробнее смотрите здесь.

[oaken]

Q: 5. Где хранятся пользователи СУБД?

A: Хоту отметить с самого начала, что во многих системах построенных на базе Firebird - подобных СУБД, возможны смысловые варианты в понятии "пользователь". Это значить, что к сущности "пользователь СУБД" может добавляться сущность "пользователь программной системы", так, например, обстоят дела в программах ДЗС/ДАС/ДГС. В этих системах понятие "пользователь" расширено до некоего прикладного уровня таким образом, что на каждого пользователя СУБД может быть своя запись в специальной табличке конкретной БД, которая регламентирует права пользователя более широко на прикладном уровне. Обычно, запись в такой табличке относится с пользователем СУБД по его логину.

Рассмотрим теперь сугубо пользователей СУБД. Firebird хранит информацию о пользователях хранится в общей базе данных безопасности. Это обычная база данных СУБД Firebird, которая располагается на сервере, и называется security.fdb. Начиная с СУБД Firebird 2 она называется security2.fdb. По умолчанию этот файл располагается в корневой директории Firebird. Yaffil хранит своих пользователей в БД ISC4.GDB. В этих базах хранятся информация о пользователях а также хеши паролей, те паролей пользователей на сервере нет.

Привилегии и роли пользователей хранятся в каждой БД отдельно. Для использования роли необходимо ее указание вместе с логином при подключении. Роли в ДАС/ДГС/ДЗС не используются.

В СУБД Firebird есть 2 специальных пользователя:
  1. SYSDBA - пользователь с полными правами, который создается по умолчанию при установке сервера.
  2. PUBLIC - виртуаальный пользователь, представляющий всех пользователей. Если какая-то операция разрешена пользователю PUBLIC, значит, любой аутентифицированный пользователь может выполнить эту операцию над указанным объектом.

[oaken]

Q: 6. Порядок действий по восстановлению поврежденных файлов БД.

A: Самый частый случай повреждения базы данных это отключение питания на сервере. Такие ситуации нужно пытаться предотвращать, используя аппаратные средства (UPS, RAID-контроллеры с батарейками). Возможны также повреждения как результат использования некачественного оборудования, конфликтов программного обеспечения и т.п. Повреждения условно можно разделить на 2 группы:
 
1. Некритичные. Обычно, в случае таких повреждений вполне возможна нормальная работа с такими базами. В большинстве случаев такие повреждения исправляются процедурой Бекап/Рестор. К таким ошибкам можно отнести повреждения страниц индексов, при рестрое они успешно пересоздаются и все встает на свои места.

2. Критичные, повреждения данных или метаданных. В результате начинают возникать непонятные ошибки при работе с БД вплоть до полного отказа подключения к базе. В таких случаях можно поступить следующим образом:
  - скопировать оригинальный файл БД в надежное место, предварительно отключив всех пользователей от базы данных. Все нижеперечисленные работы проводить только на копии базы! Потому что почти все операции по восстановлению испорченного файла БД носят необратимый характер.
  - попытаться сделать бекап/рестор базы. Если операция по резервному копированию и восстановлению прошла успешно, значит Вам очень повезло, на этом можно закончить.

3. Если бекап прошел, но восстанеовить базу не удается, то нужно поступить таким образом:
      - попробовать восстановить базу без активации индексов. Большинство ошибок восстановления бекапов успешно сделанных с битых БД заключается именно в нарушении условий уникальности некоторых индексов. После того как БД отресторится можно поочередно активировать индексы (желательно каким-либо визуальным средством а-ля IBEXpert). Плохой индекс не активирутеся с соответсвующей ошибкой, по описанию которой можно будет определить где и в какой таблице искать "плохую" запись. Восстановление БД с неактивными индексами возможно с помощью команды такого вида:

Код: [Select]

gbak -c -inactive backup_file.fbk database_file.fdb -user SYSDBA -pass masterke 
4. Если не удается создать бекап, то необходимо провести валидацию файла бд командой такого вида:

Код: [Select]

gfix -v -full database.fdb -user SYSDBA -pass masterkeЕсли выдаются ошибки checksum error, то нужно выполнить следующую команду

Код: [Select]

gfix -v -ignore database.fdb -user SYSDBA -pass masterkeЕсли предыдущая команда обнаружила ошибки, то нужно их исправить командой.

Код: [Select]

gfix -mend database.fdb -user SYSDBA -pass masterkeЭта операция позволяет пометить ошибочные страницы для того чтобы в дальнейшем процедура пошла в обход их.
Проверяем все ли починилось:

Код: [Select]

gfix -v -full database.fdb -user SYSDBA -pass masterkeЕсли на этот момент вы все еще видите ошибки, то надо попытаться сделать backup, при этом обязательно нужно отключать сборку мусора (ключ -g):

Код: [Select]

gbak -b -v -ig -g database.gdb database.gbk -user SYSDBA -pass masterkeключ -ig игнорирует ошибки при чтении структур данных, и пытается сохранить в backup все неповрежденные структуры и данные.

!Никогда не указывайте ключ -ig при обычном бэкапе - если в базе есть ошибки, gbak их проигнорирует и вы не узнаете, что база была повреждена. В результате такой бэкап может быть невосстановимым.

[oaken]

Q: 7. Проверка (Validation) БД, что это такое, как ее применять на практике.

A: Многие считают, что валидацию базы данных следует применять для установления факта наличия ошибок в базе данных. Во многих случаях такая уверенность произрастает на почве практического применения валидации в прогамме "Резерв БД" (Сирко). К сожалению, это не так. Проверять базу следует в случае сбоев в ее работе, для определения степени повреждения файла базы данных и, частично, для подготовки к созданию резервной копии поврежденной БД.

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

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