SQL.RU
 client/server technologies
 Главная | Документация | Статьи | Книги | Форум | Блоги | Опросы | Гостевая | Рассылка | Работа | Поиск | FAQ |

Основы ввода-вывода Microsoft SQL Server. Часть 2

ПУБЛИКАЦИИ  

По материалам статьи Bob Dorr: Microsoft SQL Server I/O Basics. Chapter 2

В статье рассмотрены особенности операций ввода-вывода, выполняемых SQL Server, и расширения возможностей этих операций, добавленные в SQL Server 2000 Service Pack 4 и SQL Server 2005.

Экспертиза:

    Mike Zwilling (SQL Server Development Manager)
    Paul Randal (SQL Server Lead Program Manager)
    Mirek Sztajno (SQL Server Program Manager)
    Steve Schmidt (SQL Server Software Development Engineer)
    Peter Byrne (SQL Server Software Development Engineer)
    Eric Christensen (SQL Server Software Development Engineer)
    Ryan Stonecipher (SQL Server Software Development Engineer)
    George Reynya (SQL Server Software Development Engineer)
    Kevin Farlee (SQL Server Program Manager)
    Burzin Patel (SQL Server Program Manager)
    Wei Xiao (SQL Server Technical Lead)
    Kathy Lu (SQL Server Engine Test)
    Bob Ward (SQL Server Senior Escalation Engineer)
    Suresh Kandoth (SQL Server Escalation Engineer)

Содержание

Введение

Microsoft® ™ 2005 является продолжателем традиций и вводит новшества, расширяющие возможности ввода-вывода SQL Server и повышающие его надежность. Эти новшества добавили несколько новых терминов, элементов дизайна и алгоритмов.
Опубликованный ранее документ Основы ввод-вывод в SQL Server 2000 является основой для понимания той информации, которая содержится в настоящей статье. Прежде чем Вы приступите к прочтению представленного ниже материала, прочитайте расположенный по ссылке документ.
Во время инсталляции SQL Server 2005, администраторы баз данных обнаружат, что подсистема ввода-вывода SQL Server стала значительно прозрачней и понятней. Основным фокусом дизайна ввода-вывода в SQL Server 2005 была абсолютная стабильность работы и целостность данных, в той части, которая относилась к подсистемам/каналам ввода-вывода. Новые возможности и расширения обеспечивают повышение прозрачности взаимодействия подсистем и расширение функциональности. Теперь можно выполнять инсталляцию SQL Server 2005 с очень высокой долей доверия к системе.
Эта статья является публичным документом и призвана познакомить читателя с новыми терминами, рассмотреть проблемы обслуживания и конфигурации, разъяснить новые сообщения об ошибках и улучшения, появившиеся в контексте прежних сообщений об ошибках, а также в статье описаны те расширения, которые были реализованы для операций ввода-вывода.
После прочтения этого документа Вы лучше поймете, что необходимо для работы SQL Server и возможности его операций ввода-вывода.

[В начало]

Термины

В этом разделе:

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

Подсистема / Путь (Subsystem / Path)

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

Контрольная сумма (Checksum)

Контрольная сумма - схема обнаружения ошибок, использующая вычисляемое числовое значение, которое можно потом использовать для проверки последовательности бит, для которых контрольная сумма вычислялась. По той же формуле осуществляется верификация последовательности бит, и если контрольная сумма совпадает, значит последовательность бит не была подвергнута изменениям.
Другими словами, одна и та же формула вычисления контрольной суммы для одного и того же набора байт может быть основой определения повреждения или нарушения исходных данных.
В качестве простого примера, возьмём 2-байтную строку "AB", и применим к ней формулу (Значение = Позиция + ASCII-код). Контрольная сумма - сумма значений.

Символ Позиция ASCII-код Итог A 1 65 66 B 2 66 68 контрольная сумма: 134

Теперь предположим, что эта строка была сохранена на диске, но когда она считывалась обратно, получилось "AC".

Символ Позиция ASCII-код Итог A 1 65 66 C 2 67 69 контрольная сумма: 135

Сравнение значений контрольной суммы показывает, что значения отличаются, и данные были повреждены или исправлены.
Понятно, что этот упрощённый пример не сработал бы, если бы строка была заменена на "BA". Однако, подпрограммы, которые в этих целях использует SQL Server, опираются на более сложные алгоритмы и способны обнаруживать изменение позиций символов, и другие подобные нарушения данных.

Повторное чтение (Read Retry)

Когда чтение с долговременного носителя возвращает ошибку, операцию чтения повторяется снова. Иногда, повторное чтение возвращает правильные данные. Такие чтения являются серьезной проблемой для подсистем ввод-вывод, к которой обращения должны обслуживаться немедленно, что необходимо для предотвращения системных проблем, обеспечения стабильности и предотвращения потери данных SQL Server. Если Вы сталкиваетесь с повторными чтениями, обратитесь за помощью к поставщику вашей системы ввода-вывода.

Аудит страниц DBCC (DBCC Page Auditing)

Аудит страницы DBCC является процессом общей проверки согласованности считываемых с диска данных, выполняемым средствами DBCC.

Время последнего обращения (Time of Last Access)

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

Неактивный Сервер (Idle Server)

Неактивный сервер - это такой режим, когда SQL Server "затихает"; приостанавливается выполнение основных задач, таких как контрольная точка и процесс отложенной записи. Приостановка возможна, когда отсутствуют пользовательские запросы, и она отменяется, когда поступает новый запрос. Это подобно операционным режимам suspend и resume, которые можно увидеть в операционной системе.

Запись с копированием / Снимки (Copy-On-Write / Snapshots)

Запись с копированием подразумевает создание копии данных до того, как в эти данные будут внесены изменения. Запись с копированием используется в SQL Server для поддержки снимков баз данных в SQL Server 2005. Перед изменением данных на странице, эта страница копируется в снимок базы данных. В результате, снимок базы содержит только оригинальные образы страниц данных, которые были изменены после создания снимка. Объединение представления страниц базы данных, которые не были изменены, и страниц данных в снимке - даёт представление данных на момент создания снимка.
Функциональность снимков баз данных на заданный момент времени и онлайновых DBCC операций появилась в SQL Server 2005. Для получения подробной информации об этой функциональности, см. Database Snapshots в SQL Server 2005 Books Online.

Разреженные файлы (Sparse Files)

Разреженные файлы предназначены для экономии дискового пространства, если в файлах большие участки не используются, т.е. имеются продолжительные разделы, заполненные нулями. Отмеченные как разреженные, файл NTFS, на самом деле, распределяют для данных только те кластеры диска, в которые приложение осуществляло запись явным образом. Те участки файла, в которые запись не осуществлялась, не будут в реальности распределены. Когда данные читаются из распределенных участков, будут возвращаться имеющиеся данные, поскольку они были сохранены. Чтение данных из нераспределенных участков будет просто возвращать нули.
Для получения дополнительной информации относительно разреженных файлов и работы с ними, см. Understanding Sparse File Sizes in Database Snapshots и Sparse Files на Microsoft Developer Network (MSDN).
Например, вполне возможно создать разреженный файл 100 GB на диске размером 20 GB. Объём дискового пространства, которое потребуется для разреженного файла, это будет сумма фактического количества бай, записанных в этот файл, а не максимальный размер файла.
SQL Server 2005 использует разреженные файлы для файлов снимков базы данных и во время выполнения онлайновых DBCC операций, и эти файлы должны размещаться на NTFS томах.

Контура (Streams)

NTFS тома предоставляют возможность иметь для файла данных один или несколько вторичных контуров к хранилищу. Эти контура являются неотъемлемой частью своего файла; если файл скопирован - то будут скопированы и все его контура. Каждый контур работает независимо, и допускает свой набор атрибут хранения данных и установки размеров.
Онлайновые проверки DBCC, выполняемые SQL Server 2005, основаны на технологии снимка базы данных, и используют переходные, вторичные контура файла для хранения моментального образа страниц данных во время работы DBCC операций.
Обратите внимание: Большинство распространённых утилит не обращаются к информации вторичного контура. Это касается и информации о размере.
Для получения более подробной информации, см.: File Streams на MSDN.

Фиксация или Закрепление (Harden or Hardening)

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

Засорение памяти (Memory Scribbler)

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

char gchArray [10]; gchArray [-1] = 'B'; -- обратное переполнение границ массива gchArray [10] = 'R'; -- переполнение границ массива

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

char * pchData = new char [10]; DELETE [] pchData; memcpy (pchData, 0, sizeof (char) * 10)); -- pchData недействителен

Память, управляемая указателем, была высвобождена после операции DELETE [], и больше не принадлежит текущей строке текста программы. Память может использоваться другими потоками, и memcpy может повредит память, которая ему не принадлежит, таким образом засоряя уже чужую память.
Причиной засорения памяти являются ошибки кодирования. Большинство таких ошибок привносят сторонние компоненты. Будьте осторожны при использовании сторонних расширенных хранимых процедур, COM объектов и связанных серверов, которые могут работать в адресном пространстве SQL Server.

[В начало]

Конфигурация и обслуживание

Этот раздел посвящён проблемам обслуживания и конфигурации, с которыми следует ознакомиться перед началом развертывания SQL Server.

В этом разделе:

[В начало]

Испытание отключением от питания

Испытание на отключение напряжения является одной из фундаментальных и критически важных задач обеспечения безопасности и целостности данных. Поскольку нагрузка, порождаемая кэшированием, дефрагментацией и другими расширяющими возможности ввода-вывода подпрограммами, существенно возросла, важно провести испытание на отключение напряжения до ввода сервера в промышленную эксплуатацию. Обязательно до начала промышленной эксплуатации нужно проверить на отказ SQL Server и все остальные системные компоненты. Многие программы успешно проходят испытание отключением питания, если они были правильно настроены. Неправильная конфигурация может привести к потере данных.
Испытание на отключение питания должно проводиться в условиях промышленной среды или очень близкой её имитации. Это относится и к программному обеспечению сторонних фирм, которое задействуется на промышленном сервере.
Ниже представлен список возможных ситуаций при отключении питания. Чтобы испытания не стали причиной поломки оборудования, удостоверьтесь, что соблюдаются стандарты и инструкции эксплуатации используемого в испытаниях электрооборудования.

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

  • Разъедините шнур питания, который подводит питание к дисковой подсистеме. Это может быть тот же тумблер, которым отключается материнская плата, или это может быть отдельный выключатель на внешней дисковой стойке.

  • Отключить внешнюю дисковую подсистему, подождать, и затем снова подключить соединительный кабель.

Во время тестирования отключения питания, выдерживайте достаточно большую задержку перед повторным включением.
Мы настоятельно рекомендуем Вам проводить соответствующее испытание на отключение питания не только для дисков с файлами резервных копий, но и для дисков с журналами транзакций и файлами баз данных. Протестируйте отключение питания по разным сценариям, это поможет Вам гарантированно обеспечить целостность данных. Ниже представлены несколько типичных сценариев отключения питания.
Установите для этих испытаний большой recovery - интервал. Несмотря на то, что это будет не совсем промышленная конфигурация, это поможет проверить настройки компонент подсистемы ввод-вывод. Мы предлагаем устанавливать с помощью sp_configure очень большое значение для recovery - интервала, например 5000.

Сценарий

Основные шаги проверки

Защита транзакций: Фиксации

  1. Выполните вставку заранее подготовленных наборов легко проверяемых данных и завершите транзакцию.

  2. Отключите питание.

  3. Перезапустите сервер.

  4. Проверьте базу средствами DBCC CHECKDB.

  5. Убедитесь, что все вставленные и зафиксированные данные присутствуют в базе.

Защита транзакций: Отмена

  1. Выполните вставку заранее подготовленных наборов легко проверяемых данных и завершите транзакцию.

  2. Создайте несколько активных, изменяющих данные транзакций, и оставьте эти транзакции не завершёнными.

  3. Инициируйте контрольную точку (CHECKPOINT) для всех тестируемых баз данных.

  4. Отключите питание.

  5. Перезапустите сервер.

  6. Проверьте базу средствами DBCC CHECKDB.

  7. Убедитесь, что все завершённые транзакции присутствуют в базе данных, а не завершённые транзакции были откачены.

Защита резервной копии

  1. Сделайте полную копию базы.

  2. Сделайте копию журнала транзакций.

  3. Запустите серию транзакций с заранее известными изменениями, удалениями и вставками данных.

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

  5. После завершения резервных копирований журнала, отключите питание.

  6. Перезапустите сервер.

  7. Проверьте базу средствами DBCC CHECKDB.

  8. Проверьте состояние данных.

  9. Восстановите резервные копии и проверьте состояние данных.

Обратите внимание, что эти испытания нужно проводить с включённой опцией сверки контрольной суммы базы данных.
Восстановите резервную копию на другом сервере, чтобы удостовериться, что ваша стратегия резервного копирования функционирует правильно. Это покажет Вам, как Вы сможете справиться с отказом сервера.
Для получения более подробной информации о вводе-выводе, и требованиях к кэшированию в SQL Server, см. следующие документы на MSDN:

[В начало]

Атомарная запись

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

[В начало]

Дефрагментация дисков

Поскольку физический доступ к данным является самой дорогостоящей частью запроса на ввод-вывод, дефрагментация может способствовать повышению производительности SQL Server и других приложений. Позиционирование связанных данных близко друг к другу уменьшает требования к операциям ввода-вывода.
Сегодня на рынке доступно много разных утилит дефрагментации. Некоторые утилиты позволяют дефрагментировать открытые файлы, хотя большинство таких утилит дефрагментируют закрытые файлы или работают лучше, когда файлы закрыты. Кроме того, некоторые утилиты имеют дополнительные, не встречающиеся у большинства утилит возможности.
При выборе утилиты дефрагментации для использования совместно с SQL Server, учитывайте, что такая утилита должна поддерживать транзакционность данных. Используйте утилиты дефрагментации, которые поддерживают следующие требования к транзакционности данных:

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

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

  • Write-Ahead Logging (WAL) - протокол упреждающего журналирования требуется для предотвращения перезаписей сектора, что позволяет предотвратить потерю данных. Утилита должна обеспечивать физическую целостность файла во время его дефрагментации. Фактически, утилита должна работать с границами секторов транзакционным способом, что бы правильно и не повреждая сохранять файлы SQL Server.

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

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

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

  • Дефрагментация открытого файла может повлиять на кэширование и упорядочение записей. Утилиты, умеющие дефрагментировать открытые файлы, используют компоненты пути ввода-вывода; эти компоненты не должны изменять порядок или иные характеристики операции записи. Если произойдут нарушения в сквозной записи (write-through) или протоколе WAL, это с высокой вероятностью приведёт к повреждению базы данных. База данных и все её файлы, как принято считать, являются единым объектом (это упоминается в множестве статей Базы Знаний, SQL Server Books Online, различных открытых документах и в разделе, посвящённом удалённому зеркалированию настоящего документа). Любая запись должна сохраняться в первоначальном порядке последовательности записи и с поддержкой сквозной записи.

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

[В начало]

Закрепление резервной копии

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

  1. Операции ввода-вывода потока резервирования были завершены, но последняя часть данных потока резервирования ещё остаётся в кэше.

  2. SQL Server решает, что данные резервной копии сохранены на долговременном носителе (закреплены), и для завершения операции резервного копирования усекает журнал транзакций.

  3. Происходит отключение питания, и оставшаяся в кэше часть данных потока резервного копирования оказывается потерянной.

  4. После последующего запуска SQL Server будет запущен механизм стартовой регенерации (recovery) банных, который успешно выполняется и не выдаёт сообщений об ошибках в базе данных.

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

