    Приложение Б 

    Система DB2 пример практического воплощения реляционного подхода 

    Б.1. Введение 

    Для того чтобы дать читателю представление о том, как работает реальная 
реляционная СУБД, т.е. как в ней воплощены особенности реляционной модели (по 
крайней мере некоторые из них, поскольку, как упоминалось ранее в этой книге, 
не все аспекты реляционной модели используются в современных коммерческих 
продуктах), в этом приложении приводится краткий обзор одной из реляционных 
систем, а именно системы DB2 (IBM DATABASE 2) корпорации IBM [Б.1-Б.7]. 

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

    •   Система DB2/6000 для среды AIX. 
    •   Система DB2/2 (изначально называвшаяся OS/2 Database Manager) для 
операционной системы OS/2. 
    •  Система SQL/DS для сред VM и VSE (в фирме IBM для этого продукта 
недавно принято название "DB2 for VM and VSE"). 
    •  Система DB2/400 (изначально называвшаяся SQL/400) для операционной 
системы OS/400. 
    Эти программные продукты принадлежат одному семейству и поэтому во многом 
похожи, однако в этом приложении основное внимание уделяется программному 
продукту для операционной системы MVS, т.е. далее под названием DB2 будет 
подразумеваться именно эта версия системы DB2, за исключением особо 
оговоренных случаев. Точнее, речь пойдет о последней к моменту выхода данной 
книги версии этого продукта, а именно DB2 Version 3 Release I. При описании 
этой системы многие подробности, не имеющие прямого отношения к теме 
обсуждения, опускаются. 
    В DB2, как и во многих других коммерческих реляционных системах, 
поддерживается диалект языка SQL. В частности, это позволяет включать 
SQL-директивы в программы, написанные на самых разнообразных языках (С, COBOL, 
PL/1 и т.д.). Это значит, что программа, написанная, например, на языке COBOL, 
может содержать вставленные SQL-выражения, которые перемежаются с выражениями 
на языке COBOL (что разъяснялось ранее в этой книге). В этом приложении по 
некоторым причинам (они станут понятны несколько позже) основное внимание 
уделяется именно вставленным выражениям. 
    Замечание. Поскольку DB2 является SQL-системой и вместо реляционных 
терминов отношение, кортеж и атрибут использует термины языка SQL таблица 
(table), строка (row) и столбец (column), в этом приложении изложение ведется 
с тех же позиций. Впрочем, в таком же стиле велось изложение и ранее, когда 
приходилось встречаться с языком SQL. 

    Приложение Б. Система DB2... 719 


    Б.2. Структура хранения 

    На рис. Б, 1 схематически показано устройство основных компонентов 
структуры хранения системы DB2 и связи между ними. Ниже перечислены некоторые 
основные черты этой структуры хранения. 
    •   Весь набор хранимых данных разделяется на несколько несвязанных баз 
данных, одни из которых используются системой, а другие — пользователями. (В 
главе 1 были перечислены некоторые практические причины разделения данных на 
несколько различных баз данных. В системе DB2, как и во многих других 
системах, поддерживается такая же организация.) Обратите внимание, что каталог 
системы DB2 сохраняется в одной из системных баз данных. 
    Базы данных (здесь имеются в виду пользовательские базы данных) являются 
модулями запуска и остановки в том смысле, что системный оператор может 
включить или исключить их из общего процесса обработки данных с помощью 
соответствующих команд START и STOP. 
    •  Вообще, каждая база данных разделена на несвязанные пространства—- 
несколько табличных пространств и несколько индексных пространств. Под 
пространством подразумевается набор страниц, описанный в приложении А, т.е. 
динамически расширяемое множество страниц. Страницы в данном пространстве 
имеют одинаковый размер — 4 Кбайт для индексных пространств, и 4 Кбайт или 32 
Кбайт для табличных пространств (1 Кбайт = 1024 байт). На физическом уровне 
DB2 для хранения этих пространств на диске в системе MVS используется метод 
доступа VSAM (Virtual Storage Access Method). 

    Табличное пространство Табличное   / пространство 1 Индексные 
