Основы ввода-вывода SQL Server

Область применения: SQL Server Управляемый экземпляр SQL Azure SQL Server на виртуальной машине Azure

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

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

SQL Server требует, чтобы системы поддерживали гарантированную доставку на стабильный носитель , как описано в соответствии с требованиями программы надежности операций ввода-вывода SQL Server. Дополнительные сведения о требованиях к входным и выходным данным для ядро СУБД SQL Server см. в разделе sql Server ядро СУБД требования к входным и выходным данным диска (ввода-вывода).

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

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

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

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

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

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

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

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

SQL Server has encountered ## occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [##] in database [##] (#). The OS file handle is 0x00000. The offset of the latest long I/O is: 0x00000.

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

Причины длинных запросов ввода-вывода

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

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

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

Длинные ввода-вывода также могут быть вызваны компонентом в пути ввода-вывода (например, драйвер, контроллер или встроенное ПО) постоянно откладывать обслуживание старого запроса ввода-вывода в пользу обслуживания новых запросов. Это может произойти в взаимосвязанных средах, таких как iSCSI и сети каналов волокна (из-за неправильной настройки или сбоя пути). Это может быть трудно подтвердить с помощью средства Монитор производительности, так как большинство I/Os обслуживаются быстро. Длительные операции ввода-вывода могут усугубляться рабочими нагрузками, которые выполняют большой объем операций последовательного ввода-вывода, например: создание резервных копий и восстановление, просмотр таблиц, сортировку, создание индексов, массовую загрузку и очистку файлов.

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

Проблемы с производительностью ввода-вывода, вызванные неэффективными запросами или драйверами фильтров

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

Подробные сведения об устранении этих проблем см. в статье "Устранение проблем с медленной производительностью SQL Server, вызванной проблемами ввода-вывода".

Сведения о настройке антивирусной защиты на SQL Server см. в статье "Настройка антивирусного программного обеспечения для работы с SQL Server".

Запись кэширования в контроллерах хранилища

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

Использование контроллера хранилища кэширования записи (также называемого кэшированием обратной записи) может повысить производительность SQL Server. Контроллеры кэширования и подсистемы хранения безопасны для SQL Server, если они предназначены для использования в среде системы управления критически важными транзакциями баз данных (СУБД). Эти функции проектирования должны сохранять кэшированные данные, если происходит сбой системы. Использование внешней неиспеченной системы питания (UPS) для достижения этого, как правило, недостаточно, так как режимы сбоя, не связанные с питанием, могут возникать.

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

Ведение журнала накануне записи

Инструкции изменения данных SQL Server создают логические записи страниц. Этот поток записей можно сфотографировать как два места: журнал и саму базу данных. По соображениям производительности SQL Server откладывает запись в базу данных через собственную систему буфера кэша. Записи в журнал только временно откладываются до COMMIT времени. Они не кэшируются так же, как и записи данных. Так как журнал записывает данные для данной страницы всегда перед записью данных страницы, журнал иногда называется журналом накануне записи (WAL).

Протокол ведения журналов (WAL) для записи

Протокол терминов является отличным способом описания WAL. Wal, используемый SQL Server, называется ARIES (алгоритм восстановления и изоляции семантики эксплойтов). Дополнительные сведения см. в разделе "Управление ускорением восстановления базы данных".

Это конкретный и определенный набор шагов реализации, необходимый для обеспечения правильного хранения и обмена данными и их восстановление в известном состоянии в случае сбоя. Так же, как сеть содержит определенный протокол для обмена данными согласованным и защищенным способом, поэтому wal описывает протокол для защиты данных. Все версии SQL Server открывают файлы журналов и данных с помощью функции Win32 CreateFile . Член dwFlagsAndAttributes включает параметр при открытии FILE_FLAG_WRITE_THROUGH SQL Server.

FILE_FLAG_WRITE_THROUGH

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

Этот FILE_FLAG_WRITE_THROUGH параметр гарантирует, что при успешном завершении операции записи данные хранятся в стабильном хранилище. Это соответствует спецификации протокола "Запись вперед" (WAL) для обеспечения данных. Многие устройства хранения (NVMe, PCIe, SATA, ATA, SCSI и IDE) содержат кэши подключения размером 512 КБ, 1 МБ и больше. Кэши хранилища обычно полагаются на capacitor, а не на решение, поддерживаемое батареей. Эти механизмы кэширования не могут гарантировать запись в цикле питания или аналогичной точке сбоя. Они гарантируют только завершение операций записи в секторе. По мере того как устройства хранения продолжают увеличиваться, кэши становятся больше, и они могут предоставлять большие объемы данных во время сбоя.