Очерёдность резервного копирования будет нарушена, и администратор баз данных ничего не будет об этом знать, пока во время попытки восстановления из резервной копии из последовательности резервной копии не будет извлечён поврежденный поток. Все резервные копии журнала транзакций, выполненные после повреждения, окажутся непригодными.
Обратите внимание, что в SQL Server 2005 были внесены улучшения в возможности проверки восстановления и расширены возможности проверки контрольных сумм резервных копий, но только полное восстановление из резервной копии позволяет гарантированно проверить правильность стратегии резервного копирования. Не даёт полной гарантии и успешное выполнение сразу после создания резервной копии команды RESTORE VERIFYONLY, поскольку успешность этой операции указывает только на то, что все данные были сохранены на долговременном носителе. Присутствующие в системе кэши могут возвращать находящиеся в них данные, и поток резервного копирования какое то время может быть подвержен опасности потери данных. Желательно получить информацию у производителей кэширующих устройств, позволяющую понять границы возможностей кэша и его взаимодействие с долговременными носителями. Также, желательно иметь возможность считывать для проверки данные потоков резервного копирования непосредственно с долговременного носителя.
Процесс резервного копирования в SQL Server не выставляет флаг FILE_FLAG_WRITE_THROUGH, как это делается для файлов базы данных и журналов транзакций; вместо этого, системному уровню разрешается буферизация ввода-вывода. Для гарантии целостности данных, в конце операции резервного копирования, SQL Server использует команду программного интерфейса FlushFileBuffers, которая инициализирует сброс всех кэшированных данных на долговременный носитель, после чего файл резервной копии будет закрыт.

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

[В начало]

Размер сектора диска - 4 КБ

Современные технологии и спецификации позволяют производителям выпускать диски, которые поддерживают размеры сектора превышающий использовавшийся до сих пор 512Б формат, и который для одной 8КБ страницы данных SQL Server требовал шестнадцать секторов по 512Б. Наряду с увеличением размера сектора, у разных производителей встречаются разные размеры сектора, от 512Б до 4 КБ. Например, размеры сектора могут быть следующие: 512Б, 1КБ и 4КБ. Увеличение размера сектора и отличие его размеров у разных изготовителей дисков влияет на работу SQL Server по протоколу упреждающего журналирования (Write-Ahead-Logging, WAL), ниже представлены несколько моментов, связанных с размером сектора.

[В начало]

Перезапись сектора

Некоторые изготовители дисков в своих реализациях показывают логическое представление дисковых секторов. Это означает, что операционная система видит размер сектора равный 512Б, но на самом деле диск использует своё, логическое к физическому, отображение на сектора большего размера, которые используется для хранения на физическом уровне диска. Логическая запись сектора может использовать чтение близлежащих данных, что известно под названием: "Чтение Изменение Запись" (Read Modify Write, RWM), что подразумевает выполнение перезаписи сектора целиком, после предварительного внесения в считанную информацию необходимых корректив.
Для получения более подробной информации о логическом к физическому отображении секторов, см. Implementation Guidelines for 1K/4K Sector Sizes.
Файлы журнала транзакций SQL Server всегда пишутся с выравниванием по границам и размерам сектора. Когда небольшой логический размер сектора подменяется большим физическим размером, это провоцирует перезапись (RMW) секторов журнала транзакций, которые уже были до этого сохранены на долговременном носителе. Если в последующем во время записи случится сбой, журнал транзакций окажется поврежденным, и завершённые до этого транзакции могут оказаться потерянными. Такое состояние называют "обрыв" уже закрепленного файла журнала регистрации транзакций.

    "…SQL Server 6.x не выигрывает от частых и не больших записей в журнал транзакций. При завершении транзакции, SQL Server 6.x перезаписывает всю 2К страницу журнала целиком. Это может уменьшить размер журнала по сравнению с 512-ти Байтным выравниванием по границам сектора в SQL Server 7.0, SQL Server 2000 и SQL Server 2005. Именно уменьшение размера файла журнала непосредственно влияет на суммарную механическую эффективность использования диска. Однако, как говорилось выше, используемый в SQL Server 6.x алгоритм может повредить завершённые транзакции".

Для получения более подробной информации о перезаписи секторов, и информации о том, какие изменения были внесены в SQL Server 7.0 для предотвращения перезаписи секторов журнала транзакций, прочтите статью MSDN: SQL Server 7.0, SQL Server 2000, and SQL Server 2005 logging and data storage algorithms extend data reliability.
Использование отображения секторов, как логические к физическим, может быть опасно, и может привести к возникновению сложностей, чреватых потерей данных.

[В начало]

Выравнивание по физической границе сектора

Те реализации, в которых используется логическое представление размера сектора, усложняют обслуживание запросов ввода-вывода для SQL Server и операционной системы. Для обслуживания таких запросов, используется реальный размер сектора 4КБ и представление (логическое) размера сектора 512Б.
Файл журнала регистрации транзакций SQL Server или файлы баз данных должны создаваться с выравниванием по физической границе сектора. Однако, поскольку операционная система показывает размер сектора равный 512Б, при выравнивании, начало файла SQL Server может быть так размещено, что файл окажется не выровненным по физической границе сектора.
В представленной ниже таблице продемонстрировано, как логическое представление сектора может спровоцировать размещение файлов журнала транзакций и базы данных SQL Server без выравнивания по границам сектора. Перезапись сектора (RMW) выполняется для того, что бы управлять процессом записи данных с учётом границ.
Как показано в таблице, запись на страницу 0 файла базы данных должна затронуть сектора файлов ABC и XYZ, с которых начинается ввод - вывод, и который завершается на странице 1 файла базы данных. Производительность ввода - вывода может пострадать из-за необходимости выполнять дополнительную работу при пересечении границ секторов.

Физический сектор 4КБ

Логический сектор 512Б

Сектор №1

Файл ABC
Файл XYZ

Страница файла базы 0 - Сектор 1 из 16
Страница файла базы 0 - Сектор 2 из 16
Страница файла базы 0 - Сектор 3 из 16
Страница файла базы 0 - Сектор 4 из 16
Страница файла базы 0 - Сектор 5 из 16
Страница файла базы 0 - Сектор 6 из 16

Сектор №2

Страница файла базы 0 - Сектор 7 из 16
Страница файла базы 0 - Сектор 8 из 16
Страница файла базы 0 - Сектор 9 из 16
Страница файла базы 0 - Сектор 10 из 16
Страница файла базы 0 - Сектор 11 из 16
Страница файла базы 0 - Сектор 12 из 16
Страница файла базы 0 - Сектор 13 из 16
Страница файла базы 0 - Сектор 14 из 16

Сектор №3

Страница файла базы 0 - Сектор 15 из 16
Страница файла базы 0 - Сектор 16 из 16
Страница файла базы 1 - Сектор 1 из 16
Страница файла базы 1 - Сектор 2 из 16
Страница файла базы 1 - Сектор 3 из 16
Страница файла базы 1 - Сектор 4 из 16
Страница файла базы 1 - Сектор 5 из 16
Страница файла базы 1 - Сектор 6 из 16
 

Может показаться, что избежать проблем с выравниванием по границам сектора можно создав базу данных на недавно отформатированном диске. Ошибочность этого соображения в том, что это не даст никаких гарантий того, что будет выполнено физическое выравнивание сектора, если операционная система представляет его логическим размером сектора. Кроме того, для промышленной системы это непрактично.
Другой ложный путь обхода проблемы - использование утилит дефрагментации. Ошибка здесь в том, что утилита дефрагментации, вероятно, будет работать на основе логического, а не физического размера сектора. Хотя данные и будут выровнены лучше, очень вероятно, что их размещение с использованием логических границ сектора может привести к показанным на примере проблемам.
Однако, есть ещё один способ обхода проблемы, суть которого в копировании и восстановлении базы данных, что позволяет получить хорошее физическое выравнивание. Для того чтобы изменить физическое распределение, выполните резервное копирование базы данных, а потом её восстановите из этой копии. Пересоздание файла из копии данных может привести к более удачному выравниванию по физическим секторам или даже уменьшить логическую фрагментацию. Однако, если начало файла попадёт на не выровненный участок диска, попытка восстановления из копии может привести к тому, что и все страницы базы данных получатся не выровненными, как это было в показанном ранее примере.
Большая логическая - к - физической фрагментация может иметь такой же негативный эффект, как Max Sector Frags = Physical Sector Size / Logical Sector Size. В примере, это могло привести к соотношению секторов к 8КБ страницам данных SQL Server, как шестнадцать к одной, что подразумевает сохранение одной страницы базы данных на 16 разных секторах, и смешивание с другими данными.
В SQL Server существует возможность приращения и уменьшения файлов журналов регистрации транзакций и файлов баз данных. Это приводит тому, что дисковое пространство занимается или высвобождается, а это тоже может привести к дальнейшему увеличению логической - к - физической фрагментации.
Рассмотрим пример использования файлов, для которых включено автоматическое приращение. В этом примере, размер базы данных вначале был 10ГБ с автоприращением в 1ГБ. Первоначальное распределение этих 10ГБ было выполнено на чистый диск и позволяло всем страницам данных быть правильно выровненными по физическому размеру сектора. Однако, на том же диске хранились резервные копии (это - плохая практика) и другие файлы. При добавлении данных в базу происходит автоматическое приращение файла на 1Гб, и добавляемая часть файла попадает на ту часть диска, которая начинается на не выровненном по физическим размерам сектора месте. После этого часть файла базы данных будет выровнена, а часть окажется не выровненной по физическим границам сектора области диска.
Результатом описанной в последнем примере ситуации может стать то, что сохраненные на первых 10ГБ страниц данные могут читаться и изменяться быстрее, чем на добавленном новом куске базы данных, размером 1ГБ. Подобные проблемы очень трудно поддаются обнаружению и исправлению.

[В начало]

Выравнивание по границам для 8 КБ страниц

Размеры сектора всегда должен учитываться при выравнивании 8КБ страниц данных SQL Server. SQL Server пишет данные страницами, при этом, размер запроса ввода - вывода кратен 8КБ; физический размер сектора и само выравнивание всегда должны позволять SQL Server записывать 8КБ страницы так, чтобы они хорошо размещались в границах сектора или на нескольких секторах меньшего размера. Это позволит избежать появления оборванных страниц, перехлёста страницы данных и перезаписи секторов.
Размер сектора, равный 4КБ, предоставляет возможность SQL Server занимать под страницы данных по два физических сектора, что позволяет эффективно выравнивать границы для 8КБ страниц. Если размер сектора равен 1536Б, страницы данных не получится выровнять по границам секторов. В этом случае появятся 8КБ страницы, которые будут занимать один и тот же физический сектор. Это повышает риску нежелательной перезаписи сектора (RMW), снижает производительность базы данных и может привести к потере самих данных.

[В начало]

Большие журналы транзакций

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

WHILE(@I < 10000) BEGIN BEGIN TRAN INSERT INTO tblTest values ('A', @I) COMMIT TRAN SET @I = @I + 1 END - vs - BEGIN TRAN WHILE(@I < 10000) BEGIN INSERT INTO tblTest values ('A', @I) SET @I = @I + 1 END COMMIT TRAN

Во время исполнения первого скрипта SQL Server сделает запись в файл журнала регистрации транзакций 10000 раз, как этого требует используемая конструкция BEGIN TRAN … COMMIT TRAN. Во втором скрипте SQL Server упаковывает транзакции всех 10000 вставок в одну транзакцию и завершает все транзакции одновременно.
Использование журнала транзакций для обоих примеров даёт следующие приближения:

  • При использовании для первого примера размера сектора 4КБ, используются ~40МБ дискового пространства.

  • При использовании для первого примера размера сектора 512Б, используются ~5МБ дискового пространства.

  • При использовании для второго примера размера сектора 4КБ, используется ~1МБ дискового пространства.

  • При использовании для второго примера размера сектора 512Б, используется ~1МБ дискового пространства.

Если подсистемы ввода-вывода сообщает о том, что размер сектора больше 512Б, это означает, что размер занимаемого файлом журнала транзакций SQL Server физического места будет зависеть от коэффициента: "Rate = n / 512", где "n" - это новый размер сектора. Дизайн прикладной части может оказаться критически важным для эффективного использования занимаемого журналом места.
Обратите внимание, что нужно быть очень осторожным при увеличении длинны транзакции, поскольку это может негативно сказаться на параллелизме из-за того, что блокировки будут удерживаться до завершения обрамляющей транзакции.
Хотя база tempdb изначально не журналируется, внутренние операции, такие как распределение страниц данных, могут журналироваться. Поэтому, большие размеры сектора могут повлиять и на размер tempdb тоже.

[В начало]

Восстановление и присоединение

База данных SQL Server может быть восстановлена или присоединена на системе, у которой размер сектора меньше, чем на изначальной системе. Для гарантии целостности данных, размер большого сектора должен без остатка делиться на размер меньшего сектора. Например, если у источника размер сектора был 4КБ, а восстановление/присоединение было выполнено на системе с размером сектора 1КБ или 512Б, эти размеры делят исходный без остатка. Восстановление или присоединение на системе с меньшим размером сектора равным 1536Б не делит изначальный размер сектора без остатка и потребует немедленного выполнения операций перезаписи секторов.
В SQL Server не предусмотрена возможность динамической подгонки базы данных под сектор большего размера. SQL Server просто отказывается восстанавливать или присоединять базы данных на системах с большим, чем на источнике, размером сектора; при этом генерируется сообщение об ошибке, а сами операции восстановления или присоединения прерываются. Если бы можно было работать с базой данных на диске, отформатированном с меньшим размером сектора, чем он был изначально, это привело бы к нарушению протокола WAL, потому что изменение размера сектора не гарантирует правильного размещения записей журнала в физических размерах сектора и записи регистрации транзакций будут перезаписаны.
На момент публикации этой статьи, некоторые из имеющихся подсистем ввода-вывода сообщали о том, что размер сектора большие 512Б, но большинство таких систем этого не делали. Увеличение размера сектора является следствием появления новых технологий и требует внесения изменений в программные интерфейсы уровня операционной системы. Новые версии Microsoft ® Windows и SQL Server правильно поддерживают большие размеры сектора и учитывают динамическую подстройку размера сектора.

[В начало]

Формат работы с секторами 4 КБ на системах с меньшим размером сектора

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

[В начало]

Системные и учебные базы данныхм

В поставку SQL Server 2005 входят системные (master, model и msdb) и учебные базы данных, которые были созданы на отформатированных с размером сектора 4КБ системах, и поэтому они могут быть установлены на дисках с размером сектора до 4КБ. Системные и учебные базы данных SQL Server 2000 создавались на секторах 512Б, и поэтому их установка на дисках с большими секторами потерпит неудачу.
База данных model используется SQL Server как шаблон для создания tempdb и пользовательских баз данных. При этом используется только содержимое базы данных model, а не полный физический формат. База данных tempdb и новые пользовательские базы при создании используют тот размер сектора, который во время создания сообщает операционная система. Определение размера сектора выполняется пофайлово. Это может привести к расхождениям в размере сектора у разных файлов базы данных. Удостоверьтесь, что размеры секторов имеющихся путей ввода-вывода равны.

[В начало]

Определение отформатированного размера сектора базы данных

Выполните команду DBCC FILEHEADER ('«dbname»'), которая показывает заданный при форматировании размер сектора для каждого файла базы данных. Установленный при форматировании размер сектора в байтах показывает столбец SectorSize.

[В начало]

Какие размеры сектора поддерживает SQL Server?

В настоящее время SQL Server поддерживает следующие размеры сектора:

  • физические размеры сектора, которые делят 4КБ без остатка;

  • физические размеры сектора, которые меньше оригинального размера у базы данных; и больший, оригинальный размер сектора делится без остатка на меньший, новый размер сектора;

  • 512;

  • 1024;

  • 2048;

  • 4096.

[В начало]

Удаленное зеркальное отображение

Некоторые независимые разработчики аппаратных средств предлагают решения по удаленному зеркальному отображению (Remote Mirroring). Удаленное зеркальное отображение отслеживает запись данных и дублирует её дистанционно. Из-за расстояния между источником и зеркалом, и из-за нежелательности создания дополнительно нагрузки на систему источника, запись на зеркале происходит с задержкой, и поэтому удаленные системы зеркального отображения, как правило, работают асинхронно. Для того чтобы обезопасить использование технологии удаленного зеркального отображения обслуживаемых SQL Server данных, файлов журналов регистрации транзакций и файлов резервных копий, необходимо обеспечить исполнение очень строгих правил и протоколов.
Для получения более подробной информации о поддержке SQL Server решений по удаленному зеркальному отображению, поищите статьи на MSDN, используя следующие ключевые слова: Using Third Party Mirroring Solutions with SQL Server 2000 and 2005 User Databases.