пространства	Пользовательская база данных			Пользовательская база данных		База 
данных каталога 
    Хранимая  Хранимая таблица      таблица	Хранимая таблица		Хранимая 
Хранимая   табяица таблица	• ••	Таблица каталога 
    
    
    Таблица   Таблица каталога  каталога 
    Хранимая таблица 
    
    Хранимая            Хранимая таблица               таблица 
    • • •		• • • 
    • • • 
    Индекс                  1 
    |                  Индекс                  | 
    Индекс			Индекс		Индекс 
    
    
    Рис. Б.1. Основные объекты структуры хранения системы DB2 

    •  Каждое табличное пространство содержит одну или несколько хранимых 
таблиц, которые являются представлением базовых таблиц и содержат несколько 
хранимых записей, по одной для каждой строки соответствующей базовой таблицы. 
(Иначе говоря, базовые таблицы в системе DB2 "существуют физически" в том 
смысле, что представляют собой непосредственную форму хранения. Однако, как 
объяснялось ранее в этой книге, физическое существование базовых таблиц не 
является отличительной характеристикой реляционной модели.) Хранимая

    720 Приложения 

таблица соответствует хранимому файлу, описанному в приложении А. (Исключение 
состоит в том, что очень большие хранимые таблицы можно "разделить" на 
несколько хранимых файлов для эффективного управления ими. Однако этот факт 
никак не связан с вопросами, обсуждаемыми в данном приложении.) Хранимая 
таблица должна полностью содержаться в одном табличном пространстве. 
    •   Каждое индексное пространство содержит только один индекс (структуру 
типа Б-дерева). Индекс должен содержаться только внутри одного индексного 
пространства, а хранимая таблица и все связанные с ней индексы должны 
полностью содержаться внутри одной базы данных. 

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

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

    Замечание. Хранимая запись кодируется таким образом, чтобы при 
использовании инструкции логического сравнения CLC в компьютерах IBM 
System/360 (370, 390,...) всегда выполнялось согласование типа данных для двух 
используемых значений SQL-выражения. Например, бинарные целые хранятся с 
обращенным знаковым битом. 

    Как упоминалось в приложении А, адреса хранимых записей задаются с помощью 
идентификационного номера записи (record ID — RID). 

    Б.З. Системные компоненты 

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

    Приложение Б. Система DB2...	721 

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

    Модифицированный исходный модуль 
    Модуль 
    запросов 
    к базе 
    данных 
    Компилятор 
    
    (Загрузочный модуль) (План приложения) 
    Координатор стадии исполнения 
    Диспетчер хранимых данных 
    Диспетчер буферов 
    (Другие) 
    *> 
    База данных 
    
    
    Оперативная память 

    Рис. Б.2, Подготовка и последующее выполнение приложения в системе DB2 


    722 Приложения 

    •   Прекомпилятор выполняет предварительную компиляцию программ, которые 
содержат SQL-выражения. При этом такие выражения помещаются в модуле запросов 
к базе данных (Database Request Module — DBRM), а на их месте с помощью 
инструкций типа CALL в программном коде организуются вызовы к координатору 
стадии исполнения. 
    •   Компоновщик на основе одного или нескольких модулей запросов к базе 
данных создает план приложения (или план прикладной задачи), т.е. исполняемый 
код для воплощения SQL-выражений в этих модулях, включая вызовы координатора 
стадии исполнения. 
    •   Координатор стадии исполнения следит за выполнением программ, 
содержащих SQL-выражения. При выполнении какого-либо запроса программы 
управление сначала передается координатору стадии исполнения благодаря 
операторам вызова, установленным с помощью прекомпилятора. После этого 
координатор стадии исполнения передает управление плану приложения, который, в 
свою очередь, посылает запрос диспетчеру хранимых данных. 
    •  Диспетчер хранимых данных управляет хранимой базой данных, извлечением 
