Основными недостатками данной СУБД
является относительная сложность администрирования и отсутствие (пока)
реализаций под популярные серверные ОС, например LINUX. В данной СУБД благодаря
IndexSmart-Guide возможно осуществлять настройку, формируя оптимальные индексы
для заданного числа обращений, характеризующего типичную нагрузку на БД.-
единственный пакет позволяющий генерировать сводные таблицы, что значительно
эффективность работы СУБД в качестве хранилищ данных. Сводная таблица - это
временная рабочая область, используемая базой данных для хранения ответов на
часто поступающие запросы. Модель DB2 6.1 превращается в самую недорогую из
высокопроизводительных систем. Средства административного управления этой СУБД
вполне соответствуют уровню решаемых задач, кроме того, она предоставляет
исключительно широкие возможности для работы с мультимедиа-данными и для
программирования (чего явно недостает системе Microsoft SQL Server).
Таблица 2.1 - Информация о СУБД
|
Название
|
Дата
выпуска
|
Разработчик
|
Язык
|
|
DB2
|
1983
г.
|
IBM
|
С,
С++
|
|
Oracle
|
1979
г.
|
Oracle
Corporation
|
С
|
|
Microsoft
SQL Server
|
1989
г.
|
Microsoft
|
-
|
2.4 Сравнение производительности
Сравним выбранные СУБД по критерию
«Производительность».
Для тестирования производительности применяются
различные средства, и существует множество тестовых рейтингов. Одним из самых
популярных и объективных является ТРС-анализ производительности систем.
Показатель ТРС - это отношение количества запросов, обрабатываемых за некий
промежуток времени, к стоимости всей системы. Следует отметить, что для СУБД
PostgreSQL не проводится тест ТРС, а система MSSQLServer проводит собственные
тесты производительности.
Таблица 2.2 - Результаты теста TPC
|
Название
|
Количество
транзакций, tpmC
|
Стоимость
транзакции, долл./tpmC
|
Монитор
транзакций
|
|
MicrosoftSQLServer2005
х64
|
661,475
|
1.16USD
|
Microsoft
COM+
|
|
Oracle
Database Ng Standard
|
631,766
|
1.08
USD
|
Microsoft
COM+
|
|
IBM
DB2 9.5
|
1,200,011
|
1.99
USD
|
Microsoft
COM+
|
Производительность, наряду с
надежностью, - основной критерий выбора OracleDatabase в качестве системы
управления базами данных. Существуют синтетические тесты производительности,
такие, например, как TPC (www.tpc.org <http://www.tpc.org/>). В тесте
TPC-С, который проверят производительность СУБД в OLTP системе, OracleDatabase
занимает одну из лидирующих позиций.
На синтетических тестах и в реальной
работе очень часто любят показывать результаты тестирования MySQL или MS SQL
Server, в которых при небольшом объеме данных и специализированной нагрузке
производительность этих СУБД значительно превосходит производительность OracleDatabase
или, например, IBM DB2 UDB, т.е. продуктов, которые считаются СУБД
“промышленного уровня”. Это означает, что эти СУБД способны обрабатывать
фактически неограниченный объем данных и число работающих пользователей. Под
словами “неограниченный” следует понимать, что именно эти две СУБД являются
лидерами по хранимому объему данных и работающим пользователям, при этом
сохраняя весь свой разносторонний функционал.
Кроме того, если внимательно
посмотреть на синтетические тесты, то можно заметить тот факт, что
производительность OracleDatabase практически не меняется, а то и увеличивается
при возрастании обрабатываемого объема данных. Именно это свойство отличает
промышленную систему от настольной или системы рабочих групп. В этом - суть
промышленного сервера баз данных: устойчивость к нагрузке. Впрочем, это не
мешает СУБД Oracle лидировать в тестах и ставить мировые рекорды
производительности.
2.5 Сравнение масштабируемости
Сравним выбранные СУБД по пункту
«Масштабируемость». Он предполагает возможности рассматриваемой СУБД по
увеличению объема данных со временем и в случае необходимости. Необходимо
рассмотреть максимально возможный объем хранимых данных для каждой альтернативы
(таблица 2.3).
Таблица 2.3 - Анализ СУБД по пункту
«Масштабируемость»
|
Размер
БД
|
Размер
таблицы
|
Размер
строки
|
|
DB2
|
512ТБ
|
512
ТБ
|
32677
В
|
524258
ТБ
|
524258
ТБ
|
∞
|
|
Oracle
|
∞
|
4Гб*
Размер блока
|
8KB
|
В отличие от MS SQL Server, OracleDatabase
работает на большинстве известных платформ и операционных систем: Windows (в
том числе не серверные версии), Unix, Linux, MacOS. Это существенное
преимущество OracleDatabase. Преимущество заключается не только в том, что
сейчас Oracle оставляет заказчику выбор операционной системы и аппаратной
платформы, но и в том, что в корпорации существует опыт и культура разработки
именно кроссплатформенных систем, следовательно, при появлении новой
операционной системы, более мощной и эффективной, можно быть уверенным, что под
эту операционную систему или платформу появится версия OracleDatabase.
В случае, если СУБД базируется только на одной
операционной системе, то заказчик полностью зависит не только от производителя
собственно СУБД, но и от производителя операционной системы. Зависимость эта
тем более усугубляется, если производитель и СУБД и ОС - один и тот же.
2.6 Триггеры и хранимые процедуры
Сравним выбранные СУБД по критерию «Триггеры и
хранимые процедуры». Пункт «Триггеры и хранимые процедуры» определяет наличие в
некоторой СУБД класса процедур, функций. Триггер -программа базы данных,
вызываемая всякий раз при вставке, изменении или удалении строки таблицы.
Триггеры обеспечивают проверку любых изменений на корректность, прежде чем эти
изменения будут приняты. Хранимая процедура - программа, которая хранится на
сервере и может вызываться клиентом. Поскольку хранимые процедуры выполняются
непосредственно на сервере баз данных, обеспечивается более высокое
быстродействие, нежели при выполнении тех же операций средствами клиента БД.
Проведем анализ альтернатив по данному пункту.
Таблица 2.4 - Анализ СУБД по пункту «Триггеры и
хранимые процедуры»
|
Триггер
|
Функция
|
Процедура
|
|
DB2
|
+
|
+
|
+
|
|
MicrosoftSQLServer
|
+
|
+
|
+
|
|
Oracle
|
+
|
+
|
+
|
2.7 Размер блока
Блок базы данных - это наименьшая единица
информации, которую СУБД читает или записывает на жесткий диск или в
оперативную память. Например, чтобы прочитать одну строку из таблицы, которая
занимает 200 байт, требуется прочитать из памяти или жесткого диска блок
целиком, размер которого составляет, например, 8000 байт и затем извлечь из прочитанного
блока нужную строку. Очевидно, что в этом случае 7800 байт были прочитаны зря.
Обратная ситуация, когда требуется прочитать все строки таблицы, СУБД будет
вынуждена прочитать тем больше блоков, чем больше строк и больше размер одной
строки. Выгодно было бы прочитать 1 блок размером, например 32 килобайта, чем
читать 4 блока размером по 8 килобайт. Одной из приоритетных задач по настройке
производительности является минимизация количества логических чтений
(прочитанных блоков), и в OracleDatabase администратор имеет множество
механизмов для решения этой задачи.
Кроме того, в OracleDatabase реализован механизм
управления заполнением пространства блока (pct_free, pct_used), что позволяет
эффективно настраивать СУБД для решения той или иной задачи.
В SQL Server размер блока (pagesize) равен 8
килобайт и не может быть изменен, что сильно ограничивает возможность настройки
системы, особенно DSS систем (хранилища данных). В OracleDatabase размер блока
задается во время создания базы данных, и, более того, для каждого табличного
пространства может быть задан свой размер блока, например, для табличных
пространств с маленькими, часто меняющимися таблицами - меньший размер, для
табличных пространств с большими, редко изменяющимися таблицами, содержащими
большой объем данных - больший размер, что существенно может повлиять на
производительность системы в целом.
2.8 Индексы
В OracleDatabase поддерживаются различные типы
индексов, которые не реализованы в MS SQL Server, например: B-treeclusterindexes,
Hashclusterindexes, Reversekeyindexes, Bitmapindexes, Bitmapjoinindexes. Каждый
из типов индексов может обеспечить существенный прирост производительности в
той или иной ситуации.
Таблица 2.5 - Сравнение спектра
используемых индексов
|
Тип
индекса
|
OracleDatabase
|
MS
SQL Server
|
|
B-tree
|
Да
|
Да
|
|
Function-based
|
Да
|
Да
|
|
Bitmap
|
Да
|
Нет
|
|
Reverse
|
Да
|
Нет
|
Использование Bitmapindex позволяет значительно
ускорить выбор по полям с низкой селективностью, т.е. небольшим количеством
различающихся значений в поле. Использование такого типа индекса - один из
путей решения проблемы производительности в системах хранилищ данных.
Использование Reverseindex позволяет уменьшить
конкуренцию за блоки БД при вставке в поле монотонно нарастающих значений:
например, номеров документов или уникального ключа. Это еще один инструмент
администратора базы данных по повышению производительности системы без
увеличения мощности оборудования.
2.9 Стоимость обслуживания
Существуют различные исследования на
эту тему. Например, в исследованиях, опубликованных на сайте Microsoft, как
дважды два доказывается, что обслуживание SQL Server стоит намного дешевле и
требует меньше усилий со стороны администратора. На сайте Oracle опубликованы
не менее солидные и содержательные исследования <http://oracle.axoft.ru/images/edison_group_report_ru.pdf>,
в которых точно также неоспоримо доказывается факт более низкой стоимости
обслуживания именно OracleDatabase. Причем оба исследования проводятся
независимыми компаниями. Исходя из отзывов пользователей программы, можно
сказать, что администрирование SQL Server осуществляется из действительно
удобной и логично-простой среды SQL ServerManagementStudio. В OracleDatabase
также существует удобная и простая среда выполнения всех административных
действий: Enterprisemanager. Начиная с 10-й версии, EM имеет web-интерфейс.
Следует отметить, что из Oracle EM можно управлять не только единичным
экземпляром базы данных, но и кластером и сетью GRID-серверов.
В 10-й, и в 11-й версии
OracleDatabase улучшены и дополнены функции самоадминистрирования и
самодиагностики сервера. В 10-й версии появилась функции автоматического сбора
статистики, анализа и выдачи рекомендаций. Отслеживание различных показателей,
с выдачей сообщения при достижении пороговых или критических величин.
Анализатор SQL запросов позволяет
выбрать и настраивать наиболее тяжелые SQL запросы, причем предусмотрен
вариант, в котором администратор просто выбирает проблемный SQL запрос,
просматривает и применяет рекомендации SQL TuningAdvisor, все это происходит в
консоли EM. В MS SQL Server выполнение аналогичной задачи выполняется ручным
способом, на порядок дольше, чем в OracleDatabase, за исключением настройки
индексов.
Использование появившейся в 10-й
версии технологии Flashbacktable позволяет значительно упростить восстановление
после пользовательских ошибок. Больше не требуется восстановление из резервной
копии, достаточно выбрать удаленный объект и восстановить его из корзины.
Следует отметить, что в MS SQL Server также возможно выполнение аналогичной
операции, но требует значительно больше времени: требуется восстановление из
резервной копии, выбор точки восстановления и накат потерянных транзакций
вручную. Тоже самое касается и восстановления после ошибочной транзакции. В
OracleDatabase это делается как через консоль EM, так и вручную, SQL
операторами, причем требуется просто выбрать момент в прошлом, на который
требуется восстановление. В MS SQL Server восстановление также производится из
резервной копии с последующим ручным накатом журналов.
Таким образом, OracleDatabase
предоставляет пользователю три варианта:
полная самодиагностика и
самонастройка, которая совершенствуется от версии к версии, обобщая и базируясь
на опыте тысяч администраторов по всему и миру и математических моделях;
мощную и удобную консоль
администратора, не требующую установки какого-либо дополнительно ПО на
компьютер администратора, и, следовательно, доступную с любого компьютера в
сети, в том числе по сети Интернет, если это необходимо;
тонкие средства диагностики и
настройки, оставшиеся с прошлых версий и позволяющие администратору в полной
мери применить свои знания в области настройки производительности.
Аналогичные средства других СУБД
либо жестко ограничивают администратора ввиду полной автоматизации процессов
настройки, например, оперативной памяти, либо предоставляют менее богатый
функционал для выполнения стандартных операций.
2.10 IBM DB2
UDB и
OracleDatabase
DB2 UDB и OracleDatabase имеют
неофициальный статус баз данных «промышленного» уровня. Эти две СУБД во многом похожи,
но имеются и отличия, влияющие на эффективность и стабильность СУБД. В таблице
приведены некоторые отличия в работе внутренних механизмов этих СУБД.
Таблица 2.6 - Сравнение работы
внутренних механизмов этих программ
|
Свойство
|
Oracle
|
DB2
|
|
Конкурентная
модель
|
Мульти-версия
согласованность чтения Не эскалирует блокирование на уровне строк
|
Нет
Эскалирует блокировки
|
Прозрачная
масштабируемость с технологией RealApplicationClusters(RAC)
|
Rigid data partitioning required with DB2 EEE
|
|
Возможности
индексирования
|
Широкий
выбор схем индексации
|
ТолькоB-Tree
и
dynamic bitmap indexes
|
|
Опции
разметки(секционирования)
|
По
диапазонам ключей, хеш, по списку значений ключа и составное секционирование.
Локальные и глобальные индексы.
|
Только
хеш-секционирование Только локальные индексы
|
|
Возможности
складирования дополнительных данных
|
MERGE
Multi-table INSERT
|
Не
поддерживается Не поддерживается
|
|
Интеллектуальная
справка
|
Index,
Summary, Memory, MTTR
|
Indexadvisory
только
|
|
Возможности
самонастройки
|
Self-tuning memory, free space, and I/O
management
|
Нет
эквивалентных или ограниченных возможностей
|
В первой строке сравнивается механизм блокировок
и обеспечения целостности чтения. Более подробно в таблице:
Таблица 2.7 - Сравнение механизма блокировки обеспечения
целостности
|
Oracle9i
|
DB2
|
|
Multi-version
read consistency
|
Not
available
|
|
No
read locks
|
Requires read locks to avoid dirty reads
|
|
No
dirtyreads
|
Dirty reads if not using read locks
|
|
Non-escalating row-level locking
|
Locksescalate
|
|
Readersdon’tblockwriters
|
Readersblockwriters
|
|
Writersdon’tblockreaders
|
Writersblockreaders
|
|
Nodeadlocksunderload
|
Deadlocks can be a serious problem under load
|
Во второй строке - работа в кластере, Oracle RAC
и IBM EEE:
база данные оracle кластер
Таблица 2.8 - Сравнение работы кластеров
|
Oracle
RAC
|
DB2
EEE
|
|
No two-phase commit required
|
Requires
two-phase commit
|
|
Data cached in multiple nodes
|
IPC for every cross-partition access
|
|
Singleprobefordata
|
Multiplepartitionprobes
|
|
Uniformloaddistribution
|
Loadskewlikely
|
Более подробно по поддерживаемым типам индексов:
Таблица 2.9 - Сравнение поддерживаемых индексов
|
Тип
индекса
|
Oracle
|
DB2
|
|
ReverseKeyIndexes
|
Да
|
|
|
Function-basedIndexes
|
Да
|
Partial
|
|
DynamicBitmapIndexes
|
Да
|
Да
|
|
StoredCompressedBitmapIndexes
|
Да
|
|
|
BitmapJoinIndexes
|
Да
|
|
|
Index-organizedTables
|
Да
|
|
В OracleDatabase больше поддерживаемых вариантов
партиционирования:
Таблица 2.10 - Сравнение поддерживаемых
вариантов патриционирования
|
Вид
партиционирования
|
DB2
|
|
Rangepartitioning
|
Да
|
|
|
Listpartitioning
|
Да
|
|
|
Hashpartitioning
|
Да
|
Да
|
|
Compositepartitioning
|
Да
|
|
|
Localindex
|
Да
|
Да
|
|
Globalpartitionedindex
|
Да
|
|
|
Globalnon-partitionedindex
|
Да
|
|
Как мы видим хоть IBM DB2 UDB и OracleDatabase
обе являются СУБД промышленного уровня, несомненно что по функционалу и его возможностям
Oracle обходит своего оппонента (таблицы 2.7-2.11). Также наличие намного более
полной интеллектуальной справки и возможностей администрирования (эквивалента
которым нет в DB2)делают Oracleболее доступной в администрировании, а также
позволяют снизить затраты на самообслуживание этой СУБД.
Это в свою очередь делает Oracle менее затратной
в самообслуживании, при больших функциональных возможностях и большей
доступности для пользователей по сравнению с DB2.
Заключение
Подводя итоги, мы можем сказать, что в плане
доступности администрирования пользователями программа Oracle является лидером
среди рассматриваемых систем. Конечно мы заметим, что администрирование SQL
Server осуществляется из действительно удобной и логично-простой среды SQL
ServerManagementStudio, однако Oracle предоставляет как и полную
самодиагностику и самонастройку, так и тонкие средства диагностики и настройки,
позволяющие администратору в полной мери применить свои знания в области
настройки производительности. В результате в MS SQL Server идёт сразу после
Oracle, а на последнем месте оказывается DB2, характеризующаяся относительной
сложностью администрирования.
Затрагивая стоимость самообслуживания, мы также
можем сказать, что Oracle является более предпочтительным по сравнению со
своими оппонентами. Несомненно, что Oracle стоит больше чем MSSQLServerи тем
более DB2. Однако из-за большей доступности администрирования пользователями
затраты на её самообслуживание (обучение работников пользованию программой,
интеграция с другим ПО) в дальнейшем соответственно снижаются, что выдвигает её
вперёд. Конечно DB2 намного дешевле, но сложность администрирования и менее
полная интеллектуальная справка повышают цену самообслуживания этой системы в
дальнейшем.
Несомненно, что одним из важных пунктов выбора
СУБД является производительность. На синтетических тестах и в реальной работе
очень часто любят показывать результаты тестирования MySQL или MS SQL Server, в
которых при небольшом объеме данных и специализированной нагрузке
производительность этих СУБД значительно превосходит производительность
OracleDatabase и IBM DB2 UDB. Однако есть одно но, которое нужно учесть.
Производительность DB2 и Oracle практически не меняется, а то и увеличивается
при возрастании обрабатываемого объема данных. Это связано с тем, что обе эти
СУБД являются СУБД промышленного уровня, особенностью которых является
устойчивость к нагрузке. Так как цель своей работы я обозначил как поиск СУБД
для предприятия, я соответственно предполагаю, что объёмы данных будут довольно
большими, а нагрузка будет различной. Следовательно, я скорее выберу СУБД
промышленного уровня для своего предприятия, а не MSSQL. Если же выбирать из
DB2 и Oracle, то по производительности следует выбрать именно Oracle.
Ещё одним важным фактором выбора СУБД является
разнообразие функциональных возможностей. По этим показателям MSSQL проигрывает
своим оппонентам. DB2 и Oracle конечно похожи (обе являются СУБД промышленного
уровня), но возможности Oracle разнообразнее (те же возможности складирования
дополнительных данных и индексирования). В результате Oracle снова становится
победителем.
И последний фактор - наличие собственных
уникальных технологий. Тут на самом последнем месте оказывается MSSQL. Дальше
идёт DB2 со своими возможностями масштабирования (разработанная специалистами
IBM технология кластеризации баз данных не имеет аналогов)и генерирования
сводных таблиц (DB2-единственный пакет позволяющий генерировать сводные
таблицы, что значительно эффективность работы СУБД в качестве хранилищ данных).
На первом же месте оказывается Oracleсо своими технологиями RAC,
ActiveDataGuard, RAT,
TotalRecall,InMemoryDatabaseCache,AutomaticStorageManagement.Они позволяют
увеличить надёжность системы и данных, производительность, дают новые
возможности разгрузки базы данных.
В конечном итоге, по-моему мнению Oracle
является самым приемлемым и перспективным вариантом для предприятий.
Список используемых источников
1. “Система
управления базами данных (СУБД), Назначение и основные функции”. [Электронный
ресурс].URL:<http://www.infosgs.narod.ru/31.htm>
. “Базы
данных - Урок 1. Понятие базы данных”. [Электронный ресурс].
URL:<http://www.site-do.ru/db/db1.php>
. “Базы
данных - Урок 2. Структура базы данных”. [Электронный ресурс].
URL:http://www.site-do.ru/db/db2.php
. “Классификация
баз данных”. [Электронный ресурс].
URL:<http://cs.karelia.ru/studies/filatova_information/CMD_1996566_M/my_files/Inform/DataBase/a-2.htm>
. “Основные
функции СУБД”.[Электронный ресурс].
URL:<http://citforum.ru/database/osbd/glava_6.shtml>
. “Система
управления базами данных”.[Электронный ресурс].
URL:<https://ru.wikipedia.org/wiki/Система_управления_базами_данных>
. “Преимущества
СУБД Oracle”. [Электронный
ресурс].URL:<http://oracle.axoft.ru/fordev/advantagesOracle.php>