Варианты поставки Sybase eaServer. Системы управления базами данных и поддержки информационных хранилищ (IBM DB2)

Система управления базами данных IBM DB2 начинает свое развитие в далеких 70-х годах и сейчас занимает прочное положение на рынке корпоративных СУБД, отвечая высоким требованиям к производительности, надежности, безопасности и масштабируемости.

Игорь Булатенко, специалист по информационной безопасности, Positive Technologies

Система управления базами данных IBM DB2 начинает свое развитие в далеких 70-х годах и сейчас занимает прочное положение на рынке корпоративных СУБД, отвечая высоким требованиям к производительности, надежности, безопасности и масштабируемости. В частном секторе система DB2 не получила широкого распространения, несмотря на наличие бесплатной версии IBM DB2 Express. Возможно, именно из-за этого в Интернете не так много статей по поводу настройки и использования DB2.

Модель безопасности DB2 обладает широким функционалом и позволяет защитить данные как от внешнего воздействия, так и разграничить права доступа для внутренних пользователей средствами самой СУБД.

Однако неподготовленному пользователю сложно с нуля разобраться во всем этом многообразии, поэтому некоторые важные аспекты будут рассмотрены в данной статье.

Точка входа

Точка входа в DB2 выглядит следующим образом: СУБД -> экземпляр (instance), который может быть привязан к определенному порту -> имя конкретной базы данных. Настройки безопасности могут быть изменены как в конкретном экземпляре, так и в конкретной базе данных.

Аутентификация

Аутентификация - это первоочередной механизм безопасности, который применяется, когда вы пытаетесь соединиться с сервером DB2. При аутентификации проверяется корректность предоставляемых учетных данных. Главной особенностью в DB2 является то, что аутентификация пользователей производится только внешними плагинами. Внутренних пользователей, в отличие от Oracle или MS SQL Server, здесь не существует. Даже функция создания пользователя, которая есть в программе IBM Data Studio, на самом деле не создает пользователя, а назначает указанному пользователю привилегию на соединение с базой данных.

Существует несколько вариантов аутентификации, нужный вариант регулируется параметром AUTHENTICATION в менеджере базы данных. Значение данного параметра влияет на то, где будет производиться аутентификация клиентов (на стороне сервера или на стороне клиента) и будут ли данные передаваться в зашифрованном виде (значения с окончанием _ENCRYPT). Поддерживаемые значения данного параметра доступны по следующему адресу:

Просмотреть конфигурацию менеджера базы данных можно с помощью запроса к таблице sysibmadm.dbmcfg, но для этого нужно иметь доступ к любой из баз данных, что не всегда возможно. Если у вас есть локальный доступ к серверу, то можно открыть процессор командной строки (db2 или db2.exe в Windows), соединиться с экземпляром и выполнить следующие команды:

Db2 => attach to db2inst1
db2 => get database manager configuration

Значением по умолчанию для параметра AUTHENTICATION является SERVER. Проверка правильности предоставленных учетных данных пользователя производится на стороне сервера средствами операционной системы, но все данные при этом передаются в открытом виде и могут быть перехвачены злоумышленником.

Рассмотрим, каким образом выглядит перехваченная информация в Wireshark.

Переданные от клиента логин и пароль видны в пакете при просмотре EBCDIC.

При изменении типа аутентификации на SERVER_ENCRYPT логин и пароль будут передаваться уже в зашифрованном виде и проверяться на стороне сервера.

Значение изменяется следующим образом:

Db2 => attach to db2inst1
db2 => update database manager configuration using authentication server_encrypt
db2 => db2stop force
db2 => db2start

Пакет аутентификации при этом будет выглядеть так:

Однако текст запросов и результат будет все равно передаваться в открытом виде.

Пакет с запросом в Wireshark:

Пакет с ответом в Wireshark:

В случае, если для параметра AUTHENTICATION настроено значение DATA_ENCRYPT, то шифруются учетные данные пользователя, а также информация, передаваемая между клиентом и сервером.

Значение изменяется аналогично рассмотренному выше примеру:

Db2 => attach to db2inst1
db2 => update database manager configuration using authentication data_encrypt
db2 => db2stop force
db2 => db2start

После этого передаваемые данные также будут шифроваться:

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

Если же вдруг по какой-то причине необходим такой тип аутентификации, то нужно учесть, что существует еще два дополнительных параметра, которые в конечном итоге влияют на то, как будет проходить проверка учетных данных пользователя. Это параметр trust_allclnts , с помощью которого можно указать, каких клиентов считать доверенными, и параметр trust_clntauth , определяющий, где проверять логин и пароль, если они были переданы при соединении. Оба этих параметра влияют на аутентификацию, только если параметр AUTHENTICATION имеет значение CLIENT.

В случае успешной аутентификации ID пользователя соотносится с идентификатором DB2. Обычно идентификатор совпадает с именем пользователя, но в нем используются символы верхнего регистра.

Авторизация

Полномочия уровня конкретного экземпляра прописываются в конфигурации менеджера БД. Речь идет о следующих полномочиях:

• SYSADM (полномочия администратора системы);
• SYSCTRL (полномочия на управление системой);
• SYSMAINT (полномочия на обслуживание системы);
• SYSMON (полномочия на мониторинг системы).

Задаются данные привилегии с помощью указания той группы, в которую будет входить пользователь. Для этого используются следующие параметры файла dbmcfg (соответственно указанным выше полномочиям):

Легко получить список пользователей, которые входят в группу, средствами DB2 нельзя, нужно делать это в самой операционной системе или анализировать, в какие группы входит конкретный пользователь (запрос см. на вкладке "полезные запросы").

При настройке DB2 обязательно необходимо проверить список пользователей, которым назначено полномочие SYSADM. Это полномочие позволяет управлять всеми объектами базы данных.

Полномочия конкретной базы можно посмотреть в представлении SYSCAT.DBAUTH . Обратите внимание на привилегию CONNECTAUTH, которая определяет, будет у пользователя доступ к БД или нет, и привилегию NOFENCEAUTH, которая отвечает за создание неизолированных (not fenced) процедур и функций. Такие процедуры выполняются в адресном пространстве базы данных и, в случае ошибки, могут нарушить целостность базы данных и таблиц в ней.

Привилегии

Привилегии подпрограмм (функций, процедур и методов) можно посмотреть в представлении SYSCAT.ROUTINEAUTH . Здесь все не совсем тривиально, в зависимости от полей SPECIFICNAME и TYPENAME привилегии могут быть выданы на все подпрограммы заданной схемы.

Пользователи, группы, роли

Также, в DB2 существует встроенная роль PUBLIC. Пользователю базы данных нет необходимости предоставлять роль PUBLIC: отозвать у пользователя роль PUBLIC невозможно. Когда привилегия предоставляется роли PUBLIC, фактически происходит предоставление привилегии всем пользователям базы данных. Не следует выдавать какие-либо полномочия базы данных роли PUBLIC. Привилегии на таблицы и представления стоит выдавать с крайней осторожностью, только на просмотр и без возможности переназначения (WITH GRANT OPTION).

Из-за особенности аутентификации при выдаче привилегий существование пользователя или группы в системе не проверяется. В результате в системе могут появиться аутентификационные пользователи без привязки к реальным пользователям системы. Найти таких пользователей можно с помощью следующего SQL-запроса:

Для поиска подобных групп используется аналогичный запрос, но при этом в запросе указывается, что данные о PUBLIC выводить не нужно:

LBAC

Автоматические средства сканирования

Полезные запросы и команды

Получить настройки менеджера базы данных:

либо

Изменить параметр менеджера базы данных:

После этого необходим перезапуск экземпляра:

Получить настройки базы данных:

либо

Список пользователей операционной системы:

Список групп операционной системы:

Вывести текущее имя базы данных:

Ввести текущее имя пользователя:

Получить список групп, в которые входит пользователь:

Список всех установленных СУБД:

Список всех экземпляров в СУБД:

Ограничить количество выводимых строк:

СУБД IBM DB2 - результат почти 30-х опытно-конструкторских и исследовательских работ фирмы IBM. Последнюю на сегодня версию данной СУБД (6.х) отличает один из наиболее продуманных наборов средств управления и оптимизации и механизм БД, допускающий наращивание от портативного ПК с Windows 95 до целого кластера больших ЭВМ S/390, работающих под управлением OS/390.

Пакет DB2 выпускается в двух редакциях: DB2 Workgroup и DB2 Enterprise Edition. В данной СУБД реализованы все известные по предшествующим версиям DB2 новаторские технологии механизма БД, такие, как распараллеливание обработки запроса, полный набор средств тиражирования, сводные таблицы запросов для повышения производительности БД, возможности объектно-ориентированного конструирования баз данных и средства языка Java. К этому надо добавить, что система DB2 оснащена полым набором мультимедиа-расширений, позволяющих сохранять текст, звук и видео- фрагменты, изображения и географические данные и манипулировать ими. Можно говорить, что по возможностям масштабирования разработанная специалистами IBM технология кластеризации баз данных не имеет аналогов. Эти расширения существенно облегчают процесс разработки приложений для Web, а так же программ, содержащих фотоизображения и объемные текстовые отчеты. Система DB2 вполне конкурентоспособна и в качестве платформы для разработки приложжений т.к существует средство Stored Procedure Builder - автоматически преобразовывающее оператор SQL в соответствующий класс Java и включающее его в структуру базы данных. В версии DB2 6.1 значительно улучшена функциональная совместимость с другими СУБД: пакет позволяет использовать разработанную Microsoft спецификацию OLE DB, новый стандарт доступа к базам данных. Средства административного управления СУБД DB2, которые в новой версии переписаны на Java и могут быть получены из Web, заслуживают самой высокой оценки.

