EnInterBase 2007 Update Guide (перевод)
перевод IB2007UpdateGuide.pdf выполнен kdv, www.ibase.ru, 02.10.2007
все "примечания" в статье сделаны kdv.
публикация перевода документа вне www.ibase.ru запрещена
Содержание:
- Изменение лицензирования
- Новое в Service Pack 2
- Инкрементный бэкап
- Журналирование
- Изменения оптимизатора в IB 2007 SP2
Изменение лицензирования
Для упрощения регистрации и лицензирования InterBase 2007 использует тот же самый менеджер лицензий, что и другие продукты Borland (CodeGear).
В этой главе описан новый процесс регистрации лицензий InterBase
Изменения в процедуре установки
Следующие изменения произошли в отношении процедуры установки и регистрации InterBase 2007.
Сравнение
Вот список отличий между предыдущими и текущей версией:
- Вы больше не можете использовать текстовый файл лицензий, ib_license.dat, от предыдущих версий. Файл заменен регистрируемым серийным номером.
- IBConsole, iblicense и другие приложения, которые зависели от InterBase License API (iblicense.dll) устарели и не используются для управления лицензиями в InterBase 2007. Тем не менее, IBConsole остается частью дистрибутива, и поддерживает управление лицензиями для предыдущих версий. Используйте новую программу License Manager для управления лицензиями InterBase 2007. Обратите внимание, что вы должны использовать команду File | Save после ввода серийного номера в License Manager. Иначе 15-дневный период действия лицензии без регистрации не будет работать.
- Библиотека управления лицензиями и регистрацией поменяла свое название с libborland_lm.{dll, so} на sanctuarylib.{dll, so}
- При установке только клиентской части InterBase (Client Only) вам не нужно устанавливать ib_license.dat для возможности работы по сети. Лицензия на клиентской части больше не нужна.
Установка InterBase 2007
В процессе установки (по ее завершении) появится программа регистрации, запрашивающая серийный номер и ключ лицензии.
Регистрация
После установки InterBase 2007 вам нужно ввести серийный номер и ключ, полученные от Borland перед первым запуском сервера.
Вы можете зарегистрироваться в онлайн при помощи инсталлятора, или оффлайн путем запуска отдельного менеджера лицензий (LicenseManager.exe).
После того как вы зарегистрировали свою копию InterBase 2007, вы обнаружите файл borland.loc в подкаталоге license каталога установки InterBase. При старте, если сервер не нашел правильную регистрационную информацию, он сообщит об ошибке в лог-файл (interbase.log).
Если вы не завершите процесс регистрации, InterBase 2007 будет функционировать как пробная версия в течение 15-ти дней. Если вы не завершите решистрацию в течение этого времени, сервер перестанет работать.
Новое в Service Pack 2
Совместимость клиента и сервера
Клиентская часть IB 2007 SP2 содержит исправления ошибок при подсоединении к предыдущим версиям InterBase. Рекомендуется обновить клиентскую часть до SP2 на всех компьютерах. Для локального доступа к базам данных версия сервера и клиента должны быть идентичны. Новая клиентская библиотека позволяет соединяться с серверами InterBase предыдущих версий, однако сертифицирована работа только с серверами версий 2007 и 2007 SP2. Для соединения с серверами предыдущих версий используйте соответствующие библиотеки. Например, для соединения с IB 7.5 нужна клиентская библиотека от 7.5, и так далее.
Новая функциональность и изменения
В Service Pack 2 (билд 8.1.0.253) появилась новая функциональность:
- Преаллокирование журнала
- параметры URL JDBC-драйвера
- Forced Write по умолчанию ON
- Преаллокирование файла базы данных
- таблица сортировки PT_BR для бразильского набора символов
- Улучшения оптимизатора
- Дескрипторы UDF
Инкрементный бэкап
Возможность создания инкрементных бэкапов (также называемых online dump) позволяет вам эффективно выполнять резервное копирование баз данных.
Утилита gbak (используемая в предыдущих версиях для создания полных резервных копий базы данных и их восстановления) считывает все записи всех таблиц базы данных под управлением транзакции и записывает их в файл. Восстановление базы данных из такого файла реконструирует базу данных с нуля. Такое копирование-восстановление имеет много полезных побочных эффектов, как уплотнение страниц данных и сброс счетчика новых транзакций.
Однако, такой метод резервного копирования занимает длительное время для больших баз данных, и может занимать еще больше времени при сильной загрузке сервера. Открываемая gbak транзакция snapshot также может приводить к накоплению версий записей.
Инкрементный бэкап (online dump) - это механизм физического копирования страниц базы данных, при котором копия базы данных является целостной.
Вы можете использовать инкрементный бэкап как базу, на которой может быть выполнена резервная копия при помощи gbak. Для этого достаточно переписать online dump на другой компьютер и на нем выполнить gbak. Это также позволит вам выполнить проверку базы данных, т.к. проверка требует монопольного доступа, что может быть неприемлемо для промышленной базы данных.
Дополнительно, данная функциональность позволяет вам делать инкрементные файлы, которые содержат только измененные страницы с момента последнего полного инкрементного бэкапа.
замечание: данная функциональность доступна только для баз данных формата ODS 12.
Создание инкрементного бэкапа
Поддержка инкрементного бэкапа (online dump) была добавлена в утилиту gbak посредством расширения database parameter block (DPB)
(DPB документирован в этом разделе, поэтому если вы являетесь производителем сторонних инструментов, вы можете добавить эту функциональность в ваши программы)
У gbak есть 2 главных опции
gbak {-b} {options} - создать резервную копию базы данных
gbak {-c | -r} {options} - восстановить резервную копию базы данных
замечание: опции -c и -r являются вариантами одного и того же действия - создания БД из резервной копии. В случае -c, если база данных с именем эквивалентным восстанавливаемой, существует, gbak выдаст ошибку. В случае -r оригинальный файл базы данных будет переписан новым файлом. Никогда не используйте ключ -r, в противном случае вы можете остаться без базы данных, если восстановление из бэкапа по каким-либо причинам будет неуспешным.
Инкрементный бэкап добавляет третью опцию gbak:
gbak -d {-ov} dbname file [size] add_file1 [size1] add_file2 [size2] ...
Первый файл (file) является основным файлом дампа. Если указаны дополнительные файлы (add_file), то они добавляются к набору инкрементного бэкапа
[E:/tpc_c] gbak -d tpc_c.gdb tpc_c.gdmp tpc_c.gdmp.1 gbak: WARNING: Dumped 46270 pages of a total 46270 database pages gbak: WARNING: Dumped 1 pages to page appendix file
[E:/tpc_c] gbak -d tpc_c.gdb tpc_c.gdmp tpc_c.gdmp.1 gbak: ERROR: I/O error for file "E:\TPC_C\TPC_C.GDMP.1" gbak: ERROR: Error while trying to create file gbak: ERROR: The file exists. gbak: Exiting before completion due to errors
[E:/tpc_c] gbak -d tpc_c.gdb tpc_c.gdmp tpc_c.gdmp.2 gbak: WARNING: Dumped 2 pages of a total 46270 database pages gbak: WARNING: Dumped 0 pages to page appendix file
В примере выше, файл tpc_c.gdmp.1 добавляется к полному дампу.
Повторное выполнение приводит к ошибке, т.к. файл tpc_c.gdmp.1 уже существует. Последняя команда добавляет новый файл tpc_c.gdmp.2, в который записываются страницы, измененные в базе данных с момента предыдущего инкрементного бэкапа.
примечание: в организации "множества" файлов дампа нет никакой явной необходимости. То есть можно делать многофайловый дамп, но при этом нужно обязательно указывать размер каждого файла. Можно не указывать размер, и с каждым новым обновлением дампа добавлять новый файл (как в примере выше) - тогда каждое новое обновление будет находиться в текущем файле, однако дамп будет представлять собой многофайловую БД, и по частям такие файлы использовать нельзя. Например, после выполнения примера выше статистика по tpc_c.gdmp покажет следующее:
gstat -h tpc_c.gdmp ... Database file sequence: File j:\tpc_c.gdmp continues as file j:\tpc_c.gdmp.1 File j:\tpc_c.gdmp.1 continues as file j:\tpc_c.gdmp.2 File j:\tpc_c.gdmp.2 is the last file
Файлы инкрементного бэкапа могут быть как на компьютере сервера, так и на удаленном компьютере, который доступен серверу InterBase для записи файлов. Это значит, что при создании дампа запись в файл производится сервером InterBase, а не утилитой gbak. В то время как файл дампа может быть как на локальном так и на сетевом диске, файл page appendix всегда находится только на локальном диске.
Файл page appendix представляет собой некое подобие многоверсионности InterBase, когда предыдущая версия записи сохраняется, а измененная версия записывается отдельно. Файл page appendix позволяет сохранять изменяемые в момент процедуры dump страницы. Это временный файл, который удаляется при успешном завершении gbak -d.
примечание: инкрементный бэкап является инкрементным только в том смысле, что первый раз дамп производится полным копированием файла БД, а последующие выполнения команды gbak -d приводят к поиску измененных в БД страниц и записи в дамп только этих страниц. При этом всегда происходит полное чтение всего файла исходной БД (но никакого "сравнения" между БД и файлом дампа не производится. В дамп записываются только измененные с момента предыдущего дампа страницы). Даже если вы используете "многофайловый" онлайновый дамп, вы не можете "восстановить" базу из дампа используя только части дампа. То есть, дамп является всегда полной и целостной копией файла БД, независимо от того, он представляет собой один файл или несколько.
Параметр [size] является необязательным и указывает максимальный размер файла в страницах, используя размер страницы базы данных. Если параметр [size] не указан, то размер файла дампа будет определяться размером файла базы данных.
Если вы выполните команду gbak -d еще раз, на существующем файле дампа, то будет создан инкрементный дамп.
[E:/tpc_c] gbak -d tpc_c.gdb tpc_c.gdmp gbak: WARNING: Dumped 46270 pages of a total 46270 database pages gbak: WARNING: Dumped 23 pages to page appendix file // произошел полный дамп - 46270 страниц базы данных. за время выполнения дампа // работа пользователей привела к изменению 23 страниц [E:/tpc_c] gbak -d tpc_c.gdb tpc_c.gdmp gbak: WARNING: Dumped 2 pages of a total 46270 database pages gbak: WARNING: Dumped 0 pages to page appendix file // произошел инкрементный дамп - обновлено только 2 страницы базы данных. за время выполнения дампа // пользователи не работали, в page appenix file не было сохранено ни одной страницы
Эта команда обновляет существующий дамп теми страницами, которые изменились с момента последнего дампа. Если операция полного дампа не завершилась из-за ошибки, то такой файл дампа будет удален. Если InterBase не может удалить такие файлы, то их надо удалить вручную.
Перезапись инкрементного бэкапа
Ключ -ov удаляет текущий набор файлов online dump и инициирует создание полной копии БД.
// делаем обычное обновление дампа - обновляется только 3 страницы (2+1) [E:/tpc_c] gbak -d tpc_c.gdb tpc_c.gdmp gbak: WARNING: Dumped 2 pages of a total 46270 database pages gbak: WARNING: Dumped 1 pages to page appendix file
// делаем обновление дампа с -ov - создается новый дамп (копируется вся БД и журнал) [E:/tpc_c] gbak -d -ov tpc_c.gdb tpc_c.gdmp gbak: WARNING: Dumped 46270 pages of a total 46270 database pages gbak: WARNING: Dumped 7 pages to page appendix file
Файлы онлайнового дампа макрируются как read-only база данных InterBase. Это означает, что такая база данных может быть использована приложениями, которые осуществляют только чтение из БД. Неизвестно, как будут себя вести такие приложения в тот момент, когда файлы дампа обновляются. Если онлайновый дамп конвертируется в read-write БД, то он перестает быть "онлайновым дампом" и становится обычной базой данных. Попытка произвести обновление такого дампа будет неуспешной.
// переводим дамп в режим read-write (обычная БД) [E:/tpc_c] gfix tpc_c.gdmp -mode read_write // пытаемся обновить дамп [E:/tpc_c] gbak -d tpc_c.gdb tpc_c.gdmp gbak: ERROR: online dump failure: dump file has no dump timestamp gbak: Exiting before completion due to errors // переводим дамп обратно в режим read-only [E:/tpc_c] gfix tpc_c.gdmp -mode read_only // пытаемся обновить дамп [E:/tpc_c] gbak -d tpc_c.gdb tpc_c.gdmp gbak: ERROR: online dump failure: dump file has no dump timestamp gbak: Exiting before completion due to errors
Нет такой операции, как "восстановление дампа" (аналогично gbak -c). Онлайновый дамп может быть превращен в обычную read-write БД, как было показано выше. Если текущее размещение дампа не совсем удобно для работы с БД, то можно выполнить online dump над дампом (как над обычной БД) и разместить новый дамп в нужном месте. Эту особенность можно использовать для "копирования" многофайловых баз данных, сохраняя корректными ссылки на вторичные файлы.
Проверка при помощи gfix -v также может быть выполнена над дампом, как надо обычной БД. GFIX производит дополнительную проверку страниц БД, чтобы в них не было временных меток более новых чем метка самого дампа. Временная метка дампа представляет собой дату и время последнего полного успешного инкрементного дампа.
[E:/tpc_c] gfix -v -n tpc_c.gdmp
Summary of validation errors
Number of database page errors : 1
and in the InterBase log file:.
IBSMP (Server) Sat Jun 24 14:41:36 2006
Database: E:\TPC_C\TPC_C.GDMP
Page 155 has timestamp 1151170444 greater than dump timestamp 1151170438
Изменение метки времени
Вывод gstat -h расширен для того чтобы показать временные метки дампа. Обратите внимание что Creation date - это дата создания файла БД, а не дампа.
Database "tpc_c.gdmp" Database header page information: Flags 0 Checksum 12345 Write timestamp Jun 28, 2006 19:57:41 Page size 4096 ODS version 12.0 Oldest transaction 72 Oldest active 73 Oldest snapshot 73 Next transaction 74 Sequence number 0 Next attachment ID 0 Implementation ID 16 Shadow count 0 Page buffers 0 Next header page 0 Clumplet End 102 Database dialect 3 Creation date Jun 25, 2006 13:22:10 Online dump timestamp Jun 28, 2006 19:59:16 Attributes read only Variable header data: Dump file length: 20000 *END*
В API вы можете инициировать выполнение дампа путем передачи специальной информации в вызов isc_attach_database. В следующей таблице перечислены имена и значения констант database parameter block (dpb), которые можно использовать для управления данной функциональностью.
| Имя параметра | Назначение | Длина | Значение |
| isc_dpb_online_dump | директива на создание онлайн дампа | 1 | 0 или 1 |
| isc_dpb_old_overwrite | эквивалент ключа -ov утилиты gbak (см. выше) - перезаписывает существующий дамп. | 1 | 0 или 1 |
| isc_dpb_old_file_name | имя файла дампа | длина строки | строка - имя файла дампа |
| isc_dpb_old_file_size | количество страниц файла дампа | 1, 2 или 4 | длина дампа в виде числа страниц |
Успешное выполнение дампа возвращает статус-вектор:
status [0] = isc_arg_gds status [1] = isc_arg_success status [2] = isc_arg_warning status [3] = isc_old_dump_stats status [4] = isc_arg_number status [5] = <no. of dumped pages> status [6] = isc_arg_number status [7] = <total no. of DB pages> status [8] = isc_arg_gds status [9] = isc_old_appendix_stats status [10] = isc_arg_number status [11] = <no. pages written to appendix> status [12] = isc_arg_end
Файл Page Appendix
Когда выполняется online dump, сервер не осуществляет запись в базу данных. Вместо этого изменяемые страницы записываются в так называемый Page Appendix File - временный файл с именем ib_dump_. Каждая измененная с момента начала online dump страница базы данных записывается в этот файл не более одного раза.
Для больших баз данных с высокой интенсивностью изменений, page appendix file за время выполнения online dump может получиться большим. Соответственно, в temp должно быть доступно соответствующее свободное пространство, иначе произойдет ошибка. Информация, возвращающая gbak о размере page appendix file (в страницах) может помочь в определении необходимого места в temp.
примечание: со слов Чарли каро это работает следующим образом::
- сервер при выполнении дампа копирует страницы из БД в дамп, подряд
- если страница модифицируется во время дампа, ее старая копия пишется в page appendix file. Страница записывается один раз, т.е. необходимость сохранения старой копии определяется по timestamp страницы. Таким образом в page appendix файл записывается только оригинальная версия изменяемой страницы, существовавшей на момент старта dump
- по мере того, как дамп копирует страницы, если он обнаруживает измененную страницу (проверка timestamp), то он ее "пропускает" (записывает пустую страницу).
- по окончании чтения БД дамп переносит все сохраненные старые страницы из page appendix file в дамп. Результатом является копия файла БД на момент старта dump.
таким образом, нехватка места для page appendix file не может "повредить" файл базы данных или привести к остановке ее работы. Одновременно, поскольку сохраненные изменения переносятся "блоком" из page appendix file, это означает, что во время выполнения инкрементного дампа по сети нагрузка на сеть будет только в момент переноса page appendix file.
Советы по инкрементному бэкапу
- Поскольку дамп является результатом физического копирования страниц БД, дамп не является переносимым между разными аппаратными платформами (например, Intel<->Sparc). Вместо дампа нужно использовать утилиту gbak (с ключами -b -t).
- Одновременно можно создавать несколько дампов одной и той же базы данных, однако это не рекомендуется из соображений производительности.
- Выполнение онлайнового дампа всегда приводит к чтению всей базы данных
- Функциональность онлайнового дампа используется InterBase во время архивации журнала (create journal archive)
- Выполнение онлайнового дампа может быть прервано при помощи InterBase Performace Monitor, IBConsole, через временные системные таблицы (tmp$) или терминированием процесса gbak.
- Внешние таблицы (external table) не копируются при онлайновом дампе
- Внешние таблицы могут быть недоступны, если онлайновый дамп используется в качестве базы данных только на чтение. Если пути к внешним файлам не могут быть доступны из места расположения онлайнового дампа, то не существует другого способа модифицировать эти пути, кроме как перевести дамп в режим read-write базы данных. Соответственно, после этой операции обновлять такой онлайновый дамп изменениями оригинальной БД далее не представляется возможным.
Журналирование
Этот раздел описывает подсистему журналирования и синтаксис DDL для создания, изменения и удаления файлов журнала и архивов журнала. Журналирование баз данных делает управление очень большими базами данных (VLDB) более удобным и обеспечивает средства восстановления в случае сбоев.
Обратите внимание, что журналирование доступно только в серверной редакции InterBase 2007, и не может быть использовано в Desktop Edition.
Подсистема журналирования
Следующие критерии должны быть определены для оптимального конфигурирования журнала:
- скорость ввода-вывода устройства, на котором создается журнал
- скорость создания новых файлов журнала
- легкость конфигурирования и характеристики оборудования
Для получения высокой производительности рекомендуется чтобы база данных и файлы журнала находились на разных физических устройствах (дисках). По умолчанию команда CREATE JOURNAL создает файлы журнала там же, где находится база данных. Это не является рекомендуемой практикой, но может быть полезно когда большая часть базы данных помещается в оперативную память сервера. В этом случае чтение будет идти из кэша операционной системы, а запись - только при сбросе журнала в БД, что может быть сконфигурировано на более частые обновления.
Оператор CREATE JOURNAL приводит к переключению всех операций с БД на асинхронные (БД переключается в режим Forced Writes = OFF). Ввод-вывод файлов журнала остается синхронным, и это не может быть изменено. Все изменения, произведенные транзакциями, записываются в журнал до завершения транзакций. Это гарантирует свойства ACID транзакций (Атомарность, Целостность, Изолированность и Стабильность).
Использование асинхронного ввода-вывода для базы данных позволяет операционной системе оптимизировать ввод-вывод, например, записывать несколько измененных страниц в один "прием". Ввод-вывод журнала организован при помощи стратегии "careful write" (корректная запись). Это дает возможность переносить страницы из журнала в базу данных в любом порядке, после того как изменения были помещены в журнал.
Во время переноса страниц из журнала в базу данных (checkpoint) все измененные и оставшиеся в кэше страницы выгружаются на диск перед тем как checkpoint считается успешно завершенным. Вы можете включить Forced Writes = ON для базы данных, и это исключит необходимость выгрузки страниц на диск перед завершением checkpoint.
Архивы журнала
Архив журнала это набор каталогов, где находится архивная копия файлов журнала конкретной базы данных. В целях защиты от сбоев, архив журнала должен быть всегда на сервере или на отдельном от сервера БД файл-сервере. Текущее ограничение - все файлы журнала должны быть в одном каталоге.
Существует три типа архива журналов: Database Archive - архив базы данных, Journal Archive - архив журнала и Recovery (или online dump).
Нет необходимости в том, чтобы InterBase работал на той же машине, где находятся архивы. Поскольку архивы журналов сохраняются на удаленный файл-сервер, в качестве файл-сервера можно использовать любую платформу. Например, сервер БД под Linux может использовать NFS, смонтированную на файл-сервере Solaris или Netware.
Включение журналирования
В этом разделе показаны операторы DDL для включения журналирования базы данных.
Создание файлов журнала
CREATE JOURNAL [<journal-file-specification>] [LENGTH <number-of-pages> [PAGES]] [CHECKPOINT LENGTH <number-of-pages> [PAGES]] [CHECKPOINT INTERVAL <number-of-seconds> [SECONDS]] [PAGE SIZE <number-of-bytes> [BYTES]] [PAGE CACHE <number-of-buffers> [BUFFERS]] [[NO] TIMESTAMP NAME];
<journal-file-specification> - строка в кавычках, содержащая полный путь и базовое имя файла журнала. Имя файла журнала используется как шаблон для файлов журнала.
Параметр LENGTH определяет количество страниц отдельного "сегмента" журнала. Т.е. количество страниц, которые будут записаны в журнал, прежде чем запись будет продолжена в другом файле журнала. Один файл журнала не может быть больше 2-х гигабайт.
Остальные параметры управляют конфигурацией журналирования БД:
| Параметр | Описание |
| CHECKPOINT LENGTH | Определяет количество страниц журнала, после которых запись новых страниц идет в новый файл журнала. При этом "старый" файл журнала записывается в БД. |
| CHEKPOINT INTERVAL | Определяет время в секундах между checkpoint замечание: Если указаны оба параметра - CHECKPOINT LENGTH и CHEKPOINT INTERVAL, то к checkpoint будет приводить то событие, которое наступит раньше. |
| PAGE SIZE | Определяет размер страницы журнала, в байтах. Размер страницы журнала должен быть как минимум в 2 раза больше чем размер страницы базы данных. Если страница журнала указывается меньшего размера, то она будет приведена к 2-кратному размеру страницы БД, вместе с выдачей предупреждения. |
| PAGE CACHE | Определяет количество страниц, которые будут выделены для кэша журнала. Размер памяти, выделяемый под такой кэш, определяется умножением PAGE CACHE на PAGE SIZE. |
| [NO] TIMESTAMP NAME | Определяет добавление метки времени к файлу журнала. Если включено (по умолчанию), то к имени файла будет добавлена строка вида: <YYYY>_<MM>_DD>T<hh>_<mm>_ssZ.<sequence-number>.journal |
| [NO] PREALLOCATE | размер преаллокирования файлов журнала. |
Все параметры оператора CREATE JOURNAL не являются обязательными. Значения по умолчанию приведены в следующей таблице:
| Параметр | Значение по умолчанию |
| <journal-file-spec> | полное имя базе данных путь к ней |
| LENGTH | 500 страниц |
| CHECKPOINT LENGTH | 500 страниц |
| CHECKPOINT INTERVAL | 0 секунд (выключено) |
| PAGE SIZE | размер страницы БД * 2 |
| PAGE CACHE | 100 страниц |
| TIMESTAMP NAME | включено |
Отключение файлов журнала
Оператор DROP JOURNAL отключит журналирование и удалит все файлы журнала. Эта операция не будет удалять файлы архива журнала, но отключит их обслуживание (обновление). Удаление журнала требует монопольного доступа к базе данных. Синтаксис оператора следующий:
DROP JOURNAL
Архивы журнала
Назначение архивов журнала - обеспечить возможность восстановления базы данных на произвольный (сохраненный) момент времени.
Архивация журналов не является автоматическим копированием журнальных файлов или выполнением online dump. Нет явного ddl, который бы позволял указать, когда нужно помещать очередную копию журналов в архив. Архивирование журналов эквивалентно обычной операции backup.
Команда создания архива журналов определяет каталог, где будут храниться архивы. Создание архивов журнала не требует монопольного доступа к базе данных. Важно помнить, что создание архива журналов автоматически выполняет создание копии базы данных (online dump) в каталоге архива журналов.
Команда DDL для создания архива журналов:
CREATE JOURNAL ARCHIVE [<journal archive directory>]
где <journal archive directory> - имя диска и каталога, где будет размещаться архив.
Обратите внимание, что данная команда не создает сам каталог. Команда вернет ошибку, если указанный каталог не существует или не доступен.
Спецификация каталога для архива журналов должна соответствовать требованиям как для копирования файлов. Например, если каталог для архива это символическая ссылка UNIX, то вам нужно использовать именно символическую ссылку, а не оригинальное имя каталога. Также каталог может быть указан в спецификации UNC, если файл в такой спецификации может быть открыт операционной системой.
Если каталог архивов не указан, то каталог с журналами базы данных автоматически становится архивом. Обычно, когда происходит контрольная точка переноса страниц из журнала в базу данных, файл журнала переименовывается чтобы использовать занятое дисковое пространство под новый журнал. В случае оператора
CREATE JOURNAL ARCHIVE;
файлы журнала по мере их использования не будут переименовываться или удаляться во время checkpoint, а будут оставаться на диске и использоваться как архивные. В данном случае никакого копирования файлов не происходит.
Удаление архива журналов
Команда DROP JOURNAL ARCHIVE прекращает возможность архивирования журналов для базы данных. Это также приводит к удалению всех online dump и копий журналов в каталоге архива. Каталог архива при этом не удаляется.
Отключение архива журналов не выключает журналирование. База данных будет продолжать использовать протокол упреждающей записи для сохранения изменений в журналах. Если требуется отключить журналирование, то нужно выполнить оператор DROP JOURNAL.
Управление архивом журналов
Архивированные online dump и журналы представляют собой точки, относительно которых может быть восстановлена база данных. Журналы из архива могут быть применены к соответствующему online dump так же, как это происходит при автоматическом восстановлении БД из обычных журналов. Опционально может быть указана метка времени, до которой необходимо применять изменения, накопленные в архивированных журналах.
Восстановление
При восстановлении базы данных из журнала в ней будет отключено журналирование. Это сделано для того, чтобы предотвратить использование восстановленной базой данных файлов журнала, используемых текущей базой данных.
Обычно восстановление используется когда оригинальная база данных повреждена или недоступна при аппаратных сбоях. При этом, возможно восстановление базы данных из журнала как на этом, так и на другом компьютере. Если для такой базы данных требуется журналирование и архивы журналов, их необходимо включить для восстановленной базы.
Команды архивации и восстановления
Для архивирования и восстановления используется утилита gbak.
Архивация БД:
gbak -archive_database <dbname>
Обратите внимание, что в отличие от online dump каждая такая команда будет заново делать online dump базы данных, и помечать его соответствующей временной меткой. По управлению размером архива смотрите дальше эту статью.
Архивация файлов журнала:
gbak -archive_journals <dbname>
Восстановление базы данных из архива:
gbak -archive_recover [-until <timestamp>] <archive_dbname> <local_dbname>
Если вы не используете команду -until, то процедура восстановления затронет все имеющиеся файлы журналов. При выполнении этой команды не из командной строки слова 'until timestamp' нужно обрамлять кавычками, чтобы части даты и времени не были восприняты как отдельные аргументы. В качестве timestamp может использоваться дата в формате, принятом для сервера (sql), также как и литералы now и today.
Если это возможно, процесс восстановления попытается использовать и обычные файлы журнала, которые не были архивированы. В этом случае, база данных будет восстановлена вплоть до самой "свежей" committed транзакции оригинальной базы данных.
примечание: это означает, что восстановление из журнала можно делать на ходу, в целях "тиражирования" БД. Например, для БД регулярно сохраняется архив журнала. И, он периодически восстанавливается из архива в другую БД на этом же или другом компьютере.
Сценарий.
- создаем журнал
- создаем архив журнала
- во время работы журнал наполняется и периодически переносится в базу данных (автоматически)
- архивируем базу данных. в журнал попадает дамп базы данных. Это будет точкой отсчета, откуда будут восстанавливаться основные данные плюс журнал.
- по мере работы обычный журнал переносится в БД по checkpoint
- теперь архивируем журнал. в этот момент будут архивированы только журналы, которые были записаны в базу данных с того момента, как мы произвели дамп базы (путем первой архивации журнала)
- если требуется восстановить БД ( в другой файл), выполняем команду gbak -archive_recover <дамп> <база>. Процесс будет выполняться непрерывно, автоматически, т.е. по мере обновления базы и переноса данных в архив, они будут вычитываться из архива и обновлять новую БД. Если требуется восстановить только до определенного момента - укажите параметр -until timestamp с нужным значением даты и времени.
В целом такой механизм почти не отличается от аналогичного тиражирования базы данных при помощи online dump.
Управление размером архива
По умолчанию архив будет увеличиваться бесконечно, по мере перемещения текущих журналов в архив. Таким образом, общий объем архива со временем может стать очень большим (дамп плюс все журналы за время работы БД).
Для чистки ненужных архивов журнала используйте утилиту gfix. С увеличением числа архивных файлов журнала также будет увеличиваться время, необходимое на восстановление такой БД. Поэтому рекомендуется периодически создавать новые дампы базы данных в архиве. В определенный момент вы можете решить, что старые дампы БД и архивы журналов для них вам больше не нужны, поскольку есть более новые дампы и архивы журналов для них.
Номер архива и чистка архивов
Все элементы архива нумеруются в соответствии с порядком, в котором они помещались в архив.
Для чистки архива нужно использовать gfix:
gfix -archive_sweep [-force] <archive_sequence_no>
Если по какой-либо причине элемент архива не может быть удален, чистка будет остановлена и вернет ошибку. В некоторых случаях успешное выполнение команды будет невозможным. Например, если архив удален вручную, чистка всегда будет давать сообщение об ошибке, потому что не будет находить нужный для удаления файл. Опция -force в таких случаях игнорирует ошибку и позволяет продолжить чистку.
Ключ -force также приводит к тому, что возникающие ошибки будут сохраняться в interbase.log, вместо возврата ошибки gfix.
Команда для указания максимального числа дампов в архиве:
gfix -archive_dumps <number>
Как только количество дампов будет больше указанного номера (<number>), все ненужные старые элементы архива будут автоматически удалены.
примечание: например, если установить количество дампов в 7, и делать gbak -archive_database ежедневно, то в каталоге будет 7 архивов (дампов и журналов БД) за последнюю неделю. Разумеется, следует учитывать размер такого архива, т.к. он будет более чем в 7 раз больше оригинальной базы данных.
Иногда такие элементы не могут быть удалены. Например, дамп БД может зависеть от старого файла журнала. В этом случае, InterBase автоматически изменит <number> на минимально допустимый, чтобы зависимость не была нарушена.
Отслеживание состояния архива
Для отслеживания состояния архива в ODS 12 введена новая системная таблица, RDB$JOURNAL_ARCHIVES. Вышеупомянутые команды gbak и gfix используют эту таблицу для определения целевых элементов архива.
| Столбец | Тип | Длина | Описание |
| RDB$ARCHIVE_NAME | VARCHAR | 1024 | Имя элемента архива |
| RDB$ARCHIVE_TYPE | CHAR | 1 | Тип архива. 'D' - дамп, 'S' - вторичный файл дампа. 'J' - файл журнала |
| RDB$ARCHIVE_LENGTH | INT64 | 8 | Размер элемента архива в байтах |
| RDB$ARCHIVE_SEQUENCE | INTEGER | 4 | Последовательный номер элемента |
| RDB$ARCHIVE_TIMESTAMP | TIMESTAMP | 8 | Дата и время добавления элемента в архив |
| RDB$DEPENDED_ON_SEQUENCE | INTEGER | 4 | Номер элемента, от которого зависит этот элемент архива. Для 'S' это номер элемента типа 'D', для 'D' это номер элемента 'J', с которого нужно начинать восстановление |
| RDB$DEPENDED_ON_TIMESTAMP | TIMESTAMP | 8 | То же, что и выше, только метка времени элемента архива, от которого зависит этот элемент. |
Ограничения журнала и архивов
- Архивы не переносимы между различными аппаратными платформами. Например, архив, сделанный в Windows не может быть использован для восстановления БД на Unix. Вместо этого нужно использовать обычный транспортируемый backup/restore.
- Файлы журнала и файлы архива журналов могут находиться только в одном каталоге. Количество архивируемых элементов зависит только от допустимого количества файлов в каталоге в конкретной файловой системе.
- Архивируются только полные дампы БД. В частности, невозможно архивировать инкрементные дампы.
- Журналирование должно быть включено перед тем как конфигурируется архивирование журналов
примечание: также ограничением системы журналов и архива журналов можно считать невозможность четкого задания интервалов журналирования или архивирования, то есть невозможность восстановления базы из журнала на конкретный момент времени (заданный вами, а не меткой времени в имени дампа или архива журнала) . Частота создания журналов или архивов определяется а) числом страниц одного файла журнала; б) интервалом checkpoint, если он задан; г) интенсивностью модификации страниц базы данных.
Например, если выбрать большие файлы журнала, то при малой интенсивности изменения БД они будут накапливать очень много изменений, и между checkpoint будут большие интервалы времени, что может быть нежелательно в случае необходимости оперативного восстановления максимально целостного ближайшего состояния базы данных. Если наоборот, при большой интенсивности изменений выбрать малый интервал checkpoint или небольшой размер журнала, то журналов будет много, что скажется на производительности.
Кроме того, регулярность появления файлов журнала или архивов журнала зависит от регулярности работы с БД. Обычно работа с БД является нерегулярной как в течение недели, так и в течение дня.
Советы по организации журнала
Пример, рассматриваемый далее, поможет вам организовать журналирование наилучшим образом. Этот пример разработан для минимальной конфигурации, с целью уменьшения размера журналов и уменьшения вероятности ожиданий в кэше журнала. Умолчательные значения параметров журнала разработаны с тем, чтобы не перегружать слабые компьютеры. Это то же самое, что и умолчательный размер кэша в 2048 страниц.
Давайте создадим журнал следующим образом:
CREATE JOURNAL 'e:\database\test' LENGTH 65000 CHECKPOINT LENGTH 10000 PAGE CACHE 2500
Если размер страницы БД равен 8к, то параметр PAGE SIZE журнала будет автоматически принят как 16к (2*8к).
Соответственно, параметр LENGTH (65000) приведет к созданию файлов журнала размером 1 гигабайт (65000 *16к). Значение LENGTH по умолчанию (500) приведет к тому, что файлы журнала будут иметь размер 8 мегабайт, то есть, они будут создаваться достаточно часто, и результатом будет падение производительности. Использование большего LENGTH (65000) сделает создание новых файлов журнала примерно в 130 раз более редким (65000/500).
Параметр CHECKPOINT LENGTH равный 10000 означает, что контрольная точка переноса страниц из журнала в БД будет происходить через каждые 160 мегабайт (10000 * 16k) накопленных изменений страниц. Умолчательный CHEKPOINT LENGTH равен 500, что означает что перенос данных будет происходить каждые 8 мегабайт. Значение CHECKPOINT LENGTH выбирается индивидуально, на ваш вкус. Это максимальное число страниц, которые будут перенесены в базу данных в случае сбоя системы. Вы можете ожидать скорость переноса на уровне 1-2 мегабайта в секунду (зависит от оборудования), соответственно, для 160 мегабайт это около 2-х минут.
Параметр PAGE CACHE может быть увеличен для сокращения времени ожидания кэша журнала. В процессе работы сервер записывает определенное количество страниц из кэша на диск (в журнал).
Например, сервер записывает 500 страниц из кэша журнала на диск. Размер в 2500 страниц оставит свободными 2000 страниц для кэширования текущих изменений. Умолчательный размер PAGE CACHE, равный 100, может быть недостаточным, и сервер может делать паузы на время освобождения буфера.
Наконец, использование кэша устройств SAN будет всегда ухудшать производительность при включении журналирования. Это происходит потому, что при включенном журнале информация будет сохраняться дважды: один раз в файлы журнала, и второй раз в файлы БД, плюс дополнительная загрузка процессора на управление кэшем журнала.
Даже для подключаемых напрямую устройств хранения (жесткие диски) необходимо обращать внимание на кэширование записи на диск. На новых системах кэширование записи обычно включено по умолчанию. Это означает что синхронная запись в базу данных или журнал не синхронизирована с записью на диск. Невозможно гарантировать целостность при сбоях, если дисковое кэширование записи включено, или у устройства хранения нет питания от батарей.
Нормальную производительность при включенном журналировании InterBase можно получить только если запись на диск происходит без кэширования.
Преаллокирование журнала
Чтобы предотвратить вероятность сбоя системы журналирования из-за нехватки свободного места нужно использовать преаллокирование журнала.
Замечание: если журналы разных баз данных находятся на одном диске, то будет не вполне очевидно, сколько дискового места в сумме потребуется для этих журналов.
Поскольку журнал обновляется в режиме синхронного ввода-вывода, изменение файла журнала вызывает изменения в файловой системе. Это действие вызывает перемещение головок диска от файла журнала и при последующей записи требует их репозиционирования. Чтобы избежать этого, в оператор CREATE JOURNAL добавлен параметр PREALLOCATE
Пример
... [[NO] PREALLOCATE int [PAGES]]
Общий размер будет равен int*journal_page_size.
Преаллокирование базы данных
Начиная с InterBase 2007 Service Pack 2 оператор CREATE DATABASE расширен возможностью указания размера создаваемой базы данных. Указание размера приводит к аллокированию файла БД на диске в соответствии с заданным. Возможность указания размера также относится к спецификации вторичных файлов БД.
Пример
... [[NO] PREALLOCATE int [PAGES]]
По умолчанию, файл базы не преаллокируется, т.е. растет по мере создания новых страниц.
GSTAT также изменен, чтобы при указании ключа -h показывать количество преаллокированных страниц (информация Preallocate pages).
ISQL дополнительно содержит параметр preallocate для опции -extract. Это приводит к выводу значения параметра преаллокирования, указанного при создании базы данных.
GBAK сохраняет параметр preallocate в резервной копии базы данных, и при восстановлении такой резервной копии создает базу данных преаллокированного размера (а также показывает этот параметр в логе восстановления БД). Для изменения значения preallocate введена новая опция
-pr[eallocate] n
где n - количество преаллокируемых страниц. Значение 0 запрещает преаллокирование.
! При восстановлении базы данных с ключом -page_size и размером страницы отличным от имеющегося, размер preallocation соответственно меняется. Например, если была сделана резервная копия базы данных с размером страницы 4096 байт и preallocation = 5000, то при восстановлении такой базы с указанием размера страницы 2048 байт preallocation будет соответственно увеличено до 10000, чтобы размер преаллокированного файла базы данных соответствовал исходному.
gbak -v foo.gdb foo.gbk -page_size 2048 ... Reducing the database page size from 4096 bytes to 2048 bytes Increasing database preallocation from 5000 pages to 10000 pages created database foo1.gdb, page_size 2048 bytes database preallocation 10000 pages
Forced Writes = ON по умолчанию
Начиная с InterBase 2007 Service Pack 2 вновь создаваемые базы данных будут по умолчанию иметь режим синхронной записи включенным (Forced Write = ON). Это сделано для минимизации повреждений базы при сбоях оборудования. Альтернативой включения синхронной записи является журналирование.
Дескрипторы UDF
InterBase 2007 Service Pack 2 расширяет возможности UDF. До SP2 при объявлении пользовательских функций можно было использовать только явно заданные параметры. Также было проблематично передавать NULL в этих параметрах.
Объявление UDF
Синтаксис декларации UDF расширен следующим образом:
DECLARE EXTERNAL FUNCTION name [ datatype ;
| CSTRING ( int ) | DESCRIPTOR [, datatype | CSTRING ( int ) |
DESCRIPTOR ]]
RETURNS { datatype [BY VALUE] | CSTRING ( int ) | PARAMETER n } [FREE_IT]
ENTRY_POINT 'entryname ' MODULE_NAME 'modulename ';
Пример
DECLARE EXTERNAL FUNCTION DESC_ABS DESCRIPTOR RETURNS DOUBLE PRECISION BY VALUE ENTRY_POINT 'IB_UDF_abs' MODULE_NAME 'smistry_udf';
Использование дескрипторов в C++ и Delphi
в ibase.h введена новая структура - ISC_DSC. Упомянутая выше функция DES_ABS должна быть объявлена на C следующим образом:
double IB_UDF_abs (ISC_DSC *d)
{
double double_var ;
/* function body */
return double_var ;
}
ISC_DSC имеет следующее описание:
/*********************************/
/* Descriptor control structure */
/*********************************/
typedef struct isc_dsc {
unsigned char dsc_version; /* should be set to DSC_CURRENT_VERSION or 2 */
unsigned char dsc_dtype; /* the InterBase data type of this particular parameter */
char dsc_scale; /* scale of the parameter for numeric data types */
char dsc_precision; /* precision of the numeric data type */
unsigned short dsc_length; /* size in bytes of the parameter */
short dsc_sub_type; /* for textual data types will have information about character
set and collation sequence, see DSC_GET_CHARSET and DSC_GET_COLLATE
macros for more information */
unsigned short dsc_flags; /* will be set to indicate null to
DSC_null or to DSC_no_subtype to indicate that
the sub type is not set, this is a bit
map so multiple bits might be set,
use binary operations to test, see
table below for explanation */
unsigned char *dsc_address; /* pointer to the actual value of the datatype */
} ISC_DSC;
Флаги dsc_flags
/* values for dsc_flags */
/* Note: DSC_null is only reliably set for local variables (blr_variable) */
#define DSC_null 1
#define DSC_no_subtype 2 /* dsc has no sub type specified */
#define DSC_nullable 4 /* not stored. instead, is derived
from metadata primarily to flag SQLDA (in DSQL) */
#define DSC_system 8 /* dsc for system field */
Дополнительные макросы:
#define DSC_VERSION2 2 #define DSC_CURRENT_VERSION DSC_VERSION2 #define DSC_null 1 #define DSC_no_subtype 2 #define DSC_nullable 4 #define dsc_ttype dsc_sub_type #define DSC_GET_CHARSET( dsc ) ((( dsc )->dsc_ttype ) & 0x00FF) #define DSC_GET_COLLATE( dsc ) ((( dsc )->dsc_ttype ) >> 8)
Изменения оптимизатора в IB 2007 SP2
Оптимизатор анализирует таблицы и индексы, и по заданному SQL формирует план (способ) выполнения запроса.
Оптимизация индексов в коррелированных подзапросах UPDATE
Оптимизатор использует индексную выборку для коррелированного запроса оператора UPDATE, если соответствующий индекс присутствует.
Пример:
UPDATE A SET A.C1 = (SELECT B.C1 FROM B WHERE B.C2 = A.C2)
Если есть индекс по B.C2, то он будет использован для поиска соответствующих значений в B по условию B.C2 = A.C2.
Сокращение булевских операций
Все булевские выражения по AND/OR сокращаются по мере возможности во время выполнения.
Пример 1:
SELECT * FROM TABLE T WHERE T.A = 5 OR T.B = 6
если T.A = 5, то проверка T.B = 6 не будет производиться.
Пример 2:
SELECT * FROM TABLE T WHERE T.A = 5 AND EXISTS (SELECT ...
Если T.A <> 5, то конструкция EXISTS (SELECT... не будет выполняться.
Примечание: изменение порядка операндов AND/OR не влияет на сокращение булевских операций.
Излишние индексы при or/in
Для операций OR/IN по одному и тому же столбцу используется только один доступный индекс.
Пример:
SELECT * FROM TABLE WHERE FIELD IN (1, 2, 3)
или
SELECT * FROM TABLE WHERE (FIELD =1) OR FIELD=2) OR (FIELD=3)
если по FIELD есть индекс IDXF, то план запроса будет
PLAN (TABLE INDEX (IDXF, IDXF, IDXF))
ранее для поиска по индекса IDXF создавалось 3 (в данном случае) битовые карты. Сейчас используется одна, что сокращает время выполнения запроса и экономит ресурсы сервера.
Оптимизация OUTER JOIN и SORT/MERGE
Алгоритм SORT/MERGE для операций outer join переработан. Теперь внешний (outer) и внутренний потоки различаются, и сопоставляются null из inner и значение из outer, когда в inner-потоке нет соответствия outer.
Инварианты в запросах
Оптимизатор теперь проверяет запрос на наличие условий вида 'литерал операция литерал', и если результат операции False, прекращает дальнейшие вычисления.
Пример:
SELECT * FROM TABLE
WHERE 1 = 0
Ранее сервер полностью перебирал все записи таблицы. Теперь обращения к таблице (в этом случае) не будет. Обращения к таблице будут, если условие вида where :param = 0, и в :param передано 1 - план запроса строится до передачи значений параметров.