Министерство ОбразованияРоссийской Федерации
Название Вашего института(полное)
Название Вашей кафедры (полное)
Курсовая работа
по специальности ""
на тему:
«Восстановление базы данных»
Москва, 2010
Содержание
Введение
1.Причины повреждений баз данных
2.Восстановление баз данных на примере SQL Server 2005
2.1Основные возможности восстановления баз данных SQL Server 2005
2.2Подготовка к восстановлению
2.3Проведение восстановления
2.4Специальные ситуации восстановления
Заключение
Списоклитературы
Введение
Установлено, что большинство предприятий, переживших крупную необратимуюпотерю корпоративных данных, прекращают свое существование в течение трех летпосле такого инцидента. Мысль о возможной катастрофе неприятна для ИТ- ибизнес-менеджеров, поэтому они часто не принимают серьезных предупредительныхмер. К сожалению, это грубая правда жизни. И здесь под «предупредительнымимерами» ни в коем случае нельзя понимать «покупку техникиbrand-name», так как «брэнды» тоже ломаются, иногда даже чаще чем«самосборные машины». Поэтому «предупредительные меры» — это не только качественное «железо», но и планирование резервногокопирования данных.
Актуальность моего исследования определила цель и задачи работы:
Цель исследования – рассмотреть методы восстановления баз данных
Для достижения цели необходимо решить следующие задачи:
1. На основе анализазарубежной и отечественной литературы, монографических источников изучить методывосстановления баз данных
2. Выявить причины прикоторых базу данных нужно восстанавливать
3. Провести анализосновных возможностей восстановления
4. Рассмотреть напримере SQL Server2005 восстановление базы данных
5. На основепроведенного исследования сделать выводы и дать рекомендации по работе
Для раскрытия поставленной цели и задач определена следующая структураисследования: работа состоит из введения, двух глав, заключения и спискаиспользованной литературы. Названия глав отображают их содержание.
1.Причины повреждений баз данных
Существует несколько причин, при которых база данных может оказатьсяповрежденной. Перечислим наиболее характерные.
1. Отключение питания сервера.
Самый частый случай повреждения базы данных это отключение питания насервере. Такие ситуации нужно пытаться предотвращать, используя аппаратныесредства (UPS, RAID-контроллеры с батарейками).
Существует два режима записи страниц — синхронный и асинхронный.Синхронная запись означает, что измененные страницы базы данных не будуткэшироваться операционной системой, а будут записываться непосредственно надиск при выталкивании страниц из кэша на запись (на Windows это в буквальномсмысле отсутствие флага lazy write при открытии файла БД). Это ухудшаетпроизводительность, поэтому большинство людей выключают forced writes. В этомслучае измененные страницы находятся в кэше операционной системы до тех пор,пока операционная система не решит записать их на диск.
В некоторых случаях при непрерывной работе с БД операционная система несбрасывает измененные страницы на диск до тех пор, пока все пользователи неотсоединятся от базы данных. При выключении питания в этом случае повреждениябазы данных могут быть максимальными. Причем, повреждения в данном случаепроисходят от «недозаписи» информации. Это куда менее печальныйслучай, чем «перезапись» информации случайными данными. Однако, наWindows было обнаружено, что если у базы данных установлено Forced Write = Off,то при определенных условиях измененные страницы БД могли неделями не попадатьв БД, и оставаться в кэше операционной системы. При этом, в случае сбоя сервера(или отключения питания), пропадало огромное количество изменений в БД (а базамогла выглядеть вообще неповрежденной). То есть, БД как бы оказывалась«неизменяемой» в течение длительного времени.
2. Дефекты оборудования
Память. Самый частый дефект — сбои памяти (RAM). Очевидно, прииспользовании серверов «своей сборки» приобретается память подешевле,что приводит к соответствующим результатам. Желательно для сервера приобретатьи материнскую плату и память с поддержкой ECC. Сбои памяти могут привести кдостаточно тяжелым последствиям. Сервер не только «пропускает»страницы базы данных через память, но и кэширует их в памяти. Контрольные суммыстраниц, даже если бы они и были, не помогут когда сервер будет записыватьстраницу на диск через сбойный участок памяти. В противном случае данныепришлось бы перечитывать, что весьма серьезно ухудшило бы производительность.Сбои памяти еще плохи тем, что в этом случае поврежденными как правилооказываются и база данных и ее копия, если копия используется в качестве«быстрой резервной копии» (т.к. запись на диск идет из одних и тех жеучастков памяти).
Диски. Раньше, лет 10-15 назад, bad-блоки появлялись часто, исуществовали специальные утилиты для их исправления. Сейчас контроль ошибок нетолько может исправить данные на поврежденном блоке самостоятельно, но ипрозрачно сохранит блок в рабочем месте диска, а плохой блок пометит кисключению из дальнейшего использования. Грубо говоря, нынешние диски либоработают, либо не работают целиком.
Контроллеры. Здесь можно отметить только то, что при сбое в работеконтроллера некорректная информация может быть записана на все носители,которые подключены к этому контроллеру. Именно поэтому при организации созданиякопии рекомендуется располагать ее на винчестере, подключенном к другомуконтроллеру.
Другие программы. Приложения в основном не работают с операционнойсистемой на «внутреннем» уровне. Такие приложения никогда не смогутвызвать сбой типа известного «синего экрана» в Windows. Поэтому еслиподобный сбой ОС произошел, в этом скорее виноваты некорректно работающиедрайверы или само оборудование (очень часто в «синем экране» виноватыдрайвера видео).
3. Сбои самого сервера
Разумеется, серверные программы, как и любое другое ПО, не являютсяидеальной программой. Идеальной, конечно, в смысле отсутствия ошибок. Если«железо» работает нормально, сервер может сам «сломаться» илибо просто перестать работать, либо испортить базу данных.
Раньше код сервера содержал вызов обычной функции позиционирования пофайлу БД (seek), которая не могла адресовать более 4-гигабайт (в те далекиевремена просто не было файловых систем, которые поддерживали файлы больше 4-хгигабайт). Когда в функцию передавалось такое большое число, оно обрезалось постаршим разрядам. Происходила такая ситуация при операции расширения файла БД,т.е. при записи новых страниц, а следовательно файл БД оказывался«затертым» новой информации с самого начала, т.е. с нулевой страницы(страница заголовка БД). Если новых страниц к записи было много, то уничтожаласьначальная часть БД, где как правило содержатся системные таблицы, страницыинформации о транзакциях и т.п. Причем борьба с пресловутым размером файла в 4гигабайта дольше всего велась на Linux, что связано не только с кодом СУБД, нои с поддержкой файлов таких размеров самой операционной системой и ее файловымисистемами. На Windows, Firebird и Yaffil этой проблемы уже нет, т.е. файл БДможет иметь размер и 10, и 20 и больше гигабайт.
В любом случае, при работе на Unix или Windows следует внимательноизучить возможности ядра и конкретной (используемой) файловой системы — способны ли они работать с файлами больше 4-х гигабайт, а также проверитьверсию IB/FB/YA, чтобы быть уверенным в корректной работе с такими файлами, илинаоборот, сразу предусмотреть разбиение БД на многофайловую, например«кусками» по 2-3 гигабайта.
В отношении файловых систем Windows известна следующая особенность: наFAT32 поддерживаются файлы размером не более 4 гигабайт (чаще всего указанноеповреждение БД и происходит при использовании этой, фактически уже устаревшей,файловой системы). Допустим, размер вашей БД достиг 3-х гигабайт, и вы хотитеперенести ее на NTFS, чтобы избежать ограничения в 4 Гб. Проблема в том, что сFAT32 на NTFS скопируется только 2 гигабайта из 3-х, из-за особенностейWindows. Это еще раз подчеркивает необходимость знания ограничений используемыхфайловых систем и их взаимодействия на одном компьютере.
4. Остановка во время сборки мусора
Если во время принудительного завершения работы сервера были активныеподключения и сервер занимался сборкой мусора, то база данных может бытьповреждена (и чаще всего это так и происходит). Уменьшить вероятность такихповреждений можно только отключив автоматическую сборку мусора, а в случаепринудительной сборки мусора предварительно делать «быстрый» backup,чтобы резервная копия базы данных оказалась самой свежей в случае сбоя иповреждения БД.
5. Повреждения индексов
Повреждения индексов могут происходить как по всем вышеперечисленнымпричинам, так и из-за ряда багов сервера при работе с индексами. Посколькуиндексы не являются 100% необходимым видом объектов для функционирования базыданных, их повреждения обнаруживаются значительно позже, чем повреждения другихобъектов БД (например, данных таблиц). И клиентские приложения могут продолжатьфункционировать в такой ситуации как и прежде.
Однако, при повреждении индексов возможно искажение данных, получаемыхприложениями. Если в индексе повреждено несколько ключей, и сервер не выдалсообщения об ошибке при выполнении запроса, использующего такой индекс, врезультат запроса не попадут записи, на которые ссылаются те самые поврежденныеключи. То есть, часть записей может «пропасть». Обнаружить разницу ввыдаваемом количестве записей можно только используя запросы с полным переборомзаписей
SELECT * FROM TABLE
и с перебором по индексу
SELECT * FROM TABLE
WHERE FIELD > 0
где FIELD — столбец, по которому есть возможно поврежденный индекс, а> 0 — условие, которое однозначно будет выбирать все записи.
Можно этого и не делать, а при подозрении на «пропаданиезаписей» сразу посмотреть в log-файл, и перестроить те индексы, оповреждениях которых там сообщается.
В log-файл пишутся только порядковые номера индексов (а не их имена) дляконкретных таблиц. Процесс backup поврежденные или неповрежденные индексы (заисключением повреждений индексов по системным таблицам) не интересуют, т.к.индексы в backup хранятся только в виде описания в системных таблицах (restoreсоздает индексы по этим описаниям в самом конце процесса restore). Backupсчитывает записи в натуральном порядке и индексы не использует, поэтому всесуществующие (committed) записи обязательно попадут в backup. Однако, еслиповрежден уникальный индекс, то в определенных условиях существует вероятностьповторной вставки записи в таблицу с уже существующим (уникальным) значениемстолбца. Эта ситуация может привести к невосстановимому backup, т.е. процессrestore остановится в момент создания уникального индекса, обнаружив дубликатуникального значения в восстановленных записях. Но такая проблема также неявляется катастрофической — процесс создания индексов выполняется самымпоследним, т.е. после того как абсолютно все объекты БД уже восстановлены вбазе данных процессом restore. Если вдруг обнаружена проблема неуникальныхданных при создании индекса, можно попробовать найти такую запись (и затемудалить лишнюю) запросом
SELECT ID, COUNT(*) FROM TABLE
GROUP BY ID
HAVING (COUNT(*)) > 1
где id — столбец, по которому есть не создаваемый уникальный индекс.После этого можно активировать индексы, которые не были восстановлены.
6. Повреждения таблиц
Нормальная база данных — это не набор отдельных таблиц. Таблицы междусобой могут быть достаточно сильно взаимосвязаны, вплоть до циклических ссылок.Поэтому даже один и тот же тип и объем повреждения может иметь разныепоследствия, в зависимости от того, с какой таблицей это произошло. Типичныйпример: таблица CLIENTS — справочная, а ORDERS — оперативная. Если пропадетчасть записей из ORDERS, то после починки БД будет нормально функционировать.Если же будет повреждена CLIENTS, то после починки в ORDERS будут записи,ссылающиеся на несуществующих клиентов. Таким образом БД вроде бы будетотремонтирована, но логическая целостность данных будет нарушена. Бороться сэтой ситуацией никак невозможно, разве что чаще делая backup (посколькусправочники меняются реже, чем оперативные данные). Подобная ситуация (сповреждением master-таблицы) может возникнуть даже в том случае, если всезаписи пакета master-detail вставляются в одной транзакции, а Forced Writeвыключен (off) — страницы с записями detail могут быть записаны на дископерационной системой из кэша раньше, чем соответствующие им записи таблицыmaster. Это не приводит к «невосстановимому backup», но после restoreпридется или добавлять недостающие master-записи, или удалять«осиротевшие» detail-записи (в зависимости от сложности триггеров,обрабатывающих вставку в master или удаление в detail. Возможно, такие триггерына время ремонта данных нужно будет отключить).
Также, в подобной ситуации, при restore отремонтированной базы данныхмогут оказаться неактивными индексы по Foreign Key соответствующих связейmaster-detail. Активировать их можно после упомянутых вставок или удаленийmaster/detail, путем установки rdb$indices.rdb$index_inactive в 0.
7. Стихийные и техногенные бедствия
Шторм, землетрясение, воры, пожар, прорыв водопровода — всё это приводитк потере всех носителей данных, расположенных на определённой территории.Данная причина потери данных бывает очень редко, но она имеет место.
Единственный способ защиты от стихийных бедствий — держать частьрезервных копий в другом помещении.
8. Вредоносные программы
В эту категорию входит случайно занесённое ПО, которое намеренно портитинформацию — (вирусы, черви, «троянские кони»). Иногда факт зараженияобнаруживается, когда немалая часть информации искажена или уничтожена.
Решением этой проблемы будет:
· установка антивирусных программ на рабочие станции. Простейшиеантивирусные меры — отключение автозагрузки, изоляция локальной сети от Интернета,и т. д.;
· обеспечение централизованного обновления: первая копия антивирусаполучает обновления прямо из Интернета, а другие копии настроены на папку, кудапервая загружает обновления; также можно настроить прокси-сервер таким образом,чтобы обновления кешировались (это всё меры для уменьшения трафика);
· иметь копии в таком месте, до которого вирус не доберётся —выделенный сервер или съёмные носители;
Если копирование идёт на сервер: обеспечить защиту сервера от вирусов(либо установить антивирус, либо использовать ОС, для которой вероятностьзаражения мала). Хранить версии достаточной давности, чтобы существовала копия,не контактировавшая с заражённым компьютером.
Если копирование идёт на съёмные носители: часть носителей хранить (бездописывания на них) достаточно долго, чтобы существовала копия, неконтактировавшая с заражённым компьютером.
9. Человеческий фактор
Намеренное или ненамеренное уничтожение важной информации — человеком,специально написанной вредоносной программой или сбойным ПО.
Тщательно расставляются права на все ресурсы, чтобы другие пользователине могли модифицировать чужие файлы. Исключение делается для системногоадминистратора, который должен обладать всеми правами на всё, чтобы бытьспособным исправить ошибки пользователей, программ и т.д.
Обеспечить работающую систему резервного копирования — то есть, систему,которой люди реально пользуются и которая достаточно устойчива к ошибкамоператора. Если пользователь не пользуется системой резервного копирования, всяответственность за сохранность ложится на него.
Хранить версии достаточной давности, чтобы при обнаружении испорченныхданных файл можно было восстановить.
Перед переустановкой ОС следует обязательно копировать всё содержимоераздела, на которой будет установлена ОС, на сервер, на другой раздел или на CD/ DVD.
Оперативно обновлять ПО, которое заподозрено в потере данных.
2.Восстановление баз данных на примере SQLServer 2005 2.1 Основные возможности восстановления баз данных SQL Server 2005
Прежде чем рассматривать процедуру восстановления баз данных SQL Server,уточним значение нескольких терминов используемых в SQL Server.
Restore. С точки зрения SQL Server, этоттермин можно перевести как «восстановление с носителя». Чаще всеговосстановлением с носителя приходится заниматься в ситуациях, когда база данныхповреждена физически или нужно исправить большую ошибку пользователя. Нередкоею пользуются для создания тестовой базы для проверки критических обновленийили учебы. Во время этого процесса производится перенос данных из резервнойкопии на сервер базы данных.
Recovery. Его можно перевести как«восстановление работоспособности». Во время процедуры recoveryустраняются все проблемы, которые могут быть с базой данных (например,возникшие из-за незавершенных транзакций), и база данных открывается длядоступа пользователей. Процедура recovery должна быть произведена послевосстановления с носителя — restore, однако она запускается и в другихситуациях. Например, если работа сервера был завершена некорректно (например,пропало питание), то эта процедура вернет все базы данных в работоспособноесостояние.
Failure (сбой) обычно означает сбой вработе базы данных, например, появились ошибки на диске, на котором быларасположена база данных. Операционная система и программные файлы сервера приэтом остались в рабочем состоянии, и вам нужно произвести восстановление толькобазы данных.
Disaster (катастрофа) означаеткатастрофический отказ сервера, например, из-за скачка напряжения, пожара,затопления и т. п. При восстановлении в случае такого катастрофического отказавам придется вначале установить операционную систему и программное обеспечениеSQL Server, а потом уже производить восстановление рабочих баз данных.
Общий план восстановления обычно выглядит следующим образом:
1. Вначале производится процедура restore — необходимая информациявосстанавливается с носителя. Вы можете восстановить только полную резервнуюкопию, а уже после этого произвести восстановление разностной резервной копии ирезервных копий журналов транзакций. Официальное название этого этапа — фазакопирования данных (data copy phase).
2. Если производится также восстановление журналов транзакций, тоследующим действием SQL Server записывает в базу данных всю информацию озавершенных транзакциях из журнала транзакций. Эта операция называется rollforward (завершение). Сам этап называется фазой повтора (redo phase), а обапервых этапа вместе — этап завершения (roll forward step).
3. Только в редакции SQL Server 2005 Enterprise Edition пользователямоткрывается доступ к базе данных. Открытие доступа на этом этапе — это новаявозможность SQL Server 2005. Она имеет свое название — fast recovery (быстроевосстановление). Если же пользователь попытается обратиться к данным,измененным незавершенными транзакциями, то доступ ему будет закрыт за счетмеханизма блокировок.
4. Затем SQL Server обнаруживает в журнале все незавершенные транзакции иотменяет их. Эта операция называется rollback — откат транзакций, а сам этап называетсяэтапом отката (rollback phase).
5. После этого к базе данных открывается доступ в обычном режиме во всехверсиях SQL Server.
Отметим еще несколько моментов, связанных с процессом восстановления SQLServer 2005:
· для восстановления вы можете использовать не только резервныекопии, которые были созданы в версии SQL Server 2005, но и те, которые былисозданы на версиях 7.0 и 2000. Обновление до версии 2005 произойдетавтоматически. Конечно, такую возможность следует рассматривать как еще одинвариант обновления баз данных;
· создатели SQL Server 2005 активно рекламируют новую возможность —восстановление на открытой базе данных. На самом деле такое восстановлениеможно производить только тогда, когда в базе данных несколько файловых групп, ивосстанавливаемая файловая группа находится в автономном режиме (offline).Поэтому на самом деле пользователи работать с восстанавливаемыми данными,конечно, не смогут;
· в SQL Server 2005 восстановление полнотекстовых индексовпроизводится вместе с базами данных;
· информация о восстановлении, как и информация о резервномкопировании, записывается в служебные таблицы базы данных msdb. Используютсятаблицы restorehistory, restorefile и restorefilegroup. 2.2 Подготовка к восстановлению
Перед восстановлением потребуется произвести некоторые подготовительныедействия.
Первое, что нужно сделать, — это запретить пользователям доступ к базеданных, подлежащей восстановлению. Это можно сделать разными способами:
· для большинства баз данных достаточно установить для параметра Restrict Access(Ограничить доступ) свойств базы данных значение Restricted.Если же пользователи вашей базы данных могут подключаться с правами dbo, то для этого параметра можно установить значение Single;
· если на сервере имеется только одна рабочая база данных, то лучшепросто на время восстановления отключить сетевой доступ к SQL Server. Для этого можно, например,на время восстановления отключить протокол TCP/IP в контейнере SQL Server 2005 Network Configuration в SQL Server Configuration Manager.
Если к базе данных в настоящий момент подключены пользователи, то ихсоединения придется закрыть.
Может случиться так, что база данных повреждена настолько сильно, чтоизменить ее свойства не удается. Она при этом может находиться в состоянии suspect (подозрительное) или в автономном режиме offline (информацию о состоянии можно просмотреть, например,из контейнера Datаbases в Management Studio).Если база данных находится в автономном режиме, то запустить ее восстановлениевам не удастся. В этой ситуации самый простой выход — отсоединить (detach) поврежденную базу данных и произвести восстановлениес резервной копии так, как будто эта база данных отсутствует на сервере вообще.Отметим, что для того, чтобы отсоединить базу данных, помеченную какподозрительная (suspect), ее необходимо вначалеперевести в состояние «экстренной необходимости» (emergency)- ALTER DATABASE db1 SET emergency.
Если база данных находится в рабочем режиме, а время у вас есть, толучше, конечно, подстраховаться, создав еще одну, самую свежую резервную копиюэтой базы данных и журнала транзакций (или только журнала транзакций взависимости от ситуации).
После того, как доступ пользователей к базе данных закрыт, рекомендуетсяпроверить заголовки ваших резервных копий. Для этого можно использоватьследующие команды:
· RESTORE FILELISTONLY — возвращает информацию о списке файлов ижурналов транзакций, которые помещены в данную резервную копию. Эта информацияберется из таблицы backupfile базы данных msdb;
· RESTORE HEADERONLY — возвращает информацию об имени резервной копии,ее типе, описании, времени создания и времени устаревания и т. п… Этаинформация берется из таблицы backupset базы данных msdb;
· RESTORE LABELONLY — выводит служебную информацию о метке носителя. Восновном метка нужна для картриджей стриммеров, но может применяться и дляфайлов. Информация берется, в том числе, и из таблицы backupmediasetбазы данных msdb.
Пример выполнения команды на просмотр информации о резервной копии можетвыглядеть так:
· RESTORE FILELISTONLY FROM backupdevice1;
· Конечно, вы можете обратиться к таблицам с историей резервногокопирования в базе данных msdb и напрямую. 2.3 Проведение восстановления
После того, как подготовка завершена, можно приступать к самомувосстановлению. Запустить восстановление можно при помощи графическогоинтерфейса Management Studio (контекстное меню Restore Database для контейнера Databases или контекстное меню Tasks| Restore для контейнера базы данных) или при помощикоманды RESTORE. Как обычно, опишем возможности,которые представляет графический интерфейс, и приведем информацию о техпараметрах команды RESTORE, которым они соответствуют.
Destination to restore… To database (Назначение восстановления… в базу данных) —это, конечно, имя восстанавливаемой базы данных. Обратите внимание, что вместовыбора базы данных из списка вы можете ввести свое имя. В этом случае изрезервной копии на сервере будет создана новая база данных. В некоторых случаяхможет быть удобно восстановить копию существующей базы данных под другимименем, а затем при необходимости старую базу данных удалить, а восстановленнуюпереименовать, присвоив ей старое название.
Команда на восстановление базы данных в самом простом варианте можетвыглядеть так:
RESTORE DATABASE db2 FROM DISK = 'D:\SQLBackups\BackupFile1.bak'
При этом резервная копия вполне могла быть создана для базы данных db1, а не db2;
To a point of time (Намомент времени) — позволяет задать восстановление на определенный момент времени.Обычно используется только в ситуации, когда пользователь совершил ошибку(например, удалил важные данные) и вы знаете примерно, когда это произошло.Используется только при восстановлении журналов транзакций. Этот переключательсоответствует параметру STOPAT команды RESTORE, например, WITH STOPAT = '01/06/2006 12:14:24'. Длякоманды RESTORE можно указать еще два параметра:
1. восстановление на метку транзакции. Обычно метка транзакцииприменяется перед выполнением рискованных операций (применение исправлений отразработчиков, очистка или массовая загрузка данных и т. п.). Создать меткутранзакции можно очень просто:
BEGIN TRAN mark1 WITH MARK;
COMMIT TRAN;
Для восстановления потребуется использовать параметр WITH STOPATMARK = 'mark1',чтобы остановиться точно на этой метке или WITH STOPBEFOREMARK = 'mark1'для остановки точно перед этой меткой;
2. восстановление на номер последовательности в журнале транзакций (log sequence number, LSN).Номер LSN есть у каждой операции, которая зафиксированав журнале транзакций. К сожалению, стандартными средствами просмотреть журналтранзакций и найти LSN для транзакции, с которойначались проблемы, невозможно. Для этой цели придется использовать утилитытретьих фирм, например, Lumigent Log Explorer.После того, как номер LSN найден, можно использовать теже параметры STOPATMARK и STOPBEFOREMARK,но синтаксис будет немного другим, например:
RESTORE LOG db1 FROM DISK ='D:\SQLBackups\BackupFile1.bak' WITH STOPATMARK = 'lsn:120';
From database (Из базы данных) — дляобнаружения резервных копий будет использоваться история резервного копированияиз таблиц базы данных msdb. В списке можно выбрать нетолько текущую базу данных, но и другие базы данных, которые есть на этомсервере;
From device (Из устройства) — вампотребуется указать местонахождение резервной копии явно. Эта возможностьиспользуется в тех ситуациях, когда вам нужно восстановить базу данных надругой сервер или местонахождение резервной копии изменилось. В любом случаевам потребуется выбрать логическое устройство резервного копирования, картриджстриммера или файл на диске. Еще одна возможность (доступная только в Enterprise Editionи только при полном восстановлении базы данных) — использовать в качествеисточника снимок базы данных (databasesnapshot);
Select the backup sets to restore(Выбрать резервную копию для восстановления) — в этом списке вам потребуетсяустановить флажки напротив тех резервных копий, которые вы планируетевосстановить. Обратите внимание, что флажки можно поставить напротив несколькихрезервных копий. В этом случае для каждой выбранной резервной копии будетвыполнена отдельная команда RESTORE.
При помощи этого же списка можно получить множество дополнительнойинформации о восстанавливаемых резервных копиях (если прокрутить список вправо):о времени резервного копирования, о размере резервной копии, о пользователе,которые производил это копирование, и т.п.
Дополнительные и очень важные параметры восстановления представлены навкладке Options окна восстановления базы данных Management Studio:
Overwrite the existing database (Перезаписыватьсуществующую базу данных) — установленный флажок позволяет перезаписатьсуществующую базу данных. Фактически он отменяет проверки, которые призваны недопустить потери данных в случае ошибочного восстановления. Таких проверокпредусмотрено три:
· запрещено восстанавливать резервную копию чужой базы данных насервер, если под этим именем на сервере есть своя база данных;
· запрещено перезаписывать файлы, которые относятся к базам данных,находящимся в автономном режиме (offline), и, кромеэтого, вообще любые файлы, которые не относятся к SQL Server;
· запрещено производить восстановление базы данных, если на нейосталась часть журнала транзакций, резервное копирование которой еще непроизводилось (tail-log). Этоновая проверка, которая появилась только в SQL Server 2005.
Чтобы эти проверки отменить, нужно установить указанный флажок илииспользовать параметр WITH REPLACE в команде RESTORE;
Preserve the replication settings (Сохранитьнастройки репликации) — сохранить настройки репликации при восстановлении.Соответствует параметру KEEP_REPLICATIONкоманды RESTORE. Обычно используется только тогда,когда база данных одновременно участвует и в репликации, и в автоматическойдоставке журналов (log shipping).
Prompt before restoring each backup (Выводить приглашение перед каждымвосстановлением) — выводить приглашение перед восстановлением каждой следующейрезервной копии из выбранного вами списка. Обычно этот параметр используетсятолько тогда, когда каждая копия лежит на своем картридже стриммера, и вамнужно их менять. Этот параметр можно настроить только на графическом экране Management Studio,поскольку в коде Transact-SQLдля восстановления каждой резервной копии вам придется использовать своюсобственную команду RESTORE;
Restrict access to the restored database(Ограничить доступ к восстанавливаемой базе данных) — после восстановлениядоступ будет открыт только членам роли базы данных db_owner и членам серверных ролей dbcreatorи sysadmin. Этот параметр обычно применяется в техслучаях, когда после восстановления базы данных вам необходимо произвестидополнительные проверки или внести исправления. Ему соответствует параметркоманды RESTORE WITH RESTRICTED_USER;
Restore the database files as (Восстановить файлы базыданных как) — очень важный параметр, который позволяет определить новый путьдля восстанавливаемых файлов баз данных. Без него не обойтись, например, в техситуациях, когда вы восстанавливаете базу данных на другой сервер, на которомконфигурация дисков выглядит по-другому. Этому флажку в команде RESTORE соответствует параметр MOVE,например:
RESTORE DATABASE db1 FROM DISK = 'D:\SQLbackups\BackupFile1.bak' WITH MOVE 'db1' TO'D:\db1.mdf',MOVE 'db1_log'TO 'D:\db1_log.mdf';
Здесь db1 и db1_log — это логические названия файлов базы данных и журналатранзакций соответственно, а 'D:\db1.mdf' и 'D:\db1_log.mdf' — это новые места дляфайлов, которые будут восстановлены с резервной копии;
Recovery state (Состояние восстановления) — еще один важнейшийпараметр, который определяет, будет ли база данных открыта для пользователейпосле окончания восстановления с носителя. В вашем распоряжении три варианта:
1. WITH RECOVERY— восстановление в обычном режиме. После окончания восстановления начнетсяпроцедура RECOVERY, все незавершенные транзакции будутотменены, и в итоге база данных будет открыта для пользователей. Этот параметриспользуется по умолчанию;
2. WITH NORECOVERY— после окончания процесса восстановления с носителя процедура RECOVERY не начнется. Базы данных останется в нерабочемсостоянии восстановления. Этот параметр используется тогда, когда послевосстановления резервной копии вы хотите восстановить дополнительные копии,например, после восстановления полной резервной копии восстановить резервную копиюжурнала транзакций;
3. WITH STANDBY— процедура RECOVERY начнется, но вся информация о всехотмененных незавершенных транзакциях будет записана в файл отмены (его нужнобудет указать). В результате пользователи смогут обращаться к восстановленнойбазе данных для чтения (например, для создания отчетов), но в то же времясохраняется возможность применения следующих резервных копий журналовтранзакций. Такое решение используется обычно только при примененииавтоматической доставки журналов на резервный сервер (log shipping).
Как и в случае с командой BACKUP, некоторыевозможности команды RESTORE доступны только из кода Transact-SQL. Про некоторые из них(например, про возможность восстановления до метки транзакции или LSN) уже рассказано. Далее представлено еще несколькопараметров, которые нельзя выбрать при помощи графического интерфейса:
PAGE — этот параметр позволяет указатьопределенные страницы в базе данных, которые будут восстанавливаться. Эта новаявозможность SQL Server 2005, в предыдущих версиях ее не было.
CHECKSUM | NOCHECKSUM— позволяет включить или отключить проверку контрольных сумм привосстановлении. По умолчанию такая проверка производится, а в случае выявлениярасхождений восстановление прекращается и выдается сообщение об ошибке;
CONTINUE_AFTER_ERROR | STOP_ON_ERROR — будет лиостановлено восстановление в случае обнаружения ошибок в контрольной сумме. Поумолчанию установлен параметр STOP_ON_ERROR;
MEDIANAME — позволяет указать имяносителя, с которого производится восстановление. Используется только длядополнительных проверок;
MEDIAPASSWORD и PASSWORD— при помощи этих параметров вам потребуется указать пароли для носителя ирезервной копии соответственно, которые были использованы при резервномкопировании. Эти параметры также следует отнести к категории дополнительныхпроверок. Если вы производите восстановление резервной копии на другой сервер(по отношению к тому, на котором была создана резервная копия), то парольуказывать не нужно;
PARTIAL — определяет, что в ходе данногосеанса восстановления будет производиться восстановление только одной файловойгруппы (если резервное копирование производилось по файловым группам).Процедура восстановления базы данных по частям (т. е. по файловым группам)называется piecemeal restore;
RESTART — позволяетпродолжить операцию восстановления с того момента, когда она была прервана(например, необходимо вставить следующий картридж в стриммер);
REWIND | NOREWIND— производить ли после окончания восстановления перемотку ленты в картридже илинет. По умолчанию используется значение REWIND, т. е.производить;
STATS — так же, как и для команды BACKUP, этот параметр определяет частоту появленияинформационных сообщений. По умолчанию информация о ходе восстановлениявыводится после восстановления приблизительно каждых 10% резервной копии;
UNLOAD | NOUNLOAD— выгружать картридж из стриммера после окончания восстановления или нет. Поумолчанию используется значение UNLOAD, т. е.выгружать. UNLOAD включает в себя также и перемоткуленты на начало, поэтому вместе с параметром REWINDиспользоваться не может.
2.4 Специальныеситуации восстановления
Во всех предыдущих версиях SQL Server можно было выполнять восстановление базы данных,только отключив от нее всех пользователей. В SQL Server 2005 появилась новаявозможность — восстановление на работающей базе данных. Другое название такоготипа восстановления — оперативное восстановление (online restore).
Конечно, на практике обойтись совсем без ограничения доступапользователей не удастся. При восстановлении на работающей базе данных вам влюбом случае придется перевести в автономный режим (offline)тот файл или файловую группу, восстановление которого вы производите в данныймомент. Остальные файлы или файловые группы могут оставаться в рабочем режиме.
Для восстановления на открытой базе данных предусмотрены и другиеограничения:
· резервное копирование на работающей базе данных можетиспользоваться только для баз данных, которые работают в режиме восстановления Full или Bulk-logged;
· оперативное восстановление первого файла базы данных илипервичной файловой группы (в которых находятся системные таблицы и картаразмещения данных) производить нельзя.
Если это возможно, SQL Server автоматически применяет режим оперативноговосстановления при восстановлении отдельных файлов, файловых групп и страничномвосстановлении (но не при обычном восстановлении всей базы данных). Если выхотите запретить применение оперативного восстановления и производитьвосстановление файлов, файловых групп и отдельных страниц в обычном автономномрежиме, то можно перед восстановлением выполнить команду BACKUP LOG WITH NORECOVERY.Эта команда, которая обычно применяется только при использовании автоматическойдоставки журналов (log shipping), позволяет создать резервную копию журналатранзакций и перевести базу данных в специальное состояние RESTORING.В этом состоянии доступ к базе данных пользователей будет закрыт, авосстановление будет производиться только в автономном режиме.
Синтаксис команд для выполнения оперативного восстановления ничем неотличается от обычного. Например, чтобы в оперативном режиме восстановить файл db1file2, уже переведенный вавтономный режим, можно использовать следующие команды:
RESTORE DATABASE db1 FILE = 'db1file2' FROM DISK ='D:\SQLBackups\BackupFile1.bak' WITH NORECOVERY;
RESTORE LOG db1 FROM DISK ='D:\SQLBackups\BackupLogFile1.bak';
Еще одна новая возможность SQL Server 2005, связанная с восстановлением, — восстановлениеотдельных страниц данных (page restore). Теперь в некоторых ситуациях можно вместовосстановления всей базы данных или каких-то файлов, ограничитьсявосстановлением лишь отдельных страниц. Это позволит:
· сэкономить время;
· произвести восстановление в оперативном режиме, без отключенияпользователей от базы данных. Недоступными для пользователей будут тольковосстанавливаемые страницы.
Чаще всего ошибки на страницах баз данных возникают из-за сбоев дисковили дисковых контроллеров. Поэтому перед таким восстановлением лучше убедиться,что с дисковой подсистемой сервера у вас все в порядке.
Восстановление отдельных страниц базы данных можно производить только присоблюдении следующих условий:
· вы используете редакцию Enterprise Edition;
· восстанавливаемые страницы не относятся к журналу транзакций, кслужебным страницам базы данных и к полнотекстовым каталогам;
· база данных работает в режиме Full или Bulk-logged;
· файловые группы, к которым относятся восстанавливаемые страницы,доступны и на чтение, и на запись.
Порядок действий восстановления отдельных страниц базы данных обычнотакой:
1. Вначале вы обнаруживаете, что некоторые страницы в базе данныхповреждены. Такую информацию можно получить при просмотре журналов событий SQL Server,при помощи команд DBCC (например, DBCC CHECKDB) и просто при помощи анализасообщений, которые возвращаются клиентскому приложению. Сам SQL Server выявляет поврежденныестраницы при помощи анализа контрольных сумм или контрольных бит.
2. Перед восстановлением вам нужно получить информацию о номерахповрежденных страниц и номерах файлов, в которых эти страницы находятся. Этаинформация хранится в таблице suspect_pagesбазы данных msdb (она заносится в эту таблицуавтоматически). Номера страниц находятся в столбце page_id, а номера файлов — в столбце file_id. Надо отметить, что в таблице suspect_pages не может быть более 1000 записей. По достижении этогопредела запись в таблицу просто прекращается. Поэтому рекомендуется в случаефизического повреждения баз данных после восстановления очистить эту таблицу.
3. Затем запускаете команду на восстановление базы данных, например:
RESTORE DATABASE db1 PAGE = '1:51, 1:52, 1:55' FROM DISK= 'D:\SQLBackups\BackupFile1.bak';
По умолчанию восстановление запускается в оперативном режиме, безотключения пользователей от базы данных. Больше 1000 поврежденных страницвосстанавливать нельзя.
В некоторых ситуациях может потребоваться произвести восстановлениесистемной базы данных master, в которой хранитсяслужебная информация всего сервера (например, информация о логинах,пользовательских базах данных, настройках сервера и т. п.).
Перед тем, как производить восстановление базы данных master,подумайте об альтернативных возможностях. Если пострадала не только эта базаданных, но и пользовательские базы данных, то возможно легче и надежнее будетпросто переустановить весь сервер, а затем восстановить пользовательские базыданных с резервных копий. Если повреждена база данных master,а пользовательские базы данных не пострадали, то можно думать о том, чтобыпереустановить сервер или перестроить базу данных master,а пользовательские базы данных присоединить. Такой вариант будет наиболеенадежным.
Восстановление базы данных master отличается отвосстановления обычных баз данных некоторыми особенностями:
· производить восстановление базы данных masterможно только после перезапуска сервера в однопользовательском режиме. Прощевсего сделать это, запустив SQL Server из командной строки. Для этого нужно перейти вкаталог, в котором находится файл sqlservr.exe (по умолчанию это C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn), а затем выполнитькоманду: sqlservr.exe -m
· если база данных master повреждена, тосервер вполне может не запуститься. В этом случае, чтобы все-таки можно былозапустить сервер и произвести процедуру восстановления, нужно перестроить базуданных master. При перестроении база данных master возвращается к своему исходному состоянию (когдасервер был только что установлен). В предыдущих версиях SQL Server для перестроения базы данных master использовалась специальная утилита rebuildm.В SQL Server2005 для этой цели используется программа установки SQL Server;
· для базы данных master доступен толькоодин тип резервного копирования — полное резервное копирование всей базыданных. Поэтому восстановить вы можете только всю базу данных masterцеликом. Резервное копирование и восстановление журналов транзакций, а такжелюбые другие операции восстановления (файлов, файловых групп, отдельных страници т. п.) для этой базы данных не предусмотрены;
· после восстановления базы данных masterсервер автоматически перезагрузится.
После того, как восстановление базы данных masterзавершится, очень рекомендуется проверить, не возникло ли каких-то проблем на SQL Server.Могут обнаружится проблемы:
· с логинами. Для проверки можно использовать хранимую процедуру sp_validatelogins;
· с пользователями баз данных. Проверку можно произвести при помощикоманды: sp_change_users_login @Action= 'Report';
· со списком баз данных на сервере. Если какой-то базы данных всписке нет, но файлы ее остались на диске, эту базу данных можно зановоприсоединить к серверу.
Если вы произвели перестроение базы данных master,то после завершения восстановления этой базы данных обязательно нужнопроизвести восстановление баз данных model и msdb. В остальном, резервное копирование и восстановлениеэтих баз производится так же, как и пользовательских.
Произвести резервное копирование базы данных tempdbневозможно. Поскольку эта база данных создается заново при каждом запуске SQL Server,то восстанавливать ее не нужно.
Заключение
Процесс восстановления данных — важнейшая операции в SQL Server.Восстановить данные не так сложно, как представлялось раньше, особенно спомощью графического интерфейса утилиты Enterprise Manager. Затруднениевызывает только восстановление поврежденной базы данных master.
Делая резервные копии и тестируя каждую создаваемую резервную копию ивосстановленную базу данных, мы избегаем частых потерь данных и сбоев.
Резервное копирование необходимо для возможности быстрого и недорогоговосстановления информации в случае поломки рабочей копии базы по какой-либопричине.
В заключении своей работы хочется привести первый закон Чизхолма, которыйдоказывает актуальность данной работы:
Все, что может испортиться, портится.
Все, что не может испортиться, портится тоже.
Списоклитературы
1. Ковязин А.Н., Востриков С.М. «Мир Interbase», М.: Кудиц-Образ,2002г.
2. Крис Касперски «Восстановление данных. Практическое руководство» Спб.:БХВ-Петербург, 2007г.
3. Леонов Василий. «Восстановление данных». М.: Эксмо, 2009 г.
4. Михеев Ростислав «MS SQL Server 2005 для администраторов». Спб.:БХВ-Петербург, 2007г.
5. Уильям Р. Станек «Microsoft SQLServer 2005. Справочник администратора». М.: Русская Редакция, 2008 г.