Сравнение Borland InterBase 4.x, Sybase SQL Server и Microsoft SQL Server
ОГЛАВЛЕНИЕ
Даже если большинство систем не требуют экзотических возможностей, как вышеперчисленные, они все равно желают от РСУБД тех-же характеристик для реальных задач и решения реальных проблем бизнеса. Перечисленные характеристики Borland InterBase также очень хорошо подходят для рабочих групп, отделов, и приложений уровня предприятия. Цель этого документа - продемонстрировать преимущества Borland InterBase в сравнении с SQL-серверами Microsoft SQL Server и Sybase, или дать вам возможность сравнить архитектуры и особенности этих SQL-серверов.
1.1. Замечания
До выпуска Microsoft SQL Server 6.0, Sybase SQL Server и Microsoft SQL Server были одним и тем-же продуктом. Microsoft SQL Server 4 был лицензирован у Sybase и продавался под маркой Microsoft. В 1995 году Microsoft выкупил исходные тексты у Sybase и модифицировал их для того, чтобы выпустить Microsoft SQL Server 6.0. Sybase продолжила разработку своего SQL Server и в настоящее время выпускает его под названием Sybase SQL Server System 10 и System 11. Тем не менее, и Microsoft SQL Server и Sybase SQL Server имеют одно и то-же ядро сервера баз данных. Поэтому в большинстве случаев они ведут себя совершенно одинаково. По этой причине, термин “SQL Server” в этом документе будет относиться и к Microsoft SQL Server и к Sybase SQL Server. Там, где эти продукты отличаются, будут упоминаться их соответствующие полные имена.
1.2. Немного Истории
InterBase был придуман и создан группой сотрудников Digital Equipment Corporation [DEC], желавших воплотить в RDBMS ряд уникальных технологических решений, обеспечивающих большие преимушества по сравнению с существовавшими серверами баз данных. InterBase начался в 1985 году как Groton Database Systems (GDS) и вскоре был переименован в InterBase. Группа была приобретена Ashton Tate в 1991 году. Borland получил InterBase в 1992 году как часть приобретения Ashton Tate.
Как и планировалось разработчиками, InterBase продемонстрировал целый ряд технологических новшеств. Среди них Множественные поколения записей, автоматическое двухфазное подверждение транзакций, зеркалирование базы данных, большие двоичные объекты [BLObs], битовые индексы, многмерные массивы и уведомления о событиях.
Боьшинство существующих RDBMS не смогли воспроизвести или создать эквивалентные технологии. Например, архитектура SQL Server использует комбинацию страничных, индексных и табличных блокировок для обеспечения конкурентного доступа к данным. SQL Server также поддерживает двухфазное подтверждение транзакций, однако требует большого количества кода для реализации подтверждения или отката. SQL Server обеспечивает хранение данных типа BLOb, но в более ограниченном и менее быстродействующем варианте чем это реализовано в InterBase.
2. Механизмы блокировок
2.1. Background
Целостность данных - самое важное качество для корпоративных данных. Существует много способов для обеспечения целостности данных в RDBMS. Наиболее распространены пессимистическая и оптимистическая схемы блокировок. Пессимистические блокировки - простейший в реализации способ, когда блокируются страницы, индексы или таблицы для обеспечения целостности транзакции. Оптимистические блокировки предполагают отсутствие блокировок для клиентского приложения. При этом используются более сложные механизмы для обеспечения целостности транзакции. Оптимистические блокировки, обеспечивая целостность данных, обладают оптимальной производительностью и легкостью в использовании.
2.2. SQL Server
2.2.1. Страничные Блокировки
Для того, чтобы гарантировать целостность данных, архитектура SQL Server использует механизм блокировок страниц данных. Страница данных это набор записей, хранимых в некоторой области жесткого диска на сервере. Все страницы имеют один и тот-же размер, который определяется конфигурацией сервера и базы данных. В зависимости от длины записей и размера страницы, страница может содержать определенное количество записей. Записи в большинстве случаев добавляются в конец таблицы. Базовый размер страницы в SQL Server равен 2K, и это является минимальной единицей блокировкиl. Страничные блокировки требуют от разработчика глубоких знаний о конкурентной работе с данными и настройке кода для получения максимально конкурентного доступа. Страничная блокировка блокирует все записи или соответствующие ссылки в индексах, хранимые на одной странице. Например, если размер записи в таблице равен 100 байт, а размер ключа индекса равен 10 байт, то блокировка одной страницы данных и одной страницы индекса приведет к куммулятивному эффекту блокирования 18-ти записей и 180-ти ключей индекса.
Когда происходит запись в таблицу, то для обеспечения целостности записи RDBMS блокирует страницу, на которой находится эта запись. Блокирование целой страницы намного быстрее блокирования отдельной записи, и требует намного меньше ресурсов сервера для управления блокировками. Вместе с тем, блокирование целой страницы, приводит к блокированию других пользователей от изменения данных на этой-же странице. В дополнение к блокированию страницы, на которой находится интересующая запись, SQL Server дополнительно блокирует предыдущу и следующую страницу (относительно блокируемой). Доступ к записям на блокированных страницах будет невозможен в течение действия блокировки. Блокирование может возникнуть во многих ситуациях. Наиболее частая причина блокировки - добавление записи или ее модификация. Кроме этого, использование курсоров клиентским приложением может также производить большое количество блокировок страниц. В таких ситуациях пользователь, всего-лишь просматривающий записи, блокирует других пользователей от внесения изменений на эти-же страницы до тех пор, пока не закроется курсор либо блокировка не переместится на другие страницы.
То, что "читатель" записи блокирует страницу на которой эта запись находится, и ее смежные страницы, может привести к проблемам производительности для пользователей, которые нуждаются в доступе к данным на заблокированных страницах. Вместо того, чтобы сосредоточиться на разработке правил управления данными, разработчик вынужден описывать сложную обработку возможного возникновения конфликтов блокировок. Это увеличивает сложность приложения, и повышает стоимость разработки и сопровождения.
2.2.2. Блокировки Индексов
Индексы SQL Server блокируются точно так-же, как и страницы данных соответствующих таблиц, однако эффект блокировки страницы индекса значительно шире. Записи в таблице хранятся в большинстве случаев в случайном порядке (исключение составляют кластерные индексы). Когда обновляется страница данных, то должен обновиться соответствующий индекс. Как и у таблиц, данные индексов хранятся на страницах. Для обновления страницы индекса, эта страница должна быть сначала заблокирована. Если данные в таблице распределены случайным образом, то блокировка страницы индекса приведет к блокировке большого количества страниц данных, поскольку страница индекса ссылается на большое количество страниц данных. Это значит что модификация одного ключевого значения на странице может заблокировать множество совершенно посторонних записей на страницах данных. Если для таблицы определено несколько индексов, то изменение одной записи приведет к лавинообразному росту блокировок страниц, не относящихся к странице где находится модифицируемая запись. В приложениях, работающих с большими объемами данных, это может сильно снизить производительность системы.
2.2.3. Блокировки Таблиц
Целостностное представление базы данных иногда требует уровня изоляции "воспроизводимое чтение". "Воспроизводимое чтение" гарантирует неизменность видимых данных на время действия транзакции. Это очень важно в финансовых приложениях или при создании отчетов по большим объемам данных в то время как другие пользователи модифицируют записи. Для обеспечения целостного представления данных в Sybase или Microsoft SQL Server разработчик должен использовать блокировки таблиц. Блокировка таблицы вызывает полную блокировку, разделяемую, для обновления или исключительную [Shared, Update, or Exclusive]. Представьте себе свод баланса бухгалтером - пока свод не закончен, архитектура SQL Server требует чтобы разработчик полностью заблокировал таблицу на время свода. Кроме этого может потребоваться полное блокирование связанных таблиц. Более подробно эта тема обсуждается в секции 6.3.
2.2.4. Эскалация страничных блокировок в Блокировки Таблиц
Длинные транзакции, затрагивающие большое количество записей, требуют большого количества страничных блокировок. Как только количество страничных блокировок достигает определенного предела, SQL Server автоматически включает полную блокировку таблицы. Назначение такого механизма в том, чтобы уменьшить работу RDBMS по управлению блокировками и обеспечению конкурентного использования данных, и чтобы предотвратить деградацию производительности. Естественно, что полная блокировка таблицы заблокирует другим пользователям доступ к этой таблицы. Эскалация может произойти как при обновлениях, так и при обычной выборке данных. Для того, чтобы обеспечить оптимальную производительность при многопользовательском доступе, администратор БД должен тщательно проанализировать структуры БД и алгоритмы клиентских приложений на пересекающиеся запросы по чтению и обновлению данных. После этого администратор должен определить уровень эскалации табличных блокировок чтобы сбалансировать управление большим количеством блокировок страниц и блокировку доступа при эскалации табличных блокировок. Разработчики приложений также должны понимать особенности страничных и табличных блокировок, и соответственно программировать обработку доступа при блокировках. Такие требования добавляют к приложениям дополнительную сложность кода, увеличивая стоимость разработки и сопровождения.
2.2.5. Варианты решения проблем
Для того, чтобы обрабатывать множество ограничений механизма блокировок SQL Server, разработчики должны использовать множество решений для оптимизации баланса между конкурентным доступом и производительностью:
- Использовать администратора БД, хорошо знакомого с SQL Server, для проведения анализа клиентских приложений, статистики базы данных и структур данных, чтобы установить оптимальное значение уровня эскалации табличных блокировок.
- Буферизировать данные локально (например использовать Cached Updates в BDE 3.x) для сокращения времени транзакции до минимума. В любом случае необходимо специально программировать обработку ситуаций, когда разные пользователи пытаются обновить одни и те-же записи.
- Использовать репликацию данных, над которыми может произоводиться длительная обработка (сложные отчеты). К сожалению, репликация в SQL Server является односторонней. Это ограничение часто делает невозможным использование репликации для более сложных задач. В Sybase, репликация производится при помощи отдельного продукта, называемого “Replication Server”.
- Использовать временные таблицы для пакетных обновлений данных. Это может вызвать другие проблемы, поскольку пользователи могут параллельно такому обновлению модифицировать данные в других таблицах, и данные во временной таблице станут неактуальными.
- Использовать HOLDLOCK для установления блокировки SHARE на выбранные элементы данных, чтобы предотвратить обновление этих данных другими пользователями. При большом количестве пользователей, возможно что другие пользователи будут пытаться обновить одни и те-же страницы данных или индексов. Множественные блокировки SHARE могут быть применены к одним и тем-же элементам чтобы блокировать обновления. При таком сценарии, другой пользователь получит deadlock и один из двух пользователей должен быть отключен для прекращения ситуации deadlock. Использование монопольных блокировок предотвратит deadlock, но и сделает невозможным просмотр заблокированных данных другими пользователями. Ненормальное завершение приложения может оставить неразрешенные блокировки до тех пор, пока сервер определит что связь с приложением оборвалась.
2.2.6. Операция Вставки в Microsoft SQL Server
В Microsoft SQL Server 6.5 механизм блокировок улучшен по сравнению с версией 6.0 и Sybase SQL Server поддержкой блокировок на уровне записей при вставке. Это увеличивает производительность вставки записей, но никак не решает другие проблемы со страничными, индексными или табличными блокировками. Поэтому, независимо от версии, обновление данных в архитектуре SQL Server все-равно требует табличных или страничных блокировок для обеспечения целостности данных.
2.3. InterBase
2.3.1. Архитектура Многоверсионности Записей
InterBase обеспечивает оптимистические блокировки при помощи Архитектуры Многоверсионности Записей (Multi-Generational Architecture- [MGA]). Этот механизм создает оптимизированные версии для новых, удаленных или обновляемых записей, которые видны только в контексте конкретной транзакции, изменяющей данные. Реально, InterBase версионирует только изменяемые столбцы (поля) путем создания deltas. Это обеспечивает максимальную производительность и минимальные требования к дисковому пространству.
Состояние "невидимости" версионированных записей длится только в течение транзакции. После подтверждения (committing) транзакции, измененные записи становятся видимы транзакциям, стартовавшим до завершения этой транзакции (Д.К. - только если эти транзакции ReadCommitted или стартовали после завершения транзакции, менявшей данные. Для транзакций RepeatableRead, стартовавших до завершения такой транзакции, изменения записей не видны). Вообще, все другие транзакции имеют свое собственное представление изменяемых записей, пока они (транзакции) не закончатся подтверждением или отменой. Как только транзакции, читавшие или обновлявшие записи, завершились, InterBase освобождает старые версии записей. Когда две транзакции пытаются обновить одну и ту-же запись, транзакция, первой сделавшая обновление является "владельцем", и вторая транзакция получит сообщение об ошибке. Разработчики приложений как для SQL Server так и для InterBase одинаково могут управлять такими ситуациями. В любом случае, приложение для SQL Server должно сначала перечитать запись чтобы убедиться что она не изменена. В зависимости от средств разработки приложений, разработчику, использующему SQL Server, может потребоваться написать дополнительный код для такой операции. Вместо того, чтобы писать код обработки страничных, индексных и табличных блокировок, разработчик при использовании InterBase должен обрабатывать только конфликты обновления с другими транзакциями. Это означает значительно меньшие затраты при разработке и сопровождении для корпораций, использующих InterBase.
(Д.К.- на самом деле механизм многоверсионности значительно сложнее. Например, блокировки в терминах MS SQL, Sybase, Oracle даже на уровне записей в InterBase отсутствуют.
2.4. Производительность
Результаты тестов на производительность в основном зависят от механизмов блокировок, используемых в тестируемой СУБД. Страничные и табличные блокировки SQL серверов Microsoft и Sybase могут сильно влиять на производительность, когда многим пользователям требуется доступ к одним и тем-же данным (или находящимся на близлежащих страницах). Например, в реальных ситуациях, страничные блокировки в SQL Server могут замедлять доступ к данным (ожидание освобождения блокировок страниц, индексов или таблиц). Этот эффект может быть заметен в системах с большим объемом данных или когда пользователи выполняют создание длительных отчетов по данным в тот момент, когда другие пользователи модифицируют данные. Архитектура Многоверсионности Записей InterBase гарантирует доступность данных на чтение для любых пользователей и в любое время. Клиентское приложение никогда не ждет доступности таблиц, записей или индексов, независимо от числа пользователей в системе или длительности и сложности какой-либо транзакции. Разработчики, использующие InterBase, автоматически получают максимум производительности приложений, безотносительно сложности обработки данных.
3.Двухфазное подтверждение транзакций
3.1. Background
Слово "транзакция" произошло от слияния слов "акция трансформации". Транзакция это действие или группа действий, которые переводят систему из одного целостного состояния в другое. Например, при переводе денег с одного счета на другой, должна быть изменена сумма либо обоих счетов, либо ни одного в случае ошибки.
Транзакци характеризуются свойствами ACID:
Atomicity (атомарность) - "все или ничего". Либо вся транзакция завершается, либо ни одна из ее частей. Если транзакция не может быть завершена, то все операции, произведенные внутри транзакции, отменяются.
Consistency (целостность) - Транзакция должна переводить базу данных из одного целостного состояния в другое. Целостность определяется бизнес-правилами (логикой базы данных) и вводится в действие приложением.
Isolation (изоляция, изолированность) - Поскольку может возникать множество конкурентных транзакций, каждая транзакция должна быть изолирована от действий, производимых другими транзакциями. Т.е. транзакции должно "казаться", что она является единственной, выполняемой над базой данных.
Durability (прочность)- Изменения, подтвержденные транзакцией, обязаны вступить в силу.
Если использовать в качестве примера оплату по кредитной карте, то все ACID-свойства должны иметь место. Представим что информация кредитной карты хранится в одной БД, а информация о счете клиента - в другой. В этом случае при изменении количества денег на кредитной карте соответственно должен измениться счет клиента, и выполняться это должно в одной транзакции. Такие ситуации обрабатываются при помощи двухфазного подтверждения транзакций (Two Phase Commit - 2PC). Это механизм, который применяет к изменениям в обоих базах данных свойства ACID.Двухфазное подтверждение транзакций имеет две отдельные фазы: подготовка и подтверждение. Если по какой-то причине процесс не может быть выполнен в течение фазы подготовки, например после снятия денег с кредитной карты но до изменения суммы счета клиента, то транзакция должна быть отменена (rollback). Это гарантирует что на счету не останется денег больше, чем на кредитной карте (или наоборот). Пока обе базы данных не будут изменены правильным образом, любые действия над БД должны оставаться неподтвержденными. Если все порции транзакции выполнились успешно, то подтверждение производится над двумя БД. Это называется двухфазным подтверждением транзакций.
3.2. Microsoft SQL Server
Архитектура SQL Server позволяет программировать 2PC используя Координатор Распределенных Транзакций (Microsoft Distributed Transaction Coordinator [MSDTC]). MSDTC требует чтобы разработчик создавал объекты транзакций используя OLE. Если меняется приложение, то код 2PC должен быть повторно протестирован и сопровождаться все время жизни приложения. При этом сопровождаться должны не только клиентское приложение и база данных, но и объекты MSDTC также должны сопровождаться и координироваться с остальными частями системы. Это ухудшает переносимость, и требует дополнительных затрат на разработку и сопровождение.
3.3. Sybase SQL Server
В Sybase SQL Server, разработчики должны использовать 2PC для обеспечения целостности транзакций, производимых над разными БД. В двадцатитомной документации на Sybase System 10 есть только одно упоминание 2PC. Конечно, на WEB-сервере Sybase есть некоторое количество документов, поясняющее как обработку 2PC можно писать на C , FORTRAN , Pascal и COBOL . Каждый из этих примеров содержит более чем 100 строк кода. В результате разработчикам приходится создавать сложные внешние процедуры, недокументированные Sybase, и использовать другие языки программирования вместо использования естественных возможностей RDBMS. Переход на другую платформу может потребовать перекомпиляцию или переписывание кода. Как и в случае Microsoft SQL Server, необходимо сопровождать и синхронизировать внешние (по отношению к БД) объекты, что увеличивает стоимость разработки и усложняет сопровождение. Ситуация может еще больше осложниться, если используются серверы Sybase для разных платформ.
3.4. InterBase
InterBase обеспечивает автоматическую обработку 2PC в соответствии со всеми требованиями ACID без дополнительного программирования на любых платформах (Windows NT, DEC UNIX, HP-UX, Irix и т.д.). Это обеспечивает максимум легкости сопровождения при отсутствии дополнительных затрат.
4. CHAR и VARCHAR
4.1. Хранение
4.1.1. SQL Server
4.1.1.1. CHAR или VARCHAR
Практически во всех SQL-серверах реализовано два главных типа данных для хранения символьной информации. Первый - фиксированной длины, и известный как CHAR. В большинстве РСУБД CHAR занимает пространство фиксированной длины независимо от длины действительно хранимых данных. Свободное пространство поля типа CHAR "дополняется" до объявленной длины пробелами. Тип CHAR полезен если длина хранимых данных практически не меняется, например как для кодов стран и штатов США. CHAR может быть использован и для хранения имен или адресов, но это приведет к большим потерям дискового пространства.
VARCHAR хранит символьные данные с переменной длиной. Это значит что на диске распределяется пространства столько-же, сколько нужно для хранения символьных данных. Максимальная длина поля типа VARCHAR указывается при создании таблицы. Когда значение типа VARCHAR записывается на диск, РСУБД определяет его фактическую длину, и отводит под его хранение столько-же байт на диске. VARCHAR обеспечивает эффективное использование дискового пространства при хранении символьных данных, когда длина значения символьного поля варьируется в больших пределах.
4.1.1.2. Ограничения Длины
Длина типа VARCHAR в SQL Server ограничена 255 байтами. Если требуется хранение строк длиной более 255 символов, то необходимо использовать тип поля TEXT. Данные в поле типа TEXT хранятся как данные BLOb с размером сегмента 2K (минимальный размер страницы). Другими словами, даже если данные в поле TEXT занимают один байт или 1500 байт, SQL Server распределяет блок размером 2K для хранения значения поля. SQL Server жертвует дисковым пространством с целью обеспечения производительности при работе с полями BLOb. Разработчик должен тщательно планировать структуру базы данных для баланса между занимаемым дисковым пространством и производительностью, и иногда идти на компромисс, используя комбинацию из двух или более VARCHAR для хранения строковых данных, которые превышают 255 символов но гарантированно меньше 2К. Соответственно и приложение должно извлекать данные из таких полей и группировать их в одно поле для нормального представления данных..
4.1.2. InterBase
4.1.2.1. CHAR или VARCHAR
Как и семейство СУБД SQL Server, InterBase поддерживает типы как CHAR так и VARCHAR. С точки зрения клиентского приложения они выглядят так-же, как и в SQL Server. Это обеспечивает совместимость приложений. Внутри, InterBase обеспечивает хранение этих типов данных иначе, чем SQL Server. В InterBase, данные CHAR и VARCHAR хранятся одинаково - концевые пробелы обрезаются, и только строка фактической длины хранится в базе данных. В случае VARCHAR, когда данные запрашиваются с сервера, клиентскому приложению возвращается значение переменной длины. В случае CHAR, InterBase дополняет строку пробелами до длины, указанной в структуре таблицы, и возвращает данные как строку с фиксированной длиной. Кроме этого, InterBase использует алгоритм сжатия (RLE) для экономии места, занимаемого данными на диске, как для типа CHAR так и для VARCHAR.
4.1.2.2. VARCHAR
Максимальная длина поля типа VARCHAR в InterBase равна 32K (такое-же ограничение длины имеет и CHAR).Разработчик может использовать всю выгоду от VARCHAR без ограничения в 255 символов. Такая возможность имеет большое значение для разработчиков, которые хотят производить поиск или манипулировать большими потоками текста, такими как поля MEMO, без необходимости использовать поля BLOb и их ограничений [в реализации Sybase и Microsoft]. Если размер данных MEMO может превысить 32K, то только InterBase позволяет эффективно использовать тип BLOb с определяемым размером сегмента. Кроме этого, операции поиска LIKE, CONTAINING и STARTING WITH можно применять к CHAR, VARCHAR и BLOB-полям любого типа.
4.2. Производительность
4.2.1. SQL Server
При всей очевидности гибкости и эффективности хранения символьных данных в полях типа VARCHAR может показаться, что это наилучший выбор для хранения символьных данных. Напротив, использование VARCHAR в SQL Server приводит к ухудшению производительности из-за дополнительных затрат на извлечение данных. Поэтому разработчики должны выбирать между эффективным хранением и эффективным извлечением данных.
4.2.2. InterBase
И наоборот, поскольку способ хранения CHAR и VARCHAR в InterBase идентичен, разработчик никогда не заботится о выборе типа данных с учетом производительности. Вместо этого разработчик может основать свой выбор на том, как представляется соответствующий тип данных в клиентском приложении. Разработчик также может не беспокоиться об оптимальном хранении данных и о затратах дискового пространства, поскольку InterBase использует алгоритмы сжатия строковых данных.
4.3. Модификация CHAR и VARCHAR "на месте"
4.3.1. SQL Server
Пространство, распределяемое для индивидуальных значений VARCHAR, определяется при первом сохранении записи на диск. Любые произвольные модификации значений VARCHAR могут потребовать другого пространства для хранения данных. Изменение размера данных приводят к тому, что SQL Server перераспределяет пространство для данных на основе их новой длины. Например, если пользователь обновляет список поставщиков, и модифицирует адрес с “6475 Christie Avenue” на “100 Borland Way”, то SQL Server должен удалить запись целиком и добавить ее в таблицу чтобы произвести обновление данных.
Существует несколько замечаний, относящихся к этому процессу:
- Transaction Log: Каждое удаление или вставка приводит к регистрации этого действия в Transaction Log. Периодически администратор БД должен очищать записи в Transaction Log. Неправильно или нерегулярно обслуживаемые transaction logs могут переполниться и вызвать "падение" SQL Server. Для небольших организаций, без специально выделенного администратора БД, это может стать катастрофой.
- Длинные транзакции: Длинные транзакции, обновляющие большое количество значений полей VARCHAR могут блокировать последние страницы данных таблицы на длительный период времени. Транзакция, обновляющая поле типа VARCHAR у каждой записи таблицы приведет к тому, то все записи будут удаляться из таблицы и добавляться в ее конец. Это может привести к росту transaction log большему, чем рост данных в базе данных.
- Свободное пространство: Пространство, занимаемое удаленными записями остается незаполненным, пока над базой данных не будут произведены процедуры по ее сопровождению. В результате таблица может занимать пространство более чем вдвое превышающее реальный объем данных плюс размер transaction log, который вырос в результате регистрации удаления старых записей и добавления обновленных.
- Неуспешные транзакции: Добавление обновленной записи перемещает изменяемую запись в конец таблицы. Это действие блокирует последние страницы таблицы пока не завершится транзакция. Другие пользователи, создающие новые записи, или редактирующие записи с полями VARCHAR, могут также делать попытки записи в конец таблицы. В архитектуре SQL Server, существует много ситуаций, когда "читатели" блокируют "писателей". Поэтому, другие пользователи могут заблокировать обновление записей с полями VARCHAR из-за блокировок последних страниц таблицы, вызывая неуспешное выполнение транзакции.
- Производительность: Блокировка дополнительных страниц ухудшит пропускную способность БД, заставляя пользователей ожидать окончания блокировок страниц. При большом количестве записей, содержащих поля VARCHAR, производительность может существенно упасть.
4.3.2. InterBase
InterBase перераспределяет пространство для хранения VARCHAR "на лету". Это означает что процесс "удаление-добавление", используемый в архитектуре SQL Server, не возникает в InterBase. Вместо этого на странице данных добавляется версия значения CHAR или VARCHAR (delta), а модифицируемая запись остается на своем месте и не модифицируется. Результатом такого механизма является максимальная производительность при обновлениях CHAR и VARCHAR. Кроме этого, в InterBase отсутствует transaction log (благодаря многоверсионности записей), что не только повышает производительность, но и избавляет администратора БД от дополнительной работы. Никаких других блокировок, кроме блокировки обновленной записи от обновления ее другими пользователями, не возникает.
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-сервером, действия по восстановлению БД будут абсолютно идентичны для любой платформы.
Восстановление БД может производиться между любыми операционными системами. Т.е. файл 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 не требует памяти больше, чем базовая память для операционной системы. Он динамически использует ресурсы диска и памяти без вмешательства администратора БД.