SQL Server: Советы по восстановлению после повреждений, сжатию баз данных и прочее

Вопрос. Моя стратегия запасного копирования заключается в каждодневном выполнении полной запасной копии в 1 час ночи и запасной копии журналов каждый час. Программка DBCC CHECKDB также запускается каждый денек в 4 утра. Если я приду на работу в 8 утра и обнаружу, что во время ночной проверки целостности были обнаружены значимые повреждения, каким образом я могу все вернуть без значимой утраты данных?

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

В сценарии, описанном вами, повреждение было найдено программкой DBCC CHECKDB, которая запускается после сотворения полной запасной копии базы данных, но не существует обычного метода определения того, вышло ли повреждение до либо после запасного копирования базы данных. Если повреждение вышло до запасного копирования базы данных, то запасная копия содержит покоробленную версию базы данных, и восстановление будет более сложным.

1-ое, что бы я сделал, — это вернул более свежайшую запасную копию базы данных в другом местоположении и запустил бы программку DBCC CHECKDB на нем. Если не будет найдено повреждений, вы можете произвести восстановление без утраты данных при помощи последующей процедуры:

Возьмите запасную копию «хвоста» журнальчика покоробленной базы данных (для получения более новых транзакций).
Произведите восстановление более свежайшей полной запасной копии базы данных, определив пункт WITH NORECOVERY.
Поочередно восстановите все запасные копии журналов транзакций с момента проведения полного запасного копирования базы данных и сотворения запасной копии «хвоста» журнальчик, и используя пункт WITH NORECOVERY.
Окончите последовательность восстановления при помощи команды RESTORE databasename WITH RECOVERY.

В конце концов, вы должны снова запустить программку DBCC CHECKDB для проверки наличия повреждения, провести анализ первопричин для того, чтоб узнать причину повреждения, и сделать 1-ые шаги по устранению задачи.

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

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

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

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

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

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

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

Без использования механизма управления версиями строк 1-ый запрос может возвратиться с неверными плодами, если во время выполнения запроса запущена задачка по очистке при отслеживании конфигураций. А 2-ой запрос может быть не выполнен, если некие строчки таблицы со ссылками на результаты первого запроса удалены перед выполнением второго запрос.

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

Существует два вида изоляции снимков — один обеспечивает целостность на уровне транзакций (параметр базы данных: allow_snapshot_isolation), а другой – на уровне инструкций T-SQL (параметр базы данных: read_committed_snapshot). Параметр на уровне транзакций требуется для корректного использования отслеживания конфигураций, и он просто именуется изоляция снимков.

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

Очень тщательно изоляция снимков описана в техническом документе моей супруги Кимберли Изоляция снимков.

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

Хранилище версий находится в базе данных tempdb, и это является 2-ой вероятной неувязкой, связанной с производительностью. Tempdb может стать самой загруженной базой данной на неких экземплярах SQL Server, потому что она является общей для всех подключений и баз данных. В общем, база данных tempdb может оказать сильное негативное воздействие на производительность, даже без использования управления версиями строк. Добавление управления версиями строк значит повышение нагрузки на базу данных tempdb исходя из убеждений применяемого места и операций ввода/вывода, что может существенно понизить производительность.

Более тщательно на данную тему можно прочесть в техническом документе Работа с базой данных Tempdb в SQL Server 2005. Хотя оба технических документа, упомянутых мною в этой статье, были написаны для SQL Server 2005, они подходят и для SQL Server 2008.

Вопрос. Инспектирует ли программка DBCC CHECKDB полностью все в базе данных? Кто-то произнес мне, что нет. Также, может ли отладка все поправить? Снова же, мне произнесли, что нет. Могу ли я сделать что-то еще, если программка DBCC CHECKDB не является всесторонней?

Ответ. И да, и нет! Программка DBCC CHECKDB является всесторонним набором проверки целостности, и набор выполняемых проверок вырастает от версии к версии. Вы правы, существует вещи, которые она не инспектирует. Все просто.

Ниже представлено все, что она делает:

Проверка системных каталогов на целостность
Проверка метаданных размещения на целостность
Проверка всех таблиц юзеров на целостность

