Поделиться через

  • Статья

Управление буферами

Главное назначение базы данных SQL Server — хранение и поиск данных, поэтому интенсивное использование операций дискового ввода-вывода — это основное свойство компонента Database Engine. А так как дисковые операции ввода-вывода могут потреблять много ресурсов и требовать относительно длительного времени для выполнения, SQL Server обращает огромное внимание на рациональное использование операций ввода-вывода. Управление буфером — это ключевой компонент в достижении этой рациональности. Компонент управления буфером состоит из двух механизмов: диспетчер буферов для доступа и обновления страниц базы данных и буферный кэш (известный как буферный пул) для сокращения операций ввода-вывода файла базы данных.

Принцип работы управления буфером

Буфер — это 8-килобайтовая (КБ) страница в памяти такого же размера, что и страница данных или индекса. Буферный кэш делится на 8-килобайтовые страницы. Диспетчер буферов содержит функции чтения страниц данных или индекса из файлов базы данных на диске в буферный кэш и записывает измененные страницы обратно на диск. Страница остается в буферном кэше до тех пор, пока диспетчеру буферов не понадобится область буфера для считывания дополнительных данных. Данные записываются обратно на диск, только если они были изменены. Данные в буферном кэше могут измениться несколько раз, прежде чем будут сохранены обратно на диске. Дополнительные сведения см. в разделах Считывание страниц и Запись страниц.

Во время запуска SQL Server вычисляет размер виртуального адресного пространства для буферного кэша, основанного на ряде параметров, например: количество физической памяти в системе, указанное максимальное количество потоков сервера и различные параметры запуска. SQL Server резервирует этот объем виртуального адресного пространства процесса (целевой объем памяти) в буферном кэше, но получает (фиксирует) только необходимый объем физической памяти, требуемый для текущей загрузки. Можно запросить столбцы bpool_commit_target и bpool_committed в представлении каталога sys.dm_os_sys_info, чтобы получить количество зарезервированных страниц в качестве указателя памяти и количество зафиксированных страниц в буферном кэше соответственно.

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

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

  • Диспетчер ресурсов управляет полным использованием памяти и использованием адресного пространства на 32-разрядных платформах.

  • Диспетчер базы данных и операционная система SQL Server (SQLOS) для низкоуровневых операций файлового ввода-вывода.

  • Диспетчер журнала для упреждающего ведения журнала.

Поддерживаемые возможности

Диспетчер буферов поддерживает следующие возможности:

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

  • Диспетчер буферов поддерживает технологию памяти с «горячей» заменой, которая позволяет пользователям добавлять физическую память, не перезапуская сервер. Дополнительные сведения см. в разделе Память с «горячей» заменой.

  • Диспетчер буферов поддерживает динамическое распределение памяти на 32-разрядных платформах Microsoft Windows XP и Windows 2003, если включены расширения AWE. Динамическое распределение памяти позволяет компоненту Database Engine эффективно получать и освобождать память в буферном кэше, чтобы поддерживать текущую рабочую нагрузку. Дополнительные сведения см. в разделе Динамическое управление памятью.

  • Диспетчер буферов поддерживает большие страницы на 64-разрядных платформах. Размер страницы зависит от версии Windows. Дополнительные сведения см. в документации по Windows.

  • Диспетчер буферов обеспечивает дополнительную диагностику, выполняемую с помощью динамических представлений управления. Можно использовать эти представления, чтобы контролировать различные ресурсы операционной системы, характерные для SQL Server. Например, можно использовать представление sys.dm_os_buffer_descriptors, чтобы контролировать страницы в буферном кэше. Дополнительные сведения см. в разделе Динамические административные представления, связанные с операционной системой SQL Server (Transact-SQL).

