Файл: Причины повреждений баз данных.pdf

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

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

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

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

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

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

Глава 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, но она запускается и в других ситуациях. Например, если работа сервера был завершена неправильно (к примеру, пропало питание), то эта процедура возвратит все базы данных в работоспособное состояние.