Дополнительные сведения о поддержке FUA дистрибутивом Linux и его влиянии на SQL Server см. в статье SQL Server On Linux: внутренние внутренние компоненты принудительного доступа к единицам (FUA).

Целостность транзакций и восстановление SQL Server

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

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

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

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

Запись контроллеров устройств хранения и кэширования

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

Даже если сервер использует UPS, это не гарантирует безопасность кэшированных операций записи. Многие типы системных сбоев могут возникать, что upS не адресует. Например, ошибка четности памяти, ловушка операционной системы (ОС) или аппаратный сбой, вызывающий сброс системы, может привести к неконтролируемой прерывании системы. Сбой памяти в кэше записи оборудования также может привести к потере важных сведений журнала.

Другая возможная проблема, связанная с контроллером кэширования записи, может возникнуть при завершении работы системы. Это не редкость, чтобы циклировать ОС или перезапустить систему во время изменений конфигурации. Даже если осторожный оператор следует рекомендации ОПЕРАЦИОННОй системы, чтобы ждать, пока все действия хранилища не будут прекращены до перезапуска системы, кэшированные записи по-прежнему могут присутствовать в контроллере. Ctrl++AltDel При нажатии сочетания клавиш или нажатии кнопки сброса оборудования кэшированные записи могут быть удалены, что может привести к повреждению базы данных.

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

Использование кэшей хранилища с SQL Server

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

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

В этом разделе рассматриваются последствия кэшей хранилища. Рекомендуется ознакомиться со следующими статьями в Базе знаний Майкрософт для дальнейшего уточнения кэширования и альтернативных обсуждений в режиме сбоя:

• 86903 SQL Server и контроллеры дисков кэширования
• Описание алгоритмов ведения журнала и хранилища данных, которые расширяют надежность данных в SQL Server

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

• Основы ввода-вывода SQL Server 2000
• Основные сведения о ввода-выводах SQL Server 2

Эти два документа применяются ко всем поддерживаемым версиям SQL Server.

Решения кэширования с поддержкой батареи

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

Реализации подсистемы хранилища

Существует множество типов реализаций подсистемы. RAID (избыточный массив независимых дисков) и SAN (сеть зоны хранения) являются двумя примерами реализации подсистемы. Обычно эти системы создаются с дисками на основе SCSI. Для этого есть несколько причин. В следующем разделе описаны общие рекомендации по хранению на высоком уровне.

SCSI, SAS и NVMe

Устройства хранения SCSI, SAS и NVMe:

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

Не SCSI

Другие реализации дисков, такие как интегрированная среда разработки, ATA и SATA:

• Обычно производится для использования легких и средних обязанностей.
• Обычно предназначены для отдельных пользовательских приложений.

Контроллеры, отличные от SCSI, требуют больше пропускной способности основного процессора (ЦП) и часто ограничиваются одной активной командой. Например, если диск, отличный от SCSI, корректирует неправильный блок, диск требует ожидания команд узла. Шина ATA представляет еще один пример: шина ATA поддерживает два устройства, но только одна команда может быть активной. Это оставляет один диск бездействия, а другой диск обслуживает ожидающая команда. Системы RAID, созданные на основе классических технологий, могут испытать эти симптомы и значительно повлиять на самый медленный ответ. Если эти системы не используют расширенные проекты, их производительность не так эффективна, как производительность систем на основе SCSI.

Рекомендации по работе с хранилищем

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

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

• Схема пути доступа
• Требование отключения кэша на диске

Механические жесткие диски

Механические диски используют спиннинг магнитных тарелк для хранения данных. Они доступны в нескольких емкостях и форм-факторах, таких как интегрированная среда разработки, SATA, SCSI и последовательный подключенный SCSI (SAS). Некоторые диски SATA включают конструкции прогнозирования сбоев. Диски SCSI предназначены для более тяжелых циклов работы и снижения частоты сбоев.

Кэширование дисков должно быть отключено, чтобы использовать диск с SQL Server. По умолчанию кэш дисков включен. В Windows Server перейдите на вкладку "Свойства диска", чтобы получить доступ к вкладке "Политика свойств>>" для управления параметром кэша диска.

IDE и системы на основе ATA могут откладывать команды узлов при выполнении таких действий, как плохая корректировка блока. Это может привести к периодам остановленного действия ввода-вывода.

Преимущества SAS включают расширенную очередь до 256 уровней, а также главу очереди и очередь вне порядка. Серверная планка SAS разработана таким образом, что позволяет использовать диски SAS и SATA в одной системе.

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

Хранилище с твердым состоянием

