отчет. Учебная практика 4ИП. Практическая работа 1 2 Построение er модели. 2 Практическая работа 2. 10 Выборка с использованием условий отбора. 10
 Скачать 1.35 Mb.
|
Практическая работа №11.Управление транзакциями.Цель работы: Изучение механизма работы транзакций в MySQL. Теоретические сведения Изменения БД часто требуют выполнения нескольких запросов, например при покупке в электронном магазине требуется добавить запись в таблицу заказов и уменьшить число товарных позиций на складе. В промышленных БД одно событие может затрагивать большее число таблиц и требовать многочисленных запросов. Если на этапе выполнения одного из запросов происходит сбой, это может нарушить целостность БД (товар может быть продан, а число товарных позиций на складе не обновлено). Чтобы сохранить целостность БД, все изменения должны выполняться как единое целое. Либо все изменения успешно выполняются, либо, в случае сбоя, БД принимает состояние, которое было до начала изменений. Это обеспечивается средствами обработки транзакций. Транзакция – последовательность операторов SQL, выполняющихся как единая операция, которая не прерывается другими клиентами. Пока происходит работа с записями таблицы (обновление или удаление), никто другой не может получить доступ к этим записям, т. к. MySQL автоматически блокирует доступ к ним. Таблицы ISAM, MyISAM и HEAP не поддерживают транзакции. В настоящий момент их поддержка осуществляется только в таблицах BDB и InnoDB. Транзакции позволяют объединять операторы в группу и гарантировать, что все операторы группы будут выполнены успешно. Если часть транзакции выполняется со сбоем, результаты выполнения всех операторов транзакции до места сбоя отменяются, приводя БД к виду, в котором она была до выполнения транзакции. По умолчанию MySQL работает в режиме автоматического завершения транзакций, т. е. как только выполняется оператор обновления данных, который модифицирует таблицу, изменения тут же сохраняются на диске. Чтобы объединить операторы в транзакцию, следует отключить этот режим: setAUTOCOMMIT=0; После отключения режима для завершения транзакции необходимо ввести оператор COMMIT, для отката – ROLLBACK. Включить режим автоматического завершения транзакций для отдельной последовательности операторов можно оператором START TRANSACTION. Для таблиц InnoDB есть операторы savepoint и rollback to savepoint, которые позволяют работать с именованными точками начала транзакции.    Оператор savepoint устанавливает именованную точку начала транзакции с именем point1. Оператор rollback to savepoint point1 откатывает транзакцию к состоянию, в котором находилась БД на момент установки именованной точки. Все точки сохранения транзакций удаляются, если выполняются операторы commit или rollback без указания имени точки сохранения. Практическая работа При выполнении лабораторной работы необходимо: создать транзакцию, произвести ее откат и фиксацию; составить отчет по лабораторной работе. Пример выполнения работы Для выполнения задания объединим несколько операций по добавлению в таблицу catalogs новых каталогов, а затем произведем откат транзакции, т. е. отмену произведенных действий. Отключаем режим автоматического завершения, добавляем новые записи и проверяем, добавились записи или нет.  Откатываем транзакцию оператором ROLLBACK (изменения не сохранились).  Воспроизведем транзакцию и сохраним действия оператором COMMIT.   Изолированность транзакций Таблицы InnoDB предлагают четыре различных уровня изолированности транзакций. В порядке от самого сильного к слабому, уровни изолированности могут быть следующими: упорядочение (serializabie); повторяемое чтение (repeatable read); чтение подтвержденного (read committed); чтение неподтвержденного (read uncommitted). Как и для многих других опций, здесь тоже приходится выбирать мёжду устойчивостью и производительностью. Упорядочение (serializabie) — это идеал с точки зрения чистоты и устойчивости. С упорядочением чтение и запись в базе данных должны казаться выполняющимися по очереди, когда записываемые изменения вносятся полностью до начала последующего чтения. При этом транзакции не всегда будут выполняться в неперемежающейся последовательности — многие транзакции не мешают одна другой, но в случае коллизии будут мешать. Блокировка и ожидание вместе с непроизводительными усилиями на предсказание возможных коллизий превращают упорядочение в самый медленный режим изолированности. Если вы захотите использовать этот режим, воспользуйтесь следующей командой: set transaction isolation level serializable; Для InnoDB уровнем изолированности по умолчанию является повторяемое чтение (repeatable read). В этом режиме изолированности каждая транзакция работает в изолированной версии таблицы, где каждая строка остается в том виде, в котором она находилась перед началом транзакции. При чтении любой строки гарантируется повторяемость результата. Если вызвать select * from account where number=l; в начале транзакции и выполнять тот же запрос в рамках транзакции позже, вы получите один и тот же результат. Тем не менее существует опасность так называемого фантомного чтения. Возможно, что другая транзакция, которая была только что зафиксирована, добавила в таблицу новые строки. Если выполнить один и тот же запрос с некоторым условием дважды, например select * from account where balance>1000; то вполне возможно, что во второй раз вы получите новые строки — фантомные. На практике фантомное чтение в MySQL должно наблюдаться исключительно редко. Для решения этой проблемы механизм InnoDB использует алгоритм, называемый блокировкой следующего ключа, но столбец, который используется в соответствующем условии, должен быть индексирован. Вы, вероятно, уже знаете, что InnoDB предлагает блокировку на уровне строк. Когда транзакция использует строку, она блокирует ее, чтобы транзакция могла изолироваться от других. Вместе с такой блокировкой строк блокировка следующего ключа заблокирует и пустоты между строками, найденные в индексе. В результате такого подхода к разрешению проблемы фантомного чтения лишь небольшому числу систем действительно может понадобиться режим упорядочения для изолированности. set transaction isolation level repeatable read; Если установить для сервера режим чтение подтвержденного (read committed), транзакции уже не будут слишком изолированными. Если выполнить запрос и повторить его позже в рамках той же транзакции, во второй раз вы получите другой результат, если за это время другая транзакция изменит данные и будет зафиксирована. Если вам потребуется установить этот режим, соответствующая команда должна выглядеть так: set transaction isolation level read committed; На самом слабом уровне изолированности, в режиме чтения неподтвержденного (read uncommitted), очевидно уже не только то, что транзакции больше не изолированы, не обеспечивают целостность и, таким образом, соответствие ACID, но и то, что транзакций по сути вообще иметь невозможно. В этом режиме транзакции могут читать изменения, которые вносят другие транзакции, до того, как эти изменения будут подтверждены (т.е. зафиксированы). Это называют "грязным " чтением. Вы можете допустить это только при исключительно необычных условиях, например, когда вы знаете, что все активные потоки будут либо только читать, либо только записывать данные, но не то и другое одновременно. Чтобы установить режим чтения неподтвержденного, используйте следующую команду: set transaction isolation level read uncommitted;  Задание для самостоятельного выполнения. Исследовать по приведенному алгоритму механизм транзакций в СУБД MySQL. Требования к оформлению отчета Титульный лист. Название работы. Тему, цель и задание к работе. Снимки экрана (скриншоты) процесса разработки. Выводы (что узнали, где можно применить полученные знания). |