Основными недостатками данной СУБД является относительная сложность администрирования и отсутствие (пока) реализаций под популярные серверные ОС, например LINUX.

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

СУБД от Informix.

В последнее время наметился переход от реляционных СУБД к объектно-ориентированным (что явно прослеживается на примере Oracle). Informix также следуя данной концепции анонсировала новое решение СУБД Centaur базирующуюся на реляционной БД Informix Dynamic Server 7.3 и объектно-реляционной БД Informix Universal Data Option и сочетающую в себе высокое быстродействие Dynamic Server при работе с данными с универсальностью и мультимедиа функциями Universal Data Option. Данная реализация предназначена для разработки интернет систем. Предположительно данная СУБД будет обладать гибкой средой разработки, обладающей наращиваемостью, соответствующей характерным для Интернета интенсивным нагрузкам, и средствами работы с новыми типами данных, которые с развитием Web стали использоваться повсеместно. Реализованные в новой системе средства Java позволят разработчикам создавать на этом языке хранимые процедуры, пользовательские программы и компоненты DataBlades, которые в Informix называют заказными расширениями базы данных.

С точки зрения клиентов Inforix, это станет большим шагом вперед, поскольку до настоящего времени при работе с DataBlades они могли пользоваться только языком Си и SPL, внутренним языком фирмы Informix для написания хранимых процедур. Кроме того, пакет Centaur будет оснащен встроенными средствами обработки объектов ActiveX. Это даст возможность, к примеру, создавать хранимые процедуры БД на языке Visual Basic; правда, для этого нужно, чтобы пакет Centaur выполнялся в среде Windows NT.

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

Выводы.

Рассмотрев основные характеристики архитектур построения АИС, серверных операционных систем и СУБД в дальнейшем в качестве архитектуры АИС мы выберем архитектуру интернет/интранет, в качестве серверной ОС Linux, в качестве СУБД Oracle 8i. В сводной таблице представлены сравнительные характеристики двух наиболее распространенных на сегодня решений на базе Microsoft SQL Server 7.0 (на NT) и Oracle8i (на Unix, Linux).

DB2 (в русском языке произносится «диби́ два», также распространена калька с английского «диби́ ту») - семейство программных продуктов в области управления информацией компании IBM .

Чаще всего, ссылаясь на DB2, имеют в виду реляционную систему управления базами данных DB2 Universal Database (DB2 UDB), разрабатываемую и выпускаемую компанией IBM.

Иногда встречается написание «DB/2», но такое написание неверно: в системе обозначений IBM число в знаменателе дроби означает платформу и «/2» означает продукт для операционной системы OS/2 (или серии компьютеров PS/2). Например, версия DB2 для OS/2 обозначалась «DB2/2».

Реализации

В настоящее время СУБД DB2 представлена версиями на следующих платформах:

• DB2 for Linux, UNIX and Windows v9 для платформ AIX , HP-UX , Linux , Solaris , Windows и бета-версия для платформы Mac OS X
• DB2 for z/OS v9 для платформ z/OS и OS/390
• DB2 Server for VSE & VM v7 для платформ z/VM и z/VSE
• DB2 for i для платформы IBM i (встроена в систему на аппаратно-программном уровне)

В прошлом выпускались версии сервера СУБД DB2 для OS/2 , UnixWare , PTX.

Клиенты СУБД DB2, помимо перечисленных платформ, выпускаются или выпускались в различных версиях также для SINIX, IRIX , классической Mac OS и для MS-DOS , а также в мобильной версии DB2 Everyplace для Windows CE , Palm OS , Symbian OS , Neutrino и виртуальной машины Java .

В настоящее время, помимо коммерческих продуктов семейства, IBM распространяет также бесплатный дистрибутив DB2 Express-C для платформ Linux (x86, x86-64, POWER), Windows (x86, x86-64), Solaris (x86-64), Mac OS X (x86-64 beta). Бесплатная версия имеет ограничения на использование для работы СУБД не более одного двухъядерного процессора и 2 Гбайт оперативной памяти (общее количество процессоров и пямяти в системе может быть любым, но ресурсы сверх указанных ограничений не будут использоваться СУБД).

История

DB2 имеет долгую историю и, как некоторые считают, стала первой СУБД, использующей SQL .

С 1975 по 1982 год прототип DB2 разрабатывался в IBM под названием System Relational, или System R . Язык SQL впервые был реализован именно в IBM System R, но эта система имела исследовательский характер, а коммерческий продукт, включающий SQL, первой выпустила компания Oracle в 1979 году.

СУБД DB2 получила своё название в 1982 году, когда был выпущен первый коммерческий релиз для под названием SQL/DS, и затем релиз для MVS под названием DB2. Долгое время наряду с «DB2» употреблялся вариант «Database 2», также являющийся торговой маркой IBM. По всей видимости, имелось в виду, что это вторая флагманская СУБД IBM после старой иерархической СУБД IMS.

Развитие DB2 уходит корнями в начало 1970-х, когда доктор Э. Ф. Кодд , работавший на IBM, разработал теорию реляционных баз данных и в июне 1970 года опубликовал модель манипуляции данными. Для воплощения этой модели он разработал язык реляционных баз данных и назвал его Alpha. IBM предпочла передать дальнейшую разработку группе программистов, неподконтрольной доктору Кодду. Нарушив некоторые принципы реляционной модели, они реализовали её как «структурированный английский язык запросов», сокращённо SEQUEL. Поскольку SEQUEL было уже зарегистрированной торговой маркой, название сократили до SQL - «структурированный язык запросов», и таким оно осталось по сей день.

Таким образом, исторически СУБД DB2 возникла из продуктов DB2 для MVS (потомком которого является DB2 for z/OS) и родственного ему SQL/DS для VM (потомок - DB2 Server for VSE & VM). В дальнейшем другим коллективом разработчиков в IBM был реализован сервер OS/2 EE Database Manager, впоследствии эволюционировавший в DB2 v2 для OS/2, AIX и затем Windows, а потом в DB2 UDB (его потомок - DB2 for Linux, UNIX and Windows). Ещё одним коллективом была выполнена интеграция архитектуры DB2 со встроенной базой данных AS/400 (потомок - DB2 for i). IBM постепенно движется по пути интеграции всех этих веток.

Особенности

К отличительным особенностям DB2 относится диалект языка SQL, определяющий, за редкими исключениями, чисто декларативный смысл языковых конструкций, и мощный многофазовый оптимизатор, строящий по этим декларативным конструкциям эффективный план выполнения запроса. В отличие от других диалектов SQL, в диалекте SQL DB2 практически отсутствуют подсказки оптимизатору, мало развит (а долгое время вообще отсутствовал) язык хранимых процедур, и, таким образом, всё направлено на поддержание декларативного стиля написания запросов. Язык SQL DB2 при этом является вычислительно полным, то есть потенциально позволяет в декларативной форме определять любые вычислимые соответствия между исходными данными и результатом. Это достигается в том числе за счёт использования табличных выражений, рекурсии и других развитых механизмов манипулирования данными.

Благодаря приоритету IBM в развитии реляционной теории и позициям фирмы в компьютерной отрасли, диалект DB2 SQL оказывает значительное влияние на стандарты SQL ANSI /ISO .

Хранимые процедуры в DB2 не очень широко применяются, при этом традиционно для написания хранимых процедур используются обычные языки программирования высокого уровня (Си , Java , PL/I , Кобол и т.д.), это позволяет программисту легко оформлять один и тот же код либо как часть приложения, либо как хранимую процедуру, в зависимости от того, на клиенте или на сервере его целесообразнее выполнять. В настоящее время в DB2 также реализовано процедурное расширение SQL для хранимых процедур в соответствии со стандартом ANSI SQL/PSM.

Оптимизатор DB2 широко использует статистику распределения данных в таблицах (если процесс её сбора был выполнен администратором базы данных), поэтому один и тот же запрос на языке SQL может быть оттранслирован в совершенно различные планы выполнения в зависимости от статистических характеристик данных, которые он обрабатывает.

Поскольку исторически DB2 развивалась с многопользовательских систем на мейнфреймах , то большое внимание в архитектуре DB2 уделяется вопросам безопасности и распределения ролей обслуживающих DB2 специалистов. В частности, в отличие от многих других СУБД, в DB2 имеются отдельные роли для администратора СУБД (ответственного за конфигурирование программных компонентов DB2 и их оптимальное выполнение в компьютерной системе) и администратора базы данных (ответственного за управление данными в конкретной базе).