Операции дискового ввода-вывода

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

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

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

  • Все операции ввода-вывода происходят в вызывающих потоках, если не используется параметр affinity I/O. Параметр «affinity I/O mask» привязывает операцию дискового ввода-вывода SQL Server к определенному подмножеству ЦП. В средах высокоскоростной обработки транзакций (OLTP) SQL Server данное расширение может улучшать производительность потоков SQL Server, выдающих вводы-выводы.

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

Длительные запросы операций ввода-вывода

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

SQL Server обнаружил %d запросов ввода-вывода, выполняющихся более %d секунд, в файле [%ls] базы данных [%ls] (%d). Дескриптор файла ОС — 0x%p. Смещение последней длительной операции ввода-вывода — %#016I64x.

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

Причины длительных запросов операций ввода-вывода

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

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

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

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

Длительные операции ввода-вывода также могут быть вызваны компонентом в пути ввода-вывода (например драйвером, контроллером или программой ПЗУ), постоянно откладывающим обслуживание старого запроса ввода-вывода в пользу обслуживания более новых запросов, которые ближе к текущей позиции головки диска. Основная методика обработки запросов, которые наиболее близки к текущей позиции головки для чтения-записи, называется «элеваторный поиск». Это довольно сложно отследить с помощью системного монитора Windows (PERFMON.EXE), так как большинство операций ввода-вывода выполняется быстро. Длительные операции ввода-вывода могут усугубляться рабочими нагрузками, которые выполняют большой объем операций последовательного ввода-вывода, например: создание резервных копий и восстановление, просмотр таблиц, сортировку, создание индексов, массовую загрузку и очистку файлов.

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

Определение ошибки

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

Защита от разрыва страницы

Защита от разрыва страницы, включенная в SQL Server 2000, является прежде всего способом обнаружения поврежденных страниц из-за сбоев питания. Например, неожиданный сбой питания может оставить только часть страницы, записанной на диск. Когда используется защита от разрыва страницы, в конце каждого 512-байтового сектора на странице помещается 2-битовая подпись (исходные два бита копируются в колонтитул). Подпись чередуется двоичными числами 01 и 10 после каждой записи, так что всегда можно определить, когда на диск записана только часть секторов. Если бит имеет неверное состояние, когда читается страница, значит она была записана неправильно и обнаружен разрыв страницы. Защита от разрыва страницы использует минимальные ресурсы, однако она не обнаруживает все ошибки, вызванные аппаратными сбоями диска.

Защита контрольной суммой

Защита контрольной суммой, включенная в SQL Server 2005, обеспечивает более надежную проверку целостности данных. Контрольная сумма рассчитывается для данных каждой записанной страницы и сохраняется в колонтитуле. Всякий раз, когда страница с сохраненной контрольной суммой читается с диска, компонент Database Engine повторно вычисляет контрольную сумму для данных страницы и вызывает ошибку 824, если новая контрольная сумма отличается от сохраненной. Защита контрольной суммой может перехватить больше ошибок, чем защита от разрыва страницы, потому что она учитывает каждый байт страницы, однако она более ресурсоемкая. Когда защита контрольной суммой активирована, ошибки, вызванные сбоями питания и поврежденным оборудованием или программой ПЗУ, могут быть обнаружены во время чтения страницы с диска диспетчером буферов.

Вид используемой защиты страницы является атрибутом базы данных, содержащей страницу. Защита контрольной суммой задана по умолчанию для баз данных, созданных в SQL Server 2005 и более поздних версиях. Механизм защиты страницы указывается во время создания базы данных и может быть изменен с помощью инструкции ALTER DATABASE. Установку защиты текущей страницы можно определить с помощью запроса значения столбца page_verify_option в представлении каталога sys.databases или свойства IsTornPageDetectionEnabled функции DATABASEPROPERTYEX. Если установка защиты страницы изменена, новая установка сразу не влияет на всю базу данных. Вместо этого страницы принимают текущий уровень защиты базы данных во время следующей записи. Это означает, что база данных может состоять из страниц с различными видами защиты.