5. Многоразмерные Массивы

InterBase обеспечивает уникальный тип данных называемый Многоразменый Массив (Multi Dimensional Array [MDA]). Тип MDA не реализован ни в одной другой РСУБД. Тип MDA позволяет разработчику зранить массивы любой длины и до 16 измерений. Поскольку массив хранится в одном поле, только одна запись и столбец требуются для выборки данных из массива. Массивы предоставляют возможность хранения и представления данных в случаях, в большинстве невозможных для архитектуры SQL Server. Ключевой особенностью является производительность массивов. Представьте себе набор данных, которых должен быть представлен как массив  100x100x100 элементов. Общее количество элементов будет равно 1,000,000 (миллион). Для записи такого количества элементов в обычном случае потребовалось-бы 100000 обновлений страниц данных и индексов. Чтение такого количества элементов так-же потребовало-бы  1,000,000 чтений. При использовании полей типа массив, только одна запись нуждается в чтении или обновлении. Дополнительно, если элемент массива содержит значение NULL, то InterBase не выделяет для него дисковое пространство. В реляционных терминах, доступ к набору данных с одной стороны отношения, не имеющего соответствющего значения, потребует использования outer joun в любом запросе, использующем такое отношение. В большинстве РСУБД, производительность запросов с outer join невелика. Доступ к массивам InterBase осуществляется другим способом, и поэтому не ухудшает скорость доступа к данным.

Компания Bear Stearns использует массивы InterBase для хранения части своих данных, и именно по причине высокой скорости обработки массивов. Bear Srearns производит покупку товаров на бирже и их быструю продажу с небольшой наценкой. Поскольку цена на разных биржах варьируется, ключ к успешной перепродаже это вычисление максимальной разницы в цене пока цены на бирже не изменились. Массивы InterBase по своим характеристикам отвечают требованиям такой задачи..

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

Высокая производительность и богатое представление данных, обеспечиваемые многомерными массивами, позволяют разработчикам создавать решения, невозможные при использовании других РСУБД.

6. Обработка Транзакций

6.1. Модели Транзакций

Индустрия баз данных поддерживает несколько разных моделей транзакций для решения различных задач.

6.1.1. OLTP

Интерактивная обработка транзакций [OLTP] наиболее характерна для банковских операций. По такому сценарию, приложение выполняет серию коротких (по содержимому и по времени) транзакций. Приложению может потребоваться изменение одной-двух записей или небольшой отчет. Большие и длительные отчеты выполняются неинтерактивно.

6.1.2. DSS

Системы поддержки принятия решений (или анализа информации) [DSS] преназначены для поддержки длительных транзакций, таких как итоговые отчеты или статистический анализ. Этот тип систем зависит от относительно статического "вида" базы данных, для того чтобы обеспечить целостность данных на все время действия длительной транзакции.

6.1.3. OLCP

Интерактивная комплексная обработка [OLCP] является смесью моделей OLTP и DSS. Такая модель пытается поддержать баланс между этими двумя моделями, и предназначается для большинства реальных приложений. Такие требования приводят к необходимости иметь высокую производительность, возможность выполнения резервирования данных "на ходу", выполнять длительные запросы или длительные отчеты пока пользователи обновляют текущую информацию. Информация должна быть доступна в любое время без ограничения доступа как для OLTP так и для  DSS транзакций.

6.2. SQL Server

Архитектура SQL Server разработана для поддержки либо OLTP либо DSS, но не для одновременной поддержки обоих. Кроме этого, не поддерживается большинство требований к режиму OLCP для реальных приложений. Такие ограничения вызваны механизмом блокировок, используемым в  SQL Server.

6.3. Типичный Сценарий

Представьте себе таблицу, в которой записи являются ежемесячными записями баланса счетов. По определению, сумма по всем записям должна быть равна нулю (т.е. сумма дебета должна быть равна сумме кредита). Представьте также, что в системе работают одновременно два пользователя - аналитик и оператор. Если аналитик решит запустить длительный отчет, например по всем периодам, то такой запрос должен будет прочитать все записи в таблице. Если аналитик начнет запрос, а в это время оператор выполнит обновление (помните, что сумма дебета и кредита должны равняться 0) самой верхней записи таблицы (которую запрос аналитика уже прочитал) и нескольких самых нижних записей (которые запрос аналитика еще не успел прочитать из-за длительности своего выполнения), то аналитик увидит только вторую часть транзакции оператора. Итог у аналитика не сойдется и запрос придется выполнять снова.
 
