Разделы презентаций
- Разное
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Геометрия
- Детские презентации
- Информатика
- История
- Литература
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
Транзакции и параллелизм
Содержание
- 1. Транзакции и параллелизм
- 2. Транзакция (transection) – это группа операторов SQL,
- 3. Фиксация вносимых измененийСреду базы данных легко представить
- 4. Фиксация вносимых измененийОператор SQL, влияющий на обновления
- 5. Транзакция – это последовательность операторов SQL, которая
- 6. Чтобы сделать постоянными все изменения с момента
- 7. Во многих реализациях предусмотрен специальный параметр AUTOCOMMIT
- 8. При аварийном завершении сеанса пользователя – например,
- 9. Транзакции, которые включают целую группу несвязанных операторов
- 10. Предположим, что нам нужно удалить из базы
- 11. UPDATE Orders SET snum = NULL
- 12. Следовательно, приведенную группу операторов можно рассматривать как
- 13. SQL и многопользовательский режим работыОбычно SQL используется
- 14. Предположим, что вы применяете к таблице продавцы
- 15. Будут ли отражать средние значения, полученные последним
- 16. Допустим, что вы нашли ошибку и выполняете
- 17. Типовые проблемы параллелизма Одновременная обработка транзакций называется
- 18. Изменения в БД могут отменяться уже после
- 19. Например:Аудитор должен иметь возможность вернуться назад и
- 20. Пример:Два пользователя одновременно пытаются изменить значения внешнего ключа и значение его родительского ключа.
- 21. Стандартные термины для проблем параллелизма Потерянное обновление
- 22. Потерянное обновление
- 23. По завершению этой последовательности операторов значение comm
- 24. Преждевременное чтение
- 25. Запрос к транзакции №2 выводит значение, которое
- 26. Неповторяющиеся чтение
- 27. В транзакции №2 были получены два разных
- 28. Фантомная вставка
- 29. Поскольку в середине транзакции №2 выполняется оператор
- 30. Решение проблем параллелизмаSQL обеспечивает управление параллелизмом CUNCURRENCY
- 31. В любой момент времени лишь одна транзакция
- 32. Все блокировки делятся на две общие категории:Пессимистические
- 33. Использование пессимистического блокированияПри пессимистическом блокировании некоторые типы
- 34. Уровни изоляцииДля поддержки блокировок определены уровни изоляции
- 35. Слайд 35
- 36. Уровень SERIALIZABLE (последовательное выполнение), устанавливается по умолчанию
- 37. Уровень REPEATABLE READ (повторяющееся чтение) допускает из
- 38. Уровень READ COMMITED (чтение с фиксацией) допускает
- 39. Уровень READ UNCOMMITED (чтение без фиксаций) допускает
- 40. Разделяемы и исключительные блокировкиДля обеспечения всех уровней
- 41. Исключительные блокировки (EXCLUSIVE LOCKS) или Х-блокировки (X-LOCKS),
- 42. Транзакции READ ONLY и READ WRIGHTНа всех
- 43. Ее противоположностью является транзакция READ WRIGHT, которая
- 44. Установка параметров транзакцииВ SQL 92 был введет
- 45. ЭТОТ оператор перекрывает параметры по умолчанию для
- 46. Грануляция блокировокКакие данные могут быть заблокированы?Вся строка,
- 47. Грануляция блокировки, часто определяется либо в логических,
- 48. Если встречается схема блокирования с такими объектами,
- 49. Наиболее распространённые возможностиБлокирование на уровне таблицы (table
- 50. Блокирование на уровне страницы (page level locking)
- 51. Блокирование на уровне элемента (item level locking)
- 52. Использование оптимистического блокированияТермин оптимистического блокирования активно используется
- 53. Можно применять уровни изоляции, определенные ранее, а
- 54. Кроме того, отмечается любое чтение данных, а
- 55. В таблице предоставлен вариант примера с потерянным
- 56. Слайд 56
- 57. Какой способ лучше? Как часто могут возникать
- 58. Выбирая тип блокирования необходимо выяснить: Какого ожидаемое
- 59. Насколько длинными и сложными будут транзакции? Чем
- 60. СПАСИБО ЗА ВНИМАНИЕ!
- 61. Скачать презентанцию
Транзакция (transection) – это группа операторов SQL, выполняемых, как единое целое.Параллелизм (concurrency) относится к механизмам, с помощью которых СУБД предотвращает взаимное влияние операций, одновременно выполняемых над одними и теми же данными
Слайды и текст этой презентации
Слайд 2Транзакция (transection) – это группа операторов SQL, выполняемых, как единое
целое.
взаимное влияние операций, одновременно выполняемых над одними и теми же данными равными пользователями.
Слайд 3Фиксация вносимых изменений
Среду базы данных легко представить в виде множества
пользователей, постоянно вводящих и изменяющих информацию. При этом система будет
функционировать без сбоя.В реалии постоянно возникают ошибки, причиной которых являет как человек, так и компьютер.
В случае ошибки необходимо дать возможность отменить выполнение операции.
Слайд 4Фиксация вносимых изменений
Оператор SQL, влияющий на обновления (например на оператор
обновления или на DROP TABLE), необязательно является необратимым.
После выполнения оператора
(или группы операторов) принимается решение станут ли произведенные изменения постоянными или будут прогнозируемыми;С этой целью операторы объединяются в группы, называемые транзакциями.
Слайд 5Транзакция – это последовательность операторов SQL, которая принимается или отменяется,
как единое целое.
Инициируя сеанс работы в SQL, начинается транзакция;
Все вводимые
операторы будут входить в одну и ту же транзакцию, если не вводится оператор Commit Work или Rollback Work.Commit – делает все изменения, выполненные в ходе транзакции постоянными.
Rollback –отменяет их.
После каждого оператора Commit и Rollback начинается транзакция.
Слайд 6Чтобы сделать постоянными все изменения с момента входа или последнего
изменения Commit и Rollback, используется следующий синтаксис:
COMMIT WORK;
Синтаксис для отмены
изменений выглядит так:ROLLBACK WORK;
Слайд 7Во многих реализациях предусмотрен специальный параметр AUTOCOMMIT или SET AUTOCOMMIT
ON
Что бы вернутся к обычной обработки транзакций нужно ввести:
SET AUTOCOMMIT
OFFСистема может автоматически включать AUTOCOMMIT при входе.
Слайд 8При аварийном завершении сеанса пользователя – например, когда система дает
сбой или пользователь перезагружает компьютер – астматически выполняется откат текущей
транзакции.Это одна из причин по которым стоит делить операторы, вводимые в ручную, на множество отдельных транзакций.
Транзакция не должна содержать много несвязанных операторов, она часто состоит из единственного оператора.
Слайд 9Транзакции, которые включают целую группу несвязанных операторов позволяют только сохранить
или отменить всю группу.
Как группу, тогда как отмена обычно нужна
только для одного конкретного изменения.Транзакция должна состоять из одного или нескольких связанных операторов.
Слайд 10Предположим, что нам нужно удалить из базы данных продавца по
имени Иванов. Прежде чем удалить ее саму оператором DELETE из
таблицы ПРОДАВЦЫ, необходимо что-то сделать с его заказами и покупателями.Логично установить ID Продавца для этих заказов в NULL, чтобы никто из продавцов не получал по ним комиссионные, а покупателей передать продавцу Петрову.
После этого вы можете удалить его из таблицы Продавцы.
Слайд 11UPDATE Orders
SET snum = NULL
WHERE snum
= 1004;
UPDATE Customers
SET snum
WHERE snum =
1004;DELETE FROM Salespeople
WHERE snum = 1004;
Слайд 12Следовательно, приведенную группу операторов можно рассматривать как одну транзакцию.
Можно предварить
эту группу операторов COMMIT или завершить оператором COMMIT или ROLLBACK
Слайд 13SQL и многопользовательский режим работы
Обычно SQL используется в многопользовательской среде,
где в одно и то же время операции над БД
могут выполнять несколько пользователей.Это создает предпосылки для конфликтов между разными операциями.
Слайд 14Предположим, что вы применяете к таблице продавцы следующий оператор:
UPDATE
Salespeople
SET comm = comm * 2
WHERE sname
LIKE ‘R%’:Во время время его выполнения вводится следующий запрос:
SELECT city, AVG (comm)
FROM Salespeople
GROUP BY city;
Слайд 15Будут ли отражать средние значения, полученные последним пользователем, те изменения,
которые вносились в таблицу ранее?
Это может не иметь большого значения,
здесь важно чтобы результаты запроса отражали либо все изменения, либо никаких. Любой промежуточный результат будет случайным образом завесить от того порядка, в котором производятся физические изменения данных.
Результаты запросов не должны завесить от физических деталей и не могут быть случайными и непредсказуемыми.
Слайд 16Допустим, что вы нашли ошибку и выполняете откат изменений после
того как последний пользователь получил свои результаты.
Теперь его средние значения
основаны, на изменениях, которые утратили силу, но он не может об это узнать.
Слайд 17Типовые проблемы параллелизма
Одновременная обработка транзакций называется параллелизмом (concurrency) и
здесь могут возникать следующий проблемы.
Обновления могут выполнятся независимо друг от
друга. Например, продавец выполняет запрос к инвентарной таблице, находит на складе 10 единиц товара и заказывает для покупателя 6 из них.
До того, как это изменение будет сделано, другой продавец просматривает таблицу и заказывает 7 того же товара для своего покупателя.
Слайд 18Изменения в БД могут отменяться уже после их использования, как
в приведенном выше примере, когда вы отменили ошибочный ввод после
получения пользователем его результатов.Частичный результат одной операции может влиять на результат другой операции, в том же примере пользователь получил средние значения пока вы производили обновления.
Это не всегда представляет проблему, но во многих случаях функции, на подобие агрегатных, должны отражать состояние базы данных в момент относительной стабильности.
Слайд 19Например:
Аудитор должен иметь возможность вернуться назад и опередить, что средние
значения существовали в некоторый момент и могла оставаться неизменными, если
бы после этого не вносилось никаких изменений.Это невозможно если во время вычисления функции выполнялось обновление.
Когда два пользователя пытаются выполнить мешающие друг другу действия, возможно тупиковая ситуация.
Слайд 20Пример:
Два пользователя одновременно пытаются изменить значения внешнего ключа и значение
его родительского ключа.
Слайд 21Стандартные термины для проблем параллелизма
Потерянное обновление (LOST UPDATE)
Преждевременное чтение
(DIRTY READ)
Неповторяющееся чтение (NON-REPETEABLE READ)
Фантомная вставка (PHANTOM INSERT)
Они объясняются в
следующих таблицах 
Слайд 23По завершению этой последовательности операторов значение comm = . 14
Обновление
до . 10 не имело результата.
Это не обязательно является
ли это проблемой, например установка для comm значения . 14 на следующей неделе дала бы тот же самых эффект перекрытия.Однако при изменении данных часто учитывается их предыдущее значение.
Пользователь, выполнявший Транзакцию №2 был введет в заблуждение: он думал, что текущие comm = . 12, тогда как они были = . 10
Если бы он намеревался увеличить комиссионные на . 02, то результат был бы ошибочным.
Если выполнить увеличение непосредственно, использую в операторе UPDATE предложение SET comm = comm + 0.02, то ошибки можно избежать, но это не всегда легко сделать при сложных вычислениях.
Слайд 25Запрос к транзакции №2 выводит значение, которое уже исчезло из
БД.
Отмена транзакции №1 эквивалентна тому, что значение comm никогда
не = . 10, но именно это значение было показано в транзакции №2. 
Слайд 27В транзакции №2 были получены два разных ответа на один
вопрос, данные действительно изменились, но иногда необходимо гарантировать, что данные
останутся постоянными до завершения транзакцииЭто особенно важно для приложений, которые выполняют чтение данных из обротку и сохранение новых значений тем или иным образом связанных со старыми.
В токам случае подобная ситуация представляет проблему.
Слайд 29Поскольку в середине транзакции №2 выполняется оператор ISERT из транзакции
№1 результаты одинаковых запросов будут отличатся.
Здесь показан особый случай неповторяющегося
чтения.Если вклинивающемся операторам, является INSERT, a не UPDATE или DELETE, то новая строка не может быть одной из тех, что выведены предыдущим запросом.
Эта новая фантомная строка не существовавшая раньше.
На практике различие между фантомными вставками и другими случаями неповторяющегося чтения заключается в том, что фантомные вставки дают более ограниченный эффект.
Слайд 30Решение проблем параллелизма
SQL обеспечивает управление параллелизмом CUNCURRENCY CONTROL
В первоначальном стандарте
SQL говорилось, что одновременное выполнение операторов должно быть организованно так,
что бы это было эквивалентно ситуации, когда не один из операторов не вводится о полного завершения предыдущего (включая COMMIT и ROLLBACK)Это правило является идеалом с точки зрения целостности данных, но на практике, часто требуется обеспечить более оперативный доступ к информации.
Слайд 31В любой момент времени лишь одна транзакция будет иметь возможность
изменять данные (хотя их чтение возможно для нескольких транзакций)
Механизмы, которые
SQL использует для управления параллельными операциями, называются блокировками (LOCKS) Блокировки приостанавливают определенные операции над БД на то время, пока активны другие операции или транзакции.
Слайд 32Все блокировки делятся на две общие категории:
Пессимистические блокировки (pessimistic locks)
Прекращают
доступ к данным для одновременных транзакций
Оптимистические блокировки (optimistic locks)
Отслеживают возникновение
конфликтов и при необходимости выполняют откат транзакции Оптимистическое блокирование более подходит, если ожидаемая частота конфликта не велика. При таком блокировании операции могут выполняться с меньшими задержками, поскольку доступ к данным не ограничен.
Но при возникновении их конфликта все результаты работы пропадают, поэтому при высокой частоте конфликтов будет трудно доводить транзакции до конца.
Слайд 33Использование пессимистического блокирования
При пессимистическом блокировании некоторые типы одновременного доступа к
данным запрещены.
Первая операция, которая может привести к конфликту, блокирует некоторые
или все данные, которые использует, последующие конфликтные операции либо отменяются, либо ставятся в очередь до того момента, когда станет возможно их повторное выполнение.Используется конфигурационный параметр NO WAIT
Слайд 34Уровни изоляции
Для поддержки блокировок определены уровни изоляции (ISOLATION LEVELS), определяющие
какие типы конфликтов допустимы.
В таблице перечислены различные уровни изоляции
и операции разрешенные на каждом уровне. 
Слайд 36Уровень SERIALIZABLE (последовательное выполнение), устанавливается по умолчанию и обеспечивает максимальную
степень контроля.
В последовательном режиме каждая транзакция выполняется изолированно, не влияя
на выполнение других параллельных транзакций.Эта ситуация идеальна с точки зрения целостности данных, но не является лучшей с точки зрения производительности.
Слайд 37Уровень REPEATABLE READ (повторяющееся чтение) допускает из всех возможных видов
неповторяющегося чтения только фантомные вставки.
Этот уровень изоляции полезен на транзакции,
на которые не влияет возможная вставка данных.Если добавление в таблицу новой строки не меняет результатов запросов данной транзакции.
REPEATABLE READ окажется предпочтительнее SERIALIZABLE, поскольку допускает оператор INSERT.
Слайд 38Уровень READ COMMITED (чтение с фиксацией) допускает неоднократное выполнение одного
и того же запроса с разными результатами, но только при
условии, что результаты параллельных транзакций были зафиксированы.
Слайд 39Уровень READ UNCOMMITED (чтение без фиксаций) допускает не однократное выполнение
одного и того же запроса с разными результатами независимо от
того, были ли результаты параллельных транзакций зафиксированы.
Слайд 40Разделяемы и исключительные блокировки
Для обеспечения всех уровней изоляции используются блокировки
двух логических типов: разделяемые и исключительные
Разделяемы блокировки (SHARED LOCKS) или
S-блокировки (S-LOCKS) могут одновременно устанавливаться многими пользователями. Это позволяет любому количеству пользователей иметь доступ к данным, но не изменять их.Например, вы можете использовать разделяемые блокировки для повторного чтения.
Слайд 41Исключительные блокировки (EXCLUSIVE LOCKS) или Х-блокировки (X-LOCKS), позволяют иметь доступ
к данным только владельцу блокировки.
Исключительные блокировки используются для операторов изменяющих
содержимое или структуру таблицы и позволяют исключить потерянные изменения.Можно одновременно устанавливать данные блокировки обоих типов.
Слайд 42Транзакции READ ONLY и READ WRIGHT
На всех уровнях изоляции потерянные
изменения не допускаются, это означает, что при наличие внутри транзакции
запроса параллельным транзакциям запрещается обновлять или удалять любые данные, выбранные этим запросом до полного завершения транзакции (фиксации или отката).Как правило именно это и нужно при возможном изменении данных, но если известно, что изменение производится не будут, можно объявить транзакцию как READ ONLY.
Слайд 43Ее противоположностью является транзакция READ WRIGHT, которая может выполнять, как
запросы, так и изменения данных.
Транзакция READ ONLY не устанавливает никаких
блокировок на данные, но и не может их обновлять.По умолчанию транзакции READ UNCOMMITED имеет тип READ ONLY, а остальные тип READ WRIGHT
Таким образом, общей установкой по умолчанию для транзакций является READ WRIGHT SERIALIZABLE.
Слайд 44Установка параметров транзакции
В SQL 92 был введет оператор SET TRANSACTION.
Поддержка этого оператора не требуется на начальном уровне соответствия SQL
92.Пример:
SET TRANSACTION
ISOLATION LEVEL REPEATABLE READ
READ WRIGHT
Слайд 45ЭТОТ оператор перекрывает параметры по умолчанию для последовательной транзакции, но
оставляет открытым вопрос об их определении, основной установкой по умолчанию
является SERIALIZABLE READ WRIGHT.В некоторых системах администратор может их изменять. Определённые таким образом параметры могут применятся к отдельной схеме или даже к целой области физического накопителя.
Стандарт SQL 92 не поддерживает оптимистичное блокирование. Если оно реализовано в СУБД придется использовать нестандартный синтаксис хотя такой синтаксис может быть включен в оператор SET TRASACTION.
Слайд 46Грануляция блокировок
Какие данные могут быть заблокированы?
Вся строка, вся таблица, отдельное
значение столбца.
Это определяется грануляцией (granularity) блокировки, называемой также уровнем блокирования
(locking level).
Слайд 47Грануляция блокировки, часто определяется либо в логических, либо в физических
терминах (либо в терминах логических объектов базы данных, например таблицы
и строки, либо в терминах объектов, связанных с физической организацией данных на диске или на другом носителе).Во втором случае, уровень блокирования может зависеть не только от самой СУБД, но и от операционной системы, а также от архитектуры компьютера.
Слайд 48Если встречается схема блокирования с такими объектами, как dbspace, tablespace
или page, то речь идет о параметрах устройства хранения данных.
Слайд 49Наиболее распространённые возможности
Блокирование на уровне таблицы (table level locking) означает,
что блокируется вся таблица. Такие блокировки быстро устанавливаются и снимаются,
но в максимальной ограничивают доступ данных.Блокирование на уровне пространства таблицы или базы данных (tablespace или dbspace level locking) означает, блокирование физической области накопителя, в которой может размещаться как часть таблицы, так и несколько таблиц (минимизировать конфликт блокировок)
Слайд 50Блокирование на уровне страницы (page level locking) также связанно с
параметрами накопителя. Страница - это единица хранения данных, имеющая определенный
настраиваемый размер. Между страницами и логическими блоками данных необязательно должно быть взаимно-однозначное соответствие. Блокировка страниц очень эффективна с точки зрения производительности и может быть рекомендована если администратор настраивал страницы е ее учетом.
Слайд 51Блокирование на уровне элемента (item level locking) означает, что блокировка
применяется только к одному значению, столбцу или строке. Этот вариант
идеален с точки зрения параллельности, однако работает довольно медленно, поэтому не широко реализован. В SQL 99 определены большие сложные элементы данных (так называемые LOB), и для них блокирование на уровне элемента может иметь смысл.
Слайд 52Использование оптимистического блокирования
Термин оптимистического блокирования активно используется в индустрии баз
данных, но точнее было бы говорить об оптимистическим управлении параллелизмом.
Оптимистическое блокирование не препятствует выполнению каких-либо операций, отменяя лишь те из них, которые привели к конфликтам.
Поскольку эта возможность SQL не является стандартной, ее поддержка в конкретной СУБД может иметь свою специфику.
Слайд 53Можно применять уровни изоляции, определенные ранее, а также определять, какие
конфликты требуют отката. Оптимистическое блокирование использует механизм называемый отметкой времени
(timestamp).Когда транзакция затрагивает элемент данных СУБД делает запись об этом событии и отмечает точное время когда оно произошло.
Слайд 54Кроме того, отмечается любое чтение данных, а также окончание каждой
транзакции (фиксация или откат).
При любом изменении СУБД пытается проверить с
помощью отметок времени, согласуется ли оно с предыдущими. Если эта проверка дала отрицательный результат, СУБД проверяет, не вызвала ли транзакция конфликтов нарушающих заданный уровень изоляции.
Если такое нарушение имеет место, СУБД выполняет откат транзакции.
Слайд 55В таблице предоставлен вариант примера с потерянным обновлением. Потеря обновления
возможна и здесь. Схема оптимистического блокирования разрешает все операции, но
когда транзакция Т2 пытается выполнить обновления, СУБД отмечает, что с момента последнего чтения данные изменились.Следовательно, транзакция Т2 будет отменена. СУБД проигнорирует введенный оператор COMMIT WORK, выдав сообщение об ошибке.
Слайд 57Какой способ лучше? Как часто могут возникать конфликты?
Если частота конфликтов
велика, оптимистическое блокирование приведет к отмене многих транзакций в противном
случае оно может повысить общую производительность.
Слайд 58Выбирая тип блокирования необходимо выяснить:
Какого ожидаемое соотношение запросов и
обновлений? Если пользователи в основном считывают данные, то конфликты будут
возникать редко так как параллелизм не является проблемой, пока данные не начинают изменяться.Пример: таблица с информацией о сотрудниках, зарплата, продолжительность отпуска и т.д. Такая БД может стать кандидатом для оптимистического блокирования.
Слайд 59Насколько длинными и сложными будут транзакции? Чем больше операторов содержит
транзакция, тем сложнее выполнить ее откат, если клиент проведет через
множество WEB страниц, а потом транзакция должна быть отменена, то это не очень удобно. Многое зависит от того, как разработано Internet приложение, а также от возможностей сервера и промежуточных программ, то есть необходимо учитывать подобные аспекты при выборе схемы параллелизма.
