MS SQL Server и кэширующие дисковые контроллеры + FAQ
По материалам статьи Microsoft Knowledge Base "INF: SQL Server and Caching Disk Controllers".
Информация в этой статье относится к Microsoft SQL Server версий: 4.2x, 6.0, 6.5, 7.0, 2000.
Использование дисковых контроллеров, кэширующих запись (такой механизм называется отложенной
записью - write back caching), может существенно поднять эффективность SQL Server. Дисковые
контроллеры (кэширующие запись) и дисковые подсистемы могут быть безопасны для SQL Server,
если они специально разработаны для использования в критичной к потере данных среде, какими
являются современные системы управления базами данных (DBMS - СУБД) использующие транзакционные
механизмы обслуживания информации. Эти их особенности должны предотвращать потерю кэшированных
данные, если происходит отказ системы. Достигнуть этого только путём использования источников бесперебойного
питания (ИБП - UPS) не достаточно, потому что система может отказать по причинам, которые не связаны с
энергообеспечением. Использование большинства кэширующих контроллеров и дисковых подсистем может
быть безопасно для работы совместно с SQL Server. Современные серверные платформы, как правило,
безопасны. Однако, Вы должны получить у своего поставщика серверных решений информацию о том, что
дисковая подсистема была проверена и одобрена для использования в транзакционной среде RDBMS.
Инструкции SQL Server, модифицирующие данные, инициируют запись логических страниц. Этот поток
записываемых страниц, может иметь два места назначения: журнал регистрации транзакций или
непосредственно сама база данных. Что бы повысить эффективность этих операций, SQL Server задерживает
запись в базу данных, размещая страницы в кэше данных, буферизируя, таким образом, систему записи
модифицированных страниц. Запись в журнал транзакций имеет очень маленькую задержку после
получения инструкции COMMIT. Они не кэшируются также как данные. Поскольку регистрация
изменений страниц в журнале всегда предшествует записи страниц данных, журнал регистрации транзакций
иногда называют журналом "write-ahead".
Целостность транзакций - одна из фундаментальных задач, решаемая современной СУБД. Транзакции
являются не делимыми, целостными модулями инструкций, которые выполняются полностью или
откатываются полностью назад. Журнал регистрации транзакций SQL Server (write-ahead), это жизненно
важный компонент в системе поддержки целостности транзакций. Любая СУБД должна включать систему
поддержки целостности транзакций, которая позволяет восстанавливать работоспособность базы после
незапланированных отказов системы. Увы, идеальную с этой точки зрения систему создать очень трудно и
поэтому подобные отказы всё-таки могут случаться. Для многих СУБД отказ системы может привести к
необходимости выполнения очень продолжительных, ручных процедур по восстановлению целостности
данных или по восполнению утраченной информации. Напротив, механизм восстановления данных после
сбоя в SQL Server полностью автоматизирован и работает без вмешательства оператора. Например, SQL
Server может поддерживать критическое приложение, промышленную прикладную программу, и пережить
отказ системы из-за мгновенного колебания напряжения в электросети. После восстановления электропитания,
аппаратные средства сервера перезагрузят программное обеспечение операционной системы и SQL Server.
После запуска, SQL Server автоматически выполнит процесс восстановления, основанный на данных в
журнал регистрации транзакций. Этот процесс полностью проходит без вмешательства оператора. Всякий
раз, после перезагрузки своих рабочих станций, пользователи могут убедиться, что их данные не пострадали,
включая последнюю транзакцию, которую они ввели. Механизм поддержки целостности транзакций SQL
Server и автоматического восстановления представляет собой очень мощное средство поддержания высокой
производительности системы в любое время (time-and-labor).
Если дисковый контроллер, кэширующий данные, не разработан для использования в транзакционной среде
СУБД, это может поставить под угрозу способность SQL Server восстанавливать данные, что может привести
к разрушению базы данных. Это может случится, если контроллер вмешивается в работу журнала регистрации
транзакций SQL Server, и буферизует их в собственном аппаратном кэше контроллера, но не может сохранить
эти записанные в его кэш страницы в момент отказа системы. Большинство современных дисковых контроллеров
имеют опцию кэширования записи, но не все они позволяют эту опцию отключать. Даже если сервер
использует UPS, это не гарантирует, что кэширование записи будет защищено. Множество типов системных
отказов происходит по причинам, не зависящим от UPS. Например, ошибка четности памяти, зависание
операционной системы или аппаратный сбой, который провоцирует перезагрузку системы, могут повлечь
за собой неизбежное прерывание работы системы. Отказы памяти и аппаратных средств ввода/вывода, могут
привести к тому, что информация в кэше контроллера будет потеряна.
Другая возможная проблема, связанная с использованием кэширующего запись контроллера, может
проявляться во время завершения работы операционной системы. Иногда необходимо периодически
перезагружать операционную систему или перезагрузка ОС нужна для внесения изменений в её конфигурацию.
Даже если оператор будет следовать рекомендации о том, что до начала перезагрузки операционной системы
необходимо дождаться, чтобы дисковые операции прекратились, кэширование записи может всё ещё выполняться
контроллером. Когда исполняется комбинация клавиш CTRL+ALT+DEL, или нажата кнопка RESET, операции
кэширования записи могут быть прерваны, что потенциально может привести к повреждению базы данных.
При проектировании аппаратных средств кэширования записи, фирмой производителем дисковых контроллеров
должны приниматься во внимание все возможные причины потери "грязных" данных кэша, что бы обезопасить
базы данных. В числе мер, которые могут быть предприняты разработчиком такого контроллера, можно назвать:
прерывание сигнала RST шины контроллера, который даёт команду на немедленный сброс кэша контроллера;
наличие собственного аккумулятора у контроллера; наличие зеркальной или ERC памяти (error checking correcting).
При приобретении дискового контроллера, для сервера СУБД, убедитесь у Вашего поставщика, что этот контроллер
имеет перечисленные опции или любые другие особенности, позволяющие избежать потери данных из собственного
кэша контроллера.
FAQ на тему использования кэширующих дисковых контроллеров с MS SQL Server
По материалам статьи Microsoft Knowledge Base "INF: Using Hard Disk Controller Caching with SQL Server".
Информация в этой статье относится к Microsoft SQL Server версий: 4.2x, 6.0, 6.5, 7.0
Вопрос
Возможны ли проблемы при использование кэширующего дискового контроллера, работающего в составе
SQL Server, если к серверу подключен UPS, чтобы избежать нарушения целостности данных из-за сбоя питания? Ответ
Если дисковый контроллер когда-либо не сможет записать кэшируемые им данные, предназначенные для
журнала регистрации транзакций SQL Server, механизм восстановление сервера баз данных не сможет работать правильно. Вопрос
Какой эффект оказывает использование кэширующего дискового контроллера на эффективность работы
SQL Server? Ответ
Если кэш дискового контроллера всегда будет записан на диск так, как это предусматривалось работой
сервера (даже при получении команды с клавиатуры на перезагрузку, при сбое операционной системы или
при сбое жёсткого диска), проблем в работе СУБД не возникнет. С другой стороны, если дисковый контроллер
не сможет осуществить запись некоторых данных журнала регистрации транзакций SQL Server и задержит
физическое применение каких-либо данных журнала регистрации транзакций (из-за использования типа сортировки
«elevator»), и не сможет записать оставшуюся не применённой часть данных (вероятность такого
стечения обстоятельств не исключена); SQL Server никогда не узнает, что часть записей журнала регистрации
транзакций отсутствует. Процедура регенерации данных при старте сервера или даже последовательное восстановление
полной копии базы с последующими копиями журнала транзакций (включая копию журнала после сбоя) не сможет
привести к правильному восстановлению базы данных. В самом худшем случае, процедура регенерации данных,
после потери данных кэша контроллера (повлекшей нарушение целостности данных), пройдёт успешно, а потеря
данных будет обнаружена намного позже.
Если дисковый контроллер разработан для использования в составе СУБД, он должен уметь правильно использовать
метод сквозной записи на диск (write-through) и предоставлять возможность выбора для разных дисковых массивов
разных методов кэширования. Дисковое устройство, на котором размещены журналы регистрации транзакций,
должно всегда быть write-through. Кроме того, если автоматическая регенерация данных при старте СУБД отрабатывает
должным образом, все устройства SQL Server должны быть очищены после исполнения контрольной точки. Если
дисковый контроллер не поддерживает опцию write-through, единственной альтернативой этому можно считать
очень частое создание резервных копий. Кроме того, Вам не придётся рассчитывать на процедуру регенерации
данных при старте сервера и на те записи журнала транзакций, которые были активны в момент сбоя. Вы сможете
рассчитывать только на те записи, которые до этого удалось сохранить в резервной копии. Вопрос
Где должно выполняться кэширование, на SQL Server или на дисковом контроллере? Ответ
Ответ зависит от того, какой метод позволяет СУБД работать быстрее. Наши эксперименты показали, что кэш
SQL Server является более эффективным, чем буфер системы ввода-вывода операционной системы. Однако, мы
не располагаем сведениями о том, действительно ли кэширование SQL Server более эффективно чем кэширование,
используемое специализированными дисковыми контроллерами. Кэш SQL Server, по видимому, не работает с
такой же скоростью, как аппаратный кэш. Однако, кэш СУБД более интеллектуален и может работать более
продуктивно.
Проведите моделирование с имитацией типичной рабочей нагрузкой, установив параметры памяти SQL Server
в минимальные значения, необходимые для поддержки требуемого числа пользователей (кэш дискового контроллера
должен быть активным) для вашей инсталляции. Выполните измерения производительности этой конфигурации,
которые будут сравниваться с конфигурацией без аппаратного кэша. После этого, пробуйте запустить сервер
баз данных с параметрами памяти, увеличенными на величину кэша данных в RAM, которая должна быть сравнима
с величиной кэша дискового контроллера (кэш дискового контроллера должен быть дезактивирован). Для корректного
сравнения, число страниц в кэше процедур должно быть одинаково в обоих моделируемых вариантах. Это потребует
некоторой корректировки конфигурации, потому что размер кэша процедур определяется в процентах от полного
размера кэша данных, в то время, как размер полного кэша определяется конфигурационными параметрами памяти
и количеством пользовательских подключений. Реальный размер кэша будет составлять то, что останется после
предоставления 42КБ каждому пользовательскому подключению. Это остаток будет разделен между процедурным
кэшем и кэшем страниц данных согласно процентному соотношению, указанному в параметре кэша процедур.
Замечания автора рассылки
В качестве резюме к обеим статьям, можно сказать, что грамотное использование аппаратных дисковых контроллеров,
имеющих собственный кэш операций ввода/вывода, несомненно, должно привести к существенному повышению
эффективности работы СУБД. Накладываемые технологией обслуживания транзакций ограничения на опции и
режимы кэширования, встраиваемые в аппаратные средства, несомненно, должны приниматься во внимание при
инсталляции, как "железа", так и СУБД. Современные дисковые контроллеры объединяют в себе целый набор
разнообразных возможностей, дающих огромные преимущества и от которых невозможно отказаться (RAID,
высвобождение ресурсов центрального процессора, многоканальность, диски автоматической подмены, работа
в кластере и т.д.). В последнее время очень широкое распространение получили технологии NAS и SAN, которые
не мыслимы без применения очень мощных и высокоинтеллектуальных контроллеров дисковых массивов. Всё
это говорит о том, что работа современной СУБД без кэширующих дисковых контроллеров становится невозможной.
Представленными Вам статьями было показано, что неправильная конфигурация аппаратных средств может привести
к повреждению базы данных. Ключевым элементом, защита которого позволит избежать подобных разрушений,
является журнал регистрации транзакций. Журналы должны располагаться на отдельных дисковых массивах и
для этих дисков должно быть запрещено кэширование записи. Кроме того, необходимо запретить использование
сигналов интерфейса SCSI на инициализацию устройств, в результате которой происходит потеря данных аппаратного
кэша контроллера. Каждый контроллер, как минимум, должен обладать собственным, встраиваемым аккумулятором,
для предотвращения преждевременного обесточивания кэша. Современные аппаратные средства идут ещё дальше.
Возможно дублирование и резервирование не только самих дисков, но и контроллеров, шин и т.п. Современные
автономные дисковые массивы способны обслуживать не один, а несколько серверов, причём используя для этого
целый набор интерфейсов, таких, как SCSI, FC, Fast Ethernet и т.п. Давно уже прошли те времена, когда размер
базы данных не превышал десятка Гигабайт. Сегодня, множество задач оперирует сотнями, а то и тысячами Гигабайт,
для чего большой объём кэша данных у СУБД начинает иметь огромное значение. Для эффективного наполнения
такого кэша данных наличие промежуточного, аппаратного кэша даёт только преимущества.
