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

Время жизни "грязных" страниц - страница считается "грязной", когда имели место изменения её данных. Грязная страница не может быть удалена из буферного пула SQL Server, пока вначале связанные с ней записи журнала транзакций и затем сама страница не будут записаны непосредственно на долговременный носитель. Увеличение интервала прохождения контрольной точки (после увеличения интервала регенерации) под высокой нагрузкой системы провоцирует вытеснение обработки грязных страниц под управление кода программы отложенной записи. Это может привести к полной деградации производительности, потому что отложенная запись не предназначена для исполнения действий, подобных контрольной точке.
Программа отложенной записи действительно исполняет соответствующие её действия с грязными страницами, чтобы обеспечить гарантию целостности данных и высвобождение свободного места, но, в отличие от процесса контрольной точки, она не приспособлена для сокращения времени жизни грязных страниц. Контрольные точки позволяют более продуктивно сохранять грязные страницы. Передача функций контрольных точек программе отложенной записи увеличит время ожидания, потому что отложенная записи вынуждена исполнять I/O для отложенных буферов, вместо простых операций в памяти, обеспечивающих свободное место. Если Вы изменили интервал регенерации, нужно проверить показания счётчиков производительности, относящиеся к программе отложенной записи.

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

Продолжительность регенерации - Увеличение интервала регенерации может привести к увеличению времени регенерации. Если SQL Server не штатно завершает свою работу (неожиданное завершение процесса или, например, происходит падение напряжения), во время следующего старта, менеджер регенерации обеспечивает правильность состояния транзакций базы данных. Если контрольная точка запускается не часто, и это приводит к значительному увеличению числа грязных страниц, не штатное завершение потребует для менеджера регенерации исполнение большого числа откатов и проверки транзакций, необходимых для возврата базы данных к непротиворечивому состоянию транзакций. Основным фактором, влияющим на производительность этой операции, является то, что буферный пул SQL Server будет "холодным" (в памяти не будет страниц) во время регенерации. Процедура восстановления должна будет считать в память все соответствующие страницы базы данных и сделать необходимые изменения. Это может увеличить время ожидания регенерации, что является нежелательным для промышленных применений. Увеличение интервала регенерации часто приводит к потерям в производительности и к дискриминации требований к доступности приложений.
Например, предположим, что при штатной загрузке системы контрольная точка каждую минуту должна сбрасывать на диск 250 Мб грязных буферов. В соответствии с алгоритмом работы контрольной точки, при интервале регенерации в 10 минут, на диск будет сброшено 2500 Мб данных, если все другие влияющие факторы останутся постоянными. Если продолжительность контрольной точки превысить величину интервала, тогда для этого дискового массива стоит увеличить число дисков, что бы все страницы успевали обрабатываться, и возможности параллельной обработки были задействованы полностью. Однако, 2500 Мб грязных страниц сами по себе потребуют достаточно больших затрат для поддержания удовлетворительной работы процесса регенерации.

Обзор моделей резервирования

Microsoft SQL Server 2000 использует несколько моделей резервирования баз данных: Full, Bulk-Logged и Simple. Рабочая нагрузка прикладной системы при разных моделях резервирования может получить разное поведение I/O. Приложение, аппаратное решение и модель резервирования должны выбираться из бизнес - требований к развертываемой системе по резервированию и восстановлению.

Сброс на диск записей журнала транзакций

