Pokochać testy, czyli droga bez powrotu

Bohdan Szymczak

Przeniesienie systemu na nową wersję bazy danych niesie ze sobą zawsze pewne ryzyko niepowodzenia. Wynika ono z faktu, iż nowe oprogramowanie RDBMS wraz z nową, zwykle bardzo atrakcyjną funkcjonalnością może być w pewnych obszarach niekompatybilne wstecz, oraz oczywiście – jak każdy software – posiada nowe, czasem zidentyfikowane, ale częściej nieznane błędy. Z tego powodu przenosząc aplikację użytkową na nową wersję bazy danych, należy taką operację dokładnie zaplanować i – co najważniejsze – przeprowadzić wcześniej próby na środowisku testowym.

Dobrą praktyką stosowaną w informatyce jest radykalne ubezpieczenie niepowodzenia poprzez przygotowanie procedury wycofania zmian (rollback, fallback). Stosuje się ją wszędzie tam, gdzie istnieje ryzyko błędu po implementacji nowego oprogramowania, zaś możliwości zaradcze są niewystarczające lub skutki przeciągającej się awarii są na tyle poważne, że nieakceptowane przez kierownictwo firmy. Wycofanie się ze zmiany oprogramowania i przywrócenie poprzedniej wersji jest sposobem na radykalne, choć doraźne rozwiązanie problemu i daje możliwość lepszego przygotowania się do kolejnej próby aktualizacji.

W przypadku podniesienia wersji bazy Oracle z 9i na 10g istnieje możliwość wycofania się z przeprowadzonej operacji, o ile uruchomienie nowej wersji oprogramowania nie zostało połączone z ustawieniem parametru inicjalizacyjnego bazy COMPATIBLE na wartość 10.2. Planując operację upgrade do wersji 10g, można ją przeprowadzić dwuetapowo, to znaczy początkowo uruchomić nowe binaria „pod rządami” parametru COMPATIBLE równego 9.2, zaś po pewnym okresie eksploatacji podnieść wartość parametru do 10.2.

Jeżeli jednak baza rozpocznie swoją pracę z ustawioną wartością parametru COMPATIBLE równą 10.2 i pojawią się poważne problemy eksploatacyjne, które nie będą mogły być szybko rozwiązane, to próba powrotu do starej wersji oprogramowania bazy danych skończy się niepowodzeniem, co uwidoczni się poniższym komunikatem:

SQL> STARTUP DOWNGRADE;
ORACLE instance started.
Total System Global Area 436207616 bytes
Fixed Size 2029528 bytes
Variable Size 327157800 bytes
Database Buffers 104857600 bytes
Redo Buffers 2162688 bytes
ORA-00201: control file version 10.2.0.0.0 incompatible with ORACLE version 9.2.0.6.0
ORA-00202: control file: '/u01/oradata/B920/control01.ctl'

A zatem, uruchomienie migrowanej bazy danych w pełnej funkcjonalności wersji 10.2 nie daje możliwości powrotu do wersji 9i przy użyciu mechanizmów downgrade, a tylko ten mechanizm w prosty sposób gwarantuje brak utraty danych wprowadzonych do bazy już po podniesieniu wersji. Rozwiązaniem alternatywnym jest odtworzenie ostatniej pełnej kopii bazy danych, która zgodnie z regułami bezpieczeństwa, powinna być wykonana tuż przed operacją upgrade, a następnie ponowne wprowadzenie danych z okresu nieudanej eksploatacji podniesionej wersji bazy.

Dla pewnej klasy aplikacji, takie rozwiązanie, jakkolwiek uciążliwe i generujące dużą pracochłonność, jest akceptowalne, a co najważniejsze wykonalne. Są to aplikacje, dla których istnieje możliwość wtórnego wprowadzenia danych, albo w sposób ręczny, albo automatyczny. Można również – przewidując ewentualne problemy – drukować i przechowywać wszystkie dokumenty źródłowe wprowadzane do systemu, a następnie, w razie konieczności powrotu do poprzedniej wersji bazy, ponownie wprowadzić je ręcznie.