и обновлением записей, которые были заданы планом приложения. Иначе говоря, он 
выполняет функции, присущие диспетчеру файлов, который был описан в приложении 
А. При этом во время выполнения основной задачи вызываются другие необходимые 
компоненты для выполнения таких дополнительных функций, как блокировка, 
идентификация, сортировка и т.д. Например, для выполнения физических операций 
ввода-вывода вызывается диспетчер буферов. 
    •   Диспетчер буферов предназначен для физического обмена страницами 
данных между диском и оперативной памятью, т.е. для выполнения описанных выше 
операций ввода-вывода. Используя терминологию приложения А, можно отметить, 
что так же, как диспетчер хранимых данных можно сопоставить с диспетчером 
файлов, диспетчер буферов можно сопоставить с диспетчером дисков. 

    Б.4. Подробное описание потока управления 

    В этом разделе более подробно описываются некоторые идеи и основные этапы 
подготовки и выполнения приложения в системе DB2 (см. рис. Б.2), 
представленные в предыдущем разделе. Предположим, что код программы Р написан 
на языке COBOL (этот язык выбран лишь в качестве примера, для других языков 
весь процесс в целом будет выглядеть так же). Ниже приведена 
последовательность выполнения подготовки и запуска приложения на основе 
программы Р. 
    \.  Прежде чем компилировать код программы Р с помощью компилятора языка 
COBOL, его необходимо обработать прекомпшятором системы DB2, который 
применяется для всех используемых в системе DB2 языков программирования. 
Основная задача прекомпилятора заключается в анализе кода программы, поиске 
SQL-выражений и замене их с помощью оператора CALL инструкциями вызова. После 
запуска приложения для выполнения этих выражений управление будет передаваться 
координатору стадии исполнения. На основе найденных SQL-выражений 
прекомпилятор создаст DBRM-модуль запросов к базе данных, который впоследствии 
будет обработан компоновщиком. 

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

    2.  Затем модифицированная программа на языке COBOL будет скомпилирована и 
скомпонована обычным способом. Далее результат выполнения этого этапа будет 
называться "загрузочным модулем Р". 

    Приложение Б, Система DB2...	723 


    3.  После этого наступает очередь компоновщика, который в действительности 
является компилятором SQL-выражений и конвертирует запросы к базе данных (т.е. 
SQL-выражения) в исполняемый код. (Более того, он является оптимизирующим 
компилятором, поскольку благодаря компоновщику код не только компонуется, но и 
оптимизируется. Иначе говоря, важный оптимизирующий элемент в системе DB2 
является подчиненным элементом компоновщика. Дополнительная информация об 
оптимизации представлена в следующем разделе.) 
    Входной информацией для компоновщика являются DBRM-модули запросов к базе 
данных (или набор нескольких DBRM-модулей, если в оригинальной программе 
содержится несколько отдельно компилируемых процедур). Результат работы 
компоновщика, т.е. компилированный код, который уже упоминался как план 
приложения, сохраняется в каталоге системы DB2, где он впоследствии может быть 
найден координатором стадии исполнения. 
    4.  Наконец, несколько слов о запуске приложения. Поскольку оригинальная 
программа была, по сути, разделена на две части (загрузочный модуль и план 
приложения), их необходимо каким-то образом вновь объединить на этапе 
выполнения. На рис. Б.2 схематически показан этот процесс. Сначала загрузочный 
модуль Р загружается в оперативную память и запускается обычным образом. 
Спустя некоторое время, наступает очередь выполнения одного из вызовов на 
основе инструкции CALL, вставленной прекомпилятором. После этого управление 
передается координатору стадии исполнения, который извлекает план приложения 
из каталога, загружает в оперативную память и передает ему управление. План 
приложения, в свою очередь, вызывает диспетчер хранимых данных, который 
выполняет необходимые операции с хранимыми данными (вызывая при необходимости 
диспетчер буферов) и передает назад соответствующие результаты. 

    Б.5. Компиляция и перекомпиляция 

    Во всех предыдущих разделах был опущен один чрезвычайно важный момент. Как 
