>>-UPDATE QP_SYSTEM USING--------------------------------------->
>--+-DEFAULT------------------------------+--------------------><
'-CREATE_RESULT_TABLE_ALIASES--+-'Y'-+-'
'-'N'-'
Przy próbie wykonania jednego z wymienionych niżej zadań w Centrum Query Patroller lub w wierszu komend programu Query Patroller generowany jest komunikat ostrzegawczy:
Komunikat ostrzegawczy brzmi:
DQP1024W Utworzenie, zmiana lub usunięcie klasy zapytania
odniesie skutek dopiero po zrestartowaniu serwera Query Patroller.
Również podręcznik DB2 Query Patroller(TM) Guide: Installation, Administration, and Usage dla wersji 8.2 zawiera informację o konieczności zrestartowania serwera Query Patroller po utworzeniu, zmianie lub usunięciu klas zapytań, aby zmiany te odniosły skutek.
Treść komunikatu oraz informacje w podręczniku są nieścisłe. Trzy wymienione wyżej czynności dotyczące klasy zapytań odnoszą skutek natychmiast, chyba że zostaną istnieją zapytania oczekujące w kolejce lub uruchomione. Jeśli istnieją zapytania oczekujące w kolejce lub uruchomione, w tym zapytania nowo wprowadzone, zmiana klasy zapytania odniesie skutek po zrealizowaniu zapytań oczekujących w kolejce lub uruchomionych. Aby uniknąć oczekiwania na zrealizowanie oczekujących lub uruchomionych zapytań, należy zrestartować serwer Query Patroller.
Znaczenia stanów zapytania Anulowane i Gotowe zostały zaktualizowane w następujący sposób:
Przy uruchamianiu generatora danych historycznych dla programu Query Patroller utworzone zostaną tabele wyjaśniania, o ile nie zostały utworzone wcześniej. Jednak zdecydowanie zalecane jest utworzenie tabel wyjaśniania przed uruchomieniem generatora danych historycznych. Tworząc tabele wyjaśniania należy zadbać o to, by znalazły się one w tej samej partycji. Samodzielne utworzenie tabel wyjaśniania w tej samej partycji poprawia wydajność działania narzędzia wyjaśniającego. To z kolei korzystnie wpływa na wydajność generatora danych historycznych.
Jeśli kolumna Explain Run (Uruchomienie wyjaśniania) w raporcie Query Activity over Time (Historical Analysis) (Częstotliwość zapytań - Analiza historyczna) zawiera status zapytania Ran unsuccessfully (Wykonanie niepomyślne), oznacza to, że dla tego zapytania dane historyczne nie zostały wygenerowane. Z tego powodu zapytanie to nie będzie figurować w żadnych raportach ani wykresach dotyczących analizy historycznej. Zgodnie z dokumentacją wersji 8, aby ustalić przyczyny nieudanego wykonania zapytania, należy przeanalizować zawartość pliku qpuser.log.
Oprócz pliku qpuser.log należy także przejrzeć zawartość pliku qpdiag.log.
Jeśli używany jest generator danych historycznych i jego zamknięcie nastąpi w sposób nieprawidłowy, przy następnej próbie uruchomienia tego generatora zostanie wyświetlony komunikat o błędzie. Poniżej wymieniono przykłady nieprawidłowego zamknięcia generatora danych historycznych:
Gdy generator danych historycznych zostanie zatrzymany w sposób nieprawidłowy, przed podjęciem próby ponownego uruchomienia tego generatora konieczne jest wywołanie następującej komendy:
qp -d baza_danych generate historical_data stop
gdzie baza_danych określa bazę danych, względem której wykonywana jest ta komenda.
Po wykonaniu niektórych operacji na klasach zapytań nie jest już wymagane zatrzymanie i zrestartowanie programu Query Patroller w celu uwzględnienia zmian.
W poniższej tabeli zapytanie aktywne to zapytanie ze statusem Uruchomione lub W kolejce.
Zagnieżdżone zapytania nie mogą być umieszczane w kolejce. Jeśli nastąpi przekroczenie progu, które zwykle spowodowałoby umieszczenie zapytania w kolejce, zagnieżdżone zapytanie zostanie wykonane natychmiast.
Inaczej niż w poprzednich wersjach, obecnie można umieszczać w kolejce zapytania zawierające następujące instrukcje:
Podczas korzystania z klienta usług terminalowych (Terminal Services Client) z rozdzielczością 640x480 w celu połączenia się z pulpitem zdalnym, na którym działa Centrum Query Patroller, okno Submission Preferences (Preferencje wprowadzania) może wydawać się puste. Aby okno to było wyświetlane poprawnie, należy użyć rozdzielczości większej niż 640x480.
Od wersji 8.2 program DB2 Universal Database (UDB) obsługuje grupy użytkowników inne niż grupy w systemie operacyjnym. Powoduje to niewielką zmianę w rozwijanej liście Submitter Profile to Use (Używany profil wprowadzającego) w oknie Query Submission Preferences (Preferencje wprowadzania zapytań) w Centrum Query Patroller.
Użytkownik zalogowany do programu Query Patroller, ale nie posiadający uprawnienia DBADM ani uprawnienia do edycji w zakresie zarządzania innymi użytkownikami programu Query Patroller, może tylko dodawać i aktualizować swoje własne preferencje wprowadzania. W takim wypadku rozwijana lista Submitter Profile to Use (Używany profil wprowadzającego) zawiera istniejące profile dla grup programu DB2 UDB, do których należy dany użytkownik, a nie grup systemu operacyjnego, do których należy ten użytkownik.
Użytkownik zalogowany do programu Query Patroller i posiadający uprawnienia DBADM lub uprawnienia do edycji w zakresie zarządzania innymi użytkownikami programu Query Patroller, może dodawać i aktualizować preferencje wprowadzania innych użytkowników. W takim wypadku rozwijana lista Submitter Profile to Use (Używany profil wprowadzającego) zawiera wszystkie istniejące grupowe profile wprowadzającego.
Podczas pracy z harmonogramami w Centrum Query Patroller można zapisywać harmonogramy w oknie Schedule (Harmonogram) i później je importować. Harmonogramów zapisanych przy użyciu pakietu poprawek 6 lub starszego nie można zaimportować do wersji 8.2 lub nowszej. Ograniczenie to jest spowodowane zmianą w szeregowaniu między poziomami pakietów JDK wprowadzonymi w programie DB2 UDB, wersja 8.2.
Komendę RUN IN BACKGROUND QUERY może uruchomić wyłącznie użytkownik, który pierwotnie wprowadził zapytanie.
Od wersji 8.1 z pakietem poprawek 5 program Query Patroller przestał tworzyć tabele wynikowe w schemacie zgodnym z identyfikatorem autoryzowanego użytkownika, który wprowadził zapytanie. Obecnie program Query Patroller tworzy tabele wynikowe we wspólnym schemacie DB2QPRT. Aby umożliwić odwoływanie się do tabel przy użyciu schematu użytkownika wprowadzającego, w programie Query Patroller, wersja 8.2, wprowadzono opcję automatycznego tworzenia aliasu dla każdej nowej tabeli wynikowej tworzonej przez program Query Patroller. Tabela wynikowa jest tworzona w schemacie DB2QPRT, a alias jest tworzony w schemacie zgodnym z identyfikatorem autoryzowanego użytkownika, który wprowadził zapytanie.
Aby włączyć lub wyłączyć tę opcję, należy użyć komendy UPDATE QP_SYSTEM z opcją CREATE_RESULT_TABLE_ALIASES:
Aliasy utworzone z opcją CREATE_RESULT_TABLE_ALIASES są automatycznie usuwane podczas usuwania tabeli wynikowej. Mogą się jednak zdarzyć dwie sytuacje, w których tabela wynikowa zostaje usunięta, a odpowiadające jej aliasy - nie.
Aby usunąć aliasy, dla których odpowiadające tabele wynikowe zostały usunięte, wprowadzono nową komendę REMOVE RESULT_TABLE_ALIASES. Jest ona wykonywana automatycznie za każdym razem, gdy tabele wynikowe są usuwane w ramach zaplanowanego w programie Query Patroller procesu usuwania tabel wynikowych. Komenda REMOVE RESULT_TABLE_ALIASES uzyskuje listę aliasów do usunięcia na podstawie następującego zapytania:
with a as (select tabschema, tabname from syscat.tables
where type = 'A' and tabname like 'QUERY%_RESULTS'),
t as (select tabname from syscat.tables
where type = 'T' and tabname like 'QUERY%_RESULTS')
select all tabschema, tabname from a
where not exists (select * from t where t.tabname=a.tabname)
Konieczne jest uprawnienie DBADM.
Komenda ta usuwa wszystkie aliasy, dla których usunięto odpowiadające im tabele wynikowe. Aliasy te zostały pierwotnie utworzone przez program Query Patroller dla tabel wynikowych.
Program Query Patroller korzysta z pewnych chronionych procedur zapisanych w bazie, które mogą umieszczać wpisy w pliku qpdiag.log. W związku z tym identyfikator chronionego użytkownika musi mieć dostęp do zapisu do pliku qpdiag.log oraz do ścieżki, w której znajduje się plik qpdiag.log.
[ Początek strony |Poprzednia strona | Następna strona | Spis treści ]