Query Patroller

Aktualisierung für das Verhalten von Abfrageklassen

Wenn eine der folgenden Tasks über die Query Patroller-Zentrale oder die Query Patroller-Befehlszeile ausgeführt wird, wird eine Warnung zurückgegeben:

Die Warnung lautet wie folgt:

DQP1024W  Das Erstellen, Ändern oder Entfernen einer
Abfrageklasse wird erst wirksam, wenn der Query
Patroller-Server erneut gestartet wird.

Im DB2 Query Patroller(TM)-Handbuch: Installation, Verwaltung und Verwendung der Version 8.2 wird beschrieben, dass Sie den Query Patroller-Server nach dem Erstellen, Ändern oder Entfernen von Abfrageklassen erneut starten müssen, damit Ihre Änderungen wirksam werden.

Die Nachricht und die Aussage im Handbuch treffen nicht mehr zu. Die drei zuvor aufgelisteten Tasks für Abfrageklassen werden sofort ausgeführt, es sei denn, es sind Abfragen vorhanden, die sich in der Warteschlange befinden oder gerade ausgeführt werden. Wenn dies der Fall ist (auch unter Berücksichtigung neu übergebener Abfragen), werden die an den Abfrageklassen vorgenommenen Änderungen wirksam, sobald die Abfragen, die sich in der Warteschlange befinden oder gerade ausgeführt werden, abgeschlossen sind. Wenn Sie nicht warten wollen, bis alle Abfragen, die sich in der Warteschlange befinden bzw. gerade ausgeführt werden, abgeschlossen sind, müssen Sie den Query Patroller-Server erneut starten.

Anmerkung:
Wie auch bei anderen Query Patroller-Versionen wird die Aktualisierung der maximalen Anzahl Abfragen für eine Abfrageklasse immer sofort ausgeführt.

Definitionsaktualisierungen für den Status verwalteter Abfragen

Die Bedeutungen der Abfragestatus Abgebrochen und Fertig werden wie folgt aktualisiert:

Abgebrochen
Die Abfrage wurde durch den Administrator, den übergebenden Benutzer oder einen Bediener, dessen Profil das Zugriffsrecht MONITORING mit Editierberechtigung aufweist, über die Query Patroller-Zentrale oder über die Query Patroller-Befehlszeile abgebrochen. Nur aktive, angehaltene, freigegebene und in der Warteschlange stehende Abfragen können abgebrochen werden.
Fertig
Die Abfrage wurde erfolgreich beendet.
Anmerkung:
Obwohl die Abfrage selbst ohne Fehler beendet wurde, empfängt die Anwendung möglicherweise einen Fehler, wenn die Beendigung von einem externen Ereignis verursacht wurde, z. B. von einer DB2 force-Anwendung.

Erstellen von EXPLAIN-Tabellen vor der Ausführung des Query Patroller-Generators für Protokolldaten

Wenn Sie den Generator für Protokolldaten für Query Patroller ausführen, falls die EXPLAIN-Tabellen nicht bereits vorhanden sind, wird der Generator diese für Sie erstellen. Es ist jedoch sehr empfehlenswert, dass Sie die EXPLAIN-Tabellen vor der Ausführung des Generators für Protokolldaten erstellen. Wenn Sie die EXPLAIN-Tabellen erstellen, stellen Sie sicher, dass Sie diese auf derselben Partition erstellen. Das aktive Erstellen der EXPLAIN-Tabellen auf derselben Partition verbessert die Leistung des EXPLAIN-Tools. Diese Verbesserung erhöht die Leistung des Generators für Protokolldaten.

Überprüfen der Query Patroller-Protokolldateien für die Protokollanalyse

Wenn in der Spalte Ausführung mit EXPLAIN bearbeiten des Berichts Abfrageaktivität im Laufe der Zeit (Protokollanalysen) ein Status Nicht erfolgreich ausgeführt für eine Abfrage angezeigt wird, wurden keine Protokolldaten für diese Abfrage generiert. Daher wird die Abfrage in keinen Protokollanalyseberichten oder -diagrammen angezeigt. Wie in Version 8 dokumentiert, können Sie die Datei qpuser.log überprüfen, um festzustellen, warum die Abfrage nicht erfolgreich war.

Sie sollten nicht nur die Datei qpuser.log, sondern auch die Datei qpdiag.log überprüfen.

Abnormale Beendigung des Generators für Protokolldaten

Wenn der Generator für Protokolldaten ausgeführt und abnormal beendet wird, wird beim nächsten Versuch, den Generator auszuführen, ein Fehler ausgegeben. Beispiele für eine abnormale Beendigung:

Wenn der Generator für Protokolldaten abnormal beendet wird, müssen Sie vor der erneuten Ausführung des Generators den folgenden Befehl absetzen:

    qp -d datenbank generate historical_data stop

Dabei gibt datenbank die Datenbank an, für die der Befehl ausgeführt wird.

Dynamische Aktualisierung von Abfrageklassen

Einige Operationen für Abfrageklassen können ab sofort ausgeführt werden, ohne dass Query Patroller gestoppt und erneut gestartet werden muss.

In der folgenden Tabelle ist eine aktive Abfrage eine Abfrage, die sich in einem aktiven Status oder in einer Warteschlange befindet.

Tabelle 38. Bedingungen für die erfolgreiche Durchführung von Abfrageklassenänderungen
Art der Änderung Bedingungen für die erfolgreiche Änderung
Hinzufügen, Entfernen oder Aktualisieren einer Abfrageklasse Wenn keine aktiven Abfragen vorhanden sind, werden die Änderungen umgehend durchgeführt.
Aktualisieren einer Abfrageklasse mit nur einer Änderung an Max. Anzahl Abfragen Die Änderung wird umgehend durchgeführt, auch wenn aktive Abfragen vorhanden sind.
Aktualisieren einer Abfrageklasse mit nur einer Änderung an Max. Aufwand einer Abfrage Wenn aktive Abfragen vorhanden sind, wird die Aktualisierung in den folgenden Fällen durchgeführt:
  • Query Patroller wird gestoppt und erneut gestartet.
  • Es sind keine aktiven Abfragen mehr vorhanden.
Anmerkung:
Wenn eine Änderung bezüglich des maximalen Aufwands einer Abfrage ansteht, werden nachfolgende Aktualisierungen von Abfrageklassen erst dann wirksam, wenn eine der obigen Bedingungen erfüllt ist.
Hinzufügen oder Entfernen einer Abfrageklasse Wenn aktive Abfragen vorhanden sind, kann eine Abfrageklasse in den folgenden Fällen hinzugefügt oder entfernt werden:
  • Query Patroller wird gestoppt und erneut gestartet.
  • Es sind keine aktiven Abfragen mehr vorhanden.

Verhalten verschachtelter Abfragen

Verschachtelte Abfragen können nicht in eine Warteschlange eingereiht werden. Stattdessen wird die verschachtelte Abfrage bei Überschreitung eines Schwellenwerts, der normalerweise die Einreihung in eine Warteschlange zur Folge hätte, umgehend ausgeführt.

Einschränkungen nach SQL-Anweisungstyp

Im Gegensatz zu früheren Angaben können Abfragen mit den folgenden Anweisungen in eine Warteschlange eingereiht werden:

Einschränkungen der Auflösung bei der Verwendung von Terminal Services Client

Wenn Sie Terminal Services Client mit einer Auflösung von 640x480 verwenden, um eine Verbindung zu einem fernen Desktop herzustellen, auf dem die Query Patroller-Zentrale aktiv ist, wird das Fenster Übergabevorgaben möglicherweise leer angezeigt. Sie müssen eine höhere Auflösung als 640x480 verwenden, damit das Fenster Übergabevorgaben richtig angezeigt wird.

Neue Unterstützung von Gruppen für Abfrageübergaben

Ab Version 8.2 unterstützt DB2 Universal Database (UDB) auch andere Benutzergruppen als Betriebssystemgruppen. Daher gibt es eine leichte Änderung in der Dropdown-Liste Zu verwendendes Übergabeprofil im Fenster Vorgaben für die Abfrageübergabe der Query Patroller-Zentrale.

Wenn Sie angemeldet sind, aber weder die Berechtigung DBADM noch das Zugriffsrecht zum Editieren für die Query Patroller-Benutzerverwaltung haben, können Sie nur eine Übergabeeinstellung für sich selbst hinzufügen oder aktualisieren. In diesem Fall enthält die Dropdown-Liste Zu verwendendes Übergabeprofil die vorhandenen Übergabeprofile der DB2 UDB-Gruppen, zu denen Sie gehören, und nicht nur die Betriebssystemgruppen, zu denen Sie gehören.

Wenn Sie angemeldet sind und entweder die Berechtigung DBADM oder das Zugriffsrecht zum Editieren für die Query Patroller-Benutzerverwaltung haben, können Sie Übergabeeinstellungen für andere Benutzer hinzufügen oder aktualisieren. In diesem Fall enthält die Dropdown-Liste Zu verwendendes Übergabeprofil alle vorhandenen Gruppenübergabeprofile.

Query Patroller-Zeitplaneinschränkungen

