Опубликован: 11.12.2006 | Доступ: свободный | Студентов: 5820 / 381 | Оценка: 4.42 / 3.86 | Длительность: 57:15:00
Лекция 32:

Резервное копирование Microsoft SQL Server

Отказы системы

У вас могут возникнуть сомнения в необходимости резервного копирования, если вы используете такие технологии, как службы кластеризации Microsoft Cluster Services и отказоустойчивые дисковые подсистемы RAID. Тем не менее резервное копирование необходимо. Возможны различные случаи отказов вашей системы, а упомянутые системы поддержки отказоустойчивости и восстановления в случае отказов позволяют продолжить нормальную работу вашей системы не для всех случаев отказов. В этом разделе мы рассмотрим некоторые из потенциальных причин отказов и способы восстановления после этих отказов.

Некоторые из отказов могут носить умеренный характер; некоторые могут оказаться разрушительными. Чтобы понять важность резервного копирования, вы должны знать о трех основных категориях отказов: отказы оборудования, отказы программного обеспечения и человеческие ошибки.

Отказы оборудования

Отказы оборудования – это, видимо, наиболее распространенный тип отказов, с которыми вы будете сталкиваться. Хотя эти отказы возникают менее часто по мере роста надежности компьютерного оборудования, но компоненты компьютеров все равно со временем становятся подвержены износу. Вот следующие типичные отказы оборудования.

  • Отказ ЦП (CPU), памяти или шины (магистрали) данных. Эти отказы обычно приводят к аварийному отказу системы. После замены неисправного компонента и перезапуска системы SQL Server автоматически выполняет воспроизведение базы данных. Собственно база данных не затрагивается таким отказом, поэтому ее восстановление (с резервной копии) не требуется; SQL Server просто должен воспроизвести потерянные транзакции
  • Отказ диска. Если вы используете отказоустойчивые матрицы RAID, то отказ этого типа, возможно, вообще не повлияет на состояние базы данных. Вы должны просто отремонтировать матрицу RAID. Но при отказе всей матрицы RAID единственной альтернативой является восстановление базы данных из резервной копии и использование резервных копий журнала транзакций для воспроизведения базы данных.
  • Катастрофический отказ системы или полная потеря сервера. При разрушении всей системы из-за пожара или другой катастрофы, возможно, потребуется восстановление "с нуля". Потребуется новое оборудование, восстановление базы данных с резервной копии и воспроизведение базы данных с помощью резервных копий данных и журнала транзакций.
Отказы программного обеспечения

Отказы программного обеспечения происходят редко, и вашу систему, возможно, никогда не затронет такой тип отказов. Однако отказы программного обеспечения обычно более разрушительны, чем отказы оборудования, поскольку программное обеспечение содержит встроенные средства, которые сводят к минимуму отказы оборудования, а без этих защитных средств система подвержена аварийным отказам в случае отказов оборудования. Примером программного средства является журнал транзакций, предназначенный для восстановления систем после отказов оборудования. Существуют следующие типичные отказы программного обеспечения.

  • Отказы операционной системы. Если отказ этого типа происходит в подсистеме ввода-вывода, то могут быть запорчены данные на диске. Если отказ не затрагивает базу данных, требуется только воспроизведение. Если запорчена информация в базе данных, то остается только восстановление базы данных с резервной копии.
  • Отказ СУРБД (RDBMS). Возможен отказ самого SQL Server. Если отказ этого типа привел к порче данных, то должно быть выполнено восстановление базы данных с резервной копии и последующее воспроизведение. Если данные не запорчены, то для возврата системы к состоянию, в котором она находилась на момент отказа, требуется только автоматическое воспроизведение.
  • Отказ приложения.Возможен отказ приложений, что может приводить к порче данных. Если отказ этого типа привел к порче данных, то должно быть выполнено восстановление базы данных с резервной копии (как и в случае отказа СУРБД). Если данные не запорчены, то восстановление не нужно; автоматическое воспроизведение вернет систему к состоянию, в котором она находилась на момент отказа. Возможно, вам потребуется получить исправление от поставщика этого приложения, чтобы не допустить повторения отказа этого типа.