Ниже представлено резюме по тем, не относящимся к протоколу WAL атрибутам, которые являются необходимыми для успешного развертывания удаленного зеркального отображения. Порядок записи (Write ordering): порядок записи на источнике должен быть таким же, как и на зеркале. Если порядок записи не поддерживается, будет нарушен протокол WAL, и база данных может быть повреждена.
Последовательность в группе (Consistency groups): последовательность в группе подразумевает, что все операции ввода-вывода с несколькими томами обслуживаются единым потоком ввода-вывода, с сохранением порядка запросов на запись в рамках этой группы. Без сохранения порядка записи во всей группе томов, отображение базы данных SQL Server становится не безопасно. Если каждый том может иметь независимый порядок записи, файл журнала регистрации транзакций и файлы базы данных на зеркале не будут поддерживать правильную семантику моментов времени (point-in-time), и база данных может быть повреждена.
Обратите внимание, что последовательность в группе применима также и к решениям для локального зеркального отображения.
Точки восстановления (Restore points): Ниже на примере показаны точки восстановления или ветвления для удаленной системы зеркального отображения.

Источник

Зеркало

Full Database Backup

 

Log Backup #1 (LSN 1 to 100)

 

Log Backup #2 (LSN 101 to 200)

 

Произошел отказ

 

 

Log Backup #3 (LSN 101 to 150)

 

Log Backup #4 (LSN 150 to 200)

Проблема с точкой восстановления происходит при работе с LSN 101. Если решение удаленного зеркального отражения не гарантирует немедленную доставку копий на зеркало, то, в случае отказа, некоторые операции записи могут быть потеряны. В приведённом примере, изменения для LSN с 150 по 200 сервера источника были сделаны в целях выживания во время отказа и они никогда не будут воспроизведены на зеркале. Зеркало переведено в активное состояние и поэтому потеряло данные между 150 и 200, потому что эти данные никогда зеркалу не передавались. После выполнения регенерации (recovery) база данных зеркала, с точки зрения транзакций, будет непротиворечива, но некоторые данные будут потеряны.
Файл журнала регистрации транзакций резервируется сразу после отказа, как это показано на примере. С этим связаны две серьёзные проблемы, которые требуют правильного разрешения:

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

  2. Во время восстановления, относящийся к источнику "Log Backup #2" должен считаться повреждённым. Последовательность восстановления в этом случае может быть следующей:

    1. Восстановить полную резервную копию базы данных.

    2. Восстановить "Log Backup #1".

    3. Восстановить "Log Backup #3". Если "Log Backup #2" будет восстановлен, "Log Backup #3" и "Log Backup #4" не будут восстанавливаться, потому что запись в журнале 150 - 201 на зеркале отличаются от источника, где она потеряна.

    4. Восстановить "Log Backup #4".

[В начало]

Изменения и добавления в сообщения об ошибках ввода-вывода, сделанные в Microsoft SQL Server 2005

В SQL Server 2005 существенно возросло число хранимых в системных метаданных сообщений об ошибках и информационных, контекстных сообщений, чем это было в предыдущих версиях. Эта глава посвящена наиболее существенным изменениям и добавлениям в сообщениях об ошибках вода-вывода.

В этом разделе:

[В начало]

Ошибка 823

Сообщение об ошибке 823 было разделено на два сообщения об ошибках, это было сделано для улучшения контекста. Сообщение об ошибке 823 в SQL Server 2005 говорит о проблеме при передаче ввода-вывода, а сообщение об ошибке 824 говорит о проблемах логической последовательности. Сообщение об ошибке 823 указывает на серьезную системную ошибку, при возникновении которой требуется разрешить проблемы в операционной системе.
Ниже показан пример улучшенного текста сообщения об ошибке 823:

    The operating system returned error «OS ERROR» to SQL Server during a «Read/Write» at offset «PHYSICAL OFFSET» in file «FILE NAME». Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

В SQL Server ошибка 823 происходит после того, как один из перечисленных далее запросов к программным интерфейсам возвращает ошибку операционной системы:

  • ReadFile

  • WriteFile

  • ReadFileScatter

  • WriteFileGather

  • GetOverlappedResult

Для получения дополнительной информации об ошибке 823, прочтите статью на сайте Microsoft: Error message 823 may indicate hardware problems or system problems in SQL Server.
Во время исполнения операций чтения, SQL Server 2005 может использовать повторные чтения перед тем, как произойдёт регистрация что состояния ошибки 823. Ниже в этом документе повторные чтения будут рассмотрены более подробно.

[В начало]

Ошибка 824

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

    SQL Server detected a logical consistency-based I/O error: «ERROR TYPE DESCRIPTION». It occurred during a «Read/Write» of page «PAGEID» in database ID «DBID» at offset «PHYSICAL OFFSET» in file «FILE NAME». Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Типы ошибки

Сообщение 824 содержат более подробную информацию о каждой найденной логической ошибке, как это показано в следующей таблице.

Обратите внимание: ошибка 824 указывает на серьезную проблему со стабильностью подсистемы ввода-вывода и должна быть исправлена немедленно.

Тип ошибки

Описание

Контрольная сумма
Checksum

Во время операции чтения обнаружена ошибка контрольной суммы. Контрольная сумма, хранимая на странице данных, не соответствует контрольной сумме, рассчитанной после операции чтения. Данные на странице были повреждены, и, чтобы исправить это, потребуется восстановление.
Дополнительные данные:
"incorrect checksum (expected: ##; actual: ##)"
Для получения помощи, войдите в контакт с изготовлением ваших аппаратных средств.

Оборванная страница
Torn Page

Во время операции чтения обнаружена ошибка обрыва бит. После операции чтения оказывается, что обрывки бит, указанные в заголовке страницы данных, не соответствуют обрывкам бит, хранимым на отдельных секторах. Данные на странице были повреждены, и, чтобы исправить это, потребуется восстановление.
Дополнительные данные:
"torn page (expected signature: ##; actual signature: ##)"
Для получения помощи, войдите в контакт с изготовлением ваших аппаратных средств.

Короткая передача
Short Transfer

Затребованное число байт не прочитано. Например, если запрос на чтение составлял 8КБ, но возвращено было только 4КБ данных, такое состояние помечается как ошибка короткой передачи. Это указывает на то, что файл поврежден, или в подсистеме ввода-вывода имеется серьезная проблема передачи данных на носитель или от носителя.
Дополнительные данные:
"insufficient bytes transferred"

Неверный идентификатор страницы
Bad Page Id

В заголовке страницы указан неправильный идентификатор для ожидаемой страницы. Идентификатор ожидаемой страницы рассчитывается по формуле: (id страницы = физическое смещение в файле / 8192 Байт). Если ожидаемую страницу вернуть не удаётся, инициируется ошибка неправильного идентификатора страницы. Дополнительные данные:
"incorrect pageid (expected ##:##; actual ##:##)"
Часто такое происходит когда во время чтения подсистема ввода-вывода возвращает неправильные данные. Исследования, проведённые службой поддержки Microsoft SQL Server, показывают, что обычно подсистема ввода-вывода возвращает данные по неправильному смещению в файле, или страница содержит одни нули. Для получения помощи, войдите в контакт с изготовлением ваших аппаратных средств.

Задержка восстановления
Restore Pending

Для исправления повреждённых страниц, можно воспользоваться новшеством SQL Server 2005 в редакции Enterprise Edition, который позволяет восстановить всего одну страницу. Если страница была повреждена, она помечается как плохая страница, и любая попытка обращения к ней возвращает ошибку 824. Это указывает на то, что только восстановление может исправить поврежденную страницу, после чего она может снова использоваться. Дополнительные данные:
"Database ID «DBID», Page «PAGEID» is marked RestorePending. This may indicate disk corruption. To recover from this state, perform a restore."

Чтение устаревших данных
Stale Read

Для получения более подробной информации о чтении устаревших данных, см. главу "Защита от чтения устаревших данных", ниже в этом документе. Для управления стением устаревших данных используется флаг трассировки: -T818.
Если говорить кратко, когда страница только что записалась на диск и еще не была удалена из считающейся устаревшей хеш-таблице чтений, порядковый номер журнала транзакций (LSN) в этой хеш-таблице отличается от LSN в заголовке страницы. Если они не соответствуют друг другу, страница помечен как ошибочная.
Пример сообщения:
"stale page (a page read returned a log sequence number (LSN) (##:##:##) that is older than the last one that was written (##:##:##))"

Ошибка аудита страницы
Page Audit Failure

При включённом флаге трассировки -T806, для страниц выполняется проверка DBCC, чтобы позволяет обнаружить проблемы логических последовательностей. Если выявляются проблемы, чтение считается ошибочным.
Дополнительные данные:
"audit failure (a page read from disk failed to pass basic integrity checks)"
Аудит страниц может повлиять на производительность, и должен использоваться только тогда, когда исследуется стабильность данных.

[В начало]

Ошибка 832

Сообщение об ошибке 832 возникает, когда зафиксирован сбой контрольной суммы в оперативной памяти. Более подробная информации о реализации в оперативной памяти механизма контрольных сумм будет изложена в главе о дополнительных возможностях, появившихся в Microsoft SQL Server 2005.

Ниже представлен пример текста ошибки 832.

    A page that should have been constant has changed (expected checksum: «VALUE», actual checksum: «VALUE», database «DBID», file «FILE», page «PAGE»). This usually indicates a memory failure or other hardware or OS corruption.

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

[В начало]

Ошибка 833

SQL Server 2000 с установленным SP4 и SQL Server 2005 показывают предупреждения о задержках ввода-вывода (stalled I/O), которые будут описаны ниже. Вот пример такого предупреждения 833, которое может встретиться в файле регистрации ошибок SQL Server.

    SQL Server has encountered «##» occurrence(s) of I/O requests taking longer than «##» seconds to complete on file [«FILE»] in database [«DB NAME»] («DBID»). The OS file handle is «HANDLE». The offset of the latest long I/O is: «PHYSICAL OFFSET»

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

  • Сбои в работе антивирусной защиты;

  • Перегрузка из-за компрессии;

  • Потеря сети;

  • Сбои в работе дублирующих путей ввода-вывода.

[В начало]

Дополнительные возможности, появившиеся в Microsoft SQL Server 2005

Эта глава посвящена тем дополнительным возможностям ядра SQL Server 2005, которые относятся к вводу-выводу.

В этой главе:

[В начало]

Контрольная сумма

В SQL Server 2005 появились контрольные суммы страниц данных, блоков журнала и резервных копий. Для получения более подробной информации о возможностях контрольной суммы и о способах её использования, обратитесь к разделу ALTER DATABASE статьи о PAGE_VERIFY в Документации по SQL Server 2005.
Повышение возможностей аппаратных средств наряду с всё большим распространением использования антивирусной защиты, кэширующих механизмов и других, промежуточных фильтр - драйверов, повышает сложность подсистемы ввода-вывода и увеличивает число возможных причин отказа. Microsoft SQL Server 2005 и Microsoft Exchange Server реализуют механизм контрольных сумм, позволяющий повысить защиту данных.
Алгоритм контрольной суммы, используемый SQL Server 2005, аналогичен алгоритму, используемому в Microsoft Exchange Server. В алгоритме SQL Server добавлены циклы, позволяющие обнаружить перестановки секторов.
В Microsoft Exchange Server проверка контрольной суммы была добавлена несколько лет назад, и весьма успешно. В библиотеке Microsoft Knowledge Base можно легко найти подробную информацию об ошибке 1018, которая индицирует в Exchange Server расхождение контрольной суммы. Вот один из примеров таких статей в Базе знаний Exchange Server KB151789:

    "Когда Вы запустили транзакцию в базе данных Jet, информационное хранилище или хранилище каталога запишет её в файл журнала транзакций (Edb*.log в Mdbdata или Dsadata). После этого транзакция будет передана базе данных Jet. В этот момент, ядро Jet вычисляет значение контрольной суммы для страницы, которое будет сохранено в заголовке страницы, и затем оно будет запрашиваться, когда файловая система будет записывать 4КБ страницу данных в базу на диске.

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

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

[В начало]

Запись

Страницы данных SQL Server обычно сохраняются на диске в результате исполнения контрольной точки или процесса отложенной записи.

  • SQL Server принимает решение о том, когда выполнить очередную контрольную точку, основываясь на задаваемом с помощью sp_configure параметре глобальной конфигурации "recovery interval" и на количестве используемого в тот момент места в журнале транзакций.

  • SQL Server 2005 принимает решение о необходимости записи на диск грязных страниц из кэша буферного пула, основываясь на данных о вытеснении памяти и времени последнего обращения к страницам.

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

Обратите внимание: Для базы данных model включён режим проверки контрольных сумм (аудит страниц - page audit). Поэтому все созданные в SQL Server 2005 новые базы данных будут иметь активированный режим защиты данных с помощью вычисления контрольных сумм.

[В начало]

Чтение

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

[В начало]

Расхождения контрольных сумм

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

[В начало]

Использование PAGE_VERIFY

Команда ALTER DATABASE может используется для изменения значения параметра настройки защиты страниц базы данных - PAGE_VERIFY. Для этого параметра допустимы три значения: NONE, CHECKSUM и TORN_PAGE_DETECTION. Проверка страниц задаётся на уровне базы данных. Значение этой настройки сохраняется во время записи на долговременный носитель в каждом заголовке страниц и указывает на тип защиты страницы.
Похожие действия по вычислению контрольных сумм выполняются и для операций по чтению или записи блоков журнала транзакций, если включена защита контрольной суммой. Запись и чтение журнала регистрации транзакций всегда используют бит четности (для защиты от оборванных страниц), с помощью которого можно определить неповреждённые блоки журнала. Расчет контрольных сумм блоков журнала является новой, дополнительной возможностью, и применяется только при включённой опции проверки контрольной суммы для базы данных.
Ниже представлена таблица, в которой собраны те действия, которые осуществляются в SQL Server 2005 для проверки страниц, и могут отличаться в зависимости от задаваемого на уровне базы данных значения PAGE_VERIFY, а также от значений этого параметра, которые хранятся в заголовках страниц. Некоторые из перечисленных в этой таблице действий могут показаться странными, поскольку значения состояния защиты у страницы при чтении отменяет действие текущей установки защиты на уровне базы данных. Однако, при чтении можно проверить страницу только по тем значениям, которые хранятся в заголовке страницы, поскольку установки на уровне базы данных не всегда могут быть выполнимы. Например, невозможно проверить при чтении контрольную сумму, если он не была рассчитана и сохранена во время записи страницы.

Установки заголовка страницы

Действия до записи

Действия после чтения

NONE

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

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

Page Header Status = NONE

Значение PAGE_VERIFY для базы

Проверки для защиты

NONE

Нет

TORN

Нет

CHECKSUM

Нет

CHECKSUM

Формула расчета контрольной суммы применяется к странице данных 8КБ. Значение контрольной суммы в заголовке страницы изменено, и состояние защиты в заголовке страницы установлено на CHECKSUM. После этого страница сохраняется на долговременном носителе.
Защита с помощью контрольной суммы использует больше всего процессорных циклов из имеющихся трех вариантов защиты. Это происходит потому, что для её расчёта используются все биты страницы. Однако, алгоритм был максимально оптимизирован, и его воздействие на производительность минимизировано. Защита контрольной суммой является в SQL Server 2005 установкой базы данных по умолчанию.

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

Page Header Status = CHECKSUM

Значение PAGE_VERIFY для базы

Проверки для защиты

NONE

Нет

TORN

CHECKSUM

CHECKSUM

CHECKSUM

TORN

Защита от оборванных страницы проверяет при записи по два бита каждого 512-байтного сектора страницы. В заголовок страницы, кроме метода защиты, вписывается последовательность пар бит для всех секторов страницы, после чего страница сохраняется на долговременном носителе.
Поскольку для TORN-защиты нужно проверять только 2 бита на каждый сектор 8КБ страницы, потребуется меньше циклов процессора, но степень защиты будет гораздо меньше, чем с контрольной суммой.

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

