Query Patroller

Aktualizace chování tříd dotazů

Při provedení některé z následujících úloh prostřednictvím centra Query Patroller nebo z příkazového řádku modulu Query Patroller se zobrazí varovná zpráva:

Text varování:

DQP1024W  Vytvoření, změny a odebrání třídy dotazů se 
          projeví až po restartování serveru Query Patroller.

Také v příručce DB2 Query Patroller(TM) Guide: Installation, Administration, and Usage verze 8.2 je uvedeno, že po vytvoření, změně nebo odebrání tříd dotazů je nutné restartovat server Query Patroller, aby změny vstoupily v platnost.

Zpráva ani text v příručce již neodpovídají skutečnosti. Uvedené akce s třídami dotazů se projeví bezprostředně po provedení, pokud nejsou ve frontě zařazeny žádné dotazy ani neprobíhá jejich zpracování. Pokud existují dotazy ve frontě nebo zpracovávané dotazy, včetně nově zadaných dotazů, změny třídy dotazů proběhnou po dokončení zpracování čekajících nebo právě prováděných dotazů. Nechcete-li čekat na dokončení všech čekajících a zpracovávaných dotazů, musíte restartovat server Query Patroller.

Poznámka:
Aktualizace maximálního počtu dotazů pro třídu dotazů se podobně jako u starších verzí modulu Query Patroller projeví okamžitě.

Aktualizace definic pro stavy spravovaných dotazů

Významy stavů dotazu ZrušenoHotovo byly aktualizovány následujícím způsobem:

Zrušeno
Dotaz byl zrušen prostřednictvím Centra Query Patroller nebo prostřednictvím příkazového řádku modulu Query Patroller, a to administrátorem, odesilatelem, nebo operátorem, jehož profil obsahuje oprávnění MONITORING s autorizací pro úpravy. Zrušit lze pouze spuštěné, pozastavenévydané dotazy a dotazy ve frontě.
Hotovo
Dotaz byl úspěšně dokončen.
Poznámka:
Ačkoli samotný dotaz byl dokončen bez chyby, aplikace může obdržet chybu, bylo-li dokončení způsobeno externí událostí, například vynuceným ukončením aplikací DB2.

Vytvoření tabulek Explain před spuštěním generátoru historických dat produktu Query Patroller

Pokud při spuštění generátoru historických dat produktu Query Patroller dosud neexistují tabulky Explain, budou generátorem vytvořeny. Důrazně se však doporučuje vytvořit tabulky Explain ještě před spuštěním generátoru historických dat. Při vytváření tabulek Explain zkontrolujte, že je vytváříte ve stejné oblasti. Aktivní vytvoření tabulek Explain ve stejné oblasti vede ke zlepšení výkonu prostředku Vysvětlení. Toto zlepšení zvyšuje výkon generátoru historických dat.

Kontrola souborů žurnálu produktu Query Patroller pro analýzu historie

Pokud sloupec Explain Run (vysvětlit spuštění) v sestavě Aktivita dotazu v průběhu času (Analýza historie) obsahuje stav dotazu Ran unsuccessfully (Spuštěno neúspěšně), nebyla pro dotaz generována data historie. Proto se dotaz nezobrazí v žádné sestavě ani grafu analýzy historie. Jak je dokumentováno ve verzi 8, chcete-li určit příčinu neúspěšnosti dotazu, můžete prozkoumat soubor qpuser.log.

Kromě souboru qpuser.log byste měli prozkoumat také soubor qpdiag.log.

Nestandardní ukončení generátoru historických dat

Pokud spustíte generátor historických dat a ukončíte jej nestandardním způsobem, dojde při příštím pokusu o jeho spuštění k chybě. Mezi nestandardní ukončení patří:

Po nestandardním ukončení generátoru historických dat musíte před dalším pokusem o jeho spuštění zadat následující příkaz:

    qp -d databáze generate historical_data stop

,kde databáze určuje databázi, na níž je příkaz spuštěn.

Dynamická aktualizace třídy dotazů

Určité operace třídy dotazů již nevyžadují ukončení a restartování produktu Query Patroller, aby vstoupily v platnost.

V následující tabulce je aktivním dotazem dotaz, jehož stav je Spuštěno nebo Ve frontě.

Tabulka 38. Podmínky, za nichž změny třídy dotazů vstoupí v platnost
Typ změny Podmínky, za nichž změny vstoupí v platnost
Přidání, odebrání nebo aktualizace třídy dotazů. Pokud neexistují žádné aktivní dotazy, jsou změny uplatněny okamžitě.
Aktualizace třídy dotazů, která zahrnuje pouze změnu hodnoty Maximální počet dotazů. Je uplatněna okamžitě, i v případě, že existují aktivní dotazy.
Aktualizace třídy dotazů, která zahrnuje pouze změnu hodnoty Maximální náklady na dotaz. Pokud existují aktivní dotazy, aktualizace vstoupí v platnost, jakmile je splněna některá z následujících podmínek:
  • Produkt Query Patroller je ukončen a restartován.
  • Neexistují žádné další aktivní dotazy.
Poznámka:
Pokud existuje nevyřízená změna hodnoty Maximální náklady na dotaz, nebudou uplatněny žádné následné změny třídy dotazů libovolného typu, dokud nebude splněna jedna z výše uvedených podmínek.
Přidání nebo odebrání třídy dotazů. Pokud existují aktivní dotazy, přidání nebo odebrání vstoupí v platnost, jakmile je splněna některá z následujících podmínek:
  • Produkt Query Patroller je ukončen a restartován.
  • Neexistují žádné další aktivní dotazy.

Chování vnořeného dotazu

Vnořené dotazy nemohou být zařazeny do fronty. Namísto toho bude vnořený dotaz spuštěn okamžitě, jakmile překročí práh, který by normálně způsobil zařazení dotazu do fronty.

