Вопрос. Моя стратегия резервного копирования заключается в ежедневном выполнении полной резервной копии в 1 час ночи и резервной копии журналов каждый час. Программа DBCC CHECKDB также запускается каждый день в 4 утра. Если я приду на работу в 8 утра и обнаружу, что во время ночной проверки целостности были обнаружены значительные повреждения, каким образом я могу все восстановить без значительной потери данных?
Ответ. Это зависит от того, когда произошло повреждение, что было повреждено, и какие резервные копии у вас имеются. В идеале у вас должен быть заранее разработанный план аварийного восстановления, который бы провел вас через все следующие этапы, но я полагаю, что это гипотетический вопрос.
В сценарии, описанном вами, повреждение было обнаружено программой DBCC CHECKDB, которая запускается после создания полной резервной копии базы данных, но не существует простого способа определения того, произошло ли повреждение до или после резервного копирования базы данных. Если повреждение произошло до резервного копирования базы данных, то резервная копия содержит поврежденную версию базы данных, и восстановление будет более сложным.
Первое, что бы я сделал, - это восстановил наиболее свежую резервную копию базы данных в другом местоположении и запустил бы программу DBCC CHECKDB на нем. Если не будет обнаружено повреждений, вы сможете произвести восстановление без потери данных с помощью следующей процедуры:
- Возьмите резервную копию "хвоста" журнала поврежденной базы данных (для получения наиболее свежих транзакций).
- Произведите восстановление наиболее свежей полной резервной копии базы данных, определив пункт WITH NORECOVERY.
- Последовательно восстановите все резервные копии журналов транзакций с момента проведения полного резервного копирования базы данных и создания резервной копии "хвоста" журнал, и используя пункт WITH NORECOVERY.
- Завершите последовательность восстановления с помощью команды RESTORE databasename WITH RECOVERY.
Наконец, вы должны еще раз запустить программу DBCC CHECKDB для проверки наличия повреждения, провести анализ первопричин для того, чтобы выяснить причину повреждения, и предпринять первые шаги по устранению проблемы.
В случае наличия повреждения после проведения описанной выше последовательности восстановления, значит, повреждены резервные копии журналов транзакций, или, возможно, было что-то повреждено в памяти, а затем было включено в журнал транзакций. В этом случае вам придется выполнить восстановление на момент времени, чтобы найти время возникновения повреждения, и приостановить восстановление перед этим моментом. Данная процедура выходит за рамки данной статьи, но хорошо описана в электронной документации.
Если наиболее свежая резервная копия не содержит повреждения, вам придется выполнить данную процедуру, но начать ее следует со следующей полной резервной копии базы данных. Это предполагает наличие данной копии со всеми промежуточными резервными копиями журнала.
Альтернативная стратегия (которую вам, возможно, придется использовать, чтобы выполнить требование о наибольшем допустимом значении времени простоя - или RTO) может заключаться в удалении поврежденных данных вручную или с помощью функции восстановления в программе DBCC CHECKDB, и последующей попытке частичного восстановления из более позднего набора резервных копий.
Восстановление после повреждения иногда может быть очень простой, а иногда и очень сложной задачей, в зависимости от того, что пошло не так и какие опции доступны вам. Я рассмотрю данные вопросы в нескольких статьях, которые выдут в следующих месяцах.
Вопрос. Наша группа разработчиков собирается создать решение с функцией отслеживания изменений сервера SQL Server 2008. Из документации видно, что нам нужно активировать изоляцию снимков в используемой базе данных - я беспокоюсь о влиянии на производительность. Вы можете дать совет по этому поводу?
Ответ. Я рассказывал об отслеживании изменений в номере журнала за ноябрь 2008 года (Отслеживание изменений в корпоративной базе данных), но вам нужно активировать управление версиями строк. Это объясняется тем, что механизм извлечения измененных данных выглядит следующим образом:
- Запрос системы отслеживания изменений на обнаружение таблиц, которые были изменены.
- Запрос к таблице на получение измененных строк.
Без использования механизма управления версиями строк первый запрос может вернуться с неправильными результатами, если во время выполнения запроса запущена задача по чистке при отслеживании изменений. А второй запрос может быть не выполнен, если некоторые строки таблицы со ссылками на результаты первого запроса удалены перед выполнением второго запрос.
Одним способом обеспечения стабилизации является блокировка данных об отслеживании изменений и необходимых таблиц пользователя, но это приведет к низкому уровню параллелизма (из-за блокировки) и уменьшению производительности. Другим способом обеспечения стабилизации является использование изоляции снимков.
Существует два вида изоляции снимков - один обеспечивает целостность на уровне транзакций (параметр базы данных: allow_snapshot_isolation), а другой - на уровне инструкций T-SQL (параметр базы данных: read_committed_snapshot). Параметр на уровне транзакций требуется для корректного использования отслеживания изменений, и он просто называется изоляция снимков .
Изоляция снимков поддерживает версии записей таблиц таким образом, что если, например, запускается явная транзакция, транзакция гарантированно получает согласованный вид базы данных на момент времени, наряду с точкой времени, с которой началась транзакция. Для использования механизма отслеживания изменений, два описанных выше запроса должны быть вставлены в одну явную транзакцию, а уровень изоляции должен быть установлен на снимок; данное сочетание гарантирует целостность.
Очень подробно изоляция снимков описана в техническом документе моей жены Кимберли Изоляция снимков.
Существует две возможных проблемы, связанных с производительностью, при использовании изоляции снимков. Первая заключается в том, что все обновления всех таблиц в базе данных должны генерировать версии записей при их изменении - даже если версия никогда не используется. Версия записи перед изменением должна копироваться в хранилище версий, а новая запись должна иметь ссылку на предыдущую запись - на случай того, если другая транзакция начнется до того, как данная транзакция закончится и для нее понадобится корректная версия записи. Это увеличит нагрузку во время проведения всех операций по обновлению.
Хранилище версий находится в базе данных tempdb, и это является второй возможной проблемой, связанной с производительностью. 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.