Номер варианта

1

2

3

4

5

Начальные данные

Число рабочих станций

30

30

30

30

30

Время дообработки запроса на рабочей станции

0

0

300

0

300

Время формирования запроса на рабочей станции

300

300

300

300

300

Время канала (пр.)

20

20

20

20

40

Время канала (обр.)

20

20

20

40

40

Число процессоров

1

1

1

1

1

Время обработки в процессоре

10

10

10

10

10

Число дисков в системе

2

2

2

2

2

Время обработки в диске

20

20

20

20

20

Вероятности обращения к дискам

0,5 0,5

0,5 0,5

0,5 0,5

0,5 0,5

0,5 0,5

Вероятность обратного перехода на обработку ()

0

0,5

0

0,5

0,5

Результат моделирования.

Загрузка процессора

0,248

0,508

0,247

0,323

0,251

Загрузка дисков 1

2

0,250

0,244

0,484

0,505

0,255

0,256

0,330

0,329

0,253

0,268

Загрузка канала

0,999

0,999

0,999

0,999

0,999

Время реакции системы

872,48

872,82

890,21

1464,71

1989,66

№

Модель

Загрузка устройств

Время реакции

Pk

Pп

Pд1

Pд2

1

Аналитическая

Имитационная

0,986

0,999

0,246

0,248

0,246

0,250

0,246

0,244

916,51

872,48

2

Аналитическая

Имитационная

0,982

0,999

0,491

0,508

0,491

0,484

0,491

0,505

921,69

872,82

3

Аналитическая

Имитационная

0,965

0,999

0,241

0,247

0,241

0,255

0,241

0,256

943,41

890,21

4

Аналитическая

Имитационная

0,990

0,999

0,330

0,323

0,330

0,330

0,330

0,329

1517,85

1464,71

5

Аналитическая

Имитационная

0,986

0,999

0,246

0,251

0,246

0,253

0,246

0,268

2133,02

1989,66

Borland InterBase 4.x

MicrosoftS SQL Server

Sybase SQL Server

1. Требования к аппаратному обеспечению.

1.1. Процессор

386 (486 и выше)

386 (486 и выше)

386 (486 и выше)

1.2. Оперативная память

8(16) М.

16(32) М.

8 М.

1.3. Свободное место на диске

<10 М.

35 М.

<20 М.

2. Механизмы блокировок.

Целостность данных - самое важное качество для корпоративных данных. Существует много способов для обеспечения целостности данных в RDBMS. Наиболее распространены пессимистическая и оптимистическая схемы блокировок. Пессимистические блокировки - простейший в реализации способ, когда блокируются страницы, индексы или таблицы для обеспечения целостности транзакции. Оптимистические блокировки предполагают отсутствие блокировок для клиентского приложения. При этом используются более сложные механизмы для обеспечения целостности транзакции. Оптимистические блокировки, обеспечивая целостность данных, обладают оптимальной производительностью и легкостью в использовании.

InterBase обеспечивает оптимистические блокировки при помощи Архитектуры Многоверсионности Записей (Multi-Generational Architecture- [MGA]). Этот механизм создает оптимизированные версии для новых, удаленных или обновляемых записей, которые видны только в контексте конкретной транзакции, изменяющей данные. Реально, InterBase версионирует только изменяемые столбцы (поля) путем создания deltas. Это обеспечивает максимальную производительность и минимальные требования к дисковому пространству.

Состояние "невидимости" версионированных записей

длится только в течение

2.1. Страничные Блокировки.

Для того, чтобы гарантировать целостность данных, архитектура SQL Server использует механизм блокировок страниц данных. Страница данных это набор записей, хранимых в некоторой области жесткого диска на сервере. Все страницы имеют один и тот же размер, который определяется конфигурацией сервера и базы данных. В зависимости от длины записей и размера страницы, страница может содержать определенное количество записей. Записи в большинстве случаев добавляются в конец таблицы. Базовый размер страницы в SQL Server равен 2K, и это является минимальной единицей блокировки. Страничные блокировки требуют от разработчика глубоких знаний о конкурентной работе с данными и настройке кода для получения максимально конкурентного доступа. Страничная блокировка блокирует все записи или соответствующие ссылки в индексах, хранимые на одной странице. Например, если размер записи в таблице равен 100 байт, а размер ключа индекса равен 10 байт, то блокировка одной страницы данных и одной страницы индекса приведет к куммулятивному эффекту блокирования 18-ти записей и 180-ти ключей индекса.

Figure 1 SQL Server Page Locks