Omezení typem příkazu SQL

Oproti předchozí dokumentací lze zařadit do fronty dotazy s následujícími příkazy:

Omezení rozlišení při použití klienta Terminal Services Client

Používáte-li klienta Terminal Services Client s rozlišením 640x480 pro připojení ke vzdálené pracovní ploše, která je spuštěna v Centru Query Patroller, může se okno Předvolby odeslání zobrazovat prázdné. Chcete-li okno Předvolby odeslání zobrazit správně, musíte použít vyšší rozlišení než 640x480.

Podpora nové skupiny pro odeslání dotazu

Od verze 8.2 podporuje produkt DB2 Universal Database (UDB) kromě skupin operačního systému také skupiny uživatelů. Proto nastala malá změna v rozbalovacím seznamu Použitý profil zadavatele v okně Předvolby odeslání dotazu v Centru Query Patroller.

Jste-li přihlášeni, ale nemáte oprávnění DBADM nebo oprávnění Upravit pro správu uživatelů produktu Query Patroller, můžete přidávat a aktualizovat předvolbu odesílání pouze pro sebe. V takovém případě bude rozbalovací seznam Použitý profil zadavatele obsahovat namísto pouhých skupin operačního systému, do kterých patříte, také existující profily zadavatele pro skupiny DB2 UDB, do kterých patříte.

Jste-li přihlášeni, ale máte buď oprávnění DBADM, nebo oprávnění Upravit pro správu uživatelů produktu Query Patroller, můžete přidávat a aktualizovat předvolby odesílání pro ostatní uživatele. V takovém případě bude rozbalovací seznam Použitý profil zadavatele obsahovat profily zadavatele pro všechny existující skupiny.

Omezení časového plánu produktu Query Patroller

Pracujete-li v Centru Query Patroller s časovými plány, můžete používat okno Časový plán pro ukládání plánů do souboru a jejich pozdější import. Vlastníte-li časový plán uložený pomocí opravy FixPak 6 nebo dřívější, nelze jej importovat pomocí verze 8.2 nebo vyšší. Toto omezení platí kvůli změně serializace mezi úrovněmi sad JDK uvedenými produktem DB2 UDB verze 8.2.

Pro použití příkazu RUN IN BACKGROUND QUERY je vyžadována autorizace

Chcete-li spustit příkaz RUN IN BACKGROUND, musíte být zadavatelem, který původně dotaz odeslal.

Vytvoření aliasu pro výslednou tabulku

Od verze produktu Query Patroller verze 8.1 oprava FixPak 5 produkt Query Patroller již nevytváří výsledné tabulky ve schématu, které odpovídá autorizačnímu ID zadatavele dotazu. Produkt Query Patroller namísto toho vytváří výsledné tabulky v běžném schématu DB2QPRT. Aby bylo možné se na výsledné tabulky odkazovat pomocí schématu zadavatele, produkt Query Patroller verze 8.2 zavádí volbu pro automatické vytváření aliasu pro každou novou výslednou tabulku, kterou produkt Query Patroller vytvoří. Výsledná tabulka bude vytvořena ve schématu DB2QPRT a alias bude vytvořen ve schématu odpovídajícím autorizačnímu ID zadavatele.

Chcete-li tuto volbu zapnout nebo vypnout, zadejte příkaz UPDATE QP_SYSTEM s volbou CREATE_RESULT_TABLE_ALIASES:

Číst syntaktický diagramVynechat zobrazení syntaktického diagramu>>-UPDATE QP_SYSTEM USING--------------------------------------->
 
>--+-DEFAULT------------------------------+--------------------><
   '-CREATE_RESULT_TABLE_ALIASES--+-'Y'-+-'
                                  '-'N'-'
 

Odstranění osiřelých aliasů výsledných tabulek

Aliasy vytvořené pomocí volby CREATE_RESULT_TABLE_ALIASES budou při zrušení tabulky automaticky zrušeny. Existují ovšem dvě situace, kdy bude výsledná tabulka zrušena, aniž by byl zrušen odpovídající alias.

Pro vyčištění aliasů, které nemají odpovídající výsledné tabulky, byl vytvořen nový příkaz REMOVE RESULT_TABLE_ALIASES. Tento příkaz je automaticky proveden, kdykoli jsou výsledné tabulky vymazány v rámci naplánovaného procesu úklidu produktu Query Patroller. Příkaz REMOVE RESULT_TABLE_ALIASES získá seznam aliasů k vymazání pomocí následujícího dotazu:

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)
Předpoklady

Musíte mít oprávnění DBADM.

Postup

  1. Zadání příkazu REMOVE RESULT_TABLE_ALIASES

Tento příkaz odstraní všechny existující aliasy, jejichž výsledné tabulky byly zrušeny. Aliasy byly původně vytvořeny produktem Query Patroller pro výsledné tabulky.

Syntaxe příkazu

Číst syntaktický diagramVynechat zobrazení syntaktického diagramu>>-REMOVE RESULT_TABLE_ALIASES---------------------------------><
 

Poznámka:
Informace o zadávání příkazů produktu Query Patroller pomocí rozhraní příkazového řádku a informace o obecné syntaxi příkazů produktu Query Patroller naleznete v rozhraní příkazového řádku produktu Query Patroller.

Jméno chráněného uživatele vyžaduje soubor qpdiag.log s právem zápisu a cestu

Modul Query Patroller používá některé chráněné uložené procedury, které mohou protokolovat položky do souboru qpdiag.log. Proto musí mít jméno chráněného uživatele přístup do souboru qpdiag.log pro psaní a znát cestu, kde je soubor qpdiag.log umístěn.

[ Začátek stránky |Předchozí stránka | Další stránka | Obsah ]