Page Header Status = TORN

Значение PAGE_VERIFY для базы

Проверки для защиты

NONE

Нет

TORN

TORN

CHECKSUM

TORN

Обратите внимание, что SQL Server не будет перезаписывать все страницы базы данных, если выполнить ALTER DATABASE с изменением PAGE_VERIFY. Опция PAGE_VERIFY изменится только через какое-то время, и сохранённые на диске страницы будут иметь тот вид защиты, который был им установлен во время записи. Т.о. база данных может иметь страницы с любыми из трех возможных состояний проверки страниц.
Не существует специальной команды, которая бы установила опцию PAGE_VERIFY и применила это ко всем страницам базы данных. Это относится также и к операциям резервного копирования и восстановления.

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

  • Пересоздание кластеризованных индексов в базе данных может привести к тому, что большинство данных окажется на грязных страницах индексов, и это позволит увеличить число страниц с новым состоянием защиты. Однако, кучи, поля типов text/image, хранимые процедуры, хранимые сборки и другие не попадут на грязные страницы при пересоздании кластеризованных индексов.

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

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

[В начало]

Контрольные суммы в оперативной памяти

В SQL Server 2005 защита страниц данных получила дополнительные возможности, механизм PAGE_VERIFY CHECKSUM расширен теперь и на оперативную память, и контрольная сумма может вычисляться для находящихся там страниц. Существует несколько ситуации, для которых это может оказаться полезным, например, это может быть загрязнение памяти (in-memory scribblers), нестабильность файла подкачки и нестабильность оперативной памяти.
Для обслуживания контрольных сумм находящихся в оперативной памяти страниц данных используется всё тот же алгоритм расчёта контрольной суммы - PAGE_VERIFY CHECKSUM. Сохранённые на долговременный носитель с состоянием CHECKSUM страницы, будут вовлечены в алгоритм расчёта контрольных сумм в оперативной памяти, если включён динамический флаг трассировки -T831. Страница данных предварительно должна получить при записи на долговременный носитель начальное значение контрольной суммы, чтобы для неё стала возможна защита, использующая алгоритм проверки контрольных сумм в оперативной памяти.
Когда во время некоторых переходов страницы из одного состояния в другое выполняется проверка контрольной суммы находящейся в оперативной памяти страницы, это приводит к небольшому снижению производительности. В следующей далее таблице описаны состояния, в которых может находиться страница:

Состояние
страницы

Описание состояние

Грязная
(Dirty)

Считается, что страница данных является "грязной", когда она была изменена, но не была ещё записана на долговременный носитель. Как только грязная страница сохранена на долговременный носитель, её считают "чистой".

Чистая
(Clean)
 

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

Проверка контрольной суммы находящейся в оперативной памяти страницы данных выполняется, если истинны следующие условия:

  • Страница была записана на диск при включённой PAGE_VERIFY CHECKSUM.

  • Для базы данных была включена опция PAGE_VERIFY CHECKSUM.

  • Был включён флаг трассировки -T831.

Обслуживание режима PAGE_VERIFY происходит во время чтения и записи страниц данных. Вычисление контрольной суммы в оперативной памяти происходит при включённом флаге трассировки -T831. В представленной ниже таблице показаны те действия с контрольной суммой, которые происходят в случае правильного включения режима контроля CHECKSUM, когда страница содержит правильную контрольную сумму, и когда включён флаг трассировки -T831.

Действие

Описание

Чтение страницы

 

Состояние страницы

Описание состояния

Физическое чтение

Контрольная сумма проверяется после окончания чтения; контрольная сумма сохраняется для проверки в оперативной памяти.

Логическое чтение
 

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

Запрос изменения страницы

 

Состояние страницы

Описание состояния

Грязная
(Dirty)

После того, как страница помечается "грязной", контрольная сумма для неё больше не проверяется. Контрольная сумма будет ещё раз рассчитана, когда страница будет записана на долговременный носитель.
Проверка контрольной суммы в оперативной памяти не производится.

Чистая (Clean)

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

Возврат (Discard)

Страница считается "возвращённой", когда она возвращена в список свободных страниц.

Состояние страницы

Описание состояния

Грязная
(Dirty)

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

Чистая (Clean)

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

Обратите внимание, что не изменяющиеся страницы (которые никогда не становятся "грязными") остаются в состоянии "чистые", пока они не будут возвращены, и всё это время контрольная сумма тоже не будет меняться.
 

Процесс отложенной записи использует защиту, основанную на проверке контрольной суммы буферов чистых (постоянных) страниц. Эти проверки выполняются всегда, и для этого не требуется включать флаг трассировки -t831. Каждую секунду процесс отложенной записи вносит изменения в счётчики производительности буферного пула и выполняет разнообразные вспомогательные действия. Во время этих служебных операций, отложенная запись может переместить более шестнадцати буферов. Когда отложенная запись находит чистый буфер с действительной контрольной суммой, она проверяет правильность этой контрольной суммы. Если проверка оканчивается ошибкой, об это сигнализируется генерацией сообщения об ошибке 832. Это становится возможным, поскольку выполняемый в фоновом режиме аудит контрольной суммы в оперативной памяти потребляет мало ресурсов. Страницы, которые долгое время остаются в состоянии "чистые" (постоянные), позволяют средствам защиты процесса отложенной записи обнаружить возможные повреждения ещё до того, как такие страницы будут возвращены.
Если контрольные проверки выявляют проблемы, SQL Server генерирует сообщение об ошибке 832, которое указывает на то, что было зафиксировано состояние ошибки. Если Вы сталкиваетесь с расхождениями контрольной суммы в оперативной памяти, используйте представленную ниже диагностику:

  • Проверьте резервные копии, чтобы убедиться в корректности стратегии восстановления.

  • Проведите полное тестирование аппаратных средств, сосредоточив особое внимание на компонентах памяти.

  • Проверьте все сторонние программы, используемые в системе или работающие в адресном пространстве SQL Server. Сторонние компоненты могут привести к засорению памяти, что часто приводит к возникновению проблем. Такими компонентами могут быть COM - объекты, расширенные хранимые процедуры, связанные серверы или другие, аналогичные объекты.

  • Убедитесь в том, что на сервере применены все заплатки и сервисные пакеты для операционной системы.

  • Если используется антивирусная защита, удостоверьтесь в том, что её хранилище штаммов вирусов актуально, и в системе нет вирусов.

  • Проверьте, что размещение файла подкачки соответствует требованиям к вводу-выводу SQL Server.

  • Включите форсированные краткие блокировки, как это будет описано ниже в этом документе, что помогает изолировать источник проблем.

  • Попробуйте использовать для воспроизведения проблемы те же самые входные буферы или воспользуйтесь возможностью воспроизведения трассы (Replay) в SQL Server Profiler. Если проблема воспроизводится, попробуйте воспроизвести её на другом компьютере. Если проблема воспроизводится и на других компьютерах, обратитесь за дополнительной помощью в службу поддержки Microsoft SQL Server.

[В начало]

Принудительная краткая блокировка

SQL Server 2000 и SQL Server 2005 могут использовать принудительные краткие блокировки (latch enforcement) для страниц базы данных, находящихся в кэше буферного пула. Принудительная краткая блокировка является механизмом виртуальной защиты памяти (VirtualProtect), когда страница базы данных меняет состояние с "чистая" на "грязная". В представленной ниже таблице показаны виртуальные состояния защиты.

Состояние страницы

Виртуальное состояние защиты

Грязная

"Чтение и запись" во время изменения.

Чистая
 

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

Страница базы данных остается в виртуальном состоянии защиты "Только для чтения", пока не будет установлена краткая блокировка изменения (modification latch). Когда установлена краткая блокировка изменения, защита страницы изменяется на "Чтение и запись". Как только краткая блокировка изменения будет снята, защита страницы возвращается в виртуальное состояние "Только для чтения".

    Обратите внимание, что по умолчанию защита принудительной краткой блокировкой отключена. Принудительную краткую блокировку можно включить флагом трассировки -T815. SQL Server 2000 SP4 и 2005 принимает или отключает это флаг без необходимости перезапуска службы SQL Server, для чего используются команды: DBCC traceon (815,-1) и DBCC traceoff (815,-1). Более ранние версии требуют включения этого флага трассировки в параметрах запуска SQL Server.
    Также, обратите внимание, что этот флаг трассировки должен использоваться только по рекомендации службы поддержки Microsoft SQL Server, поскольку его использование может привести к существенным изменениям в работе сервера, и изменение виртуальных состояний защиты не поддерживается на некоторых версиях операционных систем, когда используются режимы PAE/AWE.
    Кроме того, обратите внимание, что расширенная поддержка VirtualProtect в Windows Server ™ 2003 SP1 и Windows XP SP2 подразумевает использование механизмов виртуальной защиты и для распределённой через AWE памяти. Это очень существенное изменение, и из-за расширения возможностей защиты оно может повлиять на работу SQL Server, если в его глобальной конфигурации указано использование AWE или фиксации страниц памяти (locked pages memory).

Принудительная краткая блокировка применяется только к страницам базы данных. Другие области памяти остаются неизменными и краткой блокировкой не защищаются. Например, к таким областям можно отнести: буфер вывода TDS, план запроса и любые другие структуры памяти, которые тоже не подпадают под действие защиты принудительной краткой блокировки.
До непосредственно изменений, SQL Server должен изменить защиту страниц, разрешив читать и писать в страницы базы данных. Краткая блокировка используется для поддержания физической стабильности страницы базы данных, поэтому краткая блокировка изменения удерживается ровно столько, сколько нужно для выполнения физических изменений на странице. Если в течение этого времени страница будет повреждена (наложенная запись), принудительная краткая блокировка не будет в состоянии вызвать исключение.
В версиях предшествующих SQL Server 2004 SP4, защита принудительной краткой блокировки использовала больше переходов из состояния в состояние. В следующей таблице показаны транзакции защиты, применяемые в предшествующих SQL Server 2000 SP4 версиях:

Состояние страницы

Виртуальное состояние защиты

Грязная

"Чтение и запись" во время изменения.

Чистая без ссылок
 

"Нет доступа" - любая попытка чтения или записи на странице вызывает исключение.

Чистая с ссылками
 

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

Поскольку переходы состояний виртуальной защиты обходятся довольно дорого, SQL Server 2000 SP4 и SQL Server 2005 больше не используют переход защита страницы в состояние "Нет доступа", что значительно сокращает общее число переходов. Старые версии могли создать исключение при попытке недопустимого чтения, которые в более новых реализациях невозможны. Накладные расходы на переходы защиты в состояние "Нет доступа" часто делали принудительные краткие блокировки слишком тяжелыми для использования в промышленной среде. Если оставлять страницы в состояние с доступом только для чтения, это значительно уменьшает число изменений состояний защиты, но по-прежнему позволяет идентифицировать наложенную запись - "загрязнение" страниц.
SQL Server не возвращает все страницы данных в состояние "Чтение и запись" сразу после отключения флага трассировки. Страницы вернуться в состояние "Чтение и запись" когда будут изменены, так что это может занять некоторое время, по истечении которого весь буферный пул будет полностью избавлен от воздействия механизма принудительных кратких блокировок.

[В начало]

Контрольные суммы резервного копирования и восстановления

Инструкции BACKUP и RESTORE в SQL Server 2005 поддерживают опцию вычисления контрольной суммы - CHECKSUM, которая позволяет использовать защиту контрольной суммой потока резервирования и вызвать операции проверки контрольной суммы во время восстановления из резервной копии. Чтобы включить поддержку контрольной суммой резервной копии, нужно в команде BACKUP включить опцию CHECKSUM.
Процессы резервного копирования и восстановления пытаются по возможности работать с большими блоками. Например, операция резервирования просматривает битовые маски распределений в базе данных, чтобы определить, какие страницы данных попадают в поток на резервный носитель. Как только блок данных идентифицирован, операция резервного копирования считывает из файла данных для записи в поток резервирования большие от 64 КБ до 1 МБ блоки. Операция резервного копирования старается не работать с отдельными байтами страниц данных или блоков журнала регистрации транзакций, это помогает повысить производительность и скорость копирования.
Операции резервного копирования и восстановления, у которых для защиты целостности данных задействованы возможности проверки контрольной суммы, более требовательны к процессорным ресурсам. Резервное копирование или восстановление с включённой опцией контрольной суммы просматривает каждый байт потока, что как раз и повышает нагрузку на процессоры. Расчёт контрольной суммы для резервирования и восстановления использует тот же алгоритм, который вычисляет значение контрольной суммы для носителей резервных копий, и который используется для страниц данных и блоков журнала транзакций.
Следующие правила применимы к командам BACKUP и RESTORE для операции CHECKSUM:

  • По умолчанию, в SQL Server 2005 операции BACKUP и RESTORE поддерживают обратную совместимость (значение по умолчанию - NO_CHECKSUM).

  • Установка для базы данных опции PAGE_VERIFY не влияет на операции резервного копирования и восстановления. Влияет только установка опции CHECKSUM в команде резервного копирования или восстановления.

  • Контрольная сумма резервного копирования и восстановления - это одно значение, представляющее контрольную сумму всего потока; оно не относится к отдельным страницам или блокам журнала, помещённым в поток резервирования. Значение вычисляется во время резервного копирования и сохраняется в резервной копии. Это значение вычисляется повторно во время восстановления и сверяется с хранимым значением.

  • Резервное копирование с опцией CHECKSUM не изменяет страницы при сохранении их на резервном носителе. Состояния защиты страницы (NONE, CHECKSUM или TORN) будет таким, каким оно было считано в файле базы данных. Если контрольная сумма была сохранена на странице данных, она будет проверена перед тем, как эта страница будет записана в поток резервирования.

  • Если резервная копия была создана с опцией CHECKSUM, для проверки контрольной суммы могут использоваться команды восстановления и сверки. Попытка восстановления с опцией CHECKSUM резервной копии без контрольной суммы возвратит ошибку.

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

[В начало]

Восстановление на уровне страниц

В SQL Server 2005 Enterprise Edition добавлена возможность восстановления на уровне отдельных страницы, что позволяет осуществлять восстановление поврежденных страниц из резервной копии. Для базы данных можно восстановить из резервной копии одну страницу, не выполняя при этом полного восстановления базы данных, файловой группы, или файла данных. Для получения дополнительной информации, см. SQL Server 2005 Books Online.

[В начало]

Доступность базы данных в фазе отмены (Undo)

В SQL Server 2005 Enterprise Edition доступу к базе данных возможен сразу после завершения фазы повтора (Redo) стадии регенерации (recovery). В фазе отмены применяются механизмы блокировок, которые призваны защитить откат операций. Для сокращения времени простоя, можно объединить восстановление на уровне страниц с послеаварийной регенерацией, что позволяет предоставить доступ к базе данных уже на фазе отмены.

[В начало]

Защита от оборванных страниц (Torn page)

Защита от оборванных страницы не претерпела значительных изменений со времён SQL Server 7.0 и SQL Server 2000. В этой главе подробно описана работа защиты от оборванных страниц, что должно Вам помочь понять разницу между этой защитой, и защитой с помощью контрольной суммы. Наличие оборванной страницы обычно указывает на то, что один или несколько секторов были повреждены.

[В начало]

Распространённые причины

Здесь мы рассмотрим несколько наиболее распространённых проблем, приводящих к появлению ошибки обнаружения оборванной страницы, с которыми сталкивалась служба поддержки Microsoft SQL Server:

  • Подсистемы или аппаратные средства неправильно обрабатывают данные, возвращая перемешанные сектора. Такое наблюдалось у ряда контроллеров или их встроенного программного обеспечения из-за включённого для аппаратного кэша упреждающего чтения.

  • Отключение питающего напряжения.

  • Отражение бит (bit flips) или иные повреждения заголовка страницы. В таких случаях статус страницы указывает на то, что она была оборвана, хотя на самом деле этого не происходило.

[В начало]

Реализация

