Администрирование InterBase: обслуживание БД

Резервное копирование базы данных (Backup)

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

Еще один важный момент: копии базы данных должны храниться не просто на другом разделе жесткого диска, а вообще на другом жестком диске, ведь диск с рабочей БД тоже может выйти из строя. Если копии будут храниться на нем, то они также будут потеряны. Лучше всего хранить резервные копии на другом ПК, и (или) записывать их на CD -носители. К примеру, во многих банках существует правило: делать три резервных копии и хранить их в разных местах, даже в разных зданиях (на случай пожара). Так что отнеситесь к этой лекции серьезно.

Проще всего было бы скопировать файл базы данных *.gdb на другое место, однако так делать не рекомендуется по разным причинам. Пользователи могут вносить данные в базу, следовательно, файл БД будет постоянно изменяться. Чтобы просто скопировать файл, придется отключить работу сервера, то есть, запретить пользователям работу с базой данных, что обычно не приветствуется персоналом организации. Кроме того, в лекции №18 мы говорили, что интенсивная работа с базой данных может привести к тому, что индексы становятся разбалансированными, значения в них располагаются, как попало, и использование индекса не ускоряет, а даже замедляет поиск данных. А в лекции №24 мы говорили о транзакциях, и знаем, что многие версии старых записей (мусор) обычно присутствуют в БД, возможно, есть и "повисшие" транзакции. Все эти проблемы не решаются простым копированием файла *.gdb, и остаются в такой копии.

Для создания нормальной резервной копии БД, в InterBase имеются собственные механизмы. Использование встроенных механизмов InterBase имеет следующие преимущества:

Таким образом, резервное копирование нужно осуществлять исключительно средствами InterBase.

Резервную копию можно сделать разными способами: с помощью утилиты командной строки, с помощью IBConsole, а также программно (рассмотрим в следующей лекции). Испробуем вначале самый простой вариант - утилиту IBConsole.

Backup с помощью IBConsole

Убедитесь, что сервер InterBase запущен, и загрузите IBConsole. Вначале откройте раздел локального сервера, в котором хранится наша БД First.gdb. То есть, вы должны войти в локальный сервер, указав пароль пользователя SYSDBA. Не имеет значения, открыта ли сама база First, копирование можно проводить как при работающей, так и при закрытой БД. Выберите команду меню "Database -> Maintenance -> Backup/Restore -> Backup". В разделе Database в поле Alias выберите псевдоним нашей БД " first ". В разделе Backup File(s) в поле Server укажите " Local Server ", а в поле Alias также укажите " first ". В нижнем разделе нужно вписать адрес и имя создаваемой резервной копии (в качестве имени я использовал текущую дату, у вас имя может быть другим), как на рисунке ниже. Когда вы в следующий раз будете делать резервное копирование, то адрес и имя резервной копии заполнятся автоматически, как только вы выберите алиас " first " в разделе Backup File(s). В этом случае вы сможете оставить имя файла и адрес без изменений, или же изменить их. Как видите, backup -файлам традиционно дают расширение *.gbk:

В правой части окна можно ничего не менять, подробнее о параметрах резервного копирования мы поговорим ниже. Нажмите кнопку "ОК", и резервное копирование начнется, оно может занять некоторое время. По окончании копирования выйдет сообщение " Database backup completed". Теперь можете закрыть все окна и открыть папку с базой first.gdb. Там же должен появиться файл с резервной копией 03012010.gbk. Сравните размеры этих файлов и убедитесь, что backup -файл в десятки раз меньше. Далее полученную копию можно размножить уже обычным образом, перенести ее на другой ПК или (и) переименовать ее. При создании резервной копии можно указать любое имя файла. Мы указали текущую дату. Такой прием позволяет хранить много копий в одном месте, и всегда можно найти самую свежую из них.

Backup с помощью утилиты командной строки