транзакции. После подтверждения (committing) транзакции, измененные записи становятся видимы транзакциям, стартовавшим до завершения этой транзакции.

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

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

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

2.2. Блокировки Индексов.

Индексы SQL Server блокируются точно так-же, как и страницы данных соответствующих таблиц, однако эффект блокировки страницы индекса значительно шире. Записи в таблице хранятся в большинстве случаев в случайном порядке (исключение составляют кластерные индексы). Когда обновляется страница данных, то должен обновиться соответствующий индекс. Как и у таблиц, данные индексов хранятся на страницах. Для обновления страницы индекса, эта страница должна быть сначала заблокирована. Если данные в таблице распределены случайным образом, то блокировка страницы индекса приведет к блокировке большого количества страниц данных, поскольку страница индекса ссылается на большое количество страниц данных. Это значит что модификация одного ключевого значения на странице может заблокировать множество совершенно посторонних записей на страницах данных.

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

2.3. Блокировки Таблиц.

Целостностное представление базы данных иногда требует уровня изоляции "воспроизводимое чтение". "Воспроизводимое чтение" гарантирует неизменность видимых данных на время действия транзакции. Это очень важно в финансовых приложениях или при создании отчетов по большим объемам данных в то время как другие пользователи модифицируют записи. Для обеспечения целостного представления данных в Sybase или Microsoft SQL Server разработчик должен использовать блокировки таблиц.

2.4. Эскалация страничных блокировок

в Блокировке Таблиц.

Длинные транзакции, затрагивающие большое количество записей, требуют большого количества страничных блокировок. Как только количество страничных блокировок достигает определенного предела, SQL Server автоматически включает полную блокировку таблицы. Назначение такого механизма в том, чтобы уменьшить работу RDBMS по управлению блокировками и обеспечению конкурентного использования данных, и чтобы предотвратить деградацию производительности. Естественно, что полная блокировка таблицы заблокирует другим пользователям доступ к этой таблицы. Эскалация может произойти как при обновлениях, так и при обычной выборке данных.

Для того, чтобы обрабатывать множество ограничений механизма блокировок SQL Server, разработчики должны использовать множество решений для оптимизации баланса между конкурентным доступом и производительностью; одно из них - использовать репликацию данных, над которыми может произоводиться длительная обработка (сложные отчеты). К сожалению, репликация в SQL Server является односторонней. Это ограничение часто делает невозможным использование репликации для более сложных задач.

В Microsoft SQL Server 6.5 механизм блокировок улучшен по сравнению с версией 6.0 и Sybase SQL Server поддержкой блокировок на уровне

В Sybase, репликация производится при помощи отдельного продукта, называемого “Replication Server”.

записей при вставке. Это увеличивает производительность вставки записей, но никак не решает другие проблемы со страничными, индексными или табличными блокировками. Поэтому, независимо от версии, обновление данных в архитектуре SQL Server все-равно требует табличных или страничных блокировок для обеспечения целостности данных.

Результаты тестов на производительность в основном зависят от механизмов блокировок, используемых в тестируемой СУБД. Страничные и табличные блокировки SQL серверов Microsoft и Sybase могут сильно влиять на производительность, когда многим пользователям требуется доступ к одним и тем-же данным (или находящимся на близлежащих страницах). Например, в реальных ситуациях, страничные блокировки в SQL Server могут замедлять доступ к данным (ожидание освобождения блокировок страниц, индексов или таблиц). Этот эффект может быть заметен в системах с большим объемом данных или когда пользователи выполняют создание длительных отчетов по данным в тот момент, когда другие пользователи модифицируют данные. Архитектура Многоверсионности Записей InterBase гарантирует доступность данных на чтение для любых пользователей и в любое время. Клиентское приложение никогда не ждет доступности таблиц, записей или индексов, независимо от числа пользователей в системе или длительности и сложности какой-либо транзакции. Разработчики, использующие InterBase, автоматически получают максимум производительности приложений, безотносительно сложности обработки данных.

3. Двухфазное подтверждение транзакций.

Слово "транзакция" произошло от слияния слов "акция трансформации". Транзакция это действие или группа действий, которые переводят систему из одного целостного состояния в другое. Транзакци характеризуются свойствами ACID:

Atomicity (атомарность) - "все или ничего". Либо вся транзакция завершается, либо ни одна из ее частей. Если транзакция не может быть завершена, то все операции, произведенные внутри транзакции, отменяются.

Consistency (целостность) - Транзакция должна переводить базу данных из одного целостного состояния в другое. Целостность определяется бизнес-правилами (логикой базы данных) и вводится в действие приложением.