Защита от оборванных страниц основана на переключениях состояний двух бит из 01 в 10 и обратно при каждой операции записи страницы на диск. Если операция записи А установит биты защиты в 01, значит операция записи B должна установить 10. После этого, операция C должна устанавливать 01 и так далее. Последние два бита каждого 512Б сектора сохраняются в заголовке страницы и заменяются битами оборванных страниц, т.е. значениями 01 или 10.
Соответствующие участники в заголовке страниц данных SQL Server представлены в следующем списке вместе с диаграммой обслуживания бит оборванных страниц.

Участник

Описание

m_flagBits

Битовое поле, которое индицирует состояния: TORN, CHECKSUM или NONE

m_tornBits

Содержит данные для проверки состояний: TORN или CHECKSUM.


Рисунок 1

Биты состояния оборванных страниц устанавливаются в значения 01 или 10, и эти значения хранит участника m_tornBits. Для обслуживания пятнадцати 512Б секторов, каждая пара последних бит этих секторов располагаются с увеличением позиции разрядов, и всё это хранится участником m_tornBits.
Ниже представлена расшифровка шагов, показанных на предыдущем рисунке:

    Шаг 1: В m_tornBits сохраняются значения бит секторов от младших до старших разрядов (подобно небольшому массиву), с увеличением позиций сохраняемых разрядов в соответствии с размещением секторов на странице.
    Шаг 2: В двух последних битах сектора сохраняется текущее значение битов оборванных страниц, которые заменяют имеющиеся там значения.

Биты оборванных страниц ревизуются в момент чтения страницы с диска, если для базы данных включена защита PAGE_VERIFY.

    Шаг 1: Последние биты массива m_tornBits сверяются с образцами (10 или 01), что позволяет убедиться в том, что заголовок не поврежден.
    Шаг 2: Последние пары бит каждого сектора сверяются с соответствующими битами оборванных страниц массива m_tornBits.
    Если какая либо из этих проверок выявит расхождение, страница считается оборванной. В SQL Server 2000 возвратит ошибку 823, а SQL Server 2005 выдаст ошибку 824.
    Шаг 3:

      SQL Server 2000: Первоначальные значения заменяются во время проверки каждого сектора, даже если было обнаружено расхождение. Это не позволяет определить, какой именно сектор был оборван.
      SQL Server 2005: Обнаружение источника проблем усовершенствовано тем, что после обнаружения ошибки биты остаются неизменными. Можно изучить данные на странице, чтобы точнее определить состояние оборванной страницы.

[В начало]

Защита от чтения устаревших данных (Stale Read)

Чтение устаревших данных стало одной из наиболее часто разбираемых проблем службой поддержки Microsoft SQL Server. Чтением устаревших данных называется такой случай, когда операция физического чтения возвращает старые даны страницы, которые считаются непротиворечивыми на данный момент времени и успешно проходят проверку TORN или CHECKSUM. Вместо текущих данных, операция чтения возвращает предыдущий образ страницы данных. Также, такой случай называют потерянной записью (lost write), потому что самые последние данные, записанные на долговременный носитель, не возвращаются следующей операцией чтения.
Наиболее распространённым источником проблем, проявляющихся в виде чтения устаревших данных и потерянной записи, являются такие компоненты, как упреждающее чтение аппаратного кэша, который может ошибочно возвращать старые, находящиеся в кэше данные, вместо того, что бы вернуть последнюю записанную информацию.
Такие ошибки указывают на серьезные проблемы с подсистемой ввода-вывода, приводящие к искажениям связей страниц, к искажениям при распределении страниц, к потере логических или физических страниц данных, к аварийным отказам при регенерации или восстановлении копий журнала, а также к другим проблемам с целостностью и стабильностью данных.
В основанную на SQL Server 2000 SP3 заплатку (8.00.0847) была добавлена функциональность по обнаружению чтения устаревших данных. Защита от чтения устаревших данных подробно описана в статье Microsoft Knowledge Base: PRB: Additional SQL Server Diagnostics Added to Detect Unreported I/O Problems.

[В начало]

Дополнительная функциональность

В SQL Server 2000 SP4 и SQL Server 2005 были внесены изменения, заменившие кольцевой буфер на хеш-таблицы, с помощью которых низкоуровневая проверка чтения устаревших данных выполняется более эффективно. До этого, SQL Server 2000 SP3 проверял чтение устаревших данных только при выявлении других ошибок (605, 823 и т.д.). Используемый в последних версиях дизайн хеш-таблицы использует ряд не ресурсоёмких, логических проверок при чтении страниц, включая проверку чтения устаревших данных любой страницы при включённом флаге трассировки -T818.
В SQL Server 2005 при каждом сохранении страницы на диске в хеш-таблицу вставляется или изменяется запись, содержащая DBID, PAGEID, RECOVERY UNIT и сбрасываемый на долговременный носитель LSN. После завершения операции чтения, в хеш-таблице находятся записи с соответствующими DBID и PAGEID. Значение LSN из хеш-таблицы сверяется со значением LSN из заголовка страницы. Если эти значения LSN не соответствуют друг - другу, страница считается повреждённой. Т.е. страница считается повреждённой, если при последующей операции чтения не будет возвращён самый последний записанный LSN.
Для поддержки высокой производительности операций ввода-вывода и для ограничения используемого объёма памяти, размер хеш-таблицы ограничен. Она содержит записи только о последних записанных страницах данных. Число отслеживаемых операций ввода-вывода отличается в 32-х и 64-х битных версиях SQL Server 2000 SP4 и SQL Server 2005. Для повышения быстродействия, каждая область хэша и связанные с ней записи устроены таким образом, чтобы они представляли собой одну строку в кэше процессора, что призвано ограничить длину цепочки хеширования пятью записями на каждую области памяти. В 32-разрядных версиях общий размер хеш-таблицы ограничен 64КБ (состоящий из 2560 полных записей => 20MБ окно данных), а в 64-битной версии это будет уже 1 МБ (состоящий из 40960 полных записей => 320MБ окно данных).
Выбор такого ограничения размера основывался на результатах тестирования известных ситуаций, при которых возникали чтения устаревших данных или потеря записи. Эти ошибки обычно характеризовались использованием аппаратного кэша памяти, в котором оказывались старые версии страниц данных, и операциями чтения, которые следовали сразу же за операцией записи или с ней пересеклись.

[В начало]

Обнаружение задержек ввода-вывода (Stalled I/O)

С точки зрения производительности, на работу ядра базы данных наиболее ощутимо влияет подсистема ввода-вывода. Остановки или задержки в работе подсистемы ввода-вывода могут привести к снижению параллелизма работающих с SQL Server приложений. Служба поддержки Microsoft SQL Server провела ряд испытаний, направленных на определение того, как увеличение задержек в работе подсистемы ввода-вывода, а также остановки в её работе, влияют на снижение возможностей и на работу SQL Server в целом.
Для версии SQL Server 2000, остановки или задержки ввода-вывода можно обнаружить путём анализа sysprocesses, в которой можно увидеть находящиеся в состоянии ожидания ввода-вывода страниц данных буфера и/или блоков журнала. Принимая во внимание то, что небольшие задержки могут быть отражением состояний ожидания для некоторых фильтр-драйверов или аппаратных компонент; если наблюдается состояние ожидания по своей продолжительности превышающее 30 секунд, это говорит, скорее всего, о наличии серьезных проблем в работе использующего SQL Server приложения.
Начиная с SQL Server 2000 SP4 и SQL Server 2005, используются специальные средства мониторинга и поиска состояний остановки или задержки ввода-вывода, которые по своей продолжительности превышают 15 секунд, и затрагивают операции со страницами данных и журналом транзакций. Работа этих средств в SQL Server 2000 SP4 описана в статье Microsoft Knowledge Base: SQL Server 2000 SP4 diagnostics help detect stalled and stuck I/O operations.
Кроме того, в SQL Server 2000 SP4 и SQL Server 2005 выдаётся больше информации о кратких блокировках. Краткие блокировки используются для гарантии физической стабильности страниц данных во время исполнения операций чтение или записи на долговременный носитель. Эта дополнительная информация о кратких блокировках часто становиться причиной того, что после установки SQL Server 2000 SP4 многим кажется, что SPID блокирует сам себя. То, как информация о кратких блокировках из sysprocesses может использоваться для поиска остановок и задержек ввода-вывода, а так же то, почему SPID может казаться блокирующим сам себя, описывается в статье: The blocked column in the sysprocesses table is populated for latch waits after you install SQL Server 2000 SP4.
SQL Server 2005 выполняет контроль и обнаружение задержек ввода-вывода. Предупреждения о задержках ввода-вывода активируются, когда задержка превышает 15 секунд или больше. В дополнение к этому, были улучшены сообщения об ошибках из-за превышения допустимого времени ожидания краткой блокировки, чтобы они могли явно указать на то, что буфер находится во вводе-выводе. Это является показателем того, что ввод-вывод был остановлен на 300 секунд (пять минут) или дольше.
Существует чёткая разница между выдачей сообщения и регистрацией события. Сообщения появляются только в пятиминутных (или больше) интервалах, когда с файлом происходит новая операция ввода-вывода. Любой посылающий ввод-вывод исполнитель проверяет соответствующий файл и при необходимости выдаёт сообщения. Если были зарегистрированы задержки ввода-вывода, и после последнего сообщения прошли пять минут, в файл регистрации ошибок SQL Server помещается новое сообщение.
Регистрация же осуществляется подпрограммами завершения ввода-вывода и процессом отложенной записи, которые анализируют все ожидания ввода-вывода, фиксируя те из них, которые могут считаться задержками или остановкой ввода-вывода. Регистрация осуществляется во время того, когда запрос ввода-вывода находится на стадии рассмотрения (FALSE == HasOverlappedIoCompleted) и прошло уже 15 или более секунд.
Обратите внимание, что если запрос HasOverlappedIoCompleted возвращает значение FALSE, это указывает на то, что операционная система или подсистема ввода-вывода не завершили запрос ввода-вывода.

[В начало]

Динамическое административное представление dm_io_pending_io_requests

SQL Server 2005 предоставляет возможность динамического мониторинга информации об обслуживаемом вводе-выводе, что позволяет администратору базы данных определить подверженные задержке ввода-вывода базы данных, их файлы и смещения в этих файлах. Динамическое административное представление (DMV) dm_io_pending_io_requests предоставляет подробную информацию о выполнении и состоянии каждого из исполняемых запросов ввода-вывода. Эта информация может использоваться службой поддержки платформ Microsoft и разными утилитами, для выяснения первопричин задержек. Для получения более подробной информации, посетите сайт поддержки: http://support.microsoft.com, на котором ищите информацию о трассировке событий IRP и ETW.
Столбец представления io_pending содержит одно из ключевых значений возвращаемого набора, он указывает на то, находится ли запрос ввода-вывода в обработке или подсистема ввода-вывода уже завершила его обслуживание. Значение этой колонки определяется с помощью вызова HasOverlappedIoCompleted, который показывает состояние запроса ввода-вывода. В представленной далее таблице показаны возможные для колонки io_pending значения:

Значение
io_pending

Описание

TRUE

Указывает на то, что асинхронный запрос ввода-вывода ещё не закончен. SQL Server не может выполнять другие действия с этим диапазоном данных, пока операционная система и подсистема ввода-вывода не завершат запрос ввода-вывода.
Чтобы получить более подробную информацию о состояниях ожидания во время запросов ввода-вывода, обратитесь к описанию HasOverlappedIoCompleted, представленному в документации SDK.
Продолжительные асинхронные запросы ввода-вывода обычно указывают на проблемы в ядре подсистемы ввода-вывода, которые должны быть устранены, чтобы SQL Server вернулся в штатный режим работы.

FALSE

Указывает на то, что запрос ввода-вывода закончен и возможны дополнительные действия по обслуживанию задачи в SQL Server.
Если длительность задержки ввода-вывода продолжает увеличиваться, это может привести к проблемам в работе планировщика SQL Server. Для изучения работы планировщика SQL Server и возникающих при этом проблем, обратитесь к обзорному документу: How to Diagnosis and Correct Errors 17883, 17884, 17887, and 17888.

Столбец io_pending_ms_ticks - число миллисекунды (ms), прошедших с момента отправки запроса ввода-вывода операционной системе.
io_handle - дескриптор файла, с которым связан запрос ввода-вывода. По этому столбцу можно составить соединение по столбцу file_handle с динамической административной функцией (DMF) dm_io_virtual_file_stats, и в результате узнать конкретный файл и ассоциированную для ввода-вывода базу данных. Ниже показан пример запроса, который позволяет получить эту информацию.

SELECT fileInfo.*, pending.* FROM sys.dm_io_pending_io_requests AS pending INNER JOIN (SELECT * FROM sys.dm_io_virtual_file_stats(-1, -1)) AS fileInfo ON fileInfo.file_handle = pending.io_handle

Этот запрос можно расширить, добавив вывод информации о типе и названии базы данных, или добавить вычисление затронутого PAGEID, используя для этого смещение (Offset/8192 = PAGEID).
ПРЕДУПРЕЖДЕНИЕ: DMV и DMF в своей работе обращаются к внутренним системным структурам. Внутренние структуры могут быть доступны только для безопасных потоков, и это может сопровождаться изменением производительности. Использование обращаются к ядру SQL Server динамических административных представлений и функций должно быть сведено к минимуму, что бы это не вредило общей производительности сервера.

[В начало]

Повторное чтение

В SQL Server 2005 внесены изменения в логику использование повторного чтения страниц данных, что призвано повысить уровень последовательности операций чтения. Повторное чтение выполняет ту же операцию чтения после отказа предыдущей операции чтения, что бы попытаться все-таки завершить операцию чтения успешно.
Microsoft с успехом использует операции повторного чтения, что позволяет компенсировать неустойчивую работу подсистем ввода-вывода. Повторные чтения могут маскировать проблемы нарушения целостности данных в подсистеме ввода-вывода и должны быть тщательно изучены, чтобы определить и устранить их первопричину. Например, разрушающийся диск может периодически возвратить неправильные данные. Повторное чтение может вернуть правильные данные и тем самым способствовать хорошей последовательности чтения во время исполнения запроса. Однако, такая ситуация явно говорит о том, что диск находится под угрозой и он должен быть тщательно проверен, чтобы предотвратить потерю критических данных.
Microsoft добавило логику повторного чтения в Exchange Server, и было выявлено улучшение последовательности операций чтения. В этой главе Вы узнаете, как и когда SQL Server 2000 и SQL Server 2005 исполняют операции повторного чтения.

[В начало]

Повторы для ресурса

SQL Server 2000 исполняет повторное чтение только если в начале операции чтения происходит сбой и возвращаются ошибки операционной системы: ERROR_WORKING_SET_QUOTA (1453) или ERROR _NO_SYSTEM_RESOURCES (1450). В отличие от более развитых возможностей SQL Server 2005, SQL Server 2000 не использует других форм повторного чтения, кроме как повтор сортировки.
Когда происходит ошибка, исполнитель SQL Server выжидает 100ms и снова пробует повторить операцию чтения. Этот цикл продолжается, пока ввод-вывод не пройдёт успешно. Упрощенный алгоритм показан ниже.

WHILE(    FALSE == ReadFile()
    && (1450 == GetLastError() || 1453 == GetLastError())
)
{
    Yield(100);
}

SQL Server 2005 использует ту же самую логику когда нужно запустить операцию чтения.

[В начало]

Повтор сортировки

SQL Server 7.0, 2000 и 2005 используют логику повторов, связанную с сортировкой. Чаще всего, такие повторы появляются в виде записей в файле регистрации ошибок SQL Server, в которых упоминается 'BobMgr'. Когда чтение из очереди буфера сортировки в tempdb оканчивается неудачей, SQL Server пробует повторить эту операцию чтения снова. Повтор выполняется всего несколько раз, после чего считается, что сортировка окончилась сбоем. Повтор сортировки является серьезной проблемой стабильности ввода-вывода. Чтобы исправить эту проблему, пробуйте переместить базу tempdb в другое место.

[В начало]

Повторы чтения при других отказах

