Installationsvoraussetzung für Query Patroller Version 8
Setzen von DYN_QUERY_MGMT zum Installieren und Verwenden von Query Patroller
Zusätzliche Informationen zur Migration von Query Patroller Version 7
Entfernen der Voraussetzungen zum Starten von Query Patroller (AIX)
Verwenden von DB2 Governor mit Query Patroller
Korrektur der Befehlszeilenhilfe von Query Patroller
Query Patroller-Abfragewiederherstellung
Installation des Query Patroller-Servers
Verwenden von Query Patroller mit dem DB2-Verbindungskonzentrator
DBCLOB-Objekte im Dialog 'Ergebnis anzeigen' nicht verfügbar
Notwendigkeit, den Befehl qpsetup für jede Datenbank auszuführen
Beachtung der Groß-/Kleinschreibung bei Profil-IDs von Query Patroller
Kein Bedienerprofil erforderlich für Benutzer mit Berechtigung DBADM
Anwenden von Filtern beim Anzeigen zahlreicher Abfragen
Korrekturen an der Beschreibung des Befehls LIST QUERIES
Korrekturen an den Beschreibungen der Befehle qpstart und qpsetup
Empfehlungen für das Generieren von Protokolldaten
Stoppen des Generators für Protokolldaten
Einleiten eines Ladevorgangs durch im Hintergrund ausgeführte Abfragen
Fehler auf Grund von Speichermangel mit Query Controller oder der Query Patroller-Zentrale
Wenn Sie Query Patroller Version 8 unter DB2 Universal Database Enterprise Server Edition Version 8.1.2 installieren, müssen Sie außerdem FixPak 2+ installiert haben. Das heißt, Sie müssen sowohl DB2 Version 8.1.2 (auch bekannt als FixPak 2) als auch FixPak 2+ installiert haben, bevor Sie Query Patroller installieren.
Wenn Sie eine höhere Version von DB2 Enterprise Server Edition verwenden, ist dieses zusätzliche FixPak nicht erforderlich.
Sowohl DB2 Version 8.1.2 (FixPak 2) als auch FixPak 2+ können von folgender Website für die technische DB2-Unterstützung heruntergeladen werden: http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/download.d2w/report
Wenn Sie versuchen, Query Patroller Version 8 unter DB2 Enterprise Server Edition Version 8.1.2 zu installieren, ohne vorher FixPak 2+ installiert zu haben, werden Sie eine Fehlernachricht empfangen, die besagt, dass Sie nicht über die richtige Version von DB2 Universal Database verfügen, um das Produkt zu installieren.
Damit Query Patroller Abfragen abfangen und verwalten kann, muss der Parameter DYN_QUERY_MGMT auf ENABLE gesetzt werden. Dieser Parameter muss jedoch vor der Installation von Query Patroller auf DISABLE gesetzt werden, um das Abfangen jeglicher interner Abfragen zu verhindern, die vom Installationsprogramm ausgeführt werden.
Dieser Parameter ist standardmäßig auf DISABLE gesetzt.
Bei der Migration eines Administratorprofils von Query Patroller Version 7 auf Query Patroller Version 8 wird ein Bedienerprofil erstellt. Diesem Profil wird automatisch die maximale Berechtigungsstufe für alle Query Patroller-Zugriffsrechte erteilt. Das migrierte Profil erhält jedoch nicht automatisch die Berechtigung DBADM für die Query Patroller-Datenbank. Dies bedeutet, dass das migrierte Administratorprofil keine Zugriffsrechte hat, um Protokolldaten zu generieren oder Bedienerprofile zu erstellen, zu aktualisieren oder zu entfernen. Wenn ein Benutzer mit diesem migrierten Profil solche Tasks durchführen muss, müssen Sie nach der Migration dem Benutzer die Berechtigung DBADM erteilen.
Protokolldaten können nicht für Abfragen generiert werden, die positionierte UPDATE- oder DELETE-Anweisungen enthalten.
In der Query Patroller-Dokumentation werden folgende Voraussetzungen zum Starten von Query Patroller auf AIX-Betriebssystemen genannt:
EXTSHM=ON export EXTSHM
Diese Abhängigkeit wurde entfernt, und die Elemente oben sind nicht mehr Voraussetzung zum Starten von Query Patroller auf AIX-Betriebssystemen.
Die Hauptfunktion von Query Patroller besteht darin, Datenbankadministratoren bei Abfragen einer Datenbank zu unterstützen. Die Hauptfunktion von DB2 Governor besteht darin, Administratoren bei der Verwaltung von Anwendungen zu unterstützen, die für eine Datenbank ausgeführt werden.
Mit DB2 Governor können Sie Begrenzungen für Ressourcen setzen, wie z. B. die Anzahl der Sperren, die Leerlaufzeit sowie die von einer Anwendung verwendete CPU. DB2 governor kann zusammen mit Query Patroller eingesetzt werden, um ein beträchtliches Maß an administrativer Steuerung zu gewährleisten. Damit Sie diese jedoch effektiv zusammen einsetzen können, müssen Sie Kenntnis von deren Interaktion haben.
Query Patroller ist ein System zusammenarbeitender Anwendungen, die für eine Datenbank ausgeführt werden. Da Governor auf diese wie auch auf andere Anwendungen einwirken kann, sind einige Richtlinien beim Angeben von Regeln in der Governor-Konfigurationsdatei zu beachten.
Es ist insbesondere wichtig, das Einbeziehen der von Query Patroller verwendeten Prozesse in die Regeln der Governor-Konfigurationsdatei zu vermeiden. Query Patroller verwendet javaw.exe, java.exe, db2fmp.exe und qp.exe unter Windows sowie Java, db2fmp, und qp unter UNIX, um eigene Operationen durchzuführen. Schließen Sie diese Prozesse nicht in die Governor-Konfigurationsdatei ein, damit Query Patroller nicht von Governor beeinträchtigt wird. Sie müssen auch sicherstellen, dass eine allgemeine Regel nicht alle Anwendungen standardmäßig abfängt. Beziehen Sie stattdessen explizit die Liste von Anwendungen ein, die durch DB2 Governor abgefangen werden sollen.
Wenn die von Query Patroller verwendeten Prozesse nicht vom Abfangen durch DB2 Governor ausgeschlossen werden können, müssen Sie die folgenden Richtlinien beim Erstellen der Regeln Ihrer Governor-Konfigurationsdatei beachten.
Die Einschränkung durch andere Begrenzungen wie die CPU-Belastung und Leerlaufzeit können möglicherweise zu Beeinträchtigungen von Query Patroller-Prozessen durch DB2 Governor führen. Dies hängt von der Zeit und der Anzahl Ressourcen ab, die Query Patroller für die Bearbeitung von Query Patroller-Steuertabellen verwendet. Wie bereits erwähnt, kann dieser Wert nicht vorher festgelegt werden, da er von der Hardwarekonfiguration und der Datengröße abhängig ist. Falls gewünscht, setzen Sie die Begrenzungen auf höhere Werte, damit DB2 Governor nicht Query Patroller beeinträchtigt.
Wenn Prioritäts- oder Zeitplanaktionen auf Query Patroller-Prozesse angewendet werden, wird Query Patroller mit reduzierten Systemressourcen weiterhin ausgeführt. Wenn jedoch eine FORCE-Aktion auf den Query Patroller-Prozess angewendet wird, kann der Prozess beendet werden. Die FORCE-Aktion kann möglicherweise einen Query Patroller-Prozess normal beenden und dabei einen Rückkehrcode SQL1224N zurückgeben oder einen Anwendungsfehler bzw. eine abnormale Beendigung des DARI-Prozesses (SQL1131N) verursachen, wenn der db2fmp-Prozess vor Absetzen der FORCE-Aktion gestartet wurde. Query Patroller kann den db2fmp-Prozess nach dessen Start nicht stoppen. Der db2fmp-Prozess versucht, die Ausführung vollständig abzuschließen, sogar nachdem Query Patroller die Datenbankverbindung beendet hat, die der db2fmp-Prozess für die erfolgreiche Ausführung benötigt.
Weitere Informationen zum db2fmp-Prozess finden Sie im Handbuch Application Development Guide: Programming Client Applications.
Query Patroller und auch DB2 Governor können für dieselben Abfragen übergebenden Anwendungen eingesetzt werden. Eine übergebende Anwendung, wie z. B. der DB2-Befehlszeilenprozessor (db2bp.exe unter Windows und db2bp unter UNIX), kann als eine von Query Patroller abgefangene Anwendung aufgelistet sowie auch in die Governor-Konfigurationsdatei einbezogen werden.
Query Patroller fängt Abfragen bei Übergabezeit ab, während DB2 Governor Anwendungen bei Abfrageausführungszeit abfängt. Da eine Abfrageübergabe vor der Ausführung stattfindet, wird Query Patroller Abfragen immer vor DB2 Governor abfangen. Dies bedeutet, dass, wenn Query Patroller eine Abfrage anhält oder in die Warteschleife stellt, DB2 Governor auf die Ausführung der Abfrage warten muss, bevor die die Abfrage übergebende Anwendung abgefangen wird.
Eine von Query Patroller abgefangene Abfrage kann entweder durch die übergebende Anwendung oder eine andere Anwendung (qprunquery.exe unter Windows und qprunquery unter UNIX) ausgeführt werden. Wenn nach den Übergabevorgaben des übergebenden Benutzers die übergebende Anwendung warten muss, bis die Abfrageergebnisse zurückgegeben werden, bevor die Anwendung freigegeben wird, führt die übergebende Anwendung die Abfrage aus. Wenn die übergebende Anwendung in der Konfigurationsdatei von DB2 Governor aufgelistet ist, fängt DB2 Governor die übergebende Anwendung ab, wenn diese die Abfrage ausführt.
Wenn nach den Übergabevorgaben des übergebenden Benutzers die übergebende Anwendung freigegeben und die Abfrageergebnisse an eine Ergebnistabelle geschickt werden sollen, wird die Abfrage durch qprunquery ausgeführt. In diesem Fall fängt DB2 Governor die Anwendung nur ab, wenn qprunquery in der Konfigurationsdatei von DB2 Governor enthalten ist.
Laut Query Patroller-Dokumentation erhalten Sie durch Eingabe von "gp ?" in die Befehlszeile eine Auflistung der Query Patroller-Befehle. Dies ist nicht korrekt. Um eine Liste mit Query Patroller-Befehlen anzuzeigen, müssen Sie einen Datenbanknamen wie folgt eingeben:
qp -d db-name ?
oder
qp -d db-name help
qp -d db-name -u benutzer-id -p kennwort ?
oder
qp -d db-name -u benutzer-id -p kennwort help
Wenn der Status einer in die Warteschlange eingereihten oder aktiven Abfrage geändert wird, kann Query Patroller in seltenen Fällen nicht in der Lage sein, den neuen Status sofort zu erfassen. Dies passiert normalerweise bei einer wie im Folgenden beschriebenen abnormalen Beendigung:
Der Query Patroller-Server führt beim Systemstart und in regelmäßigen Abständen eine automatische Wiederherstellung aus. Er prüft auf Abfragen mit dem aktuellen Status 'In die Warteschlange eingereiht' oder 'Aktiv' und ob der Status immer noch zutrifft. Wenn der aktuelle Status immer noch zutrifft, wird die Abfrage normal bearbeitet. Wenn der Query Patroller-Server beendet und neu gestartet wurde, wird die interne Datenstruktur des Query Patroller-Servers wiederhergestellt. Wenn jedoch festgestellt wurde, dass eine Abfrage mit dem Status 'In Warteschlange eingereiht' oder 'Aktiv' nicht mehr in DB2 vorhanden ist, weil der DB2-Server beendet und neu gestartet wurde oder Query Patroller inaktiv war und den Status der Abfrage nicht aktualisieren konnte, erfolgt eine Wiederherstellung für die Abfrage. Die vorgenommene Wiederherstellungsaktion hängt davon ab, ob die Abfrage die Ergebnisse an eine Clientanwendung oder an eine DB2-Ergebnistabelle zurückgeben sollte.
Beachten Sie bitte bei der Installation des Query Patroller-Servers Folgendes:
Wenn Query Patroller eine Abfrage in die Warteschlange stellt, blockiert diese Abfrage die Anwendung, solange sie sich in der Warteschlange befindet, also bis die Abfrage ausgeführt wird.
Wenn der DB2-Verbindungskonzentrator nicht aktiviert ist, enthält jede Anwendung ihren eigenen Agenten, der die Datenbankverbindung verwaltet, bis die Anwendung die Verbindung unterbricht. Wenn der Konzentrator aktiviert ist, benutzen alle Anwendungen einen Pool von Agenten gemeinsam, die zwischen Anwendungen bei Transaktionsabschluss getauscht werden. Wenn der Konzentrator aktiviert ist und Query Patroller Abfragen in die Warteschlange stellt, belegt Query Patroller diese Agenten also, bis die Abfragen ausgeführt werden. Dies würde den Pool mit verfügbaren Agenten verkleinern und die Leistung von DB2 beeinflussen, da Anwendungen auf Grund ihrer Unfähigkeit, die Services eines Agenten zu nutzen, weder eine Verbindung herstellen noch eine Anforderung ausführen könnten. Deshalb stellt Query Patroller bei aktiviertem Verbindungskonzentrator keine Abfragen in die Warteschlange; stattdessen weist Query Patroller standardmäßig Abfragen, die in die Warteschlange gestellt werden sollen, mit dem SQLCODE-Wert 29009 und dem Ursachencode 6 zurück.
Um das Zurückweisen von Abfragen zu verhindern, die andernfalls in die Warteschlange gestellt würden, können Sie auswählen, dass Query Patroller Abfragen trotz aktiviertem Konzentrator ausführt, indem Sie den Parameter BLOCK_OPTION auf Systemebene mit dem Befehl UPDATE QP_SYSTEM oder auf Benutzerebene mit dem Befehl UPDATE SUBMITTER_PROFILE setzen. Standardmäßig ist BLOCK_OPTION auf 'R' ('reject' - zurückweisen) gesetzt, d. h. Abfragen werden bei aktiviertem Konzentrator zurückgewiesen, anstatt in die Warteschlange gestellt zu werden. Um anzugeben, dass Query Patroller Abfragen ausführen soll, anstatt diese bei aktiviertem Konzentrator zurückzuweisen, setzen Sie BLOCK_OPTION auf 'P' ('proceed' - fortsetzen).
Beispiel: Damit Query Patroller Abfragen für die Datenbank "sample" ausführen kann, die andernfalls bei aktiviertem Konzentrator zurückgewiesen werden, setzen Sie die Option BLOCK_OPTION wie folgt auf 'P':
qp -d sample -u benutzer-id -p kennwort "UPDATE QP_SYSTEM USING BLOCK_OPTION 'P'"
Damit Query Patroller mit dem Profil "STEVED" übergebene Abfragen ausführen kann, die andernfalls bei aktiviertem Konzentrator zurückgewiesen werden, setzen Sie BLOCK_OPTION für dieses Profil wie folgt auf 'P':
qp -d sample -u benutzer-id -p kennwort "UPDATE SUBMITTER_PROFILE FOR USER'STEVED' USING BLOCK_OPTION 'P'"
Die Werte für BLOCK_OPTION werden in den Tabellen QP_SYSTEM- und SUBMITTER_PROFILE für die Datenbank gespeichert.
Für die Einstellung BLOCK_OPTION für QP_SYSTEM ist die Dateneingabe nicht optional. Für die Einstellung BLOCK_OPTION für SUBMITTER_PROFILE ist die Dateneingabe optional. Wenn BLOCK_OPTION sowohl für das QP_SYSTEM als auch für das Übergabeprofil eines Benutzers festgelegt wird, hat der Wert des Übergabeprofils eine Vorrangstellung für diesen Benutzer. Für alle anderen Benutzer gilt die Einstellung BLOCK_OPTION für QP_SYSTEM. Um sicherzustellen, dass die Einstellung BLOCK_OPTION für QP_SYSTEM für einen bestimmten Benutzer gilt, setzen Sie die BLOCK_OPTION für SUBMITTER_PROFILE für diesen Benutzer auf NULL.
Aufgrund einer JDBC-Einschränkung können DBCLOB-Objekte im Query Patroller-Dialogfenster Ergebnis anzeigen nicht angezeigt werden. Anstelle von DBCLOB-Objekten wird in diesem Fenster eine leere Zeichenfolge angezeigt. Diese Einschränkung gilt nur für die Query Patroller-Zentrale, nicht für die Query Patroller-Befehlszeile.
Für jede Datenbank, die Sie mit Query Patroller verwenden möchten, müssen Sie den Befehl qpsetup ausführen. Dadurch wird für jede Datenbank eine Reihe von Query Patroller-Steuerungsdatenbankobjekten erzeugt, wie z. B. den Tabellen zugeordnete Steuertabellen, Anzeigen und Auslöser sowie für die Ausführung von Query Patroller erforderliche benutzerdefinierte Funktionen und Prozeduren. Die Steuertabellen enthalten Informationen, wie z. B. Konfigurationseinstellungen, Benutzerprofile und Daten zeitbezogener Abfragen. Weitere Informationen finden Sie in Query Patroller-Handbuch: Installation, Verwaltung und Verwendung oder in den Informationen zu Query Patroller in 'Information - Unterstützung'.
Es ist zu berücksichtigen, dass bei Übergabeprofil- und Bedienerprofil-IDs von Query Patroller die Groß-/Kleinschreibung beachtet werden muss. Diese Profil-IDs müssen auch als DB2-Berechtigungs-IDs vorhanden sein. Dies bedeutet, dass eine vorhandene DB2-Berechtigungs-ID "TESTUSER" bereits vorhanden sein muss, wenn Sie ein Übergabeprofil für einen als "TESTUSER" angegebenen Benutzer erstellen. Wenn Sie ein Übergabeprofil für einen als "testuser" angegebenen Benutzer erstellen, wird dieses Profil nicht der DB2-Berechtigungs-ID "TESTUSER" zugeordnet und nicht von Query Patroller verwendet. Dagegen werden jegliche Abfragen, die mit der ID "TESTUSER" übergeben wurden, dem Standardübergabeprofil PUBLIC zugeordnet.
Für Benutzer mit der Berechtigung BDADM für Datenbanken müssen keine Bedienerprofile erstellt werden. Solche Benutzer verfügen bereits über die höchste Ebene der Bedienerberechtigungen, deshalb ist das Hinzufügen von Bedienerprofilen für sie überflüssig. Es kann auch irreführend sein, ein Bedienerprofil für Benutzer mit der Berechtigung DBADM zu erstellen, da der Benutzer trotz Einschränkungen der dem Profil zugeordneten Bedienerberechtigungen alle Tasks von Query Patroller durchführen kann.
Die Antwortzeit der Query Patroller-Zentrale kann sich erheblich verlangsamen, wenn Sie mehrere Hundert verwaltete oder zeitbezogene Abfragen anzeigen. Zur Abschwächung dieses Problems empfiehlt es sich, einen Filter auf die Sichten anzuwenden, um die Anzahl der angezeigten Abfragen zu verringern. Weitere Informationen zum Anwenden von Filtern in der Query Patroller-Zentrale finden Sie in Query Patroller-Handbuch: Installation, Verwaltung und Verwendung oder in den Informationen zu Query Patroller in 'Information - Unterstützung'.
Die Dokumentation zu Query Patroller Version 8 beschreibt die Parameterwerte für den Parameter WITH STATUS des Befehls LIST QUERIES fehlerhaft. Die Dokumentation gibt an, dass ein Wert von "R" alle zurückgewiesenen Abfragen zurückgibt. Dieser Wert gibt jedoch tatsächlich an, dass eine Liste mit allen aktiven Abfragen zurückgegeben wird.
In der Beschreibung des Standardverhaltens des Befehls LIST QUERIES ist ebenfalls ein Fehler aufgetreten. Die Dokumentation besagt, dass durch das Absetzen des Befehls LIST QUERIES ohne die Angabe von Parametern die letzen 100 Abfragen zurückgegeben werden. Dies ist nicht korrekt. Wird der Befehl LIST QUERIES ohne jegliche Parameter abgesetzt, gibt er eine Liste aller verwalteten Abfragen zurück, die zu dem aktuellen Benutzer gehören. Der Parameter "FOR USER ALL" muss angegeben werden, um alle verwalteten Abfragen anzuzeigen.
Die Dokumentation zu Query Patroller Version 8 besagt, dass ein Benutzer mit der Berechtigung DBADM den Befehl qpstart ausführen kann. Dies ist nicht korrekt. Sie müssen der Eigner des Exemplars sein, das die Datenbank enthält, auf der Sie Query Patroller ausführen wollen, um den Befehl qpstart abzusetzen.
Die Dokumentation besagt außerdem, dass Sie den Befehl qpsetup ausführen können, wenn Sie die Berechtigung DBADM haben. Dies ist nicht korrekt. Sie müssen die Berechtigung SYSADM haben, um den Befehl qpsetup für eine Datenbank auszuführen.
Es wird empfohlen, dass Sie den Generator für Protokolldaten (unter Verwendung des Befehls GENERATE HISTORICAL_DATA) während Zeiten geringer Datenbankauslastung ausführen. Das Ausführen dieses Befehls während Zeiten geringer Systemauslastung minimiert das Risiko von Leistungsproblemen für die Datenbank.
Ferner wird empfohlen, dass Sie den Befehl GENERATE HISTORICAL_DATA regelmäßig ausführen, um die Anzahl Abfragen zu reduzieren, für die Daten gleichzeitig erfasst werden.
Setzen Sie den folgenden Befehl ab, um das Generieren von Protokolldaten zu stoppen, während der Generator für Protokolldaten aktiv ist:
generate historical_data stop
Dadurch wird eine Markierung gesetzt, die nach jeweils 20 Abfragen überprüft wird, während der Generator für Protokolldaten aktiv ist. Wenn diese Markierung gesetzt ist, wird der Generator für Protokolldaten inaktiviert. Die Abfragedaten, die bis zu diesem Punkt generiert wurden, werden beibehalten und nicht regeneriert, wenn der Generator für Protokolldaten das nächste Mal ausgeführt wird. Der Wert, der angibt, wann Protokolldaten zum letzten Mal erfasst wurden (TIME_HIST_GENERATOR_LAST_RUN in der Steuertabelle QP_SYSTEM) wird jedoch nicht aktualisiert.
Wenn eine Abfrage im Hintergrund ausgeführt wird, werden die Ergebnisse der Abfrage in einer Ergebnistabelle gespeichert. Jede Abfrage, die eine Ergebnistabelle generiert, wird von einem Prozess ausgeführt, der als qprunquery bezeichnet wird. Dieser Prozess erstellt eine Ergebnistabelle und leitet das Laden über einen Cursor ein, um die Tabelle mit den Ergebnissen der Abfrage zu füllen. Das bedeutet, dass für Abfragen, die Ergebnistabellen erstellen, die gleichen Einschränkungen gelten wie für jeden anderen Ladevorgang über einen Cursor. Eine vollständige Beschreibung dieser Einschränkungen finden Sie in der Dokumentation des Befehls LOAD in DB2 Command Reference.
Bei jedem Ladevorgang, der von qprunquery ausgeführt wird, werden Einträge in die Datei db2diag.log gestellt. Auf UNIX-Betriebssystemen wird mindestens eine Nachricht in einem Unterverzeichnis des Verzeichnisses INSTANCE/db2dump erstellt, wobei INSTANCE das Verzeichnis ist, in dem Sie DB2 installiert haben. Unter Windows wird mindestens eine Nachricht in einem Unterverzeichnis des Verzeichnisses erstellt, das im Datenbankkonfigurationsparameter diagpath angegeben ist. Der Name des Unterverzeichnisses für die Nachrichtendatei wird basierend auf den Details der Ladeoperation generiert. Der Name eines Unterverzeichnisses einer generierten Nachrichtendatei kann z. B. wie folgt lauten:
qpTbLoad_SAMPLE_349_2003-05-21-16.51.32
Dabei gilt Folgendes:
Der Name der Nachrichtendatei, die in diesem Unterverzeichnis enthalten ist, würde wie folgt lauten:
qpTbLoad_SAMPLE_349_2003-05-21-16.51.32.MSG.*
Die Nachrichtendateien werden gelöscht, sobald der Ladevorgang erfolgreich beendet wurde. Zur Unterstützung der Fehlerbestimmung werden die Nachrichtendateien nicht gelöscht, wenn der Ladevorgang fehl schlägt.
Es gibt eine Begrenzung für die Anzahl simultaner Ladeoperationen, die parallel ausgeführt werden können. Das Überschreiten dieser Begrenzung führt dazu, dass eine Abfrage abgebrochen wird und der Fehler SQL6555 auftritt, der in der Datei qpdiag.log aufgezeichnet wird. Wenn dieser Fehler auftritt, können Sie ihn beheben, indem Sie den Bereich ändern, der von der Registrierdatenbankvariablen DB2ATLD_PORTS angegeben wird, die die zulässige Anzahl paralleler Ladevorgänge festlegt, die gleichzeitig ausgeführt werden können. Zum Berechnen der ungefähren Anzahl Ports, die in Ihrem System erforderlich ist, ermitteln Sie die maximale Anzahl Ladevorgänge fest, die gleichzeitig ausgeführt werden müssen, einschließlich derer, die von qprunquery eingeleitet wurden, und anderer Ladeoperationen. Multiplizieren Sie diesen Wert mit der Anzahl logischer Partitionen pro physischer Partition in Ihrer Umgebung. Fügen Sie diesem Betrag 25 % hinzu.
Setzen Sie den folgenden Befehl ab, um die Registrierdatenbankvariable DB2ATLD_PORTS zu setzen:
db2set DB2ATLD_PORTS=anz1:anz2
Dabei ist anz1<anz2
Query Patroller verwendet einen Standardwert von 6000 Ports im Bereich 50000-56000. Dieser Wert wird durch das Setzen von DB2ATLD_PORTS überschrieben.
Wenn Query Patroller eine große Anzahl Abfragen verwaltet und Query Controller oder die Query Patroller-Zentrale aktiv ist, empfangen Sie möglicherweise einen Fehler auf Grund von Speichermangel, selbst wenn genügend Speicher auf der Maschine verfügbar ist. Sie können die Einstellungen der Umgebungsvariablen für den Java-Zwischenspeicher ausgehend von ihren Standardwertenvergrößern, um mehr verfügbaren Speicher verwenden zu können.
Die zu aktualisierenden Umgebungsvariablen sind QP_INIT_JAVA_HEAP_SIZE und QP_MAX_JAVA_HEAP_SIZE. Wenn diese Variablen nicht gesetzt sind, ist der Standardwert 32 MB bzw. 512 MB.
Möglicherweise bietet IBM die in dieser Dokumentation beschriebenen Produkte, Services oder Funktionen in anderen Ländern nicht an. Informationen über die gegenwärtig im jeweiligen Land verfügbaren Produkte und Services sind beim IBM Ansprechpartner erhältlich. Hinweise auf IBM Lizenzprogramme oder andere IBM Produkte bedeuten nicht, dass nur Programme, Produkte oder Dienstleistungen von IBM verwendet werden können. An Stelle der IBM Produkte, Programme oder Dienstleistungen können auch andere ihnen äquivalente Produkte, Programme oder Dienstleistungen verwendet werden, solange diese keine gewerblichen oder anderen Schutzrechte der IBM verletzen. Die Verantwortung für den Betrieb der Produkte, Programme oder Dienstleistungen in Verbindung mit Fremdprodukten und Fremddienstleistungen liegt beim Kunden, soweit nicht ausdrücklich solche Verbindungen erwähnt sind.
Für in diesem Handbuch beschriebene Erzeugnisse und Verfahren kann es IBM Patente oder Patentanmeldungen geben. Mit der Auslieferung dieses Handbuchs ist keine Lizenzierung dieser Patente verbunden. Lizenzanfragen sind schriftlich an
IBM Europe, Director of Licensing, 92066 Paris La Defense Cedex, France,Trotz sorgfältiger Bearbeitung können technische Ungenauigkeiten oder Druckfehler in dieser Veröffentlichung nicht ausgeschlossen werden. Die Angaben in diesem Handbuch werden in regelmäßigen Zeitabständen aktualisiert. Die Änderungen werden in Überarbeitungen bekanntgegeben. IBM kann jederzeit Verbesserungen und/oder Änderungen an den in dieser Veröffentlichung beschriebenen Produkten und/oder Programmen vornehmen.
Verweise in diesen Informationen auf Websites anderer Anbieter dienen lediglich als Benutzerinformationen und stellen keinerlei Billigung des Inhalts dieser Websites dar. Das über diese Websites verfügbare Material ist nicht Bestandteil des Materials für dieses IBM Produkt. Die Verwendung dieser Websites geschieht auf eigene Verantwortung.
Werden an IBM Informationen eingesandt, können diese beliebig verwendet werden, ohne dass eine Verpflichtung gegenüber dem Einsender entsteht.
Lizenznehmer des Programms, die Informationen zu diesem Produkt wünschen mit der Zielsetzung: (i) den Austausch von Informationen zwischen unabhängigen, erstellten Programmen und anderen Programmen (einschließlich des vorliegenden Programms) sowie (ii) die gemeinsame Nutzung der ausgetauschten Informationen zu ermöglichen, wenden sich an folgende Adresse (Anfragen an diese Adresse müssen auf englisch formuliert werden):
IBM Canada LimitedDie Bereitstellung dieser Informationen kann unter Umständen von bestimmten Bedingungen - in einigen Fällen auch von der Zahlung einer Gebühr - abhängig sein.
Die Lieferung des im Handbuch aufgeführten Lizenzprogramms sowie des zugehörigen Lizenzmaterials erfolgt im Rahmen der Allgemeinen Geschäftsbedingungen der IBM, der Internationalen Nutzungsbedingungen der IBM für Programmpakete oder einer äquivalenten Vereinbarung.
Alle in diesem Dokument enthaltenen Leistungsdaten stammen aus einer gesteuerten Umgebung. Die Ergebnisse, die in anderen Betriebsumgebungen erzielt werden, können daher erheblich von den hier erzielten Ergebnissen abweichen. Einige Daten stammen möglicherweise von Systemen, deren Entwicklung noch nicht abgeschlossen ist. Eine Garantie, dass diese Daten auch in allgemein verfügbaren Systemen erzielt werden, kann nicht gegeben werden. Darüber hinaus wurden einige Daten unter Umständen durch Extrapolation berechnet. Die tatsächlichen Ergebnisse können abweichen. Benutzer dieses Dokuments sollten die entsprechenden Daten in ihrer spezifischen Umgebung prüfen.
Informationen über Produkte anderer Hersteller als IBM wurden von den Herstellern dieser Produkte zur Verfügung gestellt, bzw. aus von ihnen veröffentlichten Ankündigungen oder anderen öffentlich zugänglichen Quellen entnommen. IBM hat diese Produkte nicht getestet und übernimmt im Hinblick auf Produkte anderer Hersteller keine Verantwortung für einwandfreie Funktion, Kompatibilität oder andere Ansprüche. Fragen zu den Leistungsmerkmalen von Produkten anderer Anbieter sind an den jeweiligen Anbieter zu richten.
Aussagen über Pläne und Absichten der IBM unterliegen Änderungen oder können zurückgenommen werden und repräsentieren nur die Ziele der IBM.
Diese Veröffentlichung enthält Beispiele für Daten und Berichte des alltäglichen Geschäftsablaufes. Sie sollen nur die Funktionen des Lizenzprogrammes illustrieren; sie können Namen von Personen, Firmen, Marken oder Produkten enthalten. Alle diese Namen sind frei erfunden, Ähnlichkeiten mit tatsächlichen Namen und Adressen sind rein zufällig.
COPYRIGHTLIZENZ:
Diese Veröffentlichung enthält Beispielanwendungsprogramme, die in Quellensprache geschrieben sind. Sie dürfen diese Beispielprogramme kostenlos kopieren, ändern und verteilen, wenn dies zu dem Zweck geschieht, Anwendungsprogramme zu entwickeln, verwenden, vermarkten oder zu verteilen, die mit der Anwendungsprogrammierschnittstelle konform sind, für die diese Beispielprogramme geschrieben werden. Die in diesem Handbuch aufgeführten Beispiele sollen lediglich der Veranschaulichung und zu keinem anderen Zweck dienen. Diese Beispiele wurden nicht unter allen denkbaren Bedingungen getestet.
Kopien oder Teile der Beispielprogramme bzw. daraus abgeleiteter Code müssen folgenden Copyrightvermerk beinhalten:
(C) (Name Ihrer Firma) (Jahr). Teile des vorliegenden Codes wurden aus Beispielprogrammen der IBM Corp. abgeleitet. (C) Copyright IBM Corp. _Jahr/Jahre angeben_. Alle Rechte vorbehalten.
Folgende Namen sind in gewissen Ländern Marken der International Business
Machines Corporation und wurden in mindestens einem der Dokumente in der DB2
UDB-Dokumentationsbibliothek verwendet:
|
ACF/VTAM AISPO AIX AIXwindows AnyNet APPN IBM System AS/400 BookManager C Set++ C/370 CICS Database 2 DataHub DataJoiner DataPropagator DataRefresher DB2 DB2 Connect DB2 Extenders DB2 OLAP Server DB2 Query Patroller DB2 Universal Database Distributed Relational Database Architecture DRDA eServer Extended Services FFST First Failure Support Technology IBM IMS IMS/ESA iSeries |
LAN Distance MVS MVS/ESA MVS/XA Net.Data NetView OS/390 OS/400 PowerPC pSeries QBIC QMF RACF RS/6000 S/370 SP SQL/400 SQL/DS IBM System /370 IBM System /390 SystemView Tivoli VisualAge VM/ESA VSE/ESA VTAM WebExplorer WebSphere WIN-OS/2 z/OS zSeries |
Folgende Namen sind in gewissen Ländern Marken oder eingetragene Marken anderer Unternehmen und wurden in mindestens einem der Dokumente in der DB2 UDB-Dokumentationsbibliothek verwendet.
Microsoft, Windows, Windows NT und das Windows-Logo sind in gewissen Ländern Marken der Microsoft Corporation.
Intel und Pentium sind in gewissen Ländern Marken der Intel Corporation.
Java und alle auf Java basierenden Marken sind in gewissen Ländern Marken von Sun Microsystems, Inc.
UNIX ist in gewissen Ländern eine eingetragene Marke von The Open Group.
Andere Namen von Unternehmen, Produkten oder Dienstleistungen können Marken anderer Unternehmen sein.