уже упоминалось, система DB2 является компилируемой системой, т.е. запросы к 
базе данных компилируются (компоновщиком) во внутреннюю форму. Хотя многие 
другие системы и все системы нереляционного типа, наоборот, являются 
интерпретируемыми системами. С точки зрения эффективности компилируемые 
системы обладают более высокой производительностью, чем интерпретируемые [Б. 
10]. Однако компилируемые системы обладают и существенным недостатком. Дело в 
том, что предпринятые во время компиляции (с помощью компоновщика) заключения 
могут оказаться ложными во время выполнения. Ниже приведен пример 
возникновения такой ситуации. 
    1.  Предположим, что программа Р откомпилирована в понедельник, а для 
оптимизации стратегии доступа решено использовать индекс X, Тогда в плане 
приложения применяются явным образом ссылки, заданные по именам индекса X. 
Иначе говоря, генерируемый код будет сильно связан с выбором стратегии (т.е. в 
значительной степени будет зависеть от него). 
    2.  Допустим во вторник некий пользователь, обладающий соответствующими 
правами, задаст следующую команду: 
    DROP INDEX X ; /* удалить индекс X */ 
    3.  А теперь представьте себе, что случится, когда в среду некий 
пользователь, обладающий соответствующими правами, попытается вновь запустить 
программу Р. 
    А случится вот что. Если удалить индекс, система DB2 попытается найти в 
каталоге планы, зависящие от данного индекса, и отметить их как 
недействительные ("invalid"). Если координатор стадии исполнения извлечет 
такой план для

    724	Приложения 

выполнения, будет обнаружен маркер "недействителен" ("invalid"), а затем вызван 
компоновщик для подготовки нового плана, т.е. будет выбрана новая стратегия 
доступа и в соответствии с ней перекомпилирован исходный DBRM-модуль (который 
был сохранен в каталоге). Если перекомпиляция прошла успешно, новый план 
заменит прежний и координатор стадии исполнения продолжит работу с новым 
планом. Таким образом, процесс перекомпиляции в целом будет незаметен для 
пользователя, кроме некоторого замедления выполнения отдельных SQL-выражений. 
Хотя при этом возможно некоторое понижение общей производительности системы, 
перекомпиляция не окажет никакого влияния на логику программы. 
    Обратите внимание, что в данном случае речь идет об автоматической 
перекомпиляции на основе языка SQL, а не COBOL, т.е. в результате удаления 
индекса недействительной стала не программа на языке COBOL, а план приложения, 
связанный с этой программой. 
    Теперь становится ясно, каким образом программы могут не зависеть от 
физических структур доступа или, точнее, как можно создать (удалить) такие 
структуры, не переписывая заново программы. Как отмечалось ранее в этой книге, 
такие SQL-выражения, как SELECT и UPDATE, не содержат явного упоминания 
подобных структур, а всего лишь указывают, какие данные интересуют 
пользователя. Выбор способа получения этих данных или изменение прежнего 
способа осуществляется самой системой DB2, точнее, компоновщиком. Системы типа 
DB2 обеспечивают высокую степень независимости данных (конкретнее, физическую 
независимость данных, отличную от логической независимости, описанной в главе 
17), поскольку даже в компилируемой системе пользователи и их программы могут 
работать независимо от физической структуры хранимых данных. 

    Замечание. Независимость данных легче организовать в интерпретируемой 
системе, поскольку процесс компиляции и оптимизации повторяется каждый раз при 
запуске интерпретируемой программы. Но для таких повторов требуются 
дополнительные расходы времени и других ресурсов. Именно поэтому для системы 
DB2 был вы-i*f ан компилируемый тип. 

    Следует подчеркнуть еще один важный момент. Приведенный пример 
