SQL: co sie dzieje, kiedy zmieniasz PageVerify na CHECKSUM?

9-Sie-2019

Stare bazy migrowane ze starych systemow SQL moga miec ustawiona opcje PageVerify na TORN_DETECTION. Oczywiscie to metoda z zeszlego wieku i aktualnie powinnismy uzywac CHECKSUM. Obie wartosci mowia o tym w jaki sposob kontrolowac, czy zapis strony bazy danych na dysk wykonal sie w 100%, czy tez sa jakies problemy. TORN_PAGE pozwoli dowiedziec sie tylko o tym czy zapis zostal zakonczony poprawnie, podczas gdy CHECKSUM pozwala sprawdzic czy podczas zapisu (lub odczytu) nie doszlo do przeklamania.

Zalozmy ze jedna z baz przetrwala od roku 2005 do dzisiaj z opcja TORN_PAGE. Co sie stanie kiedy zmienimy opcje na CHECKSUM? Czy ta jedna zmiana spowoduje, ze serwer przeczyta wszystkie strony z dysku, wyliczy na nich sume kontrolna i zapisze dane spowrotem na dysk? Czy jezeli jakas strona byla uszkodzona i miala ustawiony bit odpowiadajacy za TORN_DETECTION to czy ten blad bedzie nadal widoczny?

Otoz:

  • Po zmianie opcji serwer NIE przeczyta i nie wyliczy sumy kontrolnej dla wszystkich stron. Bedzie sie to dzialo sukcesywnie w miare nowych zapisow stron na dysk. Jesli masz wiec tabele z 1 rekordem, ktory nigdy sie nie zmieni, to strona na ktorej ta tabela jest zapisana nie bedzie maila wyliczonej sumy kontrolnej. Mozna to nieco przyspieszyc wymuszajac np. przebudowanie wszystkich tabel i indeksow.
  • Po zmianie opcji, jesli strona miala ustawiony bit TORN_DETECTION, to ten bit bedzie nadal ustawiony. Podczas odczytu takiej strony serwer zglosi po prostu blad

Wiecej na ten temat pisze Paul Randal w swojej serii Myth busters:

A SQL Server DBA myth a day: (17/30) page checksums

 

Komentarze:

  1. Gość napisał,

    Mój komentarz nie jest związany z tematem tego wpisu, ale przypomniałem sobie dziwny błąd który wyrzucił mi SQL Developer (czyli GUI), gdy bawiłem się bazą utworzoną w Oracle 11g XE. Niestety głupio zrobiłem i nie zachowałem sobie kodu PL/SQL. Przerabiałem jakiś przykład procedury przetwarzającej łańcuch znaków. Gdy ten łańcuch zawierał tylko znaki ASCII, to procedura działała poprawnie. A gdy zawierał polskie litery, to SQL Developer zgłaszał mi błąd składni SQL. Sprawdzałem działanie wielokrotnie i błąd był powtarzalny za każdym razem. Natomiast gdy tą samą procedurę uruchomiłem z wiersza poleceń, czyli za pomocą okna SQL*Plus, to obie wersje łańcuchów były przetwarzane poprawnie, bez błędu. Błąd był o tyle dziwny że SQL Developer potraktował polskie znaki (a pewnie któryś konkretny) z łańcucha, jako część składni SQL, a takie coś jest niedopuszczalne. Taki dziwny przypadek jak z „Archiwum X”. A czy Pan też miał jakieś przypadki z „Archiwum X” w trakcie swojej pracy?

  2. Rafał Kraik napisał,

    Staram się ich nie mieć… bo lepiej znać przyczyny niż nie, ale oczywiście nie zawsze się da. Tak jak w dowcipie:
    -co to jest informatyka teoretyczna – wszyscy wiedzą co zrobić zeby działało, ale nie działa
    -a co to jest informatyka stosowana – działa, ale nikt nie wie dlaczego

Dodaj komentarz:

Autor: Rafał Kraik