Widok materializowany

Widok materializowany fizycznie przechowuje wyniki zapytania, wymagające jednak ręcznego lub automatycznego odświeżania.

Jak działa fizycznie zapisany wynik zapytania

Widok materializowany to obiekt bazy danych, który przechowuje na dysku rezultat określonego zapytania. Zwykły widok zapisuje przede wszystkim definicję zapytania i oblicza wynik podczas odczytu, natomiast widok materializowany utrwala wiersze zwrócone w chwili jego utworzenia albo ostatniego odświeżenia. Dzięki temu kolejne odczyty mogą korzystać z gotowych danych zamiast ponownie wykonywać kosztowne operacje łączenia tabel, filtrowania, grupowania lub sortowania.

Przechowywany rezultat nie jest jednak niezależną kopią, która samoczynnie odzwierciedla każdą zmianę w tabelach źródłowych. Jeżeli po utworzeniu widoku materializowanego zostanie dodany, zmodyfikowany albo usunięty rekord w tabeli bazowej, zmiana nie musi być od razu widoczna w materializowanym wyniku. Aktualność zależy od sposobu odświeżania oraz od możliwości konkretnego silnika bazy danych. Z tego powodu widok materializowany należy traktować jako przechowywany, okresowo aktualizowany rezultat zapytania, a nie jako zwykły widok z dodatkową nazwą.

Odświeżanie a aktualność danych

Odświeżenie widoku materializowanego polega na ponownym wykonaniu zapytania źródłowego i zapisaniu nowego rezultatu. Operacja może przebudować całą zawartość obiektu albo, jeżeli dany silnik udostępnia taki mechanizm i spełnione są jego wymagania, uwzględnić zmiany w sposób bardziej przyrostowy. Tryb pełnego odświeżenia jest prostszy do przewidzenia, lecz przy dużych tabelach może długo czytać dane i zajmować zasoby procesora, pamięci masowej oraz systemu wejścia-wyjścia.

Harmonogram odświeżania powinien wynikać z wymaganej świeżości informacji. Raport generowany raz dziennie może korzystać z widoku aktualizowanego w nocy, natomiast zestawienie używane do bieżącej kontroli zapasów wymaga krótszego odstępu między odświeżeniami albo innego modelu przetwarzania. Należy uwzględnić także czas wykonywania zapytania, możliwość nakładania się kolejnych uruchomień oraz zachowanie aplikacji, gdy odświeżenie zakończy się błędem. Samo utworzenie harmonogramu nie gwarantuje aktualności, jeśli zadanie nie uruchamia się poprawnie lub zapytanie zwraca niepełny wynik.

Wydajność, indeksy i koszty utrzymania

Główną korzyścią widoku materializowanego jest skrócenie czasu odczytu danych, gdy zapytanie źródłowe jest złożone, a jego wynik jest wielokrotnie wykorzystywany. Dotyczy to między innymi agregacji, podsumowań według wielu wymiarów oraz raportów wymagających łączenia dużych zbiorów. Po materializacji zapytanie użytkownika może czytać gotowe wiersze. Na widoku materializowanym można również tworzyć indeksy, jeśli obsługiwany silnik na to pozwala. Indeks powinien odpowiadać rzeczywistym warunkom filtrowania i sortowania, ponieważ nieprawidłowo dobrany indeks zwiększa zajętość dysku i koszt odświeżenia bez poprawy pracy aplikacji.

Przyspieszenie odczytu odbywa się kosztem dodatkowego miejsca oraz pracy wykonywanej podczas odświeżania. Trzeba monitorować rozmiar przechowywanego rezultatu, czas przebudowy, blokady, obciążenie dysku i opóźnienie między zmianą danych źródłowych a pojawieniem się nowych informacji. Ważna jest także zależność między widokiem a jego tabelami bazowymi. Zmiana nazw kolumn, typów danych lub logiki zapytania może wymagać przebudowania widoku, modyfikacji indeksów i aktualizacji kodu korzystającego z jego struktury. Jeżeli materializowany wynik jest używany w procesie decyzyjnym, dokumentacja powinna jasno określać datę lub zakres danych objętych ostatnim odświeżeniem.

Rozpoznawanie problemów z materializowanym wynikiem

Objawem nieprawidłowo działającego widoku materializowanego może być rozbieżność między wynikiem bezpośredniego zapytania do tabel źródłowych a wynikiem odczytanym z materializowanego obiektu. Podczas analizy należy porównać czas ostatniego odświeżenia, status zadania uruchamiającego aktualizację, liczbę rekordów oraz warunki użyte w zapytaniu. Warto sprawdzić, czy odświeżenie zakończyło się błędem, czy aplikacja odczytuje właściwy obiekt i czy filtr nie pomija danych z powodu nieoczekiwanej wartości null, zmiany typu albo różnicy strefy czasowej.

Diagnostyka laptopa lub komputera PC zwykle nie polega na naprawianiu samego mechanizmu bazy danych, lecz na ustaleniu, czy problem wynika z aplikacji, połączenia, konfiguracji albo lokalnego środowiska uruchomieniowego. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, dlatego przy problemach z programem korzystającym z materializowanych danych można sprawdzić stan systemu, działanie aplikacji oraz podstawową konfigurację urządzenia. W przypadku problemu po stronie zapytania lub silnika bazy danych konieczna jest dodatkowo analiza definicji obiektu, harmonogramu odświeżania i logów właściwego środowiska bazodanowego.