Записи журнала сбрасываются на диск аналогично страницам данных. За запись в журнале базы данных отвечает менеджер журнала транзакций. Вы можете сделать запрос к таблице sysprocesses, чтобы увидеть относящиеся к журналу транзакций SPID.
Когда запрашивается сброс на диск всех записей журнала до какого-нибудь номера LSN по требованию одного из системных потоков, такой запрос будет поставлен в очередь менеджера журнала. Процесс будет ждать ответа менеджера о том, что I/O завершился успешно. Менеджер журнала просматривает очередь и форматирует запросы. После этого он организует I/O кратными размеру сектора диска блоками.
I/O передаётся функции WriteFile, использующей OVERLAPPED (асинхронные) механизмы. После этого, менеджер журнала возвращается к обслуживанию других, поставленных в очередь запросов. Когда I/O будет закончен, отрабатывает завершающая его подпрограмма, которая проверяет успешность записи. Если запись прошла успешно, ожидающий процесс получит об этом сообщение, и может продолжить свои операции.
На этой стадии, порядок записи является критичным. Поскольку одному журналу может быть направлен запрос на несколько операций записи, должен соблюдаться порядок обслуживания LSN.
Например, если страницы 50, 100 и 200 изменяются в разных транзакциях, и сначала изменяется страница 50, потом 100, а затем 200. Тогда, при получении запросов на сброс LSN для страниц 50, 100 и 200, он будет выполнен в том же самом порядке. Если записи в журнале для страниц 50 и 200 будут сброшены на диск долговременного носителя, считается выполненным только сброс LSN для страницы 50, и SQL Server сбросит на диск только страницу 50. LSN для страницы 100 должен быть сброшен на диск долговременного носителям прежде, чем LSN 100, и только потом LSN 200 может считаться сброшенным на диск (журнал фиксируется).
Порядок записи - ключевой элемент поддержки целостности данных в SQL Server.

Упреждающее чтение (Read-Ahead)

Для упреждающего чтения SQL Server 2000 использует функцию ReadFileScatter. Для поиска страниц данных, которые могут скоро понадобиться, SQL Server использует довольно сложные алгоритмы.
Например, если выполняется запрос, который может использовать индекс, может быть принято решение о необходимости упреждающего чтения соответствующих ему строк из страниц фактических данных, которые необходимы для получения требуемой выборки. Поскольку элементы индекса идентифицированы, SQL Server может генерировать OVERLAPPED (async) операции I/O для страниц данных, которые планируются в следующих шагах плана исполнения запроса. Это демонстрирует то, как запрос использует упреждающее чтение для поискового оператора - bookmark lookup.
В этом примере продемонстрирована только одна из возможностей применения упреждающего чтения, которые задействованы в SQL Server. Извлечение во время поиска по индексу I/O страниц данных, повышает полезность утилизации в системе CPU и I/O. Зачастую этот I/O завершается к тому времени, когда это необходимо, и следующие шаги плана исполнения уже имеют прямой доступ к необходимым данным, располагающимся уже в памяти, и не нужно прерываться на ожидании извлекающего их I/O.
Когда вызывается упреждающее чтение, оно может охватить от 1 до 1024 страниц. Для большинства редакций SQL Server глубина запроса одного упреждающего чтения ограничивается 128 страницами. Однако, Microsoft SQL Server Enterprise Edition поднимает это ограничение до 1024 страниц.
SQL Server использует следующие шаги для организации упреждающего чтения:

1. Получение необходимого количества буферов из свободной области.

2. Для каждой страницы:

   1. Определение статуса нахождения страницы в оперативной памяти (in-memory), путём хеш-поиска.

   2. Если обнаружено, что страница уже находиться в памяти, организуется запрос на упреждающее чтение с немедленным возвратом буфера в свободную область после завершения I/O.

   3. Определяются параметры запроса на I/O для вызова функции ReadFileScatter.

   4. Организуется краткая I/O блокировка, для защиты буфера от доступа на время операции.

   5. Если хеш-поиск не обнаружил страницу, она вставляется в хеш-таблицу.

3. Исполнение операций функции ReadFileScatter по чтению данных.

