В настоящее время вы работаете в автономном режиме; ожидается повторное подключение к Интернету

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

ВНИМАНИЕ! Данная статья переведена с использованием программного обеспечения Майкрософт для машинного перевода и, возможно, отредактирована посредством технологии Community Translation Framework (CTF). Корпорация Майкрософт предлагает вам статьи, обработанные средствами машинного перевода, отредактированные членами сообщества Майкрософт и переведенные профессиональными переводчиками, чтобы вы могли ознакомиться со всеми статьями нашей базы знаний на нескольких языках. Статьи, переведенные с использованием средств машинного перевода и отредактированные сообществом, могут содержать смысловое, синтаксические и (или) грамматические ошибки. Корпорация Майкрософт не несет ответственности за любые неточности, ошибки или ущерб, вызванные неправильным переводом контента или его использованием нашими клиентами. Подробнее об CTF можно узнать по адресу http://support.microsoft.com/gp/machine-translation-corrections/ru.

Эта статья на английском языке: 230785
Аннотация
Этой статье описано, как расширить алгоритмы ведения журнала и данных Microsoft SQL Server, целостность и надежность данных.

Дополнительные сведения о базовых понятий ядер и ARIES (алгоритм для восстановления и использования семантики изоляции), см. следующие проводки ACM для систем баз данных документа (в разделе «том 17, номер 1 марта 1992 г.):

Записи интереса настоящего документа является C. Mohan. Документ адресов технологии SQL Server для расширения надежность данных и целостности применительно к сбоям.

Корпорация Майкрософт рекомендует ознакомиться в следующих статьях базы знаний Майкрософт для получения дополнительных сведений о кэшировании и обсуждения альтернативных сбой режима:
86903 Описание контроллеры дисков с кэшированием в SQL Server
234656 Сведения об использовании кэша диска с SQL Server, который должен знать каждый администратор баз данных
Дополнительная информация
Прежде чем начать подробное обсуждение, некоторые термины, используемые в этой статье определены в следующей таблице.
ТерминОпределение
Резервные батареиБатареи отдельно и локализованные функции резервного копирования непосредственно доступны и управляется механизм кэширования во избежание потери данных.
Примечание Это не источник бесперебойного питания (ИБП). ИБП не гарантирует любые операции записи и могут быть отключены от кэширования устройства.
КэшМеханизм промежуточного хранения, используемый для оптимизации физических операций ввода-вывода и улучшения производительности.
«Грязная» страницаСтраница, содержащая изменения данных, которые еще не были записаны на диск в постоянном хранилище. Дополнительные сведения о буферах «грязная» страница см "Запись страниц"раздел в электронной документации по SQL Server.
Примечание Содержимое также применяется к Microsoft SQL Server 2012 и более поздних версий.
СбойВсе, что может привести к неожиданным сбоя процесса SQL Server. Примеры: питание отключения, перезагрузки компьютера, ошибки памяти, других проблем с оборудованием, поврежденных секторов, сбои в работе диска, сбои системы и т. д.
ОчисткаПринудительное буфера кэша стабильный носитель.
ЗащелкаОбъект синхронизации, используемый для защиты ресурса физической согласованности.
Энергонезависимое хранениеЛюбой носитель, доступный через сбои системы.
Закрепленные страницыСтраница, которая остается в данных в кэше и нельзя очистить в постоянном хранилище, пока все связанные записи защищены в постоянном хранилище месте.
Постоянном хранилищеАналогично ПЗУ.
Энергозависимой памятиЛюбой носитель, на котором останется без изменений различных сбоев.

Упреждающее ведение журнала Упреждающей записью протоколов

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

ARIES документ определяет Упреждающей следующим образом:
Протокол Упреждающей утверждает, что записи журнала, представляющая некоторые данные изменения уже должен быть в постоянном хранилище перед измененных данных разрешено заменять предыдущую версию данных в энергонезависимой памяти. То есть система не разрешено записывать обновленная страница ПЗУ версии страницы, пока по крайней мере отката части записи журнала, описывающие обновления страницы были записаны в сохраняемое хранилище.
Дополнительные сведения о упреждающее ведение журнала, см. Журнал транзакций с упреждающей раздел в электронной документации по SQL Server.