Isolation (изоляция, изолированность) - Поскольку может возникать множество конкурентных транзакций, каждая транзакция должна быть изолирована от действий, производимых другими транзакциями. Т.е. транзакции должно "казаться", что она является единственной, выполняемой над базой данных.

Durability (прочность) - Изменения, подтвержденные транзакцией, обязаны вступить в силу.

Two Phase Commit – 2PC - это механизм, который применяет к  изменениям в обоих базах данных свойства ACID. Двухфазное подтверждение транзакций имеет две

отдельные фазы: подготовка и подтверждение. Если по какой-то причине процесс не может быть выполнен в течение фазы подготовки, то транзакция должна быть отменена

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

выполнились успешно, то подтверждение производится над двумя БД. Это называется двухфазным подтверждением транзакций.

InterBase обеспечивает автоматическую обработку 2PC в соответствии со всеми требованиями ACID без дополнительного программирования на любых платформах (Windows NT, DEC UNIX, HP-UX, Irix и т.д.). Это обеспечивает максимум легкости сопровождения при отсутствии дополнительных затрат.

Архитектура SQL Server позволяет программировать 2PC используя Координатор Распределенных Транзакций (Microsoft Distributed Transaction Coordinator [MSDTC]). MSDTC требует чтобы разработчик создавал объекты транзакций используя OLE. Если меняется приложение, то код 2PC должен быть повторно протестирован и сопровождаться все время жизни приложения. При этом сопровождаться должны не только клиентское приложение и база данных, но и объекты MSDTC также должны сопровождаться и координироваться с остальными частями системы. Это ухудшает переносимость, и требует дополнительных затрат на разработку и сопровождение.

В Sybase SQL Server, разработчики должны использовать 2PC для обеспечения целостности транзакций, производимых над разными БД. В двадцатитомной документации на  Sybase System 10 есть только одно упоминание 2PC. В результате разработчикам приходится создавать сложные внешние процедуры, недокументированные  Sybase, и использовать другие языки программирования вместо использования естественных возможностей RDBMS. Переход на другую платформу может потребовать перекомпиляцию или переписывание кода. Как и в случае Microsoft SQL Server, необходимо сопровождать и синхронизировать внешние (по отношению к БД) объекты, что увеличивает стоимость разработки и усложняет сопровождение. Ситуация может еще больше осложниться, если используются серверы Sybase для разных платформ.

4. CHAR и VARCHAR. Хранение и производительность.

Практически во всех SQL-серверах реализовано два главных типа данных для хранения символьной информации. Первый - фиксированной длины, и известный как CHAR. В большинстве РСУБД CHAR занимает пространство фиксированной длины независимо от длины действительно хранимых данных. Свободное пространство поля типа CHAR "дополняется" до объявленной длины пробелами. Тип CHAR полезен если

длина хранимых данных практически не меняется, например как для кодов стран и штатов США. CHAR может быть использован и для хранения имен или адресов, но это приведет к большим потерям дискового пространства.

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

Максимальная длина поля типа VARCHAR в InterBase равна 32K (такое-же ограничение длины имеет и CHAR). Разработчик может использовать всю выгоду от VARCHAR без ограничения в 255 символов. Такая возможность имеет большое значение для разработчиков, которые хотят производить поиск или манипулировать большими потоками текста, такими как поля MEMO, без необходимости использовать поля BLOb и их ограничений [в реализации Sybase и Microsoft]. Если размер данных MEMO может превысить 32K, то только

InterBase позволяет эффективно использовать тип BLOb с определяемым размером сегмента. Кроме этого, операции поиска LIKE, CONTAINING и STARTING WITH можно применять к CHAR, VARCHAR и BLOB-полям любого типа.

Поскольку способ хранения CHAR и VARCHAR в InterBase идентичен, разработчик никогда не заботится о выборе типа данных с учетом производительности. Вместо этого разработчик может основать свой выбор

Длина типа VARCHAR в SQL Server ограничена 255 байтами. Если требуется хранение строк длиной более 255 символов, то необходимо использовать тип поля TEXT. Данные в поле типа TEXT хранятся как данные BLOb с размером сегмента 2K (минимальный размер страницы). Другими словами, даже если данные в поле TEXT занимают один байт или 1500 байт, SQL Server распределяет блок размером 2K для хранения значения поля. SQL Server жертвует дисковым пространством с целью обеспечения производительности при работе с полями  BLOb.

При всей очевидности гибкости и эффективности хранения символьных данных в полях типа VARCHAR может показаться, что это наилучший выбор для хранения символьных данных. Напротив, использование VARCHAR в SQL Server приводит к ухудшению производительности из-за дополнительных затрат на извлечение данных. Поэтому разработчики должны выбирать между эффективным хранением и эффективным извлечением данных.

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

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

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

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

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

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