В SQL Server 2005 внесены улучшения в логику повторного чтение. Они направлены на то, чтобы чтение выполнялось и в тех случаях, когда отказ произошёл уже после того, как чтение было успешно начато. Если ReadFile возвращает TRUE, это указывает на то, что операционная система приняла от приложения запрос на чтение из файла. Если после этого происходил отказ, SQL Server выдавал ошибки 823 или 824.
SQL Server 2005 использует операции повторного чтения для того, чтобы сохранить непрерывность чтения даже тогда, когда чтение закончилось ошибкой, вызванной нехваткой ресурсов. В любых отличных от нехватки ресурсов случаях, возможны еще четыре повторные попытки.
Каждый последующий повтор выжидает некоторое время, после чего операция чтения может быть повторена ещё раз. Время выжидания рассчитывается по следующей формуле: ("время выжидания" = "номер попытки повтора" * 250ms). Если состояние ошибки не исчезает после четырех повторов (всего пять попыток: первое чтение и четыре повтора), выдаётся сообщение об ошибке 823 или 824. SQL Server 2005 сохраняет исходное описание состояния ошибки, например, это может быть расхождение контрольной суммы. Эти сообщения об ошибках сохраняются в файле регистрации ошибок SQL Server.
Если повтор выполнился успешно, к файлу регистрации ошибок SQL Server добавляется особое информационное сообщение, которое указывает на то, что были повторы. Вот пример такого сообщения:

"A read of the file «FILE NAME» at offset «PHYSICAL OFFSET» succeeded after failing «RETRY COUNT» time(s) with error: «DETAILED ERROR INFORMATION». Additional messages in the SQL Server error log and system event log may provide more detail. This error condition threatens database integrity and must be corrected. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online."

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

[В начало]

Аудит страниц

В SQL Server 2000 SP4 и SQL Server 2005 расширены возможности аудита страниц. Включение динамического флага трассировки -T806 приводит к тому, что все физически считанные страницы подвергаются глубокому DBCC - аудиту сразу после завершения чтения. Эта проверка выполняется в то же время, что и PAGE_AUDIT, а также другие логические проверки страниц.
Это ещё один способ обнаружения повреждений страниц данных, который использует область страницы, не входящую во всегда проверяемый при физическом чтении заголовок. Например, если включить флаг трассировки -T806, то область строк на странице будет проверяться на нарушение их последовательности.
Впервые, аудит страниц появился в SQL Server 2000 SP3 v.8.00.0937. Для получения более подробной информации, см. следующую статью Microsoft Knowledge Base: FIX: Additional diagnostics have been added to SQL Server 2000 to detect unreported read operation failures.
Обратите внимание: Включение аудита страниц увеличивает нагрузку на процессоры и снижает общую производительность SQL Server.
В SQL Server 2005 появилась возможность сверки контрольных сумм, которая может использоваться вместо аудита страниц. Защита контрольной суммой гарантирует, что каждый бит на странице соответствует тому, что храниться на долговременном носителе. Зачастую, проверка контрольных сумм в SQL Server 2005 является лучшим решением, чем постоянный аудит и проверка целостности данных. Однако, аудит страницы позволяет обнаруживать повреждения, которые уже были сохранены на долговременном носителе, причём, даже в тех случаях, когда физическая последовательность страницы не была нарушена. Служба поддержки Microsoft SQL Server в своей практике сталкивалась с подобными примерами. В одном таком случае, внешняя расширенная хранимая процедура осуществляла наложенную запись на странице данных, которая к тому времени уже была отмечена как "грязная". Контрольная сумма рассчитывалась для уже поврежденной страницы, после чего страница была сохранена на диск. Чтение такой страницы при включённом аудите страниц показывало ошибку, при этом, контрольная сумма совпадала. Если оказывается, что серверу не удаётся обнаружить проблему с помощью сверки контрольной суммы, но он может её обнаружить с аудитом страниц, рассмотрите возможность включения режима сверки контрольной суммы в оперативной памяти, и режима принудительных кратких блокировок, что должно Вам помочь определить источник наложенной записи (scribbler).

[В начало]

Аудит журнала

В SQL Server 2000 и 2005 добавлен флаг трассировки -T3422, который включает аудит журнала регистрации транзакций. Аудит журнала существенно упрощает разрешение проблем, связанных с искажением записей журнала транзакций, но повышает нагрузку на сервер, вызванную операциями журналирования.

[В начало]

Контрольная точка

SQL Server 2005 позволяет теперь управлять порождаемым командой CHECKPOINT вводом-выводом, и лучше обслуживает ввод-вывод автоматического исполнения контрольных точек. Для получения более подробной информации об изменениях в команде CHECKPOINT и выборе значения для определяющего продолжительность исполнения контрольной точки параметра, см. SQL Server 2005 Books Online.
В Microsoft пришло много предложений по реализации более динамичного алгоритма контрольной точки. Например, это могло бы быть полезным во время завершения работы SQL Server. Для баз данных с очень высокими требованиями к доступности, более агрессивная контрольная точка способствовала бы уменьшению объема работы и времени исполнения стартовой регенерации (recovery).
Объём активности операций журналирования определяет частоту запуска для базы данных контрольной точки. Записи журнала транзакций имеют исчисляемую в миллисекундах стоимость. После каждой записи в журнал, прогнозируется стоимость исполнения регенерации, начинаемой с последней контрольной точки. Если заданная продолжительность регенерации превышена, вызывается контрольная точка. Это позволяет удерживать время исполнения стартовой регенерации в рамках заданного значения продолжительности регенерации.
Ниже представлены основные правила работы контрольной точки. Термин "Задержка" указывает на время, прошедшее с момента начала записи, и до того момента, пока она не будет считаться законченной процессом контрольной точки.

Действие

Описание

Ручной запуск контрольной точки с указанием продолжительности

Задержка ввода-вывода установлена в значение по умолчанию - 20ms. При остановке сервера, параметр продолжительности устанавливается в 100ms.
Максимальный объём ввода-вывода будет соответствовать большему из результатов этих двух формул:

  • Число зафиксированных буферов / 3750;

  • Число планировщиков * 80;

Объём ввода-вывода постоянно корректируется, чтобы прокачка через буферный пул была соразмерима с прошедшим и заданным временем.

Ручной запуск контрольной точки без указания продолжительности
- или -
Автоматический запуск контрольной точки в зависимости от активности работы с базой

Задержка ввода-вывода установлена в значение по умолчанию - 20ms. При остановке сервера, параметр продолжительности устанавливается в 100ms.
Максимальный объём ввода-вывода будет соответствовать большему из результатов этих формул:

  • Число зафиксированных буферов / 3750;

  • Число планировщиков * 80;

  • Минимальный объём установок ввода-вывода равен двум.

Объём ввода-вывода корректируется таким образом, чтобы запись успевала проходить в заданное время.

[В начало]

Для любых вызовов контрольной точки

Когда контрольная точка достигает порогового значения объёма ввода-вывода, она уступает ресурсы одному из ещё не законченных запросов ввода-вывода.

[В начало]

Если продолжительность не задана или контрольная точка исполняется автоматически

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

[В начало]

Ручное управление контрольной точкой через указание продолжительности

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

[В начало]

SQL Server 2005 SP1 учитывает вероятность непрерывного запуска контрольной точки

В SQL Server 2005 SP1 немного был изменён алгоритм работы контрольной точки. SQL Server 2005 не добавляет временные интервалы между вводом-выводом. В связи с этим, процесс контрольной точки может закончиться перед самым началом следующего запуска. В Service Pack 1 добавлены соответствующие задержки, которые стараются насколько возможно выдерживать продолжительность. Хотя это и не является рекомендуемой практикой, но администратор может отключить автоматический запуск контрольных точек и использовать ручное управление контрольными точками с указанной продолжительностью. Запуск контрольной точки в ручную, в непрерывном цикле и с заданной продолжительностью тоже может обеспечить непрерывное обслуживание контрольной точки. Делать это можно очень осторожно, потому что контрольные точки будут преобразованы в последовательную форму, и это может повлиять на другие базы данных, а также операции резервного копирования. Кроме того, необходимо будет организовать процесс контрольной точки для всех баз данных.
Обратите внимание, что в SQL Server 2005 Service Pack 1 включена заплатка для очень редкой ошибки, связанной с работой контрольной точки. Заплатка помогает тогда, когда контрольная точка получает очень маленькое окно, за которое она не успевает сбросить буфер на диск. Это может привести к повреждению данных. Для предотвращения этой проблемы, установите SQL Server 2005 SP1.

[В начало]

Улучшения подсистемы множественной записи (WriteMultiple)

В SQL Server 7.0 появилась встроенная подсистема, которая называлась WriteMultiple - подсистема множественной записи. WriteMultiple сохраняет страницы данных на долговременный носитель. Для получения более подробной информации, см. главу "Сброс страниц данных на диск".
SQL Server 7.0 и 2000 могли обслуживать операции множественной записи до 16 страниц (128 Кбайт). В SQL Server 2005 возможность множественной записи расширена до 32 страниц (256 Кбайт). Это может повлиять на размер блока при выборе конфигурации для ваших задач. Для получения более подробной информации о физическом размещении базы данных, см. статью Physical Database Storage Design.
Кроме того, в SQL Server 2005 была изменена логика множественной записи. В SQL Server 7.0 и 2000, функция принимала идентификатор стартовой страницы. Стартовая и непрерывная цепочка последующих 16-ти грязных страниц одной и той же базы данных связывались в один запрос на запись. SQL Server делает это, используя поисковые запросы в хеш-таблице, стараясь найти следующие непрерывно расположенные страницы. Если такая страница не найдена, или найденная страница является чистой, запрос ввода-вывода считался законченным.
В SQL Server 2005 добавили ещё один поисковый запрос и дополнительные шаги по обеспечению безопасности множественной записи. В SQL Server 2005 начальные страницы ищутся тем же способом, который использовался версиями SQL Server 7.0 и 2000. Когда первый этап поиска в прямом направлении от передовой страницы закончен, SQL Server 2005 может сделать обратный поиск, если в запрос ввода-вывода пока попало меньше 32 страниц. Для поиска дополнительных страниц, SQL Server использует те же самые поисковые запросы в хеш-таблице. Например, если бы множественная запись после первого прохода нуждалась в дополнительных страницах, а передовой страницей являлась страница 1:20, поисковый запрос исследовала бы страницы 1:19, 1:18 и так далее. Поиск был бы прекращён при наступлении одного из перечисленных ниже условий:

  • страница не найдена.

  • страница найдена, но она является чистой.

  • для запроса ввода-вывода были найдены все 32 страницы.

В SQL Server 2005 введены дополнительные проверки заголовка страницы. Одна из этих дополнительных проверок - проверка идентификатора страницы. Ожидаемое значение идентификатора страницы сравнивается с его фактическим значением в заголовке страницы. Это помогает бороться с наложенной записью или с записью на диск повреждённых страниц, что приводит к повреждению базы данных.

[В начало]

Усовершенствования упреждающего чтения

В SQL Server 2005 дизайн упреждающего чтения был доработан, чтобы снизить требования к физической передаче данных, и усовершенствовать манипуляции со страницами в запросе, если страницы данных уже находится в буферном пуле. Для получения более подробной информации об упреждающем чтении в SQL Server, см. Упреждающее чтение (Read-Ahead).
Например, запрос упреждающего чтения включает обработку страниц с 1 по 128, но страницы 1 и 128 уже присутствуют в буферном пуле SQL Server. В SQL Server 2005 запрос упреждающего ч тения извлечёт страницы с 2 по 127, в то время как SQL Server 2000 запросил бы страницы с 1 по 128 и игнорировал бы данные, которые были извлечены для страниц 1 и 128.

[В начало]

Разреженные файлы / Копия на записи / Контура

Для снимков баз данных и онлайновых операций DBCC CHECK* используется присутствующая в NTFS технология разреженных файлов (sparse files). В этой главе будет дана детальная информация по этой технологии, применяющейся теперь и в SQL Server.

Обратите внимание: на момент публикации, заявленные производителем новшества, такие как "thin provisioning", еще не были протестированы. Более детальную информации по этой теме можно найти в программе Always On Storage Solution Review SQL Server.

[В начало]

Контура (Streams)

Онлайновые операции DBCC CHECK* для каждого проверяемого файла данных используют в качестве переходного процесса контур разреженного файла. Имена контуров соответствуют следующему шаблону: «ORIGINAL FILE»:MSSQL_DBCC«DBID». Контур - вторичная область данных, связанная с оригинальным файлом, и поддерживаемая файловой системой. Онлайновые DBCC операции используют контура, для создания переходных снимков базы данных, на момент исполнения проверки. Этот снимок пользователям базы данных недоступен. Контур снимка дает возможность онлайновой DBCC операции сымитировать и проверить все факты используя точную на определённый момент времен копию базы данных. Для этого нужно только непосредственно само хранилище. Во время онлайновых DBCC операций, в контуре сохраняются только те страницы, которые изменились после начала DBCC. Когда онлайновая DBCC операция закончится, контур удаляется.
Стоит обратить внимание и на то, что контур предоставляет возможность DBCC операциям уменьшить гранулярность блокировок. Если контур создать не удаётся или недостаточно места, DBCC возвращается к старому алгоритму, в основе которого лежит блокировка таблиц. Администратор должен обеспечить достаточный запас свободного места на каждом томе, что необходимо для обеспечения высокого параллелизма обслуживаемых баз данных.
Для получения более подробной информации об онлайновых DBCC операциях, см. DBCC Internal Database Snapshot Usage в SQL Server 2005 Books Online.

[В начало]

Копирование при записи и разреженные файлы

Моментальный снимок базы данных содержит образы страниц данных, которые были изменены после создания снимка. Создание снимка базы данных сопровождается немедленным откатом активных на момент создания транзакций для снимка базы данных. Для создания нового снимка активные транзакции в первичной базе данных должны быть прокручены назад, таким образом, чтобы получить правильный момент времени снимка. Сами транзакции в первичной базе данных остаются при этом неизменными.
В целях экономии физического дискового пространства, снимки базы данных хранятся в специальных разреженных файлах. Это лимитирует требования к физическому дисковому пространству снимка базы данных и изменению образа снимка. Чем больше страниц данных изменяется в исходной базе данных, тем больший физический размер нужен для хранения снимка базы.
Файлы для снимка базы данных именуются в команде CREATE DATABASE. Например, родительская для снимка база данных может называться main.mdf, а снимок может называться snapshot_main.mdf.
SQL Server 2005 для страниц данных снимка использует копирование при записи. Перед тем, как внести изменения на первичную страницу базы данных, она копируется и сохраняется во всех связанных с базой данных снимках. Для администраторов важно контролировать физический размер снимка баз данных, чтобы хорошо представлять и прогнозировать требования к хранилищу на будущее. Обратите внимание, что наименьшим модулем распределения разреженного файла является 64КБ. Поэтому дисковое пространство может исчерпываться быстрее, чем Вы ожидаете.
Для получения более подробной информации о снимках база данных, см. Как работают моментальные снимки базы данных в SQL Server 2005 Books Online.

Стадии повтора и отката процесса регенерации используют журнал транзакций, и предназначены для того, чтобы поддерживать целостность баз данных на уровне транзакций. Однако, эта логика не применима к снимкам базы данных. Обратите внимание, что у снимков баз данных нет журналов транзакций. Поэтому, всё связанное с копированием при записи должно быть закончено во время транзакции в первичной базе данных.
Снимок использует комбинацию вызовов программного интерфейса для того, что бы распределить регион в 64КБ разреженного файла. Кроме того, в оперативной памяти поддерживается специальная битовая маска распределения, позволяющая отследить отдельные страницы, которые сохраняются в снимке. Во время создания или расширения файла снимка, SQL Server устанавливает соответствующие атрибуты файловой системы таким образом, чтобы все незаписанные регионы возвращали цельный нулевой образ в ответ на любой запрос чтения.
После начала запроса на изменение в первичной базе данных, страница данных записывается в какой-либо снимок базы данных и соответственно изменяется хранящаяся в оперативной памяти битовая маска распределения. Поскольку это может привести к вводу-выводу на снимке базы данных, при внедрении решения с копированием при записи важно учитывать подобную дополнительную нагрузку. Определение того, когда необходимо скопировать страницы базы данных, требует использования некой комбинации вызовов разных программных интерфейсов и осуществления запросов на чтение. Исходя из этого, запросы на чтение могут быть направлены в снимок базы данных, что позволяет определить, скопирована ли страница данных в снимок базы.
В тот момент, когда SQL Server выполняет операцию копирования при записи в разреженный файл, и для этого необходимо получить дополнительное физическое место в хранилище, операционная система может выполнить эту запись синхронно. Для предотвращения синхронного характера записи, руководящий процессом копирования при записи планировщик SQLOS может выполнять запись используя вторичных исполнителей из исполнительского пула. На практике, если существуют несколько снимков одной и той же первичной базы данных, запись может быть распараллелена, и выполнена с использованием нескольких исполнителей. Инициализирующий исполнитель ожидает, пока вторичные исполнители завершат запись, чтобы продолжить изменения первоначальной страницы данных. Когда SQL Server ждет завершения записи, изначальный исполнитель может находиться в состоянии ожидания записи реплики, или ожидания краткой блокировки ввода-вывода реплики страницы данных.
Даже если транзакция будет откачена, страница данных записывается в снимок. Разреженный файл занимает место в физическом хранилище после того, как произойдёт запись. После этого уже невозможно так откатить эту операцию, что бы вернуть задействованное физическое дисковое пространство.

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

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

