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:
Komentarze:
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?
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