23. Рівні ізоляції транзакцій.

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

Проблема пропавшего обновления.

1-ый пользователь:

SELECT A.AA /* A.AA=100*/

FROM A UPDATE A SET A.AA=50

2-ой пользователь:

SELECT A.AA /*A.AA=50*/

FROM A UPDATE A SET A.AA=20

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

Проблема несогласованных данных. Обычно

1-ый пользователь - чтение;

2-ой пользователь - обновление;

1-ый пользователь - чтение.

Проблема "строки - признаки" возникает, когда между 2-мя запросами выполняются операторы INSERT и DELETE     Основной подход для согласованных действий заключается в следующем. Пользователь не должен видеть промежуточные результаты транзакций другого пользователя. Это значит, что две транзакции А и В должны давать один и тот же результат независимо от их последовательности. Это называется сериализация транзакций. Каждый пользователь работает так, как будто других пользователей нет. В связи с этим транзакции должны быть короткими. Если программа прочитала строку, то ни один пользователь, кроме этой программы не может внести изменения до окончания транзакции. Происходит захват данных или блокировка. В SQL сервере блокировка запрещает читать данные, которые изменяются другим пользователем. При этом за один раз разрешается изменять не более одной записи. Различают три вида блокировки: мягкая; раздельная; монопольная.  

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

Монопольная блокировка выполняется при действии команд INSERT, DELETE и UPDATE.

В SQL сервере существуют следующие уровни блокировки:

Rip - блокировка строки. Используется редко для вставки данных.

Key - блокировка индекса для защиты диапазона.

Page - блокировка страницы (8кБ). Основной вид блокировки. Используется по умолчанию.

Extent - блокировка группы (8 страниц).

Table - блокировка таблицы.

Db - блокировка БД.

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

Уровень 0 - разрешается двум процессам изменять одни и те же данные.

24.Збережені процедури в tsql.

Хранимые процедуры - это откомпилированная SQL - конструкция, которая хранится и выполняется на сервере. Процедуры могут или выбирать (читать) данные или модифицировать данные, но не одновременно (в рамках одной процедуры).

Создание хранимой процедуры: CREATE PROCEDURE [<владелец>.]<имя_процедуры>[;<номер_процедуры>] (<Параметр1>,<Параметр2>, ... <Параметр255>) [FOR REPLICATION | WITH RECOPILE | WITH ENCRYPTION] AS <команда> <Параметр>=@<имя_параметра><тип>[OUTPUT][=<значение по умолчанию>][VARYING]

WITH ENCRYPTION - при записи в системную таблицу происходит шифрование процедур.

    Каждая процедура компилируется при первом запуске. При этом план процедуры может записываться в кэш, а может не записываться в кэш, т.е. создается каждый раз. WITH RECOMPILE - позволяет перекомпилировать процедуру при каждом обращении. FOR REPLICATION - означает, что это процедура репликации (обновление данных на всех связанных серверах). AS - начало тела процедуры. Запуск процедуры: EXEC <имя_процедуры> Удаление процедуры: DROP PROCEDURE <имя_процедуры> Хранимые процедуры могут возвращать и передавать значения, не обязательно связанные с данными в базовой таблице.  Преимущества хранимых процедур перед процедурами приложения:

1. Высокая производительность, т.к. они выполняются на сервере.

2. Раздельное создание программного обеспечения клиента и сервера.

3. Высший уровень безопасности.

4. Применяются общие правила управления данными на сервере.

5. При компиляции хранимые процедуры оптимизируются.

6. Хранимые процедуры могут запускаться из приложения, что разгружает приложение.

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

Процедуры всегда перекомпилируются при:

1. Загрузке SQL - сервера.

2. При удалении индекса.

3. При обращении нескольких пользователей к одной и той же процедуре.

4. При удалении и создании процедуры

Уровень 1 - запрещается чтение во время модификации данных ("грязное" чтение).

Уровень 2 - запрещается неповторяемое чтение, т.е. в промежутках между чтением в процессе одной транзакции запрещается изменение данных другой транзакцией.

Уровень 3 - запрет фантомов вставки и удаления.

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

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

Управление распределенными транзакциями. Существует два аспекта управления транзакцией:

1. управление восстановления. 2.параллелизмом (поскольку выполняются разные части транзакций на разных компьютерах.)

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

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

Независимость от аппаратного обеспечения. Опр-ся все серверные СУБД, которые работают на различных платформах.

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

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

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

правило 6: Возможность модификации представлений (View Updating Rule): Каждое представление должно поддерживать все операции манипулирования данными, которые поддерживают реляционные таблицы: операции выборки, вставки, модификации и удаления данных.

правило 7: Наличие высокоуровневых операций управления данными (High-Level Insert, Update, and Delete): Операции вставки, модификации и удаления данных должны поддерживаться не только по отношению к одной строке реляционной таблицы, но по отношению к любому множеству строк.

правило 8: Физическая независимость данных (Physical Data Independence): Приложения не должны зависеть от используемых способов хранения данных на носителях, от аппаратного обеспечения компьютеров, на которых находится реляционная база данных.

правило 9: Логическая независимость данных (Logical Data Independence): Представление данных в приложении не должно зависеть от структуры реляционных таблиц. Если в процессе нормализации одна реляционная таблица разделяется на две, представление должно обеспечить объединение этих данных, чтобы изменение структуры реляционных таблиц не сказывалось на работе приложений.

правило 10: Независимость контроля целостности (Integrity Independence): Вся информация, необходимая для поддержания целостности, должна находиться в словаре данных. Язык для работы с данными должен выполнять проверку входных данных и автоматически поддерживать целостность данных.

правило 11: Дистрибутивная независимость (Distribution Independence): База данных может быть распределённой, может находиться на нескольких компьютерах, и это не должно оказывать влияние на приложения. Перенос базы данных на другой компьютер не должен оказывать влияния на приложения.

правило 12: Согласование языковых уровней (The Nonsubversion Rule): Если используется низкоуровневый язык доступа к данным, он не должен игнорировать правила безопасности и правила целостности, которые поддерживаются языком более высокого уровня.