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

Флаг трассировки 818

Инструментарий, который включается флагом трассировки -T818, отслеживает операции записи последних 2048 страниц. При успешном завершении I/O записи (верный ID страницы, успешная передача байт, и соответствующие коды ошибок операционной системы), DBID, ID страницы и LSN помещаются в закольцованном буфере. В случае возникновения отказа, будет выставлена ошибка 823.
Когда обнаружена ошибка 823 или 605, SQL Server просматривает кольцевой буфер, ища там значение LSN, которое было зафиксировано для последней, записанной страницы. Если он некорректно, об этом в файл регистрации ошибок SQL Server добавляется дополнительная информация, которая указывает тип ошибки, а также ожидаемый и обнаруженный номера LSN.
Дополнительная информация об LSN, о котором идёт речь, появится в файле регистрации ошибок SQL Server. Возвращаемый после чтения LSN явно старше (устаревший), чем значение, которое соответствует последней записи.

SQL Server has detected an unreported OS/hardware level read or write 
problem on Page (1:75007) of database 12 
LSN returned (63361:16876:181), LSN expected (63361:16876:500)
Contact the hardware vendor and consider disabling caching mechanisms to
correct the problem

С появлением SQL Server 2000 Service Pack 4 (SP4), дизайн -T818 лучше использует хэш-таблицы. Стало доступно более 2048 записей в хэш-памяти для 32-битных редакций, а 64-битных даже ещё больше.
Поскольку мы имеем реализацию в виде хэш-таблицы, проверка чтения устаревших данных может выполняться при каждом чтении, а не только для тех страниц, которые выявлены по предыдущим ошибкам 823 или 605. Эта проверка подобна другому стандарту, по которому проверяется ID объекта страницы (605) и состояние ошибки номера страницы (823). Поскольку проверка выполняется при каждом чтении, это позволяет охватить даже те ситуации, когда ID страницы и ID объекта являются правильными, но строки страницы были повреждены.
Например, если была вставлена строка, страница была сброшена на диск и произошло чтение устаревших данных (строки отсутствуют на диске), ID объекта и ID страницы будут правильными, и до появления SP4, возможно, чтение устаревших данных не было бы зафиксировано. Новый дизайн обнаружит несоответствие LSN и выставит ошибку 823.

Оборванные страницы

Страницы базы данных SQL Server занимают 8 Кб, в то же время, типичный размер передаваемого на аппаратном уровне блока равен 4 Кб, если используются 512-байтные секторы диска. Когда Вы используете конфигурацию с RAID, незаполненные части могут проявиться, как оборванное чтение. Синхронизация чтения и записи может внести путаницу для разных дисков, так что могут быть извлечены частично старые и частично новые данные. Опять, ошибка состоит в том, что после записи, не все части кэша упреждающего чтения были до конца переданы на диск. Не правильный образ сохраняется в аппаратном кэше упреждающего чтения, пока он не будет извлечён принудительно.

Пример сброса на диск аппаратного кэша

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

• Запуск dbcc dropcleanbuffers, после чего будут удалены все буферы из буферного пула.
• Запуск dbcc checkdb для базы данных, имеющих соответствующие проблемы.

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

SQLIOStress.exe

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

[В начало]

Сообщения об ошибках SQL Server

Во время работы SQL Server обнаруживает много разных типов проблем с I/O или нарушений в целостности данных. Обнаруженные проблема I/O или нарушения целостности данных сохраняются SQL Server в виде сообщений об ошибках. Наиболее типичные ошибки - 605, 823, 624 и записи об отказах при восстановлении.
Не поддаются обнаружению в SQL Server только несколько ситуаций. Эти ситуации проявляются как логические проблемы данных и обычно генерируют неожиданные исключения на уровне приложения.

Ошибки во время исполнения (run-time)

Ошибки 605 и 823 проявляются непосредственно на этапе исполнения проверки правильности страниц и идентификаторов объектов. Это простые проверки - ловушки на этапе исполнения, которые не влияют на производительность. Проблема состоит в том, что чтение устаревших данных повышает вероятность проявления большого количества потенциально возможных ошибок.

Логические ошибки