Более подробное описание проверок выходят за рамки обсуждения данного вопроса (но вы сможете отыскать дополнительную информацию в моем блоге либо в книжке «Внутренняя структура SQL Server 2008″), но любая страничка базы данных передается в память и проверяется. Эта программка увидит повреждения, вызванные сбоями в подсистеме ввода/вывода (примерно 99.99% всех повреждений происходят по этой причине).

Два более узнаваемых элемента, которые не проверяются ни в какой версии SQL Server — это содержимое столбцов и статистика индексных ключей, которые хранятся в базе данных, хотя данная функция, может быть, будет добавлена в будущих выпусках, также реальность ограничений (к примеру, ограничения наружного ключа в таблицах). Реальность ограничений можно проверить при помощи команды DBCC CHECKCONSTRAINTS раздельно от программки DBCC CHECKDB, и, практически, если вы обязаны запустить операцию отладки в базе данных, содержащей ограничения, хорошо будет позднее проверить ограничения, потому что средства отладки не берут во внимание ограничения и могут по ошибке сделать их неправильными. Все это описано в электрической документации.

Система отладки не может поправить все. Существует ряд повреждений, которые нереально поправить с гарантией в течение разумного периода времени. Перечень таких повреждений маленькой и описан в моем блоге CHECKDB под хоть каким углом: Может ли программка CHECKDB все поправить? К примеру, просмотрите страничку повреждения в системном каталоге — единственным средством отладки является удаление странички. Но что если на данной страничке хранятся метаданные для неких пользовательских таблиц в базе данных? Удаление данной странички, непременно, удалит и эти пользовательские таблицы, потому отладка тут невозможна.

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

Программка DBCC CHECKDB имеет довольно способностей для обнаружения повреждений, и она должна временами запускаться, как часть стратегии по обслуживанию базы данных (поглядите мой блог Значимость постоянного выполнения проверок на целостность) для того, чтоб отыскать повреждения так стремительно, как это только может быть. Нет средства лучше для этой работы, но вы сможете прирастить эффективность программки DBCC CHECKDB, убедившись в том, что контрольные суммы страничек активированы на всех базах данных. Это позволит серверу SQL Server обнаруживать мельчайшие конфигурации на страничке базы данных за пределами памяти сервера SQL Server.

Вопрос. Я запутался в вопросе сжатия базы данных. В одной статье я прочел, что сжатие файлов базы данных — это отлично, в другой — это плохо. То же самое происходит, когда я пробую отыскать информацию о сжатии файлов журнальчика. Каковой ваш ответ?

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

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

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

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

Людям рекомендуют (либо они решают) произвести сжатие файлов данных для освобождения места. Может случиться так, что задание ведения индексов может вызвать повышение файлов данных либо переполнение диска, что приведет к естественному желанию высвободить это «неиспользуемое» место. Но очень возможно, что данное место пригодится еще, и лучше бросить свободное место, доступное для файлов данных, ежели повсевременно создавать сжатие и автоматическое повышение файлов.

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

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

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

Выяснить больше о журнальчике транзакций можно в статье » Осознание ведения журнальчика и восстановления», которую я опубликовал в февральском номере журнальчика. Также в блоге имеется запись с обсуждением управления размером журнальчика транзакций — смотрите статью Значимость правильного управления размером журнальчика транзакций.

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

Пол С. Рэндал (Paul S. Randal) является руководящим директором SQLskills.com и владельцем звания MVP по SQL Server. Он работал в группе разработчиков обработчика хранилищ SQL Server в Microsoft с 1999 по 2007 год. Пол написал DBCC CHECKDB/repair для SQL Server 2005 и был ответственным за разработку базисного механизма хранилищ при разработке SQL Server 2008. Пол, будучи спецом по аварийному восстановлению, высочайшей доступности и обслуживанию баз данных, часто делает презентации на конференциях. Он ведет блог по адресу SQLskills.com/blogs/paul, либо вы сможете зайти в его чат Twitter на Twitter.com/PaulRandal.

Связанный контент

Главные сведения о запасных копиях SQL Server
Ведение журнальчика и восстановление в SQL Server
SQL Server 2008: расширенное устранение проблем при помощи расширенных событий

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.