Целостность БД.

Обеспечение целостности БД, является ключевым компонентом в работе администратора БД.

 

Типы целостности.

По отношению к БД можно рассматривать 2 аспекта целостности бд: структурная, семантическая.

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

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

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

 

Структурная целосность БД.

Она имеет первостепенное значение для администрирования БД. СУБД использует внутренние структуры и указатели для поддержания объектов БД в соответсвующем порядке. Если эти структуры повреждаются, то доступ к БД затрудняется.

 

Лекция №5.

 

Типы струкрутных проблем.

Одной общей проблемой, которая относится ко всем реляционным БД является индексное искажение.

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

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

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

Помимо индексов в СУБД используются указатели для определенных типов данных. 

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

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

 

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

 

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

Целостность БД можно исследовать с помощью программных утилит.

 

Возможности утилиты DBCC.

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

 

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

 

Опции согласованности.

Утилита DBCC представляет 2 опции для базовой согласованности:

1.    DBCC CHECKTABLE (table_name)

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

2.    DBCC PREINDEX (table_name)

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

Лекция №6.

Проверка БД.

Для проверки целостности БД существуют дополнительные опции:

1.      DBCC CHECKDB(database_name)

Запускается CHECKTABLE в каждой таблице БД. Эта опция проверяет согласованность данных и индексных страниц всех определенных таблиц.

2.      ---- CHECKCATALOG(---)

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

3.      ------CHECKALLOC(----)

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

 

 

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

Команда BDCC может быть использована для отслеживания текущего распределения для использования памяти. Например,

BDCC MEMUSAGE.

Утилита сообщает BDCC о сконфигурированном распределении памяти и её использовании 20 основными потребителями. При этом будет отображена следующая информация:

1.      Сконфигурированная память. Указывается объем памяти сконфигурированный для СУБД.

2.      Размер кода – объем памяти использованный кодом.

3.      Ядро и структуры – это объем памяти использованный для ядра и сервера.

4.      Страничный кэш – это объем памяти, использованный для кэша данных.

5.      Процедурные буферы и заголовки – объем памяти, использованный для процедурного КЭШа.

6.      Подробности буферного КЭШа – это список 20 основных пользователей КЭШа с указанием типа БД и объектов, доступ к которым был получан.

7.      Подробности процедурного КЭШа – это список 20 основных пользователей процедурного КЭШа с указаем типа использования и расхода памяти.

 

Для BDCC существуют и дополнительные опции, такие как:

- способность генерировать отчеты, содержащие информацию о внутренних элементах БД

- способность печатать отформатированные страничные таблицы и тд.

 

Семантическая целостность данных.

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

 

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

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

1.Целостность объектов.

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

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

 

Пример.

CREATE TABLE EMP

(empno INTEGER PRIMARY KEY,

emp_address VARCHAR(70),

emp_type CHAR(8),

emp_dept CHAR(3) NOT NULL WITH DEFAULT,

SALARY DECIMAL(7,2) NOT NULL,

Commission DECIMAL(7,2),

Bonus DECIMAL(7,2) ) INdb.t;

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

Сразу после указания последнего столбца таблицы нужно добавить следующую запись.

 

PRIMARY KEY pkemp (empno, emp_type)

 

Но при этом указание ПК должно быть удалено со столбца empno прежде чем это все начнет работать.

 

2.Уникальные ограничения.

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

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

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

 

3.Тип данных и длина

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

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

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

 

Типы данных, определяемые пользователем.

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

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

Контрольные ограничения.

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

 

Лекция №7.

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

Синтаксис контрольного ограничения -  КО = < имя ограничения>  <контрольное условие>.

Имя ограничения – идентифицирует контрольное ограничение в БД. Одно и то же контрольное ограничение не может быть заданно более 1 раза для одной и той же таблицы. Если имя ограничения не кодировано явно. СУБД автоматически генерирует уникальное имя ограничения. Каждое СУБД использует разные алгоритмы для генерирования имени контрольного ограничения. Но обычно имя является производным от имени первого столбца в контрольном условие.

Контрольное условие – фактически определяет логику ограничения и задается с помощью любого из основных предикатов, а также следующих операторов: BETWEEN, IN, LIKE, NULL ; связок: AND и OR, которые связывают условия друг с другом.

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

1.      КО может ссылать только на столбцы в таблице, в которой она была создана.

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

3.      Первый операнд контрольного ограничения является именем столбца, содержащегося в таблице. Второй операнд является либо именем 2ого столбца, либо константой.

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

Преимущества контрольных ограничений.

К основным преимуществам следует отнести:

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

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

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

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

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

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

 

Примеры контрольных ограничений.

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

 

CREATE TABLE EMP

(empno INTEGER PRIMARY KEY,

CONSTRAINT check_empno

CHECK (empno BETWEEN 100 and 25000),

emp_address VARCHAR (70),

emp_type CHAR(8)

CHECK(emp_type IN(‘temp’,’fulltime’,’contract’)),

emp_dept CHAR(3) NOT NULL WITH DEFAULT,

salary DECIMAL(7,2) NOT NULL

CONSTRAINT check_salary

CHECK(salary < 50000,00),

Commission  DECIMAL(7,2),

Bonus DECIMAL(7,2)

) IN bd.ts;

 

