Когда-то давным-давно существовал параметр проверки страниц, известный как TORN_PAGE_DETECTION. Результаты его применения были посредственными, хотя он все же был полезен для проверки повреждений данных при записи в SQL Server. Процесс просматривал лишь первые два байта каждого 512-байтного сектора на странице, и записывал их в заголовок страницы. При последующей операции чтения выполнялось сравнение сохраненных в заголовке метаданных со значением в байтах в начале каждого сектора на странице. Если эти значения совпадали, предполагалось, что данные на странице не испорчены, так как никаких других искажений в остальных 510 байтах сектора быть не может. Так ли это?
Появление CHECKSUM
Так было во времена SQL Server 2000. Немногие с тех пор остались в строю: сильные духом, хронически уклоняющиеся от модернизации в сферах, обслуживающих здравоохранение, а также компании, технический персонал которых давно уволился и теперь никто не знает, функционируют или нет программы, поддерживаемые базами данных.
После выпуска SQL 2005 у нас появился гораздо более привлекательный вариант, который стал стандартным — CHECKSUM. При данном подходе вычисляется контрольная сумма для всех байтов в секторе и записывается в заголовок; это значение проверяется при последующих операциях чтения. Такой метод гораздо лучше, чем 2/512, ведь порча данных может произойти в любом месте.
Проблема в том, что когда поставщики программного обеспечения обновляют свои базы данных, заменяя предшествующие версии SQL Server, они редко учитывают все тонкости настройки базы данных. Некоторые настройки остаются неизменными, и более того, значения по умолчанию старых версий полагаются оптимальными для следующей (или следующей после следующей после следующей) версии, что не всегда верно. По этой причине я предлагаю очень простой сценарий для исправления устаревших и неправильно настроенных параметров проверки страниц в базах данных SQL Server 2005 и более поздних.
Приведенный в листинге сценарий определяет любую базу данных, где используется TORN_PAGE_DETECTION или NOTHING, и выдает вычисляемый код T-SQL для обновления до CHECKSUM. Я регулярно применяю этот сценарий ко всем своим экземплярам в группе зарегистрированных серверов с использованием собственной функциональности SQL Server Management Studio (SSMS).
Иногда обнаруживается устаревший параметр, который позволяет манипулировать именами серверов и баз данных, облегчая работу администратора базы данных. Последний столбец, возвращенный сценарием, содержит вычисляемый код T-SQL, который можно запустить, чтобы внести изменения в базы данных с параметрами, унаследованными от SQL 2000.
Предупреждение
Помните, что изменение параметров не затронет чистые страницы, уже находящиеся на диске или в буфере. Запись полносекторной контрольной суммы не происходит до тех пор, пока страница не будет «загрязнена» и не будет выполнена запись после подсчета контрольной суммы. Очень удачную иллюстрацию дала Колин Морроу. Я рекомендую прочитать ее публикацию, чтобы увидеть, как работает контрольная сумма (http://colleenmorrow.com/2012/06/07/page_verify-checksum-vs-torn-page-detection/).
SELECT [имя] AS [имя_базы_данных]
, [page_verify_option_desc] AS [current_page_verify_option_desc]
, 'ALTER DATABASE [' + [имя] + '] SET PAGE_VERIFY CHECKSUM WITH NO_WAIT;' AS [SQL Command]
FROM sys.[DATABASES]
WHERE [page_verify_option_desc] <> 'CHECKSUM'
AND [уровень_совместимости] > 80
AND [name] NOT IN ('master', 'model', 'msdb', 'tempdb', 'distribution')
ORDER BY [имя];