перекомпиляции иллюстрирует поведение системы при удалении индекса, что 
происходит довольно часто на практике. Однако такая же последовательность 
действий выполняется и при удалении других объектов (не только индексов). 
Например, при удалении базовой таблицы все связанные с ней планы приложения 
будут отмечены, как недействительные. Конечно, автоматическая перекомпиляция 
произойдет только в том случае, если будет создана другая таблица с именем 
прежней (и не произойдет, если между вновь созданной и удаленной таблицами 
есть значительная разница). 
    Возвращаясь к описанному ранее примеру с удаленным индексом, можно задать 
вопрос, возможна ли перекомпиляция при создании нового индекса. Это 
невозможно, так как нет полной уверенности в том, что при такой перекомпиляции 
система будет работать в оптимальном режиме. Наоборот, может оказаться, что 
после перекомпиляции потребуется выполнить множество лишних действий, 
поскольку прежний компилируемый код уже был создан согласно некоторой 
оптимальной стратегии. При удалении объекта ситуация несколько иная, так как 
программа может просто не работать при отсутствии некоторого несуществующего 
объекта (индекса или какого-либо другого), поэтому в таком случае 
перекомпиляция необходима. Таким образом, если некоторый пользователь, обычно 
это администратор базы данных, создает новый индекс и предполагает, что с его 
помощью можно добиться повышения производительности программы, то ему следует 
явным образом выполнить перекомпиляцию с помощью команды REB1ND. (Возможно, в 
будущем в системе DB2 будет пр едусмотрена автоматическая перекомпиляция при 
вставке новых индексов.) Хотя даже в этом случае нет никаких гарантий, что в 
новом плане приложения будет использован новый индекс. 

    Приложение Б. Система DB2...	725 

    В заключение следует отметить, что SQL-выражения всегда компилируются в 
системе DB2 и никогда не интерпретируются, даже если эти выражения созданы в 
интерактивном режиме. Иначе говоря, если пользователь вводит выражение с 
директивой SELECT, оно будет откомпилировано, для него будет создан план 
приложения, план будет запущен, а после выполнения удален. Как показывают 
результаты экспериментов, даже при использовании системы, повторно 
компилируемой в интерактивном режиме, достигается более высокая 
производительность, чем для интерпретируемой системы [Б. 10]. Преимущество 
компиляции состоит в том, что реальный процесс физического доступа к заданным 
данным более эффективен, поскольку основан на оптимизированном и 
компилированном коде. Недостатком такого подхода является необходимость 
предварительного создания компилированного кода. Однако перечисленные 
преимущества часто довольно существенно компенсируют этот недостаток. 

    Б.6. Утилиты 

    В этом разделе кратко описаны действия, которые приходится выполнять при 
ежедневной работе с системой типа DB2. Для выполнения многочисленных задач на 
уровне администратора или оператора в системе DB2 предусмотрено использование 
различных утилит и инструментов (они перечислены ниже вместе с краткой 
характеристикой выполняемых с их помощью действий). Помимо этого описана общая 
идеология использования утилит различных типов. Обратите внимание, что данное 
описание весьма упрощенное, а более подробно об утилитах можно прочесть в [Б.7]. 
    •  CHECK. С помощью этой утилиты можно проверить хранимые данные: 
например, соответствует ли данный индекс индексируемой им таблице, не содержит 
ли данная таблица каких-либо "повисших" значений внешних ключевых полей (т.е. 
значений, которым не соответствует ни одна строка в таблице; такая ситуация 
может возникнуть в результате выполнения утилиты LOAD с отключенным режимом 
целостности данных). 
    •  COPY. Эта утилита используется для создания полной или частичной 
архивной копии базы данных или некоторой ее части (подробнее об этом ниже). 
Частичная копия содержит только те страницы, которые были обновлены после 
предыдущего полного или частичного копирования. 
    •   LOAD. Эта утилита предусмотрена для загрузки данных из 
последовательного файла в одну или несколько хранимых таблиц внутри заданной 
базы данных. Перед загрузкой эти таблицы обязательно должны быть пустыми. 
Следует отметить, что утилита LOAD может быть запущена, когда отключен либо 
режим проверки целостности данных, либо режим регистрации, либо оба режима. 
    •  MERGECOPY. С помощью этой утилиты объединяются либо полная копия с 