Обратите внимание: Такие утилиты, как: WinZip, WinRAR, COPY и другие не поддерживают фактическую целостность разреженных файлов. Когда такой файл скопирован с помощью подобных утилит, все не распределённые байты будут считываться и восстанавливаться как нули. Для правильного копирования нужно реальное распределение и восстановление файла без потери атрибут разреженного файла. Для копирования разреженных файлов нужно использовать такие утилиты, которые умеют получать полный образ и восстанавливать структуру метаданных файла.

[В начало]

Видимость контуров и разреженных файлов

Размеры контуров и разреженных файлов проще контролировать, если Вы имеете представление о некоторых ключевых ограничениях их видимости.
Вторичные потоки файлов часто не видны для команд типа DIR. Это может создавать трудности при попытке определения числа копирований при записи, произошедших во время онлайновых операций DBCC CHECK*. Однако, существует несколько утилит третьих фирм, которые могут использоваться для получения информации о размере и о контурах файла.
Аналогичным образом обстоит дело и с определением размера разреженных файлов, который показывают команды типа 'DIR', и который у них равен полному размеру файла до установленной метки конца файла, а не реально занимаемому физическому месту на диске. Проводник Windows показывает логический размер как "Size", а физический размер файла как "Size on Disk".
Когда SQL Server пишет в разреженный файл базы данных, он может заполучить место, кратное размеру экстента базы данных 64 Кбайт (8 страниц * 8КБ каждая = 64КБ). SQL Server 2005 отслеживает какие сегменты разреженного файла ещё не были распределены. Он не только копирует страницу во время операции копирования при записи, но и следующие семь страниц (целый экстент), заполняя их маркером отсутствия данных. На системном уровне это уменьшает фрагментацию, поскольку операции проводятся с наиболее распространённым размером кластера файловой системы. Кроме того, это позволяет ускорить последующие запросы на копирование при записи для любых из незаполненных семи страниц, поскольку физическое место и разметка файловой системы уже были для них подготовлены. Также, это предоставляет возможность SQL Server использовать информацию о распределении на уровне файл для определения того, какие экстенты в разреженном файле были уже физически распределены. Заполненные метками пустых данных образы страниц могут использоваться для определения того, какие из включенных в распределенные регионы страницы были скопированы из базы данных источника.

[В начало]

Чтение из моментального снимка базы данных

Когда поступает запрос хранящихся в моментальном снимке данных, SQL Server 2005 осуществляет чтение данных из файла снимка и из соответствующего первичного файла базы данных. Для этого используются создаваемые в оперативной памяти разреженные битовые маски распределения базы данных и метки образов пустых страниц, с помощью которых SQL Server может быстро определять фактическое место нахождения страниц данных, которые затребованы запросом.
Например, во время исполнения запроса SQL Server может воспользоваться преимуществами большого запроса на чтение, считывая по восемь или более страниц данных в одном запросе на чтение, как это принято в упреждающем чтении. Давайте посмотрим это на примере.
Операция упреждающего чтения в базе данных источнике, для одного участка данных, охватит одним чтением сразу 64КБ, получив сразу восемь непрерывных страниц. Однако, если третья и шестая страницы были изменены и скопированы (копированием при записи) в снимок базы данных, это приведёт к разбиению операции чтения. В нашем примере потребуется пять отдельных запросов на чтение:

  • Страницы 1 и 2 могут читаться из базы

  • Страница 3 из снимка

  • Страницы 4 и 5 из базы

  • Страница 6 из снимка

  • Страницы 7 и 8 из базы

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

ПРЕДУПРЕЖДЕНИЕ: Если Вы используете снимки базы данных SQL Server или онлайновые операции DBCC CHECK*, чтобы исключить возможность повреждения снимка, применяете имеющиеся заплатки к операционной системе. Возможные ошибки описаны в статье: Error message when you run a DBCC check command in SQL Server 2005: "8909 16 1 Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 0 (type unknown)"

[В начало]

Быстрая инициализация файла

Современные операционные системы, включая Windows XP и Windows Server 2003, умею инициализировать файлы существенно быстрее своих предшественников, поскольку при использовании программного интерфейса SetFileValidData это происходит практически мгновенно. Этот интерфейс предоставляет возможность SQL Server получить физическое дисковое пространство без физического его обнуления, что и приводит к существенному ускорению подобных операций, выполняемых SQL Server. Все версии SQL Server используют структуры распределения базы данных, которые позволяют находить пригодные для использования страницы базы данных. После распределения, новая страница данных форматируется и записывается на долговременный носитель.
SQL Server 2000 создавал и расширял файлы журнала и данных, размечая новый участок нулевыми значениями. Если у экземпляра SQL Server 2005 неправильно установлены права запускающей службу учетной записи, он будет вести себя при создании и расширении файлов так же, как и SQL Server 2000. Алгоритм, используемый SQL Server, более агрессивен, чем инициализация нулями в NTFS (DeviceIoControl, FSCTL_SET_ZERO_DATA); он имеет более совершенный механизм блокировки файла в NTFS, и позволяет осуществлять параллельный доступ к нескольким разделам файла. Инициализация нулями ограничивает физические возможности ввода-вывода и может выполняться очень долго.
SQL Server 2005 использует мгновенную инициализацию файла только применительно к файлам данных. Мгновенная инициализация файла подразумевает отсутствие разметки нулями на этапе создания или приращения файла данных. Это означает, что SQL Server 2005 может создать очень большие файлы данных практически мгновенно.
К мгновенной инициализации файла в SQL Server 2005 применимы следующие правила:

  • Операционная и файловая системы должны поддержать мгновенную инициализацию файла.

  • Учетная запись для запуска SQL Server должна обладать правом SE_MANAGE_VOLUME_NAME. Эта привилегия позволяет использовать SetFileValidData.

  • Это должен быть файл данных от базы данных SQL Server. Файлы журналов регистрации транзакций SQL Server не могут использовать мгновенную инициализацию файла.

  • Если включён флаг трассировки -T1806, поведение SQL Server 2005 по инициализации файлов становиться таким же, как и у SQL Server 2000.

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

Обратите внимание: Для того, что бы гарантировать получение физического места для файла данных во время его создания или увеличения, используйте флаг трассировки -T1806.

Флаг трассировки -T1806 обеспечивает обратную совместимость, приводя к обнулению во время инициализации файла базы данных, и запрещает использование мгновенной инициализации файла. К такому же результату приводит изъятие прав SE_MANAGE_VOLUME_NAME. Для получения более подробной информации относительно права SE_MANAGE_VOLUME_NAME, см. статью "Инициализация файлов базы данных" в SQL Server 2005 Books Online.

Обратите внимание: Инициализация файла нулями не обеспечивает полной защиты от чтения предыдущих данных. Для обеспечения такой защиты, физический носитель должны отвечать требованиям стандартов Министерства Обороны США (Department Of Defense - DOD), которые представляют семь разных способов записи, одним из которых является инициализация файла нулями.
Для получения более подробной информации о защите ранее записанной информации, см. статью "Upgrading your PC? Protect and purge your personal files".
Для подробной информации о DoD 5015.2-STD, см. документ "Design Criteria Standard for Electronic Records Management Software Applications".

[В начало]

Привязка ввода-вывода и резервирование снимком

Привязка ввода-вывода (affinity I/O mask) выполняется специальными, скрытыми планировщиками, и управляет на уровне ядра такими задачами ввода-вывода буферного пула, как журналирование (log writer).

Примечание переводчика: привязка ввода-вывода для SQL Server 2005 SP1 действовала только на внутренний процесс отложенной записи.

Новая опция глобальной конфигурации - "привязка ввода-вывода" была добавлена в SQL Server 2000 SP1. Статья Microsoft Knowledge Base: INF: Understanding How to Set the SQL Server I/O Affinity Option описывает, как настроить привязку ввода-вывода.

Поставщики решений могут использовать так называемые виртуальные устройства (Virtual Device -VDI), на основе которых выполняется резервное копирование методом создания снимка, причем достигается практически зеркалирование данных. Для того чтобы SQL Server мог работать с таким снимком, необходимо гарантировать стабильность данных по меткам времени и исключить возможность оборванной записи. Это достигается путём фиксации всех новых операций ввода-вывода и завершая всех запросов ввода-вывода на уровне базы данных. Резервное копирование посредством Windows Volume Shadow Copy Service (VSS) является одним из основанных на VDI приложений.

Дизайн SQL Server 2000 не позволял контролировать фиксацию ввода вывода (frozen I/O) в комбинации с привязкой ввода-вывода. Резервирование снимком одной базы данных фиксировало запросы ввода-вывода (чтение и запись) для всех баз данных, что делало нежелательным одновременное выполнение привязки ввода-вывода и резервирования снимком.
Как было показано в указанной чуть выше статье, SQL Server 2005 поддерживает привязку ввода-вывода. Это позволяет исправить ситуацию, при которой возможно было зафиксировать все запросы ввода-вывода при настроенной привязке ввода-вывода.
Привязка ввода-вывода в SQL Server нужна только в очень редких случаях, и рекомендована в качестве настраиваемой опции глобальной конфигурации только для высокопроизводительных серверов. Использовать её можно только после тщательного тестирования, и если после тестирования будет явно видно, что включение привязки ввода-вывода приведёт к заметным улучшениям в работе сервера. Успешное применение привязки ввода-вывода может увеличить общую производительность экземпляра сервера. Без внесения указанных в статье изменений в глобальную конфигурацию, планировщики привязки ввода-вывода стараются поддерживать использование своего процессора на достаточно не высоком уровне и стараются не мешать другим планировщикам использовать не задействованные ресурсы этого процессора.

[В начало]

Закрепление страниц памяти

И 32-х и 64-битные редакции SQL Server могут использовать программный интерфейс AWE для закрепления страниц в памяти ( lock pages in memory), как это делается посредством VirtualLock, и потому закрепление всех страниц в памяти не гарантируется в том смысле, как это гарантируется при использовании AllocateUserPhysicalPages. Иногда это может вводить в заблуждение, поскольку управляющие доступностью памяти через окно AWE параметры глобальной конфигурации (выводимые при вызове sp_configure) существуют, но не используются в 64-битной редакции SQL Server. Вместо этого, при использовании установок интерфейса AWE будет предоставлено только разрешение на закрепление страниц в памяти. Разрешение уровня операционной системы: "Lock Pages In Memory" необходимо SQL Server для выполнения распределений через AWE.
Закрепление страниц в памяти может положительно сказаться на обслуживании ввода-вывода, и может снизить затраты на регулировку рабочего множества SQL Server.

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

Для эффективного исполнения операций ввода-вывода, используемая для этого память не должна сталкиваться с отсутствием страниц в физической памяти (page faults). Т.о., если память не закреплена, обращение к отсутствующим в физической памяти страницам становиться возможным. Поскольку большинство приложений память для ввода-вывода не закрепляет, операционная система сама переводит память в закреплённое состояние. Когда ввод-вывод закончен, память переводится назад, в не закреплённое состояние. 64-битный SQL Server 2005 Enterprise Edition определяет наличие разрешения на закрепление страниц в памяти, и устанавливает закрепление страниц кэша данных. 32-битный SQL Server требует что бы был установлен параметр глобальной конфигурации, включающий поддержку доступа к памяти через механизмы AWE, после чего становиться возможным закрепление страниц памяти. Это позволяет во время исполнения запросов ввода-вывода избегать переходов между закреплённым и не закреплённым состоянием страниц памяти, что повышает эффективность операций ввода-вывода. Чтобы отключить такое закрепление, достаточно удалить разрешение на уровне системы на эту операцию, либо включить флаг трассировки -T835 для 64-битной редакции сервера баз данных.

Важно: SQL Server старается сократить число листаний, отдавая память обратно операционной системе тогда, когда он может это сделать. Однако, в некоторых условиях сделать это бывает сложно. Когда страницы закреплены, они не могут быть подвержены листанию. Мы рекомендуем использовать закрепление страницы с осторожностью.

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

[В начало]

Простой сервера

По аналогии имеющихся в операционной системе операции определения состояний процессов suspend/resume, SQL Server 2005 тоже может определять состояние "простоя" своего процесса (sqlservr.exe). Каждый экземпляр SQL Server 2005 имеет специальную системную задачу, называемую: Монитор Ресурсов, основная задача которой - отслеживание уровня утилизации памяти ядра и корректировка на основе такого мониторинга размера кэша. Когда Монитор Ресурсов SQL Server 2005 обнаруживает, что не обслуживается никаких инициализированных пользователем запросов, он извещает о простое сервера посредством установки процессу соответствующего состояния. Когда поступает новый пользовательский запрос или необходимо отреагировать на критическое событие, SQL Server "просыпается" и выполняет необходимую работу. В представленной ниже таблице показано, какие действия предпринимаются на возможные события и разного типа запросы во время нахождения SQL Server в состоянии простоя:

Событие / Тип запроса

Описание

Пользовательский запрос

В ответ на инициализированный клиентским приложением пользовательский запрос будут предприняты те действия, которые требуются от SQL Server для исполнения этого запроса.
Пользовательские запросы бывают следующих типов:

  • Пакетный запрос

  • Запрос SQL RPC

  • Запрос DTC

  • Запрос на подключение

  • Запрос на отключение

  • Заявка на запрос

Подобные типы запросов также принято называть "внешними запросами".
Наличие активных пользовательских запросов не даёт SQL Server перейти в состояние простоя.
Когда SQL Server находится в состоянии простоя, запрос пользователя выводит процесс SQL Server из этого состояния.

Внутренние задачи

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

  • Lazy writer (отложенная запись);

  • Log writer (журналирование) ;

  • Automatic checkpointing (автоматическая контрольная точка) ;

  • Lock monitor (монитор блокировок).

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

Критические события

Некоторые редакции SQL Server в ответ на такие события, как, например, сообщения об ошибках памяти, могут вывести процесс SQL Server из состояния простоя, это важно для должной обработки такого события.

Есть несколько основных относящихся к процессу SQL Server правил, которые определяют, может ли он перейти с состояние простоя.
SQL Server не может перейти в состояние простоя по следующим причинам:

  • В течение 15 минут не должно быть никаких активных пользовательских запросов.

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

  • Service Broker должен находится в неактивном состоянии.

SQL Server выйдет из состояния простоя в следствие следующих причин:

  • Вытеснение памяти (за исключением SQL Server Express).

  • Внутреннее критическое событие или сообщение.

  • Внешний запрос, например, получения пакета Tabular Data Stream (TDS).

Состояние простоя может повлиять на способы взаимодействия SQL Server с системой. В представленной ниже таблице показано то, как это взаимодействие изменяется для разных редакций сервера баз данных.

Редакция сервера баз данных

Поведение сервера