Szereg nowoczesnych systemów nie daje jednak takich możliwości. Należą do nich przede wszystkim systemy pracujące w trybie ciągłym 24×7, mające zwykle podłączone liczne interfejsy poprzez szereg kanałów dostępu. Systemy bankowe, sklepy internetowe, zautomatyzowane systemy logistyki przetwarzają dane pochodzące z różnych źródeł w sposób ciągły i na ogół nie mają wbudowanej funkcjonalności powtórnego wprowadzenia wszystkich danych. Dla tych systemów proces upgrade bazy do pełnej funkcjonalności wersji 10.2 jest drogą bez powrotu; kto na nią wstąpi musi podążać do przodu, gdyż możliwość wycofania się jest bardzo utrudniona.

Skoro zatem ryzyko podniesienia wersji bazy jest tak wysokie, należy dobrze zastanowić się jak je zminimalizować, a wręcz całkowicie zniwelować. Pozostawiając rozważania o rozbudowie funkcjonalności aplikacji, zobaczmy najpierw, co proponuje w tym temacie producent bazy. Odpowiednia do tego celu będzie lektura dokumentu „Oracle Upgrade Companion”, który jest cennym uzupełnieniem podstawowej instrukcji „Oracle Database 10g Upgrade Guidei stanowi w dużej części zbiór dobrych praktyk zebranych przez zespół techniczny Oracle w procesie zdobywania wiedzy i doświadczeń u użytkowników bazy.

Duży nacisk należy położyć na bardzo dobre przygotowanie i zaplanowanie operacji upgrade, oraz weryfikację działania nowej wersji poprzez gruntowne testy regresywne. Właśnie testy mają stanowić główny element zabezpieczenia dla całej operacji, ale ze względu na ich rozległość, stanowią również największy koszt dla tej operacji. Testowi powinien podlegać cały system, a więc zarówno główna aplikacja, jak i aplikacje pomocnicze, interfejsy i narzędzia administracyjne. Przy dużych systemach koszt upgrade, to również czas niezbędny na zaplanowanie i przeprowadzenie testów. Nie należy zakładać, że cała operacja podniesienia wersji Oracle dla dużych baz i skomplikowanych instalacji, może być wykonana „z marszu”; wręcz przeciwnie – okres przekraczający nawet 6 miesięcy jest w tym przypadku całkowicie uzasadniony i nie powinien budzić zdziwienia.

Budowa środowiska testowego to kolejne wyzwanie. Największy nacisk należy położyć na jego zgodność z instalacją produkcyjną. Głównymi parametrami określającymi tę zgodność są: jednakowa platforma sprzętowa i systemowa, baza w postaci kopii bazy produkcyjnej, oraz – co niezwykle istotne – przeprowadzenie testów w sposób możliwie najlepiej symulujący zachowanie aplikacji produkcyjnej. Planując scenariusze testowe należy wziąć pod uwagę obszary, które w naturalny sposób są kandydatami do sprawdzenia. Ponieważ zmienionym elementem systemu nie jest aplikacja, ale baza danych, zatem warto zwrócić uwagę na te cechy bazy, które uległy zmianie w porównaniu z wersją poprzednią, lub które zgodnie z informacją producenta mogą funkcjonować odmiennie.

Takim wrażliwym elementem jest wydajność bazy, będąca pochodną tworzonych przez optymalizator planów wykonań. Jak wspomniałem w artykule „Statystyczna pułapka, czyli donos na ciernistą drogę od 9i do 10g„, zamieszczonym w poprzednim numerze PLOUG’tek, działanie optymalizatora zapytań jest jedną z poważniejszych zmian w Oracle 10g, stąd właściwe zaplanowanie i przeprowadzenie testów wydajnościowych jest kluczowe dla powodzenia przyszłej operacji na środowisku produkcyjnym.

Osobnym problemem jest umiejętność generacji obciążenia bazy danych przy pomocy transakcji, które w największym stopniu odzwierciedlają obciążenie rzeczywiste. Przyszła migracja do wersji 11g będzie pod tym względem łatwiejsza, dzięki dostępności mechanizmu Oracle Replay; na razie trzeba jednak posługiwać się oprogramowaniem innych firm, lub własną inwencją.