одной или несколькими частичными копиями, образуя при этом обновленную полную 
копию, либо набор частичных копий для последующего создания обновленной 
составной частичной копии. 
    •  QUIESCE. Эта утилита используется для временного прекращения выполнения 
операций с некоторым набором базовых таблиц. Такое состояние соответствует 
одной позиции в файле регистрации, так что этот набор таблиц впоследствии 
можно легко восстановить. В частности, утилита QUIESCE может быть весьма 
полезной для указания положения целостности набора таблиц, связанных с 
ссылочными ограничениями. Это положение можно использовать впоследствии для 
восстановления данных в состояние целостности (об этом также идет речь в 
следующем пункте). 
    •  RECOVER. С помощью этой утилиты самая последняя полная копия, все 
последующие частичные копии и сведения о состоянии базы данных используются 
для восстановления данных, например после краха операционной системы. Кроме

    726	Приложения 

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

    EXPLAIN 

    EXPLAIN — это специальное SQL-выражение, которое используется для 
получения информации об оптимальном выборе стратегии доступа для заданного 
SQL-запроса. (Выражение EXPLAIN не предусмотрено в стандарте языка SQL [8.1], 
но поддерживается в той или иной форме во многих программных продуктах, 
которые работают на основе языка SQL.) Получаемая информация содержит сведения 
об используемых индексах, разного рода подробности, а также (если заданный 
запрос включает какие-либо соединения) порядок соединения таблиц и методов, с 
помощью которых реализуются отдельные соединения (подробнее это описано в 
главе 18). Такая информация может быть полезной для настройки существующих 
приложений, а также для определения способа функционирования проектируемых 
приложений. Ниже приведен пример использования выражения EXPLAIN. 

    EXPLAIN PLAN FOR 
    SELECT S.S#, P.P# 
    FRCM  S, P 
    WHERE    S.CITY = P.CITY ; 

    Результат выполнения выражения EXPLAIN размещается в специальной таблице 
базы данных под названием PLAN_TABLE. Пользователь может впоследствии с 
помощью обыкновенного SQL-выражения SELECT создавать на основе этой таблицы 
запросы: например, используется ли данный индекс или позволяет ли создание 
нового индекса избежать необходимости проводить сортировку. 

    Контрольное оборудование 

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

    Приложение Б. Система DB2...	727 

    Б.7. Резюме 

    В данном приложении приведен краткий обзор системы DB2 для создания общего 
представления о реальной реляционной системе. Сначала были описаны основные 
объекты хранения системы DB2 -— базы данных, табличные и индексные 
пространства (аналогичные наборам страниц из приложения А), хранимые таблицы 
(аналогичные хранимым файлам из приложения А), а также индексы (Б-деревья 
системы DB2). Хранимая таблица является хранимой версией базовой таблицы, на 
основе которой в системе DB2 (как и во многих других современных коммерческих 
программных продуктах такого рода) непосредственным образом отображаются 
базовые таблицы на физическую структуру хранения. Поэтому в ней не 
обеспечивается такой независимости данных, которую следовало бы обеспечить 
(подробнее это описано в главах 3 и 4). 
    Далее были описаны этапы подготовки и выполнения прикладной программы. 
Сначала с помощью прекомпилятора из программы удаляются SQL-выражения (с 
заменой их инструкциями CALL) и используются для создания модулей запросов к 
базе данных (DBRM-модулей). Затем программа компилируется и компонуется 
обычным способом. DBRM-модули данной программы обрабатываются компоновщиком 
для создания плана приложения, т.е. компилированной версии исходных 
SQL-выражений (в этом случае компоновщик можно рассматривать как 
оптимизирующий SQL-компилятор). Во время выполнения программы операторы CALL, 
вставленные предварительным компилятором, передают контроль координатору 
стадии исполнения, который, в свою очередь, вызывает диспетчер хранимых данных 
(аналог диспетчера файлов из приложения А) для выполнения заданных операций с 
хранимыми данными. Диспетчер хранимых данных, в свою очередь, вызывает 
диспетчер буферов (аналог диспетчера дисков из приложения А) для выполнения 
физических операций ввода-вывода страниц. 
    В этом приложении особое внимание уделялось тому факту, что SQL-запросы в 
