Published using Google Docs
Лекция 10. Механизмы среды хранения и архитектура СУБД
Updated automatically every 5 minutes

10. Механизмы среды хранения и архитектура СУБД

Механизмы среды хранения БД служат для управления двумя группами ресурсов – ресурсами хранимых данных и ресурсами пространства памяти. В задачу этого механизма входит отображение структуры хранимых данных в пространство памяти, позволяющее эффективно использовать память и определить место размещения данных при запоминании и при поиске данных.

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

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

1. При запоминании нового объекта:

2. При поиске объекта:

3. При удалении объекта:

Примечание: в реляционных СУБД формирование связей осуществляется на логическом уровне (т.е. по значениям атрибутов).

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

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

Структура хранимых данных

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

Хранимые записи одного типа состоят из фиксированной совокупности полей и могут иметь формат фиксированной или переменной длины.

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

Хранимая запись состоит из двух частей:

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

2.     информационная часть. Содержит значения элементов данных.

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

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

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

МЕХАНИЗМЫ РАЗМЕЩЕНИЯ ДАННЫХ И ДОСТУПА К ДАННЫМ

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

Рассмотрим основные способы доступа к данным.

Хеширование

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

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

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

Хеширование не рекомендуется в следующих случаях:

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

Принцип организации кластеров

Кластеризация является методом совместного хранения родственных данных (таблиц).

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

Например, первичный ключ таблицы ТОВАРЫ и внешний ключ таблицы ПОСТАВКИ.

Некластеризованные (а)                 Кластеризованные (б) данные

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

Два основных преимущества кластеров:

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

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

Не следует создавать кластер:

ОРГАНИЗАЦИЯ ПАРАЛЛЕЛЬНОГО ДОСТУПА К ДАННЫМ

Параллельный доступ к данным подразумевает одновременное выполнение двух и более запросов к одним и тем же объектам данных (таблицам, блокам и т.п.). Для организации одновременного доступа не обязательно наличие многопроцессорной системы. На однопроцессорной ЭВМ запросы выполняются не одновременно, а параллельно. Обычно для каждого запроса выделяется некоторое количество процессорного времени (квант времени), по истечении которого выполнение запроса приостанавливается, он ставится в очередь запросов, а на выполнение запускается следующий (по очереди) запрос. Таким образом, процессорное время делится между запросами, и создаётся иллюзия, что запросы выполняются одновременно.

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

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

Транзакция обладает следующими свойствами:

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

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

2.     Согласованность: транзакция начинается на согласованном множестве данных и после её завершения множество данных также согласовано.

3.     Изолированность, т.е. отсутствие влияния транзакций друг на друга.

4.     Продолжительность: результаты зафиксированной транзакции не могут быть потеряны. Возврат БД в предыдущее состояние может быть достигнут только путём запуска компенсирующей транзакции.

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

– фиксация транзакции:         COMMIT [WORK];

– откат транзакции:                ROLLBACK [WORK];

– точка сохранения:                SAVEPOINT <имя_точки_сохранения>;

Фиксация транзакции заключается в следующем:

1.     Изменения, внесённые транзакцией, делаются постоянными.

2.     Уничтожаются все точки сохранения для данной транзакции.

3.     Завершается транзакция (уничтожаются системные записи о транзакции в оперативной памяти).

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

Для организации отката СУБД во время выполнения транзакции производит запись в сегменты отката всех внесённых изменений.

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

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

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



 

Архитектура корпоративной среды обработки транзакций (Enterprise Transaction Processing - ETP) представлена на рисунке.

Это три ряда компьютеров:



Компьютеры ряда 1, функционирующие под управлением DOS, MS Windows, OS/2, UNIX, используются в качестве рабочих мест конечных пользователей. Характерная черта ETP - отсутствие ограничений на модели компьютеров, составляющих этот ряд. Однако, как правило, ряд 1 состоит из компьютеров на базе процессоров Intel 486/Pentium под управлением MS Windows (MS Windows фактически стала стандартом оконного графического интерфейса для большинства категорий пользователей и стандартом операционной среды для подавляющего числа прикладных программ и систем).

Ряд 2 составляют компьютеры среднего класса под управлением ОС UNIX, и, как правило, реляционные СУБД (Oracle, Informix, Ingres), выступающие в качестве менеджера ресурсов.

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

Таким образом, среда обработки транзакций формируется из набора разнородных компьютеров (и соответствующих ОС), ранжируемых от персональных компьютеров до мэйнфрейм-систем. TPM на базе UNIX представляет собой своего рода "клей", который связывает вместе компьютеры трех рядов в открытую унифицированную среду обработки транзакций.

Ключом к интеграции систем, функционирующих на компьютерах различных рядов, является специализированный интерфейс прикладного программирования ATMI (Application Transaction Manager Interface), обеспечивающий:

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

Обеспечение защиты данных

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

Защита включает в себя две основные функции:

Безопасность данных (обеспечение физической защиты)

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

Наиболее типичными сбоями являются следующие:

1.     Пользовательские ошибки.

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

2.     Сбой предложения.

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

3.     Сбой процесса.

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

4.     Сбой экземпляра базы данных (сервера).

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

5.     Сбой носителя (диска).

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

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

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

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

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

Обычно технология проведения резервного копирования такова:

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

Рассмотрим структуру журнала транзакций на примере СУБД Oracle8.

Структура журнала транзакций СУБД Oracle8

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

СУБД применяет два этапа при восстановлении после сбоев: прокрутку вперед и прокрутку назад.

1.     Прокрутка вперед.

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

2.     Прокрутка назад.

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

Защита от несанкционированного доступа

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

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

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

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

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

Парольная идентификация заключается в присвоении каждому пользователю двух параметров: имени (login) и пароля (password). При входе в систему она запрашивает у пользователя его имя, а для подтверждения того, что это имя ввел его владелец, система запрашивает пароль. Имя выдаётся пользователю при регистрации администратором, а пароль пользователь устанавливает сам.

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

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

Основные функции СУБД:

Непосредственное управление данными во внешней памяти

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

Управление буферами оперативной памяти

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

Управление транзакциями

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

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

 Журнализация

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

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

Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

Поддержка языков БД

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

Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language).

Язык SQL позволяет определять схему реляционной БД и манипулировать данными. Язык SQL содержит специальные средства определения ограничений целостности БД. Специальные операторы языка SQL позволяют определять так называемые представления БД, фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является таблица) с именованными столбцами. Авторизация доступа к объектам БД производится на основе специального набора операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Полномочия пользователей описываются в специальных таблицах-каталогах, а их контроль поддерживается на языковом уровне.

Типовая организация современной СУБД

Логически в современной реляционной СУБД можно выделить:

В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД.

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

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

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

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

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