|
|
Лекция Резервное копирование. 4. Лекция Методы аварийного восстановления для защиты базы данных версия для печати и pda
4. Лекция: Методы аварийного восстановления для защиты базы данных: версия для печати и PDA
Данная лекция рассказывает о методах аварийного восстановления для защиты базы данных. В частности, о выборе необходимой стратегии резервного копирования для базы данных, о конфигурировании правильной модели восстановления о выполнении полного, разностного резервного копирования и резервного копирования журнала транзакций
|
|
|
|
В предыдущей лекции рассматривалась тема обеспечения безопасности -защиты данных от несанкционированного доступа. В этой лекции рассказывается о защите данных от непредвиденной потери. Предотвращение потерь данных - одна из самых важных проблем, с которой можно столкнуться при управлении системами баз данных. Потери данных могут иметь место в результате множества самых различных проблем.
Неисправности аппаратного обеспечения
Вирусы
Некорректное использование инструкций UPDATE и DELETE
Ошибки программного обеспечения
Аварийные ситуации, например, пожар или затопление
Чтобы избежать потери данных, можно реализовать для базы данных стратегию восстановления. Стратегию восстановления необходимо спланировать, реализовать и протестировать с учетом возможных неисправностей, с которыми можно встретиться в процессе работы системы, и необходимого уровня защиты данных. В витринах данных, то есть в случаях, когда данные можно восстановить из других систем, вероятно, нет необходимости создавать резервные копии каждой отдельной транзакции. Возможно, будет достаточно выполнять полное резервное копирование данных с регулярными временными интервалами. И наоборот, для базы данных, в которой хранятся транзакции интернет-магазина, возможно, будет необходимо сохранять резервные копии каждой отдельной транзакции. СУБД SQL Server предоставляет полный комплекс функций для реализации именно того вида резервного копирования, который вам необходим. В данной лекции рассматриваются наиболее широко используемые в Microsoft SQL Server стратегии для защиты данных.
Полное резервное копирование базы данных
Самой распространенной стратегией резервного копирования является резервное копирование всей базы данных через заранее заданные промежутки времени (например, каждую ночь). Благодаря такой стратегии аварийного восстановления можно восстановить базу данных до состояния на момент выполнения последнего резервного копирования. Эта стратегия реализуется посредством выполнения полных резервных копий базы данных, как рассказывается ниже.
Полная резервная копия базы данных содержит все данные и метаинформацию базы данных, которые необходимы для восстановления базы данных полностью, включая полнотекстовые каталоги. При восстановлении базы данных из полной резервной копии восстанавливаются все файлы базы данных, причем данные извлекаются в непротиворечивом состоянии на тот момент времени, в который выполнялось резервное копирование. Пока выполняется резервное копирование, база данных работает в рабочем режиме, и пользователь может выполнять транзакции, изменяя данные обычным путем. Термин "непротиворечивое состояние" означает, что все транзакции, которые были зафиксированы в процессе выполнения резервного копирования базы данных, применяются, а все транзакции, которые не были завершены, подвергаются откату. Для ситуаций, которые могли бы привести к нарушению непротиворечивости данных вследствие выполнения транзакций, изменяющих данные в процессе выполнения резервного копирования, в SQL Server есть особый процесс, который позволяет гарантировать непротиворечивость данных. Этот процесс выполняет запись на устройство резервного копирования как страниц данных, так и журнала транзакций.
С овет. Полнотекстовые каталоги были введены в базы данных, чтобы добавить в SQL Server функции полнотекстового индексирования. Полнотекстовое индексирование позволяет быстрее и с большей точностью осуществлять поиск данных в базе данных. Дополнительную информацию о полнотекстовом индексировании см. в Электронной документации по SQL Server в разделе "Полнотекстовые индексы".
Скорость резервного копирования определяется скоростью используемых устройств ввода/вывода (тех устройств ввода вывода, которые используются для сбора и хранения информации). Чтобы добиться наилучшей производительности, SQL Server считывает файлы последовательно. Если ваши устройства ввода/вывода способны одновременно обрабатывать данные ввода/вывода резервного копирования и данные ввода/вывода, поступающие в результате обычного использования системы, то создание резервной копии окажет на производительность системы незначительное воздействие. Тем не менее, лучше выполнять полное резервное копирование базы данных при отсутствии пиковых нагрузок.
В следующем разделе мы рассмотрим варианты реализации этой стратегии резервного копирования.
Простая модель восстановления
Следует заранее уведомить SQL Server о том, какой тип резервного копирования вы намерены использовать, поэтому надо сконфигурировать базу данных так, чтобы настройки соответствовали выбранному вами типу резервного копирования. Такая настройка выполняется посредством выбора значения параметра "модель восстановления базы данных". Модель восстановления базы данных, которая используется по умолчанию, является производным от модели восстановления модели базы данных, определенной при ее создании. Чтобы реализовать стратегию резервного копирования, которая будет включать только полные резервные копии, следует выбрать простую модель восстановления ( SIMPLE ).
Выбираем модель восстановления SIMPLE
В меню Start (Пуск) выберите All Programs,. Microsoft SQL Server 2005, SQL Server Management Studio (Все программы, Microsoft SQL Server 2005, Среда SQL Server Management Studio).
В диалоговом окне Connect To Server (Соединение с сервером) нажмите кнопку Connect (Соединить).
В панели инструментов Standard (Стандартная) нажмите кнопку New Query (Новый запрос), чтобы открыть окно New Query (Новый запрос).
Чтобы задать модель восстановления, можно использовать инструкцию ALTER DATABASE. Введите текст следующей инструкции и нажмите кнопку Execute (Выполнить).
USE master;
GO
ALTER DATABASE AdventureWorks
SET RECOVERY SIMPLE;
GO
Д ополнительная информация.В этой лекции рассматривается, главным образом, создание резервных копий и восстановление с помощью инструкций SQL. В лекциях 6-7 будет рассмотрено выполнение многих из этих же процедур не через инструкции T-SQL, а с помощью интерфейса пользователя SQL Server Management Studio.
Проверяем настройки модели аварийного восстановления
Чтобы просмотреть заданную для базы данных модель восстановления, можно использовать функцию DATABASEPROPERTYEX, которая извлекает параметры текущей базы даты или свойства указанной базы данных. Выполните инструкцию, приведенную ниже, чтобы извлечь информацию о модели восстановления базы данных AdventureWorks.
SELECT DATABASEPROPERTYEX('AdventureWorks','Recovery')
Убедитесь, что в результатах запроса указана модель восстановления SIMPLE.
Закройте окно среды SQL Server Management Studio.
Устройства резервного копирования
До начала выполнения операций резервного копирования необходимо определить, где будут храниться резервные копии. Место хранения резервных копий называется устройством резервного копирования. Каждое устройство резервного копирования может хранить несколько резервных копий разных типов. Существует два разных вида устройств резервного копирования:
Ленточные устройства.Могут использоваться для хранения резервных копий на лентах. Ленточные устройства должны быть установлены локально. Резервная копия может занимать несколько лент, а на одной ленте могут находиться одновременно резервные копии SQL Server и Windows.
Дисковые устройства.Файлы на локальном или удаленном диске или дисковом накопителе. К этим файлам обращаются, указывая путь к файлу, в котором хранится резервная копия. Для обращения к удаленным хранилищам следует использовать путь в формате UNC.
П римечание. В этой книге будет рассмотрено только резервное копирование на дисковые устройства. Резервное копирование файлов SQL Server на ленточные устройства в настоящее время используется не очень часто. Если резервные копии SQL Server сохраняются на лентах, то они обычно создаются при помощи программ сторонних разработчиков, которые предлагают дополнительные функции, например, использование удаленного ленточного хранилища. В качестве альтернативы ленточное устройство может использоваться для дополнительного страхования сохранности данных, резервная копия которых уже сохранена на дисковом устройстве.
Устройства резервного копирования идентифицируются по имени устройства. В качестве имени устройства может использоваться имя логического или физического устройства. Имя физического дискового устройства представляет собой путь к файлу резервной копии, например, "\\BACKUPSERVER\Backups\adv\AdventureWorks.bak". Этот путь можно включить непосредственно в инструкцию резервного копирования. Имя логического устройства представляет собой имя, указывающее на имя физического устройства резервного копирования и хранящееся в SQL Server. Когда в инструкции резервного копирования используется имя логического устройства, SQL Server осуществляет поиск соответствующего физического устройства в системном каталоге и выполняет резервное копирование, сохраняя резервную копию в указанной папке.
Чтобы добавить в системный каталог логическое устройство, можно использовать хранимую процедуру sp_addumpdevice. В следующем примере определяется логическое устройство с именем Adv_FullDb_Dev.
EXEC sp addumpdevice "disk", "AdvFullDbDev", "T:\BACKUPS\AdvFullDbDev.bak";
С овет. Обязательно измените путь к файлу, чтобы он соответствовал вашему компьютеру. Т:/, то измените эту часть пути к файлу в инструкции так, чтобы он соответствовал букве диска на вашем компьютере. Кроме того, убедитесь в том, что все папки, заданные в этом пути, существуют на вашем компьютере.
Имена логических и физических устройств являются взаимозаменяемыми, для резервного копирования и восстановления базы данных могут использоваться оба имени. Конечно, как правило, лучше все время использовать одно из двух соглашений о назначении имен, чтобы не усложнять код. Следует заранее выбрать соглашение, которое вам больше нравится.
Никогда не следует выполнять резервное копирование на дисковое устройство, которое размещается на том же физическом устройстве хранения, что и сама база данных. Даже если дисковое хранилище отличается устойчивостью против сбоев благодаря наличию RAID, всегда существует возможность возникновения неисправности контроллера и повреждения данных на дисках. Кроме того, следует подумать о сохранении файлов резервной копии устройства резервного копирования на лентах и хранении этих лент в удаленном месте.
С овет. Сокращение RAID происходит от выражения "redundant array of independent disks" (избыточный массив независимых дисков). Такие массивы представляют собой системы дисков с несколькими приводами, которые используются для повышения доступности и емкости хранилища.
Выполнение полного резервного копирования базы данных
После того, как вы установили модель резервного копирования на SIMPLE и решили, на каком устройстве резервного копирования сохранять резервные копии, можно приступить к выполнению резервного копирования. Полное резервное копирование базы данных выполняется с помощью довольно простой инструкции BACKUP DATABASE. В простейшей форме нужно только указать системе, резервную копию какой базы данных создать и на каком устройстве ее сохранить. Чтобы создать резервную копию базы данных AdventureWorks на предварительно выбранном логическом устройстве, используется следующая инструкция T-SQL:
USE master;
GO
BACKUP DATABASE AdventureWorks
TO Adv_FullDb_Dev;
Если надо выполнить полное резервное копирование базы данных на физическое устройство, необходимо указать тип устройства и место размещения резервной копии в инструкцииBACKUP DATABASE. Чтобы создать резервную копию базы данных в папке t:\adv.bak, используйте следующую инструкцию:
USE master;
GO
BACKUP DATABASE AdventureWorks
TO DISK='t:\adv.bak';
Как уже говорилось, на любом устройстве резервного копирования может храниться больше одной резервной копии. В аргументе инструкции BACKUP DATABASE можно указать, следует ли SQL Server перезаписать существующую резервную копию на этом устройстве или дописать ее к существующим резервным копиям. Для этого используются ключевые слова INIT илиNOINIT. Если указать INIT, то перед запуском резервного копирования устройство резервного копирования форматируется, при этом удаляются все резервные копии, которые имеются на этом устройстве. NOINIT, которое используется по умолчанию, если не указано иное, разрешает SQL Server дописать резервную копию на существующее устройство резервного копирования с сохранением всех существующих на нем резервных копий. Эти опции устанавливаются при помощи блока WITH в конце инструкции BACKUP DATABASE.
Если нужно создать такую же резервную копию, как в предыдущем примере, но при этом указать SQL Server сначала очистить устройство, используйте следующую инструкцию:
USE master;
GO
BACKUP DATABASE AdventureWorks
TO DISK='t:\adv.bak'
WITH INIT;
Как видите, выполнение полного резервного копирования базы данных не отличается сложностью. В следующем разделе вы увидите, что полная резервная копия - это основной тип резервного копирования, на котором строятся все остальные типы резервного копирования. Остальные типы резервного копирования зависят от наличия полной резервной копии, потому что им необходима восстановленная база данных в качестве исходной точки. Эти типы резервного копирования, в том числе, разностное резервное копирование, сохраняют изменения, которые были внесены в базу данных после создания полной резервной копии. Таким образом, мы видим, что полные резервные копии важны не только в стратегии восстановления, при которой выполняется только полное резервное копирование, но и в других стратегиях резервного копирования, о которых речь пойдет ниже.
Разностное резервное копирование
Главное преимущество полного резервного копирования базы данных заключается в том, что в полной резервной копии содержатся все данные, которые необходимы для восстановления базы данных полностью. Но это преимущество может одновременно быть и недостатком. Представьте себе базу данных, для которой каждую ночь создается резервная копия. Если придется восстанавливать базу данных, в любом случае придется использовать резервную копию, созданную прошлой ночью, и в результате будут потеряны результаты работы за целый день. Один из способов уменьшить потенциальный промежуток времени, который может быть не учтен резервным копированием является более частое выполнение полного резервного копирования базы данных. Но это само по себе является проблематичным. Поскольку все данные и фрагменты журнала транзакций записываются на устройство резервного копирования, выполнение резервного копирования может отнимать слишком много времени. Кроме того, для хранения всех этих резервных копий необходимо много дискового пространства h° , а полное резервное копирование может снизить производительность базы данных в результате потребности в большом объеме операций ввода/вывода. Не лучше ли будет один раз выполнить резервное копирование ночью, а затем выполнять резервное копирование только тех данных, которые были изменены в течение дня? Такие функциональные возможности предоставляет разностный тип резервного копирования.
Разностное резервное копирование сохраняет только те изменения данных, которые произошли после создания полной резервной копии. Если одни и те же данные с момента создания полной резервной копии изменялись несколько раз, то разностное резервное копирование сохраняет самую последнюю версию измененных данных. Для восстановления данных из разностной резервной копии придется сначала восстановить данные полной резервной копии, а после этого применить только последнюю из разностных резервных копий, как показано нарис. 4.1.
Рис. 4.1. Стратегия резервного копирования с использованием разностных резервных копий
Выполнение разностного резервного копирования
Выполнение разностного резервного копирования мало чем отличается от выполнения полного резервного копирования. Единственное отличие заключается в том, что в блоке WITHобъявляются инструкции по создании разностной резервной копии. Синтаксис инструкции BACKUP DATABASE для выполнения резервного копирования базы данных Adventure Works на физическое устройство с перезаписью других существующих резервных копий на этом устройстве будет таким:
USE master;
GO
BACKUP DATABASE AdventureWorks
TO DISK='t:\adv_diff.bak'
WITH INIT,DIFFERENTIAL;
Если вы хотите использовать логическое устройство, то следует сначала создать его, как и в случае полного резервного копирования.
USE master;
GO
EXEC sp_addumpdevice "disk", "Adv_Diff_Dev",
"T:\BACKUPS\AdvDiffDev.bak";
GO
BACKUP DATABASE AdventureWorks
TO Adv_Diff_Dev
WITH INIT,DIFFERENTIAL;
В ажно. Для восстановления данных из разностной резервной копии всегда необходима самая последняя полная резервная копия. Будьте внимательны, чтобы не перезаписать или удалить полную резервную копию базы данных, пока она необходима для восстановления данных из разностных резервных копий.
Резервное копирование журнала транзакций
Комбинируя полную и разностную копии базы данных, можно создать снимок состояния данных и восстановить их. Но в некоторых ситуациях желательно также иметь резервные копии всех событий, которые произошли с базой данных, вплоть до записей о каждой выполненной инструкции. Таким образом, можно было бы восстановить базу данных до любого необходимого состояния. Резервное копирование журнала транзакций как раз и предоставляет такую возможность. Как ясно из названия, метод резервного копирования журнала транзакций создает резервные копии всех записей журнала транзакций, которые произошли в базе данных. Основные преимущества резервного копирования журнала транзакций следующие:
Резервное копирование журнала транзакций позволяет восстановить данные на определенный момент времени.
Поскольку резервное копирование журнала транзакций создает резервные копии записей в журнале, можно выполнить резервное копирование из журнала транзакций даже в том случае, если данные повреждены. При помощи такой резервной копии можно восстановить базу данных вплоть до последней транзакции, которая имела место до того, как начались проблемы. Таким образом, в случае возникновения неисправности ни одна из фиксированных транзакций не будет потеряна.
Как и в случае с разностными резервными копиями, для восстановления базы данных из резервных копий журнала транзакций в стратегии восстановления необходима базовая полная резервная копия базы данных. Стратегия резервного копирования с использованием резервных копий журнала транзакций показана на рис. 4.2. Полные резервные копии базы данных выполняются в часы наименьшей загрузки оборудования, а резервные копии журнала транзакций выполняются в определенное время в течение дня. Резервные копии журнала транзакций содержат все транзакции, которые произошли с момента создания последней резервной копии журнала транзакций. Следовательно, чтобы восстановить базу данных с использованием резервных копий журнала транзакций, необходимы полная резервная копия базы данных и все резервные копии журнала транзакций с момента создания полной резервной копии. Как видите, важно, чтобы все резервные копии были доступны. Если полная резервная копия базы данных или одна из резервных копий журнала транзакций будут утеряны, то восстановление данных в желательном объеме будет невозможно.
Рис. 4.2. Стратегия резервного копирования с использованием резервных копий журнала транзакций
Комбинирование разностных резервных копий и резервных копий журнала транзакций
Возможна еще одна стратегия - это комбинирование полного и разностного методов резервного копирования с резервным копированием журнала транзакций. Такая стратегия применяется, когда восстановление данных из резервных копий журнала транзакций отняло бы слишком много времени. Поскольку восстановление данных из резервной копии журнала транзакций означает, что все транзакции должны быть выполнены снова, то восстановление всех данных, особенно в крупных базах данных, может занять очень много времени. Разностные резервные копии применяют только изменения данных, которые могут быть выполнены быстрее по сравнению с повторным выполнением всех транзакций.
Чтобы восстановить базу данных при использовании комбинированной стратегии, как показано на рис. 4.3, нужно восстановить сначала данные последнего полного резервного копирования, затем последнего разностного копирования, и в завершение данные всех последующих резервных копий журнала транзакций.
Рис. 4.3. Комбинированная стратегия резервного копирования
Например, чтобы восстановить данные до резервной копии журнала транзакций Т3, следует восстановить данные полной резервной копии F1, разностной резервной копии D1 и резервной копии журнала транзакций Т3.
Интервал времени между созданием резервных копий журнала транзакций зависит от:
Количества и размера транзакций, выполняемых в базе данных. При этой стратегии резервного копирования SQL Server должен хранить все транзакции до тех пор, пока не будет сохранена резервная копия журнала транзакций. Следовательно, в файл журнала транзакций должны поместиться все транзакции, которые были выполнены за период времени между двумя последовательными резервными копированиями журнала транзакций. Если журнал заполняется слишком быстро, следует уменьшить временные интервалы между созданием резервных копий журнала транзакций или увеличить размер файла журнала транзакций.
Приемлемого объема потери данных. Как уже упоминалось выше, можно восстановить данные вплоть до последней транзакции, если файлы данных утрачены. Но если журнал транзакций будет поврежден или утрачен, то можно будет восстановить только данные на момент последнего резервного копирования журнала транзакций. Уменьшение временных промежутков между созданием резервных копий журнала транзакций снизит объем потерянных данных в подобной ситуации.
| |
|
|
Скачать 156.73 Kb.