InterBase полностью поддерживает модель OLCP. Уникальная архитектура многоверсионности записей гарантирует, что пользователи транзакций  OLTP не обнаружат блокировок при обновлении данных, используемых транзакциями DSS, в то время как транзакциям DSS гарантируется воспроизводимое чтение. Кроме этого, пользователь не столкнется со страничными, индексными или табличными блокировками ни в какой ситуации. Вместо блокировок IB обеспечивает версии записей, которые всегда представляют целостный вид на базу данных во время действия транзакции. Многоверсионность записей гарантирует воспроизводимость состояния БД как для чтения, так и возможность обновления данных независимо от уровня изоляции транзакции. Это снижает сложность и время разработки клиентских программ, и обеспечивает доступность корпоративных данных в любой момент.

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

В настоящее время фирма Sybase выпустила специальный продукт, позволяющий работать с DSS-транзакциями - Sybase IQ. Это специальный продукт, который предназначен для выполнения транзакций DSS только в режиме чтения (и фактически только по архивным, а не оперативным данным). Обновление такой БД в режиме OLTP практически невозможно из-за специально применяемых структур данных. Таким образом задачи OLTP и DSS у Sybase решаются при помощи двух отдельных продуктов - Sybase System 11 и Sybase IQ соответственно).

6. Установка.

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

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

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

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

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

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

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

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

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

7.1. Резервное копирование.

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

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

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

свою работу. Такая остановка требует вмешательства

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

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

квалифицированного администратора БД для устранения проблем. Это также блокирует работу пользователей на время, требуемое для восстановления БД в рабочее состояние.

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

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

Borland InterBase не использует transaction log для хранения информации о транзакциях и изменениях, которые они производят. Вместо этого

используются Transaction Inventory Pages [TIP]. На этих страницах хранится

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

transaction log зависит от длины записи. Для коротких

записей отношение размера log к размеру данных может достигать 10:1. Для длинных записей это отношение

информация о состоянии любой транзакции: активная, подтвержденная, отмененная или подоготовленная (для двухфазного потдтверждения транзакций (2PC).  В случае системного сбоя, как только сервер будет запущен, будут автоматически просканированы TIP с целью поиска неподтвержденных транзакций. Все записи, найденные в неподтвержденном состоянии, будут отменены. Этот процесс практически для БД любого размера происходит в течение нескольких секунд.

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

меньше.

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

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

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

Контрольные точки в Borland InterBase не используются. Вместо этого применяется синхронное и асинхронное

Архитектура SQL Server требует чтобы администратор установил контрольные точки для БД. Контрольные точки - это интервалы времени, через которые происходит запись накопленных в кэше SQL-сервера изменений на диск (transaction logs и страницы

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

данных).

Если изменения происходили между двумя checkpoint, и в это время произошел сбой, то данные будут потеряны.

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

Borland InterBase автоматически конфигурируется и настраивается и не требует никакого вмешательства администратора в настройки. Это максимально облегчает управление и сопровождение. В общем случае, у IB существует не более конфигурационных 20 параметров, которые практически никак не влияют друг на друга (основных параметров всего 3 – размер кэша и лимиты занимаемой

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

В Sybase System 11 появилось более 200 параметров настройки. Это добавляет сложности к управлению сервером, стоимость обучения администратора БД, и предполагает что по мере усложнения используемой базы

данных может

памяти). Это сделано специально для уменьшения стоимости сопровождения и обслуживания. После установки, вмешательство администратора БД требуется разве что в случае катастрофического сбоя оборудования, или для регулярного выполнения bakup, который можно автоматизировать при помощи утилиты AT на Windows NT, или специальных утилит на UNIX.

потребоваться настройка севера.

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

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

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

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

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

существовании таковых они переводятся в отмененное состояние.

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

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

№

Статья сметы затрат

Сумма (руб.)

1

Материалы

688

2

Оборудование

3602,5

3

Услуги сторонних организаций

6

4

Заработная плата

1931,44

5

Отчисления на социальные нужды

743,60

6

Накладные расходы

697,15

7

Себестоимость

7668,69

8

Прибыль

2070,55

9

Цена

9739,24

10

Продажная цена

11687,09

Наименование

Количество

Цена (руб.)

Бумага формата А4 (высокого качества: плотность 80 г/м²).

1 пачка (500 листов)

120

Картридж для принтера OKI Page 4w

1 шт.

528

Дискеты MF 2HD (Verbatim).

4 шт.

40