Чтобы обеспечить приложению доступ к части данных, DB2 может запросить для приложения “разделяемую блокировку” (если приложение только читает данные) или “исключающую блокировку” (если оно также модифицирует данные). Если никто не использует данные, получение блокировки гарантировано. Если другое приложение уже заблокировало данные в режиме разделяемой блокировки, гарантируется получение только разделяемой блокировки на эти же данные. Приложения, которые не получают требуемую блокировку, вынуждены ждать.
Для некоторых типов запросов неважно, данные в согласованном состоянии или нет. Хорошим примером такого типа запросов будет запрос бизнес-аналитика, который хочет знать, как много продуктов ‘Y’ уже продано. Ему нужны приблизительные цифры. Если бы он запустил запрос, требующий челостности данных, то параллельные приложения, добавляющие информацию о продажах в таблицу, вынуждены были бы ждать завершения этого запроса. Но так как аналитику требуются только приблизительные цифры, этого можно избежать.
Системный журнал DB2
Операция модификации данных DB2 выполняется в памяти, в “буферах данных”. Запись модифицированных данных на диск может произойти в любой момент, перед или после того, как изменения будут зафиксированы или откачены назад. Однако при каждом выполнении операции COMMIT или ROLLBACK выполняется операция ввода-вывода и помещается информация в журнальный набор данных.
Журнальный набор данных позволяет DB2 восстанавливать данные даже при сбое системы, и поэтому, он всегда должен содержать последние введенные пользователем данные. Прежде чем измененные данные помещаются в базу данных, в журнальный набор данных записывается соответствующая информация.
Получение резервной копии происходит в результате выполнения утилиты COPY.
В промежутках между получением резервных копий DB2 продолжает запись всех изменений в журнальный набор данных. Если по какой-то причине данные были разрушены не по вине DB2 (например, сбой диска), утилита DB2 RECOVERY в состоянии восстановить данные из образа, созданного при копировании, а затем применить к ним записи из журнального набора данных с момента создания копии этой копии.
Чтобы DB2 могла восстановить “испорченные” данные, должна быть либо резервная копия этих данных, либо эти данные должны быть журналированы (что всегда выполняется для SQL-запросов, но не всегда для утилит).
Обеспечивать возможный уровень производительности - задача DB2
Приложение с помощью SQL-запроса формулирует свои требования (что она хочет).
Система должна определить, как наиболее эффективно выполнить SQL-запрос.
Если приложение содержит SQL-операторы, то традиционный процесс компиляции потребует небольшой дополнительной работы. Наиболее важным моментом является так называемая BIND-операция, во время выполнения которой DB2 определяет путь исполнения запроса.
BIND-операция создает путь исполнения запроса и сохраняет его в управляющем наборе данных DB2. Позже, во время выполнения приложения, DB2 просто загрузит путь исполнения запроса в память и выполнит его.
Каталог DB2
CREATE STOGROUP CREATE DATABASE
SYSVOLUMES
SYSTABLESPACE SYSTABLES
SYSTABLEPART SYSCOLUMNS
SYSFIELDS
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.