Примечание. Компании часто проводят опробование бета-версий SQL Server. Бета-версии программного обеспечения предназначены только для оценки и тестирования и не должны использоваться в условиях промышленной эксплуатации. Иногда бета-версии содержат ошибки и средства, которые не были проверены в полной мере. Вам следует использовать эксплуатационную версию Microsoft SQL Server 2000, прошедшую полное тестирование и готовую к промышленной эксплуатации.
Человеческие ошибки

Третьей основной категорией отказа является человеческая ошибка. Человеческие ошибки могут возникать в любой момент и без предупреждения. Они могут быть умеренными и серьезными. К сожалению ошибки этого типа могут оставаться незамеченными в течение дней или даже недель, что затрудняет процесс восстановления. Поддерживая хорошие взаимоотношения с вашими пользователями (включая средства связи), вы можете быстрее и проще выполнять восстановление после ошибок пользователей. Пользователи не должны опасаться вашей реакции и сразу сообщать вам об ошибке. Чем раньше вы узнаете об ошибке, тем лучше. Следующие отказы могут быть вызваны человеческой ошибкой:

  • Потеря сервера с базой данных. К потере сервера могут приводить такие человеческие ошибки, как внезапное отключение питания или отключение сервера без закрытия SQL Server. Воспроизведение происходит автоматически при перезапуске SQL Server, но может потребовать определенного времени. Если отказ не затронул базу данных на диске, то восстановление не требуется.
  • Потеря данных. Этот тип потери данных может быть вызван, например, случайным удалением файла данных, что привело к потере базы данных. Для возврата базы данных к ее состоянию до отказа должны быть выполнены операции восстановления и воспроизведения.
  • Потеря таблицы или порча данных.Если таблица удалена по ошибке или ее данные изменены некорректным образом, то для возврата таблицы к ее исходному состоянию вы можете использовать восстановление и воспроизведение. Это может оказаться очень сложным делом, поскольку отдельную таблицу или небольшой набор данных нельзя просто восстановить из резервной копии. Пример восстановления данных после отказа этого типа приводится в "Восстановление и воспроизведение базы данных" .

Журнальное протоколирование в SQL Server

Чтобы понять, как сочетаются операции резервного копирования и восстановления с воспроизведением базы данных, вам нужно сначала узнать, как происходит журнальное протоколирование в SQL Server. В этом разделе дается обзор возможностей журнального протоколирования и создания контрольных точек в SQL Server, а также описывается резервное копирование журнала транзакций.

Журнал транзакций

Журнал транзакций используется для записи всех транзакций и модификаций, которые вносятся в базу данных этими транзакциями. Именно эта запись позволяет выполнять воспроизведение. При фиксировании транзакции операция фиксирования не завершается, пока в журнал транзакций не будет внесена запись о фиксировании данной транзакции. Поскольку изменения, которые вносятся в базу данных, не сразу записываются на диск, журнал транзакций является единственным средством, с помощью которого можно воспроизвести транзакции в случае отказа системы.

Примечание. Если какой-либо файл данных поврежден и должен быть восстановлен с резервной копии, то для возврата базы данных к состоянию, в котором она находилась непосредственно перед отказом, необходимо воспроизвести транзакции, выполненные с этим файлом данных. А поскольку журнал транзакций является определяющим компонентом для этого процесса и занимает ограниченное дисковое пространство, то необходимо создавать резервные копии этого журнала. Для воспроизведения базы данных у вас должны быть сохранены все данные журнала транзакций, созданные с момента последнего резервного копирования. Если вас интересует только восстановление с последней резервной копии базы данных, то вы можете не выполнять резервное копирование журнала транзакций, но с помощью текущего журнала транзакций вы не сможете воспроизвести транзакции, выполненные с момента создания резервной копии базы данных.
Поток откладываемой записи (Lazywriter Thread)