Оператор CREATE TABLE emp содержит 3 контрольных ограничения целостности :

1.      Имя первого КО check_empno оно задается в столбце empno. Это ограничение обеспечивает, что столбец empno может содержать только значения из диапазона вмест области всех целых значений.

2.      В столбце emp_type – это пример контрольного ограничения без имени. Это специфическое ограничение. Оно ограничивает значения, которые могут быть установлены в emp_type до :temp< fulltime, contract. Приемлемы только эти значения.

 

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

 

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

Дополним листинг несколькими КО целостности уровня таблицы.

 

CONSTRAIN coinm_vs_salary

CHECK(salary > commission),

CONSTRAIN human_bonus

CHECK (commission = 0 OR bonus =0),

 

Этой вставкой мы добавили 2 КО на уровне таблицы:

1.      Coinm обеспечивает, что не один из работников не может зарабатывать комиссионные больше чем заработная плата.

2.      Human_bonus это ограничение гарантирует, что работник не может получать и бонус и премию одновременно.

 

Нулевые значения и другие потенциальные проблемы.

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

Запуск БД может вызвать проблемы с контрольными ограничениями.

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

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

 

Правила.

В SQL сервере имеется специальный тип КО, который называется правило. И хотя правила аналогичны КО целостности, они являются «автономными» объектами БД. Подобно КО правила определяют параметры для подтверждения данных. И всякий раз, когда данные вставляются или обновляются. Правила проверяются, чтобы гарантировать, что модификация данных подчиняется правилу. Свои правила могут иметь как столбцы, так и определяемые пользователем типы данных.

 

 

 

 

-------------У НИКИТЫ!!!-----------------------

 

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

 

1.Управление траз-ями целостность БД.

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

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

При завершении транзакции оператором COMMIT результат фиксируется во внешней памяти. При завершении оператором ROLLBACK результаты гарантированно отсутствуют во внешней памяти. Понятие транзакции тесно связанно с понятием целостности БД. Оч часто БД может обладать такими ограничениями целостности, которые невозможно не нарушить, выполняя только 1 оператор изменения БД. Например, в БД «Сотрудники отдела» естественным ограничением целостности является значение атрибута ОТД_РАЗМЕР в картеже ОТДЕЛЫ, описывающим данный отдел (например отдел 320). С картежем отношения СОТРУДНИКИ таких, что значение атрибута СОТРУДНИКИ СОТР_ОТД_НОМЕР=320. Каким образом принять сотрудника в отдел 320? нЕЗАВИСИМО от того какая операция будет выполнена 1ой вставка нового картежа в отношение СОТРУДНИКИ или модификация существующего картежа БД окажется в нецелостном состоянии. Поэтому для поддержания подобного сост целостности допускается их нарушение внутри транзакции с тем условием, чтобы к моменту завершения транзакции условия целостности были соблюдены. В системах с развитыми средставми ограничения и контроля целостности каждая транзакция начинается при целостном состоянии БД и должна завершаться, сохраняя состояние БД целостным. Несоблюдение этого условия приводит к тому, что вместо оператора COMMIT  будет выполняться ROLLBACK и БД остается в том состоянии, в котором она была до начала транзакции, т.е. в целостном состоянии.

Различают 2 вида ограничений целостности:

-немедленно проверяемые

-откладываемые

 

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

 

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

 

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

 

Изолированностью пользователей.

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

Уровни изолированности тран=ций:

-уровень потерянных изменений.

Рассмотрим след сценарий совместного выполнения 2х транзакций. ТР1 изменяет объект роблема картежей ROLLBACK.(например по причине наруш-я цел-ти). Например при повторном чтении объекте А ТР1 не видит транз-ций произвд-х раньше. Такая ситуация называется «ситуацией потерянных изменений». Она противоречит требованию изолированности польхзователей. Чтобы избежать такй ситуации ТР1 требуется чтобы до заверш ТР1 никакая др транз-ция не могла изменять А. Отсутсвие потерянных изменений явл-ся мин требованием к СУБД по части синхронизации парал-но выполняемых транз-ций.

2ой уровень. Отсутствие чтения «грязных данных».

ТР1 изменяет А. Парал-но ТР2 читает А. По скольку опеоации изменения ещё не завершн, то ТР2 видит несогласованные «грязные данные»(в частности операция ТР1 мб отвержена при немедленной проверке). Это несоотв

Кажд польз начинает свою транзакцию и в праве. Чтобы избежать ситуацию  с чтением гряз дан до ТР1 изменивший А, никакая др тран-ция не должна читать А(мин требованием является блокировка чтения объекта А до завершения операции ТР1).

 

