Odtwarzanie procedur i indeksów

Odtwarzanie procedur i indeksów to etap przywracania bazy, w którym po danych odtwarza się obiekty pochodne.

Rola procedur i indeksów po odtworzeniu danych

Odtwarzanie procedur i indeksów to etap przywracania bazy danych po awarii, uszkodzeniu nośnika, błędnej operacji administracyjnej albo odtworzeniu kopii zapasowej. Najpierw przywraca się zapisane dane, a następnie odtwarza obiekty, które opisują sposób korzystania z tych danych lub przyspieszają ich wyszukiwanie. Do tej grupy należą między innymi procedury składowane, funkcje, wyzwalacze, widoki oraz indeksy. Nie są one zwykle kopią samych rekordów, lecz częścią struktury i logiki bazy.

Procedura składowana zawiera zapisane instrukcje wykonywane przez silnik bazy, na przykład zapytania odczytujące dane, aktualizujące rekordy lub kontrolujące transakcję. Indeks jest dodatkową strukturą z kluczami uporządkowanymi według wybranych kolumn i odwołaniami do odpowiednich wierszy. Po odtworzeniu tabel dane mogą więc być dostępne, ale aplikacja może działać wolno albo zwracać niepełne wyniki, jeśli obiekty zależne nie zostały przywrócone lub nie zostały poprawnie odbudowane.

Kolejność zależności podczas przywracania bazy

Właściwa kolejność odtwarzania wynika z zależności między obiektami. Tabele i inne obiekty przechowujące dane muszą istnieć, zanim można utworzyć indeks odnoszący się do ich kolumn. Procedura odwołująca się do tabeli, widoku lub funkcji może zostać utworzona wcześniej tylko wtedy, gdy konkretny silnik dopuszcza takie odwołanie i późniejszą kompilację. W praktyce bezpieczniej jest najpierw odtworzyć schemat, następnie dane, później indeksy, a na końcu obiekty zawierające wykonywaną logikę.

Podczas odbudowy trzeba sprawdzić klucze główne, ograniczenia unikatowości i klucze obce, ponieważ indeksy mogą być powiązane z wymuszaniem tych reguł. Indeks unikatowy nie pozwoli utworzyć struktury, jeżeli w tabeli znajdują się powtarzające się wartości, które powinny być niepowtarzalne. Z kolei indeks oparty na kolumnie usuniętej, przemianowanej albo mającej inny typ danych zakończy się błędem. Samo odtworzenie definicji obiektu nie oznacza zatem, że jego działanie zostało zweryfikowane.

Procedury i funkcje mogą również zależeć od uprawnień, schematów oraz nazw obiektów. Po odtworzeniu należy porównać właścicieli, role i prawa wykonywania z konfiguracją sprzed awarii. Zmiana użytkownika definiującego obiekt może wpłynąć na sposób rozwiązywania nazw i dostęp do tabel. Błąd ujawniony dopiero przy pierwszym wywołaniu procedury jest szczególnie niebezpieczny, ponieważ proces odtwarzania może formalnie zakończyć się powodzeniem, mimo że aplikacja nie będzie mogła wykonać wymaganej operacji.

Odbudowa indeksów i kontrola ich spójności

Indeksy odtwarza się na podstawie zapisanych definicji obejmujących tabelę, kolumny, kolejność kluczy oraz ewentualne warunki filtrowania. Kolejność kolumn w indeksie ma znaczenie dla optymalizatora zapytań: indeks zaczynający się od kolumny klient_id może być użyteczny dla wyszukiwania po tej kolumnie, ale nie musi przyspieszać zapytania filtrującego wyłącznie po drugiej lub trzeciej kolumnie klucza. Przywrócenie indeksu wymaga więc zachowania jego dokładnej definicji, a nie tylko utworzenia dowolnej struktury na tej samej tabeli.

Po odbudowie należy przeprowadzić kontrolę spójności bazy oraz sprawdzić, czy silnik poprawnie odczytuje wszystkie tabele i indeksy. Weryfikuje się również liczbę rekordów, działanie kluczy unikatowych, obecność wymaganych ograniczeń i wyniki reprezentatywnych zapytań. Jeżeli silnik przechowuje statystyki używane do wyboru planu wykonania, mogą one wymagać ponownego zebrania po masowym odtworzeniu danych. Nie należy jednak utożsamiać statystyk z indeksami: statystyki opisują rozkład danych, natomiast indeks jest fizyczną lub logiczną strukturą służącą do wyszukiwania.

Wydajność po odtworzeniu może różnić się od stanu sprzed awarii. Przyczyną może być brak części indeksów, inna kolejność odbudowy, nieaktualne statystyki, zmiana parametrów silnika albo odtworzenie danych w innej kolejności. Kontrola powinna obejmować czas wykonania kluczowych zapytań, użyty plan wykonania oraz występowanie pełnych skanów tabel tam, gdzie wcześniej stosowano indeks. Dodatkowo warto sprawdzić, czy odbudowa nie utworzyła indeksów dublujących się funkcjonalnie, ponieważ takie struktury zwiększają koszt zapisów i zajmują miejsce bez proporcjonalnej korzyści.

Test funkcjonalny po zakończeniu odtwarzania

Końcowy test powinien potwierdzić nie tylko obecność obiektów, lecz także ich działanie w typowych scenariuszach. Należy uruchomić procedury odczytujące dane, wykonujące zmianę rekordu i obsługujące transakcję, a następnie porównać wyniki z oczekiwanym zachowaniem. W przypadku procedury modyfikującej dane sprawdza się, czy zmiana jest zapisywana, czy błędne parametry są odrzucane oraz czy transakcja może zostać wycofana bez pozostawienia częściowo zmienionych danych. Testy powinny być wykonywane na kontrolowanym zbiorze danych, aby nie wprowadzać dodatkowych zmian do produkcyjnej bazy.

Osobno warto przetestować widoki, funkcje i wyzwalacze zależne od odtworzonych tabel. Zapytanie korzystające z widoku powinno zwrócić prawidłowe kolumny i rekordy, funkcja powinna poprawnie obsłużyć wartości puste oraz typowe wartości graniczne, a wyzwalacz nie powinien wykonywać operacji wielokrotnie dla jednego zdarzenia. Dzienniki silnika i aplikacji należy sprawdzić pod kątem błędów kompilacji procedur, naruszeń ograniczeń, brakujących uprawnień oraz przekroczeń czasu wykonania. Dopiero zgodny wynik testów strukturalnych, funkcjonalnych i wydajnościowych potwierdza, że odtwarzanie zostało zakończone poprawnie.

W dokumentacji odtworzenia powinny znaleźć się informacje o użytej kopii zapasowej, zakresie przywróconych danych, kolejności tworzenia obiektów, błędach pominiętych podczas procesu i wynikach testów. Taki zapis ułatwia ponowne wykonanie procedury oraz porównanie środowiska po awarii z konfiguracją referencyjną. W przypadku problemów z komputerem, na którym działa lokalna baza lub narzędzia administracyjne, diagnostyka powinna obejmować stan dysku, dostępność miejsca, połączenie z bazą i poprawność plików konfiguracyjnych, ponieważ awaria sprzętowa może ponownie przerwać odbudowę obiektów.