Хранилище с твердым состоянием имеет преимущества по сравнению с механическими (спиннингом) жесткими дисками, но подвержено многим из этих же шаблонов сбоев, что и спиннинг-носитель. Хранилище с твердым состоянием подключено к серверу с помощью различных интерфейсов, включая NVM Express (NVMe), PCI Express (PCIe) и SATA. Обратитесь к носителям с твердым состоянием, так как вы будете спиннинговать носитель, и убедитесь, что соответствующие гарантии применяются для сбоя питания, например контроллер кэширования с поддержкой батареи.

Распространенные проблемы, вызванные сбоем питания, включают:

• Битовое повреждение: записи демонстрируют случайные битовые ошибки.
• Летающие записи: Хорошо сформированные записи в конечном итоге в неправильном месте.
• Шорн пишет: операции частично выполняются на уровне ниже ожидаемого размера сектора.
• Повреждение метаданных: метаданные в FTL повреждены.
• Неответственное устройство: устройство не работает вообще или в основном не работает.
• Несериализируемость: окончательное состояние хранилища не приводит к сериализуемому порядку операций.

512e

Большинство объемов хранилища с твердым состоянием сообщает о 512-байтовом секторе, но используйте 4 КБ-страницы в блоках стирки 1 МБ. Использование 512-байтовых секторов для устройства журнала SQL Server может создавать дополнительные действия чтения и записи (RMW), что может способствовать снижению производительности и износу диска.

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

0xFFFFFFFF

Недавно отформатированный диск обычно содержит все нули. Стертый блок твердого состояния устройства все 1s, что делает необработанный считывания стертого блока все 0xFF. Тем не менее, это необычно для пользователя, чтобы прочитать стертый блок во время обычных операций ввода-вывода.

Метка шаблонов

Метод, который мы использовали в прошлом, заключается в написании известного шаблона на весь диск. Затем при выполнении действия базы данных с тем же диском мы можем обнаружить неправильное поведение (устаревшее чтение и потеря записи/ чтение неправильного смещения/т. д.) при неожиданном появлении шаблона.

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

Firmware (Встроенное ПО)

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

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

Распространенный подход к сбору мусора (GC) для хранилища с твердым состоянием помогает предотвратить повторяющиеся повреждения данных. При чтении одной и той же ячейки возможно, что электронное действие может утечки и причинить ущерб соседним ячейкам. Хранилище сплошным состоянием защищает данные с различными уровнями кода исправления ошибок (ECC) и другими механизмами.

Один из таких механизмов связан с выравниванием износа. Хранилище с твердым состоянием отслеживает действие чтения и записи на устройстве хранения. Сборка мусора может определять горячие точки или расположения, которые будут носиться быстрее, чем другие расположения. Например, GC определяет, что блок был в состоянии только для чтения в течение определенного периода времени и должен перемещаться. Как правило, это движение к блоку с большей износом, поэтому исходный блок можно использовать для записи. Это помогает сбалансировать износ на диске, но перемещает данные только для чтения в расположение, которое имеет больше износа и математически увеличивает вероятность сбоя, даже если немного.

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

Ошибка ОС 665 и дефрагментация

Спиннинг мультимедиа должен держать блоки рядом друг с другом, чтобы уменьшить движение головы диска и повысить производительность. Хранилище с твердым состоянием не имеет физической головы, что устраняет время поиска. Многие устройства с твердым состоянием предназначены для параллельного выполнения параллельных операций в разных блоках. Это означает, что дефрагментация носителей твердого состояния не требуется. Последовательные действия — это лучшие шаблоны операций ввода-вывода для максимальной пропускной способности ввода-вывода на устройствах хранилища с твердым состоянием.

Рекомендации.

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

• Рекомендуется использовать файловую систему ReFS , чтобы избежать ограничений атрибутов NTFS.

• Убедитесь, что размер файла соответствует размеру.

Дополнительные сведения об устранении ошибки ОС 665, связанной с фрагментацией, см. в разделе об ошибках ОС 665 и 1450 для файлов SQL Server.

Сжатие

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

Итоги

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

Рекомендации по кэшу и SQLIOSim

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

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

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

SQL Server требует, чтобы системы поддерживали гарантированную доставку на стабильный носитель, как описано в соответствии с требованиями программы надежности операций ввода-вывода SQL Server. Дополнительные сведения о требованиях к входным и выходным данным для ядро СУБД SQL Server см. в разделе sql Server ядро СУБД требования к входным и выходным данным диска (ввода-вывода).

Связанный контент

• Руководство по архитектуре страниц и экстентов
• Руководство по архитектуре управления памятью
• SQL Server в Linux: внутренние внутренние элементы принудительного доступа к единицам (FUA)
• Основные операции ввода-вывода в SQL Server, раздел 2