Использование при необходимости в программах статического SQL и концепции пакетов допускает, в отличие от большинства других СУБД, реализацию такой модели безопасности, когда права на выполнение определённых операций могут выдаваться прикладным программам при отсутствии таких прав у работающих с этими программами пользователей. Это позволяет в таком случае гарантировать невозможность работы пользователя с базой данных в обход прикладной программы, если у пользователя имеются только права на запуск программы, но не на самостоятельную манипуляцию данными.

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

DB2 является единственной реляционной СУБД общего назначения, имеющей реализации на аппаратно-программном уровне (система IBM i ; также в оборудовании мэйнфреймов IBM System z реализуются средства поддержки DB2).

Современные версии DB2 обеспечивают расширенную поддержку использования данных в формате XML , в том числе операции с отдельными элементами документов XML.

Обработка ошибок

Полезной особенностью SQL-сервера DB2 является возможность обработки ошибок. Для этой цели используется структура SQLCA (англ. SQL Communications Area - область связи SQL), возвращающая информацию об ошибке прикладной программе после каждого выполнения SQL-выражения.

Поля структуры SQLCODE и их значения

Основная, но не всегда полезная диагностика ошибки содержится в поле SQLCODE (тип данных - целое число) внутри SQLCA блока. Она может принимать следующие значения:

• 0 означает успешное выполнение.
• Положительное число означает успешное выполнение с одним или более предупреждениями. Например, +100 означает, что не найдены столбцы.
• Отрицательное число означает неудачу с ошибкой. Например, −911 означает обнаруженный истёкший интервал ожидания блокировки (или мёртвую блокировку), запускающий последовательный откат.

SQLERRM (тип данных - строка из 71 символа). Содержит текстовую строку с описанием ошибки в случае, если поле SQLCODE меньше нуля.

SQLERRD (тип данных - массив , 6 целых чисел). Описывает результат выполнения последнего оператора SQL:

• 1 элемент - внутренняя информация;
• 2 элемент - содержит сгенерированное сервером значение поля типа SERIAL для оператора INSERT, либо дополнительный код ошибки;
• 3 элемент - равен количеству обработанных записей;
• 4 элемент - примерная стоимость выполнения данного оператора;
• 5 элемент - смещение ошибки в текстовой записи оператора SQL;
• 6 элемент - внутренняя информация.

Примечания

Ссылки

• Страница программы на сайте IBM
• DB2 на developerWorks - статьи и тренинги о DB2
• PlanetDB2 - блоги о DB2

Литература

• Дейт К. Руководство по реляционной СУБД DB2. - М.: Финансы и статистика, 1988. - 320 с. - ISBN 5-279-00063-9
• Зикопулос П. К., Бакларц Дж., деРус Д., Мельник Р. Б. DB2 версии 8: официальное руководство = DB2 Version 8: The Official Guide. - М.: КУДИЦ-ОБРАЗ, 2004. - 400 с. - ISBN 5-9579-0031-1
• Смирнов С. Н. Работаем с IBM DB2: Учебное пособие. - М.: Гелиос, 2001. - 304 с. - ISBN 5-85438-007-2 (рекомендовано УМО вузов в области информационной безопасности в качестве учебного пособия по специальностям «Комплексное обеспечение информационной безопасности автоматизированных систем» и «Компьютерная безопасность»)
• Сьюзен Виссер, Билл Вонг. Освой самостоятельно DB2 Universal Database за 21 день = Sams Teach Yourself DB2 Universal Database in 21 Days. - 2-е изд. - М.: Вильямс , 2004. - 528 с. - ISBN 0-672-32582-9
• Hook J., Harbus R., Snow D. The Universal Guide to DB2 for Windows NT®. - New Jersey: Prentice Hall PTR, 1999. - P. 504. - ISBN 0-13-099723-4

Wikimedia Foundation . 2010 .

Смотреть что такое "IBM DB2" в других словарях:

IBM DB2 - Developer(s) IBM Initial release 1983 (1983) … Wikipedia

IBM DB2 - DB2 ist ein kommerzielles relationales Datenbank Management System (RDBMS) der Firma IBM, dessen Ursprünge auf das System R und die Grundlagen von E. F. Codd vom IBM Research aus dem Jahr 1970 zurückgeht. Inhaltsverzeichnis 1 Eigenschaften 1.1… … Deutsch Wikipedia

IBM DB2 - Développeur IBM Dernière version … Wikipédia en Français

IBM DB2 Commonstore - DB2 CommonStore Archiving software produced by IBM for managing e mail messages or SAP ERP data. Part of the IBM Information Management portfolio which builds upon the DB2 database platform. DB2 CommonStore is one of several products which are… … Wikipedia

Обзор основных понятий и общее описание архитектуры СУБД IBM DB2 для платформ Linux, Unix и Windows

Серия контента:

Этот контент является частью # из серии # статей: Обзор DB2 LUW

http://www.?q=%D0%9E%D0%B1%D0%B7%D0%BE%D1%80+DB2+LUW&co=ru&lo=ru&ibm-submit.x=11&ibm-submit.y=13&sn=mh&lang=ru&cc=RU&en=utf&hpp=

Следите за выходом новых статей этой серии.

Исходные материалы и контактная информация

Отдельная благодарность Марку Баринштейну за уделенное время на вычитку материала статей, внимание к деталям и ценные замечания.

Основная часть материала статей является вольной интерпретацией официальной документации DB2. Представленная информация была реструктурирована и переформулирована для сжатого и в то же время максимально понятного изложения. Ссылки на использованные источники во всех случаях представлены в тексте статей и в разделе «Ресурсы».

В рамках серии статей планируется обзорно осветить следующие вопросы:

1. (статья, которую вы сейчас читаете);
2. (установка, настройка, диагностика, резервное копирование и восстановление);
3. расширенные процедуры администрирования (перенос информации, оптимизация производительности, управление приоритетами выполнения);
4. средства для построения аналитических хранилищ данных;
5. технологии in-memory аналитики - DB2 BLU;
6. массивно-параллельная аналитическая обработка данных с DB2 DPF (Database Partitioning Feature);
7. распределенные базы данных (отказоустойчивые конфигурации, репликация данных и федеративный доступ к данным);
8. возможности кластерных конфигурации DB2 pureScale для обеспечения отказоустойчивости и масштабируемости.

Статьи серии будут публиковаться по мере подготовки соответствующих материалов.

Семейство продуктов DB2

Имя «DB2» используется компанией IBM для целого семейства продуктов, отличающихся друг от друга как составом программно-аппаратных платформ, на которых они применяются, так и функционалом, архитектурой и технологическими особенностями. Данные различия обусловлены тесной интеграцией большинства продуктов семейства DB2 с возможностями операционных систем, в которых они функционируют, а также спецификой этих операционных систем.

В семейство продуктов DB2 на текущий момент входят:

• DB2 for Linux, Unix and Windows , или же DB2 LUW - СУБД для систем с операционной системой Linux (RedHat, SuSE, Ubuntu), UNIX (AIX, HP-UX, Solaris) и Microsoft Windows, которой и посвящена данная статья и другие статьи этой серии;
• DB2 for z/OS - СУБД для операционной системы z/OS, используемой на мейнфреймах IBM System z;
• DB2 Server for VSE & VM - СУБД для операционных z/VM и z/VSE, используемых на мейнфреймах IBM System z;
• DB2 for i - СУБД для операционной системы System i, применяемой на платформе IBM Power.

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

Терминология, используемая в документации на различные СУБД семейства DB2, не является унифицированной, причем одни и те же термины для разных вариантов DB2 могут использоваться в различных значениях: например, термины «база данных» и «табличное пространство» имеют разные значения для DB2 LUW и DB2 for z/OS, что обусловлено архитектурными различиями между этими видами СУБД.

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

Устаревшие функции DB2 LUW

В том или ином виде, продукт DB2 LUW присутствует на рынке с 1989 года (год выхода операционной системы OS/2 1.10 Extended Edition, включавшей в свой состав компонент Database Manager - т.е. реляционную СУБД, явившуюся основой для DB2 LUW).

В ходе длительного развития продукта некоторые первоначально разработанные функций были переосмыслены и заменены другой реализацией, либо полностью исключены из продукта из-за отсутствия в них надобности. Поэтому при работе с материалами, подготовленными для старых версий DB2 (например, для версии 9.7), необходимо учитывать, что часть описанных в этих материалах функций может быть заменена в более новых версиях DB2 (например, 10.5 и 11.1). Детальная информация об исключённых и заменённых функциях приведена в .

Наиболее заметные для администраторов и разработчиков изменения включают в себя:

• замену устаревших графических инструментов управления «Центр управления», «Центр задач» и ряда других на функции бесплатно распространяемого пакета IBM Data Studio, а также на функции средств, входящих в бесплатную редакцию продукта IBM Data Server Manager;
• прекращение использования сервера администрирования DB2 (DB2 Administration Server, DAS), который был необходим для работы устаревших инструментов администрирования;
• замену инструментов DB2 Governor и Query Patroller для управления рабочими нагрузками на функционал DB2 Workload Manager (DB2 WLM).

Цель подготовки данной серии статей

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

При этом автором не ставится задача подготовки обзорного описания всех продуктов семейства DB2 (см. врезку «Семейство продуктов DB2»), вместо этого планируется сосредоточить усилия на варианте DB2 для операционных систем Linux, Unix и Windows - т.е. на продукте DB2 LUW.