Как для создания резервной копии, так и для восстановления БД InterBase предлагает утилиту командной строки gbak, которая неявно вызывалась утилитой IBConsole и в предыдущем примере. Если вы еще не забыли, утилиты InterBase хранятся в папке BIN там же, где установлен InterBase. Утилита gbak является наиболее универсальным и гибким инструментом, позволяя задавать множество параметров. При миграции БД с одной версии InterBase к другой, действует правило: можно восстанавливать резервные копии более старых версий InterBase, но не наоборот. То есть, если ваша резервная копия сделана на InterBase версии 6.5, ее без проблем можно перенести в 7.1 или выше. При попытке сделать обратную миграцию, вы можете столкнуться с массой проблем. Также gbak можно использовать для миграции между InterBase, Firebird или Yaffil, все клоны всех версий также содержат эту утилиту.

Синтаксис утилиты простой:

gbak <параметры> <файл_оригинал> <файл_копия>

Параметры gbak для резервного копирования отражены в следующей таблице:

Загрузите окно cmd, сделайте текущей папку

c:\program files\borland\interbase\bin

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

Обычную копию можно сделать командой (выполните эти примеры, в окне cmd их придется вводить вручную):

gbak -user sysdba -pas masterkey -b c:\databases\first.gdb c:\databases\first.gbk

Копию с выводом информации на экран:

gbak -user sysdba -pas masterkey -b -v c:\databases\first.gdb c:\databases\first2.gbk

Копию пустой БД (только метаданные):

gbak -user sysdba -pas masterkey -b -m  c:\databases\first.gdb c:\databases\empty_first.gbk

Restore с помощью IBConsole

Если резервное копирование базы данных нужно делать как можно чаще, то восстановление ( restore ) делается изредка, по необходимости. Например, для оптимизации работы базы данных (сборка мусора, удаление повисших транзакций, пересчет индексов), при миграции на другой SQL -сервер, или при разрушении БД, что к счастью, случается нечасто. Оптимизацию желательно делать не реже, чем раз в месяц. Если же вы делаете восстановление с целью перехода, например от InterBase 6.5 на InterBase 7.1 или выше, то резервную копию нужно делать на старом сервере, а восстановление - уже на новом. Если база данных большая, то восстановление может занять какое то время.

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

Откройте IBConsole и войдите в локальный сервер (база данных first должна быть закрыта). Выберите меню " Database -> Maintenance -> Backup/Restore -> Restore". Часть параметров заполнится автоматически, однако их можно поменять. Например, можно выбрать другой файл с резервной копией, указать иной размер страниц, и т.д. Взгляните на следующий рисунок:

Если вы помните, в лекции № 15 мы создавали базу данных с размером страницы 4096. Это было сделано специально, чтобы в данной лекции продемонстрировать изменение размера страницы при восстановлении резервной копии на более подходящий размер 8192. Также в поле Overwrite (Писать поверх существующего файла) мы указали True, чтобы заменить старую БД. В реальной практике записывать восстанавливаемую БД поверх существующей рабочей версии ни в коем случае не рекомендуется. Что, если восстановление пройдет неудачно, а рабочую БД мы уже "затрем"? Поэтому рекомендуется восстанавливать базу данных в другую папку, и только в случае, если при восстановлении не выйдет ошибок, поместить ее вместо старой рабочей версии. Причем желательно на всякий случай сделать простую копию (Проводником Windows или другим файловым менеджером) и старой рабочей версии.

Теперь стоит только нажать "ОК", и восстановление базы начнется. Подробная информация о восстановлении будет выведена в отдельное окно. Закончится восстановление сообщением "Service ended at 03.01.2010 11:58:25" (у вас будут другие дата - время). После этого сообщения все окна Restore можно закрыть, а восстановленную БД - открыть и работать с ней.

Restore с помощью утилиты командной строки

Для восстановления базы данных из резервной копии также используется утилита gbak, но уже с другими параметрами:

Обычное восстановление утилитой gbak с выводом информации на экран может быть выполнено командой (сначала перенесите существующий first.gdb на другое место):

gbak -user sysdba -pas masterkey -c -v c:\databases\03012010.gbk  c:\databases\first.gdb

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

Если при восстановлении БД мы хотим изменить размер страниц, укажем их в параметре - p:

gbak -user sysdba -pas masterkey -c -p 8192 -v c:\databases\03012010.gbk  c:\databases\first.gdb

Теневые (Shadow) копии

Сервер InterBase имеет механизм теневого ( shadow ) копирования базы данных. Такое копирование создает "зеркало" базы данных на случай какого-либо аппаратного или сетевого сбоя, или случайного удаления или повреждения базы данных операционной системой. В этом случае имеется возможность вручную или даже автоматически перейти с основной базы данных на теневую копию, и продолжить работу системы. Однако теневое копирование ни в коем случае не может заменить резервное копирование утилитой gbak, так как все ошибки и мусор, присутствующие в основной базе данных, будут присутствовать и в ее теневой копии. Shadow - файлы являются дополнительным средством безопасности данных, но никак не панацеей от всех возможных бед. Теневые копии можно создавать и в другой папке того диска, на котором находится основная база данных, однако при этом теряются все преимущества использования shadow копий. Обычно такие копии создают на другом жестком диске, физически подключенном к серверному ПК.

Создание и удаление теневых копий происходит посредством команд DDL (часть SQL ), которые можно вводить разными способами, например, с помощью IBConsole. Для примера создадим теневую копию для нашей базы данных first.gdb. Эту копию мы поместим по адресу D:\DataBases\ , однако если у вас на компьютере нет диска D:, то просто создайте другую папку, например, C:\DataBases2\ и соответственно меняйте адрес в примерах ниже на собственный. На момент создания теневой копии указанная папка должна существовать.

Запустите сервер InterBase, если он не работает, и загрузите IBConsole. Войдите в локальный сервер пользователем SYSDBA (также на создание теневой копии имеет право владелец (создатель) базы данных, если ее создавал не SYSDBA ). Далее откройте базу данных first. Теневая копия при создании привязывается к той базе данных, для которой она создается, поэтому база данных должна быть открыта. А при удалении теневой копии из БД удаляются и ссылки на нее.

Итак, нажмем кнопку " SQL ", открывающую окно Interactive SQL, и в окне запросов введем следующий оператор:

CREATE SHADOW 1 AUTO 'D:\DATABASES\First.shd';

Затем нажмем кнопку " Execute Query ", чтобы выполнить запрос. Вы можете открыть указанную папку Проводником или любым файловым менеджером, и убедиться, что файл с теневой копией создан. Чтобы полноценно связать shadow файл с базой данных и наполнить его данными, придется закрыть IBConsole, или хотя бы прервать контакт с базой данных ( disconnect ). Как только это случится, теневая копия наполнится данными, и будет иметь такой же размер, как основная БД. При следующем открытии базы и работе с ней все изменения также будут производиться и в теневой копии.

Удалить теневую копию можно также в Interactive SQL при подключенной БД командой

DROP SHADOW 1;

При этом в базе данных удаляются все ссылки на shadow копию, а файл с этой копией физически удаляется с диска.

Разберем синтаксис создания и удаления Shadow -копий.

CREATE SHADOW <номер> [AUTO | MANUAL] [CONDITIONAL]
'спецификация-файла' 
[LENGTH [=] <целое> [PAGE[S]]] [<вторичный-файл>];

Здесь:

<номер> - любое целое число, идентификатор shadow -копии.

[ AUTO ] - автоматический режим, устанавливается по умолчанию. Этот режим позволяет базе данных работать в случае, если теневая копия по каким-то причинам станет недоступной, или если недоступной станет рабочая база данных при доступной теневой копии. Если недоступной станет рабочая база данных, InterBase заменит ее теневой копией и восстановит соединение. В таком случае выводится окно с сообщением, чтобы проинформировать администратора о случившемся.

[ MANUAL ] - ручной режим. При выборе этого режима, если вдруг теневая копия становится недоступной, то доступ к базе данных прекращается. Чтобы возобновить доступ, администратору необходимо вручную удалить испорченную теневую копию, и создать новую.