Wydaje się, że największe zagrożenie dla operacji upgrade’u bazy pochodzi z dwóch źródeł:

  • Wewnętrznych bugów oprogramowania Oracle;
  • Zmiany działania optymalizatora zapytań i wynikającej stąd możliwości generacji nieoptymalnych planów zapytań.

Pierwsze zagrożenie powinno być zneutralizowane wnikliwą analizą opublikowanej na Metalinku listy patchy, które w postaci one-off mogą rozwiązać wykryte błędy. O ile błędy pojawią się już w środowisku produkcyjnym, to pozostaje już tylko liczyć na niezawodny support producenta.

Drugie zagrożenie jest poważne, gdyż w krytycznym przypadku może doprowadzić do całkowitej awarii systemu. Aby temu zaradzić, należy rygorystycznie podejść do wszelkich zaleceń producenta bazy danych, opisujących warunki do prawidłowej pracy optymalizatora. Prawidłowość i aktualność statystyk naliczonych na obiektach bazy danych, statystyk słownikowych oraz systemowych odgrywa tu rolę kluczową. I znów, weryfikacja tych działań musi być wykonana w procesie testowym.

A zatem, drogi użytkowniku bazy Oracle, czas najwyższy zapłonąć gorącą miłością do testów – tylko to bowiem może zapewnić ci spokój na drodze do świetlanej przyszłości, którą wiążesz oczywiście z nowymi funkcjonalnościami bazy Oracle 10g, a dalej 11…

Czy jednak, zgodnie z postawioną na początku tezą, podniesienie wersji bazy do 10.2 jest faktycznie drogą bez powrotu?

Z jednej strony istnieje w dokumencie „Oracle Upgrade Companion” zdecydowane sformułowanie, cytuję: „You cannot downgrade if you have changed the COMPATIBLE parameter to 10.2.0.x from 9.2.0.x.„, ale znajduje się ono w punkcie zatytułowanym symptomatycznie: „When All Else Fails… Going Back to the Previous Version„. A zatem producent widzi jednak pewne szanse, które sprowadzają się według niego do trzech możliwości:

  1. Użycie repliki bazy danych i mechanizmu streams – gwarantuje brak utraty danych i szybkie przekazanie poprzedniej wersji do eksploatacji;
  2. Użycie mechanizmu export/import – gwarantuje brak utraty danych, ale czas trwania operacji eksportu danych z bazy w wersji 10g i importu do bazy w wersji 9i może być nieakceptowanie długi, szczególnie dla baz o dużych rozmiarach;
  3. Odtworzenie bazy w wersji 9i z kopii bezpieczeństwa – oznacza utratę danych wprowadzonych do bazy po podniesieniu wersji do 10g, lub konieczność powtórnego ich wprowadzenia, o ile taką możliwość daje aplikacja.

W tym krótkim artykule, chciałem zasygnalizować kolejny problem, jaki wiąże się z podniesieniem wersji bazy danych Oracle z 9i do 10g. Jak pokazano, po uruchomieniu pełnej funkcjonalności bazy 10g nie ma prostej metody powrotu do wersji poprzedniej. Jest to faktycznie droga bez powrotu, chyba, że w ramach przygotowania do operacji zostanie również opracowana procedura wycofania, oparta o jedną z trzech podanych powyżej metod. Żadna z nich nie jest pozbawiona wad, każda powinna być wcześniej również sprawdzona. Jak zatem wykonać upgrade bezpiecznie i z pełnym sukcesem? Po prostu – pokochać testy…

Bibliografia:

  1. Oracle® Database Upgrade Guide 10g Release 2 (10.2) B14238-02, January 2008
  2. Complete Checklist for Manual Upgrades to 10gR2 Note:316889.1, Last Revision Date: 22-APR-2008
  3. Oracle Upgrade Companion
  4. Best Practices for Load Testing. Note:466452.1
  5. Statystyczna pułapka, czyli donos na ciernistą drogę od 9i do 10g. PLOUG’tki nr 46