SQL Server Express Service

  • По умолчанию, эта редакция может переходить в состояние простоя.

  • Обращается к операционной системе для принудительного уменьшения выделяемого под рабочее множество процесса SQL Server объёма память, использует для этого вызовы функции программного интерфейса: SetProcessWorkingSetSize (…,-1,-1) Своеобразная подгонка - балансировка рабочего множества.

  • Не выходит из состояния простоя в ответ на уведомления операционной системы о вытеснении памяти.

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

SQL Express - отдельный пользовательский экземпляр

  • По умолчанию, эта редакция может переходить в состояние простоя.

  • Может настраиваться таким образом, чтобы рабочее множество активно балансировалось.

  • Выходит из неактивного состояния в ответ на уведомления операционной системы о вытеснении памяти.

Workgroup

  • По умолчанию, эта редакция может переходить в состояние простоя.

  • Может настраиваться таким образом, чтобы рабочее множество активно балансировалось.

  • Выходит из неактивного состояния в ответ на уведомления операционной системы о вытеснении памяти.

Standard,
Enterprise,
Developer

  • Эта редакция может переходить в состояние простоя при включении флага трассировки.

  • Выходит из неактивного состояния в ответ на уведомления операционной системы о вытеснении памяти.

SQL Server всегда пытается обойтись без использования файла подкачки. Однако, не всегда без это возможно обойтись и полностью исключить листания. Простой процесса SQL Server может привести к интенсивному использованию файла подкачки и увеличить использование пути ввода-вывода, даже несмотря на то, что SQL Server пытается избегать таких ситуаций. Операции листания приводят к тому, что целые участки памяти сохраняются или считываются с долговременного носителя. Сбои во время листания могут привести к искажениям памяти.
Обратите внимание: Операционная система Windows используют такой дизайн хранилища и упреждающего чтения файла подкачки, который очень похож на то, как SQL Server работает с файлами данных и журналов. Это означает, что, будучи в состоянии простоя, SQL Server может испытать такую нагрузку ввода-вывода от операций листания, которая подобна его чтениям и записи в файлы данных. Чтобы в таких условиях гарантировать целостность данных, файл подкачки должен поддержать такие же спецификации ввода-вывода, какие применяются для баз данных и журналов SQL Server.
Возможность перевода SQL Server в состояние простоя может управляться следующими флагами трассировки:

  • 8009 - Включает возможность перевода сервера в состояние простоя.

  • 8010 - Отключает возможность перевода сервера в состояние простоя.

[В начало]

Зеркальное отображение баз данных (DataBase Mirroring или DBM)

В SQL Server 2005 SP1 были включены возможности зеркального отображения баз данных. Для получения более подробной информации о зеркальном отображении баз данных, см. Обзор зеркального отображения базы данных в SQL Server 2005 Books Online.
Зеркальное отображение базы данных не может существовать в виде самостоятельного решения. Однако, для отображаемой базы данных действуют все требования по организации взаимодействия с исходной базой, обеспечению целостности данных и защите от отказов, которые уже были описаны ранее в настоящем документе, в главе: Удаленное зеркальное отображение.
Зеркальное отображение базы данных использует основанные на циклическом избыточном коде проверки целостности данных (прим. переводчика: более сложный, чем контрольная сумма алгоритм), что необходимо для гарантированной передачи данных между источником и его зеркалом. В SQL Server 2005 для новых баз данных предусмотрена возможность сверки контрольной суммы страниц данных и блоков журнала регистрации транзакций, что повышает возможности обеспечения целостности данных. Для расширения таких возможностей ваших решений, как обеспечения постоянной готовности - 'Always On', мы рекомендуем использовать основанные на циклическом избыточном коде проверки целостности данных в комбинации с проверкой контрольных сумм, что обеспечит самый высокий уровень защиты от нарушений целостности данных.

[В начало]

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

В SQL Server 2005 была введена поддержка масштабирования доступа к общедоступным (далее общим) базам данных (Scalable Shared Database - SSD), т.е. одну и ту же открытую только для чтения базу данных могут использовать несколько экземпляров SQL Server, при этом, файлы такой базы размещаются на томах с атрибутом "read-only". Подробную информацию об установке и обслуживании SSD можно найти в SQL Server 2005 Books Online Web Refresh, а также в статье Microsoft Knowledge Base: Scalable shared databases are supported by SQL Server 2005.
SSD позволяет использовать несколько новых возможностей масштабирования, в числе которых можно назвать следующие:

  • доступ для множества серверов;

  • разнесение серверных ресурсов;

  • разнесение ресурсов системной базы данных tempdb.

Обратите внимание: доступ к открытым только для чтения файлам баз данных SQL Server никогда не поддерживался для физически других серверов. SQL Server SSD ни в каком виде не поддерживает запись в файлы базы данных.

Некоторые подсистемы ввода-вывода умеют на уровне тома налету копировать запросы на запись, (copy-on-write snapshots, COW) поддерживая, таким образом, моментальный снимок файла. В подобных решениях, подсистемы ввода-вывода контролируют операции записи на первичном томе (чтение - запись) и сохраняют исходные данные в моментальном снимке всего тома. Снимок тома может предоставляться в виде доступной только для чтения копии. Открытый только для чтения том моментального снимка поддерживается в качестве одного из вариантов конфигурации базы данных SQL Server SSD. Такой подход может стать мощным инструментом для работы с оперативной информацией в промышленной среде, когда необходимо только чтение, но оно должно выполняться с нескольких серверов.
Некоторые подсистемы, вместо подхода с созданием моментального снимка тома и предоставления его только для чтения, используют механизмы распределенных блокировок. Это позволяет нескольким серверам работать с одним томом и для чтения, и для записи. Среда с распределенными блокировками может быть весьма производительной, но она не отвечает требованиям по обеспечению единого образа данных на указанный момент времени (point-in-time) для вторичных серверов. Оперативные данные предоставляются всем серверам, подключившим себе такой том. SQL Server SSD не поддерживает запись в файлы базы данных. Буферный пул SQL Server нельзя синхронизировать по заданным моментам времени с вторичными серверами, поскольку это породило бы разного рода проблемы, связанные с грязным чтением.


Последовательность создания и использования SQL Server SSD

[В начало]

Упреждающее заполнение локального кэша

SQL Server 2005 Enterprise Edition старается побыстрее заполнить локальный кэш данных сервера, причём, ещё на стадии инициализации. Рост используемой памяти во время инициализации принято называть ramp-up стадией. На этой стадии, всякий раз, когда для исполнения запроса требуется прочитать одну страницу, будет на самом деле прочитано восемь страниц (64 КБ), которые будут распределены в буферном пуле. Упреждающее заполнение кэша помогает уже после рестарта сервера сделать время ожидания чтения одиночных страницы заметно меньше, чем в предыдущих версиях. Это дает возможность быстрее заполнить кэш данных, после чего SQL Server будет выдавать больше страниц из кэша, чем с диска (возрастёт процент логических чтений).
Не поддерживающие серверную архитектуру NUMA компьютеры, обычно, реализуются в виде одного узла. Когда у сервера памяти много, это может стать существенным преимуществом, потому что в таком случае возможна более быстрая перезаливка кэша данных. Каждый узел закреплён и управляется собственным монитором ресурсов. SQL Server имеет информацию о всех процессорных узлах и требующихся для них объемах и конфигурациях памяти, которая находятся в домене близости каждого узла. Это относится и к буферному пулу. Перечисленные возможности позволяют считать SQL Server полностью NUMA-совместимым сервером.

[В начало]

Шифрация файловой системы (EFS)

Файлы баз данных SQL Server могут храниться в зашифрованном NTFS виде. Однако, эту возможность следует использовать с осторожностью, поскольку при этом будут отключены возможности асинхронного ввода-вывода, что может вызвать проблемы производительности. Если ввод-вывод осуществляется с зашифрованным файлом, планировщик SQL Server прерывает свою деятельность пока этот запрос ввода-вывода не буде завершен. Такие операции SQL Server, как упреждающее чтение, тоже будут отключены для зашифрованных EFS файлов. Мы рекомендуем по возможности использовать встроенные в SQL Server 2005 криптографические возможности вместо шифрации средствами EFS.
Использование EFS для SQL Server целесообразно использовать для физической защиты файлов баз данных. Используйте эти возможности на портативных ЭВМ или в тех инсталляциях, где необходима физическая защита данных.
Если сервер должен быть развернут в среде с EFS шифрацией, желательно выполнить следующие рекомендации:

  • Используйте выделенный экземпляр SQL Server.

  • Протестируйте производительность приложения и СУБД в такой конфигурации.

  • Протестируйте работу сервера с привязкой ввода-вывода и без такой привязки. Использование привязки ввода-вывода может обеспечить работу SQL Server в псевдо -асинхронном режиме.

[В начало]

DiskPar.exe

Утилита diskpar предназначена для предотвращения проблем в работе сервера, связанных с выравниванием и нарушением границ сектора. Во время работы подсистем SQL Server выравнивание по границам сектора должно быть правильным, иначе не получить оптимальной производительности. Производители подсистем ввода-вывода должны следовать имеющимся рекомендациям, которые необходимо выполнять для обеспечения правильного, с точки зрения SQL Server, выравнивания по границам сектора. Эти же рекомендации применимы и к Microsoft Exchange Server. То, что написано ниже, взято из документации по Microsoft Exchange Server и всё это применимо к SQL Server.
Не смотря на то, что некоторое хранилища выдают неправильную информацию о размере сектора и трека, использование утилиты diskpar помогает предотвращать нарушение границ в кэше. Если мы имеем дело с подобным диском, то каждое энное (обычно 8-ое) чтение или запись будет выходить за границу, и диск должен будет выполнить две физические операции.
Вначале любого диска есть раздел, который зарезервирован для мастер-блока начальной загрузки (MBR) и который занимает 63 сектора. Это означает, что если наш пользовательский раздел начинается с 64-го сектора, он может пострадать от нарушения границ раздела. Большинство производителей использует начальное смещение по 64-й сектор.
Стоит заглянуть в предлагаемую производителем спецификацию, чтобы убедиться в стандартности этой установки для выбранного Вами дискового массива.

[В начало]

Хранилища данных высокой доступности в постоянной готовности

SQL Server 2005 открывает для решений с высокой доступностью новую программу для хранилищ в постоянной готовности (Always On). Поставщики подобных хранилищ проанализировали соответствие этих решений требованиям для Microsoft SQL Server и опубликовали документы, в которых подробно описано, как соответствующие решения могут использоваться совместно с SQL Server, чтобы обеспечить постоянную готовность. Для получения более подробной информации, см. What are SQL Server Always on Technologies?

[В начало]

SQLIOSim

Утилита SQLIOSim выпущена взамен SQLIOStress. Она используется для тестирования характерной SQL Server нагрузки ввода-вывода, и не требует для этого установки самого SQL Server. В тестах не используются настоящие базу данных и журналы SQL Server, но они эмулируются. Эта утилита имеет большой диапазон установок для характеристик тестирования, позволяет регулировать объём используемой памяти, число файлов баз данных, позволяет сжимать и увеличивать файлы, работать с файлами больше 4ГБ и мн. др.
Мы рекомендуем использовать SQLIOSim для проверки подсистем ввода-вывода перед тем, как Вы приступите к установке SQL Server. Это поможет Вам обезопасить данные.

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

    Важно: Утилиты SQLIOSim и SQLIOStress используются также и в Microsoft Hardware Compatibility Labs, а также и многими производителями дисковых подсистем, это позволяет им удостовериться в том, что подсистема ввода-вывода соответствует требованиям SQL Server для операций ввода-вывода. Если SQLIOSim или SQLIOStress выдают ошибки, это говорит о том, что подсистема ввода-вывода не соответствует уровню совместимости HCL-compliant. Это может привести к серьезным повреждениям данных или даже к их потере.

[В начало]

Заключение

Для получения более подробной информации:
http://technet.microsoft.com/ru-ru/sqlserver/default.aspx

Этот документ Вам помог? Пожалуйста, оцените полезность этого документа. Масштаб оценок: от 1 (очень плохо) до 5 (отлично), Ваша оценка этого документа?

[В начало]

Ссылки

Когда Вы занимаетесь установкой подсистемы ввода-вывода, необходимо учесть очень много разных аспектов. В этом разделе собран список документов, которые было бы полезно изучить.
Для получения информации о связанных с вводом-выводом обновлениях, Вы можете также посетить веб-страницу http://www.microsoft.com/sql/support.

[В начало]

Публикации на SQL.RU

  • http://www.sql.ru/articles/Publications.shtml#151

  • [В начало]

    SQL Server Always Storage Solution Review Programv

  • http://www.microsoft.com/sql/AlwaysOn

  • [В начало]

    Certification Policy

  • KB913945 - Microsoft does not certify that third-party products will work with Microsoft SQL Server

  • KB841696 - Overview of the Microsoft third-party storage software solutions support policy

  • KB231619 - How to use the SQLIOStress utility to stress a disk subsystem such as SQL Server

  • [В начало]

    Fundamentals and Requirements

  • White paper - SQL Server 2000 I/O Basics (applies to SQL Server versions 7.0, 2000, and 2005)

  • KB230785 - SQL Server 7.0, SQL Server 2000 and SQL Server 2005 logging and data storage algorithms extend data reliability

  • KB917047 - Microsoft SQL Server I/O subsystem requirements for the tempdb database

  • KB231347 - SQL Server databases not supported on compressed volumes (except 2005 read only files)

  • [В начало]

    Subsystems

  • KB917043 - Key factors to consider when evaluating third-party file cache systems with SQL Server

  • KB234656 - Using disk drive caching with SQL Server

  • KB46091 - Using hard disk controller caching with SQL Server

  • KB86903 - Description of caching disk controls in SQL Server

  • KB304261 - Description of support for network database files in SQL Server

  • KB910716 - Requirements for SQL Server 2005 and SQL Server 2000 to support remote mirroring of user databases

  • KB833770 - Support for SQL Server 2000 and SQL Server 2005 on iSCSI technology components

  • [В начало]

    Design and Configuration

  • White paper - Physical Database Layout and Design

  • KB298402 - Understanding How to Set the SQL Server I/O Affinity Option

  • KB78363 - When Dirty Cache Pages are Flushed to Disk

  • White paper - Database Mirroring in SQL Server 2005

  • White paper - Database Mirroring Best Practices and Performance Considerations

  • KB910378 - Scalable shared database are supported by SQL Server 2005

  • MSDN article - Read-Only Filegroups

  • KB156932 - Asynchronous Disk I/O Appears as Synchronous on Windows NT, Windows 2000, and Windows XP

  • [В начало]

    Diagnostics

  • KB826433 - Additional SQL Server Diagnostics Added to Detect Unreported I/O Problems

  • KB897284 - SQL Server 2000 SP4 diagnostics help detect stalled and stuck I/O operations (applies to SQL Server 2005)

  • KB828339 - Error message 823 may indicate hardware problems or system problems in SQL Server

  • KB167711 - Understanding Bufwait and Writelog Timeout Messages

  • KB815436 - Use Trace Flag 3505 to Control SQL Server Checkpoint Behavior

  • KB906121 - Checkpoint resumes behavior that it exhibited before you installed SQL Server 2000 SP3 when you enable trace flag 828

  • WebCast - Data Recovery in SQL Server 2005

  • [В начало]

    Known Issues

  • KB909369 - Automatic checkpoints on some SQL Server 2000 databases do not run as expected

  • KB315447 - SQL Server 2000 may be more aggressive with Lazy Writers than SQL Server 7.0

  • KB818767 - Improved CPU Usage for Database Logging When Transaction Log Stalls Occur

  • KB815056 - You receive an "Error: 17883" error message when the checkpoint process executes

  • KB915385 - A snapshot-based database backup restore process may fail, and you may receive an error message in SQL Server 2005

  • Support Assistance (http://www.microsoft.com/sql/support)

  • [В начало]

    Utilities

  • Download - SQLIO Disk Subsystem Benchmark Tool

  • Download - SQLIOStress utility to stress disk subsystem (applies to SQL Server 7.0, 2000, and 2005 - replaced with SQLIOSim)

  • [В начало]

    Перевод: Александра Гладченко  2007г.

    Rambler's Top100 Рейтинг@Mail.ru  Administrator: Обратная связь 
    Copyright: SQL.Ru 2000-2013