Widok wielokrotnie zagnieżdżony

Wielokrotnie zagnieżdżony widok odwołuje się do innych widoków, co może pogarszać wydajność zapytań.

Na czym polega wielokrotne zagnieżdżenie widoku

Widok wielokrotnie zagnieżdżony to obiekt logiczny w bazie danych, którego definicja odwołuje się do innego widoku, a ten z kolei korzysta z kolejnych widoków. Przykładowo widok raportowy może pobierać dane z widoku łączącego tabele klientów i zamówień, który korzysta z widoku filtrującego aktywne rekordy. W takim układzie końcowe zapytanie nie odczytuje wyłącznie tabel źródłowych, lecz przechodzi przez kilka poziomów definicji.

Widok zazwyczaj nie przechowuje osobnej kopii wyniku zapytania. Podczas wykonania zapytania silnik bazy danych rozwija definicję widoku i analizuje wynikający z niej instruktaż zapytania razem z warunkami, złączeniami, sortowaniem oraz agregacjami. Konkretne zachowanie zależy od używanego silnika i rodzaju widoku, dlatego samo zagnieżdżenie nie oznacza automatycznie błędu. Problem pojawia się wtedy, gdy kolejne warstwy ukrywają kosztowne operacje albo utrudniają optymalizatorowi wybór efektywnego planu wykonania.

Wpływ na plan wykonania i wydajność zapytań

Każdy poziom zagnieżdżenia może dodawać następne złączenia tabel, filtry, grupowanie lub obliczenia. Jeżeli kilka widoków wykonuje podobne operacje, końcowe zapytanie może przetwarzać większy zbiór danych, niż sugeruje krótka instrukcja wywołująca widok. Szczególnie niekorzystne jest filtrowanie dopiero w zewnętrznym zapytaniu, gdy wcześniejszy widok zwraca wiele wierszy i dopiero później ograniczana jest ich liczba. W takiej sytuacji rośnie koszt odczytu, sortowania i przekazywania danych pomiędzy etapami planu.

Wielokrotnie zagnieżdżony widok może również utrudniać analizę planu wykonania. W raporcie planu pojawiają się wtedy operacje wynikające z kilku definicji, a osoba diagnozująca problem musi prześledzić zależności między obiektami. Niektóre konstrukcje ograniczają możliwość przesuwania predykatów do wcześniejszych etapów zapytania. Dotyczy to między innymi złożonych wyrażeń, agregacji, funkcji okienkowych, operatorów zbiorowych i obliczeń wykonywanych przed zastosowaniem końcowego filtra. Rzeczywisty wpływ należy oceniać na danych podobnych do produkcyjnych, sprawdzając czas wykonania, liczbę odczytanych stron, zużycie pamięci oraz operacje sortowania.

Diagnostyka zależności i typowe problemy projektowe

Analizę warto rozpocząć od sporządzenia grafu zależności: dla każdego widoku należy ustalić, z jakich widoków i tabel korzysta oraz które obiekty są używane przez inne zapytania. Pomaga to wykryć cykliczne zależności, powtarzające się złączenia i warstwy, które nie wprowadzają żadnej dodatkowej logiki. Należy też porównać listy kolumn, typy danych i znaczenie filtrów. Widok może wyglądać jak prosty interfejs, ale po zmianie tabeli bazowej jego kolumny, typy lub semantyka mogą przestać odpowiadać oczekiwaniom aplikacji.

Do praktycznych oznak problemu należą: długi czas wykonania tylko niektórych wariantów zapytania, nagły wzrost liczby odczytów po dodaniu kolejnego poziomu, pełne skanowanie dużych tabel, wielokrotne sortowanie oraz duże różnice między planem dla małego i dużego zakresu danych. Nie należy usuwać widoków wyłącznie dlatego, że są zagnieżdżone. Bezpieczniejsze jest porównanie planu przed i po uproszczeniu definicji, sprawdzenie poprawności wyników oraz pomiar zapytań z reprezentatywnymi parametrami. Czasem lepszym rozwiązaniem jest połączenie kilku warstw w jedną przejrzystą definicję, ograniczenie liczby zwracanych kolumn, przeniesienie selektywnego filtra bliżej tabel źródłowych albo zastosowanie mechanizmu materializowania wyników, jeśli dany silnik go obsługuje.

Rola tego elementu w diagnostyce laptopa i komputera PC

Problemy z wielokrotnie zagnieżdżonymi widokami mogą być odczuwalne na komputerze użytkownika jako wolne działanie programu, długie otwieranie raportu albo chwilowe obciążenie procesora, pamięci masowej i pamięci operacyjnej. Sam widok znajduje się jednak w bazie danych lub w aplikacji korzystającej z bazy, więc wymiana podzespołu nie zastępuje analizy zapytania. Na laptopie lub komputerze PC warto rozdzielić objaw sprzętowy od programowego: sprawdzić, czy opóźnienie występuje tylko w jednej funkcji, czy również w innych aplikacjach, oraz czy powtarza się przy tym samym zapytaniu.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, a w przypadku problemów z działaniem aplikacji można rozpocząć od diagnostyki systemu, dysku, pamięci oraz procesów obciążających komputer. Jeżeli sprzęt działa prawidłowo, dalszej analizy wymaga konfiguracja aplikacji, połączenie z bazą i plan wykonywania zapytania po stronie używanego systemu bazodanowego. Takie rozdzielenie ułatwia ustalenie, czy przyczyną jest awaria komputera, przeciążenie zasobów, opóźnienie sieciowe, czy nieefektywna definicja zagnieżdżonych widoków.