Читателям, заинтересованным в практическом руководстве по началу работы с DB2, рекомендую обратиться к свободно распространяемой книге « », переведённой на русский язык. В этой книге приведено множество примеров типовых операций с программным обеспечением DB2, что позволяет с лёгкостью приступить к работе как с описанной в книге версией DB2 9.7, так и с более новыми версиями DB2 (10.5 и 11.1). При работе с актуальными версиями программного обеспечения DB2 необходимо учитывать, что часть функционала версии 9.7 объявлена устаревшей и не поддерживается в новых версиях продукта (см. врезку «Устаревшие функции DB2 LUW»).

Функциональные возможности DB2 LUW

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

Для обеспечения конкурентного доступа к данным со стороны параллельно исполняемых приложений в DB2 используется транзакционный механизм, основанный на применении блокировок и ведения журнала транзакций, и обеспечивающий предоставление стандартных гарантий ACID (Атомарность, Согласованность, Изолированность, Долговечность). Данный механизм прошёл долгий путь эволюции для обеспечения максимальной производительности, надежности и минимизации задержек исполнения приложений.

В DB2 реализована поддержка всех распространенных промышленных стандартов доступа приложений к данным, включая стандартный язык запросов SQL, интерфейсы ODBC и JDBC, работу с типовыми текстовыми табличными форматами и т.п. Кроме того, DB2 включает в себя развитые возможности по хранению и работе с полуструктурированными данными в форматах XML, JSON/BSON. Для разработки хранимых процедур в DB2 реализована поддержка множества процедурных языков, включая:

• стандартный для DB2 язык SQL PL,
• используемый в СУБД корпорации Oracle язык SQL/PL,
• возможность разработки «внешних» хранимых процедур на языках Java, C, C++ и COBOL.

Отличительными особенностями DB2 является:

• масштабируемость, ограниченная только доступными вычислительными ресурсами, и максимально экономичное использование вычислительных ресурсов;
• мощные встроенные средства разграничения и контроля доступа, предоставляющая возможности гранулярного ограничения доступа к информации в разрезе объектов (таблиц, представлений), а также реализующая модель мандатного разграничения доступа;
• развитая интегрированная система резервного копирования и восстановления данных;
• наличие полного набора технологий для построения «классических» аналитических хранилищ данных (деление таблиц на разделы, материализованные представления, оптимизации кэширования данных и сканирования таблиц и индексов, «внутренний» параллелизм исполнения сложных запросов и т.п.);
• поддержка построения конфигураций массивно-параллельной аналитической обработки данных (MPP) из множества серверов, соединенных через коммуникационную сеть, на базе DB2 Database Partitioning Feature (DB2 DPF);
• максимальная устойчивость к отказам и практически линейное масштабирование кластерных конфигураций DB2 pureScale, с хранением данных на общих дисках;
• технология DB2 BLU, реализующая поддержку современной in-memory «поколоночной» аналитики без использования ручной оптимизации структуры баз данных.

Для облегчения миграции приложений с других типов СУБД (в первую очередь, Oracle Database) в DB2 предусмотрены развитые средства обеспечения совместимости, включая поддержку необходимых типов данных, хранимых процедур, и стандартных системных представлений.

Существует несколько редакций продукта DB2 LUW, объединяемых единым набором базовых функций и отличающихся друг от друга наличием ограничений по используемым вычислительным ресурсам и поддержке расширенного функционала. Для ознакомления с продуктом, изучения и даже развертывания небольших производственных конфигураций может использоваться редакция DB2 Express-C, доступная бесплатно. Функциональные возможности и ресурсные ограничения различных редакций DB2 LUW детально изложены в статье « ».

Структура сервера баз данных

Под сервером баз данных DB2 понимается компьютер, на котором установлено программное обеспечение сервера DB2 (DB2 engine) и который обеспечивает предоставление сервисов по управлению структурированной информацией.

Доступ к сервисам DB2 со стороны приложений обеспечивается клиентским программным обеспечением DB2 (IBM Data Server Driver Package), обеспечивающее взаимодействие с сервером DB2 в соответствии с поддерживаемыми методами подключения приложений (включая ODBC, JDBC, OLE DB, ADO, CLI и другие методы). В большинстве случаев вместе с сервером DB2 устанавливается и необходимое клиентское программное обеспечение, что обеспечивает возможность подключения к серверу DB2 приложений, непосредственно размещаемых на сервере баз данных.

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

Непосредственное предоставление сервисов СУБД обеспечивается компонентом менеджера баз данных DB2 (DB2 database manager, DB2 DBM). В каждой копии может быть создано несколько экземпляров менеджера баз данных DB2, или, более кратко – экземпляров DB2 (DB2 instances). Экземпляр – это независимая среда, в которой могут создаваться базы данных и работают приложения. Каждый экземпляр DB2 обладает собственной конфигурацией и предоставляет доступ к определенному набору баз данных. Экземпляры DB2 являются независимыми в том смысле, что выполнение операций на одном экземпляре не влияет на другие – за исключением ресурсных ограничений, вызываемых функционированием нескольких экземпляров на одном и том же физическом либо виртуальном сервере.

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

База данных – это совокупность объектов, составляющих единый информационный массив (таблиц, представлений, индексов и т.д.). Базы данных являются независимыми единицами и, соответственно, обычно не используют объекты совместно с другими базами данных (исключением могут быть распределенные конфигурации баз данных, использующие механизмы федерализации доступа к данным).

Схематически пример структуры сервера баз данных представлен на рисунке.

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

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

Параметры конфигурации DB2

Конфигурация сервера DB2 может быть задана на четырех различных уровнях:

• переменные среды;
• реестр профиля DB2;
• файл конфигурации менеджера баз данных (DBM CFG);
• файл конфигурации базы данных (DB CFG).

Переменные среды задаются на уровне операционной системы сервера и средствами операционной системы. Для ОС Windows эти переменные фактически являются глобальными для сервера, для ОС семейств Unix и Linux для каждого экземпляра могут быть установлены свои специфические настройки переменных среды.

Параметры реестра профиля DB2 могут быть заданы на уровне операционной системы (глобально) либо на уровне экземпляра, при этом настройки на уровне экземпляра переопределяют значения, определённые на уровне операционной системы. Просмотр и установка значений параметров реестра профиля DB2 выполняется с помощью команды db2set.

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

Многие параметры являются динамическими, т. е. внесенные изменения сразу же вступают в силу; однако есть параметры, для изменения которых необходимо остановить и снова запустить экземпляр. Это можно сделать в командной строке с помощью команд db2stop и db2start. Перед остановкой экземпляра все приложения должны отключиться. Для принудительной остановки экземпляра можно воспользоваться командой db2stop force.

Файл конфигурации менеджера баз данных включает параметры, влияющие на экземпляр и все базы данных, содержащихся в нем. Файл конфигурации менеджера базы данных можно просмотреть или изменить с помощью командной строки (командами GET DBM CFG и UPDATE DBM CFG), а также средствами IBM Data Studio.

Файл конфигурации базы данных включает параметры, влияющие на определенную базу данных. Файл конфигурации базы данных можно просмотреть или изменить с помощью командной строки (командами GET DB CFG и UPDATE DB CFG), а также средствами IBM Data Studio.

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

Организация хранения данных

Наименьшей единицей хранения данных в DB2 на физическом уровне является страница . Допустимые размеры страниц: 4 Кбайт, 8 Кбайт, 16 Кбайт и 32 Кбайт. Информация объектов базы данных (например, записи таблиц и элементы индексов) размещаются на страницах.

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

Хранение информации в базах данных DB2 организовано в рамках объектов, называемых табличными пространствами . Табличное пространство представляет собой именованный набор контейнеров для хранения информации, размещаемых в файловой системе сервера баз данных.

Для каждого табличного пространства создается один либо несколько контейнеров (файлов либо каталогов в файловой системе) для хранения информации, а также устанавливается размер страницы и область для кэширования данных (буферный пул, см. ниже), а также ряд других параметров.

Существуют следующие виды табличных пространств:

• обычные : используются для размещения пользовательских таблиц и индексов;
• большие : используются для размещения пользовательских таблиц и индексов, а также данных больших объектов (LOB) и данных XML. В современных версиях DB2 большие табличные пространства используются по умолчанию вместо обычных;
• временные : используются для размещения временной информации при исполнении запросов (системные временные табличные пространства) и временных таблиц, определенных приложениями (пользовательские временные табличные пространства).

Вид табличного пространства указывается при его создании и не может быть изменён иначе, как удалением и повторным созданием табличного пространства.

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

• табличные пространства под управлением системы (SMS, System Managed Storage) – в качестве контейнеров табличного пространства используются каталоги, для размещения объектов хранения в каталогах осуществляется создание файлов с данными. Пространство не распределяется предварительно, файлы увеличиваются динамически. При определении контейнеры фиксируются на момент создания;
• табличные пространства под управлением базы данных (DMS, Database Managed Storage) – в качестве контейнеров табличного пространства используются предварительно распределённые файлы, контейнеры можно добавлять, удалять или менять;
• автоматически управляемые табличные пространства (automatic storage) – автоматическое определение типа и размещения контейнера в зависимости от вида табличного пространства (DMS для обычных и больших табличных пространств, SMS для временных табличных пространств). Конкретные определения контейнеров при создании табличного пространства не задаются, нужные контейнеры создаются автоматически. Увеличением существующих и добавлением новых контейнеров полностью управляет DB2.

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

