Причины повреждений баз данных

Содержание:

Введение

Установлено, собственно большая часть фирм, переживших крупную необратимую утрату корпоративных данных, заканчивают свое существование на протяжении 3 лет в последствии этого инцидента. Мысль о возможной катастрофе малоприятна для ИТ- и бизнес-менеджеров, потому они часто не принимают серьезных предупредительных мер. Как не прискорбно, это грубая истина жизни. И тут под "вежливыми мерами" ни под каким видом невозможно разуметь "покупку техники brand-name", ибо "брэнды" также ломаются, время от времени даже чащечем "самосборные машины". Поэтому "предупредительные меры" - это не только качественное "железо", но и планирование резервного копирования данных.

Актуальность моего исследования определила цель и задачи работы:

Цель исследования – рассмотреть методы восстановления баз данных

Для достижения цели необходимо решить следующие задачи:

1. На основе анализа зарубежной и отечественной литературы, монографических источников исследовать методы восстановления баз данных
2. Выявить причины, при которых базу данных необходимо восстанавливать
3. Провести анализ основных возможностей восстановления
4. Рассмотреть на примере SQL Server 2014 восстановление базы данных
5. На основе проведенного исследования сделать выводы и дать рекомендации по работе

Для раскрытия поставленной цели и задач определена следующая структура исследования: работа состоит из введения, двух глав, заключения и списка использованной литературы. Названия глав отображают их содержание.

Глава 1. Причины повреждений баз данных

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

1. Отключение питания сервера.

Самый нередкий случай повреждения базы данных это отключение питания на сервере. Такие ситуации необходимо пробовать предотвращать, используя аппаратные средства (UPS, RAID-контроллеры с батарейками).

Существует два режима записи страниц - синхронный и асинхронный. Синхронная запись значит, что модифицированные страницы базы данных не будут кэшироваться операционной системой, а будут записываться конкретно на диск при выталкивании страниц из кэша на запись (на Windows это в буквальном смысле отсутствие флага lazy write при открытии файла БД). Это усугубляет производительность, потому большая часть людей выключают forced writes. В данном случае модифицированные страницы находятся в кэше операционной системы до того времени, пока операционная система не решит записать их на диск.

В неких случаях при непрерывной работе с БД операционная система не сбрасывает модифицированные страницы на диск до того времени, пока все юзеры не отсоединятся от базы данных. При выключении питания в этом случае повреждения базы данных могут быть наивысшими. В свою очередь повреждения в этом случае происходят от "недозаписи" информации. Это куда наименее грустный случай, чем "перезапись" информации случайными данными. Но, на Windows было найдено, что если у базы данных установлено Forced Write = Off, то при определенных критериях модифицированные страницы БД могли неделями не попадать в БД, и оставаться в кэше операционной системы. При всем этом, в случае сбоя сервера (либо отключения питания), пропадало неограниченное количество конфигураций в БД (а база могла смотреться вообщем неповрежденной). Другими словами, БД вроде бы оказывалась "неизменяемой" в течение долгого времени.

2. Недостатки оборудования

Память. Самый нередкий недостаток - сбои памяти (RAM). Разумеется, при использовании серверов "собственной сборки" приобретается память подешевле, что приводит к подходящим результатам. Лучше для сервера получать и материнскую плату и память с поддержкой ECC. Сбои памяти могут привести к довольно томным последствиям. Сервер не только лишь "пропускает" страницы базы данных через память, да и кэширует их в памяти. Контрольные суммы страниц, даже если б они и были, не посодействуют когда сервер будет записывать страницу на диск через сбойный участок памяти. В неприятном случае данные пришлось бы перечитывать, что очень серьезно усугубило бы производительность. Сбои памяти еще плохи тем, что в этом случае покоробленными обычно оказываются и база данных и её копия, если копия употребляется в качестве "резвой запасной копии" (т.к. запись на диск идет из одних и тех же участков памяти).^[1]

Диски. Ранее, лет 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, чтобы вспомогательная копия информационной базы сделалсамой актуальной в случае сбоя и повреждения БД.^[2]

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 будут записи, ссылающиеся на несуществующих клиентов. Таким макаром БД как бы будет отремонтирована, но логическая целостность данных Оперативно обновлять ПО, которое заподозрено в потере данных.Глава 2. Восстановление баз данных на примере SQL Server 2014

2.1 Основные возможности восстановления баз данных SQL Server 2014

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

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

