Наверное все со мной согласятся, если я скажу, что повреждение данных – это ночной кошмар любого администратора баз данных. Основными причинами, которые приводят к повреждениям данных, являются сбои в работе компонентов, которые лежат между Buffer Pool и дисковым массивом: это могут быть различные драйвера контроллеров, кэш хранилища, firmware хранилища и т.п. Мы не можем полностью защититься от этого, но мы можем вовремя узнать о повреждении, пока еще не стало слишком поздно. Опция базы данных PAGE_VERIFY служит как раз для этого. Опция может принимать одно из трех значений: CHECKSUM, TORN_PAGE_DETECTION или NONE. Давайте рассмотрим подробнее, что значит каждое из них.

NONE

Опция по умолчанию в SQL Server 7.0, хотя уже в SQL Server 7.0 можно было включить опцию «torn pages». Если мы используем значение NONE, то содержимое старниц с данными никак не проверяется, и если вдруг, на странице возникли повреждения, мы не можем никак о них узнать. Это может например привести к тому, что у нас в таблице изменится значение в одном из столбцов или данные станут вообще нечитаемы.

TORN_PAGE_DETECTION

В SQL Server 2000 по умолчанию при создании базы данных уже включалась данная опция, но сегодня она уже не так актуальна, как раньше. Размер сектора на физическом диске равен 512 байт (хотя сейчас уже все больше появляется дисков с размером сектора 4 килобайта). Страница данных SQL Server равна 8 килобайтам или 16 х 512 байт. Таким образом, чтобы поместить страницу целиком на диск, нужно записать 16 секторов. Для дисков, запись на которые идет без поддержки аккумулятора, в результате сбоя питания может получиться, что страница будет записана на диск лишь частично. Например, запишутся только первые 3 сектора, и страница становится «разорванной» или torn page. Алгоритм, которые лежит в основе опции TORN_PAGE_DETECTION призван защищать от такой частичной записи. С каждого 512 байтового куска страницы берутся 2 бита, из которых формируется 4 байтовое чило и записывается в заголовок страницы. Также на каждые 512 байт страницы пишется переменный флаг. При чтении страницы с диска все значения проверяются, и если они не совпадают – выдается ошибка 824.

Msg 824, Level 24, State 2, Line 2

SQL Server detected a logical consistency-based I/O error: torn page (expected signature: 0x55555555; actual signature: 0x55555559). It occurred during a read of page (1:78) in database ID 44 at offset 0x0000000009c000 in file ‘C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\CorruptionTest.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

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

CHECKSUM

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

Еще один важный момент, о котором стоит упомонять: если вы меняете опцию базы данных PAGE_VERIFY с NONE на CHECKSUM или с TORN_PAGE_DETECTION на CHECKSUM, то это не включает немедленно проверку целостности вашей страницы. Дело в том, что checksum вычисляется и записывается на страницу с данными при записи на дисковую подсистему. Поэтому, чтобы опция CHECKSUM начала действовать в полной мере – придется перезаписать все страницы, для которых она еще не вычислена. Это можно сделать например перестроением индексов или, чтобы полностью гарантировать результат – полным пересозданием всех объектов. Таким образом, у вас в пределах одной базы данных одновременно могут быть страницы с опциями NONE, TORN_PAGE_DETECTION и CHECKSUM.