По умолчанию DB2 выполняет последовательную запись в экстенты с «расслоением» между контейнерами. К примеру, если имеется табличное пространство с размером страницы 4 КБ и размером экстента 8 страниц, и используется 3 непосредственных контейнера в табличном пространстве типа DMS, это означает, что 32 КБ данных (4 КБ x 8 страниц в экстенте = 32 КБ) будет записано на один диск прежде, чем начнется запись на следующий.

Начиная с DB2 версии 10.1, с целью упрощения управления хранением данных введено новое понятие – группа хранения данных (storage group). Группой хранения данных называется именованная совокупность путей в файловой системе сервера СУБД, которые могут использоваться для размещения данных. Состав групп хранения в базе данных обычно определяет набор видов устройств хранения, доступных для размещения информации. При создании базы данных в ней всегда автоматически создается группа хранения по умолчанию.

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

Ведение журнала транзакций

IBM DB2 LUW, как и большинство других современных реляционных СУБД, обеспечивающих предоставление гарантий ACID, используют транзакционный журнал как один из основных механизмов реализации соответствующих требований.

Выполняемые DB2 операции изменения данных фиксируются в транзакционном журнале в виде последовательности записей журнала. Для каждой базы данных ведется собственный транзакционный журнал, представляющий собой последовательность файлов на диске. Размер единичного файла определяется параметром LOGFILSIZ, количество первоначально создаваемых файлов определяется параметром LOGPRIMARY. При необходимости DB2 может создать дополнительные файлы журнала, максимальное количество создаваемых файлов регулируется параметром LOGSECOND.

Запись информации в транзакционный журнал ведется с использованием специального буфера в оперативной памяти. Сброс содержимого буфера на диск (в файлы транзакционного журнала) осуществляется по мере заполнения буфера, а также при подтверждении и отмене транзакций (по команде приложения либо по факту нештатного закрытия соединения с приложением).

Файл транзакционного журнала, который необходим для восстановления данных после сбоя, называется активным. Активные файлы транзакционных журналов должны быть постоянно доступны менеджеру баз данных DB2 . Поскольку доступность файлов транзакционного журнала является критической для обеспечения работоспособности СУБД, предусмотрен механизм зеркального хранения транзакционных журналов в двух файловых системах (настраивается параметром LOGMIRROR).

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

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

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

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

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

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

Организация кэширования данных

В целях сокращения количества выполняемых операций ввода-вывода, DB2, как и другие современные реляционные СУБД, осуществляет кэширование операций чтения и записи, выполняемых над табличными пространствами. Кэширование осуществляется с использованием областей оперативной памяти, называемых буферными пулами. В DB2 может быть определено несколько различных буферных пулов (создаваемых командой CREATE BUFFERPOOL) с указанием размера страницы, размера и признака возможности автоматического управления размером. Каждое табличное пространство сопоставляется с определенным буферным пулом, при этом один буферный пул может использоваться совместно несколькими табличными пространствами.

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

При выполнении операции записи корректировка страницы выполняется непосредственно в буферном пуле. Запись страницы на диск в синхронном режиме при этом не выполняется, а сохранность данных обеспечивается механизмом ведения транзакционного журнала. Запись измененных страниц табличных пространств на диск ведется асинхронно, в фоновом режиме, и обеспечивает разумную минимизацию объема работы, которая может потребоваться для восстановления состояния базы данных при её аварийном (некорректном) закрытии. Корректное закрытие базы данных (например, при штатной остановке сервера СУБД) обеспечивает запись на диск всех измененных страниц всех буферных пулов.

Использование оперативной памяти

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

Детальное описание областей памяти DB2 приведено в , ниже представлено краткое описание назначения различных областей.

Перечень основных областей памяти DB2 приведен на рисунке ниже (изначально взятом из ).

Общая память, используемая экземпляром СУБД, включает в себя:

• Monitor Heap – область памяти для ведения мониторинга операций и состояния, размер регулируется параметром MON_HEAP_SZ;
• FCM Buffers – область памяти для взаимодействия между координирующим агентом и его субагентами, а также для обеспечения внутренних взаимодействий в многораздельных базах данных;
• Audit Buffer – область памяти, в которую помещаются записи аудита перед сбросом в журнал аудита.

На уровне базы данных принято различать:

• глобальную область базы данных, часто называемую «Областью производительности» («Performance memory»), включающую различные области кэширования и область ведения блокировок;
• область данных приложений, часто называемую «Функциональной областью» («Functional memory») и включающую различные рабочие области памяти агентов, обслуживающих подключения к базе данных.

Глобальная область базы данных состоит из следующих основных компонентов:

• Buffer pools – буферные пулы, т.е. области для кэширования данных табличных пространств;
• Lock list – область для хранения информации о блокировках, размер которой регулируется параметром LOCKLIST;
• Package cache – область для кэширования планов выполнения запросов, размер регулируется параметром PCKCACHESZ;
• Catalog cache – область для кэширования системного каталога, включающего в себя описания всех объектов базы данных, размер регулируется параметром CATALOGCACHE_SZ;
• Utility heap – оперативная память для выполнения операций обслуживания базы данных (включая операции резервного копирования и восстановления), размер регулируется параметром UTIL_HEAP_SZ;
• Database heap – оперативная память для обслуживания операций базы данных (включая буфер транзакционного журнала и кэш для ускорения доступа к системному каталогу, а также буфер аудита на уровне базы данных), размер регулируется параметром DBHEAP.

Суммарный объем глобальной области базы данных ограничен параметром DATABASE_MEMORY.

Область данных приложений включает в себя:

• Application Global Memory – общие области памяти, совместно используемые при обработке запросов приложений, максимальный объем регулируется параметром APPL_MEMORY;
• Agent Private Memory – частные области памяти, используемые для функционирования отдельных агентов, обслуживающих подключенные приложения.

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

Управление оперативной памятью при выполнении операций сортировки

При выполнении многих видов операций СУБД требуется осуществить сортировку данных, поэтому управлению оперативной памятью, используемой для сортировки, уделяется особое внимание.

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

Параметры, управляющие выделением оперативной памяти для сортировки:

• SORTHEAP – предельный размер памяти для операции сортировки;
• SHEAPTHRES – предельный размер частной области памяти агента, выделенной для операции сортировки;
• SHEAPTHRES_SHR – предельный объем общей оперативной памяти, которая может быть использована для выполнения операций сортировки (суммарно всеми потребителями) в каждый момент времени.

В DB2 поддерживается три основных модели управления памятью сортировки:

• Модель общей области сортировки (shared sort) – используется по умолчанию, подразумевает установку параметра SHEAPTHRES в значение 0. Выделение оперативной памяти для сортировки осуществляется из глобальной области базы данных.
• Модель частной области сортировки (private sort) – используется при ненулевом значении параметра SHEAPTHRES и отсутствии настроенной общей памяти сортировки. Выделение оперативной памяти для сортировки осуществляется из области данных приложений (точнее, из частных областей, принадлежащих агентам).
• Гибридная модель сортировки (hybrid sort) – используется при ненулевом значении параметра SHEAPTHRES и наличии настроенной общей памяти сортировки. Операции, требующие использования общей памяти сортировки, выполняются с выделением памяти в глобальной области базы данных, остальные операции сортировки выполняются с выделением памяти в частных областях агентов.

Использование общей (глобальной) памяти для выполнения операций сортировки предоставляет ряд важных преимуществ:

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

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

• активирована модель общей области сортировки путем установки параметра SHEAPTHRES в значение 0;
• активирован параллелизм выполнения операций путем установки параметра INTRA_PARALLEL в значение YES;
• переменная DB2_WORKLOAD установлена в значение ANALYTICS;
• активирована функция DB2 Connection Concentrator (обычно используется при организации доступа к базам данных DB2 for z/OS и DB2 for i, см. описание данной функции в ).

Автоматическое управление распределением памяти

Наличие большого количества различных областей оперативной памяти и параметров, регулирующих их объем, может требовать значительных усилий для ручной настройки сервера DB2. Поэтому, начиная с версии 9, IBM DB2 поддерживает автоматическое управление распределением оперативной памяти между различными областями с использованием самонастраивающегося менеджера памяти (STMM, Self-Tuning Memory Manager).

Если функция самонастройки включена, STMM динамически распределяет доступные ресурсы памяти между потребителями оперативной памяти в базе данных. STMM реагирует на изменения характеристик рабочей нагрузки, регулируя значения параметров конфигурирования памяти и размер буферных пулов для оптимизации производительности. Чтобы включить STMM, необходимо установить для параметра конфигурации базы данных SELF_TUNING_MEM значение ON.

Автоматическое управление распределением памяти ведётся для тех областей памяти, для которых оно было явно разрешено. При установке значения параметра конфигурации командами UPDATE DBM CFG и UPDATE DB CFG, для использования STMM после значения параметра указывается ключевое слово AUTOMATIC. Указанное при этом числовое значение параметра используется как начальное, далее STMM осуществляет периодическую корректировку значений с учетом текущей нагрузки, перераспределяя оперативную память между различными потребителями.