Recovery. Его можно перевести как "восстановление работоспособности". Во время процедуры recovery устраняются все трудности, которые могут быть с базой данных (к примеру, возникшие из-за незавершенных транзакций), и база данных раскрывается для доступа юзеров. Процедура recovery должна быть произведена после восстановления с носителя - restore, но она запускается и в других ситуациях. Например, если работа сервера был завершена неправильно (к примеру, пропало питание), то эта процедура возвратит все базы данных в работоспособное состояние.

Failure (сбой) обычно значит сбой в работе базы данных, к примеру, появились ошибки на диске, на котором была размещена база данных. Операционная система и программные файлы сервера при всем этом остались в рабочем состоянии, и для вас необходимо произвести восстановление только базы данных.^[3]

Disaster (трагедия) значит трагический отказ сервера, к примеру, из-за скачка напряжения, пожара, затопления и т. п. При восстановлении в случае такового чертовского отказа для вас придется сначала установить операционную систему и программное обеспечение SQL Server, а позже уже создавать восстановление рабочих баз данных.^[4]

Общий план восстановления обычно смотрится последующим образом:

1. Сначала делается процедура restore - нужная информация восстанавливается с носителя. Вы сможете вернуть только полную запасную копию, а уже после чего произвести восстановление разностной запасной копии и запасных копий журналов транзакций. Официальное заглавие этого шага - фаза копирования данных (data copy phase).

2. Если делается также восстановление журналов транзакций, то последующим действием SQL Server записывает в базу данных всю информацию о завершенных транзакциях из журнальчика транзакций. Данная операция называется roll forward (окончание). Сам шаг называется фазой повтора (redo phase), а оба первых шага совместно - шаг окончания (roll forward step).

3. Исключительно в редакции SQL Server 2014 Enterprise Edition юзерам раскрывается доступ к базе данных. Открытие доступа на этом шаге - это новенькая возможность SQL Server 2014. Она имеет свое заглавие - fast recovery (резвое восстановление). Если же юзер попробует обратиться к данным, модифицированным незавершенными транзакциями, то доступ ему будет закрыт за счёт механизма блокировок.

4. Потом SQL Server обнаруживает в журнальчике все незавершенные транзакции и отменяет их. Данная операция называется rollback - откат транзакций, а сам шаг называется шагом отката (rollback phase).

5. После чего к базе данных раскрывается доступ в обыкновенном режиме во всех версиях SQL Server.

Отметим еще несколько моментов, связанных с процессом восстановления SQL Server 2014:

· для восстановления вы сможете использовать не только лишь запасные копии, которые были сделаны в версии SQL Server 2014, да и те, которые были сделаны на версиях 7.0 и 2000. Обновление до версии 2014 произойдет автоматом. Естественно, такую возможность следует рассматривать как очередной вариант обновления баз данных;

· создатели SQL Server 2014 интенсивно рекламируют новейшую возможность - восстановление на открытой базе данных. По сути такое восстановление можно создавать только тогда, когда в базе данных несколько файловых групп, и восстанавливаемая файловая группа находится в автономном режиме (offline). Потому по сути юзеры работать с восстанавливаемыми данными, естественно, не сумеют;

· в SQL Server 2014 восстановление полнотекстовых индексов делается совместно с базами данных;

· информация о восстановлении, как и информация о запасном копировании, записывается в служебные таблицы базы данных msdb. Употребляются таблицы restorehistory, restorefile и restorefilegroup.^[5]

2.2 Подготовка к восстановлению

Перед восстановлением будет необходимо произвести некие предварительные деяния.

1-ое, что необходимо сделать, - это запретить пользователям доступ к информационной базе, подлежащей возобновлению. Это возможно устроить разными способами:

· для основной массы баз данных очень установить для параметра Restrict Access (Ограничить доступ) характеристик информационной базы значение Restricted. В случае если пользователи вашей информационной базы имеют все шансы подключаться с правами dbo, то чтобы достичь желаемого результата параметра возможно установить значение Single;

· коль скоро на сервере наличествует лишь 1 рабочая информационная база, то гораздо лучше просто на время восстановления отключитьсетевой доступ к SQL Server. Для этого можно, к примкеру, на время восстановления отключить протокол TCP/IP в контейнере SQL Server 2014 Network Configuration в SQL Server Configuration Manager.^[6]

Если к базе данных в реальный момент подключены юзеры, то их соединения придется закрыть.

Может случиться так, что база данных повреждена так очень, что поменять её характеристики не удается. Она при всем этом может находиться в состоянии suspect (подозрительное) либо в автономном режиме offline (информацию о состоянии можно просмотреть, к примеру, из контейнера Datаbases в Management Studio). Если база данных находится в автономном режиме, то запустить её восстановление для вас не получится. В этой ситуации самый обычный выход - отсоединить (detach) покоробленную базу данных и произвести восстановление с запасной копии так, будто бы эта база данных отсутствует на сервере вообщем. Отметим, что для того, чтоб отсоединить базу данных, помеченную как подозрительная (suspect), её необходимо сначала перевести в состояние "критической необходимости" (emergency) - ALTER DATABASE db1 SET emergency.

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