системе DB2 компилируются, а не интерпретируются, а также объяснялось, как в 
системе DB2 выполняется автоматическая перекомпиляция в случае необходимого 
изменения физической структуры хранения, например при удалении индекса. 
    Наконец, был дан краткий обзор наиболее важных утилит системы DB2 (CHECK, 
LOAD, COPY и т.д.), а также некоторых полезных инструментов, таких как, 
например, EXPLAIN. 

    Упражнения 

    Б.1. Назовите четыре основных компонента системы DB2. 
    Б.2. Нарисуйте схему общего процесса подготовки и выполнения программы в 
системе DB2. 
    Б.З. Объясните, как в системе DB2 обеспечивается физическая независимость данных. 
    Б.4. Перечислите основные объекты хранения системы DB2. 
    Б.5. Какова максимальная длина хранимой записи в байтах в системе DB2? 
Обратите внимание, что эта длина больше максимальной длины записи базовой 
таблицы. Почему? 
    Б.6. Что такое индекс кластеризации? Почему в данной хранимой таблице 
может быть не более одного такого индекса? Каковы преимущества использования 
такого индекса? 
    Б.7. Компоновщик системы DB2 содержит в качестве важного дополнительного 
компонента оптимизатор, который отвечает за выбор стратегии воплощения 

    728	Приложения 

запросов к базе данных (т.е. SQL-выражений). Например, он принимает 
решение, когда использовать или не использовать индексы. Каким образом 
оптимизатору известно о существовании индексов? Как оптимизатор распознает, 
является ли данный индекс индексом кластеризации? 
    Б.8. Расскажите о выражении EXPLAIN. 

    Список литературы 

    Работы [Б. 1-Б.5] являются руководствами пользователя системы DB2 фирмы 
IBM, a [Б.8-Б.10] связаны с различными аспектами системы System R, которая 
является предшественником системы DB2 и других SQL-продуктов фирмы IBM (этой 
теме также посвящены работы [8.12-8.16; 18.29, 18.30]). 
    Замечание. Следует помнить, что после выпуска нескольких коммерческих 
версий продукта некоторые детали внутреннего устройства системы DB2, в 
частности механизмы компиляции и оптимизации, претерпели существенные 
изменения и в значительной степени отличаются от первых версий системы System 
R. С этой точки зрения описания системы System R представляют лишь 
исторический интерес. 
    Б.1. IBM Corporation. IBM Database 2. Version 3. General Information.— IBM Form№GC26-4373. 
    Б.2. IBM Corporation. IBM Database 2. Version 3. Administration Guide (в 
3-х томах). — IBM Form № SC26^374. 
    Б.З. IBM Corporation. IBM Database 2. Version 3. SQL Reference.— IBM Form 
№ SC26-4380. 
    Б.4. IBM Corporation. IBM Database 2. Version 3. Application Programming 
and SQL Guide. — IBM Form № SC26-4377. 
    Б.5. IBM   Corporation.   IBM   Database   2.   Version   3.   Command   
and   Utility Reference. — IBM Form № SC26^t378. 
    Б.6. DB2 Special Issue // IBM Sys. J. — 1984. — 23, № 2. 
    Это серия технических статей о первой версии системы DB2. 
    Б.7. Date   C.J.,   White   C.J.   A   Guide   to   DB2   (4th   ed.). —   
Reading,   Mass.: Addison-Wesley, 1993. 
    Обширный и детальный обзор системы DB2 и некоторых сопутствующих 