Автоматическое управление средствами STMM поддерживается для следующих параметров:

• INSTANCE_MEMORY – суммарный объем оперативной памяти экземпляра DB2;
• DATABASE_MEMORY – глобальные области базы данных;
• DBHEAP – область для обслуживания операций базы данных;
• LOCKLIST – область ведения данных о блокировках;
• MAXLOCKS – процент занятия памяти блокировками одного приложения для перехода к эскалации блокировок;
• PCKCACHESZ – область кэширования планов выполнения запросов;
• SHEAPTHRES_SHR – общая область сортировки;
• SORTHEAP – размер области сортировки для одной операции;
• APPL_MEMORY – область функциональной памяти;
• APPLHEAPSZ – предельный объем частной памяти, используемый одним агентом;
• STMTHEAP – ограничение на размер области, используемой компилятором SQL и XQuery запросов (на один запрос);
• STAT_HEAP_SZ – максимальный объем оперативной памяти, выделяемый для построения статистик утилитой RUNSTATS и выделяемый из функциональной области памяти.

Виды объектов баз данных

Настоящий раздел содержит обзор видов объектов баз данных DB2. Полный перечень видов объектов баз данных DB2 и детальная информация по каждому виду объектов приведена в документации DB2:

Схемы

Схемы – это пространства имён для сбора объектов базы данных. Схемы преимущественно используются для:

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

Все объекты базы данных DB2 (за исключением общих синонимов) имеют полностью классифицированные имена, состоящие из двух частей; схема является первой частью такого имени: <имя_схемы>.<имя_объекта>

Полностью классифицированное имя объекта должно быть уникальным. Если подключиться к базе данных и создать или обратиться к объекту, не указав схему, DB2 будет использовать идентификатор пользователя, с помощью которого установлено подключение к базе данных, в качестве имени схемы. Чтобы задать схему для текущего сеанса работы, можно также воспользоваться оператором SET SCHEMA.

Создание схемы может быть выполнено явно, путем вызова оператора CREATE SCHEMA , либо неявно, при первой попытке создания объекта без указания имени схемы. В последнем случае для успешного создания схемы пользователю должна быть предоставлено полномочие IMPLICIT_SCHEMA .

Для большинства видов объектов базы данных могут быть созданы синонимы, позволяющие обращаться к исходным объектам через другое имя (возможно, размещённое в другой схеме). Создание синонимов осуществляется оператором CREATE SYNONYM / CREATE ALIAS . Также поддерживается работа с публичными синонимами, которые не привязаны к конкретной схеме. Обращение к публичным синонимам осуществляется без указания схемы вне зависимости от установленной текущей схемы сеанса работы. Создание публичных синонимов осуществляется командой CREATE PUBLIC SYNONYM / CREATE PUBLIC ALIAS .

Таблицы

Таблица – это собрание связанных данных, логически упорядоченных в столбцах и строках.

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

Создание таблицы осуществляется командой CREATE TABLE , удаление – командой DROP TABLE . Поддерживается изменение описания таблицы командой ALTER TABLE , включая добавление и удаление колонок, изменение типов данных колонок. После выполнения некоторых операций изменения описания таблицы требуется выполнить её реорганизацию (реструктурировать физическое хранение таблицы для оптимального доступа к ней) с помощью команды REORG .

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

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

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

При работе со строковыми данными, в отличие от некоторых других типов СУБД, DB2 различает пустую строку (строку нулевой длины) и NULL-значение строкового типа. Данная особенность влияет на порядок поиска (использование предиката равенства вместо выражения IS NULL) и состав допустимых значений колонок (при запрете хранения NULL-значений в колонке может быть сохранена пустая строка).

Строковые значения типов GRAPHIC, VARGRAPHIC и DBCLOB отличаются от других строковых типов тем, что всегда хранятся в кодировке UTF-16. При обращении к соответствующим колонкам со стороны клиентского приложения, СУБД обеспечивает преобразование данных к кодировке, используемой клиентским приложением.

Колонки типа DATE (дата) по умолчанию не содержат метки времени. В режиме совместимости с СУБД Oracle Database, в DB2 дополнительно поддерживается хранение атрибутов времени (часы, минуты, секунды) в колонках DATE.

При необходимости обеспечить эффективную работу с точными десятичными числами, включающими дробную часть (например, в финансовых приложениях), целесообразно использование типа данных DECFLOAT, который комбинирует точное представление значений типа DECIMAL и возможности эффективных вычислений над значениями типа FLOAT.

Тип данных BLOB обеспечивает возможность сохранения в базе данных неструктурированной двоичной информации (например, изображений или документов офисных форматов). Значения типа BLOB могут сохраняться вместе с другими полями записи (если их размер позволяет разместить их достаточно компактно), либо отдельно, в специальном объекте хранения. В последнем случае запись содержит ссылку на хранимое BLOB-значение вместо самого значения. Аналогичным образом организовано хранение значений типов CLOB и DBCLOB.

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

В дополнение к встроенным типам данных, DB2 поддерживает работу с пользовательскими типами данных, определяемыми на основе встроенных типов. Работа с пользовательскими типами данных описана в документации DB2.

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

• GENERATED ALWAYS – значение всегда устанавливается сервером DB2 и не может быть явно установлено приложением;
• GENERATED BY DEFAULT – значение устанавливается сервером DB2 в том случае, если приложение не указало явно присваиваемое значение при вставке записи.

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

• первичный ключ (PRIMARY KEY) – ограничение уникальности на набор колонок, преимущественно используемых для поиска единичной записи, в таблице может быть только один первичный ключ;
• ограничение уникальности (UNIQUE) – дополнительное ограничение уникальности на набор колонок;
• внешний ключ (FOREIGN KEY) – ссылка в виде набора значений колонок, указывающая на комбинацию колонок другой таблицы, для которой определён внешний ключ или ограничение уникальности;
• проверка (CHECK) – логическое условие, ограничивающее возможные значения одной или сразу нескольких колонок в записи.

Механизм ограничений реализует средства автоматического контроля и обеспечения целостности базы данных, включая ссылочную целостность данных (контроль наличия в «родительской» таблице записей, на которые ссылаются через внешние ключи записи «дочерних» таблиц). Грамотное использование ограничений позволяет гарантировать формальную корректность заполнения базы данных и в определённой степени защититься от ошибок приложений и пользователей при корректировке данных.

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

Временные таблицы

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

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

Временные таблицы также поддерживают индексы, т. е. ко временной таблице можно создать любой стандартный индекс. Для таких таблиц можно также выполнить сбор статистик (командой RUNSTATS) для получения информации, необходимой оптимизатору запросов.

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

В DB2 существует две основные разновидности временных таблиц:

• объявленные временные таблицы (DGTT – Declared Global Temporary Tables);
• созданные глобальные временные таблицы (CGTT – Created Global Temporary Tables).

Объявленные временные таблицы - это созданные в памяти таблицы, используемые приложением и автоматически отбрасываемые при завершении его работы. Доступ к таким таблицам может получить только то приложение, которое их создало, и они не хранятся ни в одной из таблиц системного каталога DB2.

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

Хотя DGTT дают возможность объявить временную таблицу, определение такой таблицы нельзя совместно использовать в разных подключениях или сеансах. При запуске каждого сеанса необходимо выполнять оператор DECLARE GLOBAL TEMPORARY TABLE.

При использовании созданных глобальных временных таблиц (CGTT) определение временной таблицы нужно создать всего один раз, поскольку оно сохраняется в системном каталоге DB2. Это означает, что другие подключения могут воспользоваться определением такой таблицы, а не создавать его снова.

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

Индексы

Индекс - это упорядоченный набор ключей, каждый из которых указывает на строку таблицы. Индексы обеспечивают уникальность строк (т.е. реализуют ограничения уникальности, рассмотренные в предыдущем разделе) и повышают производительность. Ниже описаны некоторые характеристики, которые можно определить для индексов:

• индексы могут строиться по возрастанию или по убыванию значений колонок;
• ключи индексов могут быть уникальными или неуникальными;
• индексы могут строиться по нескольким столбцам (такие индексы называют комбинированными);
• если индексные и табличные данные сгруппированы в одинаковой последовательности индекса, такой индекс называется сгруппированным (CLUSTERED INDEX).

Создание индексов обеспечивается оператором CREATE INDEX, удаление – оператором DROP INDEX. При создании индекса указывается его тип (уникальный / неуникальный) и состав колонок для построения индекса.

В DB2 предусмотрены инструменты, обеспечивающие автоматизрованный подбор индексов для оптимизации выполнения запросов. Наиболее удобно работа с данными инструментами организована в IBM Data Studio.

Последовательности

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

Создание последовательностей обеспечивается командой CREATE SEQUENCE, обращение к очередному и текущему полученному значениям осуществляется с помощью операторов NEXT VALUE FOR и PREVIOUS VALUE FOR. Для совместимости с СУБД Oracle Database также поддерживается синтаксис обращения к значениям последовательности через псевдо-колонки «NEXTVAL» и «CURRVAL».

Представления