SQL Server и Упреждающей

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

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

Примечание Например предположим, что отсутствует индекс и что уязвимой страница является страницей 150.
BEGIN TRANSACTION   INSERT INTO tblTest VALUES (1)COMMIT TRANSACTION				
Затем разбить мероприятие в упрощенное ведение журнала действий, как описано в следующей таблице.
ИнструкцияДействия, выполняемые
НАЧАТЬ ТРАНЗАКЦИЮЗапись в область кэша журнала. Тем не менее это необходимо для очистки в постоянном хранилище, поскольку SQL Server не внес изменений физических.
INSERT INTO tblTest
  1. Данные страницы 150 извлекаются в кэш данных SQL Server, если он уже не доступен.
  2. На странице заблокирована, закрепленные, и "грязные", и получаются соответствующую блокировку.
  3. Запись журнала, вставить построена и добавлены в кэш журнала.
  4. Новая строка добавляется на страницу данных.
  5. Блокировка освобождается.
  6. Записи журнала, связанные с транзакцией, или страница не были записаны на диск в данный момент, так как все изменения сохраняются в энергозависимой памяти.
ЗАФИКСИРОВАТЬ ТРАНЗАКЦИЮ
  1. Формируется запись журнала фиксации и стабильный носитель должен быть написан записи журнала, связанные с транзакцией. Транзакции не считается зафиксированным, пока записи журнала неправильно назначенных в постоянном хранилище.
  2. Данные 150 страница остается в кэше данных SQL Server и не очищается немедленно в постоянном хранилище. При правильной защиты записи журнала восстановления можно повторять операции, при необходимости.
  3. Блокировки транзакций, снимаются.
Не следует путать термины «блокировка» и «ведение журнала». Хотя важно, блокировки и ведения журнала, отдельные проблемы при работе с Упреждающей. В предыдущем примере SQL Server обычно содержит защелка на странице 150 раз необходимо выполнить изменения физической вставки на странице, не все время транзакции. Тип соответствующей блокировки устанавливается для защиты строк, диапазон, страницы или таблицы при необходимости. Обратитесь к электронной документации по SQL Server блокировки разделам для получения дополнительных сведений о типах блокировки.

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

SQL Server и стабильность хранилищ

SQL Server расширяет операции страницы журналов и данных, включая знание размеров сектора диска (обычно 4 096 или 512 байт).

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

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

Обнаружение разорванных страниц

Этот параметр позволяет SQL Server для обнаружения незавершенных операций ввода-вывода, вызванные сбоями питания или другими перерывами в работе системы. Если true, то немного должно быть перевернуто для каждого 512-байтового сектора в 8-килобайтовой (КБ) базы данных страницы при записи страницы на диск. Если немного в неправильном состоянии при последующих страницы считываются с SQL Server, затем страницы был написан неправильно; Обнаружен разрыв страницы. Разрывы страницы обычно определяются во время восстановления, так как любой страницы, который был написан неправильно, вероятнее всего для чтения путем восстановления.

Хотя страниц базы данных SQL Server, 8 КБ, диски выполнения операций ввода-вывода с помощью 512-байтового сектора. Таким образом 16 секторов записываются на одной странице базы данных. Разрыв страницы может возникнуть в случае сбоя системы (например, из-за сбоя питания) между временем, операционная система записывает первый сектор размером 512 байт на диске и завершения операции ввода-вывода 8 КБ. Если первый сектор страницы базы данных успешно записываются перед сбоем, страница базы данных на диске будет отображаться при обновлении, несмотря на то, что не может быть успешно.

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

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

Журнал четности

Проверка четности журнала очень похож на обнаружение разорванных страниц. Каждого 512-байтового сектора содержит битов четности. Эти биты четности всегда записываются с записью журнала и оцениваются при извлечении записи журнала. Заставляя операций записи в журнал на границе 512 байт, SQL Server можно убедиться в том, что операции committal полностью записываются секторов физического диска.