В большинстве случаев аналитику придется действительно повторить запрос (правда, тут еще надо догадаться - действительно-ли это не сошелся баланс или это произошло из-за вмешательства оператора). Но поскольку неизвестно, сколько на самом деле записей изменил оператор, да и сколько всего операторов работают в этот момент, единственным решением для аналитика может быть только административное - запретить всем операторам вводить данные до тех пор, пока аналитик не завершит формирование отчета. Еще более худшая ситуация может возникнуть, если отчет выполняется не по одной а по двум таблицам - главной и подчиненной. Большинство генераторов отчетов сначала собирают данные из подчиненных таблиц, а затем выполняют расчет по главной. Раздельное обновление данных в этих таблицах может привести к появлению полностью негодного отчета. Это недопустимо в базах данных, контролирующих научные данные реального времени или производственный процесс.
 
В архитектуре SQL Server, есть только один способ гарантировать целостность и воспроизводимость чтения - это блокировка всей таблицы. Блокировка такого типа блокирует доступ к таблице для других пользователей. В приведенном выше сценарии, SQL Server автоматически переведет страничные блокировки в блокировку всей таблицы. Однако блокировка таблицы не возникнет пока достаточное количество страниц не будет прочитано (уровень эскалации бликроовки). Так что вероятна ситуация, когда операторы, обновляющие данные, заблокируют возможность установки блокировки таблицы, и запрос аналитика "зависнет" в ожидании до бесконечности или просто не сможет выполниться. Разработчик должен знать особенности эскалации блокировок и вручную протестировать все ситуации. Возникновение полной блокировки таблицы в системах, работающих 24 часа в сутки, может быть очень труднодостижимо или вообще невозможно, поскольку такая блокировка приведет к блокировке всех остальных пользователей, работающих интерактивно и в реальном времени. Много разработчиков не имеют другого выбора кроме как выполнять подобные отчеты по расписанию, в часы наименьшей активности основной массы пользователей, и когда полная блокировка таблицы никому не помешает.
 
Разработчики должны также потратить много времени, разрабатывая систему управления блокировками, для того чтобы обеспечить работу программы при возникновении конфликтов блокировок. Часто состояние заблокированности не может быть определено пока пользователь не завершит транзакцию. Разработчики должны периодически пытаться сохранить транзакцию пока блокированные данные не станут доступными, либо писать сложные процедуры кэширования обновлений на клиентских машинах (для сокращения времени выполнения транзакции). Локальное кэширование данных вызывает много других проблем, например как следствие - большинство пользователей во время кэширования их обновлений видят неверную информацию в базе данных.
 
Сложность приложений, разрабатываемых в настоящее время, достаточно высока и без ограничений, накладываемых архитектурой SQL Server.
(Д.К. - в настоящее время фирма Sybase выпустила специальный продукт, позволяющий работать с DSS-транзакциями - Sybase IQ. Это специальный продукт, который предназначен для выполнения транзакций DSS только в режиме чтения (и фактически только по архивным, а не оперативным данным). Обновление такой БД в режиме OLTP практически невозможно из-за специально применяемых структур данных. Таким образом задачи OLTP и DSS у Sybase решаются при помощи двух отдельных продуктов - Sybase System 11 и Sybase IQ соответственно).

6.4. InterBase

Borland InterBase полностью поддерживает модель OLCP. Уникальная архитектура многоверсионности записей гарантирует, что пользователи транзакций  OLTP не обнаружат блокировок при обновлении данных, используемых транзакциями DSS, в то время как транзакциям DSS гарантируется воспроизводимое чтение. В том-же сценарии: когда аналитик начинает транзакцию, IB создает идентификатор этой транзакции. Когда оператор начинает свою транзакцию, то IB для него тоже выделяет идентификатор транзакции. Если обнаруживаются другие активные транзакции на этот момент, то IB для обеспечения воспроизводимости чтения создавать версии записей, модифицируемые любой из других активных транзакций. Во время действия транзакции аналитика ему видны только версии записей, связанные с его транзакцией. Во время действия транзакции оператора, ему видны тоже только те версии записей, которые связаны с идентификатором его транзакции. Таким образом аналитик и оператор изолированы друг от друга на время действия их транзакций, независимо от их длительности. При завершении обоих транзакций новые версии записей оператора становятся видны аналитику, а старые версии записей удаляются.

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

7. Установка и Сопровождение

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