[ CONDITIONAL ] - этот режим является дополнением к [ AUTO ], и подразумевает, что при разрушении базы данных InterBase автоматически заменит базу данных теневой копией и восстановит соединение. Но если при режиме [ AUTO ] администратору придется заново создавать новую теневую копию, то в случае [ CONDITIONAL ] InterBase сделает это сам. Режим AUTO CONDITIONAL является наиболее предпочтительным для создания бесперебойной работы системы.

'спецификация-файла' описывает адрес и имя файла теневой копии. По традиции принято таким копиям назначать расширение *.shd

[ LENGTH ] - необязательный параметр, который используется при создании многофайловой теневой копии. Атрибут <целое> - это целое число, указывающее размер первичного и вторичного файлов в страницах.

Синтаксис удаления теневой копии еще проще:

DROP SHADOW <номер>

Где номером является идентификатор shadow -копии. Как узнать этот номер, если мы создавали копию давным-давно, и уже его не помним? Давайте создадим еще одну CONDITIONAL -теневую копию:

CREATE SHADOW 3 CONDITIONAL 'd:\DataBases\first.shd';

Затем прервем соединение с базой данных, и вновь соединимся с ней, чтобы наполнить копию данными. Теперь выделим в IBConsole базу данных first и выберем команду меню "Database -> View Metadata". Откроется окно, показывающее, как создавалась БД:

Как видно из рисунка, в числе прочего указано и создание теневой копии вместе с ее адресом и идентификатором.

Создание многофайловой теневой копии имеет смысл, если размеры базы данных становятся огромными, по 2 и более гигабайта. Тогда может случиться, что на диске, выделенном под теневую копию, не хватит для нее места. В этом случае ее можно разбить на несколько частей, создавая каждую часть на своем диске. Пример создания многофайловой теневой копии (если у вас нет записывающих дисков D:, E: и F:, то можете просто указать другую папку на диске C:):

CREATE SHADOW 4 CONDITIONAL 'd:\DataBases\first1.shd' LENGTH 15000
FILE 'e:\DataBases\first2.shd' LENGTH 15000
FILE 'f:\DataBases\first3.shd';

В этом случае создастся три файла. Первый файл будет наполняться, пока его размер не достигнет 15 тысяч страниц БД, затем начнет наполняться второй файл теневой копии. Как только размер второго файла достигнет 15 тысяч страниц, начнет наполняться третий файл. Можете удалить теневую копию №4, она нам больше не нужна.

Утилита командной строки gfix

Эта утилита является одним из основных инструментов администратора БД. Утилита gfix позволяет:

Синтаксис утилиты очень простой:

gfix [параметры] <база данных>;

Все параметры утилиты приведены в следующей таблице:

Чистка sweep происходит в фоновом режиме и может выполняться параллельно работе пользователей. Этот способ более предпочтителен, чем чистка gbak при восстановлении БД. Утилита gbak не делает полной чистки, так как остаются версии удаленных записей и записей отмененных транзакций. Принудительную чистку можно сделать так:

gfix -sweep c:\databases\first.gdb -user sysdba -pa masterkey

Чистка базы данных происходит автоматически через определенное количество (по умолчанию 20 000) транзакций. Расчет интервала делается из старейшей транзакции, зарегистрированной в области TIP (Инвентарная страница транзакций), и из старейшей активной транзакции. Когда инвентарный номер старейшей активной транзакции окажется больше на указанный интервал, чем инвентарный номер старейшей зарегистрированной в TIP транзакции, произойдет автоматический запуск чистки. Изменить интервал на 10 000, например, можно так:

gfix -h 10000 c:\databases\first.gdb -user sysdba -pa masterkey

Если же вместо 10 000 указать 0, автоматическая чистка для данной БД вообще будет отменена. Как уже говорилось, чистка не требует монопольного доступа к базе данных, однако если БД очень большая, и много пользователей интенсивно с ней работают, чистка может заметно замедлить работу с БД. В этом случае, перед чисткой рекомендуется вначале отключить базу данных.

Отключение базы данных делается командой - shut с одним из трех дополнительных параметров. Чтобы безусловно отключить базу данных через 10 минут, выполните команду:

gfix -sh -force 600 c:\databases\first.gdb -user sysdba -pa masterkey

