Коли було введено розпізнавання розірваних сторінок та контрольна сума на SQL Server і які поведінки оновлення?


15

У сучасному SQL Server є два різні варіанти перевірки сторінки; будучи Torn сторінку Виявлення і контрольної суми . Жоден також, звичайно, варіант.

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

Проблема полягає в тому, що у нас є виробнича база даних, яка почала виробництво за допомогою SQL Server 2000 і з того часу перейшла на сервер SQL Server 2008 R2. Перевірка сторінки встановлена ​​на Нічого", коли я очікував виявлення розірваної сторінки . Якщо повернути цю кількість часу, нам здається, що БД спочатку був розроблений на SQL Server 7.0, а потім перейшов на SQL Server 2000, і це може пояснити спостережуваний результат.

Мені було цікаво, коли виявлення Torn Page та Checksum стали функцією SQL Server, і як вони поводилися під час міграції чи модернізації до новіших версій.

Редагувати: підбиваючи підсумки деяких відповідей:

Існує невелика розбірливість щодо деяких дат, коли Torn Detection Page прийшов на 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.


2
він був введений, коли код був вчинений.
swasheck

Чому це важливо? Яка проблема вирішується тут?
Маріан

@swasheck - вибачте, що я не розумію ваш коментар.
Пол,

1
@Paul проголосував за повторне відкриття
swasheck

1
@Paul Я додав інформацію про сторінку dbcc, щоб перевірити наявність зірваної сторінки або бітів контрольної суми у своїй відповіді.
Кін Шах

Відповіді:


15

У 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 і є DEFAULT . Під час оновлення з 2000 по 2005 рік ви повинні явно змінити параметр бази даних Page Verify, щоб використовувати CHECKSUM.

Якщо ви відновите базу даних, вже створену на sql 2005, на інший сервер, на якому працює sql 2005, не потрібно її встановлювати. Він зберігатиметься у тому, що ви коли-небудь встановили параметр «Перевірка сторінки».

Мені не вдалося дослідити, коли з’явилося виявлення Torn Page

З: 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 2000 і вище . Якщо у вас працює 7.0 або 6.5, ви можете це підтвердити :-)

введіть тут опис зображення


@Kin aye Я знаю, що це було і в SQL2000, хотілося б знати, коли він був вперше представлений. за фразою "перехід до попередніх версій", зробимо вигляд, що TPD був введений в SQL2000, тоді перехід від SQL7 до SQL2000 буде переходити між версіями до SQL2005. Мені цікаво знати, чи було включено TPD під час таких міграцій. Я повністю сподіваюся, що цього не вдалося, але не змогли це перевірити.
Пол,

@paul Я видалив їх, бо відчув, що моя редакція охоплює коментарі
swasheck

@Kin Я спробував ваш код DBCC на SQL2008R2 і отримав значення m_tornbits 1711843878 .. так що ви сказали б це міра, а не булева?
Пол

@Paul це означає, що контрольна сума або сторінка torm увімкнено. Починаючи з 2005 року і вище, ви повинні піти лише на CHECKSUM. Цікаво, чи є у вас 7,0 лежачих для тестування?
Кін Шах

6

Погляньте на посилання від BOL :

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

Це диктує, що до появи SQL Server 2005 варіант TORN_PAGE_DETECTIONіснував, але ні CHECKSUM.

І щоб відповісти на ваш другий пункт:

... і що оновлення або відновлення БД з попередньої версії підтримувало б його метод підтвердження попередньої сторінки.

Так, це правильно. Вам потрібно буде чітко встановити базу даних, щоб використовувати CHECKSUMметод перевірки сторінки.


Дякуємо за посилання @Thomas, але це не відповідає, коли TORN PAGE DETECTION вперше став доступний у SQL Server.
Пол,

2
@Paul Це відповідає на те, що виявлення порваної сторінки існувало до появи SQL Server 2005. Чи шукаєте ви, в якій версії SQL Server ця перевірка сторінки почала діяти? Окрім уроку історії, я не впевнений, що ви шукаєте, щоб отримати там. Яку проблему саме ви намагаєтеся вирішити?
Томас Стрінгер