Большинство корпораций уже стандартизировали свои операционные системы. Установка новой операционной системы может быть неприемлема корпоративным тандартом, и даже если это возможно, нежелательна по следующим причинам:

• При установке новой операционной системы требуются новые знания и опыт для ее администрирования.
• Возникают новые вопросы и требования, касающиеся безопасности доступа и сопровождения.

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

7.1. Установка и Занимаемое Пространство

7.1.1. Background

Требования установки РСУБД зависит от производителя и операционной системы. Некоторые РСУБД работают без модификации операционной системы, другие-же требуют изменения ядра до или во время процесса установки. Разработчик должен убедиться, что модификации ядра операционной системы не отразятся на производительности и совместимости с его программным обеспечением.

7.1.2. Занимаемое пространство

До установки, и MS SQL Server и Sybase SQL Server требуют предварительного распределения пространства и для РСУБД и для базы данных. Администратор системы или базы данных должен слелать необходимое пространство доступным. Если размер БД превысит отведенное ей пространство во время работы, то РСУБД может прекратить свою работу (во время добавления, изменения, или даже выполнения запроса к данным. Вот причины, по которым это может произойти:

• Большие запросы, вызывающие создание временных таблиц на диске.
• Переполнение файла, регистрирующего работу транзакций (Transaction logs).
• Добавление большего количества данных чем предполагалось.
• Переполнение файла данных при модификации полей типа VARCHAR из-за их удаления и добавления.
• Переполнение файла данных из-за большого количества удалений (Д.К. - пространство на диске может не освобождаться, а log-и будут расти).

7.1.3. Определение размера базы данных

Определение размера БД, необходимого для SQL Server может быть весьма сложным из-за множества факторов. Размер должен быть достаточным для распределения системных таблиц, пользовательских таблиц и всех индексов. Вот некоторые факторы, которые обязательно нужно учитывать:

• На протокол транзакций требуется дополнительно от 20% до 30% от общего объема данных.
• Дополнительно 150% размера таблицы при использовании кластерного индекса.
• 5% размера таблицы на внутренние затраты SQL-сервера.
• Дополнительно по 2K на запись, если она содержит поле text или image даже если поле пустое.
• Еще пространство для протокола транзакций если предполагаются частые обновления полей типа VARCHAR.
• И еще пространство, если в некоторых таблицах будут часто производиться удаления записей.

7.1.4. Microsoft SQL Server

7.1.4.1. Установка

Microsoft SQL Server существует только для Windows NT. Это исключает возможность использования оборудования, расчитанного на мощные UNIX-системы. Соответственно невозможны и многоплатформенные, масштабируемые решения.

Базы данных Microsoft SQL Server требуют тщательного распределения дискового пространства и мониторинга доступности этого пространства. Остановка из-за отсутствия свободного пространства в БД может вызвать серьезные последствия. Установка и сопровождение Microsoft SQL server не очень проста для отделов или рабочих групп, особенно если ресурсы аппаратуры ограничены. Эти особенности отражаются на затратах как поставщиков так и покупателей решений на основе MS SQL Покупатель не всегда может иметь достаточно квалифицированного администратора БД, чтобы правильно распределять пространство БД и управлять ресурсами SQL-сервера.

7.1.5. Sybase

Sybase имеет реализации для нескольких платформ, которые включают Windows NT, Novell NetWare и различные платформы UNIX. Как и для Microsoft SQL Server, установка Sybase требует предварительного распределения пространства для баз данных и РСУБД, включая все проблемы возникающие с файлами протоколов транзакций, редактированием полей VARCHAR, удалением записей, пакетной загрузкой записей и большими запросами.

Кроме этого, для достижения оптимальной производительности на платформах UNIX [включая SCO], администратор БД должен создавать "сырые" (raw) разделы диска (Д.К. - то-же самое можно делать в Informix и Oracle). Когда база данных устанавливается на "сырой" раздел, все дисковые операции выполняются напрямую РСУБД. При некотором увеличениипроизводительности добавляется и сложность в установке и сопровождении такой базы данных. Поскольку операционная система не имеет доступа к "сырому" разделу, с ним невозможно работать при помощи стандартных утилит UNIX в случае сбоя. И на платформах UNIX, Sybase производит изменения ядра операционной системы. Такие изменения могут вызвать проблемы при обновлении либо РСУБД либо операционной системы.
 

7.1.6. InterBase

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

Поскольку InterBase не требует модификации ядра ОС, он защищен от проблем совместимости при обновлении ядра ОС. Это позволяет разработчику сопровождать операционную систему без оглядки на работоспособность РСУБД.

(Д.К.- собственно процесс установки представляет собой переписывание на жесткий диск файлов дистрибутива IB. Это происходит за 3-4 минуты, после чего можно сразу создать базу данных (1 команда в ISQL, время 2-3 секунды), и приступить к созданию таблиц и других объектов БД)

7.2. Обслуживание

7.2.1. Backup

7.2.1.1. SQL Server

Сохранение БД в архив должно выполняться периодически (например по ночам). Поддерживается два типа backup, производимого SQL Server - полный (full) и сохранение изменений (incremental). Полный backup [иногда называемый dump] создает полный образ базы данных включая системные таблицы и и файлы протоколов. Backup с сохранением (incremental) делает только копию файлов протоколов. Администратор БД должен четко выполнять последовательные full и incremental backup. Это необходимо потому, что backup не сбрасывает файлы протоколов. Если-же не делать периодически incremental backup, то файлы протоколов могут переполниться, и РСУБД в результате остановит свою работу. Такая остановка требует вмешательства квалифицированного администратора БД для устранения проблем. Это также блокирует работу пользователей на время, требуемое для восстановления БД в рабочее состояние.

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

7.2.1.2. InterBase

Благодаря многоверсионности записей, база данных может быть сархивирована (backup) в любое время при любом количестве пользователей, работающих с данными в это-же время. Backup представляет собой транзакцию с уровнем изоляции RepeatableRead, которая производит только чтение всей БД. Таким образом backup "не видит" изменений, производимых или произведенных после старта backup. Это гарантирует целостное состояние архивированной БД на момент архивации. В смысле производительности выполнение backup означает подключение еще одного пользователя, который читает данные. В Borland InterBase существует только один тип архивирования - полный (full), когда архивируются абсолютно все данные, находящиеся в БД.

(Д.К. - к сожалению, incremental backup у IB отсутствует. Это можно объяснить только тем, что при отсутствии механизма Transaction Log и наличии механизма многоверсионности записей, для incremental backup пришлось-бы либо все новые версии записей, начиная с окончания full backup, класть в отдельное место, либо неявно не завершать транзакцию full backup, что привело-бы к появлению неоправданно большого количества версий записей и расходованию дискового пространства. м.б. что-то новое появится в IB 5.0)

7.2.2. Регистрация транзакций (Transaction Logs)

7.2.2.1. SQL Server

Ttransaction log - системная таблица, в которую записываются все последовательные модификации каждого объекта БД. Он также хранит информацию, необходимую для обеспечения целостности данных при модификации данных. Пространство, необходимое для регистрации транзакций трудно предсказуемо. Представьте себе, что log должен содержать информацию по каждой обновленной записи плюс изменения индексов. Также, представьте что у таблицы много индексов. Объем transaction log зависит от длины записи. Для коротких записей отношение размера log к размеру данных может достигать 10:1. Для длинных записей это отношение меньше. Операции пакетной "заливки" данных или удаления также могут потребовать большого размера transaction log. Как уже указывалось выше, при модификации записей с полями VARCHAR требуется еще больший размер transaction log, т.к. регистрируется не одна операция модификации, а две - удаления и вставки.

Если расписание архивирования БД включает смесь полного (full) и частичного (incremental) архивирования, то это тоже нужно учитывать при определении размера transaction log. Причина в том, что incremental backup - это механизм, используемый в SQL Server для очистки transaction log. Большое влияние оказывают также и длительные транзакции, особенно если они обновляют большое количество записей - в этом случае размер transaction log должен быть установлен в 200% от размера хранимых данных.

Размещение transaction log также критично - если он переполнится, и не оставит свободного места на диске, все операции с БД будут прекращены (буквально произойдет crash). Поэтому размещать БД и transaction log желательно на разных устройства.

7.2.2.2. InterBase

Borland InterBase не использует transaction log для хранения информации о транзакциях и изменениях, которые они производят. Вместо этого используются Transaction Inventory Pages [TIP]. На этих страницах хранится информация о состоянии любой транзакции: активная, подтвержденная, отмененная или подоготовленная (для двухфазного потдтверждения транзакций (2PC).  В случае системного сбоя, как только сервер будет запущен, будут автоматически просканированы TIP с целью поиска неподтвержденных транзакций. Все записи, найденные в неподтвержденном состоянии, будут отменены. Этот процесс практически для БД любого размера происходит в течение нескольких секунд. (Д.К. действительно несколько секунд, потому что отмененные записи при этом не удаляются - отмененные версии записей будут собраны как мусор только тогда, когда какой-нибудь пользователь не обратится к этим данным (кооперативная сборка мусора).

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

7.2.3. Контрольные точки (Checkpoints)

7.2.3.1. SQL Server

Архитектура SQL Server требует чтобы администратор установил контрольные точки для БД. Контрольные точки - это интервалы времени, через которые происходит запись накопленных в кэше SQL-сервера изменений на диск (transaction logs и страницы данных). Если изменения происходили между двумя checkpoint, и в это время произошел сбой, то изменения данных вообще не попадут в transaction log, соответственно откат к предыдущему состоянию будет сделан по данным, сохраненным во время последнего checkpoint перед сбоем. Интервал checkpoint влияет как на сохранность данных от сбоев так и на производительность системы - установив большой интервал, вы ускорите производительность, но можете потерять много изменений при сбое. Установив маленький интервал (1-2 минуты), ухудшится производительность системы.
(Д.К. - этот-же абзац в оригинале звучит несколько по другому - автор ошибочно думает, что интервал checkpoint прямо влияет на время восстановления системы после сбоя. Например, при checkpoint=20 минут, на восстановление потребуется тоже 20 минут. Это совсем не так - изменения данных, произведенные между checkpoint при сбое просто будут потеряны).

7.2.3.2. InterBase

Контрольные точки в Borland InterBase не используются. Вместо этого применяется синхронное и асинхронное сохранение измененных данных. Синхронное кэширование при несколько меньшей производительности гарантирует немедленное восстановление БД после сбоя. Администратор БД может установить и асинхронное кэширование, в этом случае скорость обновлений БД возрастет, однако повысится риск потери большого количества изменений при сбое, т.к. за выгрузку кэша на диск уже отвечает операционная система.
Возможность немедленного восстановления после сбоя без необходимости какого-бы то нибыло вмешательства администратора БД делает Borland InterBase наилучшим выбором для рабочих групп, отделов, или поставщиков решений, особенно для тех, которые не могут иметь в штате высококвалифицированного администратора базы данных.

7.2.4. Конфигурирование и настройка

7.2.4.1. SQL Server

Microsoft SQL Server и Sybase SQL Server имеют мириады конфигурационных опций и параметров настройки для оптимизации производительности базы данных. Многие их этих параметров достаточно сложны и могут влиять друг на друга. Только достаточно квалифицированный администратор БД может управлять всеми этими параметрами для настройки сервера. Например,  в Sybase System 11 появилось более 200 параметров настройки. Это добавляет сложности к управлению сервером, стоимость обучения администратора БД, и предполагает что по мере усложнения используемой базы данных может потребоваться настройка севера.

7.2.4.2. InterBase

Borland InterBase автоматически конфигурируется и настраивается, и не требует никакого вмешательства администратора в настройки. Это максимально облегчает управление и сопровождение. В общем случае, у IB существует не более конфигурационных 20 параметров, которые практически никак не влияют друг на друга (основных параметров всего 3 - размер кэша и лимиты занимаемой памяти). Это сделано специально для уменьшения стоимости сопровождения и обслуживания. После установки, вмешательство администратора БД требуется разве что в случае катастрофического сбоя оборудования, или для регулярного выполнения bakup (Д.К. - который можно автоматизировать при помощи утилиты AT на Windows NT, или специальных утилит на UNIX).

7.3. Восстановление при сбоях

7.3.1.1. SQL Server

Автоматическое восстановление базы данных SQL Server включает в себя "воспроизведение" содержимого transaction logs. Этот процесс последовательно применяет к БД транзакции, сохраненные в transaction log для того чтобы восстановить состояние БД на момент последнего checkpint.

Если база данных не восстанавливается из существующего transaction logI, следовательно ее надо удалить и восстановить из архива. При этом восстанавливается сначала полная копия БД, а затем все "частичные" архивы (incremental backups), которые были созданы от момента сохранения полной копии БД. Это достаточно сложный и длительный процесс.

7.3.1.2. InterBase

Восстановление базы данных Borland InterBase происходит автоматически без вмешательства администратора БД. Транзакции, которые не успели завершиться на момент сбоя, будут полностью отменены, и БД останется в целостном состоянии. Недостатком является отсутствие "частичного" архивирования, т.е. если в результате сбоя был поврежден носитель данных, восстановить удастся только БД в ее последнем полном архивировании. Это компенсируется скоростю выполнения backup, его выполнением "на ходу", а также скоростью восстановления данных.

Как уже упоминалось, при запуске Borland InterBase он проверяет БД на наличие неподтвержденных записей. При существовании таковых они переводятся в отмененное состояние. Этот процесс занимает несколько секунд. Такая особенность была ключевым фактором при выборе InterBase для американского танка M1 Abrams. Когда происходит выстрел из пушки танка, возникает весьма сильный электромагнитный импульс, который "перегружает" компьютер танка. После перезагрузки компьютера, InterBase мгновенно восстанавливает БД в целостное состояние и тут-же делает ее доступной для работы. Это свойство, не доступное в любой другой РСУБД, гарантирует доступность базы данных в жизненно важных ситуациях. Даже если потребуется восстановить БД из backup, это производится фактически одним нажатием кнопки в Server Manager, или запуском командного файла (вызывающего утилиту gbak), что может сделать даже неквалифицированный пользователь. Поскольку Borland InterBase является переносимым SQL-сервером, действия по восстановлению БД будут абсолютно идентичны для любой платформы.

Figure 2. Restoring an InterBase database using the InterBase Server Manager.

Восстановление БД может производиться между любыми операционными системами. Т.е. файл backup может располагаться например на Windows NT 3.51, а восстанавливаемая БД - на SCO UNIX.

7.3.1.3. Зеркалирование БД (Database Shadowing)

Borland InterBase использует технику "горячего" резервирования при помощи так называемой "тени" (shadow). "Теневая" БД - дубликат базы данных, находящийся на другом физическом устройстве. Обновление "тени" производится с каждым обновлением страницы основной базы данных. В случае аппаратного сбоя носителя основной базы данных, Borland InterBase в зависимости от режима "затенения" переключает пользователей на "тень", делая ее основной базой данных. Это может происходить либо автоматически, либо по команде администратора базы данных. Таким образом, решается либо задача обеспечения непрерывного доступа к БД (online), либо гарантирование наличия целой копии рабочей базы данных. "Теней" базы данных может быть столько, сколько нужно для гарантии сохранности данных.

8. РЕСУРСЫ

8.1. Microsoft SQL Server

Microsoft SQL Server требует наличия как минимум 60M на диске для установки и 16MB RAM под NT 3.51 (Д.К. наверное, имеется в виду 16Мб физической памяти). Каждый пользователь занимает по 48K памяти. Т.е. в случае 20-ти пользователей потребуется около 17Мб физической памяти, не считая памяти, необходимой для обработки таблиц и буферизации данных.

Несмотря на то, что при установке Microsoft SQL Server не требуется конфигурирования памяти, Microsoft считает этот параметр важнейшим, и рекомендует устанавливать его вручную. Microsoft не предоставляет формулы для определения оптимального значения, вместо этого рекомендуется запустить монитор производительности, и анализировать параметр "page faults/sec". Далее, поскольку Microsoft SQL Server блокирует память и временные таблицы в памяти, то другие приложения, выполняемые на этом-же компьютере могут выдать сообщение о нехватке памяти. Вообще, определение необходимого объема памяти достаточно сложная задача, решаемая только в реальных условиях, и достаточно квалифицированным администратором.

8.2. Sybase SQL Server

Установка Sybase требует приблизительно 50M на диске. Дополнительное пространство требуется для устройств дампа, временного рабочего пространства и т.п. Также плюс 2-3 MB на установку поддержки национального языка.

Требования к памяти отличаются на разных платформах. Администратор Sybase SQL Server должен подсчитать требования к памяти основываясь на:

• Статической памяти для ядра SQL Server
• Кэш процедур и данных (конфигурируемый)
• Сетевая буферизация на отдельного пользователя
• Буферы ввода/вывода.

Т.е. также, как и для Microsoft SQL Server, Sybase SQL Server создает большие затраты на сопровождение.

8.3. InterBase

Ядро Borland InterBase использует менее 2Мб памяти (что на 1Мб меньше, чем например занимает утилита FastFind из Microsoft Office). При установке на диске требуется около 8Мб, причем большинство этого пространства занимают справочные файлы, примеры, библиотеки клиентского API, и примеры БД. Borland InterBase не требует памяти больше, чем базовая память для операционной системы. Он динамически использует ресурсы диска и памяти без вмешательства администратора БД.