Однако такой радикальный способ рекомендуется использовать с осторожностью: пользователи, которые на этот момент продолжали работу с БД, потеряют результаты своей работы. Вначале вместо " -force " лучше попробовать более "мягкие" дополнительные параметры " -attach " или " -tran ".

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

gfix -o c:\databases\first.gdb -user sysdba -pa masterkey

Кэш (или буфер) - это оперативная память, выделяемая сервером для работы с базой данных. Операции в оперативной памяти происходят гораздо быстрее, чем если данные постоянно считываются с диска. Размер кэша указывается в страницах БД. Если размер страницы установлен 8192, то кэш в 5000 страниц займет примерно 40 мегабайт ОЗУ. По умолчанию, InterBase использует кэш в 75 страниц. Если сразу много пользователей одновременно обращаются к базе данных, может случиться, что серверу не хватит выделенной оперативной памяти. В этом случае он начнет работать с диском, что замедлит производительность БД. Изменить размер кэша для базы данных на 300 страниц можно так:

gfix -b 300 c:\databases\first.gdb -user sysdba -pa masterkey

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

c:\program files\borland\interbase\ibconfig

Это обычный текстовый файл, в котором все параметры закомментированы (первым символом идет "#"). Нужно снять комментарий, и установить новое значение нужного параметра. То есть, вместо

#DATABASE_CACHE_PAGES           75

указать

DATABASE_CACHE_PAGES           300

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

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

gfix -mo read_only  c:\databases\first.gdb -user sysdba -pa masterkey

Операции изменения режима занимают время! Не забудьте потом вернуть режим read_write, иначе пользователи не смогут вносить изменения в БД.

Режимы Forced Writes требуют особого пояснения. Forced Writes, или режим синхронного ввода, определяет, как будет происходить работа с БД. При включенном Forced Writes добавление новых записей, удаление старых, появление новых версий записей сразу же физически сохраняется на диске. При отключенном синхронном вводе сервер InterBase возлагает это на операционную систему: физическое сохранение изменений происходит позже - когда переполнится буфер, или когда ОС решит, что компьютер долго простаивает. Отключение Forced Writes следует делать лишь на очень надежных машинах, с обязательным источником бесперебойного питания ( UPS ). Ведь может случиться, что физической записи на диск не происходит целый день, а при сбое системы или отключении питания потеряются результаты всей работы! Отключенный режим немного увеличивает скорость работы с БД, однако данные становятся менее защищенными.

По умолчанию, все БД работают с включенным Forced Writes и отключать этот режим не рекомендуется. Если все же вы не удовлетворены производительностью БД, и при этом стопроцентно уверены в своем серверном ПК, можете попробовать отключить Forced Writes командой:

gfix -w async c:\databases\first.gdb -user sysdba -pa masterkey

Команда

gfix -v c:\databases\first.gdb -user sysdba -pa masterkey

выведет на экран все неназначенные страницы, которые являются мусором. Если на экран ничего не вышло, значит, таких страниц в БД нет.

Если база данных разрушилась, можно вместо нее активировать теневую копию командой

gfix - ac d:\databases\first.shd -user sysdba -pa masterkey

Рекомендации по ремонту поврежденных баз данных

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

gfix -mend -full -ignore <база данных> <пользователь> <пароль>

gbak -b -v -i <база данных> <резервная копия> <пользователь> <пароль>

gbak -create -v <резервная копия> <база данных> <пользователь> <пароль>

Как правило, такой порядок действий позволяет восстановить разрушенную БД. Если же этого не случилось, попробуйте использовать другие переключатели. Например, - inactive у утилиты gbak делает неактивными индексы, и если разрушены именно они, восстановление удастся. Параметр - one_at_a_time будет восстанавливать по одной записи за раз, что позволит восстановить целые таблицы, и пропустить поврежденные.

Если вы грамотно спроектируете вашу базу данных и организуете систематическое резервное копирование, то возможно, вам никогда и не придется прибегать к ремонту БД. Но знать, как это делается, необходимо каждому программисту и администратору баз данных.