Пример выполнения команды на просмотр инфы о запасной копии может смотреться так:

· RESTORE FILELISTONLY FROM backupdevice1;

· Естественно, вы сможете обратиться к таблицам с историей запасного копирования в базе данных msdb и впрямую.

2.3 Проведение восстановления

После того, как подготовка завершена, можно приступать к самому восстановлению. Запустить восстановление можно с помощью графического интерфейса Management Studio (контекстное меню Restore Database для контейнера Databases либо контекстное меню Tasks | Restore для контейнера базы данных) либо с помощью команды RESTORE. Как обычно, опишем способности, которые представляет графический интерфейс, и приведем информацию о тех параметрах команды RESTORE, которым они соответствуют.

Destination to restore ... To database (Предназначение восстановления ... в базу данных) - это, естественно, имя восстанавливаемой базы данных. Направьте внимание, что заместо выбора базы данных из перечня вы сможете ввести свое имя. В данном случае из запасной копии на сервере будет сотворена новенькая база данных. В неких случаях может быть комфортно вернуть копию имеющейся базы данных под другим именованием, а потом по мере надобности старенькую базу данных удалить, а восстановленную переименовать, присвоив ей старенькое заглавие.^[7]

Команда на восстановление базы данных в самом ординарном варианте может смотреться так:

RESTORE DATABASE db2 FROM DISK = "D:\SQLBackups\BackupFile1.bak"

При всем этом запасная копия полностью могла быть предназначена для базы данных db1, а не db2;

To a point of time (На момент времени) - позволяет задать восстановление на определенный момент времени. Обычно употребляется исключительно в ситуации, когда юзер сделал ошибку (к примеру, удалил принципиальные данные) и вы понимаете приблизительно, когда это вышло. Употребляется только при восстановлении журналов транзакций.

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 и только при полном восстановлении базы данных) - использовать в качестве источника снимок базы данных (database snapshot);

Select the backup sets to restore (Избрать запасную копию для восстановления) - в этом перечне для вас будет необходимо установить флажки напротив тех запасных копий, которые вы планируете вернуть. Направьте внимание, что флажки можно поставить напротив нескольких запасных копий. В данном случае для каждой избранной запасной копии будет выполнена отдельная команда RESTORE.

С помощью этого же перечня можно получить огромное количество дополнительной инфы о восстанавливаемых запасных копиях (если прокрутить перечень на право): о времени запасного копирования, о размере запасной копии, о юзере, которые создавал это копирование, и т.п.

Дополнительные и очень принципиальные характеристики восстановления представлены на вкладке Options окна восстановления базы данных Management Studio:

Overwrite the existing database (Перезаписывать существующую базу данных) - установленный флаг позволяет перезаписать существующую базу данных. Практически он отменяет проверки, которые призваны не допустить утраты данных в случае неверного восстановления. Таких проверок предвидено три:

· запрещено восстанавливать запасную копию чужой базы данных на сервер, если под этим именованием на сервере есть своя база данных;

· запрещено перезаписывать файлы, которые относятся к базам данных, находящимся в автономном режиме (offline), и, не считая этого, вообщем любые файлы, которые не относятся к SQL Server;

· запрещено создавать восстановление базы данных, если на ней осталась часть журнальчика транзакций, запасное копирование которой еще не выполнялось (tail-log). Это новенькая проверка, которая появилась исключительно в SQL Server 2014.

Чтоб эти проверки отменить, необходимо установить обозначенный флаг либо использовать параметр WITH REPLACE в команде RESTORE;

Preserve the replication settings (Сохранить опции репликации) - сохранить опции репликации при восстановлении. Соответствует параметру KEEP_REPLICATION команды RESTORE. Обычно употребляется только тогда, когда база данных сразу участвует и в репликации, и в автоматической доставке журналов (log shipping).

Prompt before restoring each backup (Выводить приглашение перед каждым восстановлением) - выводить приглашение перед восстановлением каждой последующей запасной копии из избранного вами перечня. Обычно данный параметр употребляется только тогда, когда любая копия лежит на собственном картридже стриммера, и для вас необходимо их поменять.

Recovery state (Состояние восстановления) - очередной важный параметр, который определяет, будет ли база данных открыта для юзеров после окончания восстановления с носителя. В вашем распоряжении три варианта:

1. WITH RECOVERY - восстановление в обыкновенном режиме. После окончания восстановления начнется процедура RECOVERY, все незавершенные транзакции будут отменены, и в конечном итоге база данных будет открыта для юзеров. Данный параметр употребляется по дефлоту;

2. WITH NORECOVERY - после окончания процесса восстановления с носителя процедура RECOVERY не начнется. Базы данных остается в нерабочем состоянии восстановления. Данный параметр употребляется тогда, когда после восстановления запасной копии вы желаете вернуть дополнительные копии, к примеру, после восстановления полной запасной копии вернуть запасную копию журнальчика транзакций;

3. WITH STANDBY - процедура RECOVERY начнется, но вся информация о всех отмененных незавершенных транзакциях будет записана в файл отмены (его необходимо будет указать). В итоге юзеры сумеют обращаться к восстановленной базе данных для чтения (к примеру, для сотворения отчетов), но в то же время сохраняется возможность внедрения последующих запасных копий журналов транзакций. Такое решение употребляется обычно только при применении автоматической доставки журналов на запасный сервер (log shipping).

Как и в случае с командой BACKUP, некие способности команды RESTORE доступны только из кода Transact-SQL. Про некие из их (к примеру, про возможность восстановления до метки транзакции либо LSN) уже поведано. Дальше представлено еще несколько характеристик, которые нельзя избрать с помощью графического интерфейса:

PAGE - данный параметр позволяет указать определенные страницы в базе данных, которые будут восстанавливаться. Данная новенькая возможность SQL Server 2014, в прошлых версиях её не было.

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 употребляться не может.^[8]

2.4 Особые ситуации восстановления

Во всех прошлых версиях SQL Server можно было делать восстановление базы данных, только отключив от нее всех юзеров. В SQL Server 2014 появилась новенькая возможность - восстановление на работающей базе данных. Другое заглавие такового типа восстановления - оперативное восстановление (online restore).

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

Для восстановления на открытой базе данных предусмотрены и другие ограничения:

· запасное копирование на работающей базе данных может употребляться только для баз данных, которые работают в режиме восстановления Full либо Bulk-logged;

· оперативное восстановление первого файла базы данных либо первичной файловой группы (в каких находятся системные таблицы и карта размещения данных) создавать нельзя.

Если это может быть, SQL Server автоматом применяет режим оперативного восстановления при восстановлении отдельных файлов, файловых групп и страничном восстановлении (но не при обыкновенном восстановлении всей базы данных). Если вы желаете запретить применение оперативного восстановления и создавать восстановление файлов, файловых групп и отдельных страниц в обыкновенном автономном режиме, то можно перед восстановлением выполнить команду BACKUP LOG WITH NORECOVERY. Данная команда, которая обычно применяется только при использовании автоматической доставки журналов (log shipping), позволяет сделать запасную копию журнальчика транзакций и перевести базу данных в особое состояние RESTORING. В этом состоянии доступ к базе данных юзеров будет закрыт, а восстановление будет выполняться исключительно в автономном режиме.

Синтаксис команд для выполнения оперативного восстановления ничем не отличается от обыденного. Например, чтоб в оперативном режиме вернуть файл db1file2, уже переведенный в автономный режим, можно использовать последующие команды:

RESTORE DATABASE db1 FILE = "db1file2" ^[9]FROM DISK = "D:\SQLBackups\BackupFile1.bak" WITH NORECOVERY;

RESTORE LOG db1 FROM DISK = "D:\SQLBackups\BackupLogFile1.bak";

Еще одна новенькая возможность SQL Server 2014, связанная с восстановлением, - восстановление отдельных страниц данных (page restore). Сейчас в неких ситуациях можно заместо восстановления всей базы данных либо каких-либо файлов, ограничиться восстановлением только отдельных страниц. Это дозволит:

· сберечь время;

· произвести восстановление в оперативном режиме, без отключения юзеров от базы данных. Труднодоступными для юзеров будут только восстанавливаемые страницы.

В большинстве случаев ошибки на страничках баз данных появляются из-за сбоев дисков либо дисковых контроллеров. Потому перед таким восстановлением лучше убедиться, что с дисковой подсистемой сервера у вас все в порядке.

Восстановление отдельных страниц базы данных можно создавать только при соблюдении последующих критерий:

· вы используете редакцию Enterprise Edition;

· восстанавливаемые страницы не относятся к журнальчику транзакций, к служебным страничкам базы данных и к полнотекстовым каталогам;

· база данных работает в режиме Full либо Bulk-logged;

· файловые группы, к которым относятся восстанавливаемые страницы, доступны и на чтение, и на запись.

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