Во многих случаях (ошибки 6xx), данные могут потерять логическую согласованность (например, при ошибке 624: Could not retrieve row from page by RID because the requested RID has a higher number than the last RID on the page. %S_RID.%S_PAGE, DBID %d). В качестве примера, можно рассмотреть случай, когда в таблицу вставляется новая строка, но имеет место чтение устаревших данных со страницы индексов, в результате чего, будет потеряна вставка в индекс. Это будет выглядеть так, как будто индекс не изменился, и строк данных в таблице будет больше, чем соответствующих строк в индексе. Это может говорить о том, что ключ индекса выбран неудачно. Если эта часть таблицы - хип, тогда реляционные идентификаторы (RID) могут оказаться неправильными, потому что страницы фактических данных сгруппированы по-другому.
Вы можете придумать и другие, приводящие к ошибкам сценарий, если рассматривать реляционные отношения данных. Если одна из страниц становится жертвой чтения устаревших данных, это может говорить о том, что вставка реально не имела места. Проявляться это может в виде не соответствия ожидаемому числу записей или нарушений первичных и внешних ключей (PK/FK). Всё это очень похоже на то, как будто бы дебет или кредит пользователя не сходится.
Когда подозревается наличие подобных проблем в данных, круг потенциальных источников проблем довольно широк. Данные могут оказаться поврежденными после проверки DBCC checkdb. Это могло быть результатом проблем на этапе исполнения, когда RID индекса вдруг начинает указывать на не те области данных, а это уже может породить множество других проблем, например, исключений или остановок.

Ошибки Log Shipping и отказы восстановления

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

Репликация

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

Промежуточные драйверы (Filter Drivers)

Многие реализации программного обеспечения резервного копирования, антивирусные программы и других приложения, реализованы в виде промежуточных драйверов между подсистемой I/O и операционной системой. Это позволяет перехватывать запросы на I/O и обрабатывать их соответствующим образом. Неправильная работа таких драйверов может стать причиной чтения устаревших данных или прерванной записи.
Часто, проблемы такого типа требуют воспроизводства в тестовой среде и значительных усилий по отладке на уровне ядра, что бы определить первопричину возникновения проблем, которые могут напоминать проблемы с привязанными к драйверу пакетами ввода-вывода (IO Request Packet). Всё это может отнимать много времени и существенно осложнять поддержку работы приложения.
Microsoft рекомендует разработать безопасную стратегию резервирования, но Вы также должны убедиться, что программное обеспечение I/O разработано в соответствии с требованиями к Microsoft SQL Server.

Привязанный I/O

В SQL Server весьма распространены проблемы с промежуточными драйверами, которые используются операционной системой, и из-за которых I/O становится привязанным к промежуточному драйверу и при этом, не обеспечивается средств регистрации или уведомления об ошибках.
Например, служба поддержки SQL Server столкнулся с одной такой проблемой в высокопроизводительной дисковой подсистеме, которая пыталась балансировать запросы на I/O между несколькими Host Bus Adapters (HBA). В программном обеспечении был дефект, который приводил к прерыванию I/O. SQL Server бесконечно ожидал окончания I/O, записав в журнале ошибок о том, что он выставил краткую I/O - блокировку.
Важно: Microsoft рекомендует, чтобы Вы оценили применимость каждого используемого в системе промежуточного драйвера, что бы он выдавал удовлетворительную диагностику проблем и не вредил работе СУБД.

Синхронный I/O

В SQL Server хорошо развиты возможности асинхронного I/O, что позволяет повысить утилизацию используемых им ресурсов. Служба поддержки SQL Server нашла решение для большинства проблем, порождаемых некоторыми промежуточными драйверами, мешавшими асинхронному I/O. Теперь от промежуточного драйвера требуется, чтобы запрос на I/O был завершён до того, как управление снова будет передано SQL Server.
Это легко реализуется, если контролировать длину очереди к дискам. Во время работы, SQL Server обычно использует несколько запросов на I/O. Когда I/O становится синхронным, очередь к дискам часто порождается одним большим запросом на I/O, а это порождает в SQL Server лишние блокировки.
Поскольку показания счётчика disk sec/transfer time не являются статичными, использовать его нужно учитывая этот факт. Когда на диск направляется не много запросов I/O, disk sec/transfer показывает хорошую скорость. Чем больше длина очереди к диску, тем больше разнообразие поведения disk sec/transfer. Однако, SQL Server умеет определять, что в результате асинхронного характера I/O, более длинные очереди к дискам и несколько большие значения disk sec/transfer могут в итоге способствовать повышению производительности и лучшему использованию ресурса.

Целостность данных

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

Компрессия против криптования

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

Компрессия

Windows может сжимать расположенные на диске файлы, что позволяет экономить занимаемое ими место. Сжатие не поддерживается в SQL Server 2000 или его предыдущих версиях. Проблема в том, что когда используется сжатие, данные файла обрабатываются операционной системой большими кусками (например, во 64 Кб). Поэтому, когда SQL Server изменяет страницу данных в 8 Кб, в действительности система работает с большей порцией данных и перезаписывает её.
Такая перезапись данных является нарушением протокола WAL, потому что данные, уже сохранённые на диске будут перезаписаны, и таким образом нарушается правило порядка записи. Перезапись может приводить к кэшированию и другим, подобным действиям, которые не желательны для реализации в базе данных требований ACID. Перезапись также нарушает требования безопасности для границ секторов.
Все файлы журналов транзакций и баз данных SQL Server не должны подвергаться компрессии.

