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.
Die Bedeutungen der Abfragestatus Abgebrochen und Fertig werden wie folgt aktualisiert:
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.
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.
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.
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.
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.
Im Gegensatz zu früheren Angaben können Abfragen mit den folgenden Anweisungen in eine Warteschlange eingereiht werden:
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.
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.
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.
Zum Ausführen des Befehls RUN IN BACKGROUND QUERY müssen Sie die Abfrage ursprünglich übergeben haben.
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:
>>-UPDATE QP_SYSTEM USING---------------------------------------> >--+-DEFAULT------------------------------+-------------------->< '-CREATE_RESULT_TABLE_ALIASES--+-'Y'-+-' '-'N'-'
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)
Sie müssen die Berechtigung DBADM haben.
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.
>>-REMOVE RESULT_TABLE_ALIASES---------------------------------><
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 ]