продуктов. Большая часть данного приложения написана на основе материала из 
этой книги. 
    Б.8. Lorie R.A., Wade B.W. The Compilation of a High-Level Data Language 
// IBM Research Report RJ2598. — 1979. 
    Схема компиляции/перекомпиляции была впервые реализована на основе системы 
System R. В статье подробно описаны некоторые детали механизма работы System R. 
    Б.9. Lorie R.A., Nilsson J.F. An Access Specification Language for a 
Relational Data Base System // IBM J. R&D. — 1979. — 23, № 3. 
    Более подробное описание процесса компиляции в системе System R. Для 
всякого заданного SQL-выражения оптимизатор системы System R генерирует 
программу на внутреннем языке ASL (Access Specification Language). Этот язык 
может рассматриваться как интерфейс между оптимизатором и генератором кода. 
(Генератор кода, судя по его названию, преобразует программу на языке ASL в 
машинный код.) Язык ASL состоит из операторов "сканирования" и "вставки" 
объектов типа индекса и хранимого файла. Цель языка ASL — более совершенное 
управление процессом трансляции на основе набора хорошо определенных 
дополнительных процессов. 

    Приложение Б. Система DB2...	729 

    Б. 10. Chamberlin D.D. et al. Support for Repetitive Transactions and 
Ad-Hoc Queries in System R // ACM TODS. — 1981. — 6, № 1. 
    В работе даны некоторые результаты измерений производительности системы 
System R как для незапланированных запросов (типа ad hoc), так и для операций 
типа "запрограммированная транзакция". (Запрограммированная транзакция — это 
простое приложение, в котором осуществляется доступ только к малой части базы 
данных и которое компилируется до этапа выполнения. Оно в некотором отношении 
подобно запланированному запросу.) Измерения проводились на компьютере системы 
IBM System 370 Model 158 с системой System R под управлением операционной 
системы VM. Несмотря на то что эти результаты названы "предварительными", в 
статье, помимо прочего, убедительно показано, что: компиляция всегда обладает 
преимуществом перед интерпретацией, даже для незапланированных запросов; 
система типа System R может обрабатывать несколько запрограммированных 
транзакций в секунду при условии, что в базе данных существуют соответствующие индексы. 
    Эта статья была одной из первых на эту тему; с тех пор несколько 
программных продуктов реляционного типа, включая, в частности, систему DB2, 
достигли производительности, которая сравнима с наилучшими значениями, 
показанными любыми другими СУБД, как реляционными, так и не реляционными. В 
частности, уже была продемонстрирована скорость обработки данных в сотни и 
даже тысячи транзакций в секунду. 

    Ответы к некоторым упражнениям 

    Б.1, Четыре главных компонента системы DB2— это компоненты системного 
управления, блокирования, управления базой данных и управления распределенными данными, 
    Б.4. Основными объектами хранения системы DB2 являются базы данных, 
табличные пространства, индексные пространства, хранимые таблицы и индексы. 
    Б.5. Поскольку каждая хранимая запись должна полностью содержаться внутри 
одной страницы, максимальная длина хранимой записи в системе DB2 
ограничивается размером страницы (4 либо 32 Кбайт). Максимальная длина записи 
базовой таблицы меньше, поскольку хранимая запись дополнительно содержит 
некоторую управляющую информацию, например в приставке хранимой записи, 
которая скрыта от пользователя. 
    Б,6. Индексом кластеризации называется индекс, для которого физическая 
последовательность индексированных данных такая же или близка к логической 
последовательности тех же данных, представленных этими индексами (подробнее 
это описано в приложении А). По определению данная хранимая таблица не может 
иметь более одного такого индекса, поскольку в хранимой таблице может быть 
только одна физическая последовательность. Преимущество индекса кластеризации 
заключается в том, что при последовательном доступе с помощью этого индекса 
достаточно однократного доступа к каждой странице с данными, причем эта 
операция будет выполнена с максимально возможной скоростью. 
    Б.7. Вся эта информация хранится в каталоге. 

    730	Приложения 