Изменение скорости

Компрессия может привести к тому, что производительность I/O станет узким местом. Служба поддержки Microsoft SQL Server регистрировала возникновение серьезных проблем с I/O, о которых сообщали клиенты, пытавшиеся использовать компрессию. В одном из таких случаев, синхронизация контрольной точки при сбросе на всего нескольких тысяч буферов возросла от нескольких секунд до минут. Объём работы, требуемый для обслуживания компрессии не только повышает нагрузку на систему, но и увеличивает время кратких блокировок, накладываемых до завершения I/O, что негативно сказывается на весь SQL Server.

Базы данных в режиме - только для чтения

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

Криптование

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

Файл подкачки и листание

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

Флаг трассировки -T815

Для облегчения обнаружения нежелательных изменений страниц данных в оперативной памяти, для SQL Server вводиться флаг трассировки -T815, которые расширяет возможности принудительных кратких блокировок. Когда для внесения изменений на страницу накладывается краткая блокировка, VirtualProtect страницы устанавливается в PAGE_READWRITE. В остальное время уровень её защиты будет - PAGE_READONLY. Это помогает перехватывать такие операции в памяти, как наложенная запись (scribblers).
Начиная с версии Microsoft SQL Server 2000 v. 8.00.0922, появилась возможность динамического переключения флага трассировки -T815, с использованием инструкций Transact-SQL: DBCC TRACEON и DBCC TRACEOFF.
Важно: Принудительные краткие блокировки допустимы только для тех систем, которые не используют AWE (Address Windowing Extensions) режимы.

Онлайновые копии файлов

Некоторые аппаратные средства резервирования от третьих фирм предоставляют возможность создания резервных копий открытых каким - либо ПО файлов, путём их отражения на аппаратном уровне. Поскольку SQL Server монопольно открывает все свои файлы баз данных и журналов, такое отражение возможно только на уровне промежуточных драйверов или на аппаратном уровне.
Типичной проблемой подобных решений является то, что они не поддерживают порядок меток времени для подобных снимков файлов. Данные копируются в то время, когда SQL Server всё ещё продолжает работу, а это может нарушить порядок записи и семантику меток времени, и привести к невозможности восстановления файлов баз данных.
Некоторые производители таких аппаратных средств реализуют в своих системах возможности создания правильных снимков, для чего используется документированная объектная модель SQL Server Virtual Device Interface (VDI). Это единственный безопасный способ фиксировать I/O с соблюдением меток времени для всех используемых файлов баз данных.

Повторяющееся чтение

Повторяющееся чтение поддерживается в Microsoft SQL Server 2000 только для операций сортировки. В следующих версиях SQL Server может появиться повторяющееся чтение и для других операций I/O.
Служба поддержка Microsoft SQL Server сталкивалась с проблемами, связанными с повторяющимся чтением. В некоторых системах фиксировалось чтение не корректных данных. Логика сортировки в SQL Server может порождать чтение тех же данных (повторяющееся чтение), и при последнем чтении данные считываются правильными. Поскольку данные должны возвращаться правильными и при первом чтении, это указывает на проблемы с хранилищем.
Предупреждение: Если ваша система не показывает признаки успешного повторяющегося чтения, это нужно рассмотреть, как серьёзный повод для беспокойства.

DBCC с опцией REPAIR

Когда происходят сбои операций I/O, считается общепринятым чаще выполнять проверку согласованности базы данных. Это помогает получить больше подробностей о степени серьёзности проблем и затрагиваемых ими участков данных.
Предупреждение: Не стоит злоупотреблять DBCC REPAIR, для исправления проблем данных. Любые их нарушения, и особенно постоянные, повторяющиеся искажения, являются симптомами более глубоких проблем, и часто связанных с используемыми долговременными носителями.

Утилиты

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

SQLIOStress.exe

SQLIOStress.exe моделирует разные схемы поведения I/O в SQL Server 2000, что позволяет проверить безопасность I/O на самом простом уровне.
Утилита SQLIOStress может быть загружена с сайта Microsoft. Ниже, представлена ссылка на статью с её описанием.

• How to Use the SQLIOStress Utility to Stress a Disk Subsystem such as SQL Server

Важно: Загружаемый дистрибутив содержит подробное описание этой утилиты.

SQLIO.exe

SQLIO.exe - это утилита эталонного тестирования I/O для SQL Server 2000. Она также может быть загружена с сайта Microsoft.

• SQLIO Performance Testing Tool (SQL Development) - Customer Available

Заключение

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