Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Лекция 6
Проблема защиты данных актуальна, т.к при работе пользователей с базами данных могут возникать ситуации, приводящие к потере данных:
Защита:
- восстановление
- параллелизм
- безопасность
1.Восстановление
Восстановление СУБД означает восстановление самой БД, т. е возвращение в исходное (правильное) состояние, если в результате какого-либо сбоя состояние данных стало неверным или подозрительным.
Для того, чтобы данные восстанавливать, надо иметь избыточность (путем резервирования, за счет дополнительных исходных данных), реализуется на физическом уровне, поэтому скрыта от конечного пользователя.
Понятие транзакции:
Для восстановления данных на программном уровне используется механизм транзакций, под которым понимается единица логической работы, то есть выполнения базой данных одного или нескольких подряд операторов обновления данных (операторы вставки, удаления, изменения данных), переводящих базу данных из одного целостного состояния в другое.
Механизм транзакций дает гарантию, что если во время выполнения обновлений произойдет сбой или отказ на программном или физическом уровне, то систему можно будет вернуть в исходное состояние.
Фактически транзакция означает, что группа операторов обновления либо выполняется полностью от начала до конца, либо отменяется полностью, как будто ничего не происходило.
Ключевые операторы:
Commit – подтвердить изменения. Сигнализирует серверу БД (диспетчеру управления транзакциями), что все операторы успешно выполнены и можно подтвердить изменения.
Roll back – отменить назад. Извещает, что произошел сбой и нужно все, что было сделано, отменить.
Среди операторов, которые модно отменять назад, есть операторы, которые внутри транзакции делать нельзя, поскольку сделать их откат назад нельзя: операторы создания новых объектов (таблиц, домена, индекса), процедур, триггеры (все операторы, начинающиеся на create(создать),alter(изменить),drop(удалить)).
Модель транзакции:
В стандарте ANSI\ISO принята модель: транзакция автоматически начинается с выполнения первого оператора обновления от пользователя и продолжается до тех пор, пока не появится Commit или Roll back,которые заканчивают транзакцию.
В некоторых СУБД (SyBase, SQL Server) принята другая модель транзакций: прежде, чем начать транзакцию, надо ввести команду Begin Transaction.Считается, что после этого любой оператор обновления входит в транзакцию. Если есть единичный оператор обновления за рамками команды Begin Transaction,то он считается оператором обновления с авто commit-ом.
Свойства АСИД (ACID):
1.Атомарность (atomicy) – в транзакции выполняются либо все операторы, либо ничего не выполняется - все откатывается назад, БД возвращается в исходное состояние.
2.Согласованность (consistency) – транзакции переводят БД из одного согласованного состояния в другое без обязательной поддержки в промежуточных точках (операторах).
3.Изолированность (isolation) – транзакции отделены друг от друга. Выполнение нескольких конкурирующих транзакций скрыто друг от друга до их окончания.
4.Долговечность (durability) – после выполнения транзакции ее обновление сохраняется даже если после этого произойдет отказ или сбой системы.
Именованные транзакции:
Существует много моделей транзакций: от чисто теоретических до практических, используемых в разных СУБД.
Хроники:
Гарсия-Малина в 1987 году предложил концепцию хроник, которая предполагает наличие компенсирующей транзакции: последовательно выполняются несколько плоских (одноуровневых) транзакций, при необходимости посылается компенсирующая транзакция, которая все отбрасывает назад (устраняет результаты нескольких плоских транзакций). Применяется такой механизм, когда транзакции относительно независимы друг от друга.
Точки сохранения (save points):
Приняты в стандарте и многие СУБД используют их на практике. Во многом похожи на подтранзакцию и предполагают, что внутри транзакции может происходить откат не к началу, а к некоторому промежуточному значению (точке сохранению), которое может отметить разработчик.
Rollback to <имя точки>
Файлы регистрации (журнал транзакций, lock-файлы):
Для того, чтобы иметь возможность отменять транзакцию, СУБД должна поддерживать журнал транзакций и запись в него обновлений. Запись в него обычно происходит до начала транзакции (протокол предварительной записи в журнал). Т.е, как только пользователь посылает команду изменения, СУБД автоматически вводит в журнал транзакций 1 запись для каждой изменяемой строки, которая включает в себя идентификатор транзакции, время начала транзакции, 2 копии строки (до и после изменения). Т.о. гарантируется, что если в момент физической записи данных уже из оперативной памяти по команде commit что-то случится, то копии хранятся в журнале, и можно будет все восстановить. Если в процессе выполнения встретится оператор Rollback,то СУБД автоматически ищет сохраненные данные в журнале и возвращает все назад. В случае системного сбоя администратор БД восстанавливает БД с помощью специальной утилиты восстановления. Она автоматически просматривает журнал транзакций, находит транзакции, которые не были завершены к моменту сбоя и отменяет их.
Отложенные транзакции: проверка всех доменов, ограничений и т.п. происходит не сразу после выполнения оператора, а на момент завершения транзакции. В этом случае протокол предварительной записи в журнал не используется, а данные заносятся в БД после получения команды фиксации.
Работа проще и быстрей, но вызывать отложенную транзакцию тяжело. Необходимо в тех случаях, когда промежуточные данных не отвечают существующим ограничениям, но до завершения транзакции это несоответствие может быть исправлено. Используются только крупными СУБД (ORACLE,SyBase).
На практике в крупных СУБД журнал регистрации часто состоит из 2-х частей: активной (интерактивной) и архивной (автономной). Интерактивная часть используется в процессе работы, она имеет размер, и пока он не заполнится, архивный специальными методами сжимается. Как только текущий журнал заполняется, он переводится в режим архивации, а заполняется уже чистый. Архивный журнал нужен для того, чтобы восстановить журнал при сбое. Размер журналов нужно рассчитывать так, чтобы не получилось, что активный журнал заполняется быстрее, чем архивируется автономный.
Ведение журнала транзакции ведет к увеличению времени заполнения БД в три раза за счет создания копий. Рекомендуется хранить журнал регистрации на отдельном высокоскоростном диске, чтобы заполнялся в параллель с БД.
Рекомендуемый размер журнала транзакций для реляционной БД 10-25% от основной БД, для БД, работающей в режиме большого числа параллельных транзакций и высокой скорости изменения, 70-75% от БД.
Оперативная обработка транзакций (OLTP – On-Line Transaction Processing):
Первоначально реляционные СУБД не использовались для систем с оперативной обработкой транзакций из-за низкого быстродействия, доминировали иерархические СУБД. В 1986 году фирма SyBase первой представила СУБД для OLTP-систем, которая обрабатывала до 250-ти транзакций в секунду), временные СУБД обрабатывают 1000 транзакций в секунду).
Для тестирования производительности СУБД существуют специальные тесты ТРС-А\В\С.
Необходимы для того, чтобы периодически фиксировать состояние системы. Т. е. с некоторым периодом времени система принимает контрольную точку, в этот момент содержимое всех оперативных буферов, т. ч. и выполняемые транзакции, записываются на диск. Если происходит отказ системы, то все транзакции, которые были начаты до или после записи контрольной точки, но успели закончиться до отказа, эти транзакции заново повторяются за счет информации, которая хранится на диске журнала, если они не закончились до отказа, то они автоматически отменяются.
Система (БД) должна быть готова к восстановлению данных не только при локальных, но и при глобальных нарушениях (отказ носителей). В этом случае должна быть периодически сохраняемая администратором копия (резервная копия,dump),которая сохранена на том или ином носителе. Для этих целей нужны специальные утилиты.
При работе с несколькими базами данных, имеющими раздельные журналы транзакций, необходим системный компонент – координатор. Его назначение – гарантировать восстановление данных, если произошло нарушение. Фактически он берет на себя функции принятия решения, фиксировать или отменять транзакцию в системе вообще. Данные могут подтверждаться в каждой БД в разное время и в соответствии со своим журналом транзакций. Координатор принимает положительные отзывы от каждой из баз данных, и если все они получены, производит фиксацию, а если какой-либо отзыв не получен, происходит общий откат глобальной транзакции.
1.5 Зеркальное копирование
Одним из способов обеспечения непрерывной работы базы данных при отказе внешней памяти является использование зеркального копирования. При этом используется максимальная избыточность на случай отказа, т. к фактически параллельно и непрерывно работают 2 базы данных, правда, на разных устройствах. Все изменения автоматически записываются в 2 копии. Если в процессе работы с основной копией что-то произойдет, система переводит управление на другую копию, а первую можно ремонтировать.
Не рекомендуется использовать зеркало на диске с журналом транзакций, поскольку это существенно снижает быстродействие.
Для поддержки зеркального копирования, напр. в SQL Server, есть специальный пользователь, управляющий зеркальным копированием (Mirror Handing User),в списке процессов он имеет имя speed1.
2.Параллелизм
Параллелизм – возможность параллельной обработки в СУБД многих параллельных транзакций к одним и тем же данным в одно и то же время.
СУБД должно осуществлять правильное восстановление данных при отмене транзакций или в случае системного сбоя и гарантировать, что пользователи при параллельной работе с данными мешать друг другу не будут.
Основные проблемы, возникающие при параллельной обработке транзакций:
1.Потеря результатов обновления.
Возникает когда одновременно, но с некоторым сдвигом во времени выполняются 2 транзакции, заключающиеся в чтении данных из одного и того же кортежа с последующим изменением данных в них.
Если 2 транзакции одновременно изменяют и фиксируют изменения одних и тех же данных, то сохраняются результаты той транзакции, которая завершилась последней по времени.
2.Незафиксированные зависимости, или т.н. «грязное чтение» (Dirty Read).
Появляется, если с помощью некой транзакции Т2 осуществляется чтение или изменение некоторого кортежа, только что измененного другой транзакцией Т1,однако изменения еще не были подтверждены. Если данные транзакции Т1 подтверждены не будут, то результаты транзакции Т2 окажутся неверными.
3.Несогласованные данные (неповторяемое чтение Fuzzy Read).
Возникает, когда одна транзакция читает кортеж, а другая изменяет его и фиксирует изменения до окончания первой.
4.Строки-призраки (Phantom).Возникает при работе не с одним кортежем, а при выполнении групповых операции (вычисление среднего, подсчет баланса, т. е. когда обрабатывается несколько строк одновременно). В таких сложных обработках, как правило,некий массив кортежей читается неоднократно. Если между первым и вторым чтениями была удалена или добавлена запись в массив строк, при повторном считывании массива появляется лишняя строка (фантом), что может привести к неверным результатам.
Т.о. СУБД должна гарантировать, что если 2 транзакции выполняются параллельно, то результаты их выполнения должны быть аналогичны тем, которые были бы при их последовательном выполнении, каждый пользователь должен чувствовать себя так, как будто он работает монопольно (концепция сериализации транзакций).
Для решения проблем при параллельной работе используется механизм блокировок: одна или набор записей блокируются на момент выполнения транзакции. Поэтому желательно делать транзакции покороче, чтобы обеспечить равномерную работу пользователей в сети.
На практике используются 2 вида блокировок:
Транзакция, предназначенная для чтения, извлечения записи, должна накладывать s-locks на читаемые записи. Транзакция, предназначенная для изменения данных, должна накладывать х-locks на эти записи. Если этой же транзакцией до этого была наложена s-locks,то эта блокировка поменяется на х-locks.Это приводит к тому, что в первом случае, только при чтении, другие пользователи могут одновременно читать ту же запись, а при изменении данных другим пользователям запрещено видеть неподтвержденные данные, пока они не будут зафиксированы.
Блокировки, как правило, задаются неявно:
запрос на извлечение данных (select) по умолчанию считается запросом с s-locks
любой запрос на обновление (insert, delete, update) по умолчанию х-locks
Некоторые СУБД поддерживают режим сосуществования s-locks,накладываемых разными клиентами на один и тот же ресурс. Т. к. если несколько человек одновременно читают одни и те же данные, то при отказе наложившего s-locks формально получается, что данные уже можно изменять, хотя другие пользователи продолжают чтение.
Для осуществления s-locks и х-locks системе нужны ресурсы (память),которая отводится для установки защиты на те или иные кортежи. Обычно в СУБД возможное число одновременных блокировок – настраиваемая величина. Как только на одну и ту же таблицу набирается некоторое количество блокировок, система переводит ее из режима блокировки записей в режим блокировки всей таблицы. Это позволяет экономить ресурсы.
Для заданного набора транзакций любой порядок их выполнения называется графиком запуска. Если транзакции выполняются друг за другом, последовательно, то такой график запуска – последовательный.
Блокировки нарушают график запуска, что может приводить к разным результатам деятельности нескольких параллельно работающих пользователей. Для того, чтобы не нарушать последовательность транзакций, используют механизм упорядочения транзакций.
Во многих коммерческих СУБД на сегодня существуют и другие методы осуществления параллельной работы кроме блокировок:
2.1 Степень дробления блокировок
Блокировке может подвергаться не только отдельная запись, но и несколько записей вплоть до блокировки всей таблицы. Кроме того, возможна теоретически блокировка на уровне одного поля. На практике блокировка поля не используется из-за ресурсоемкости, а выигрыш во времени невелик. Чаще всего блокировки осуществляются на уровне страниц (1..8 кБ),т.к. в реляционных СУБД извлечение данных также ведется страницами.
Статистика:
На одну блокировку SQL Server тратит 32 байта, число блокировок можно установить от 5000 до 2 млрд.Обычно сервер настраивается таким образом, что при превышении некоторого числа блокировок на отдельные записи таблицы (регулируемо, обычно 200),то SQL Server автоматически переводит ресурс на блокировку всей таблицы.
2.2 Взаимные блокировки
Из-за того, что несколько пользователей могут по очереди подключаться и блокировать несколько записей в рамках одной транзакции, возможно возникновение тупиковых ситуаций: транзакция Т1 обработала одну запись и обратилась ко второй записи, а транзакция Т2 сначала обработала и заблокировала вторую запись и хочет обратиться к первой. Каждая из транзакций должна обратиться к следующей записи для обновления, а запись заблокирована.Транзакции не могут закончиться, что мешает работать и другим пользователям. В этом случае в системе предусмотрены специальные периодически подключающиеся сервисы, которые сканируют оперативную память, ищут взаимные блокировки и жертвуют одной транзакцией в пользу завершения другой. Для этого используются алгоритмы:
Выявление взаимных блокировок осуществляется следующим образом: строится специальный граф ожидания .Каждая транзакция имеет свою вершину в этом графе. В случае возникновения блокировок от одной транзакции к другой проводится ребро, при взаимной блокировке появляется петля. Т. о. специальная программа, составляющая граф ожидания, ищет петли и, действуя по принципу ожидания отмены или отмены ожидания, отменяет одну из транзакций.
2.3 Уровни изоляции
Один из способов вместо блокировок – т.н. уровни изоляции. Термин «уровни изоляции» используется для описания степени вмешательства параллельных транзакций в работу некоторой данной.
Уровней изоляции может быть насколько. В стандарте SQL принято 4,в порядке возрастания приоритета:
2.4 Временные отметки
Метод временных отметок, применяемый для контроля целостности данных, полностью отличается от блокировок. Он не предусматривает какого-либо ожидания конфликтных транзакций, они просто отменяются и запускаются заново.
В его основе лежит понятие временной отметки – уникального идентификатора, включающего помимо прочего момент запуска транзакции с помощью системных часов, который и лежит в основе этой метки.
Если транзакция предпринимает попытку записи или чтения данных, то эта транзакция выполняется тогда, когда обновление было сделано более старой транзакцией. В противном случае она отменяется и перезапускается заново, чтобы ее временная отметка поменялась и те транзакции, которые еще не прошли, успели закончиться.
Базовый протокол упорядочивания транзакций включает следующие пункты:
Модификация этого протокола (правило Томаса, правило игнорирования устаревшей записи):
Если более старая транзакция пытается изменить данные, обновленные более новой, то она отменяется.