- •«Резервное копирование и восстановление баз данных в рсубд sql server»
- •230104, 230201 И направления 230200
- •1 Общие методические указания по выполнению лабораторной работы
- •2 Теоретический материал для домашнего изучения
- •2.1 Резервное копирование. Восстановление. Воспроизведение.
- •2.2 Методы резервного копирования
- •2.3 Выполнение резервного копирования
- •2.4 Управление резервным копированием
- •2.5 Методы восстановления
- •3 Домашнее задание
- •4 Методические указания по выполнению лабораторной работы
- •5 Контрольные вопросы
- •6 Варианты заданий
- •7 Список литературы
- •Методические указания
- •394026 Воронеж, Московский просп., 14
2 Теоретический материал для домашнего изучения
2.1 Резервное копирование. Восстановление. Воспроизведение.
Резервное копирование базы данных является одной из наиболее важных задач поддержки её работоспособности. Имея файлы резервной копии, и тщательно планируя восстановление после аварии, можно восстанавливать систему в случае отказа. Простой системы может доставить неудобства и принести большие убытки.
Операции резервного копирования (backup) и восстановления (restore) связаны друг с другом и предполагают сохранение информации базы данных для использования в будущем. При резервном копировании данные копируются из базы данных и сохраняются в другом месте. Резервным копированием базы данных создается копия данных сразу всех пользователей. Поскольку SQL Server предназначен для максимально возможной непрерывной эксплуатации, процесс резервного копирования может выполняться во время работы базы данных и даже в то время, как пользователи осуществляют доступ к базе данных.
При восстановлении данных из резервной копии они копируются назад в базу данных. В отличие от процесса резервного копирования процесс восстановления не может выполняться во время работы SQL Server.
Воспроизведение (регенерация) (recovery) -это способность системы управления реляционной базой данных (СУРБД - RDBMS) воспроизвести выполненные транзакции. SQL Server не выполняет запись на диск после каждого изменения, вносимого в базу данных. Так как в каждой транзакции приходилось бы ждать, пока не закончится очередная запись, создающая задержку в системе.
Именно задержки при записи изменений на диск приводят к тому, что база данных после отказа системы может остаться в запорченном состоянии из-за того, что некоторые изменения, внесенные в базу данных, могли быть не записаны на диск, а изменения, записанные на диск, могли быть не зафиксированы. Для поддержки целостности базы данных SQL Server протоколирует все изменения в журнале транзакций. При запуске SQL Server после отказа системы журнал транзакций используется для повторного исполнения (воспроизведения) транзакций, которые были фиксированы, но не записаны на диск, и отката (отмены результатов) транзакций, которые не были фиксированы на момент аварии системы. Такой подход гарантирует точность данных.
SQL Server поддерживает нескольких типов транзакций в процессе воспроизведения:
Транзакции, содержащие только запросы. Никакого воспроизведения не требуется.
Транзакции, которые внесли изменения в данные базы данных и были, но не были записаны на диск. Во время воспроизведения SQL Server читает страницы данных с диска, снова вносит изменения и затем перезаписывает эти страницы на диск.
Транзакции, которые внесли изменения в данные базы данных, были фиксированы и записаны на диск. Во время воспроизведения SQL Server определяет, что изменения были действительно записаны на диск. Никакого вмешательства не требуется.
Транзакции, которые внесли изменения в данные базы данных, но не были фиксированы. Во время воспроизведения SQL Server использует журнал транзакций для отката (отмены) всех изменений, внесенных в страницы данных, и восстанавливает базу данных к состоянию, в котором она была до запуска этих транзакций.
При запуске SQL Server после аварии системы происходит автоматический запуск механизма воспроизведения. В этом механизме воспроизведения используется журнал транзакций, позволяющий определить, для каких транзакций требуется воспроизведение и для каких не нужно. Многие транзакции не требуют воспроизведения, но SQL Server должен прочитать журнал транзакций, чтобы определить, транзакциям это все же требуется. SQL Server начинает чтение журнала транзакций с момента создания последней контрольной точки.
В случае отказа системы, после которого требуется восстановление базы данных из файлов резервной копии (например, в случае потери диска), используются журнал транзакций и резервные копии журнала транзакций - для восстановления базы данных к состоянию, в котором она находилась на момент отказа. Таким образом, операции восстановления и воспроизведения обычно используются совместно друг с другом.
Транзакция – это набор операций, которые выполняются как один логический блок. Использование транзакций позволяет SQL Server обеспечивать определённый уровень целостности и восстанавливаемости данных. Журнал транзакций используется для записи всех транзакций и модификаций (вставка, обновление или удаление), которые вносятся в базу данных этими транзакциями. Именно эта запись позволяет выполнять воспроизведение. При фиксировании транзакции операция фиксирования не завершается, пока в журнал транзакций не будет внесена запись о фиксировании данной транзакции. Поскольку изменения, которые вносятся в базу данных, не сразу записываются на диск, журнал транзакций является единственным средством, с помощью которого можно воспроизвести транзакции в случае отказа системы. В зависимости от числа изменений, вносимых в базу данных, журнал транзакций может увеличиваться до больших размеров. Поскольку журнал транзакций состоит из одного или нескольких файлов, размер которых ограничен, этот журнал будет заполняться до конца, и поэтому его приходится время от времени укорачивать (усекать). Автоматическое усечение журнала выполняется по завершении его резервного копирования.
2.1.1 Поток откладываемой записи (Lazywriter Thread)
Изменения, вносимые в базу данных, сначала вносятся в данные, которые находятся в кэше SQL Server. To, что изменения вносятся сначала в кэш, требуется в первую очередь для повышения производительности, поскольку ожидание при операциях ввода-вывода занимает много времени. Эти изменения записываются в конечном итоге на диск, но этот процесс выполняется в фоновом режиме и не виден пользователю. Поскольку модифицированные страницы хранятся в кэше, то может пройти существенный период времени, прежде чем эти страницы (их еще называют ожидающими, черновыми страницами — dirty pages) будут записаны соответствующим потоком (подпроцессом) SQLServer. Этот поток называют потоком откладываемой записи («ленивым» потоком — lazywriter thread).
Этот поток использует LRU-список записи страниц, где первой в очереди записи на диск находится наиболее давно обрабатывавшаяся страница и последней является только что обрабатывавшаяся страница. Страница, которая постоянно модифицируется (и, тем самым, все время перемещается в конец этого списка), вообще может быть не записана этим потоком на диск. Подобные вещи могут увеличивать время воспроизведения, поскольку для применения изменений к таким данным потребуется прочитать много журнальных записей.
2.1.2 Контрольные точки
Поток контрольной точки выполняет запись ожидающих страниц на диск. Создание контрольной точки – это операция, которая используется для синхронизации физических файлов данных с кэшем базы данных, чтобы уменьшить время воспроизведения в случае отказа системы. Время, необходимое для воспроизведения базы данных, определяется периодом времени, прошедшим с момента создания последней контрольной точки, и количеством черновых (ожидающих записи) страниц в буферном кэше.
В случае отказа системы, при котором не повреждены файлы данных, текущий журнал транзакций используется для воспроизведения базы данных, поскольку это требуется для повторного исполнения транзакций, которые еще не были записаны на диск. Количество требующих воспроизведения страниц зависит от количества ожидающих записи (черновых) страниц в базе данных, которое, в свою очередь, определяется интервалом между контрольными точками. При создании очередной контрольной точки происходит запись всех черновых страниц на диск, что позволяет уменьшить время, необходимое для воспроизведения.
2.1.3 Конфигурирование интервала между контрольными точками
Интервал между контрольными точками определяется параметром конфигурирования SQL Server recovery interval. Этот параметр задается для всей системы SQL Server, а не для каждой базы данных, но контрольные точки создаются по отдельным базам данных. Этот параметр указывает, сколько минут потребует SQL Server для воспроизведения каждой базы данных в случае отказа системы. Значение 0 указывает, что интервал будет определять SQL Server (обычно он меньше 1 минуты). Для систем с большим объемом памяти, где выполняется очень много операций вставки и обновления, это принятое по умолчанию значение может приводить к созданию излишнего числа контрольных точек. В этом случае можно задать для этого параметра более высокое значение (например, 30 минут). При этом производительность транзакций системы будет выше.
Чтобы задать параметр Recovery interval из Enterprise Manager, в левой панели щелкните Правой кнопкой мыши на имени сервера, для которого хотите задать этот параметр, и выберите из контекстного меню пункт Properties (Свойства), чтобы появилось окно SQL Server Properties (Свойства SQL Server). Щелкните на вкладке Database Settings (Параметры базы данных) рис. 1, и задайте нужный вам интервал (в минутах) в поле-счетчике Recovery Interval (Интервал воспроизведения).