3ий уровень. Отсутствие неповторяющихся чтений. Пример. ТР1 читает объект БД А. ТР2 изменяет объект А до завершения чтения. И заврешается оператором COMMIT, т.е. изменения прошли успешно. ТР1 повторно чтитает А, то видит

До завершения ТР1 никакая др тран-ция не должна изменять оъект А. В большинстве сист это является макс требованиям синхронизации тран-ций. Хотя это это не гарант-ет изолированности поль-ей.

Сущ возможность обеспечения разных уровней цел-ти для разных уровней выпол-ся в одной БД. Для поддерж цел-ти во многих случ достаточен 1ый уровень. Сущ ряд приложений, для которых некор индив данных несущ-на. Но при этом сущ-но сокращ-ся расходы СУБД и общ. К более тонким проблемам изолированности транкции БД относится проблема картежей-фантомов, кот вызывает ситуации.  Это противоречит закону огрнич польз-ля. Поясним. ТР1 выполняет оператор А. Для выборки картежей отношение R с условием выборки S, т.е. выбирается часть картежей отношения R которые удовл условию S. ТР2 вставляет в R новый картеж r,кот также удовл отнош S. Транзакция 1 повтороно выл-ет опер ТР1 и в рез-те получ-ся новый картеж кот ый отсутствовал при выпопении Такая ситуация противоречит    Чтобы избежать появления картежей-фантомов, требуется. Более высокий логический ур-нь синхронизации тран-ций.

 

------------------------------------------------------------------------------------------

 

 

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

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

Сериализация транзакций – это механизм их выполнения по некоторому сериальному плану. 

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

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

Между транзакциями могут возникать следующие виды конфликтов:

                 1.  W-W. Транзакция 2 пытается изменить объект, измененный не закончившейся транзакцией 1.

                 2.R-W Транзакция 2 пытается изменить объект читаемый транзакцией 1.

                 3. W-R.  2 наоборот.

 

Методы сериализации транзакций.

Существует 2 базовых метода сериализации транзакций.

Первый метод основан на синхронизационных захватах объектов БД.

Второй на использовании временных меток.

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

 

Синхронизационные захваты.

Рассмотрим для клиент-серверной архитектуры.

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

                 1. Совместный режим S-Shared ,означающий разделяемый захват объекта и требуемый для выполнения операции чтения объекта.

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

 

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

 

 

В 1 толбце приведены возможные состояния объекта с точки зрения синхронизационных захватов, при этом – соответствует состоянию объекта, для которого не установлен никакой захват. Транзакция, запросившая синхронизационный захват объекта, уже захваченный другой транзакцией в несовместимом режиме, блокируется до тех пор, пока захват с этого объекта не будет снят. В этой таблице слово нет соответствует описанным раннее возможным случаям конфликтов по доступу в объектам БД. Совместимость S захватов соответствует тому, что конфликт R-R не существует. Для обеспечения сериализации транзакций 3 уровня изолированности , синхронизационные захваты объектов, произведенные по инициативе транзакций можно снимать только по ее завершению. Эта ситуация порождает двух фазный протокол синхронизации захватов (2PL). В соответствии с этим протоколом выполнение транзакции разбивается на 2 фазы:

1 фаза – это накопления захвата;

2 фаза – фиксация или откат – это освобождение захвата.

При соблюдении этого протокола действительно обеспечивается сериализацию транзакций на 3 уровне изолированности. 

Основная проблема состоит в том, что следует считать объектом для синхронизационного захвата. Если рассматривать реляционные БД, это могут быть:

                 1. Файл – это физический (в точки зрения БД); Объект – область хранения нескольких отношений и возможно индексов;

                 2.Отношение – это логический объект, который соответствует множеству кортежей данного соответствия.

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

                 4. Кортеж – это элементарный физический объект БД.

 

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

 

Гранулированные синхронизационные захваты.

Совокупность вышеизложенных рассуждений привели к разработке гранулированных синхронизационных захватов. В этой ситуации синхронизационные захваты могут запрашиваться по отношению к объектам разного уровня: файл, отношение, кортеж.  А уровень объекта определяется выполняемой операцией. Объект любого уровня может быть захвачен в режиме S или X.  Соответствие захватов разного уровня держится на важном отличии от раннее рассмотренного. Вводится специальный протокол гранулированных захватов и новые типы захватов: перед захватом объекта в режиме S или Х, он должен быть предварительно захвачен в режиме IX, IS, SIX.  

IS – Intented for Shared lock.

IX – Intented for eXclusive lock.

SIX – Shared, Intented for eXclusive lock.

 

По отношению к некоторому составному объекту О означает намерение захватить некоторый входящий в О объект в совместном режиме. Например, при намерении читать кортежи из отношения r, это отношение должно быть захвачено в режиме IS, а для этого в таком же режиме должен быть захвачен файл IX по отношению к некоторому составному объекту О означает намерение захватить некоторый входящий в О объект в монопольном режиме. Например, при намерении удалять картежи из отношения r, это отношение должно быть захвачено в режиме IX (а для этого в таком же режиме должен быть захвачен файл).