Когда закончится операция I/O, каждая страница проверяется на соответствие её номера и возможность обрыва страниц. Кроме того, выполняются и другие проверки целостности и безопасности данных. Краткая I/O блокировка снимается, и страница становится доступна для использования, если она расположена в цепи хеширования. Если выясниться, что страница уже находиться в памяти, страница немедленно будет возвращена в свободную область.
Этот процесс демонстрирует ключевые факторы I/O экземпляра SQL Server. Упреждающее чтение возможно для страниц, которые уже могут находиться в памяти или не распределены. Поскольку в SQL Server поддерживается буферизация в оперативной памяти (in-memory buffers) и цепочки хеширования, SQL Server должен отслеживать состояние страниц. Важно, что процесс упреждающего чтения даёт возможность перекрытия запросов на чтение и запись на аппаратном уровне.
Если страница уже находится в памяти, когда отправлен запрос на упреждающее чтение, непрерывное чтение все еще остаётся необходимым и более быстрым, чем разбивка запросов на чтение на множество физических запросов. SQL Server практически не использует такое чтение для запрашиваемой страницы, но многие из окружающих её страниц могут его использовать. Однако, если в момент запроса на чтение будет выполняться операция записи, соответствующая подсистема должна определить, какой из этих типов чтения будет возвращён. Некоторое реализации возвращают текущую версию страницы до того, как будет закончена запись. В других реализациях, чтение ожидает, пока запись не будет завершена, а многие другие реализации возвращают комбинацию, показывающую частично новые и старые данные. Ключом к пониманию того, как это реализовано в SQL Server, является то, что чтение не используется, но подсистема сервера должна поддерживать достоверный образ для следующих операций чтения. Осуществляемая запись, в момент её завершения, должна формировать следующий образ операциям чтения, предоставляемый для дальнейшего использования в SQL Server. Не путайте упреждающее чтение с параллельными планами исполнения запросов. Упреждающее чтение происходит независимо от выбора вариантов параллельного плана запроса. Параллельный план может управлять нагрузкой I/O, потому что разделяет её между несколькими потоками, а упреждающее чтение выполняется и для последовательных и для параллельных планов. Для гарантии того, что параллельные потоки не работают с одним и тем же набором данных, SQL Server использует подпрограмму - поставщика параллельных страниц, который помогает сегментировать запросы данных.
В SQL Server реализована расширенная диагностика, которая заранее уведомляет об отказах при чтении. На сайте Microsoft есть статья, которая рассказывает, как включить такую диагностику и какие для этого нужно использовать команды.
Additional diagnostics added to SQL Server to detect unreported read failures

Требования I/O к ядру Microsoft SQL Server

Долговременные носители

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

Порядок записи

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

Предотвращение прерывания I/O (разбиение I/O)

В SQL Server блоки по 8 Кб должны использоваться как единый блок данных. Системы, которые разбивают I/O, должны настраиваться таким образом, чтобы они не раскалывали запросы I/O на блоки меньшего размера. Некоторые динамические диски и менеджеры томов могут устанавливать размер блока, равный размеру кластера, которые могут быть меньше 8 Кб или около 8 Кб. Такие системы могут разделить запрос SQL Server на I/O между несколькими физическими компонентами системы. При этом, они могут привести к появлению оборванных страниц, и этим нарушить порядок следования записи.
Убедитесь, что ваша система не дозволяет разбиения данным по указанной причине, и не приводит к появлению оборванных страниц.

Проблемы, ловушки и их примеры

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

Чтение устаревших данных и оборванная запись

Что такое чтение устаревших данных на аппаратном уровне и чем оно отличается от оборванной записи?
Поскольку чтение устаревших данных может проявиться как оборванная запись, или оборванная запись может появиться как чтение устаревших данных, стоит явно определить эти термины.
Следующие определения предполагают, что все запросы операционной системы исполняются успешно и приложением непривилегированного режима правильно используются соответствующие API.
Чтение устаревших данных (stale read) происходит тогда, когда по данным, возвращаемым через запросы ReadFile или ReadFileScatter, не предоставляется информация об успешности последней операции записи.
Оборванная запись (lost write) определяется тем, что данные, посланные через WriteFile или WriteFileGather, никогда не попадают на долговременный носитель.
Посмотрите внимательно на следующий ниже рисунок, исходя из допущения, что долговременные носители можно абстрагировать к образу ExpandFile.

Рисунок 2

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

• чтение устаревших данных имеет место тогда, когда долговременный носитель содержит данные с "A", но аппаратный кэш возвращает данные с "Z".
• оборванная запись имеет место тогда, когда, когда долговременный носитель содержат символы "Z", а запись фактического значения с "A" не была доведена до успешного завершения.