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 (Интервал воспроизведения).