Перед тем, как создавать восстановление базы данных 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 Server 2014 для этой цели употребляется программка установки 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.

Актуальность данной работы высока, т.к техника в век информационных технологий является важным аспектом любой сфере и у неё есть свойства давать сбои поэтому восстановления данных является актуальной темой для исследования.

Процесс восстановления утерянных данных был рассмотрен на примере SQL Server 2014 которая идеально для этого подходит и выявлены закономерности в восстановлении данных на основе которых были сделаны выводы

Делая резервные копии и тестируя каждую создаваемую резервную копию и восстановленную базу данных, мы избегаем частых потерь данных и сбоев.

Резервное копирование необходимо для возможности быстрого и недорогого восстановления информации в случае поломки рабочей копии базы по какой-либо причине.

В заключении своей работы хочется привести первый закон Чизхолма, который доказывает актуальность данной работы:

Все, что может испортиться, портится.

Все, что не может испортиться, портится тоже.

Список литературы

1. Леонов Василий.., Востриков С.М. "Мир Interbase", М.: Кудиц-Образ, 2002г.
2. Крис Касперски «Восстановление данных. Практическое руководство» Спб.: БХВ-Петербург, 2007г.
3. Ковязин А.Н., «Восстановление данных». М.: Эксмо, 2009 г.
4. MicrosoftCorporation. Компьютерные сети. Учебный курс / Пер. с англ. – М.: Русская редакция, 2009.- 696 с.
5. Нессер Д.ДЖ. Оптимизация и поиск неисправностей в сетях. – К.: Диалектика, 1996.- 384 с.
6. Анализ локальных сетей NetWare/Пер. с англ. – М.: ЛОРИ, 1995.- 596 с.
7. Носенко А.А. Сетевые методы планирования НИР и ОКР. Методическое пособие по дипломному проектированию. – Мн.: МРТИ, 1992.- 45 с.
8. Шаниров Р.С. и др. Охрана труда. Методические указания по дипломному проектированию. – Мн.: МРТИ, 1990.- 36 с.
9. Сибаров Ю.Г., Сколотнёв Н.Н.Востановления данных. – М.: Радио и связь, 2010- 199 с.
10. Павлов С.П. и др. Охрана труда в радиоэлектронной промышленности. – М.: Радио и связь, 1999.- 200 с.
11. Байченко Е.В. и.др. Локальные вычислительные сети. – М.: Радио и связь, 1999.- 304 с.
12. Челлис Д. И др. Основы построения сетей / Пер. с англ. – М.:ЛОРИ, 1997.- 323 с.
13. Русли Д., Мэксвин Д. Сети WindowsNT4.0./ К.:Диалектика,1997.- 597 с.
14. Малаян К.Р. Безопасность жизнедеятельности. Безопасность при работе с компьютером: Учеб. пособие.–СПб.:Изд-воСПбГТУ,2001.124с

Интернет-ресурсы

1. 14.Интернет магазин компьютерной техники [Электронный ресурс]: URL:http://www.dns-shop.ru/(дата обращения 19.12.2014 г.).
2. 15.Официальный сайт компании Cisco [Электронный ресурс]: URL:http://www.cisco.com/web/RU/index.html/(дата обращения 19.12.2014 г.).
3. 16. Интернет магазин всех видов кабелей [Электронный ресурс]: URL:http://www.allcables.ru/(дата обращения 19.12.2014 г.).

1. MicrosoftCorporation. Компьютерные сети. Учебный курс / Пер. с англ. – М.: Русская редакция, 2009 с 211 ↑

2. MicrosoftCorporation. Компьютерные сети. Учебный курс / Пер. с англ. – М.: Русская редакция, 2009 ↑

3. MicrosoftCorporation. Компьютерные сети. Учебный курс / Пер. с англ. – М.: Русская редакция, 2009 ↑

4. Уильям Р. Станек «Microsoft SQL Server 2014. Справочник администратора». М.: Русская Редакция, 2015 г. ↑

5. Крис Касперски «Восстановление данных. Практическое руководство» Спб.: БХВ-Петербург, 2007г ↑

6. Уильям Р. Станек «Microsoft SQL Server 2014. Справочник администратора». М.: Русская Редакция, 2015 г. ↑

7. Крис Касперски «Восстановление данных. Практическое руководство» Спб.: БХВ-Петербург, 2007г ↑

8. Крис Касперски «Восстановление данных. Практическое руководство» Спб.: БХВ-Петербург, 2007г ↑

9. Уильям Р. Станек «Microsoft SQL Server 2014. Справочник администратора». М.: Русская Редакция, 2015 г. ↑