(Возврат на основную страницу)
Что же на самом деле делает CHECKDB?
В очередной статье, посвященной CHECKDB, я расскажу о проверках выделения пространства для хранения данных (allocation checks), необходимых для SQL Server 2000 и 2005. Это проверка различных структур (страниц IAM, цепочек IAM, единиц выделения пространства, страниц GAM/SGAM, страниц PFS), описывающих размещение данных (страницы и экстенты) в базе данных. Я опишу процесс сбора информации из различных страниц, а потом расскажу, что представляют собой некоторые проверки.
Проверки выделения пространства выполняются очень быстро (на несколько порядков быстрее логических проверок — так быстро, что вы не успеете и глазом моргнуть), поскольку число страниц базы данных, которые требуется прочитать, очень мало (настолько мало, что… ладноладно, я умолкаю). Представим алгоритм сбора информации о размещении данных подробно.
Для каждого файла каждой онлайновой группы файлов в базе данных (кроме файлов журналов транзакций):
1. Прочитать все страницы PFS. Это дает нам битовую карту всех страниц IAM, а также еще одну, показывающую все смешанные страницы.
2. Прочитать страницы GAM. Это дает битовые карты всех выделенных экстентов.
3. Прочитать страницы SGAM. Это дает битовые карты всех смешанных экстентов, имеющих, по крайней мере, одну невыделенную страницу.
4. Прочитать страницы DIFF_MAP. Страница «разностной битовой карты» (differential bitmap) показывает, какие экстенты из интервала GAM были изменены с момента последнего полного или разностного резервного копирования. В следующий раз при выполнении разностного резервного копирования потребуется создать резервные копии лишь экстентов, помеченных в различных страницах DIFF_MAP как модифицированные. Это позволяет просто удостовериться, что страницы можно прочитать.
5. Прочитать страницы ML_MAP. Страница minimallylogged bitmap показывает, какие экстенты из интервала GAM были изменены в bulklogged модели восстановления с момента создания последней резервной копии журнала. При резервном копировании журнала нужно создать резервные копии всех таких экстентов, чтобы гарантировать сохранение всех изменений в базе данных. При этом резервная копия журнала может стать довольно большой (хотя журнал сам по себе остается гораздо меньше). Благодаря этому убеждаемся, что страницы можно прочитать.
6. Прочитать все страницы IAM. Это дает нам:
• список всех смешанных страниц в файле и, исходя из него, список всех смешанных экстентов в файле (помните, что первая страница IAM в цепочке IAM/единице выделения пространства содержит массив, способный вместить до 8 смешанных страниц для представляемого ей объекта/индекса/раздела);
• список всех действительных страниц IAM в файле;
• список всех выделенных специализированных (dedicated) экстентов в файле;
• информацию о ссылках для цепочек IAM.
7. После всех проведенных с каждым файлом операций прочитать метаданные Storage Engine. Это дает нам:
• информацию о корне каждой цепочки IAM. Каждая строка в скрытой таблице метаданных sys.allocation_units содержит идентификатор первой страницы IAM в цепочке IAM для единицы выделения пространства;
• информацию о цепочках IAM, ожидающих в данный момент отсроченного удаления. (Это значит, что цепочка IAM с более чем 128 удаленными — путем удаления/пересоздания индекса или удаления/усечения таблицы — экстентами не освобождает свои страницы и экстенты до момента подтверждения транзакции. Тем не менее при этом цепочка IAM отсоединена от sys.allocation_units и внесена во внутреннюю очередь. Если мы не просканируем эту очередь в процессе проверки выделения пространства, мы получим разного рода противоречия между различными битовыми картами выделения пространства.)
Ну что ж, теперь у нас есть куча всяких данных о выделении пространства, и нам нужно их обработать, чтобы убедиться, что все описывающие размещение данных структуры в порядке. Предлагаю вам список совсем не утомительных проверок, выполняемых со всеми этими данными.
1. Проверить, что каждый экстент выделен в одной из следующих структур:
• в странице GAM для интервала GAM;
• или в странице SGAM для интервала GAM как неполный смешанный экстент;
• или только в одной странице IAM, покрывающей интервал GAM;
• или ни в одной из страниц, содержащих битовые карты, но все страницы экстента должны быть выделены в страницах IAM как смешанные страницы;
• в результате могут возникнуть ошибки 8903 (GAM и SGAM), 8904 (несколько IAM) или 8905 (страница отсутствует) в зависимости от комбинации битовых карт, в которых выделен экстент.
2. Проверить, что все страницы, помеченные в страницах PFS как страницы IAM, при чтении действительно представляют собой страницы IAM.
3. Проверить, что все страницы, помеченные в страницах PFS как смешанные, находятся гдето в массиве смешанных страниц на странице IAM.
4. Проверить, что каждая смешанная страница выделена только на одной странице IAM.
5. Проверить, что номера страниц IAM в цепочке IAM представляют собой монотонно возрастающую последовательность.
6. Проверить, что на первую страницу IAM в цепочке IAM есть ссылка из строки в таблице sys.allocation_units.
7. Проверить, что никакие две страницы IAM в одной цепочке IAM не соответствуют одному и тому же интервалу GAM.
8. Проверить, что все страницы IAM в цепочке IAM принадлежат одному и тому же объекту/индексу/разделу.
9. Проверить, что ссылки в цепочке IAM верны (например, нет недостающих страниц).
10. Проверить, что все страницы IAM/GAM/SGAM, соответствующие завершающему интервалу GAM в файле, не имеют помеченных как выделенные экстентов, расположенных после физического конца файла.
Любые обнаруженные при этом ошибки потребуют для исправления REPAIR_ALLOW_DATA_LOSS, а некоторые из процедур исправления очень сложны (например, выделенные в нескольких местах экстенты) — они станут темой моих будущих публикаций.
Итак, проверки выделения пространства представляют собой следующий базовый уровень поверх простейших проверок системных таблиц. Теперь мы готовы перейти к логическим проверкам.
SQL Server Storage Engine. Часть 1
В последние дни вопрос о
гарантиях несколько раз всплывал на различных форумах, а именно: «Какие гарантии
может дать мне запуск CHECKDB, сообщающий, что моя база данных чиста?». Есть
простой ответ: «Не слишком большие». Однако позвольте мне
все же объяснить...
Я поясню свою точку зрения с помощью аналогии. Представим себе Пола, который занят контролем уличного движения в департаменте полиции Сиэтла. Пол находится в комнате контроля гдето в городе, его окружает множество мониторов, подключенных к различным камерам на шоссе. Каждые полчаса он по очереди просматривает картинку с различных камер в поисках возможных проблем. К концу получасового цикла он знает, что в городе происшествий нет.
Но постойте! Разве Полу на самом деле это известно? Нет. Он знает лишь то, что в момент, когда он проверял конкретную камеру, на соответствующем участке дорожной сети все было нормально. В то самое мгновение, когда он переключается на другую камеру, на наблюдаемом предыдущей камерой участке дороги может произойти происшествие.
Надеюсь, вы начинаете понимать, что я имею в виду. Мы знаем, что со страницей базы данных все было в порядке на момент ее чтения с диска. Но после этого с ней может случиться все, что угодно, — уже в следующую миллисекунду после завершения чтения страницы.
Так что, когда CHECKDB завершает работу, не выявив ошибок, вы знаете, что набор прочитанных страниц базы данных был в порядке на момент чтения этих страниц. Вы даже не можете быть уверены, что вся база данных в норме в любой заданный момент времени, поскольку прочитать ее в одно мгновение целиком невозможно.
Некоторые читатели могут быть шокированы, но не переживайте — ведь это просто доводы здравого смысла. В сущности, никаких гарантий отсутствия повреждений в будущем нет. Вы можете сказать, что при наличии качественного, надежного и современного оборудования вероятность повреждения данных мала, но гарантировать это вы не можете.
Данная точка зрения применима и к резервному копированию. Обычная последовательность действий состоит из запуска CHECKDB, создания резервной копии, восстановления копии на другой системе и запуска CHECKDB для полученной базы данных. Да, это дает вам основания полагать, что перед созданием копии база данных была «чистой», программа резервного копирования отработала нормально и копия тоже содержит «чистую» базу данных, — но и только. В тот момент, когда завершается последний экземпляр CHECKDB, у вас все еще нет никаких гарантий. С файлом резервной копии может чтото случиться — например, двойной сбой на уровне исходной базы данных и файла копии. Разумеется, это маловероятно, но возможно, и я много раз видел, как такое происходит.
Ну что ж, теперь, когда я многих из вас напугал до смерти, коснусь вопросов, которые вы, без сомнения, себе задаете:
• Зачем вообще запускать CHECKDB?
• Что сделать, чтобы максимально приблизиться к уровню гарантии?
На первый вопрос ответить проще. Хотя вы не получаете от чистого запуска CHECKDB никаких гарантий на будущее, вы, по крайней мере, знаете, что на данный момент все в порядке и все страницы базы данных могут быть нормально прочитаны с диска. Это неплохое подтверждение того, что ваше аппаратное обеспечение справляется с нагрузкой. Как часто запускать CHECKDB (или комбинацию других команд для проверки) — более сложная проблема, заслуживающая отдельной публикации.
На второй вопрос нет простого ответа, а о высокой доступности и восстановлении после сбоев я могу с легкостью написать целую книгу. Тем не менее пока я не собираюсь этого делать, поэтому предлагаю несколько простых правил, которые сразу приходят мне в голову, — подумайте о них и поэкспериментируйте.
Настройка транзакционной репликации в SQL Server 2005
В Microsoft SQL Server можно реплицировать данные и изменения схемы с одного сервера баз данных на другой. В этой статье описано использование мастеров SQL Server 2005 и сценариев для настройки транзакционной репликации. Особо выделяются некоторые наиболее полезные новые функции в последней версии.
Репликация — это передовая функция Microsoft SQL Server, которая позволяет переносить данные и изменения схемы с одного сервера баз данных на другой. Я собираюсь показать, как настроить транзакционную репликацию в простой среде на основе SQL Server 2005. В следующих статьях этой серии мы обсудим обслуживание и решение проблем при транзакционной репликации, а также репликацию модулей кода.
Примечание Примеры в этой статье приведены в расчете на SQL Server 2005 Service Pack 1. Хотя и не планировалось проводить здесь сравнение функциональности версий 2000 и 2005, я подчеркну те улучшения в новой версии, на которые, помоему, стоит обратить внимание. Прочитав статью, вы научитесь настраивать транзакционную репликацию с помощью мастеров и сценариев. В большинстве случаев для изначальной настройки публикации и подписчиков вы будете пользоваться мастерами, однако, если вам потребуется одинаковым образом настроить публикацию в нескольких средах, вы оцените возможность применения сценариев по достоинству.
Обслуживание транзакционной репликации в SQL Server 2005
В SQL Server 2005 Microsoft представила несколько замечательных улучшений в области репликации, снимающих некоторые проблемы обслуживания, возникавшие в предыдущих версиях. Байя Павлиашвили демонстрирует шаги, необходимые для поддержки типичной публикации, и объясняет, как новые параметры доставки изменений данных могут помочь подогнать схему репликации под нужды именно ваших приложений.
Первая статья этой серии представляла собой введение в настройку репликации в SQL Server 2005. В простых сценариях настройка репликации не представляет особой сложности, однако требует обслуживания. Из этой статьи вы узнаете, как обслуживать хранимые процедуры для репликации, вносить изменения в существующие публикации и повторно инициализировать подписку в приложении к SQL Server 2005. Как и в первой статье, я подчеркну наиболее существенные различия между последней и предыдущими версиями SQL Server.
(Возврат на основную страницу)