Beim Arbeiten mit Zeitplänen in der Query Patroller-Zentrale können Sie das Zeitplanfenster verwenden, um Zeitpläne in einer Datei zu speichern und später zu importieren. Wenn Sie einen Zeitplan haben, den Sie mit FixPak 6 oder einer früheren Version gespeichert haben, können Sie den Zeitplan nicht mit Version 8.2 oder einer späteren Version importieren. Der Grund für diese Einschränkung ist die Änderung der Serialisierung zwischen den JDK-Stufen, die mit DB2 UDB Version 8.2 eingeführt wurde.

Berechtigung zum Verwenden des Befehls RUN IN BACKGROUND QUERY erforderlich

Zum Ausführen des Befehls RUN IN BACKGROUND QUERY müssen Sie die Abfrage ursprünglich übergeben haben.

Erstellen eines Aliasnamens für eine Ergebnistabelle

Seit Query Patroller Version 8.1 FixPak 5 erstellt Query Patroller keine Ergebnistabellen mehr in dem Schema, das mit der Berechtigungs-ID des übergebenden Benutzers der Abfrage übereinstimmt. Stattdessen erstellt Query Patroller seitdem Ergebnistabellen in einem allgemeinen Schema DB2QPRT. Mit Query Patroller Version 8.2 wird eine Option eingeführt, mit der automatisch ein Aliasname für jede neue Ergebnistabelle erstellt wird, die Query Patroller erstellt, um Verweise auf die Ergebnistabellen mit dem Schema des übergebenden Benutzers zu ermöglichen. Die Ergebnistabelle wird im Schema DB2QPRT erstellt, und der Aliasname wird in einem Schema erstellt, das mit der Berechtigungs-ID des übergebenden Benutzers übereinstimmt.

Setzen Sie zum Aktivieren oder Inaktivieren dieser Option den Befehl UPDATE QP_SYSTEM mit der Option CREATE_RESULT_TABLE_ALIASES ab:

Syntaxdiagramm lesenSyntaxdiagramm berspringen>>-UPDATE QP_SYSTEM USING--------------------------------------->
 
>--+-DEFAULT------------------------------+--------------------><
   '-CREATE_RESULT_TABLE_ALIASES--+-'Y'-+-'
                                  '-'N'-'
 

Entfernen von nicht mehr benötigten Aliasnamen für Ergebnistabellen

Aliasnamen, die mit der Option CREATE_RESULT_TABLE_ALIASES erstellt werden, werden automatisch gelöscht, wenn eine Ergebnistabelle gelöscht wird. Es gibt jedoch zwei Situationen, in denen eine Ergebnistabelle gelöscht werden kann, ohne dass der entsprechende Aliasname gelöscht wird.

Zum Bereinigen von Aliasnamen ohne zugehörige Ergebnistabellen wurde ein neuer Befehl, REMOVE RESULT_TABLE_ALIASES, erstellt. Dieser Befehl wird automatisch ausgeführt, wenn die Ergebnistabellen während des terminierten Query Patroller-Prozesses zum Löschen von Ergebnistabellen gelöscht werden. Der Befehl REMOVE RESULT_TABLE_ALIASES erhält die Liste der Aliasnamen, die gelöscht werden sollen, mit der folgenden Abfrage:

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)
Voraussetzungen

Sie müssen die Berechtigung DBADM haben.

Vorgehensweise

  1. Setzen Sie den Befehl REMOVE RESULT_TABLE_ALIASES ab.

Dieser Befehl entfernt alle Aliasnamen, die noch vorhanden sind, nachdem ihre zugehörigen Ergebnistabellen gelöscht wurden. Die Aliasnamen wurden ursprünglich von Query Patroller für Ergebnistabellen erstellt.

Befehlssyntax

Syntaxdiagramm lesenSyntaxdiagramm berspringen>>-REMOVE RESULT_TABLE_ALIASES---------------------------------><
 

Anmerkung:
Informationen zur Eingabe von Query Patroller-Befehlen mit der Befehlszeilenschnittstelle und zur allgemeinen Syntax für Query Patroller-Befehle finden Sie in der Query Patroller-Befehlszeilenschnittstelle.

Abgeschirmte Benutzer-ID erfordert den Schreibzugriff auf die Datei 'qpdiag.log' und auf deren Pfad

Query Patroller verwendet mehrere abgeschirmte gespeicherte Prozeduren, die zu Protokolleinträgen in der Datei qpdiag.log führen können. Daher muss die abgeschirmte Benutzer-ID Schreibzugriff auf die Datei qpdiag.log und auf den Pfad haben, in der sich diese Datei befindet.

[ Seitenanfang |Vorherige Seite | Nächste Seite | Inhaltsverzeichnis ]