Изменения, вносимые в базу данных, сначала вносятся в данные, которые находятся в кэше SQL Server. То, что изменения вносятся сначала в кэш, требуется в первую очередь для повышения производительности, поскольку ожидание при операциях ввода-вывода занимает много времени. Эти изменения записываются в конечном итоге на диск, но этот процесс выполняется в фоновом режиме и не виден пользователю. Поскольку модифицированные страницы хранятся в кэше, то может пройти существенный период времени, прежде чем эти страницы (их еще называют ожидающими, черновыми страницами – dirty pages) будут записаны соответствующим потоком (подпроцессом) SQL Server. Этот поток называют потоком откладываемой записи ("ленивым" потоком Этот поток использует LRU-список записи страниц, где первой в очереди записи на диск находится наиболее давно обрабатывавшаяся страница и последней является только что обрабатывавшаяся страница. Страница, которая постоянно модифицируется (и, тем самым, все время перемещается в конец этого списка), вообще может быть не записана этим потоком на диск. Подобные вещи могут увеличивать время воспроизведения, поскольку для применения изменений к таким данным потребуется прочитать много журнальных записей. Например, в большой системе с объемом RAM-памяти более 1 Гб и большим числом изменений в базе данных воспроизведение может занять несколько часов. – lazywriter thread).

Кроме потока откладываемой записи, поток контрольной точки а также выполняет запись ожидающих страниц на диск. (Мы рассмотрим более подробно поток контрольной точки ниже в этом разделе.)

Последовательная запись в журнал

Журнал транзакций содержит "историю транзакций", поэтому операции ввода-вывода для журнала транзакций – это в основном операции записи, которые обычно выполняются последовательно. В случае отката транзакций происходит чтение журнала транзакций, что приводит к нарушению последовательного характера операций ввода-вывода. Поскольку откаты происходят довольно редко (так как аварии системы случаются редко и пользователи не слишком часто отменяют транзакции), ввод-вывод для журнала транзакций имеет достаточно устойчивый характер. Вы можете существенно повысить производительность операций ввода-вывода, поместив журнал транзакций на его собственный диск или матрицу RAID (см. "Проектирование системы Microsoft SQL Server" и "Конфигурирование и планирование подсистемы ввода-вывода" ). В силу исключительной важности журнала транзакций для воспроизведения базы данных вам следует защитить его с помощью дисковой матрицы RAID.

Размер журнала транзакций

В зависимости от числа изменений, вносимых в базу данных, журнал транзакций может увеличиваться до больших размеров. Поскольку журнал транзакций состоит из одного или нескольких файлов, размер которых ограничен, этот журнал будет заполняться до конца, и поэтому его приходится время от времени укорачивать (усекать). Автоматическое усечение журнала выполняется по завершении его резервного копирования, как мы увидим ниже в этой лекции.

Примечание. Вы можете усекать журнал транзакций без его резервного копирования, задав для параметра trunc. log on chkpt (усечение при создании контрольной точки) значение TRUE в используемой базе данных. Но после этого вы не сможете получать резервную копию журнала транзакций. В результате вы лишитесь возможности воспроизведения базы данных и поэтому данная установка не рекомендуется.
Воспроизведение с помощью журнала транзакций

В случае отказа системы, при котором не повреждены файлы данных, текущий журнал транзакций используется для воспроизведения базы данных, поскольку это требуется для повторного исполнения транзакций, которые еще не были записаны на диск. Количество требующих воспроизведения страниц зависит от количества ожидающих записи (черновых) страниц в базе данных, которое, в свою очередь, определяется интервалом между контрольными точками. При создании очередной контрольной точки происходит запись всех черновых страниц на диск, что позволяет уменьшить время, необходимое для воспроизведения. Контрольные точки и интервал между контрольными точками подробно описываются в разделе "Контрольные точки" ниже в этой лекции.