Представление – это отображение данных в таблицах. Данные для представлений не хранятся отдельно, они отбираются при запуске представления. Поддерживаются вложенные представления, т. е. представления, созданные на основе других представлений.

Создание представлений осуществляется командой CREATE VIEW , удаление – командой DROP VIEW . Для облегчения обновления (замены) представлений предусмотрен синтаксис CREATE OR REPLACE VIEW , который обеспечивает создание нового представления (если его еще не существует) либо замену существующего представления на новое определение (если представление с указанным именем уже было ранее создано).

Триггеры

Триггер - это объект, который автоматически выполняет операцию с таблицей или представлением. Определенное действие с объектом, для которого определен триггер, вызывает запуск триггера. Обычно триггер не считается объектом приложения; соответственно, обычно триггеры создаются не разработчиками, а администраторами баз данных.

Хранимые процедуры и функции

Хранимые процедуры – это объекты базы данных, содержащие операторы SQL и бизнес-логику. Хранение части логики приложения в базе данных повышает производительность, поскольку сокращается объем трафика между приложением и базой данных. Кроме того, хранимые процедуры предоставляют централизованное местоположение для хранения программного кода, и, соответственно, другие приложения могут воспользоваться теми же хранимыми процедурами. Для вызова хранимой процедуры используется оператор CALL.

Пользовательские функции (UDF, User Defined Functions) – это объекты базы данных, позволяющий пользователям расширить язык SQL собственной логикой. Функция всегда возвращает значение или значения, обычно как результат включенной в функцию бизнес-логики. Чтобы вызвать функцию, используйте её в составе оператора SQL или с оператором VALUES.

В DB2 хранимые процедуры и пользовательские функции можно разрабатывать на нескольких языках программирования, среди которых PL/SQL, SQL PL, Java, C, C++, COBOL.

Системный каталог

Одним из базовых информационных ресурсов СУБД является системный каталог, хранящий и предоставляющий доступ к информации о структуре базы данных, включая:

• описание таблиц, колонок и индексов;
• описание и текст представлений, триггеров и хранимых процедур;
• сведения о табличных пространствах и контейнерах для хранения данных;
• установленные полномочия по доступу к объектам базы данных;
• другую метаинформацию базы данных.

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

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

• SYSCAT.SCHEMAS – описание схем базы данных;
• SYSCAT.TABLES – описание таблиц базы данных;
• SYSCAT.COLUMNS – описание колонок таблиц;
• SYSCAT.INDEXES – описание индексов.

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

Организация параллельной транзакционной обработки

Транзакции

Транзакция (или единица работы) состоит из одного или нескольких операторов SQL, которые при выполнении рассматриваются как отдельная единица; иными словами, сбой одного оператора транзакции приводит к сбою целой транзакции, при этом все операторы, выполненные до момента сбоя, откатываются.

Транзакция заканчивается оператором COMMIT. Транзакция также может закончиться оператором ROLLBACK либо аварийным (нештатным) отключением приложения, после которого все внесённые приложением изменения в базу данных будут отменены. Началом транзакции является первый выполненный оператор после открытия соединения приложения с базой данных либо после завершения предыдущей транзакции. Каждое соединение приложения с базой данных может иметь не более одной активной транзакции.

Как уже было указано ранее, изменения в базе данных фиксируются в транзакционном журнале. Для обеспечения возможности «отката» изменений, внесенных отменяемой транзакцией, в транзакционном журнале также фиксируются границы транзакций. При этом для транзакций, выполняющих только операции чтения данных, запись в транзакционный журнал не ведется. Информация о начале транзакции помещается в транзакционный журнал перед началом выполнения первого (для данной транзакции) оператора записи данных.

В случае ошибки выполнения единичного оператора, осуществляющего запись данных, все изменения, внесенные данным оператором, отменяются с использованием данных транзакционного журнала. Приложение, получив диагностическое сообщение об отказе в выполнении оператора, может отменить всю транзакцию (оператором ROLLBACK) либо выполнить какие-то другие действия с базой данных и, в итоге, подтвердить внесённые изменения (оператором COMMIT).

Приложение может определять дополнительные точки отката в рамках транзакции (с помощью оператора SAVEPOINT) и отменять изменения, выполненные после созданной точки отката (с помощью оператора ROLLBACK TO). Использование точек отката позволяет приложению выборочно отменять выполненные в рамках транзакции действия, что может быть полезно при обработке ошибок контроля целостности данных и в других сценариях.

Блокировки

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

Для получения согласованных результатов параллельно выполняемых транзакций требуется контроль параллельного использования общих ресурсов. Такой контроль основан на применении блокировок.

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

Блокировка срабатывает автоматически по мере необходимости для поддержки транзакции и отключается после прерывания такой транзакции (с помощью команды COMMIT или ROLLBACK). Блокировка может устанавливаться на таблицы или строки.

Существует два основных типа блокировки:

• Общая блокировка (S) - устанавливается, когда приложение считывает данные и не допускает внесения изменений в ту же строку другими приложениями.
• Эксклюзивная блокировка (X) - устанавливается, когда приложение обновляет, вставляет или удаляет строку.

Если двум и больше приложениям необходимо выполнить операцию с одним и тем же объектом, одному из них придется подождать, чтобы установить требуемую блокировку. По умолчанию, приложение будет ждать бесконечно долго. Временем ожидания блокировки приложением управляет параметр конфигурации базы данных LOCKTIMEOUT. По умолчанию этот параметр имеет значение -1 (бесконечное ожидание).

Для установки времени ожидания блокировки в определенном подключении можно использовать сессионную переменную CURRENT LOCK TIMEOUT. По умолчанию для этой переменной задано значение LOCKTIMEOUT. Чтобы изменить это значение, можно воспользоваться оператором SET LOCK TIMEOUT.

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

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

Уровни изоляции

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

• потерянное обновление (при одновременном изменении одного блока данных разными транзакциями, одно из изменений теряется);
• недостоверное чтение (чтение данных, добавленных или изменённых транзакцией, которая впоследствии не подтвердится);
• неповторяющееся чтение (при повторном чтении в рамках одной транзакции, ранее прочитанные данные оказываются изменёнными);
• фантомное чтение (одни и те же выборки в одной транзакции дают разные множества строк из-за добавления, удаления либо изменения строк другими транзакциями).

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

DB2 предоставляет следующие уровни защиты для изоляции данных:

• недостоверное чтение (Uncommitted Read, UR);
• стабильность курсора (Cursor Stability, CS);
• стабильность чтения (Read Stability, RS);
• повторяемое чтение (Repeatable Read, RR).

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

При использовании уровня изоляции «Недостоверное чтение» предотвращаются следующие проблемы:

• потерянное обновление.

Стабильность курсора - это уровень изоляции по умолчанию. Он обеспечивает минимальную степень блокировки. При этом уровне изоляции блокируется «текущая» строка курсора. Если строка только считывается, блокировка сохраняется до перехода на новую строку или завершения операции. Если строка обновляется, блокировка сохраняется до завершения операции.

При использовании уровня изоляции «Стабильность курсора» предотвращаются следующие проблемы:

• потерянное обновление;
• недостоверное чтение.

До выхода DB2 9.7, при использовании уровня изоляции «Стабильность курсора» выполнение записи (операция UPDATE) закрывало для чтения (операция SELECT) доступ к той же строке. Логической основой служило то, что поскольку операция записи вносит в строку изменения, для чтения следует дождаться завершения обновлений, чтобы получить окончательное зафиксированное значение.

В DB2 9.7 по умолчанию используется другой подход к уровню изоляции «Стабильность курсора» для новых баз данных. Этот новый подход реализован с помощью «принятой на текущий момент» (currently committed, CC) семантики. При использовании CC-семантики, операция записи не закрывает доступ к той же строке для операции чтения. Ранее, такой подход был возможен при использовании уровня изоляции UR; разница с текущим подходом заключается в том, что при UR операция чтения получает недостоверные значения, а при CC-семантике - значения, принятые на текущий момент. Принятые на текущий момент значения - это значения, зафиксированные до начала операции записи.

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

При использовании уровня изоляции «Стабильность чтения» предотвращаются следующие проблемы:

• потерянное обновление;
• недостоверное чтение;
• неповторяющееся чтение.

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

Оптимизатор запросов DB2 при использовании уровня изоляции «Повторяющееся чтение» может включать в план выполнения запросов явные операции установки блокировок на уровне таблиц в случае, когда соответствующие запросы предполагают сканирование всех строк таблицы (что означает необходимость заблокировать каждую строку таблицы в ходе выполнения запроса).

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

Заключение

В данной статье были рассмотрены основные функциональные возможности СУБД IBM DB2 LUW, структура сервера баз данных, настройка конфигурации и организация хранения данных. Кроме того, рассмотрены основные принципы функционирования сервера DB2, поддерживаемые виды объектов баз данных и организация параллельной транзакционной обработки DB2.

DB2 (в русском языке произносится «диби́ два», также распространена калька с английского «диби́ ту») - семейство программных продуктов в области управления информацией компании IBM . Чаще всего, ссылаясь на DB2, имеют в виду реляционную систему управления базами данных DB2 Universal Database (DB2 UDB), разрабатываемую и выпускаемую компанией IBM .