Версиях SQL Server 7.0

Более ранние версии SQL Server 7.0 не предоставил журнал четности или средства обнаружения разрыва бит. На самом деле эти версии можно написать одну и ту же страницу журнала несколько раз до записи журнала заполнения страницы журнала 2 КБ. Это может привести к транзакции, будет успешно завершена. Если страница журнала перезаписывается во время сбоя, сектора с зафиксированных транзакций может не получить переписать правильно.

Воздействие на производительность

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

Параметр FILE_FLAG_WRITE_THROUGH гарантирует, что по возвращении успешного завершения операции записи правильное сохранение данных в постоянном хранилище. Это выполняется в соответствии с Упреждающей протокол, который обеспечивает данные.
Во многих дисках (SCSI и IDE) имеется встроенный кэш объемом 512 КБ, 1 МБ или больше. Однако кэша дисков обычно используется конденсатор не решения батареями. Такие механизмы кэширования не гарантирует запись во питания цикла или сходных точек сбоя. Они гарантируют только выполнение операций записи секторов. В частности это почему прерванная запись и определения четности журнала были созданы в SQL Server 7.0 и более поздних версий. Дисков продолжают увеличиваться в размере, кэша и могут передавать большие объемы данных во время сбоя.

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

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

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

Упорядочение сектора

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

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

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

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

При оценке факторов оптимальной производительности для сервера базы данных, существуют следует учитывать множество факторов. Наиболее важные из них — «Моя система позволяет ли допустимые возможности FILE_FLAG_WRITE_THROUGH?»

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

Тестирование показало, что многие конфигурации диск может содержать кэширование записи без соответствующего питания. Диски SCSI, IDE и EIDE воспользоваться всеми преимуществами записи кэша. Дополнительные сведения о работе службы SSDs вместе с SQL Server seethe следующие статьи блога инженеров CSS SQL Server:


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

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

Запись кэша размещения

Записи размещения кэша похож на порядок сектора. Следующее определение был взят напрямую из ведущих IDE диска производителя:
Как правило этот режим активен. Записи режим кэша принимает хост записи данных в буфер до заполнения буфера или узла передача завершена.

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

Автоматическая запись перераспределения (AWR)

Другой распространенный метод, используемый для защиты данных является обнаружение поврежденных секторов во время обработки данных. Следующее объяснение поступает из ведущих IDE диска производителя:
Эта функция является частью кэш записи и уменьшает риск потери данных во время операции отложенной записи. Если ошибка диска в процессе записи диска, останавливается задачи диска и подозрительный сектор перераспределяется пула альтернативный секторов, которые расположены в конце диска. После перераспределения задач записи диска продолжается до его завершения.
Это может быть очень мощным средством, если резервного питания от батареи для кэш. Это обеспечивает соответствующие изменения при перезагрузке. Рекомендуется для обнаружения ошибок на диске, но безопасность данных протокола Упреждающей снова потребуется это выполняется в режиме реального времени, а не в отложенным способом. С параметрами Упреждающей AWR методика не может учитывать ситуации, в которой записи журнала происходит сбой из-за ошибки сектора, но диск заполнен. Компонент database engine необходимо немедленно знать о сбое, транзакция может быть прервана правильно, администратор может получать оповещения и скорректировать действия, предпринимаемые для защиты данных и исправления ситуации сбоя носителя.

Безопасность данных

Существуют некоторые меры предосторожности, которые администратор базы данных должен предпринять, чтобы обеспечить безопасность данных.
  • Это всегда хорошая идея, чтобы убедиться в том, что достаточно стратегию резервного копирования для восстановления после сбоя. Подходят способы хранения и другие меры безопасности.
  • Операция восстановления базы данных в дополнительной или тестовой базы данных частое теста.
  • Убедитесь, что все устройства кэширования может обрабатывать все ситуации сбоя (электричества, поврежденных секторов, поврежденных дисков, отказ системы, зависание, питания пик и т.д.).
  • Убедитесь, что устройство кэширования:
    • Имеет встроенную резервного питания от батареи
    • Можно повторный выпуск записывает питания
    • Можно полностью отключить при необходимости
    • Обрабатывает переназначении поврежденных секторов в режиме реального времени
  • Включить разрыва страниц. (Это имеет незначительное влияние на производительность).
  • Настройка дисков RAID поддержка горячей замены поврежденного жесткого диска, если это возможно.
  • С помощью новых контроллерах кэширования, позволяющие увеличить дисковое пространство без перезагрузки операционной системы. Это может быть идеальным решением.