Я хотів дізнатися, коли воно виникло та як він поводився під час міграцій. Я сподіваюся зрозуміти, як деякі наші дуже старі БД отримали налаштування, які вони роблять на деяких наших сучасних серверах (ish, SQL2008R2).
Пол,

Якщо у ваших базах даних є TORN_PAGE_DETECTION, то це, безумовно, може призвести до оновлення до попереднього SQL Server 2005, і варіант підтвердження цієї сторінки зберігається.
Thomas Stringer

у них не ввімкнено TPD, це було збитковою частиною. Інші відповіді вирішили проблему зараз (SQL7.0 мав TPD, але за замовчуванням не було включено, і це була версія, спочатку розроблена проти)
Пол,

3

У сучасному 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. Перевірка сторінки встановлена ​​на НІКОЛІ, хоча я очікував, що це буде ВІДКРИТТЯ СТОРІНКИ.

Кожен, хто має дозволи на екземпляр бази даних, може змінити це значення. Це могло б зберігатися через оновлення, як зазначено в MSDN тут :

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

Він також міг бути змінений пізніше, оскільки хтось неправильно зрозумів конфігурацію і стріляв у темряві, щоб спробувати вирішити проблему.

Мені було цікаво, коли ВИКОРИСТАННЯ СТОРІНКИ стала функцією перевірки сторінки

SQL Server 2000, як зазначено вище.

як він поводиться під час міграції чи оновлення до новіших видань.

Попереднє налаштування зберігається під час оновлення, як зазначено вище.

Тепер я хотів би зазначити той факт, що інші посилання, що надаються людьми, стверджують, що SQL Server 7.0 є, коли було доступно виявлення порваної сторінки. Як зазначено в цих статтях, це правда, проте багато разів доводиться, що документація Microsoft не повинна вважатися правдою за будь-яких обставин. Є багато де вони помиляються. Тож із цим сказаним, як ви можете визначити, яка відповідь прийнятна? Ми всі надали документацію Microsoft, щоб підтвердити нашу відповідь.

Крім того, зауважте, що виявлення порваної сторінки знаходиться у списку амортизації станом на SQL Server 2012, тож, з чим викликає занепокоєння те, як це було встановлено у ваших базах даних. Якщо я побачив, що це встановлено на щось інше, ніж CHECKSUM, я негайно змінюю його та переходжу до іншого більш важливого завдання. Я не турбуюсь про те, як була встановлена ​​погана конфігурація, важливіше її виправити, а потім переконатися, що ті, хто має дозволи на її зміну, проінформують, чому цей елемент конфігурації не слід змінювати ні на що інше. Тільки мої 0,02 долара


Я думаю, що 2000 рік був, коли TPD не встановив дефолт до ВКЛ. Як і у багатьох інших нових функцій SQL Server, вони за умовчанням відключають його / вимикають і змушують DBA вмикати їх. У будь-якому випадку +1 від мене за попередження про депресію.
swasheck

Це хороший момент, у вас є гарне посилання, яке, здається, резервне копіювання того, що ви говорите. Але я відчуваю, що посилання на когось інший ( support.microsoft.com/kb/230785 ) перевершує його. Я з більшою ймовірністю вважаю, що розділ управління буфером зрозумів, що він наполовину помиляється, ніж інше посилання зрозуміло, що це абсолютно неправильно. Якщо це має сенс, не зовсім впевнений, я дуже добре ставлю себе!
Пол

Це одна з таких речей, як ліцензування, і MS нічого з цього не робить, це дуже зрозуміло ...

0

Як і @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


Дякую @DaniSQL, однак ще ніхто не відповів на це питання повністю. тобто коли було введено ВІДКРИТТЯ СТРАНИЦІ та як вона поводилася під час оновлення / міграції.
Пол,

Я залишу це для істориків, щоб дізнатися :-) Що стосується оновлення / міграції, то нічого не відбудеться, якщо ви вручну не зміните параметр перевірки сторінки на CHECKSUM у кожній базі даних. Навіть тоді вже існуючі сторінки не матимуть контрольної суми. blogs.msdn.com/b/sqlserverstorageengine/archive/2006/06/29/…
DaniSQL

дякую @DaniSQL, саме тому я розумію перехід на SQL2005 і вище для роботи. Я просто хотів переконатися, що попередні версії також підтримували таку поведінку
Пол,
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.