Несмотря на благожелательное отношение к операционной системе Linux , которая распространяется под лицензией с открытым исходным кодом, корпорация IBM пока не планирует открывать коды своей СУБД DB2. Об этом заявил директор центра IBM Linux Technology Джим Васко на прошедшей (апрель 2011 года) в Сан-Франциско ежегодной конференции Linux Foundation Collaboration Summit. Внутри IBM идет постоянная борьба между представителями разных подразделений, пояснил Васко . В одних случаях выбор в пользу Linux или Windows означает снижение доходов от продаж программного обеспечения, но рост доходов от услуг, а в других случаях речь может идти о доходах от продажи оборудования. Приходится искать оптимальное решение, заключил он. Переход под контроль Oracle пакетов с открытым кодом, разрабатывавшихся в Sun Microsystems , создал определенные проблемы для IBM , сообщил Васко. Oracle пытается убедить клиентов обменять оборудование IBM на ее собственные серверы Exadata и СУБД Oracle. В 2011 году директор Linux Foundation Джим Землин ожидает развития на базе Linux специализированных высокопроизводительных систем наподобие IBM Watson и готовых устройств, требующих минимальной настройки.

Реализации

В настоящее время, помимо коммерческих продуктов семейства, IBM распространяет также бесплатный дистрибутив DB2 Express-C для платформ Linux (x86, x86-64, POWER), Windows (x86, x86-64), Solaris (x86-64), Mac OS X (x86-64 beta). Бесплатная версия имеет ограничения на использование для работы СУБД не более одного двухъядерного процессора и 2 Гбайт оперативной памяти (общее количество процессоров и памяти в системе может быть любым, но ресурсы сверх указанных ограничений не будут использоваться СУБД).

2017: Анонс дополнений для контроля над данными

Db2 on Cloud

Обновленное решение Db2 on Cloud является полностью управляемым сервисом, доступным в IBM Cloud .

Среди характеристик технологии:

• Динамичная шкала («слайдер») для установления параметров производительности и объема памяти - с помощью клика мышкой можно мгновенно менять масштаб, увеличивая или уменьшая производительность обработки данных и необходимый объем оперативной памяти, таким же способом можно увеличить объем памяти системы хранения информации;
• Веб-консоль - помогает заказчикам быстрее освоить сервис и ускорить работу с ним.

В целом решение Db2 on Cloud позволяет избежать трудоемкого процесса согласования и закупки дополнительных вычислительных ресурсов и дополняет IBM Db2 Hosted, версию базы данных , размещенную в IBM Cloud.

Db2 on Cloud Benchmark

DB2 Analytics Accelerator

Версии

2017: JSON и HTAP

DB2 10 представляет собой первое существенное обновление СУБД за последние несколько лет: 10-я версия системы для z/OS, правда, вышла в 2010 году, но этот релиз предназначен для одновременно Linux , Unix и Windows систем.

Оба продукта содержат новый функционал. DB2 теперь поддерживает формат RDF (Resource Description Framework), а InfoSphere может взаимодействовать с развертываниями Apache Hadoop . В числе других улучшений в DB2, в частности, можно отметить ускорение процессов резервного копирования и ввода-вывода.

DB2 10 также является и более гибкой. В частности, администраторы СУБД получили инструментарий для распределения данных для хранения по разным типам носителей: например, оперативная информация может размещаться на более быстрых твердотельных накопителей, а менее ценные данные – на более дешевых и медленных накопителях на магнитной ленте.

Новая функция под названием time travel позволяет более эффективно управлять временными данными, у пользователей 10-й версии для z/OS она имела большой успех. С ее помощью пользователь или программа могут изучать данные в контексте времени их существования в СУБД по заданным периодам. Использование таких средов актуально для аналитики.

DB2 10 может быть загружена бесплатно для использования в промышленном окружении на не более чем двух процессорных ядрах и 2Гб памяти. Более функциональные версии обойдутся в сумму начиная от $6180, куда входит и стоимость годового обслуживания. Стоимость InfoSphere базируется на количестве процессоров или объеме хранимых данных, базовые версии обойдутся в порядка $40 тыс за Тб.

IBM DB2 10.5 версия

История

DB2 имеет долгую историю и, как некоторые считают, стала первой СУБД , использующей SQL.

С 1975 по 1982 год прототип DB2 разрабатывался в IBM под названием System Relational, или System R. Язык SQL впервые был реализован именно в IBM System R, но эта система имела исследовательский характер, а коммерческий продукт, включающий SQL, первой выпустила компания Oracle в 1979 году.

СУБД DB2 получила своё название в 1982 году, когда был выпущен первый коммерческий релиз для VM под названием SQL/DS, и затем релиз для MVS под названием DB2. Долгое время наряду с «DB2» употреблялся вариант «Database 2», также являющийся торговой маркой IBM . По всей видимости, имелось в виду, что это вторая флагманская СУБД IBM после старой иерархической СУБД IMS.

Развитие DB2 уходит корнями в начало 1970-х, когда доктор Э. Ф. Кодд, работавший на IBM , разработал теорию реляционных баз данных и в июне 1970 года опубликовал модель манипуляции данными. Для воплощения этой модели он разработал язык реляционных баз данных и назвал его Alpha. IBM предпочла передать дальнейшую разработку группе программистов, неподконтрольной доктору Кодду. Нарушив некоторые принципы реляционной модели, они реализовали её как «структурированный английский язык запросов», сокращённо SEQUEL. Поскольку SEQUEL было уже зарегистрированной торговой маркой, название сократили до SQL - «структурированный язык запросов», и таким оно осталось по сей день.

Таким образом, исторически СУБД DB2 возникла из продуктов DB2 для MVS (потомком которого является DB2 for z/OS) и родственного ему SQL/DS для VM (потомок - DB2 Server for VSE & VM). В дальнейшем другим коллективом разработчиков в IBM был реализован сервер OS/2 EE Database Manager, впоследствии эволюционировавший в DB2 v2 для OS/2, AIX и затем Windows , а потом в DB2 UDB (его потомок - DB2 for Linux , UNIX and Windows). Ещё одним коллективом была выполнена интеграция архитектуры DB2 со встроенной базой данных AS/400 (потомок - DB2 for i). IBM постепенно движется по пути интеграции всех этих веток.

Особенности

К отличительным особенностям DB2 относится диалект языка SQL, определяющий, за редкими исключениями, чисто декларативный смысл языковых конструкций, и мощный многофазовый оптимизатор, строящий по этим декларативным конструкциям эффективный план выполнения запроса. В отличие от других диалектов SQL, в диалекте SQL DB2 практически отсутствуют подсказки оптимизатору, мало развит (а долгое время вообще отсутствовал) язык хранимых процедур, и, таким образом, всё направлено на поддержание декларативного стиля написания запросов. Язык SQL DB2 при этом является вычислительно полным, то есть потенциально позволяет в декларативной форме определять любые вычислимые соответствия между исходными данными и результатом. Это достигается в том числе за счёт использования табличных выражений, рекурсии и других развитых механизмов манипулирования данными.

Благодаря приоритету IBM в развитии реляционной теории и позициям фирмы в компьютерной отрасли, диалект DB2 SQL оказывает значительное влияние на стандарты SQL ANSI/ISO.

Хранимые процедуры в DB2 не очень широко применяются, при этом традиционно для написания хранимых процедур используются обычные языки программирования высокого уровня (Си, Java , PL/I, Кобол и т.д.), это позволяет программисту легко оформлять один и тот же код либо как часть приложения, либо как хранимую процедуру, в зависимости от того, на клиенте или на сервере его целесообразнее выполнять. В настоящее время в DB2 также реализовано процедурное расширение SQL для хранимых процедур в соответствии со стандартом ANSI SQL/PSM.

Оптимизатор DB2 широко использует статистику распределения данных в таблицах (если процесс её сбора был выполнен администратором базы данных), поэтому один и тот же запрос на языке SQL может быть оттранслирован в совершенно различные планы выполнения в зависимости от статистических характеристик данных, которые он обрабатывает.

Поскольку исторически DB2 развивалась с многопользовательских систем на мейнфреймах, то большое внимание в архитектуре DB2 уделяется вопросам безопасности и распределения ролей обслуживающих DB2 специалистов. В частности, в отличие от многих других СУБД , в DB2 имеются отдельные роли для администратора СУБД (ответственного за конфигурирование программных компонентов DB2 и их оптимальное выполнение в компьютерной системе) и администратора базы данных (ответственного за управление данными в конкретной базе).

Использование при необходимости в программах статического SQL и концепции пакетов допускает, в отличие от большинства других СУБД, реализацию такой модели безопасности, когда права на выполнение определённых операций могут выдаваться прикладным программам при отсутствии таких прав у работающих с этими программами пользователей. Это позволяет в таком случае гарантировать невозможность работы пользователя с базой данных в обход прикладной программы, если у пользователя имеются только права на запуск программы, но не на самостоятельную манипуляцию данными.

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

DB2 является единственной реляционной СУБД общего назначения, имеющей реализации на аппаратно-программном уровне (система IBM i; также в оборудовании мэйнфреймов IBM System z реализуются средства поддержки DB2).

Современные версии DB2 обеспечивают расширенную поддержку использования данных в формате XML, в том числе операции с отдельными элементами документов XML.