Проверка дисков

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

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

Корпорация Майкрософт произвела тестирование нескольких дисков SCSI и IDE с помощью служебной программы SQLIOSim . Эта программа имитирует действия большой асинхронного чтения и записи на имитируемые устройства данных и журнала. Статистика производительности теста показывает среднее количество операций записи в секунду от 50 и 70 для дисков с отключенным кэшированием записи и СКОРОСТЬЮ от 5 200 до 7.

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

Данные устройства

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

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

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

Повышение производительности

Первый вопрос, который происходит: "у меня, кэширования диска IDE. Но при отключении его Мой производительности стало значительно меньше, чем ожидалось. Почему?"

Многие из жестких дисков IDE, корпорацией Майкрософт запустите скоростью 5,200 об/мин и на 7,200 скорость ВРАЩЕНИЯ жестких дисков SCSI. При отключении записи кэширования диска IDE механические характеристики производительности может стать фактор.

Ясное области для устранения разница в производительности: «Адреса скорость транзакций».

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

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

Тестирование показывает, высокая активность буферов, меньше 512 КБ или больше, чем 2 МБ записи может привести к снижению производительности.
Рассмотрим следующий пример:
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))GOSET NOCOUNT ONGOINSERT INTO tblTest VALUES ('Test')WHILE @@IDENTITY < 10000   INSERT INTO tblTest VALUES ('Test')				
Ниже приведены примерные результаты тестов для SQL Server.
SCSI(7200 RPM) 84 секунд
SCSI(7200 RPM) 15 секунд (кэширования контроллера)

IDE(5200 RPM) 14 секунд (кэш диска включен)
IDE(5200 RPM) 160 секунд

Перенос всю последовательность операций вставки в одной транзакции выполняется в течение четырех секунд во всех конфигурациях.

Причина — количество необходимых операций очистки журнала. Без транзакции ВСТАВКУ транзакция сама по себе, и каждый раз необходимо сбросить записей журнала для операции. Каждый сброс составляет 512 байт размера, которая требует вмешательства значительные механические устройства.

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

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

Посмотрите на операторы, связанные с сброса журнала и определить, если уменьшается число сбросов журнала. В предыдущем примере был реализован одной транзакции. Тем не менее во многих случаях это может привести к нежелательному поведению блокировки. Проверьте на этапе разработки транзакции. Для выполнения пакетов для снижения активности сброса журнала часто и небольших можно использовать код, аналогичный приведенному ниже:
BEGIN TRANGOINSERT INTO tblTest VALUES ('Test')WHILE @@IDENTITY < 50BEGIN   INSERT INTO tblTest VALUES ('Test')   if(0 = cast(@@IDENTITY as int) % 10)   BEGIN      PRINT 'Commit tran batch'      COMMIT TRAN      BEGIN TRAN   ENDENDGOCOMMIT TRANGO				
SQL Server требует, что системы поддерживают «гарантированная доставка стабильной носитель» как описано в разделе Требования к надежности программы SQL Server ввода/вывода рецензирования Загрузите документ. Дополнительные сведения о требованиях к входной и выходной компонент SQL Server database engine щелкните следующий номер статьи, чтобы перейти к статье базы знаний Майкрософт:
967576 Требования к ввода вывода ядра базы данных Microsoft SQL Server.

Внимание! Эта статья переведена автоматически

Свойства

Номер статьи: 230785 — последний просмотр: 05/17/2015 07:44:00 — редакция: 6.0

Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 7.0 Standard Edition, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Standard

  • kbhowto kbinfo kbmt KB230785 KbMtru
Отзывы и предложения