Когда Torn Page Detection и Checksum были введены в SQL Server и каковы варианты обновления?

В современном SQL Server есть две разные опции для проверки страницы; будучи Torn страницу Обнаружение и контрольной суммы . Ни один , конечно, тоже не вариант.

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

Проблема заключается в том, что у нас есть производственная база данных, которая была запущена в производство с использованием SQL Server 2000 и с тех пор перешла на сервер SQL Server 2008 R2. Page Verify установлен на None, когда я ожидал, что это будет Torn Page Detection . Возвращаясь к этому количеству времени, мы, кажется, думаем, что БД была первоначально разработана в SQL Server 7.0, а затем перенесена в SQL Server 2000, и это может объяснить наблюдаемый результат.

Мне было интересно, когда Torn Page Detection и Checksum стали функцией SQL Server, и как они вели себя при переносе или обновлении до более новых версий.

Изменить: Подводя некоторые ответы:

Существует небольшая разница в датах появления Torn Page Detection в SQL Server.
Ссылка 1: http://support.microsoft.com/kb/230785
Ссылка 2: http://technet.microsoft.com/en-us/library/aa337525(v=sql.90).aspx

Первая ссылка указывает на SQL 7.0, а вторая - на SQL2000. Я склонен доверять предложению SQL7.0, и вторая ссылка была сбита с толку из-за того, что он отключен по умолчанию в SQL7.0 и включен по умолчанию в SQL2000.

В SQL Server 2000, если вы хотите идентифицировать поврежденные страницы, для параметра базы данных TORN_PAGE_DETECTION должно быть установлено значение TRUE.

Но в SQL 2005 и выше новая настройка PAGE_VERIFY заменила старую TORN_PAGE_DETECTION, которая позволяет выбирать из двух разных типов проверки страницы: TORN_PAGE_DETECTION и CHECKSUM.

Теперь возникает вопрос, какой из них установить - TORN_PAGE_DETECTION или CHECKSUM?

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

CHECKSUM - вычисляет контрольную сумму страницы как при написании страницы, так и при чтении страницы, при условии, что на ней есть контрольная сумма.

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

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

Ссылка: Контрольная сумма в SQL2005

Чтобы конкретно ответить на ваши вопросы:

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

Да, CHECKSUM был введен в SQL Server 2005 и является ПО УМОЛЧАНИЮ . При обновлении с 2000 до 2005 вы должны явно изменить параметр страницы Проверка страницы, чтобы использовать CHECKSUM.

Если вы восстановите базу данных, уже созданную в SQL 2005, на другой сервер, на котором работает SQL 2005, вам не нужно ее устанавливать. Это будет сохраняться до того, что вы когда-либо устанавливали опцию Page Verify.

Мне не удалось исследовать, когда обнаружилось Torn Page Detection

От: http://support.microsoft.com/kb/230785

Версии SQL Server ранее 7.0

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

Таким образом, TORN_PAGE_DETECTION существует с SQL Server 7.0. Даже тогда по умолчанию это было не включено (та же ссылка) .

Примечание Обнаружение разорванной страницы не включено по умолчанию в SQL Server 7.0. Смотрите sp_dboption, чтобы узнать, как включить обнаружение в вашей системе.

Поэтому, если база данных была разработана для экземпляра 7.0 и впоследствии была обновлена, она обновила бы имеющуюся опцию PAGE VERIFY NONE (как отметил @ThomasStringer в своем ответе).

Изменить: 24.09.2013 Чтобы улучшить ответ:

Обратившись к моим внутренним заметкам по SQL Server от SQLSkills, я обнаружил, что используя дамп страницы, вы можете проверить, включено ли обнаружение разорванного бита - включено TORN_PAGE_DETECTION или CHECKSUM:

use database_name -- change here for your database !!
checkpoint
go 
dbcc traceon (3604)   -- send output to screen
go
dbcc page (dbaalert, 1,1,0)
dbcc traceoff (3604)  -- turn off the trace flag
go

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

Примечание : у меня не работает ни одна старая версия сервера sql. Ниже подтверждается SQL Server 2000 и выше . Если у вас работает 7.0 или 6.5, вы также можете это подтвердить :-)

Посмотрите на ссылку от BOL :

Когда пользовательская или системная база данных обновляется до SQL Server 2005 или более поздней версии, значение PAGE_VERIFY (NONE или TORN_PAGE_DETECTION) сохраняется. Мы рекомендуем вам использовать CHECKSUM

Это диктует, что до SQL Server 2005 опция TORN_PAGE_DETECTIONсуществовала, но не существовала CHECKSUM.

И чтобы ответить на ваш второй пункт:

... и что при обновлении или восстановлении БД из предыдущей версии будет сохранен метод проверки предыдущей страницы.

Да, это правильно. Вам необходимо явно настроить базу данных для использования CHECKSUMметода проверки страницы.

В современном SQL Server есть два разных варианта проверки страницы

Как вы указали, их три: TORN_PAGE_DETECTION, CHECKSUM и NONE.

Я считаю, что CHECKSUM был введен в SQL Server 2005

Как цитируется в этой статье MSDN под названием «Управление буфером»: Обнаружение разорванной страницы было введено в SQL Server 2000. Контрольная сумма была введена в SQL Server 2005.

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

У меня есть производственная база данных, которая была запущена в производство с использованием SQL Server 2000, хотя, возможно, была разработана для SQL Server 7.0 и с тех пор перешла на сервер SQL Server 2008 R2. Page Verify установлен на NONE, хотя я ожидал, что это TORN PAGE DETECTION.

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

Когда пользовательская или системная база данных обновляется до SQL Server 2005 или более поздней версии, значение PAGE_VERIFY (NONE или TORN_PAGE_DETECTION) сохраняется

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

Мне было интересно, когда TORN PAGE DETECTION стала функцией проверки страниц

SQL Server 2000, как указано выше.

как он ведет себя при переносе или обновлении до новых выпусков.

Предыдущая настройка сохраняется во время обновления, как указано выше.

Теперь я хотел бы отметить тот факт, что в других ссылках, предоставленных людьми, говорится, что SQL Server 7.0 был доступен при обнаружении разорванной страницы. Что, как указано в этих статьях, является правдой, однако много раз доказано, что документация Microsoft не должна рассматриваться как истина при любых обстоятельствах. Есть много где они не правы. Итак, сказав, как вы можете определить, какой ответ является приемлемым? Мы все предоставили Microsoft документацию для поддержки нашего ответа.

Также обратите внимание, что обнаружение разорванной страницы находится в списке амортизации начиная с SQL Server 2012, так что с самого начала нужно знать, как оно было установлено в ваших базах данных. Если я вижу, что он настроен на что-то кроме CHECKSUM, я немедленно изменяю его и перехожу к другой более важной задаче. Я не беспокоюсь о том, как была создана неправильная конфигурация, более важно исправить ее, а затем убедиться, что те, у кого есть разрешения на ее изменение, информированы о том, почему этот элемент конфигурации не должен быть изменен на что-либо другое. Просто мои 0,02 доллара

Как сказали @Thomas Stringer и @Kin, он представлен в SQL Server 2005, и я считаю, что он работает во всех выпусках SQL Server. Для TempDB, хотя CHECKSUM был введен в SQL Server 2008

http://blogs.msdn.com/b/sqlserverstorageengine/archive/2008/03/23/checksum-and-tempdb.aspx