Durch die Änderung des Formats der Behälternamen haben sich ebenfalls die Tabellenbereichs-ID und die Behälter-ID geändert. Das neue Format lautet wie folgt:
<speicherpfad>/<exemplar>/NODE#### /T####### /C#######. <EXT>
Dabei gilt Folgendes:
Ab DB2(R) Universal Database Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) können generierte Spalten in eindeutigen Indizes verwendet werden.
Generierte Spalten können in Integritätsbedingungen, referenziellen Integritätsbedingungen, Primärschlüsseln und globalen temporären Tabellen nicht verwendet werden. Eine Tabelle, die mit LIKE und gespeicherten Sichten erstellt wurde, übernimmt Merkmale generierter Spalten nicht.
Wenn Sie DB2WORKLOAD=SAP gesetzt haben, werden der Benutzertabellenbereich SYSTOOLSPACE und der temporäre Benutzertabellenbereich SYSTOOLSTEMPSPACE nicht automatisch erstellt.
Diese Tabellenbereiche werden für Tabellen verwendet, die automatisch von den folgenden Assistenten, Dienstprogrammen oder Funktionen erstellt wurden:
Ohne die Tabellenbereiche SYSTOOLSPACE und SYSTOOLSTEMPSPACE können Sie diese Assistenten, Dienstprogramme und Funktionen nicht verwenden.
Damit Sie diese Assistenten, Dienstprogramme oder Funktionen verwenden können, müssen Sie eine der folgenden Aktionen ausführen:
CREATE REGULAR TABLESPACE SYSTOOLSPACE IN IBMCATGROUP MANAGED BY SYSTEM USING ('SYSTOOLSPACE')
Erstellen Sie nach der Ausführung mindestens einer dieser Aktionen einen temporären Benutzertabellenbereich (bei Verwendung von DPF ebenfalls nur auf dem Katalogknoten). Beispiel:
CREATE USER TEMPORARY TABLESPACE SYSTOOLSTMPSPACE IN IBMCATGROUP MANAGED BY SYSTEM USING ('SYSTOOLSTMPSPACE')
Sobald der Tabellenbereich SYSTOOLSPACE und der temporäre Tabellenbereich SYSTOOLSTEMPSPACE erstellt wurden, können Sie die bereits erwähnten Assistenten, Dienstprogramme oder Funktionen verwenden.
Mit dem Authentifizierungstyp DATA_ENCRYPT_CMP können Clients von einem Vorgängerrelease, die keine Datenverschlüsselung unterstützen, eine Verbindung zu einem Server mit Hilfe der Authentifizierung SERVER_ENCRYPT an Stelle von DATA_ENCRYPT herstellen. Diese Authentifizierung funktioniert nicht, wenn Folgendes gilt:
In diesem Fall kann der Client keine Verbindung zum Server herstellen. Damit die Verbindung hergestellt werden kann, müssen Sie entweder für den Client einen Upgrade auf Version 8 ausführen, oder das Gateway darf höchstens die Version 8 FixPak 6 aufweisen.
DIO (Direct I/O, direkte Ein-/Ausgabe) verbessert die Leistung des Hauptspeichers, da das Caching auf Dateisystemebene umgangen wird. Dieser Vorgang reduziert den CPU-Aufwand und stellt dem Datenbankexemplar mehr Hauptspeicher zur Verfügung.
CIO (Concurrent I/O, gleichzeitige Ein-/Ausgabe) schließt die Vorteile von DIO ein und entlastet darüber hinaus die serielle Verarbeitung von Schreibzugriffen. DB2 Universal Database (UDB) unterstützt DIO und CIO unter AIX sowie DIO unter HP-UX, Linux, Windows und der Solaris-Betriebsumgebung.
Die Schlüsselwörter NO FILE SYSTEM CACHING und FILE SYSTEM CACHING sind Teil der SQL-Anweisungen CREATE und ALTER TABLESPACE, mit denen Sie angeben können, ob DIO oder CIO für die einzelnen Tabellenbereiche verwendet werden soll. Wenn NO FILE SYSTEM CACHING in Kraft tritt, versucht DB2 UDB wo immer es möglich ist, CIO zu verwenden. In Fällen, in denen CIO nicht unterstützt wird (z. B. wenn JFS verwendet wird), wird stattdessen DIO verwendet.
Weitere Informationen finden Sie im Artikel "Improve database performance on file system containers in IBM DB2 UDB Stinger using Concurrent I/O on AIX" unter der folgenden URL-Adresse:
http://www.ibm.com/developerworks/db2/library/techarticle/dm-0408lee/
Die folgenden Informationen sind Teil des Handbuchs Systemverwaltung: Implementierung, Anhang B ("Verwenden der automatischen Clientweiterleitung"):
Die automatische Clientweiterleitung in DB2 Universal Database für Linux, UNIX und Windows ermöglicht die Wiederherstellung von Clientanwendungen, nachdem die Verbindung zum Server unterbrochen wurde. Dazu wird die Datenbankverbindung vom Client zum Server automatisch wiederhergestellt, so dass die Anwendung mit einer minimalen Unterbrechung fortgesetzt werden kann.
Wenn das Herstellen einer Verbindung vom Client zum Server fehlschlägt, werden die Anforderungen des Clients für erneutes Herstellen der Verbindung an eine definierte Gruppe von Systemen verteilt. Dazu wird eine Verteilungs- oder Zuteilerroutine verwendet, wie z. B. WebSphere EdgeServer.
Sie können die Distributortechnologie in einer Umgebung verwenden, die der folgenden Umgebung ähnlich ist:
Client --> Distributor Technology --> (DB2 Connect-Server 1 oder DB2 Connect-Server 2) --> DB2 z/OS
Dabei gilt Folgendes:
Der Client wird unter Verwendung von DThostname katalogisiert, damit die Verteilungstechnologie zum Zugriff auf einen der DB2 Connect-Server ver- wendet wird. Die verarbeitende Distributortechnologie entscheidet darüber, ob GWYhostname1 oder GWYhostname2 verwendet wird. Nachdem die Entscheidung gefällt worden ist, verfügt der Client über eine direkte Socketverbindung zu einem dieser zwei DB2 Connect-Gateways. Sobald die Socketverbindung zum ausgewählten DB2 Connect-Server hergestellt worden ist, verfügen Sie über eine typische Konnektivität zwischen Client, DB2 Connect-Server und DB2 z/OS.
Gehen Sie z. B. davon aus, dass der Verteiler GWYhostname2 auswählt. Dadurch ergibt sich die folgende Umgebung:
Client --> DB2 Connect-Server 2 --> DB2 z/OS
Wenn ein Kommunikationsfehler aufgetreten ist, versucht der Verteiler nicht, die Verbindungen wiederherzustellen. Wenn Sie die Funktion zur automatischen Clientweiterleitung für eine Datenbank in einer solchen Umgebung aktivieren möchten, müssen Sie den alternativen Server für die zugeordnete Datenbank bzw. die zugeordneten Datenbanken auf dem DB2 Connect-Server (DB2 Connect-Server 1 oder DB2 Connect-Server 2) als Verteiler (DThostname) konfigurieren. Wenn der DB2 Connect-Server 1 aus irgendeinem Grund gesperrt wird, wird die automatische Clientweiterleitung ausgelöst, und es wird versucht, die Clientverbindung erneut herzustellen, wobei der Verteiler sowohl primärer und als auch alternativer Server ist. Mit dieser Option können Sie die Funktionalität des Verteilers mit der DB2-Funktion für automatische Clientweiterleitung kombinieren und verwalten. Wenn Sie den alternativen Server auf einen anderen Hostnamen setzen als den Hostnamen des Verteilers, wird den Clients die Funktion für automatische Clientweiterleitung weiterhin bereitgestellt. Die Clients stellen jedoch direkte Verbindungen zum definierten alternativen Server her und umgehen die Distributortechnologie, wodurch der Nutzen des Verteilers verloren geht.
Die automatische Clientweiterleitung fängt die folgenden SQL-Codes ab:
Die folgenden beiden Aspekte sind im Hinblick auf die Verbindung zu alternativen Servern mit DB2 Connect-Server zu beachten:
Anwendungen, die im LSA-Kontext (Local System Account) ausgeführt werden, werden auf allen Windows-Plattformen außer unter Windows ME unterstützt.
Die Anweisung CONNECT und der Befehl ATTACH unterstützen zweiteilige Benutzer-IDs. Das Qualifikationsmerkmal der SAM-kompatiblen Benutzer-ID ist der NetBIOS-Name, der maximal 15 Zeichen lang ist. Diese Funktion wird unter Windows ME nicht unterstützt.
Sie können den Namen des Kerberos-Serverprincipals überschreiben, der vom DB2(R) Universal Database-Server (UDB) unter den UNIX(R)- und Linux(TM)-Betriebssystemen verwendet wird. Setzen Sie die Umgebungsvariable DB2_KRB5_PRINCIPAL auf den gewünschten vollständig qualifizierten Namen des Serverprincipals. Das Exemplar muss erneut gestartet werden, da der Name des Serverprincipals nur von DB2 UDB erkannt wird, nachdem db2start ausgeführt wurde.
Die Voraussetzungen für die Kerberos-Unterstützung unter Linux sind in der Dokumentation nicht ausreichend beschrieben. Das bereitgestellte DB2-Kerberos-Sicherheits-Plug-in wird mit Red Hat Enterprise Linux Advanced Server 3 auf einem Client mit IBM Network Authentication Service (NAS) 1.4 unterstützt.
Für Verbindungen zu zSeries und iSeries muss die Datenbank mit dem Parameter AUTHENTICATION KERBEROS katalogisiert werden. Der Parametername TARGET PRINCIPAL muss explizit angegeben werden.
zSeries und iSeries unterstützen keine gegenseitige Authentifizierung.
Außerdem wird im DB2-Verwaltungsprotokoll oder in der Datei db2diag.log in allen Fällen eine Nachricht angezeigt, dass die Anmeldung fehlgeschlagen ist bzw. verweigert wurde.
Die lokale Sicherheitsautorität (LSA) ist nicht erreichbar.Dieser Fehler tritt auf, da Windows zuerst den lokalen Benutzer erkennt. Der Fehler kann behoben werden, indem der Benutzer in der Verbindungszeichenfolge vollständig qualifiziert wird. Beispiel:
name@DOMAIN.IBM.COM
Wenn Sie bestimmen wollen, ob Windows-Konten so konfiguriert sind, dass die DES-Verschlüsselung verwendet werden kann, prüfen Sie die Kontomerkmale für Active Directory. Wenn die Kontomerkmale geändert werden, ist möglicherweise ein Neustart erforderlich.
host/<hostname_des_servers>@<domänenname_des_servers>Beispiel:
host/myhost.domain.ibm.com@DOMAIN.IBM.COMAndernfalls müssen Sie den DB2-Service über ein gültiges Domänenkonto starten.
Ein Governor-Exemplar besteht aus einem Front-End-Dienstprogramm und mindestens einem Dämon. |Jedes Governor-Exemplar, das Sie starten, ist genau einem Exemplar des Datenbankmanagers zugeordnet. Wenn Sie den Governor starten, wird auf jeder Partition einer partitionierten Datenbank standardmäßig ein Governor-Dämon gestartet. Sie können jedoch angeben, dass auf einer einzelnen zu überwachenden Partition ein Dämon gestartet werden soll.
| |Jeder Governor-Dämon sammelt Daten zu den Anwendungen, die für die Datenbank ausgeführt werden. +Anschließend überprüft der Governor-Dämon diese Daten anhand von Regeln, die Sie in der Governor-Konfigurationsdatei für diese Datenbank angeben.
| | |Wenn Sie die Inplace-Tabellenreorganisation (statt der herkömmlichen Tabellenreorganisation) in Betracht ziehen, sollten Sie beachten, dass die Inplace-Tabellenreorganisation mehr Protokollspeicherbereich erfordert.
|Da die Inplace-Tabellenreorganisation ihre Aktivitäten protokolliert, um nach einem unvorhergesehenen Ausfall eine Wiederherstellung ausführen zu können, wird für diesen Reorganisationstyp mehr Protokollspeicherbereich benötigt als für die herkömmliche Reorganisation.
|Die Inplace-Tabellenreorganisation kann unter Umständen als Protokollspeicherbereich ein Vielfaches der Größe der reorganisierten Tabelle erfordern. Die Größe des erforderlichen Speicherbereichs hängt von der Anzahl der verschobenen Zeilen sowie von der Anzahl und Größe der Indizes für die Tabelle ab.
|Empfehlung: Wählen Sie die Inplace-Tabellenreorganisation für Operationen aus, die mit minimalen Wartungszeiten rund um die Uhr ausgeführt werden.
|Während einer Onlinetabellenreorganisation einer DMS-Tabelle können Sie eine Onlinesicherung für einen Tabellenbereich aufrufen, in dem sich die Tabelle befindet. Während der Abschneidephase können für die Reorganisationsoperation Wartestatus für Sperren (Lock Waits) auftreten.
|Detaillierte Informationen zur Ausführung dieser Tabellenreorganisationsmethoden finden Sie in den Beschreibungen zur Syntax von REORG TABLE.
| | |Unter AIX(R) 5L, 64 Bit, unterstützt die Registrierdatenbankvariable DB2_LARGE_PAGE_MEM nun das Schlüsselwort FCM.
|Unter AIX 5L(TM), 64 Bit, befindet sich FCM-Speicher standardmäßig in der DBMS-Speichergruppe. Wenn jedoch die Registrierdatenbankvariable DB2_FORCE_FCM_BP aktiviert ist, befindet sich der FCM-Speicher in seiner eigenen Speichergruppe. Unter AIX 5L, 64 Bit, unterstützt die Registrierdatenbankvariable DB2_LARGE_PAGE_MEM die Angabe der DBMS-Speichergruppe. Wenn sich FCM-Speicher in der DBMS-Speichergruppe befindet und die Unterstützung großer Seiten für diese Speichergruppe aktiviert ist, verfügt der FCM-Speicher über größere Seiten. Wenn FCM-Speicher sich in einer eigenen Speichergruppe befindet, muss dem Wert der Registrierdatenbankvariablen DB2_LARGE_PAGE_MEM das Schlüsselwort FCM hinzugefügt werden, damit große Seiten für FCM-Speicher unterstützt werden.
Ab DB2 Universal Database(TM) (UDB) Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) akzeptiert die Konfigurationsdatei, die von der Registrierdatenbankvariablen DB2_RESOURCE_POLICY angegeben wird, ein SCHEDULING_POLICY-Element. Das SCHEDULING_POLICY-Element kann einigen Plattformen zur Auswahl folgender Elemente verwendet werden:
Die Registrierdatenbankvariablen DB2PRIORITIES und DB2NTPRICLASS können einzeln zum Steuern der Planungsrichtlinie des Betriebssystems und zum Festlegen von DB2-Agentenprioritäten verwendet werden.
Durch die Angabe eines SCHEDULING_POLICY-Elements in der Konfigurationsdatei für die Ressourcenrichtlinie können Sie die Planungsrichtlinie und die zugehörigen Agentenprioritäten an einer Stelle festlegen.
Auswahl der AIX-Planungsrichtlinie SCHED_FIFO2 mit gleichzeitiger Zuordnung einer höheren Priorität für die Prozesse der DB2-Ein- und -Ausgabeprogramme für Protokolle:
<RESOURCE_POLICY> <SCHEDULING_POLICY> <POLICY_TYPE>SCHED_FIFO2</POLICY_TYPE> <PRIORITY_VALUE>60</PRIORITY_VALUE> <EDU_PRIORITY> <EDU_NAME>db2loggr</EDU_NAME> <PRIORITY_VALUE>56</PRIORITY_VALUE> </EDU_PRIORITY> <EDU_PRIORITY> <EDU_NAME>db2loggw</EDU_NAME> <PRIORITY_VALUE>56</PRIORITY_VALUE> </EDU_PRIORITY> </SCHEDULING_POLICY> </RESOURCE_POLICY>
Ersatz für DB2NTPRICLASS=H unter Windows.
<RESOURCE_POLICY> <SCHEDULING_POLICY> <POLICY_TYPE>HIGH_PRIORITY_CLASS</POLICY_TYPE> </SCHEDULING_POLICY> </RESOURCE_POLICY>
In FixPak 8 wurden die Systemumgebungsvariablen DB2_MAPPED_BASE und DB2DBMSADDR hinzugefügt.
Nur fortgeschrittene Benutzer sollten diese Registrierdatenbankvariablen verwenden.
Wenn diese Variable nicht gesetzt ist, versucht DB2 UDB, die gemeinsam genutzten Bibliotheken an die virtuelle Adresse 0x10000000 zu verlagern.
Die Registrierdatenbankvariable kann auch auf eine beliebige virtuelle Adresse (hexadezimal) im Bereich des 31- und 32-Bit-Adressraums gesetzt werden.
db2set DB2_MAPPED_BASE=
Die folgende Nachricht kann mehrmals in der Datei db2diag.log vorkommen, da diese Änderung für jeden logischen Knoten einmal erforderlich ist:
ADM0506I DB2 hat den Kernelparameter "mapped_base" automatisch von "0x40000000(hex) 1073741824(dec)" auf den empfohlenen Wert "0x10000000(hex) 268435456(dec)" aktualisiert.
Diese Nachricht wird nur angezeigt, wenn das Setzen der Registrierdatenbankvariablen erfolgreich war, und sie enthält die Adresse, an die die gemeinsam genutzten Bibliotheken verlagert werden.
db2set DB2DBMSADDR=
Diese Variable können Sie in Verbindung mit DB2_MAPPED_BASE oder alleine setzen, um die Adressraumbelegung von DB2 UDB-Prozessen zu optimieren. Diese Variable ändert die Position des gemeinsam genutzten Speichers für das Exemplar von der aktuellen Position bei der virtuellen Adresse 0x20000000 in den neu angegebenen Wert.
In Version 8.2 wurde die Registrierdatenbankvariable DB2TCP_CLIENT_RCVTIMEOUT hinzugefügt.
In Version 8.2 wurde die Leistungsvariable DB2_LARGE_PAGE_MEM hinzugefügt.
Variablenname | Betriebssysteme | Werte |
---|---|---|
Beschreibung | ||
DB2_LARGE_PAGE_MEM |
Nur AIX 5.x (64 Bit) Linux |
Standardwert=NULL
Geben Sie mit Hilfe eines Sterns (*) an, dass alle gültigen Speicherbereiche große Seitenspeicher verwenden sollen, oder geben Sie eine durch Kommas getrennte Liste spezifischer Speicherbereiche an, die den großen Seitenspeicher verwenden sollen. Die verfügbaren Bereiche variieren je nach dem verwendeten Betriebssystem. Unter AIX 5.x (64 Bit) können die folgenden Bereiche angegeben werden: DB, DBMS oder PRIVATE. Unter Linux kann der folgende Bereich angegeben werden: DB. |
Der große Seitenspeicher wird lediglich für DB2 Universal Database (UDB) für AIX 5L (64-Bit-Edition) und DB2 UDB für Linux unterstützt. Die Registrierdatenbankvariable DB2_LARGE_PAGE_MEM wird verwendet, um unter AIX 5.x oder für eine beliebige Linux-Architektur mit der entsprechenden Kernelunterstützung die Unterstützung für große Seiten zu aktivieren. Sie ersetzt die Registrierdatenbank- variable DB2_LGPAGE_BP, die lediglich zur Aktivierung des großen Seitenspeichers für den gemeinsam genutzten Datenbankspeicherbereich verwendet wird. Dieser kann jetzt durch die Angabe von DB2_LARGE_PAGE_MEM=DB aktiviert werden. In einigen Doku- mentationen wird erläutert, dass große Seiten mit der Registrierdatenbankvariablen DB2_LGPAGE_BP ermöglicht werden. Dies entspricht der Einstellung DB2_LARGE_PAGE_MEM=DB. Die Verwendung großer Seiten dient hauptsächlich zur Leistungsverbesserung hochleistungsfähiger Datenverarbeitungsanwendungen. Bei Anwendungen, die einen intensiven Speicherzugriff erfordern und große Mengen an virtuellem Speicher verwenden, kann die Verwendung großer Seiten zu einer Leistungsverbesserung führen. Um DB2 UDB für die Verwendung großer Seiten zu aktivieren, müssen Sie zunächst das Betriebssystem für die Verwendung solcher Seiten konfigurieren. Durch die Aktivierung großer privater Seiten nimmt die DB2 UDB-Speicherbelegung deutlich zu, da jeder DB2 UDB-Agent mindestens eine große Seite (16 MB) an physischem Speicher belegt. Zum Aktivieren großer Seiten für privaten Agentenspeicher auf 64-Bit-DB2 UDB für AIX (Einstellung DB2_LARGE_PAGE_MEM=PRIVATE) müssen große Seiten auf dem Betriebssystem konfiguriert sein. Außerdem müssen die folgenden Voraussetzungen gegeben sein:
Unter DB2 UDB für AIX (64 Bit) reduziert diese Variable die Größe des gemeinsamen Speichersegments, das den Datenbankspeicher unterstützt, auf den Mindestbedarf. Standardmäßig wird ein 64-GB-Segment erstellt. Weitere Informationen hierzu finden Sie unter dem Konfigurationsparameter für die Größe des gemeinsamen Datenbankspeichers. Dadurch wird vermieden, dass mehr gemeinsam genutzter Speicher im Arbeitsspeicher belassen wird als voraussichtlich verwendet wird. Die Aktivierung dieser Variablen schränkt die Möglichkeit ein, die Konfiguration für den gesamten gemeinsamen Daten- bankspeicher dynamisch zu erhöhen (z. B. Vergrößerung der Pufferpools). Unter Linux muss als zusätzliche Voraussetzung die Bibliothek libcap.so verfügbar sein. Diese Bibliothek muss installiert sein, damit diese Option funktioniert. Wenn die Option aktiviert wird und die Bibliothek nicht im System vorhanden ist, inaktiviert DB2 UDB die großen Kernelseiten und setzt die Verarbeitung wie zuvor fort. Um unter Linux zu prüfen, ob große Kernelseiten verfügbar sind, können Sie den folgenden Befehl absetzen: cat /proc/meminfo Wenn sie verfügbar sind, sollten die drei folgenden Zeilen angezeigt werden (mit anderen Werten, je nach Größe des auf Ihrer Maschine konfigurierten Speichers): HugePages_Total: 200 HugePages_Free: 200 Hugepagesize: 16384 KB Wenn diese Zeilen nicht angezeigt werden oder HugePages_Total den Wert 0 hat, ist eine Konfiguration des Betriebssystems oder des Kernels erforderlich. |
Die folgende Aktualisierung gilt für das Thema "Variablen des SQL-Compilers" im Anhang A "Registrierdatenbank- und Umgebungsvariablen von DB2" des Handbuchs Systemverwaltung: Optimierung:
Wenn mindestens eine der beiden DB2-Compilervariablen DB2_MINIMIZE_LISTPREFETCH und DB2_INLIST_TO_NLJN auf ON gesetzt ist, bleibt sie selbst dann aktiv, wenn REOPT(ONCE) angegeben ist.
Im Folgenden finden Sie die Aktualisierungen der Dokumentation zu den Konfigurationsparametern:
Der Konfigurationsparameter für den Authentifizierungstyp (authentication) des Datenbankmanagers akzeptiert außerdem die folgenden Werte:
Der Server akzeptiert verschlüsselte SERVER-Authentifizierungsschemata und die Verschlüsselung von Benutzerdaten. Die Authentifizierung funktioniert genau wie für SERVER_ENCRYPT.
Die folgenden Benutzerdaten werden bei Verwendung dieses Authentifizierungstyps verschlüsselt:
Der Server akzeptiert verschlüsselte SERVER-Authentifizierungsschemata und die Verschlüsselung von Benutzerdaten. Darüber hinaus bietet dieser Authentifizierungstyp Kompatibilität mit Produkten früherer Versionen, die den Authentifizierungstyp DATA_ENCRYPT nicht unterstützen. Diese Produkte erhalten die Möglichkeit, die Verbindung mit dem Authentifizierungstyp SERVER_ENCRYPT und ohne Verschlüsselung von Benutzerdaten herzustellen. Produkte, die den neuen Authentifizierungstyp unterstützen, müssen ihn verwenden. Dieser Authentifizierungstyp ist nur in der Konfigurationsdatei des Datenbankmanagers des Servers, jedoch nicht im Befehl CATALOG DATABASE gültig.
Ab DB2 Universal Database Version 8.2 wird der Standardwert des Konfigurationsparameters Auslastungswirkung durch gedrosselte Dienstprogramme (util_impact_lim) für den Datenbankmanager von 100 in 10 geändert.
Die folgenden Konfigurationsparameter für den Datenbankmanager akzeptieren auf allen Plattformen bis zu 30 Byte lange Gruppennamen:
Die Tabelle unter der Übersicht über die Konfigurationsparameter des Datenbankmanagers (Handbuch Systemverwaltung: Optimierung) enthält falsche Datentypen zu diesen Konfigurationsparametern für den Datenbankmanager. Der richtige Wert muss in allen Fällen char(30) lauten.
Die Maximalgröße für den Datenbankkonfigurationsparameter Segmentgröße für erweiterten Speicher (estore_seg_size) auf Windows-Plattforman lautet 16.777.216.
Die richtige Obergrenze für den Datenbankkonfigurationsparameter HADR-Zeitlimitwert (hadr_timeout) lautet 4.294.967.295.
In der Dokumentation zum Datenbankkonfigurationsparameter Max. Speicher für Sperrenliste (locklist) steht, dass der Maximalwert für Windows-64-Bit- und 32-Bit-Server, die nur Server für lokale Clients sind, 60.000 beträgt. Dieser Wert ist falsch. Er muss 524.288 lauten.
Der Wertebereich für den Datenbankkonfigurationsparameter Anzahl der Datenbanksicherungen (num_db_backups) ist falsch. Der richtige Bereich ist 0 - 32.767.
Nach der Migration von Version 8.1 auf DB2 Universal Database (UDB) Version 8.2 verwendet DB2 UDB eine neue 16 KB große Datei für Datenbankkonfigurationsparameter mit dem Namen SQLDBCONF. (In Version 8.1 war die Datei für Datenbankkonfigurationsparameter nur 4 KB groß und hieß SQLDBCON.)
Ab Version 8.1 ist die Registrierdatenbankvariable DB2_HASH_JOIN standardmäßig auf ON gesetzt.
Die Hashverknüpfungsvariable DB2_HASH_JOIN sollte verwendet werden, muss jedoch optimiert werden, um die maximale Leistung zu erzielen.
Die Leistung der Hashverknüpfung ist am besten, wenn Sie Hashschleifen und Überläufe auf den Plattenspeicher vermeiden können. Zur Optimierung der Leistung von Hashverknüpfungen schätzen Sie die maximale Speichergröße ab, die für den Parameter sheapthres verfügbar ist, und optimieren anschließend den Parameter sortheap. Erhöhen Sie den Wert dieses Parameters, bis Sie möglichst viele Hashschleifen und Überläufe auf den Plattenspeicher vermeiden, jedoch nicht den durch den Parameter sheapthres definierten Grenzwert erreichen.
Weitere Informationen finden Sie im Thema "Verknüpfungsmethoden" im Handbuch Systemverwaltung: Optimierung.
Die zuvor durch die Variable DB2NTNOCACHE erreichte Funktionalität kann auf Tabellenbereichsebene erreicht werden, indem in der Anweisung CREATE TABLESPACE oder ALTER TABLESPACE die Klausel NO FILE SYSTEM CACHING angegeben wird. Weitere Informationen hierzu finden Sie im Handbuch SQL Reference. Die Registrierdatenbankvariable DB2NTNOCACHE wird in einem zukünftigen Release entfernt.
EXPLAIN-Tabellen können für mehrere Benutzer gemeinsame Daten enthalten. Die EXPLAIN-Tabellen können jedoch auch für nur einen Benutzer definiert werden. Außerdem können Aliasnamen für jeden weiteren Benutzer definiert werden, der denselben Namen verwendet, um auf die definierten Tabellen zu verweisen. Die EXPLAIN-Tabellen können auch unter dem Schema SYSTOOLS definiert werden. Die EXPLAIN-Funktion verwendet standardmäßig das Schema SYSTOOLS, wenn keine anderen EXPLAIN-Tabellen oder -Aliasnamen unter der Sitzungs-ID des Benutzers für dynamisches SQL oder unter der Berechtigungs-ID der Anweisung für statisches SQL gefunden werden. Jeder Benutzer, der auf die gemeinsamen EXPLAIN-Tabellen zugreift, muss das Zugriffsrecht INSERT zum Einfügen für diese Tabellen aufweisen. Der Lesezugriff für die allgemeinen EXPLAIN-Tabellen muss ebenfalls eingeschränkt werden, speziell für Benutzer, die die EXPLAIN-Informationen analysieren.
EXPLAIN-Daten werden bei der Kompilierung einer SQL-Anweisung erfasst, wenn Sie dies anfordern. Bei der Anforderung von EXPLAIN-Daten sollten Sie berücksichtigen, wie die erfassten Informationen später verwendet werden sollen.
Informationen für EXPLAIN-Tabellen werden in folgenden Fällen erfasst:
Der Parameter für Sortierinformationen kann nur mit der API db2CfgGet angezeigt werden. Er kann nicht mit Hilfe des Befehlszeilenprozessors oder der Steuerzentrale angezeigt werden.
Dieser Parameter enthält 260 Byte mit Informationen zur Sortierfolge der Datenbank. Die ersten 256 Byte geben die Sortierfolge der Datenbank an, wobei Byte "n" die Sortierwertigkeit des Codepunkts enthält, dessen zu Grunde liegende dezimale Darstellung "n" in der Codepage der Datenbank ist.
Die letzten 4 Byte enthalten interne Informationen zum Typ der Sortierfolge. Bei den letzten vier Byte von collate_info handelt es sich um eine ganze Zahl. Die ganze Zahl erkennt die Endian-Folge der Plattform. Die möglichen Werte sind:
Wenn Sie diese internen Informationen zum Typ der Sortierfolge verwenden, müssen Sie eine Bytefolgeumkehrung in Betracht ziehen, wenn Informationen zu einer Datenbank auf einer anderen Plattform abgerufen werden.
Sie können die Sortierfolge bei der Erstellung der Datenbank angeben.
Ab DB2 Universal Database (UDB) Version 8.2 können Sie als Vorablesezugriffsgröße für einen Tabellenbereich die Einstellung AUTOMATIC verwenden. DB2 UDB aktualisiert automatisch die Vorablesezugriffsgröße, sobald sich die Anzahl der Behälter für den Tabellenbereich ändert.
Die Syntax der Registrierdatenbankvariablen DB2_PARALLEL_IO wird so erweitert, dass Behälter mit unterschiedlichen Merkmalen für die E/A-Parallelität erkannt werden. Bei der erweiterten Syntax können Behälter für unterschiedliche Tabellenbereiche unterschiedliche Merkmale für die E/A-Parallelität aufweisen. Die Merkmale für die E/A-Parallelität der einzelnen Tabellenbereiche werden verwendet, wenn für den Tabellenbereich als Vorablesezugriffsgröße AUTOMATIC angegeben ist. Wenn die Registrierdatenbankvariable DB2_PARALLEL_IO aktiviert ist, die erweiterte Syntax zur Angabe besonderer Merkmale für die E/A-Parallelität für Tabellenbereiche jedoch nicht verwendet wird, wird die Standardstufe für die Parallelität vorausgesetzt. Die Standardstufe ist RAID 5 (6+1).
Die vom Optimierungsprogramm verwendeten Daten für die Vorablesezugriffsgröße werden nur aktualisiert, wenn Sie eine ALTER TABLESPACE-Anweisung absetzen, die die Vorablesezugriffsgröße eines Tabellenbereichs oder die Anzahl der Behälter (mit ADD/DROP/BEGIN NEW STRIPE SET/ADD TO NEW STRIPE SET) ändert. Wenn sich die Anzahl physischer Festplatten pro Behälter in den Registry-Einstellungen ändert, muss die Anweisung ALTER TABLESPACE <tabellenbereichsname> PREFETCHSIZE AUTOMATIC abgesetzt werden, um die Daten des Optimierungsprogramms zu aktualisieren (es sei denn, eine ALTER TABLESPACE-Anweisung zur Aktualisierung der Daten des Optimierungsprogramms wurde bereits abgesetzt).
Wenn ein Tabellenbereich umgeleitet oder wiederhergestellt wird, so dass eine andere Anzahl von Behältern verwendet wird, sollten Sie die Daten des Optimie- rungsprogramms aktualisieren, indem Sie eine Anweisung ALTER TABLESPACE <tabellenbereichsname> PREFETCHSIZE AUTOMATIC absetzen. Wenn in einem Tabellenbereich mehrere Stripe-Sets vorhanden sind, wird der Stripe-Set mit der maximalen Anzahl von Behältern zur Berechnung der Vorablesezugriffsgröße verwendet. Wenn die berechnete Vorablesezugriffsgröße die Maximalgröße (32.767 Seiten) überschreitet, wird als Vorablesezugriffsgröße das größte Vielfache der Behäl- teranzahl verwendet, das kleiner als die Maximalgröße ist.
Wenn ein Tabellenbereich in einer DB2 UDB Enterprise Server Edition-Umgebung die Einstellung AUTOMATIC für die Vorablesezugriffsgröße verwendet, kann die Vorablesezugriffsgröße auf unterschiedlichen Datenbankpartitionen voneinander abweichen. Diese Situation kann eintreten, da unterschiedliche Datenbankpartitionen eine unterschiedliche Anzahl von Behältern aufweisen können, die zur Berechnung der Vorablesezugriffsgröße verwendet werden. Zum Generieren des Abfragezugriffsplans verwendet das Optimierungsprogramm die Vorablesezugriffsgröße aus der ersten Partition innerhalb einer Datenbankpartitionsgruppe.
Eine Bereichsclustertabelle kann nicht in einer Datenbank erstellt werden, die mehr als eine Partition hat.
Bei der Erstellung einer Datenbank werden drei Tabellenbereiche definiert. Dazu gehört der Tabellenbereich SYSCATSPACE für die Systemkatalogtabellen. Die Seitengröße, die als Standardeinstellung für alle Tabellenbereiche gilt, wird bei der Erstellung der Datenbank festgelegt. Bei Auswahl einer Seitengröße von mehr als 4096 bzw. 4 KB wird die Seitengröße für die Katalogtabellen auf eine Zeilengröße beschränkt, die sie haben würde, wenn der Katalogtabellenbereich eine Seitengröße von 4 KB hätte. Die Standardseitengröße der Datenbank wird als informativer Datenbankkonfigurationsparameter mit dem Namen pagesize gespeichert.
Im Anhang B "Unterstützung in der Landessprache" des Handbuchs Systemverwaltung: Konzept finden Sie im Thema "Unterstützte Gebietscodes und Codepages" Tabellen für die einzelnen Gebiete. Für zwei Tabellen ist eine Aktualisierung erforderlich:
Die Codepage für die GBK-Zeile für Linux in der Tabelle "China (VRC), Gebietskennung: CN" muss von 1383 in 1386 geändert werden.
Die Zeile sollte also wie folgt lauten:
1386 D-4 GBK 86 zh_CN.GBK Linux
Die Tabelle für "Japan, Gebietskennung: JP" wurde überarbeitet.
Der folgende Name für die Ländereinstellung muss entfernt werden:
954 D-1 eucJP 81 japanese Solaris
Die überarbeitete Tabelle sieht wie folgt aus:
Codepage | Gruppe | Codierter Zeichens. | Gebietscode | Ländereinstellung | Betriebs- system |
---|---|---|---|---|---|
932 | D-1 | IBM-932 | 81 | Ja_JP | AIX |
943 | D-1 | IBM-943 | 81 | Ja_JP | AIX |
954 | D-1 | IBM-eucJP | 81 | ja_JP | AIX |
1208 | N-1 | UTF-8 | 81 | JA_JP | AIX |
930 | D-1 | IBM-930 | 81 | - | Host |
939 | D-1 | IBM-939 | 81 | - | Host |
5026 | D-1 | IBM-5026 | 81 | - | Host |
5035 | D-1 | IBM-5035 | 81 | - | Host |
1390 | D-1 | 81 | - | Host | |
1399 | D-1 | 81 | - | Host | |
954 | D-1 | eucJP | 81 | ja_JP.eucJP | HP-UX |
5039 | D-1 | SJIS | 81 | ja_JP.SJIS | HP-UX |
954 | D-1 | EUC-JP | 81 | ja_JP | Linux |
932 | D-1 | IBM-932 | 81 | - | OS/2 |
942 | D-1 | IBM-942 | 81 | - | OS/2 |
943 | D-1 | IBM-943 | 81 | - | OS/2 |
954 | D-1 | eucJP | 81 | ja | SCO |
954 | D-1 | eucJP | 81 | ja_JP | SCO |
954 | D-1 | eucJP | 81 | ja_JP.EUC | SCO |
954 | D-1 | eucJP | 81 | ja_JP.eucJP | SCO |
943 | D-1 | IBM-943 | 81 | ja_JP.PCK | Solaris |
954 | D-1 | eucJP | 81 | ja | Solaris |
1208 | N-1 | UTF-8 | 81 | ja_JP.UTF-8 | Solaris |
943 | D-1 | IBM-943 | 81 | - | Windows |
1394 | D-1 | 81 | - |
DB2 Universal Database (UDB) unterstützt die Spezifikation XA91, die in X/Open CAE Specification Distributed Transaction Processing: The XA Specification definiert ist, mit folgenden Ausnahmen:
Wie für die XA-Schnittstelle erforderlich, stellt der Datenbankmanager eine externe C-Variable db2xa_switch und db2xa_switch_static des Typs xa_switch_t bereit, um die XA-Schalterstruktur an den Transaktionsmanager zurückzugeben. Neben den Adressen verschiedener XA-Funktionen werden folgende Felder zurückgegeben:
Gibt explizit an, dass DB2 UDB die dynamische Registrierung verwendet und dass der TM keine Migration von Zuordnungen verwenden soll. Gibt implizit an, dass kein asynchroner Betrieb unterstützt wird.
Für db2xa_switch_static ist der Wert TMNOMIGRATE festgelegt.
Gibt explizit an, dass DB2 UDB die dynamische Registrierung verwendet und dass der TM keine Migration von Zuordnungen verwenden soll. Gibt implizit an, dass kein asynchroner Betrieb unterstützt wird.
Die XA-Architektur erfordert, dass ein Ressourcenmanager (RM) einen Schalter bereitstellt, der dem XA-Transaktionsmanager (TM) Zugriff auf die xa_-Routinen des Ressourcenmanagers gibt. Ein RM-Schalter verwendet eine Struktur, die als xa_switch_t bezeichnet wird. Der Schalter enthält den Namen des RMs, Nicht-NULL-Zeiger auf die XA-Eingangspunkte des RMs, eine Markierung (Flag) und eine Versionsnummer.
Der Schalter für DB2 Universal Database (UDB) kann durch eine der folgenden Methoden abgerufen werden:
#define db2xa_switch (*db2xa_switch) #define db2xa_switch_static (*db2xa_switch)Führen Sie dies vor Verwendung von db2xa_switch oder db2xa_switch_static durch.
DB2 UDB stellt diese APIs zur Verfügung, die die Adresse der Struktur db2xa_switch oder db2xa_switch_static zurückgeben. Der Prototyp dieser Funktion lautet:
struct xa_switch_t * SQL_API_FN db2xacic( ) struct xa_switch_t * SQL_API_FN db2xacicst( )
Bei beiden Methoden müssen Sie die Anwendung an libdb2 binden ("linken").
Der Zeiger auf die Struktur xa_switch, db2xa_switch oder db2xa_switch_static wird in Form von DLL-Daten exportiert. Dies heißt für eine Anwendung unter Windows NT, die diese Struktur verwendet, dass sie mit Hilfe einer der folgenden drei Methoden auf die Struktur zugreifen muss:
#define db2xa_switch (*db2xa_switch) #define db2xa_switch_static (*db2xa_switch)Führen Sie dies vor Verwendung von db2xa_switch oder db2xa_switch_static durch.
extern __declspec(dllimport) struct xa_switch_t db2xa_switch extern __declspec(dllimport) struct xa_switch_t db2xa_switch_static
DB2 UDB stellt diese API zur Verfügung, die die Adresse der Struktur db2xa_switch oder db2xa_switch_static zurückgibt. Der Prototyp dieser Funktion lautet:
struct xa_switch_t * SQL_API_FN db2xacic( ) struct xa_switch_t * SQL_API_FN db2xacicst( )
Bei jeder dieser Methoden müssen Sie die Anwendung an db2api.lib binden ("linken").
Der folgende Code veranschaulicht die verschiedenen Methoden des Zugriffs auf db2xa_switch oder db2xa_switch_static über ein C-Programm auf einer beliebigen DB2 UDB-Plattform. Stellen Sie sicher, dass die Anwendung mit der entsprechenden Bibliothek verbunden wird.
#include <stdio.h> #include <xa.h> struct xa_switch_t * SQL_API_FN db2xacic( ); #ifdef DECLSPEC_DEFN extern __declspec(dllimport) struct xa_switch_t db2xa_switch; #else #define db2xa_switch (*db2xa_switch) extern struct xa_switch_t db2xa_switch; #endif
main( ) { struct xa_switch_t *foo; printf ( "%s \n", db2xa_switch.name ); foo = db2xacic(); printf ( "%s \n", foo->name ); return ; }
Die Spalte "Interne Einstellungen" in der folgenden Tabelle wurde so aktualisiert, dass sie die Einstellungen für den TOC (Thread of Control) enthält.
TOC ist die Entität, an die alle DB2 UDB-XA-Verbindungen gebunden werden:
TPM-Wert | TP-Monitorprodukt | Interne Einstellungen |
---|---|---|
CICS | IBM TxSeries CICS |
AXLIB=libEncServer (für Windows)
=/usr/lpp/encina/lib/libEncServer
(für Linux and UNIX-Systeme)
HOLD_CURSOR=T
CHAIN_END=T
SUSPEND_CURSOR=F
TOC=T |
ENCINA | IBM TxSeries Encina Monitor |
AXLIB=libEncServer (für Windows)
=/usr/lpp/encina/lib/libEncServer
(für Linux and UNIX-Systeme)
HOLD_CURSOR=F
CHAIN_END=T
SUSPEND_CURSOR=F
TOC=T |
MQ | IBM MQSeries |
AXLIB=mqmax
(für Windows)
=/usr/mqm/lib/libmqmax_r.a
(für AIX-Anwendungen mit Threads)
=/usr/mqm/lib/libmqmax.a
(für AIX-Anwendungen ohne Threads)
=/opt/mqm/lib/libmqmax.so
(für Solaris)
=/opt/mqm/lib/libmqmax_r.sl
(für HP-Anwendungen mit Threads)
=/opt/mqm/lib/libmqmax.sl
(für HP-Anwendungen ohne Threads)
=/opt/mqm/lib/libmqmax_r.so
(für Linux-Anwendungen mit Threads)
=/opt/mqm/lib/libmqmax.so
(für Linux-Anwendungen ohne Threads)
HOLD_CURSOR=F
CHAIN_END=F
SUSPEND_CURSOR=F
TOC=P |
CB | IBM Component Broker |
AXLIB=somtrx1i (für Windows)
=libsomtrx1
(für Linux and UNIX-Systeme)
HOLD_CURSOR=F
CHAIN_END=T
SUSPEND_CURSOR=F
TOC=T |
SF | IBM San Francisco |
AXLIB=ibmsfDB2 HOLD_CURSOR=F CHAIN_END=T SUSPEND_CURSOR=F TOC=T |
TUXEDO | BEA Tuxedo |
AXLIB=libtux HOLD_CURSOR=F CHAIN_END=F SUSPEND_CURSOR=F TOC=T |
MTS | Microsoft Transaction Server | Es ist nicht nötig, DB2 UDB für MTS zu konfigurieren. MTS wird vom ODBC-Treiber von DB2 UDB automatisch erkannt. |
JTA | Java Transaction API | Es ist nicht nötig, DB2 UDB for Enterprise Java Servers (EJS) wie IBM WebSphere zu konfigurieren. Der JDBC-Treiber von DB2 UDB erkennt diese Umgebung automatisch. In diesem Fall wird der TPM-Wert ignoriert. |
Die folgende Tabelle enthält eine Liste mit allen Konvertierungstabellendateien für Codepages, die den Codepages 923 und 924 zugeordnet sind. Jeder Dateiname hat das Format XXXXYYYY.cnv oder ibmZZZZZ.ucs, wobei XXXX die Nummer der Quellencodepage und YYYY die Nummer der Zielcodepage ist. Die Datei ibmZZZZZ.ucs unterstützt die Konvertierung zwischen Codepage ZZZZZ und Unicode.
Zur Aktivierung einer bestimmten Codepagekonvertierungstabelle benennen Sie die Konvertierungstabellendatei in den neuen Namen um (oder kopieren die Datei in den neuen Namen), der in der zweiten Spalte angegeben ist.
Wenn Sie zum Beispiel bei der Verbindung eines Clients mit 8859-1/15 (Latin 1/9) mit einer Windows-1252-Datenbank das Euro-Symbol verwenden wollen, müssen Sie die folgenden Dateien mit Codepagekonvertierungstabellen im Verzeichnis sqllib/conv/ in den neuen Namen umbenennen bzw. kopieren:
Konvertierungstabellendateien für 923 und 924 im Verzeichnis sqllib/conv/ | Neuer Name |
---|---|
04370923.cnv | 04370819.cnv |
08500923.cnv | 08500819.cnv |
08600923.cnv | 08600819.cnv |
08630923.cnv | 08630819.cnv |
09230437.cnv | 08190437.cnv |
09230850.cnv | 08190850.cnv |
09230860.cnv | 08190860.cnv |
09231043.cnv | 08191043.cnv |
09231051.cnv | 08191051.cnv |
09231114.cnv | 08191114.cnv |
09231252.cnv | 08191252.cnv |
09231275.cnv | 08191275.cnv |
09241252.cnv | 10471252.cnv |
10430923.cnv | 10430819.cnv |
10510923.cnv | 10510819.cnv |
11140923.cnv | 11140819.cnv |
12520923.cnv | 12520819.cnv |
12750923.cnv | 12750819.cnv |
ibm00923.ucs | ibm00819.ucs |
In den folgenden Tabellen sind die Konvertierungstabellen aufgelistet, die zur Unterstützung des Euro-Symbols erweitert wurden. Wenn Sie die Unterstützung für das Euro-Symbol inaktivieren wollen, laden Sie die Konvertierungstabellendatei herunter, die in der Spalte 'Konvertierungstabellendateien' angegeben ist.
Datenbankserver-CCSIDs/CPGIDs | Datenbankclient-CCSIDs/CPGIDs | Konvertierungstabellendateien |
---|---|---|
864, 17248 | 1046, 9238 | 08641046.cnv, 10460864.cnv, IBM00864.ucs |
864, 17248 | 1256, 5352 | 08641256.cnv, 12560864.cnv, IBM00864.ucs |
864, 17248 | 1200, 1208, 13488, 17584 | IBM00864.ucs |
1046, 9238 | 864, 17248 | 10460864.cnv, 08641046.cnv, IBM01046.ucs |
1046, 9238 | 1089 | 10461089.cnv, 10891046.cnv, IBM01046.ucs |
1046, 9238 | 1256, 5352 | 10461256.cnv, 12561046.cnv, IBM01046.ucs |
1046, 9238 | 1200, 1208, 13488, 17584 | IBM01046.ucs |
1089 | 1046, 9238 | 10891046.cnv, 10461089.cnv |
1256, 5352 | 864, 17248 | 12560864.cnv, 08641256.cnv, IBM01256.ucs |
1256, 5352 | 1046, 9238 | 12561046.cnv, 10461256.cnv, IBM01256.ucs |
1256, 5352 | 1200, 1208, 13488, 17584 | IBM01256.ucs |
Datenbankserver-CCSIDs/CPGIDs | Datenbankclient-CCSIDs/CPGIDs | Konvertierungstabellendateien |
---|---|---|
921, 901 | 1257 | 09211257.cnv, 12570921.cnv, IBM00921.ucs |
921, 901 | 1200, 1208, 13488, 17584 | IBM00921.ucs |
1257, 5353 | 921, 901 | 12570921.cnv, 09211257.cnv, IBM01257.ucs |
1257, 5353 | 922, 902 | 12570922.cnv, 09221257.cnv, IBM01257.ucs |
1257, 5353 | 1200, 1208, 13488, 17584 | IBM01257.ucs |
Datenbankserver-CCSIDs/CPGIDs | Datenbankclient-CCSIDs/CPGIDs | Konvertierungstabellendateien |
---|---|---|
1131, 849 | 1251, 5347 | 11311251.cnv, 12511131.cnv |
1131, 849 | 1283 | 11311283.cnv |
Datenbankserver-CCSIDs/CPGIDs | Datenbankclient-CCSIDs/CPGIDs | Konvertierungstabellendateien |
---|---|---|
855, 872 | 866, 808 | 08550866.cnv, 08660855.cnv |
855, 872 | 1251, 5347 | 08551251.cnv, 12510855.cnv |
866, 808 | 855, 872 | 08660855.cnv, 08550866.cnv |
866, 808 | 1251, 5347 | 08661251.cnv, 12510866.cnv |
1251, 5347 | 855, 872 | 12510855.cnv, 08551251.cnv, IBM01251.ucs |
1251, 5347 | 866, 808 | 12510866.cnv, 08661251.cnv, IBM01251.ucs |
1251, 5347 | 1124 | 12511124.cnv, 11241251.cnv, IBM01251.ucs |
1251, 5347 | 1125, 848 | 12511125.cnv, 11251251.cnv, IBM01251.ucs |
1251, 5347 | 1131, 849 | 12511131.cnv, 11311251.cnv, IBM01251.ucs |
1251, 5347 | 1200, 1208, 13488, 17584 | IBM01251.ucs |
Datenbankserver-CCSIDs/CPGIDs | Datenbankclient-CCSIDs/CPGIDs | Konvertierungstabellendateien |
---|---|---|
922, 902 | 1257 | 09221257.cnv, 12570922.cnv, IBM00922.ucs |
922, 902 | 1200, 1208, 13488, 17584 | IBM00922.ucs |
Datenbankserver-CCSIDs/CPGIDs | Datenbankclient-CCSIDs/CPGIDs | Konvertierungstabellendateien |
---|---|---|
813, 4909 | 869, 9061 | 08130869.cnv, 08690813.cnv, IBM00813.ucs |
813, 4909 | 1253, 5349 | 08131253.cnv, 12530813.cnv, IBM00813.ucs |
813, 4909 | 1200, 1208, 13488, 17584 | IBM00813.ucs |
869, 9061 | 813, 4909 | 08690813.cnv, 08130869.cnv |
869, 9061 | 1253, 5349 | 08691253.cnv, 12530869.cnv |
1253, 5349 | 813, 4909 | 12530813.cnv, 08131253.cnv, IBM01253.ucs |
1253, 5349 | 869, 9061 | 12530869.cnv, 08691253.cnv, IBM01253.ucs |
1253, 5349 | 1200, 1208, 13488, 17584 | IBM01253.ucs |
Datenbankserver-CCSIDs/CPGIDs | Datenbankclient-CCSIDs/CPGIDs | Konvertierungstabellendateien |
---|---|---|
856, 9048 | 862, 867 | 08560862.cnv, 08620856.cnv, IBM0856.ucs |
856, 9048 | 916 | 08560916.cnv, 09160856.cnv, IBM0856.ucs |
856, 9048 | 1255, 5351 | 08561255.cnv, 12550856.cnv, IBM0856.ucs |
856, 9048 | 1200, 1208, 13488, 17584 | IBM0856.ucs |
862, 867 | 856, 9048 | 08620856.cnv, 08560862.cnv, IBM00862.ucs |
862, 867 | 916 | 08620916.cnv, 09160862.cnv, IBM00862.ucs |
862, 867 | 1255, 5351 | 08621255.cnv, 12550862.cnv, IBM00862.ucs |
862, 867 | 1200, 1208, 13488, 17584 | IBM00862.ucs |
916 | 856, 9048 | 09160856.cnv, 08560916.cnv |
916 | 862, 867 | 09160862.cnv, 08620916.cnv |
1255, 5351 | 856, 9048 | 12550856.cnv, 08561255.cnv, IBM01255.ucs |
1255, 5351 | 862, 867 | 12550862.cnv, 08621255.cnv, IBM01255.ucs |
1255, 5351 | 1200, 1208, 13488, 17584 | IBM01255.ucs |
Datenbankserver-CCSIDs/CPGIDs | Datenbankclient-CCSIDs/CPGIDs | Konvertierungstabellendateien |
---|---|---|
437 | 850, 858 | 04370850.cnv, 08500437.cnv |
850, 858 | 437 | 08500437.cnv, 04370850.cnv |
850, 858 | 860 | 08500860.cnv, 08600850.cnv |
850, 858 | 1114, 5210 | 08501114.cnv, 11140850.cnv |
850, 858 | 1275 | 08501275.cnv, 12750850.cnv |
860 | 850, 858 | 08600850.cnv, 08500860.cnv |
1275 | 850, 858 | 12750850.cnv, 08501275.cnv |
Datenbankserver-CCSIDs/CPGIDs | Datenbankclient-CCSIDs/CPGIDs | Konvertierungstabellendateien |
---|---|---|
852, 9044 | 1250, 5346 | 08521250.cnv, 12500852.cnv |
1250, 5346 | 852, 9044 | 12500852.cnv, 08521250.cnv, IBM01250.ucs |
1250, 5346 | 1200, 1208, 13488, 17584 | IBM01250.ucs |
Datenbankserver-CCSIDs/CPGIDs | Datenbankclient-CCSIDs/CPGIDs | Konvertierungstabellendateien |
---|---|---|
837, 935, 1388 | 1200, 1208, 13488, 17584 | 1388ucs2.cnv |
1386 | 1200, 1208, 13488, 17584 | 1386ucs2.cnv, ucs21386.cnv |
Datenbankserver-CCSIDs/CPGIDs | Datenbankclient-CCSIDs/CPGIDs | Konvertierungstabellendateien |
---|---|---|
937, 835, 1371 | 950, 1370 | 09370950.cnv, 0937ucs2.cnv |
937, 835, 1371 | 1200, 1208, 13488, 17584 | 0937ucs2.cnv |
1114, 5210 | 850, 858 | 11140850.cnv, 08501114.cnv |
Datenbankserver-CCSIDs/CPGIDs | Datenbankclient-CCSIDs/CPGIDs | Konvertierungstabellendateien |
---|---|---|
874, 1161 | 1200, 1208, 13488, 17584 | IBM00874.ucs |
Datenbankserver-CCSIDs/CPGIDs | Datenbankclient-CCSIDs/CPGIDs | Konvertierungstabellendateien |
---|---|---|
857, 9049 | 1254, 5350 | 08571254.cnv, 12540857.cnv |
1254, 5350 | 857, 9049 | 12540857.cnv, 08571254.cnv, IBM01254.ucs |
1254, 5350 | 1200, 1208, 13488, 17584 | IBM01254.ucs |
Datenbankserver-CCSIDs/CPGIDs | Datenbankclient-CCSIDs/CPGIDs | Konvertierungstabellendateien |
---|---|---|
1124 | 1251, 5347 | 11241251.cnv, 12511124.cnv |
1125, 848 | 1251, 5347 | 11251251.cnv, 12511125.cnv |
Datenbankserver-CCSIDs/CPGIDs | Datenbankclient-CCSIDs/CPGIDs | Konvertierungstabellendateien |
---|---|---|
1200, 1208, 13488, 17584 | 813, 4909 | IBM00813.ucs |
1200, 1208, 13488, 17584 | 862, 867 | IBM00862.ucs |
1200, 1208, 13488, 17584 | 864, 17248 | IBM00864.ucs |
1200, 1208, 13488, 17584 | 874, 1161 | IBM00874.ucs |
1200, 1208, 13488, 17584 | 921, 901 | IBM00921.ucs |
1200, 1208, 13488, 17584 | 922, 902 | IBM00922.ucs |
1200, 1208, 13488, 17584 | 1046, 9238 | IBM01046.ucs |
1200, 1208, 13488, 17584 | 1250, 5346 | IBM01250.ucs |
1200, 1208, 13488, 17584 | 1251, 5347 | IBM01251.ucs |
1200, 1208, 13488, 17584 | 1253, 5349 | IBM01253.ucs |
1200, 1208, 13488, 17584 | 1254, 5350 | IBM01254.ucs |
1200, 1208, 13488, 17584 | 1255, 5351 | IBM01255.ucs |
1200, 1208, 13488, 17584 | 1256, 5352 | IBM01256.ucs |
1200, 1208, 13488, 17584 | 1386 | ucs21386.cnv, 1386ucs2.cnv |
Datenbankserver-CCSIDs/CPGIDs | Datenbankclient-CCSIDs/CPGIDs | Konvertierungstabellendateien |
---|---|---|
1258, 5354 | 1129, 1163 | 12581129.cnv |
Die Option SYNCPOINT für die APIs sqlesetc, sqleqryc und sqlaprep wird ab Version 8 ignoriert; sie ist nur aus Gründen der Abwärtskompatibilität verfügbar.
Der API sqlecrea wurde ein neues Feld hinzugefügt, damit direkte E/A unterstützt wird.
Der Struktur SQLB-TBSPQRY-DATA wurde das neue Feld unsigned char fsCaching hinzugefügt. Dieses Feld unterstützt die direkte E/A. Obwohl die Größe des reservierten Bits in der Dokumentation als 32 Bit dokumentiert ist, muss die richtige Größe 31 Bit lauten.
In DB2 Universal Database(TM) (UDB) Version 8.2 FixPak 3 (äquivalent zu Version 8.1 |FixPak 10) ist die neue Musterdatei ibm_db2_sln_upart_smt enthalten. In der folgenden Tabelle sind der Name und die Beschreibung der Musterdatei dargestellt.
| | |Name des Musterscripts | |Dateibeschreibung | |
---|---|
ibm_db2_sln_upart_smt | |Dieses Korn-Shell-Script für die dynamische Rekonfiguration |(DR-Script) unter AIX ermöglicht die Verwendung der DLPAR-Funktionalität (Dynamic Logical Partitioning), die unter AIX Version 5.3 auf POWER5-basierten pSeries(R)-Systemen bereitgestellt wird, wie z. B. auf dem p5-570 und dem p5-590. Dieses Script ähnelt dem DR-Script ibm_db2_sln, ist jedoch für die Unterstützung der Merkmale von POWER5(TM) und AIX Version 5.3 optimiert, wie z. B. für die Mikropartitionierung und für SMT. Weitere Informationen hierzu finden Sie im DR-Script selbst. | |
Das Beispielscript ibm_db2_sln_upart_smt befindet sich in DB2 UDB für AIX im Verzeichnis sqllib/samples/DLPAR.
Details zur Installation finden Sie in der Beschreibung der Linux 2.6-Kernel-Installations-Images in den Release-Informationen für DB2 UDB Version 8.2.2 (Abschnitt Neuheiten in diesem Release).
In den folgenden Tabellen wird die DB2-Unterstützung der Linux-Architektur in FixPak 9 beschrieben. Aktualisierungen für diese Unterstützung finden Sie auf der folgenden Website:
http://www.ibm.com/db2/linux/validate
Varianten | Kernel | Bibliothek | Kommentare |
---|---|---|---|
Conectiva Linux Enterprise Edition (CLEE) | 2.4.19 | glibc 2.2.5 | Powered by United Linux 1.0 |
LINX Rocky Secure Server 2.1 | 2.4.21 | glibc 2.2.5 | |
Red Flag Advanced Server 4.0 | 2.4.21-as.2 | glibc 2.2.93-5 | |
Red Flag Function Server 4.0 | 2.4.20-8smp | glibc 2.2.93-5 | |
Red Hat Enterprise Linux 2.1 AS/ES/WS | 2.4.9-e16 | glibc 2.2.4 | |
Red Hat Enterprise Linux (RHEL) 3 AS/ES/WS | 2.4.21-7.EL | glibc-2.3.2-95.3 | |
Red Hat Enterprise Linux (RHEL) 4 | 2.6.9 | glibc-2.3.3 | Erfordert außerdem das Paket compat-libstdc++-33 |
SCO Linux 4.0 | 2.4.19 | glibc 2.2.5 | Powered by United Linux 1.0 |
SuSE Pro 8.0 | 2.4.18 | glibc 2.2.5 | |
SuSE Pro 8.1 | 2.4.19 | glibc 2.2.5 | |
SuSE Linux Enterprise Server (SLES) 7 | 2.4.7 | glibc 2.2.2 | |
SuSE Linux Enterprise Server (SLES) 8 | 2.4.19 | glibc 2.2.5 | Geprüft bis SuSE Service-Pack 2 |
SuSE Linux Enterprise Server (SLES) 9 | 2.6.5 | glibc-2.3.3 | |
Turbolinux 7 Server | 2.4.9 | glibc 2.2.4 | |
Turbolinux 8 Server | 2.4.18-5 | glibc 2.2.5 | |
Turbolinux Enterprise Server 8 | 2.4.19 | glibc 2.2.5 | |
United Linux 1.0 | 2.4.19 | glibc 2.2.5 |
Varianten | Kernel | Bibliothek | Kommentare |
---|---|---|---|
Red Hat 7.2 | 2.4.9-34 | glibc 2.2.4 | |
Red Hat 7.3 | 2.4.18 | glibc 2.2.5 | |
Red Hat 8.0 | 2.4.18-14 | glibc 2.2.93-5 | |
SuSE 7.3 | 2.4.10 | glibc 2.2.4 |
Varianten | Kernel | Bibliothek | Kommentare |
---|---|---|---|
Red Hat 7.2 | 2.4.9-38 | glibc 2.2.4 | |
Red Hat Enterprise Linux (RHEL) 4 | 2.6.9 | glibc-2.3.3 | Erfordert außerdem das Paket compat-libstdc++-33 |
SuSE Linux Enterprise Server (SLES) 7 | 2.4.7-58 | glibc 2.2.4 | compat.rpm enthält libstdc++ 6.1. Verwenden Sie JDK 1.3.1 SR 1 für Java(TM). |
SuSE Linux Enterprise Server (SLES) 8 | 2.4.19 | glibc 2.2.5 | Powered by United Linux 1.0 |
SuSE Linux Enterprise Server (SLES) 9 | 2.6.5 | glibc-2.3.3 | |
Turbo Linux Enterprise Server (TLES) 8 | 2.4.19 | glibc 2.2.5 | Powered by United Linux 1.0 |
United Linux 1.0 | 2.4.19 | glibc 2.2.5 |
Varianten | Kernel | Bibliothek | Kommentare |
---|---|---|---|
Red Hat Enterprise Linux (RHEL) 3 AS/ES/WS | 2.4.21-7.EL | glibc-2.3.2-95.3 | |
Red Hat Enterprise Linux (RHEL) 4 | 2.6.9 | glibc-2.3.3 | Erfordert außerdem das Paket compat-libstdc++-33 |
SuSE Linux Enterprise Server (SLES) 8.0 | 2.4.19-SMP | glibc 2.2.5-16 | |
SuSE Linux Enterprise Server (SLES) 9 | 2.6.5 | glibc-2.3.3 |
Varianten | Kernel | Bibliothek | Kommentare |
---|---|---|---|
Red Hat Enterprise Linux (RHEL) 3 AS | 2.4.21-7.EL | glibc-2.3.2-95.3 | |
Red Hat Enterprise Linux (RHEL) 4 | 2.6.9 | glibc-2.3.3 | Erfordert außerdem das Paket compat-libstdc++-33 |
SuSE Enterprise Server (SLES) 8 | 2.4.19-16 | glibc 2.2.5 | Powered by United Linux 1.0 |
SuSE Linux Enterprise Server (SLES) 9 | 2.6.5 | glibc-2.3.3 | |
Turbolinux Enterprise Server 8 | 2.4.19-16 | glibc 2.2.5 | Powered by United Linux 1.0 |
United Linux 1.0 | 2.4.19 | glibc 2.2.5 |
Varianten | Kernel | Bibliothek | Kommentare |
---|---|---|---|
Red Hat Enterprise Linux 2.1 AS/ES/WS | 2.4.18-e.12smp | glibc | |
Red Hat Enterprise Linux (RHEL) 3 AS/ES/WS | 2.4.21-7.EL | glibc-2.3.2-95.3 | |
Red Hat Enterprise Linux (RHEL) 4 | 2.6.9 | glibc-2.3.3 | Erfordert außerdem das Paket compat-libstdc++-33 |
SuSE Linux Enterprise Server (SLES) 8 | 2.4.19-SMP | glibc 2.2.5 | Powered by United Linux 1.0 |
SuSE Linux Enterprise Server (SLES) 9 | 2.6.5 | glibc-2.3.3 | |
United Linux 1.0 | 2.4.19 | glibc 2.2.5 |
DB2 UDB für auf dem 2.6-Kernel basierende Linux-Varianten für Intel x86 unterstützt die folgenden Programmiersprachen und Compiler:
Ein 32-Bit-Exemplar für DB2 UDB für auf dem 2.6-Kernel basierende Linux-Varianten für x86-64 unterstützt die folgenden Programmiersprachen und Compiler:
Ein 64-Bit-Exemplar für DB2 UDB für auf dem 2.6-Kernel basierende Linux-Varianten für x86-64 unterstützt die folgenden Programmiersprachen und Compiler:
Die Optionen für das Vorkompilieren und Binden für SQL-Prozeduren können Sie anpassen, indem Sie die im Exemplar gültige DB2-Registrierdatenbankvariable DB2_SQLROUTINE_PREPOPTS mit dem folgenden Befehl setzen:
db2set DB2_SQLROUTINE_PREPOPTS=<optionen>
Außer den Optionen, die in Version 8.2 dokumentiert sind, ist die Option REOPT zulässig:
BLOCKING {UNAMBIG | ALL | NO} DATETIME {DEF | USA | EUR | ISO | JIS | LOC} DEGREE {1 | grad-der-parallelität | ANY} DYNAMICRULES {BIND | RUN} EXPLAIN {NO | YES | ALL} EXPLSNAP {NO | YES | ALL} FEDERATED {NO | YES} INSERT {DEF | BUF} ISOLATION {CS | RR | UR | RS | NC} QUERYOPT optimierungsgrad REOPT {ALWAYS | NONE | ONCE} VALIDATE {RUN | BIND}
Die Compileroption "-m64" ist erforderlich, wenn gcc/g++ zur Erzeugung von C/C++-Anwendungen und -Routinen für ein 64-Bit-Exemplar unter DB2 Universal Database für Linux auf POWER verwendet wird.
Die Compileroption "-q64" ist erforderlich, wenn xlc/xlC zur Erzeugung von C/C++-Anwendungen und -Routinen für ein 64-Bit-Exemplar unter DB2 Universal Database für Linux auf POWER verwendet wird.
Der Kompilierungs- und Bindebefehl in der Dokumentation zu DB2 Universal Database Version 8.2, mit dem gespeicherte Prozeduren in Micro Focus COBOL unter HP-UX erzeugt werden, ist falsch. Der Kompilierungsbefehl in der Prozedur sqllib/samples/cobol_mf/bldrtn ist jedoch richtig. Die Befehle zum Kompilieren und Binden werden nun in einem einzigen Befehl zusammengefasst, wobei mit der Option -y angegeben wird, dass die gewünschte Ausgabe eine gemeinsam genutzte Bibliothek ist.
Vom Micro Focus COBOL-Compiler und von der Micro Focus COBOL-Laufzeitumgebung unter HP-UX wird mindestens die Version Micro Focus Server Express 2.2 - Service Pack 1 mit Fixpack Fixpack22.02_14 für HP-UX PA-RISC 11.x (32/64 Bit) unterstützt. Dieser Fixpack ist auf der Website der Micro Focus Support Line unter http://supportline.microfocus.com verfügbar .
Damit externe Micro Focus COBOL-Routinen unter Windows ausgeführt werden können, müssen die Micro Focus COBOL-Umgebungsvariablen dauerhaft als Systemvariablen gesetzt sein.
Gehen Sie wie folgt vor, um die Umgebungsvariablen als Systemvariablen zu setzen:
Wenn Sie die Umgebungsvariablen in der Liste Benutzervariablen, an der Eingabeaufforderung oder mit einer Prozedur setzen, reicht dies nicht aus.
Die Funktion SQLDescribeParam() gibt die Beschreibung einer Parametermarke zurück, die einer vorbereiteten SQL-Anweisung zugeordnet ist.
|Bei SQLSTATE HYC00 wurde die Diagnosetabelle aktualisiert.
|SQLSTATE-Wert | |Beschreibung | |Erläuterung | |
---|---|---|
HYC00 | |Treiber ist nicht funktionsfähig. | |Die gespeicherten Prozeduren der Schemafunktion sind auf dem Server nicht zugänglich. |Installieren Sie die gespeicherten Prozeduren der Schemafunktion auf dem Server, und stellen Sie sicher, dass sie zugänglich sind. | |
Die DB2 CLI (DB2 Call Level Interface) kann eine Untermenge von Funktionen asynchron ausführen. |Der DB2 CLI-Treiber gibt die Steuerung nach dem Aufruf der Funktion, jedoch vor der Beendung ihrer Ausführung, an die Anwendung zurück. Die Funktion gibt bei jedem Aufruf SQL_STILL_EXECUTING zurück, bis ihre Ausführung beendet ist. Danach gibt sie einen anderen Wert zurück (z. B. SQL_SUCCESS).
|Die asynchrone Ausführung ist nur unter Single-Thread-Betriebssystemen von Vorteil. Anwendungen, die unter Multithread-Betriebssystemen ausgeführt werden, sollten Funktionen in separaten Threads ausführen. Die asynchrone Ausführung ist für diejenigen Funktionen möglich, die normalerweise eine Anforderung an den Server senden und anschließend auf eine Antwort warten. Statt zu warten, gibt eine asynchron ausgeführte Funktion die Steuerung an die Anwendung zurück. Die Anwendung kann anschließend andere Tasks ausführen, oder sie kann die Steuerung an das Betriebssystem zurückgeben und die Funktion mit Hilfe eines Interrupts wiederholt abfragen, bis ein anderer Rückkehrcode als SQL_STILL_EXECUTING zurückgegeben wird.
|Die Unterstützung für eine asynchrone Ausführung der CLI ist ab Version 8.2 FixPak 1 (äquivalent zu Version 8.1 FixPak 8) in DB2 Universal Database (UDB) enthalten. Die Dokumentation zu dieser Funktion finden Sie unter der URL-Adresse http://publib.boulder.ibm.com/infocenter/db2v7luw/index.jsp in Information - Unterstützung für DB2 UDB Version 7. Alle Informationen in der Dokumentation zu Version 7 gelten für Versionen ab Version |8.2 FixPak 1 (äquivalent zu Version 8.1 FixPak 8). Information - Unterstützung für DB2 Version |8 enthält keine Dokumentation zu dieser Funktion.
| | |SQL_ATTR_PING_DB ist eine 32-Bit-Ganzzahl, die mit der Funktion SQLGetConnectAttr() verwendet wird, um die Antwortzeit des Netzwerks bei einer vorhandenen Verbindung zwischen dem DB2 UDB-Client und dem DB2 UDB-Server abzurufen. Die Antwortzeit wird in Mikrosekunden zurückgemeldet.
|Wenn die Datenbank vorher eine Verbindung hergestellt und diese freigegeben hat, wird der Wert 0 zurückgemeldet. Wenn die Verbindung von der Anwendung geschlossen wurde, wird der SQLSTATE-Wert 08003 zurückgemeldet. Dieses Verbindungsattribut kann von SQLGetConnectAttr() zurückgegeben werden, Es kann jedoch nicht mit Hilfe von SQLSetConnectAttr() gesetzt werden. |Wenn Sie versuchen, dieses Attribut festzulegen, wird der SQLSTATE-Wert HYC00 (Treiber ist nicht funktionsfähig) zurückgegeben.
In der Dokumentation zur Funktion SQLBindParameter ist die Beschreibung im Abschnitt zum Eingabeparameter falsch. Die richtige Beschreibung muss wie folgt lauten:
|In der Dokumentation zur Funktion SQLMoreResults ist das Anweisungsattribut SQL_ATTR_ROW_ARRAY_SIZE falsch angegeben. Das richtige Anweisungsattribut muss SQL_ATTR_PARAMSET_SIZE lauten. Der Abschnitt zur Verwendung muss wie folgt lauten:
|Diese Funktion gibt mehrere Ergebnismengen sequenziell zurück, wenn Folgendes ausgeführt wird:
|Die folgenden Attribute sind CLI-Verbindungsattribute und werden außerdem als CLI-Umgebungsattribute unterstützt:
Informationen zu diesen Attributen finden Sie in der Dokumentation zu den CLI-Verbindungsattributen in DB2 Information - Unterstützung oder in CLI Guide and Reference Volume 2.
Zum Aktualisieren und Löschen von Zeilen in der Ergebnismenge eines dynamischen verschiebbaren Cursors muss die Anweisung UPDATE oder DELETE alle Spalten von mindestens einem eindeutigen Schlüssel in der Basistabelle einschließen. Dies kann der Primärschlüssel oder ein beliebiger anderer eindeutiger Schlüssel sein.
| | |Beispiel: Die Katalogfunktion SQLTables() gibt eine Ergebnismenge zurück, in der die Werte für die Spalte TABLE_CAT Nullwerte sind. Wenn der Wert für |RetCatalogAsCurrServer auf 1 gesetzt wird, gibt das DBMS den Wert für CURRENT SERVER in der Spalte TABLE_CAT zurück.
| | |db2 bind db2clipk.bnd collection NULLIDR1 db2 bind db2clipk.bnd collection NULLIDRAWenn sowohl das Schlüsselwort Reopt als auch das Schlüsselwort CurrentPackageSet angegeben sind, hat CurrentPackageSet Vorrang.
db2 bind db2clipk.bnd collection NULLIDR1 db2 bind db2clipk.bnd collection NULLIDRASQL_ATTR_REOPT und SQL_ATTR_CURRENT_PACKAGE_SET schließen sich gegenseitig aus. Wenn also eines dieser Attribute gesetzt ist, ist das andere Attribut nicht zulässig.
Diese Option setzt die SQL-Anweisung SET CURRENT PACKAGESET mit dem Wert CurrentPackageSet ab, sobald eine Verbindung zu einer Datenbank hergestellt wurde. Die Klausel ist standardmäßig nicht angehängt.
Die SQL-Anweisung SET CURRENT PACKAGESET legt den Schemanamen (Objektgruppen-ID) fest, mit dem das Paket für nachfolgende SQL-Anweisungen ausgewählt wird.
CLI/ODBC-Anwendungen setzen dynamische SQL-Anweisungen ab. Mit dieser Option können Sie die Zugriffsrechte steuern, mit denen diese Anweisungen ausgeführt werden:
Die SQL-Anweisungen in den CLI/ODBC-Anwendungen werden jetzt unter dem angegebenen Schema ausgeführt und verwenden die dort definierten Zugriffsrechte.
Die folgenden Paketsatznamen sind reserviert: "NULLID", "NULLIDR1", "NULLIDRA".
Wenn sowohl das Schlüsselwort Reopt als auch das Schlüsselwort CurrentPackageSet angegeben sind, hat CurrentPackageSet Vorrang.
CLI/ODBC-Anwendungen setzen dynamische SQL-Anweisungen ab. Mit diesem Verbindungsattribut können Sie die Zugriffsrechte steuern, mit denen diese Anweisungen ausgeführt werden:
Die SQL-Anweisungen in den CLI/ODBC-Anwendungen werden jetzt unter dem angegebenen Schema ausgeführt und verwenden die dort definierten Zugriffsrechte.
Das Setzen des CLI/ODBC-Konfigurationsschlüsselworts CURRENTPACKAGESET ist eine alternative Methode zur Angabe des Schemanamens.
Die folgenden Paketsatznamen sind reserviert: "NULLID", "NULLIDR1", "NULLIDRA".
SQL_ATTR_REOPT und SQL_ATTR_CURRENT_PACKAGE_SET schließen sich gegenseitig aus. Wenn also eines dieser Attribute gesetzt ist, ist das andere Attribut nicht zulässig.
MapBigintCDefault steuert den C-Typ, der verwendet wird, wenn SQL_C_DEFAULT für BIGINT-Spalten und für BIGINT-Parametermarken angegeben wird. Dieses Schlüsselwort sollte vor allem für Microsoft-Anwendungen eingesetzt werden, z. B. für die Anwendung Microsoft Access, die keine 8-Byte-Ganzzahlen verarbeiten kann. Setzen Sie MapBigintCDefault wie folgt:
Dieses Kennwort wirkt sich auf das Verhalten von CLI-Funktionen aus, bei denen SQL_C_DEFAULT als C-Typ angegeben werden kann, z. B. SQLBindParameter(), SQLBindCol() und SQLGetData().
Dieses Schlüsselwort steuert die Datenmenge, die der CLI-Treiber bei einer PREPARE- oder DESCRIBE-Anforderung anfordert. Standardmäßig gibt der Server bei Empfang einer DESCRIBE-Anforderung die Informationen zurück, die in Stufe 2 der Tabelle 25 für die Ergebnismengenspalten aufgelistet sind. Möglicherweise benötigt eine Anwendung jedoch nicht alle Informationen, oder sie benötigt zusätzliche Informationen.
Wenn das Schlüsselwort DescribeOutputLevel auf eine Stufe gesetzt wird, die dem Bedarf der Clientanwendung entspricht, wird möglicherweise die Leistung gesteigert, da die zwischen dem Client und dem Server übertragenen DESCRIBE-Daten auf die Mindestmenge begrenzt sind, die für die Anwendung erforderlich ist. Wenn DescribeOutputLevel auf einen zu niedrigen Wert gesetzt wird, kann sich dies auf die Funktionalität der Anwendung auswirken (in Abhängigkeit von den Anforderungen der Anwendung). Die CLI-Funktionen zum Abrufen der DESCRIBE-Informationen schlagen in diesem Fall möglicherweise nicht fehl, die zurückgegebenen Daten sind jedoch möglicherweise unvollständig.
Folgende Einstellungen für DescribeOutputLevel werden unterstützt:
In der folgenden Tabelle sind die Felder aufgeführt, aus denen die DESCRIBE-Informationen bestehen, die der Server bei Empfang einer PREPARE- oder DESCRIBE-Anforderung zurückgibt. Diese Felder werden in Stufen gruppiert, und das Schlüsselwort DescribeOutputLevel für die CLI/ODBC-Konfiguration steuert, welche Stufen von DESCRIBE-Informationen der CLI-Treiber anfordert.
Stufe 1 | Stufe 2 | Stufe 3 |
---|---|---|
SQL_DESC_COUNT SQL_COLUMN_COUNT SQL_DESC_TYPE SQL_DESC_CONCISE_TYPE SQL_COLUMN_LENGTH SQL_DESC_OCTET_LENGTH SQL_DESC_LENGTH SQL_DESC_PRECISION SQL_COLUMN_PRECISION SQL_DESC_SCALE SQL_COLUMN_SCALE SQL_DESC_DISPLAY_SIZE SQL_DESC_NULLABLE SQL_COLUMN_NULLABLE SQL_DESC_UNSIGNED SQL_DESC_SEARCHABLE SQL_DESC_LITERAL_SUFFIX SQL_DESC_LITERAL_PREFIX SQL_DESC_CASE_SENSITIVE SQL_DESC_FIXED_PREC_SCALE |
Alle Felder der Stufe 1 und: SQL_DESC_NAME SQL_DESC_LABEL SQL_COLUMN_NAME SQL_DESC_UNNAMED SQL_DESC_TYPE_NAME SQL_DESC_DISTINCT_TYPE SQL_DESC_REFERENCE_TYPE SQL_DESC_STRUCTURED_TYPE SQL_DESC_USER_TYPE SQL_DESC_LOCAL_TYPE_NAME SQL_DESC_USER_DEFINED_ TYPE_CODE |
Alle Felder der Stufen 1 und 2 und: SQL_DESC_BASE_COLUMN_NAME SQL_DESC_UPDATABLE SQL_DESC_AUTO_UNIQUE_VALUE SQL_DESC_SCHEMA_NAME SQL_DESC_CATALOG_NAME SQL_DESC_TABLE_NAME SQL_DESC_BASE_TABLE_NAME |
Java-Anwendungen, die über die DB2 Universal JDBC-Treiber Type 4-Konnektivität auf DB2 UDB für z/OS(R)-Server zugreifen, können die zugehörigen Verbindungskonzentrator- und Sysplex-Funktionen für den Lastausgleich nutzen.
|Diese Funktionen ähneln den Verbindungskonzentrator- und Sysplex-Funktionen für Lastausgleich von DB2 Connect.
|Der Verbindungskonzentrator für den DB2 Universal JDBC-Treiber kann die Ressourcen reduzieren, die DB2 |UDB für z/OS-Datenbankserver zur Unterstützung einer großen Anzahl Clientanwendungen benötigen. Dies geschieht, indem viele Verbindungsobjekte dieselbe physische Verbindung verwenden dürfen. Dadurch verringert sich die Gesamtzahl physischer Verbindungen zum Datenbankserver.
|Der Sysplex-Lastausgleich für DB2 Universal JDBC-Treiber kann die Verfügbarkeit einer Gruppe mit gemeinsamer Datennutzung verbessern, da der Treiber häufige Statusinformationen zu den Mitgliedern einer solchen Gruppe erhält. Der Treiber bestimmt anhand dieser Informationen das Mitglied der Gruppe mit gemeinsamer Datennutzung, an das die nächste Transaktion weitergeleitet werden soll. Über den Sysplex-Lastausgleich stellen der DB2 UDB für z/OS-Server und der Workload Manager für z/OS (WLM) sicher, dass die Last zwischen Mitgliedern der Gruppe mit gemeinsamer Datennutzung effizient verteilt und dass die Last bei Ausfall eines Mitglieds einer Gruppe mit gemeinsamer Datennutzung an die anderen Mitglieder dieser Gruppe übertragen wird.
|Der DB2 Universal JDBC-Treiber verwendet Transportobjekte und einen globalen Transportobjektpool, damit der Verbindungskonzentrator- und Sysplex-Lastausgleich unterstützt wird. Für jede physische Verbindung zum Datenbankserver gibt es ein einziges Transportobjekt. |Wenn Sie den Verbindungskonzentrator- und Sysplex-Lastausgleich aktivieren, können Sie die maximale Anzahl physischer Verbindungen zum Datenbankserver zu einem beliebigen Zeitpunkt festlegen, indem Sie die maximale Anzahl Transportobjekte festlegen.
|Für die Anzahl Transportobjekte legen Sie auf Treiberebene mit Hilfe der Konfigurationsmerkmale des DB2 Universal JDBC-Treibers Grenzen fest.
|Auf Verbindungsebene aktivieren und inaktivieren Sie für den DB2 Universal JDBC-Treiber den Verbindungskonzentrator- und Sysplex-Lastausgleich und legen Grenzen für die Anzahl Transportobjekte fest. Dazu verwenden Sie die DataSource-Merkmale.
|Sie können den globalen Transportobjektpool auf eine der folgenden Arten überwachen:
|Jedes der folgenden Konfigurationsmerkmale wird für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet.
|Der Datentyp von db2.jcc.dumpPool ist eine ganze Zahl (int.). Die Konfigu- |rationsmerkmale db2.jcc.dumpPoolStatisticsOnSchedule |und db2.jcc.dump- |PoolStatisticsOnScheduleFile müssen für das Schreiben von Statistiken eben- |falls festgelegt werden, noch bevor Statistiken geschrieben werden.
|Sie können für das Merkmal db2.jcc.dumpPool folgende Statistiktypen angeben:
|Wenn Sie einen Trace für mehrere Ereignistypen durchführen möchten, fügen Sie die Werte für diese Ereignistypen hinzu. Nehmen Sie z. B. einmal an, Sie möchten einen Trace für die Ereignisse DUMP_GET_OBJECT und DUMP_CREATE_OBJECT durchführen. Die numerischen Entsprechungen dieser Werte sind 2 und 16. Also geben Sie als Wert für db2.jcc.dumpPool die Zahl 18 an.
|Der Standardwert ist 0, d. h., für den globalen Transportpool werden nur Zusammenfassungstatistiken geschrieben.
|Der Standardwert lautet -1, d. h., die Statistikdaten für den globalen Transportpool werden nicht überschrieben.
|Wenn das Konfigurationsmerkmal db2.jcc.dumpPoolStatisticsOnScheduleFile nicht angegeben ist, werden die Statistikdaten für den globalen Transportpool nicht geschrieben.
|Der Standardwert für das Konfigurationsmerkmal db2.jcc.maxTransportObjectIdleTime beträgt 60. Wenn Sie das Konfigurationsmerkmal b2.jcc.maxTransportObjectIdleTime auf einen Wert unter 0 setzen, werden nicht verwendete Transportobjekte sofort aus dem Pool gelöscht. Diese Aktion wird nicht empfohlen, da sie hohe Leistungseinbußen verursachen kann.
|Der Standardwert für das Konfigurationsmerkmal db2.jcc.maxTransportObjectWaitTime beträgt -1. Ein negativer Wert bedeutet, dass Anwendungen unbegrenzte Zeit warten.
|Der Standardwert für das Konfigurationsmerkmal db2.jcc.maxTransportObjects beträgt -1. Dies bedeutet, dass es für die Anzahl Transportobjekte im globalen Transportobjektpool keinen Grenzwert gibt.
|Der Standardwert für das Konfigurationsmerkmal db2.jcc.minTransportObjects beträgt 0. Alle Werte kleiner-gleich 0 bedeuten, dass der globale Transportobjektpool leer werden kann.
|Jedes der folgenden DataSource-Merkmale für den DB2 Universal JDBC-Treiber wird für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet.
|Der Datentyp des Merkmals enableConnectionConcentrator ist Boolean. Der Standardwert ist false. Wenn jedoch enableSysplexWLB auf true gesetzt ist, lautet der Standardwert true.
|Der Datentyp des Merkmals enableSysplexWLB ist Boolean. Der Standardwert ist false. Wenn enableSysplexWLB jedoch auf true gesetzt ist, wird enableConnectionConcentrator standardmäßig auf true gesetzt.
|Der Datentyp dieses Merkmals ist eine ganze Zahl (int.).
|Wenn der Wert für maxTransportObjects nicht erreicht wurde und wenn im globalen Transportobjektpool kein Transportobjekt verfügbar ist, erstellt der Pool ein neues Transportobjekt. Wenn der Wert für maxTransportObjects erreicht ist, wartet die Anwendung während der Zeitspanne, die im Konfigurationsmerkmal db2.jcc.maxTransportObjectWaitTime angegeben ist. Wenn diese Zeitspanne vorbei ist und im Pool immer noch kein Transportobjekt verfügbar ist, löst der Pool eine SQLException aus.
|Das Merkmal maxTransportObjects überschreibt das Konfigurationsmerkmal db2.jcc.maxTransportObjects nicht. Das Merkmal maxTransportObjects wirkt sich nicht auf Verbindungen von anderen DataSource-Objekten aus. |Wenn der Wert für maxTransportObjects größer ist als der Wert für db2.jcc.maxTransportObjects, erhöht der Wert für maxTransportObjects den Wert für db2.jcc.maxTransportObjects nicht.
|Der Standardwert für das Merkmal maxTransportObjects beträgt -1. Dies bedeutet, dass die Anzahl der Transportobjekte für DataSource nur durch |den Wert für db2.jcc.maxTransportObjects für den Treiber begrenzt wird.
|Die folgende Vorgehensweise ist ein Beispiel für die Aktivierung der Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion für den DB2 Universal JDBC-Treiber bei WebSphere(R) Application Server.
|Servervoraussetzungen:
|Clientvoraussetzungen:
|Gehen Sie wie folgt vor, um die Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion für den DB2 Universal JDBC-Treiber bei WebSphere Application Server zu aktivieren:
|java com.ibm.db2.jcc.DB2Jcc -versionSuchen Sie in der Ausgabe eine Zeile ähnlich der Folgenden: |
[ibm][db2][jcc] Driver: IBM DB2 JDBC Universal Driver Architecture n nDabei steht n für eine Versionsnummer ab 2.7.
Legen Sie die Konfigurationsmerkmale in der Datei DB2JccConfiguration.properties fest.
|db2.jcc.minTransportObjects=0 |db2.jcc.maxTransportObjects=1500 |db2.jcc.maxTransportObjectWaitTime=-1 |db2.jcc.dumpPool=0 |db2.jcc.dumpPoolStatisticsOnScheduleFile= | /home/WAS/logs/srv1/poolstats
Legen Sie in der WebSphere Application Server-Verwaltungskonsole die folgenden Merkmale für die Datenquelle fest, die die Anwendung zum Herstellen der Verbindung zum Datenbankserver verwendet:
|Zur Überwachung der Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion für den DB2 Universal JDBC-Treiber müssen Sie den globalen Transportobjektpool überwachen. Sie können den globalen Transportobjektpool auf eine der folgenden Arten überwachen:
|Die Konfigurationsmerkmale db2.jcc.dumpPool, db2.jcc.dumpPoolStatisticsOnSchedule und db2.jcc.dumpPoolStatisticsOnScheduleFile steuern die Traceverarbeitung des globalen Transportobjektpools.
|Zum Beispiel führen die folgenden Konfigurationsmerkmale dazu, dass Sysplex-Fehlernachrichten und Nachrichten über Speicherauszugspoolfehler alle 60 Sekunden in eine Datei mit dem Namen /home/WAS/logs/srv1/poolstats geschrieben werden:
|db2.jcc.dumpPool=DUMP_SYSPLEX_MSG|DUMP_POOL_ERROR |db2.jcc.dumpPoolStatisticsOnSchedule=60 |db2.jcc.dumpPoolStatisticsOnScheduleFile=/home/WAS/logs/srv1/poolstats|
Ein Eintrag in der Poolstatistikdatei sieht wie folgt aus:
|uhrzeit Scheduled PoolStatistics npr:2575 nsr:2575 lwroc:439 |hwroc:1764 coc:372 aooc:362 rmoc:362 nbr:2872 tbt:857520 tpo:10
Die Felder haben die folgenden Bedeutungen:
|Sie können Anwendungen schreiben, um Statistikdaten zum globalen Transportobjektpool zu erfassen. Derartige Anwendungen erstellen Objekte in der Klasse DB2PoolMonitor und rufen Daten zum Pool mit Hilfe von Methoden ab.
|Der folgenden Code erstellt z. B. ein Objekt zur Überwachung des globalen Transportobjektpools:
|import com.ibm.db2.jcc.DB2PoolMonitor; |DB2PoolMonitor transportObjectPoolMonitor = | DB2PoolMonitor.getPoolMonitor (DB2PoolMonitor.TRANSPORT_OBJECT);|
Nach der Erstellung des DB2PoolMonitor-Objekts können Sie die folgenden Methoden verwenden, um den globalen Transportobjektpool zu überwachen.
|public int getMonitorVersion()|
Ruft die Version der DB2PoolMonitor-Klasse ab, die mit dem DB2 Universal JDBC-Treiber ausgeliefert wird.
|public int totalRequestsToPool()|
Ruft die Gesamtzahl der Anforderungen ab, die der DB2 Universal JDBC-Treiber seit der Poolerstellung an den Pool gesendet hat.
|public int successfullRequestsFromPool()|
Ruft die Anzahl erfolgreicher Anforderungen ab, die der DB2 Universal JDBC-Treiber seit der Poolerstellung an den Pool gesendet hat. Eine erfolgreiche Anforderung bedeutet, dass der Pool ein Objekt zurückgegeben hat.
|public int numberOfRequestsBlocked()|
Ruft die Anzahl der Anforderungen ab, die der DB2 Universal JDBC-Treiber an den Pool gesendet hat und die der Pool wegen bereits belegter maximaler Kapazität blockiert hat. Eine blockierte Anforderung kann erfolgreich sein, falls ein Objekt an den Pool zurückgegeben wird, bevor der Konfigurationswert für db2.jcc.maxTransportObjectWaitTime überschritten und eine Ausnahmebedingung ausgelöst wird.
|public long totalTimeBlocked()|
Ruft die Gesamtzeit in Millisekunden ab, während der der Pool Anforderungen blockiert hat. Wenn die Anwendung mehrere Threads verwendet, kann diese Zeitdauer viel größer sein als die Ausführungszeit der Anwendung.
|public int lightWeightReusedObjectCount()|
Ruft die Anzahl der Objekte ab, die wiederverwendet wurden, jedoch nicht im Pool waren. Dieser Fall kann eintreten, wenn ein Verbindungsobjekt an einer Transaktionsgrenze ein Transportobjekt freigibt. Wenn das Verbindungsobjekt später ein Transportobjekt benötigt und wenn das ursprüngliche Transportobjekt von keinem anderen Verbindungsobjekt verwendet wurde, kann das Verbindungsobjekt dieses Transportobjekt verwenden.
|public int heavyWeightReusedObjectCount()|
Ruft die Anzahl der Objekte ab, die aus dem Pool wiederverwendet wurden.
|public int createdObjectCount()|
Ruft die Anzahl der seit der Poolerstellung vom DB2 Universal JDBC-Treiber erstellten Objekte ab.
|public int agedOutObjectCount()|
Ruft die Anzahl der Objekte ab, die die im Konfigurationsmerkmal db2.jcc.maxTransportObjectIdleTime angegebene Leerlaufzeit überschritten haben und aus dem Pool gelöscht wurden.
|public int removedObjectCount()|
Ruft die Anzahl der Objekte ab, die seit der Poolerstellung aus dem Pool gelöscht wurden.
|public int totalPoolObjects()|
Anzahl der Objekte, die sich momentan im Pool befinden.
|Das Schlüsselwort OleDbReportIsLongForLongTypes wird für die folgenden Datenbankserver unterstützt:
CCE (Client Cursor Engine) von OLE DB und CommandBuilder von OLE DB .NET Data Provider generieren Aktualisierungs- und Löschanweisungen auf der Basis von Spalteninformationen, die von IBM DB2 OLE DB Provider bereitgestellt werden. Wenn die generierte Anweisung in der WHERE-Klausel einen LONG-Typ enthält, schlägt die Anweisung fehl, da LONG-Typen bei einer Suche mit Gleichheitsoperator nicht verwendet werden können. Wenn Sie das Schlüsselwort OleDbReportIsLongForLongTypes auf 1 setzen, meldet IBM DB2 OLE DB Provider LONG-Typen (LONG VARCHAR, LONG VARCHAR FOR BIT DATA, LONG VARGRAPHIC und LONG VARGRAPHIC FOR BIT DATA) über das gesetzte Flag DBCOLUMNFLAGS_ISLONG zurück. Dadurch wird verhindert, dass die Spalten mit LONG-Typen in der WHERE-Klausel verwendet werden.
Das Schlüsselwort OleDbSQLColumnsSortByOrdinal wird von den folgenden Datenbankservern unterstützt:
Die Microsoft OLE DB-Spezifikation erfordert, dass IDBSchemaRowset::GetRowset(DBSCHEMA_COLUMNS) die Zeilengruppe nach den Spalten TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME und COLUMN_NAME sortiert zurückgibt. IBM DB2 OLE DB Provider entspricht der Spezifikation. Allerdings wurden Anwendungen, die den Microsoft ODBC Bridge-Provider (MSDASQL) verwenden, normalerweise so codiert, dass die Zeilengruppe nach ORDINAL_POSITION sortiert wird. Wenn Sie das Schlüsselwort OleDbSQLColumnsSortByOrdinal auf 1 setzen, gibt der Provider eine Zeilengruppe zurück, die nach ORDINAL_POSITION sortiert ist.
IBM DB2 OLE DB Provider hat eine neue Eigenschaftsgruppe hinzugefügt: DB2 Data Source. Diese Eigenschaftsgruppe für DB2 Data Source ist DBPROPSET_DB2DATASOURCE.
Die GUID für die Eigenschaftsgruppe lautet wie folgt: {0x8a80412a,0x7d94,0x4fec,{0x87,0x3e,0x6c,0xd1,0xcd,0x42,0x0d,0xcd}}
DBPROPSET_DB2DATASOURCE weist drei Merkmale auf:
#define DB2PROP_REPORTISLONGFORLONGTYPES 4 Eigenschaftsgruppe: DB2 Data Source Eigenschaftsset: DB2PROPSET_DATASOURCE Typ: VT_BOOL Typischer Schreib-/Lesezugriff: R/W Beschreibung: IsLong für LONG-Typen zurückmelden
CCE (Client Cursor Engine) von OLE DB und CommandBuilder von OLE DB .NET Data Provider generieren Aktualisierungs- und Löschanweisungen auf der Basis von Spalteninformationen, die von IBM DB2 OLE DB Provider bereitgestellt werden. Wenn die generierte Anweisung in der WHERE-Klausel einen LONG- Typ enthält, schlägt die Anweisung fehl, da LONG-Typen bei einer Suche mit Gleichheitsoperator nicht verwendet werden können.
Werte | Bedeutung |
---|---|
VARIANT_TRUE | IBM DB2 OLE DB Provider meldet LONG-Typen (LONG VARCHAR, LONG VARCHAR FOR BIT DATA, LONG VARGRAPHIC und LONG VARGRAPHIC FOR BIT DATA) über das gesetzte Flag DBCOLUMNFLAGS_ISLONG zurück. Dadurch wird verhindert, dass die Spalten mit LONG-Typen in der WHERE-Klausel verwendet werden. |
VARIANT_FALSE | DBCOLUMNFLAGS_ISLONG ist für LONG VARCHAR, LONG VARCHAR FOR BIT DATA, LONG VARGRAPHIC und LONG VARGRAPHIC FOR BIT DATA nicht gesetzt. Dies ist der Standardwert. |
#define DB2PROP_RETURNCHARASWCHAR 2 Eigenschaftsgruppe: DB2 Data Source Eigenschaftsset: DB2PROPSET_DATASOURCE Typ: VT_BOOL Typischer Schreib-/Lesezugriff: R/W Beschreibung: Char als WChar zurückgeben
Werte | Bedeutung |
---|---|
VARIANT_TRUE | OLE DB beschreibt Spalten des Typs CHAR, VARCHAR, LONG VARCHAR oder CLOB als DBTYPE_WSTR. Die Codepage der in ISequentialStream implizierten Daten ist UCS-2. Dies ist der Standardwert. |
VARIANT_FALSE | OLE DB beschreibt Spalten des Typs CHAR, VARCHAR, LONG VARCHAR oder CLOB als DBTYPE_STR. Die Codepage der in ISequentialStream implizierten Daten ist die lokale Codepage des Clients. |
#define DB2PROP_SORTBYORDINAL 3 Eigenschaftsgruppe: DB2 Data Source Eigenschaftsset: DB2PROPSET_DATASOURCE Typ: VT_BOOL Typischer Schreib-/Lesezugriff: R/W Beschreibung: Nach Ordinalzahl sortieren
Die Microsoft OLE DB-Spezifikation erfordert, dass IDBSchemaRowset::GetRowset(DBSCHEMA_COLUMNS) die Zeilengruppe nach den Spalten TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME und COLUMN_NAME sortiert zurückgibt. IBM DB2 OLE DB Provider entspricht der Spezifikation. Allerdings wurden Anwendungen, die den Microsoft ODBC Bridge-Provider (MSDASQL) verwenden, normalerweise so codiert, dass die Zeilengruppe nach ORDINAL_POSITION sortiert wird.
Werte | Bedeutung |
---|---|
VARIANT_TRUE | Der Provider gibt eine Zeilengruppe zurück, die nach ORDINAL_POSITION sortiert ist. |
VARIANT_FALSE | Der Provider gibt eine Zeilengruppe zurück, die nach TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME und COLUMN_NAME sortiert ist. Dies ist der Standardwert. |
Im Thema "Installieren des allgemeinen DB2-Treibers", ist im Syntaxdiagramm für DB2Binder die URL-Syntax für den allgemeinen DB2-JDBC-Treiber falsch definiert. Die richtige Darstellung der URL-Syntax für DB2Binder sehen Sie im folgenden Diagramm:
Die Funktion für automatische Clientweiterleitung in DB2 Universal Database (UDB) für Linux, UNIX und Windows ermöglicht die Wiederherstellung von Clientanwendungen, nachdem die Verbindung zum Server unterbrochen wurde, so dass die Anwendungen nach minimaler Ausfallzeit weiterarbeiten können.
Immer wenn ein Server gesperrt wird, empfängt jeder Client, der mit diesem Server verbunden ist, einen Kommunikationsfehler, der die Verbindung beendet und zu einem Anwendungsfehler führt. Wenn die Verfügbarkeit wichtig ist, sollte eine redundante Installation oder eine Funktionsübernahme eingerichtet sein. (Die Funktionsübernahme ist die Fähigkeit des Servers, bei einem Ausfall eines anderen Servers dessen Aufgaben zu übernehmen.) In jedem Fall versucht der Client mit dem DB2 Universal JDBC-Treiber, die Verbindung zu einem neuen Server oder zum ursprünglichen Server wiederherzustellen, der möglicherweise auf einem Knoten mit Funktionsübernahme aktiv ist. Wenn die Verbindung wiederhergestellt wird, empfängt die Anwendung eine SQL-Ausnahmebedingung, die ihr das Fehlschlagen der Transaktion mitteilt, die Anwendung kann jedoch mit der nächsten Transaktion fortfahren.
Nachdem der Datenbankadministrator den alternativen Serverstandort für eine bestimmte Datenbank im Serverexemplar angegeben hat, werden die Positionen des primären und des alternativen Servers beim Verbindungsaufbau an den Client zurückgegeben. Der DB2 Universal JDBC-Treiber erstellt ein Exemplar des referenzierbaren Objekts DB2ClientRerouteServerList und speichert dieses in seinem Übergangsspeicher. Bei einem Kommunikationsausfall versucht der DB2 Universal JDBC-Treiber, die Verbindung unter Verwendung der vom Server zurückgegebenen Serverinformationen wieder herzustellen.
Das DataSource-Merkmal clientRerouteServerListJNDIName stellt auf dem Client zusätzliche Unterstützung für die Clientweiterleitung zur Verfügung; clientRerouteServerListJNDIName hat die folgenden zwei Funktionen:
clientRerouteServerListJNDIName gibt eine JNDI-Referenz zu einem DB2ClientRerouteServerList-Exemplar in einem JNDI-Repository für Daten zu alternativen Server an. Nach erfolgreicher Herstellung der Verbindung zum primären Server werden die Daten zum alternativen Server, die von clientRerouteServerListJNDIName zur Verfügung gestellt werden, mit den Daten vom Server überschrieben. Der DB2 Universal JDBC-Treiber versucht, die aktualisierten Daten nach der Funktionsübernahme an den JNDI-Speicher weiterzugeben, falls das Merkmal clientRerouteServerListJNDIName definiert ist. Wenn clientRerouteServerListJNDIName angegeben ist, werden für die Verbindung zum primären Server Informationen verwendet, die in DB2ClientRerouteServerList angegeben sind. Wenn der primäre Server nicht angegeben ist, werden die serverName-Informationen verwen- det, die auf der Datenquelle angegeben sind.
DB2ClientRerouteServerList ist eine serialisierbare JavaBean mit den folgenden vier Merkmalen:
Getter- und Setter-Methoden zum Zugriff auf diese Merkmale werden zur Verfügung gestellt. Die Definition der Klasse DB2ClientRerouteServerList lautet wie folgt:
package com.ibm.db2.jcc; public class DB2ClientRerouteServerList implements java.io.Serializable, javax.naming.Referenceable { public String[] alternateServerName; public synchronized void setAlternateServerName(String[] alternateServer); public String[] getAlternateServerName(); public int[] alternatePortNumber; public synchronized void setAlternatePortNumber(int[] alternatePortNumberList); public int[] getAlternatePortNumber(); public synchronized void setPrimaryServerName (String primaryServerName); public String getPrimaryServerName (); public synchronized void setPrimaryPortNumber (int primaryPortNumber) public int getPrimaryPortNumber (); }
Eine neue hergestellte Verbindung für Funktionsübernahme wird mit den ursprünglichen Datenquellenmerkmalen konfiguriert, mit Ausnahme des Servernamens und der Portnummer. Außerdem werden alle DB2 UDB-Sonderregister, die bei der ursprünglichen Verbindung modifiziert worden sind, in der Funktionsübernahmeverbindung vom DB2 Universal JDBC-Treiber wiederhergestellt.
Bei einem Kommunikationsausfall versucht der DB2 Universal JDBC-Treiber zuerst eine Wiederherstellung für den primären Server auszuführen. Sollte dies fehlschlagen, versucht der Treiber, eine Verbindung zur alternativen Position (Funktionsübernahme) herzustellen. Nachdem erneut eine Verbindung hergestellt worden ist, sendet der Treiber eine java.sql.SQLException mit dem SQLCODE-Wert -4498 an die Anwendung, wodurch der Anwendung angezeigt wird, dass automatisch eine Verbindung zum alternativen Server wiederhergestellt worden ist. Die Anwendung kann anschließend die Transaktion wiederholen.
Gehen Sie wie folgt vor, um Speicher so zu konfigurieren, dass DB2ClientRerouteServerList persistent festgelegt wird:
// Startkontext für Namensoperationen erstellen InitialContext registry = new InitialContext(); // DB2ClientRerouteServerList-Objekt erstellen DB2ClientRerouteServerList address=new DB2ClientRerouteServerList(); // Portnummer und Servernamen für primären Server setzen address.setPrimaryPortNumber(50000); address.setPrimaryServerName("mvs1.sj.ibm.com"); // Portnummer und Servernamen für alternativen Server setzen int[] port = {50002}; String[] server = {"mvs3.sj.ibm.com"}; address.setAlternatePortNumber(port); address.setAlternateServerName(server); registry.rebind("serverList", address);
datasource.setClientRerouteServerListJNDIName("serverList");
Über die Merkmale der DB2 Universal JDBC-Treiberkonfiguration können Sie Merkmalwerte setzen, die für den gesamten Treiber gelten. Diese Einstellungen werden anwendungsübergreifend und DataSource-Exemplar-übergreifend angewendet. Sie können die Einstellungen ändern, ohne den Anwendungsquellcode oder die DataSource-Merkmale zu ändern.
Die einzelnen Merkmaleinstellungen der DB2 Universal JDBC-Treiberkonfiguration weisen das folgende Format auf:
merkmal=wert
Wenn das Konfigurationsmerkmal mit db2.jcc.override beginnt, ist es auf alle Verbindungen anwendbar und überschreibt alle Connection- oder DataSource-Merkmale mit demselben Merkmalnamen. Wenn das Konfigurationsmerkmal mit db2.jcc oder db2.jcc.default beginnt, ist der Konfigurationsmerkmalwert ein Standardwert. Einstellungen für die Connection- oder DataSource-Merkmale überschreiben diesen Wert.
Gehen Sie wie folgt vor, um Konfigurationsmerkmale festzulegen:
Für Standalone-Java-Anwendungen können Sie die Konfigurationsmerkmale als Java-Systemmerkmale festlegen, indem Sie bei der Ausführung des Befehls java die Option -Dmerkmal=wert angeben.
Für Standalone-Java-Anwendungen können Sie die Konfigurationsmerkmale festlegen, indem Sie bei der Ausführung des Befehls java die Option -Ddb2.jcc.propertiesFile=pfad angeben.
DB2JccConfiguration.properties kann eine Standalone-Datei sein oder sich in einer JAR-Datei befinden.
Wenn DB2JccConfiguration.properties eine Standalone-Datei ist, muss der Pfad für DB2JccConfiguration.properties in der CLASSPATH-Angabe enthalten sein.
Wenn DB2JccConfiguration.properties sich in einer JAR-Datei befindet, muss diese JAR-Datei in der CLASSPATH-Angabe enthalten sein.
Sie können die folgenden Konfigurationsmerkmale für DB2 Universal JDBC-Treiber festlegen. Alle Merkmale sind optional.
Geben Sie einen vollständig qualifizierten Dateinamen als Wert des Merkmals db2.jcc.override.traceFile an.
Das Merkmal db2.jcc.override.traceFile überschreibt das Merkmal traceFile für ein Connection- oder DataSource-Objekt.
Wenn Sie z. B. die folgende Einstellung für db2.jcc.override.traceFile angeben, wird die Traceverarbeitung des Java-Codes für den DB2 Universal JDBC-Treiber in einer Datei mit dem Namen /SYSTEM/tmp/jdbctrace aufgezeichnet:
db2.jcc.override.traceFile=/SYSTEM/tmp/jdbctrace
Sie sollten die Tracemerkmale unter Anleitung der IBM Unterstützungsfunktion festlegen.
Die Funktion db2secFreeToken (durch Token belegten Speicher freigeben) ist nicht mehr Bestandteil der Benutzerauthentifizierungs-Plug-in-API db2secGssapiServerAuthFunctions_1.
Die Integrität der Installation von DB2 Universal Database (UDB) kann beeinträchtigt sein, wenn die Implementierung von Sicherheits-Plug-ins nicht auf geeignete Weise codiert, geprüft und getestet wird. DB2 UDB ergreift Vorsichtsmaßnahmen gegen viele allgemein auftretende Arten von Fehlern, kann jedoch keine vollständige Integrität garantieren, wenn benutzerdefinierte Sicherheits-Plug-ins implementiert werden.
Wenn Sie Ihr eigenes Sicherheits-Plug-in verwenden, können Sie in einer CONNECT-Anweisung, die über den Befehlszeilenprozessor (CLP) oder über eine Anweisung für dynamisches SQL abgesetzt wird, eine Benutzer-ID mit bis zu 255 Zeichen verwenden.
Für die APIs db2secGetGroupsForUser, db2secValidatePassword und db2secGetAuthIDs kann der Eingabeparameter dbname einen Nullwert haben, und der entsprechende Eingabeparameter dbnamelen für die Länge wird auf 0 gesetzt.
.so wird nun als Dateinamenerweiterung für benutzerdefinierte Sicherheits-Plug-in-Bibliotheken auf allen Linux- und UNIX-Plattformen akzeptiert.
Unter AIX können Sicherheits-Plug-in-Bibliotheken die Erweiterung .a oder .so aufweisen. Sollten beide Versionen der Plug-in-Bibliothek vorhanden sein, wird die Version mit der Erweiterung .a verwendet.
Unter HP-UX auf PA-RISC können Sicherheits-Plug-in-Bibliotheken die Erweiterung .sl oder .so aufweisen. Sollten beide Versionen der Plug-in-Bibliothek vorhanden sein, wird die Version mit der Erweiterung .sl verwendet.
Auf allen übrigen Linux- und UNIX-Plattformen ist .so die einzige unterstützte Dateinamenerweiterung für Sicherheits-Plug-in-Bibliotheken.
Unter AIX können Sicherheits-Plug-in-Bibliotheken die Dateinamenerweiterung .a oder .so aufweisen. Der Mechanismus zum Laden der Plug-in-Bibliothek hängt von der verwendeten Erweiterung ab:
Beispiel für die Erzeugung einer Plug-in-Bibliothek als 32-Bit-Archiv:
xlc_r -qmkshrobj -o shr.o MeinPlugin.c -bE:MeinPlugin.exp ar rv MeinPlugin.a shr.o
xlc_r -qmkshrobj -o MeinPlugin.so MeinPlugin.c -bE:MeinPlugin.exp
Auf allen Plattformen außer AIX wird angenommen, dass Sicherheits-Plug-in- Bibliotheken immer dynamisch ladbare gemeinsam genutzte Objekte sind.
Bei der GSS-API-Authentifizierung wird nur ein einziges Token vom Client an den Server und ein einziges Token vom Server an den Client gesendet. Diese Tokens werden auf dem Client von gss_init_sec_context() und auf dem Server von gss_accept_sec_context() abgerufen. Wenn GSS-API-Plug-ins versuchen, weitere Tokens zu senden, wird ein unerwarteter Fehler für Sicherheits-Plug-ins generiert, und die Verbindung schlägt fehl.
Nachrichtenverschlüsselung und Signaturen sind in GSS-API-Sicherheits-Plug-ins nicht verfügbar.
Alle (normalen und abnormalen) Beendigungen machen, unabhängig vom Betriebssystem, ausstehende Arbeitseinheiten implizit rückgängig.
Die Dokumentation zu neuen Funktionen für DB2 Universal Database (UDB) Version 8.2 enthält im Abschnitt zu den DB2 Universal JDBC-Treiberverbesserungen falsche Informationen zur Unterstützung von verteilten Transaktionen. Der letzte Satz dieses Abschnitts ist falsch. Richtig muss er wie folgt lauten:
Ab Version 8.2 stellt DB2 UDB Unterstützung für verteilte Transaktionsverarbei- tung bereit, die der XA-Spezifikation entspricht. Diese Unterstützung implementiert die JTS- (Java Transaction Service) und JTA-Spezifikationen (Java Transaction API) von Java 2 Platform Enterprise Edition (J2EE).
Die maximale Anzahl Ergebnismengen, die von einer CLR-Prozedur (CLR - Common Language Runtime) zurückgegeben werden können, ist beschränkt. Der Grenzwert wird von der maximalen Anzahl gleichzeitig geöffneter DB2DataReader-Objekte bestimmt, die von DB2 .NET Data Provider in einer Verbindung unterstützt werden. Die Unterstützung von gleichzeitig ablaufenden aktiven Eingabeprogrammen für Daten ermöglicht es, dass mehrere DB2DataReader-Objekte in einer Verbindung geöffnet sein können. Somit können mehrere Ergebnismengen über eine CLR-Prozedur zurückgegeben werden.
Als Datenbankadministrator oder Anwendungsentwickler können Sie die Baugruppen, die den externen DB2 Universal Database-Routinen zugeordnet sind, vor unerwünschtem Zugriff schützen, indem Sie die Aktionen von Routinen während der Ausführung beschränken. DB2 .NET-CLR-Routinen (Common Language Run Time) unterstützen die Angabe eines Modus zur Ausführungssteuerung, der angibt, welche Typen von Aktionen eine Routine zur Laufzeit ausführen darf. DB2 kann während der Ausführung erkennen, ob die Routine versucht, Aktionen auszuführen, die außerhalb des Bereichs des zugehörigen Modus zur Ausführungssteuerung sind; dies kann nützlich sein, wenn Sie bestimmen wollen, ob eine Baugruppe beeinträchtigt wurde.
Zum Festlegen des Modus zur Ausführungssteuerung für eine CLR-Routine geben Sie für die Routine in der Anweisung CREATE die optionale Klausel EXECUTION CONTROL an. Gültige Modi:
Wenn Sie den Modus zur Ausführungssteuerung in einer vorhandenen CLR-Routine modifizieren möchten, führen Sie die Anweisung ALTER PROCEDURE oder ALTER FUNCTION aus.
Wenn die Klausel EXECUTION CONTROL für eine CLR-Routine nicht angegeben ist, wird die CLR-Routine standardmäßig unter Verwendung des restriktivsten Modus zur Ausführungssteuerung, im Modus SAFE, ausgeführt. Routinen, die mit diesem Modus zur Ausführungssteuerung erstellt werden, können nur auf Ressourcen zugreifen, die vom Datenbankmanager gesteuert werden. Weniger restriktive Modi zur Ausführungssteuerung lassen zu, dass eine Routine auf Dateien im lokalen Dateisystem (FILEREAD oder FILEWRITE) oder im Netzwerk zugreift. Der Modus zur Ausführungssteuerung UNSAFE gibt an, dass für das Verhalten der Routine keine Einschränkungen gelten sollen. Routinen, die mit dem Modus zur Ausführungssteuerung UNSAFE definiert sind, können Binärcode ausführen.
Diese Steuerungsmodi stellen eine Hierarchie zulässiger Aktionen dar, und ein Modus einer höheren Ebene schließt Aktionen ein, die sich in der Hierarchie unterhalb von ihm befinden. Beispiel: Der Modus zur Ausführungssteuerung NETWORK lässt zu, dass eine Routine auf Dateien im Netzwerk, auf Dateien im lokalen Dateisystem und auf Ressourcen zugreift, die vom Datenbankmanager gesteuert werden. Verwenden Sie den restriktivsten Modus zur Ausführungssteuerung, und vermeiden Sie die Verwendung des Modus UNSAFE.
Wenn DB2 UDB zur Laufzeit erkennt, dass eine CLR-Routine versucht, eine Aktion außerhalb des Geltungsbereichs seines Modus zur Ausführungssteuerung auszuführen, gibt DB2 UDB einen Fehler zurück (SQLSTATE 38501).
Die Klausel EXECUTION CONTROL kann nur für CLR-Routinen angegeben werden. Der Bereich der Anwendbarkeit der Klausel EXECUTION CONTROL ist auf die .NET-CLR-Routine selbst begrenzt und kann nicht auf andere Routinen erweitert werden, die sie möglicherweise aufruft.
Der Datentyp DECIMAL in DB2 Universal Database (UDB) wird mit einer Genauigkeit von 31 Stellen und mit 28 Kommastellen dargestellt. Der .NET-CLR-Datentyp System.Decimal ist auf eine Genauigkeit von 29 Stellen und 28 Kommastellen begrenzt. Deshalb dürfen externe DB2 UDB-CLR-Routinen höchstens den Wert (2^96)-1 zuordnen, den höchsten Wert, der mit der Genauigkeit von 29 Stellen und mit 28 Kommastellen in einer Variablen des Datentyps System.Decimal dargestellt werden kann. DB2 UDB verursacht den Laufzeitfehler (SQLSTATE 22003, SQLCODE -413), wenn eine solche Zuordnung erfolgt.
Wenn bei der Ausführung einer Anweisung zur Routinenerstellung ein Parameter mit dem Datentyp DECIMAL definiert wird, der mehr als 28 Kommastellen aufweist, verursacht DB2 UDB den Fehler (SQLSTATE 42611, SQLCODE -604).
Die mit dem Befehl REORGCHK verwendeten Indexstatistikformeln wurden überarbeitet. Die neuen Formeln und deren Erläuterungen müssen wie folgt lauten:
|100 * (KEYS * (ISIZE + LEAF_REC_OVERHEAD) + (CARD - KEYS) | * DUPKEYSIZE ) | / ((NLEAF - NUM EMPTY LEAFS - 1) * | (INDEXPAGESIZE - 96) > MIN(50, (100 - PCTFREE))Dabei ist LEAF_REC_OVERHEAD = 9 und DUPKEYSIZE = 5. |
Eine Reorganisation wird empfohlen, wenn mehr als 50 Prozent des für den Index vorgesehenen Speicherbereichs frei sind, oder wenn PCTFREE auf einer Wert größer als 50 gesetzt ist und im Index mehr als PCTFREE % Speicherplatz frei ist. Diese Formel wird nur überprüft, wenn der Wert für NLEAF - NUM EMPTY LEAFS - 1 größer 0 ist. (Vom Wert für NLEAF wird 1 abgezogen, da |die letzte zugeordnete Blattseite normalerweise nicht gefüllt ist.)
(100 - PCTFREE) * | [ Floor((100 - min(10, PCTFREE)) / 100 * (INDEXPAGESIZE - 96) | / (ISIZE + NONLEAF_REC_OVERHEAD)) ** (NLEVELS - 2)] | * (INDEXPAGESIZE - 96) / | (KEYS * (ISIZE + LEAF_REC_OVERHEAD) | + (CARD - KEYS) * DUPKEYSIZE) < 100Dabei ist NONLEAF_REC_OVERHEAD = 12. |
Es wird bestimmt, ob die erneute Erstellung des Index eine Baumstruktur mit weniger Ebenen ergibt. Dazu wird die Größe des Speicherplatzes in einem Indexbaum, der eine Ebene weniger aufweist als die aktuelle Baumstruktur, mit Hilfe dieser Formel ins Verhältnis zum erforderlichen Speicherplatz gesetzt. Sollte eine Baumstruktur mit einer Ebene weniger erstellt werden können und noch PCTFREE verfügbar sein, wird eine Reorganisation empfohlen. |Die tatsächliche Anzahl Indexeinträge sollte über 90 % (bzw. 100 % - |PCTFREE) der Anzahl Einträge liegen, die ein Indexbaum mit NLEVELS - 1 bearbeiten kann (nur überprüft, wenn NLEVELS > 1).
Reorganisiert einen Index oder eine Tabelle.
|Die Option REORG INDEXES ALL FOR TABLE tabellenname reorganisiert alle Indizes, die für eine Tabelle definiert sind, indem sie die Indexdaten als unfragmentierte, physisch zusammenhängende Seiten erneut erstellt. Wenn Sie die Option CLEANUP ONLY der Indexoption angeben, wird eine Bereinigung ausgeführt, ohne die Indizes erneut zu erstellen. Wenn Sie versuchen, diesen Befehl auf Indizes für deklarierte temporäre Tabellen anzuwenden, wird der SQLSTATE-Wert 42995 zurückgegeben.
|Die Option REORG TABLE tabellenname reorganisiert eine Tabelle, indem sie die Zeilen so wiederherstellt, dass fragmentierte Daten beseitigt und Daten in kompakter Form gespeichert werden. Die Reorganisation der Tabelle wird mit einer der folgenden zwei Methoden ausgeführt:
|Bei beiden Reorganisationstypen werden die Indizes der Tabelle nach der Reorganisation der Tabelle erneut erstellt. |Beim Inplace-Verfahren wird der Index jedoch unvollständig reorganisiert, so dass Sie die Indizes möglicherweise später reorganisieren müssen, um die Indexfragmentierung zu reduzieren und Speicherbereiche von Indexobjekten freizugeben.
|Bei der herkömmlichen Tabellenreorganisation (offline ausgeführter Befehl REORG TABLE), wie der Standardeinstellung in DB2 Universal Database |(UDB) Version 7, geben Sie den folgenden Befehl ein:
| db2 reorg table employee index empid allow no access indexscan
| longlobdata
|
|DB2 UDB bietet zwei Verfahren zur Tabellenreorganisation: das herkömmliche | Verfahren und das Inplace-Verfahren. |Allgemein ist die herkömmliche Tabellenreorganisation schneller, Sie sollten diese jedoch nur anwenden, wenn die Anwendungen während der Reorganisation ohne Schreibzugriffe auf Tabellen funktionieren. |Wenn die Umgebung diese Einschränkung nicht zulässt, kann die Inplace-Reorganisation trotz ihrer geringeren Geschwindigkeit im Hintergrund ausgeführt werden, während der normale Datenzugriff fortgesetzt wird.
|Die herkömmliche Tabellenreorganisation ist am schnellsten, besonders wenn Sie keine LOB- oder LONG-Daten reorganisieren müssen. |Darüber hinaus werden die Indizes nach der Tabellenreorganisation bei der erneuten Erstellung perfekt sortiert. Anwendungen mit Lesezugriff können mit Ausnahme der letzten Reorganisationsphase auf das Original der Tabelle zugreifen, da die permanente Tabelle die Spiegelkopie der Tabelle ersetzt und die Indizes erneut erstellt werden.
|Die Inplace-Tabellenreorganisation ist langsamer und garantiert keine perfekt sortierten Daten. Anwendungen können jedoch während der Reorganisation auf die Tabelle zugreifen. |Darüber hinaus kann die Inplace-Tabellenreorganisation unterbrochen und später von einer beliebigen Person mit entsprechender Berechtigung fortgesetzt werden, wobei der Schema- und Tabellenname verwendet werden.
|Das Dienstprogramm REORG unterstützt keine Kurznamen.
|Beachten Sie die folgenden Einschränkungen:
|In der Dokumentation von Version 8 steht, dass keine Datenbankmigration erforderlich ist, wenn die Datenbank auf eine FixPak-Stufe von DB2 UDB Version 8 migriert wurde. Genauer gesagt ist eine Datenbankmigration zwischen FixPaks nicht erforderlich, wenn sich die Datenbank auf einer Stufe von Version 8 befindet (Version 8.1 oder 8.2 oder ein nachfolgendes FixPak). In Version 8.2 wurden Änderungen an der Verzeichnisdateistruktur der Datenbank vorgenommen, und die Migration wird automatisch ausgeführt, wenn Sie von Version 7 oder Version 8.1 zu Version 8.2 wechseln. Wenn Sie jedoch von Version 8.2 zurück zu Version 8.1 wechseln, müssen Sie db2demigdbd ausführen, um die Verzeichnisdateistruktur der Datenbank wiederherzustellen. Wenn Sie dies nicht tun, tritt bei dem Versuch, auf die Datenbank zuzugreifen, der Fehler SQL10004 auf.
Setzen Sie den Befehl db2 connect to datenbank erst dann ab, wenn Sie den Befehl db2inidb datenbank as mirror abgesetzt haben.
Wenn Sie versuchen, eine Verbindung zu einer geteilten Spiegeldatenbank herzustellen, bevor diese initialisiert wurde, werden die Protokolldateien gelöscht, die für eine aktualisierende Wiederherstellung erforderlich sind.
Die Verbindung setzt die Datenbank in den Status zurück, in dem sie sich zum Zeitpunkt der Zurückstellung befand. Wenn die Datenbank zum Zeitpunkt der Zurückstellung als konsistent markiert ist, geht DB2 Universal Database davon aus, dass eine Wiederherstellung nach einem Systemabsturz nicht erforderlich ist und leert die Protokolldateien für zukünftige Verwendung. In einem solchen Fall wird bei dem Versuch, eine aktualisierende Wiederherstellung durchzuführen, ein Fehler SQL4970 generiert.
Wenn Sie ab Version 8.2 ein DB2 Universal Database-Exemplar mit dem Befehl db2iupdt aktualisieren, müssen Sie zuerst alle DB2-Prozesse stoppen, die für dieses Exemplar ausgeführt werden.
Für den Befehl db2sqljcustomize gibt es einen neuen Parameter.
Für den Befehl sqlj gibt es einen neuen Parameter.
Der DB2-Befehl zur Überwachung und Fehlerbehebung (db2pd) ruft Informationen aus den DB2 UDB-Speichergruppen ab. Der Systembefehl db2pd wurde wie folgt erweitert:
Der in Version 8.2 (äquivalent zu Version 8.1 FixPak 7) eingeführte Parameter -hadr listet HADR-Informationen (High Availability Disaster Recovery) auf. Beschreibungen der einzelnen aufgelisteten Elemente finden Sie im Abschnitt zu High Availability Disaster Recovery des Handbuchs System Monitor Guide and Reference.
Der in Version 8.2 (äquivalent zu Version 8.1 FixPak 7) eingeführte Parameter -utilities listet Informationen zu Dienstprogrammen auf. Beschreibungen der einzelnen ausgegebenen Elemente finden Sie im Abschnitt zu Dienstprogrammen des Handbuchs System Monitor Guide and Reference.
Der in Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) eingeführte Parameter -activestatements gibt Informationen zu aktiven Anweisungen zurück. Die folgenden Informationen wurden zurückgegeben:
Ab Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) können Sie die Option wait mit dem Parameter -locks angeben, um nur Sperren mit einem Wartestatus sowie Sperren, auf die gewartet wird, zurückzugeben.
Ab Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) gibt der Parameter -applications vier neue Felder zurück:
Sobald die Anforderung verarbeitet wurde, werden die Werte auf 0 gesetzt. Auch für statische SQL-Anweisungen wird der Wert auf 0 gesetzt.
Der Befehl SET CLIENT gibt Verbindungseinstellungen für den Back-End-Prozess an.
Der Befehlsparameter SYNCPOINT für diesen Befehl wird ab Version 8 ignoriert. SYNCPOINT ist jedoch aus Gründen der Abwärtskompatibilität weiterhin vorhanden.
Der Befehl PRECOMPILE verarbeitet eine Quellendatei eines Anwendungsprogramms, die eingebettete SQL-Anweisungen enthält. Es wird eine modifizierte Quellendatei generiert, die SQL-Aufrufe in der Hostprogrammiersprache enthält, und in der Datenbank wird standardmäßig ein Paket erstellt.
Der Befehlsparameter SYNCPOINT für diesen Befehl wird ab Version 8 ignoriert. SYNCPOINT ist jedoch aus Gründen der Abwärtskompatibilität weiterhin vorhanden.
Aktualisiert die Position, den Einheitentyp oder den Kommentar in einem Verlaufsdateieintrag.
Der Befehlsparameter STATUS gibt für einen Eintrag einen neuen Status an.
In der früheren Dokumentation steht irrtümlich, dass der Befehlsparameter STATUS den Wert "I" haben kann, womit der Eintrag als inaktiv markiert wird. Gültige Werte:
Der gesamte Unterabschnitt "Erforderliche Verbindung" für die Befehle EXPORT und IMPORT lautet wie folgt:
Datenbank. Wenn das implizite Herstellen der Verbindung aktiviert ist, wird eine Verbindung zur Standarddatenbank hergestellt. Der Dienstprogrammzugriff auf Linux-, UNIX- oder Windows-Datenbankserver von Linux-, UNIX- oder Windows-Clients aus muss über eine direkte Verbindung über die Steuerkomponente, und nicht über ein DB2 Connect-Gateway oder über eine Rückschleife erfolgen.
Die vollständigen Informationen für den AUTOSELECT-Wert des Parameters INDEXING MODE lauten wie folgt:
Der Befehl SET INTEGRITY in der Beschreibung für den Modifikator "generatedoverride" wurde aktualisiert.
Die Beschreibung für den Modifikator "usedefaults" wurde ebenfalls aktualisiert.
Die Aktualisierungen lauten wie folgt:
Die Beschreibung zu den Modifikatoren "usedefaults" und "codepage=x" wurde wie folgt aktualisiert:
Der Parameter USER des Befehls ATTACH gibt die Authentifizierungskennung an. Wenn Sie eine Verbindung zu einem DB2 Universal Database-Exemplar unter einem Windows-Betriebssystem herstellen, kann der Benutzername in einem Format angegeben werden, das mit Microsoft Windows NT Security Account Manager (SAM) kompatibel ist. Das Qualifikationsmerkmal muss ein NetBIOS-Name sein, der maximal 15 Zeichen lang ist. Beispiel: domaene\benutzer
Im Abschnitt für Beispiele der Dokumentation zum Befehl RECOVER DATABASE für Version 8.2 sind Zeitmarken falsch als jjjj:mm:tt:hh:mm:ss formatiert.
Das richtige Format muss jjjj-mm-tt-hh.mm.ss lauten.
Der Befehl UPDATE HISTORY FILE aktualisiert die Position, den Einheitentyp, den Kommentar oder den Status in einem Verlaufsdateieintrag.
>>-UPDATE HISTORY--+-FOR--objektteil-+--WITH--------------------> '-EID--eid--------' >--+-LOCATION--neue-position--DEVICE TYPE--neuer-einheitentyp-+->< +-COMMENT--neuer-kommentar---------------------------------+ '-STATUS--neuer-status-------------------------------------'
Dieser Befehl aktualisiert die Systemkataloge in einer Datenbank, um die aktuelle Stufe auf die folgenden Arten zu unterstützen:
SYSADM
Datenbank. Mit diesem Befehl stellen Sie automatisch eine Verbindung zur angegebenen Datenbank her.
>>-db2updv8-- -d--datenbankname---------------------------------> >--+---------------------------------+--+-----+---------------->< '- -u--benutzer-ID-- -p--kennwort-' '- -h-'
Nach der Installation der aktuellen Stufe (FixPak oder neue Version) können Sie den Systemkatalog in der Beispieldatenbank mit dem folgenden Befehl aktualisieren:
db2updv8 -d sample
Für die Formatierung von Trapdateien (*.TRP) steht das neue Tool db2xprt.exe zur Verfügung. Mit diesem Tool können binäre DB2 Universal Database-Trapdateien in eine lesbare ASCII-Datei umgewandelt werden. Trapdateien befinden sich stan- dardmäßig im Verzeichnis des Exemplars (DB2INSTPROF) oder im Verzeichnis für Diagnosedaten, wenn der Konfigurationsparameter DIAGPATH des Datenbankmanagers festgelegt wurde.
Sie müssen über die Zugriffsberechtigung für das Verzeichnis DIAGPATH verfügen.
>>-db2xprt--+----------+--+----+--+----+------------------------> +-/p--pfad-+ '-/m-' '-/n-' '-/v-------' >--eingabedatei--+--------------+------------------------------>< '-ausgabedatei-'
Eine neue Bindedatei mit dem Namen db2uImpInsUpdate.bnd wurde dem Importdienstprogramm mit der Standardisolationsstufe Lesestabilität (RS) hinzugefügt. Diese Bindedatei wird nur bei Verwendung der Option INSERT_UPDATE vom Importdienstprogramm verwendet. Die Optionen INSERT, REPLACE und CREATE des Importdienstprogramms verwenden immer noch die Datei db2uimpm.bnd.
Die Bindedatei db2uImpInsUpdate.bnd kann mit der Option INSERT BUF nicht gebunden werden. Der Versuch, IMPORT INSERT_UPDATE auszuführen, während db2uImpInsUpdate.bnd mit INSERT BUF gebunden wird, führt zum Fehlschlagen des Importdienstprogramms und zum Auftreten des folgenden Fehlers:
SQL3525: Die Option "INSERT_UPDATE" ist mit der Option "INSERT BUF BIND ON DB2UIMPINSUPDATE.BND" nicht kompatibel.
In Version 8.2 des Handbuchs Dienstprogramme für das Versetzen von Daten Handbuch und Referenz heißt es wie folgt:
Die Funktion der gepufferten INSERT-Operationen kann nicht zusammen mit Importoperationen verwendet werden, bei denen der Parameter INSERT_UPDATE angegeben wird. Um diese Einschränkung umzusetzen, wird eine neue Bindedatei (db2uimpm2.bnd) eingeführt.
Auf Grund der Einführung einer neuen Bindedatei sollte die Anweisung wie folgt lauten:
Die Funktion der gepufferten INSERT-Operationen kann nicht zusammen mit Importoperationen verwendet werden, bei denen der Parameter INSERT_UPDATE angegeben wird. Um diese Einschränkung umzusetzen, wird eine neue Bindedatei (db2uImpInsUpdate.bnd) eingeführt.
Sie können das Importdienstprogramm verwenden, um eine Tabelle erneut zu erstellen, die mit dem Exportdienstprogramm gespeichert worden ist.
In Versetzen von Daten ist im Thema "Erneutes Erstellen einer exportierten Tabelle mit IMPORT" angegeben, dass Attribute der Originaltabelle nicht beibehalten werden. Außer den Attributen, die bereits dokumentiert sind, werden die folgenden Attribute nicht beibehalten:
Beachten Sie die folgenden Einschränkungen:
|Für das Sicherungsdienstprogramm gelten die folgenden Einschränkungen:
|Wenn Sie die Befehle START HADR, STOP HADR oder TAKEOVER HADR ausführen, werden möglicherweise die entsprechenden Fehlercodes generiert: SQL01767N, SQL01769N oder SQL01770N mit Ursachencode 98. Der Ursachencode zeigt an, dass auf dem Server, auf dem der Befehl ausgeführt wurde, keine installierte Lizenz für HADR vorhanden ist. Installieren Sie zur Behebung dieses Fehlers mit db2licm eine gültige HADR-Lizenz, oder installieren Sie eine Serverversion, die eine gültige HADR-Lizenz einschließt.
DB2 Universal Database unterstützt plattformübergreifende Sicherungs- und Wiederherstellungsoperationen.
Sie können Datenbanken, die mit DB2 UDB Version 8 auf 32-Bit-Windows-Plattformen erstellt wurden, in DB2 UDB Version 8 auf 64-Bit-Windows-Plattformen wiederherstellen oder umgekehrt.
Sie können Datenbanken, die mit DB2 UDB Version 8 auf 32-Bit-Linux-x86-Plattformen erstellt wurden, in DB2 UDB Version 8 auf 64-Bit-Linux-x86-64-Plattformen oder -IA64-Plattformen wiederherstellen oder umgekehrt.
Sie können Datenbanken, die mit DB2 UDB Version 8 auf AIX-, HP-UX-, Linux PPC-, Linux zSeries-Plattformen oder auf Plattformen mit Solaris-Betriebsumge- bungen (32 oder 64 Bit) erstellt wurden, in DB2 UDB Version 8 für AIX-, HP-UX-, Linux PPC-, Linux zSeries-Plattformen oder für Plattformen mit Solaris-Betriebsumgebungen (32 oder 64 Bit) wiederherstellen.
Die maximale Blockgröße für 3480- und 3490-Bandeinheiten unter Linux ist 61.440 Byte.
Einheit | Anschluss | Blockgrößengrenzwert | Grenzwert für DB2-Puffer (in 4 KB großen Seiten) |
---|---|---|---|
3480 | s370 | 61.440 | 15 |
3490 | s370 | 61.440 | 15 |
Wenn Sie die Befehle BACKUP DATABASE oder RESTORE DATABASE aufrufen, können Sie angeben, dass Sie die Sicherungs- oder Wiederherstellungsoperation für die Datenbank bzw. den Tabellenbereich mit dem Produkt Tivoli Storage Manager (TSM) verwalten wollen. Der erforderliche Mindeststand der TSM-Client-API ist Version 4.2.0 außer auf folgenden Systemen:
Wenn Sie die Werte der HADR-Parameter (High Availability Disaster Recovery) für lokalen Host und lokalen Service (HADR_LOCAL_SVC und HADR_REMOTE_SVC) angeben, während Sie einen update database configuration-Befehl vorbereiten, müssen Sie Ports angeben, die von keinem anderen Service belegt werden. Wenn die Parameter über die Linux- oder UNIX-Befehlszeile konfiguriert werden, müssen die Werte auch in der Datei /etc/services gesetzt werden.
Wenn Sie einen Tabellenbereich in der Primärdatenbank erstellen und die Wiedergabe des Protokolls in der Bereitschaftsdatenbank fehlschlägt, weil die Behälter nicht verfügbar sind, empfängt die Primärdatenbank keine Fehlernachricht darüber, dass die Wiederhabe des Protokolls fehlgeschlagen ist.
Zur Prüfung auf Wiedergabefehler müssen Sie bei der Erstellung neuer Tabellenbereiche die Datei db2diag.log und das Verwaltungsprotokoll für die Bereitschaftsdatenbank überwachen.
Wenn eine Übernahme auftritt, ist der von Ihnen neu erstellte Tabellenbereich in der neuen Primärdatenbank nicht verfügbar. Diese Situation können Sie beheben, indem Sie den Tabellenbereich in der neuen Primärdatenbank von einem Sicherungsimage wiederherstellen.
Im folgenden Beispiel wird der Tabellenbereich MEIN_TB in der Datenbank MEINE_DB vor der Verwendung als neue Primärdatenbank wiederhergestellt:
In der Dokumentation zu Version 8.2 steht Folgendes:
BLOBs und CLOBs werden nicht repliziert, der Speicherbereich für die BLOBs und CLOBs wird jedoch in der Bereitschaftsdatenbank zugeordnet.
Diese Aussage muss jedoch wie folgt lauten:
Nicht protokollierte BLOBs und CLOBs werden nicht repliziert, der Speicherbereich für die BLOBs und CLOBs wird jedoch in der Bereitschaftsdatenbank zugeordnet.
HADR (High Availability Disaster Recovery) unterstützt nicht die Verwendung unformatierter Ein-/Ausgabe (direkter Plattenzugriff) für Datenbankprotokolldateien. Wenn HADR mit dem Befehl START HADR gestartet wird oder wenn die Datenbank mit konfiguriertem HADR erneut gestartet wird, schlägt der zugeordnete Befehl mit der Fehlernachricht SQL1768N und Ursachencode "9" fehl.
Im Handbuch DB2 Warehouse Manager Standard Edition Installation von Version 8.2 erhalten Sie im Thema "Aktualisieren der Datenbankmanagerkonfiguration vor der Installation von Warehouse-Umsetzungsprogrammen" eine falsche Anweisung zur Aktualisierung des SDK-Pfadparameters. Sie müssen den JDK-Pfadparameter aktualisieren.
|Verwenden Sie den DB2-Befehlszeilenprozessor (CLP), um die Datenbankmanagerkonfiguration für das Ziel-DB2-Exemplar zu aktualisieren, bevor Sie Data Warehouse-Umsetzungsprogramme installieren.
|Gehen Sie wie folgt vor, um vor der Installation von Data Warehouse-Umsetzungsprogrammen die Datenbankmanagerkonfiguration zu aktualisieren:
|UPDATE DATABASE MANAGER CONFIGURATION USING JDK_PATH pfad
Dabei steht pfad für das Unterverzeichnis, in dem das JDK installiert ist.
|
|UPDATE DATABASE MANAGER CONFIGURATION USING JAVA_HEAP_SZ 4096
Unter UNIX-Betriebssystemen außer Linux können Sie für die Data Warehouse-Zentrale ab Version 8.2 FixPak 10 (äquivalent zu Version 8.1 FixPak 3) die Umgebungsvariable VW_NETRC setzen. Wenn Sie die Umgebungsvariable VW_NETRC auf off setzen, können Sie die .netrc-Datei manuell verwalten. Weitere Informationen zum richtigen Format der .netrc-Datei finden Sie in der Dokumentation zu Ihrem Betriebssystem.
|Durch die Ausführung gleichzeitig ablaufender, benutzerdefinierter FTP-Programme kann die .netrc-Datei beschädigt werden. Wenn Sie gleichzeitig ablaufende, benutzerdefinierte FTP-Programmschritte ausführen möchten, können Sie die Umgebungsvariable VW_NETRC auf OFF setzen (VW_NETRC=OFF). Fügen Sie diese Umgebungsvariable dem Profil Ihres Agentendämons für ferne Agenten und der Datei IWH.environment für den Standardagenten oder für den lokalen Agenten hinzu.
Nach der Installation von DB2 Universal Database Version 8.1 FixPak 7 oder höher müssen Sie das Tool zur Verwaltung der Data Warehouse-Steuerungsdaten ausführen, um eine neue Data Warehouse-Steuerungsdatenbank im Unicode-Format zu erstellen.
Zum Erstellen und Speichern einer Kopie der vorhandenen Data Warehouse-Steuerungsdatenbank muss Ihre Workstation über genügend Plattenspeicherplatz verfügen, um diese Kopie zu speichern, sowie zusätzlich die doppelte Menge Speicherplatz bereitstellen, die die Data Warehouse-Steuerungsdatenbank zum Speichern temporärer Dateien benötigt. Wenn die vorhandene Data Warehouse-Steuerungsdatenbank eine Größe von 10 MB hat, müssen insgesamt 30 MB Speicherplatz in demselben Exemplar verfügbar sein, in dem sich auch die vorhandene Data Warehouse-Steuerungsdatenbank befindet.
Führen Sie zum Erstellen einer neuen Data Warehouse-Steuerungsdatenbank im Unicode-Format die folgenden Schritte aus:
Die folgende Aktualisierung betrifft zwei Themen im Zusammenhang mit der Data Warehouse-Zentrale:
Bei der Definition einer Warehouse-Quelle oder eines Warehouse-Ziels ist die Anzahl der zurückgegebenen Tabellen der Standardwert 250. Sie können jedoch die neue Umgebungsvariable VWS_MAX_TABLELIST verwenden, um die Anzahl der zurückgegebenen Tabellen festzulegen. Die maximale Anzahl der Tabellen, die zurückgegebenen werden können, beträgt 40 000. Diese Anzahl kann je nach Größe der Tabellennamen in der Liste auch kleiner sein. Sie sollten eine Anzahl angeben, die viel kleiner ist als 40 000.
In Version 8 muss die Steuerungsdatenbank TBC_MD, die im Lernprogramm verwendet wird, keine ODBC-Datenquelle des Systems sein. Die Zieldatenbank oder Datenbankquelle DWCTBC muss jedoch eine System-ODBC-Datenquelle sein.
Die Vorgehensweise zum Öffnen des Notizbuchs Warehouse-Quelle definieren hat sich für die relationale Quelle des Lernprogramms geändert.
Gehen Sie wie folgt vor, um das Notizbuch Warehouse-Quelle definieren für die relationale Quelle des Lernprogramms zu öffnen:
Das Notizbuch Warehouse-Quelle definieren wird geöffnet.
Die Vorgehensweise zum Öffnen des Notizbuchs Warehouse-Ziel definieren hat sich geändert.
Gehen Sie wie folgt vor, um das Notizbuch Warehouse-Ziel definieren zu öffnen:
Das Notizbuch Warehouse-Ziel definieren wird geöffnet.
In der Protokolldatei werden Datensätze so lange gespeichert, bis ein festgelegter Additionsgrenzwert erreicht ist. Der Additionsgrenzwert beträgt standardmäßig 1000 Datensätze. In der Regel werden bei jeder Jobausführung 12 bis 15 Protokollsätze erstellt. Legen Sie den Grenzwert für die Freigabe entsprechend Ihren Erfordernissen fest. Aktualisieren Sie hierzu das Feld Protokoll löschen, wenn Anzahl Einträge gleich auf der Indexzunge Server der Seite mit den Warehouse-Merkmalen.
Der DB2 Universal Database-Ladeschritt ermöglicht jetzt die Verwendung einer Sicht oder Tabelle als Quelle für den Schritt, was cursorbasiertes Laden zur Folge hat.
Der Radioknopf Spalten gemäß den in der Eingabedatei vorhandenen Spaltenpositionen zuordnen muss ausgewählt sein, damit im Assistenten Spalten für cursorbasiertes Laden zugeordnet werden können.
Ab Version 8.2 der Data Warehouse-Zentrale muss es sich bei der Warehouse-Steuerungsdatenbank um eine Unicode-Datenbank handeln. Auch wenn Sie eine Unicode-Warehouse-Steuerungsdatenbank einer Version der Data Warehouse-Zentrale vor Version 8.2 verwenden, müssen Sie eine neue Unicode-Steuerungsdatenbank mit dem Tool zur Verwaltung der Warehouse-Steuerungsdatenbank erstellen.
Wenn Sie eine Warehouse-Steuerungsdatenbank von einer Version der Data Warehouse-Zentrale vor Version 8.2 migrieren, führt das Tool zur Verwaltung der Steuerungsdatenbank der Data Warehouse-Zentrale den Befehl db2move aus, um die Daten in eine neue Unicode-Steuerungsdatenbank zu versetzen. Während dieses Prozesses werden Fenster angezeigt, die den Fortschritt des Befehls db2move zeigen. Dieses Migrationsverfahren wird nur einmal ausgeführt.
Die Data Warehouse-Zentrale unterstützt Unicode auf Sybase-Servern nicht.
In der Detailsicht des Hauptfensters der Data Warehouse-Zentrale wurde das Datumsformat in der Spalte Modifiziert aktualisiert. Das Datum in der Spalte Modifiziert wird im Format für die Ländereinstellung angezeigt und umfasst die Uhrzeit. Diese Änderung des Datumsformats stellt sicher, dass das Sortieren von Objekten in der Spalte Modifiziert richtig ausgeführt wird. Diese Aktualisierung gilt für die meisten Listen mit Objekten der Data Warehouse-Zentrale, die in der Navigations- und Detailsicht angezeigt werden. Beispiel:
Definieren Sie zum Ausführen einer statistischen Umsetzung Ihrer Daten das statistische Umsetzungsprogramm, das Sie verwenden wollen.
Gehen Sie wie folgt vor, um statistische Umsetzungsprogramme zu definieren:
Für jedes Umsetzungsprogramm gibt es eigene Regeln für die Verbindung mit einer Warehouse-Quelle und einem Warehouse-Ziel. Weitere Informationen finden Sie in der Dokumentation für die einzelnen Umsetzungsprogramme.
Für die Verwendung eines iSeries-Warehouse-Agenten für DB2 Warehouse Manager auf Systemen mit Version 5 Release 2 bzw. 3 ist die folgende vorläufige Programmkorrektur (PTF) erforderlich:
PTF SI13558
Mit dieser vorläufigen Programmkorrektur für Datenbanken kann die CLI auf iSeries Unicode-Daten verarbeiten.
DB2 .NET Data Provider unterstützt jetzt die Verwendung von gleichzeitig ablaufenden aktiven Eingabeprogrammen für Daten. Dies bedeutet, dass Sie gleichzeitig auf Daten von mehreren DB2DataReader-Exemplaren zugreifen können, die dasselbe DB2Connection-Exemplar verwenden. Jedes DB2DataReader-Exemplar muss seinem eigenen DB2Command-Exemplar zugeordnet sein. Wenn Sie das zugeordnete DB2Command-Exemplar zu einem anderen Zweck verwenden möchten, müssen Sie explizit die Methode DB2DataReader.Close aufrufen.
Es gibt ein Zusatzschlüsselwort für das Merkmal DB2Connection.ConnectionString:
Ab DB2 Connect(TM) Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) ist das Gateway während der Authentifizierungsfestlegung kein passiver Teilnehmer mehr. Stattdessen übernimmt das Gateway eine aktive Rolle. Der Authentifizierungstyp, der im Datenbankverzeichniseintrag am Gateway angegeben wurde, überschreibt den Authentifizierungstyp, der auf dem Client katalogisiert wurde. Sowohl der Client als auch das Gateway und der Server müssen kompatible Typen angeben. Wenn der katalogisierte Authentifizierungstyp am Gateway nicht im Datenbank- verzeichniseintrag angegeben wurde, wird vom Server standardmäßig die SER- VER-Authentifizierung verwendet. Die Festlegung wird jedoch auch zwischen dem Client und dem Server vorgenommen, wenn der Server die SERVER-Authentifizierung nicht unterstützt. Dieses Verhalten weicht vom Verhalten des Clients ab, der standardmäßig den Wert SERVER_ENCRYPT verwendet, wenn kein Authentifizierungstyp angegeben wurde.
Der Authentifizierungstyp, der am Gateway katalogisiert wurde, wird nicht verwendet, wenn die Option DB2NODE oder SQL_CONNECT_NODE der SET CLIENT-API auf dem Client gesetzt wurde. In diesen Fällen erfolgt die Festlegung ausschließlich zwischen dem Client und dem Server.
Ein Server, für den der Authentifizierungstyp SERVER_ENCRYPT in der Daten- bankmanagerkonfiguration angegeben wurde, akzeptiert keine Verbindungen oder Anhänge von Clients mehr, die die SERVER-Authentifizierung anfordern.
Es wurde ein neues Sicherheitsszenario für APPC-Verbindungen hinzugefügt:
In den folgenden DB2 Connect Enterprise Edition-Themen sind fehlerhafte Abbildungen enthalten:
Die folgende Tabelle zeigt Korrekturen für Abbildungen im Thema "Zugreifen auf Host- oder iSeries-DB2-Daten über DB2 Connect Enterprise Edition".
Position innerhalb des Themas | Korrektur |
---|---|
Legende für alle vier Abbildungen |
|
Erste Abbildung (Abbildung 1: DB2 Connect Enterprise Edition) | Alle Verweise auf "APPC" und "SNA-Kommunikationsunterstützung" sind inkorrekt. SNA/APPC wird von DB2-Servern unter Linux, Unix und Windows, einschließlich DB2 Connect Enterprise Edition, nicht als eingehendes Protokoll für DB2 Runtime Client unterstützt. |
Die folgende Tabelle zeigt Korrekturen für Abbildungen im Thema "Zugreifen auf DB2-Daten über das Web mit Java".
Position innerhalb des Themas | Korrektur |
---|---|
Legende |
|
Die DB2-Entwicklungszentrale Version 8.2 erfordert jetzt Version 9.2.9 von IBM Distributed Debugger. Wenn Sie Distributed Debugger Version 9.2.9 nicht installiert haben, können Sie Fehler in gespeicherten Java-Prozeduren nicht mit Hilfe der Entwicklungszentrale beheben.
Distributed Debugger Version 9.2.9 unterstützt keine Solaris-Betriebsumgebungen mehr.
Weitere Informationen zu Distributed Debugger finden Sie im Internet unter http://www.ibm.com/software/awdtools/debugger.
Wenn Sie die Länge einer Variablen mit Hilfe des Dialogs 'Variablenbereich ändern' in der DB2-Entwicklungszentrale ändern, beträgt die maximale Länge 1024 Byte. Diese Begrenzung wird zurzeit in einer Nachricht dokumentiert, die nur auf englisch vorliegt.
In Version 8.2 wurde Unterstützung dafür hinzugefügt, dass Benutzer über die Entwicklungszentrale eine Verbindung zu einer DB2 Universal Database-Datenbank mit DB2 Universal Driver Typ 2 und 4 herstellen können. Wenn Sie jedoch versuchen, einen dieser Treiber zu verwenden, um eine Verbindung zu einem iSeries-Server oder zu einem DB2 UDB-Server von Version 8.1 oder früher herzustellen, wird folgende Fehlernachricht angezeigt:
Verbindung zu <datenbank> ist fehlgeschlagen.
IBM DB2 Universal Driver (JCC) wurde nicht gefunden.
Weitere Informationen dazu, welche Treiber Sie verwenden sollten, um diesen Fehler zu vermeiden, finden Sie im Thema "JDBC-Treiber" von DB2 Information - Unterstützung.
Ab DB2 Universal Database (UDB) Version 8.2 FixPak 1 (äquivalent zu Version 8.1 FixPak 8) können Sie das Abschlusszeichen für die Anweisung innerhalb einer Prozedur modifizieren, die vom Befehlszeilenprozessor (CLP) oder vom Befehlseditor ausgeführt wird. Dieses Modifizieren während der Verarbeitung ähnelt der momentan in DB2 UDB für OS/390 verfügbaren Methode. Im folgenden Beispiel wird veranschaulicht, wie das Abschlusszeichen nach den einzelnen Anweisungen geändert werden kann:
connect to gilroy user newton using password; select * from newton.department; --#SET TERMINATOR : select * from newton.employee: --#SET TERMINATOR @ select * from newton.department@ --#SET TERMINATOR ; select * from newton.department; --#SET TERMINATOR & terminate&
Die Möglichkeit, das Abschlusszeichen zu ändern, ist von Bedeutung, wenn eine Prozedur zusammengesetzte Anweisungen enthält. Im folgenden Beispiel geht DB2 UDB davon aus, dass der erste Strichpunkt ; in der zusammengesetzten Anweisung CREATE TRIGGER das Abschlusszeichen für die gesamte Anweisung CREATE TRIGGER ist. Dies trifft jedoch nicht zu. Es soll lediglich das Abschlusszeichen für eine der Anweisungen innerhalb der zusammengesetzten Anweisung CREATE TRIGGER sein.
CONNECT TO SAMPLE; DROP TRIGGER newton.NWTTRIGGER; CREATE TRIGGER newton.NWTTRIGGER AFTER DELETE ON newton.NWTTABLE FOR EACH ROW MODE DB2SQL BEGIN ATOMIC insert into newton.nwttable values(0,'0'); insert into newton.nwttable values( -1, '-1'); END; CONNECT RESET; TERMINATE;
Im folgenden Beispiel wird veranschaulicht, wie das Abschlusszeichen für Anweisungen innerhalb der Prozedur modifiziert werden kann, um das gewünschte Ergebnis zu erzielen.
CONNECT TO SAMPLE; DROP TRIGGER newton.NWTTRIGGER; --#SET TERMINATOR @ CREATE TRIGGER newton.NWTTRIGGER AFTER DELETE ON newton.NWTTABLE FOR EACH ROW MODE DB2SQL BEGIN ATOMIC insert into newton.nwttable values(0,'0'); insert into newton.nwttable values( -1, '-1'); END@ --#SET TERMINATOR ; CONNECT RESET;
Wenn Sie Ihre Prozeduren nicht lokal unter DB2 für OS/390 ausführen möchten oder wenn die DB2 UDB-Prozeduren keine Verbindung zu OS/390 herstellen, sollten Sie zum Modifizieren von Abschlusszeichen für Anweisungen nicht die Methode mit --#SET TERMINATOR verwenden. Stattdessen sollten Sie die vorhandenen Optionen -tdX oder ;-- verwenden.
Mit der Option -tdX können Sie das Abschlusszeichen angeben, wenn Sie eine Prozedur unter Verwendung eines CLP-Befehls aufrufen. Das Zeichen 'X' steht für das als Abschlusszeichen für Anweisungen zu verwendende Zeichen. Dies sehen Sie z. B. im folgenden Befehl:
db2 -tvf test.txt -td&
Das Zeichen & wird als Abschlusszeichen für Anweisungen verwendet, wenn die Prozedur in der Datei test.txt ausgeführt wird. Wenn diese Prozedur die zusammengesetzte Anweisung CREATE TRIGGER enthält, wird diese wie folgt geschrieben:
CONNECT TO SAMPLE& DROP TRIGGER newton.NWTTRIGGER& CREATE TRIGGER newton.NWTTRIGGER AFTER DELETE ON newton.NWTTABLE FOR EACH ROW MODE DB2SQL BEGIN ATOMIC insert into newton.nwttable values(0,'0'); insert into newton.nwttable values( -1, '-1'); END& CONNECT RESET& TERMINATE&
Die Prozedur, die die zusammengesetzte Anweisung CREATE TRIGGER enthält, kann auch mit der Option ;-- auf andere Weise wie folgt geschrieben werden:
CONNECT TO SAMPLE; DROP TRIGGER newton.NWTTRIGGER; CREATE TRIGGER newton.NWTTRIGGER AFTER DELETE ON newton.NWTTABLE FOR EACH ROW MODE DB2SQL BEGIN ATOMIC insert into newton.nwttable values(0,'0');-- insert into newton.nwttable values( -1, '-1');-- END; CONNECT RESET; TERMINATE;
Sie können das Detailteilfenster der Steuerzentrale verwenden, um Informationen zu Ihren Datenbanken anzuzeigen. Durch Auswählen einer Datenbank in der Objektbaumstruktur oder dem Inhaltsteilfenster wird eine Zusammenfassung ihres Status angezeigt. In manchen Situationen sind Datenbankinformationen möglicherweise nicht verfügbar. Einige Ursachen für die Nichtverfügbarkeit werden in der folgenden Tabelle beschrieben.
Datenbankstatuselement | Mögliche Ursachen für nicht verfügbaren Status |
---|---|
Letzte Sicherung |
|
Datenbankgröße |
|
Kapazität |
|
Ordnungsgemäßer Betrieb |
|
Verwaltung |
|
Dem Dialog Ausgabeoptionen, der über das Fenster Ereignismonitor erstellen gestartet wird, wurde ein Knopf Generieren hinzugefügt. Durch Anklicken des Knopfs Generieren wird die Standardausgabeoption für das Schreiben in die Tabelle generiert. Diese Ausgabe entspricht der Syntax, die vom Befehl db2evtbl generiert wird.
Die generierte Option zeigt dem Benutzer, welche Tabellen und Datenelemente eingeschlossen werden, wenn der Ereignismonitor erstellt wird. Benutzer können den Befehl entsprechend ihren Anforderungen modifizieren.
Die generierte Syntax basiert auf dem Ereignismonitornamen und den Ereignistypen, die im Fenster Ereignismonitor erstellen angegeben wurden. Geben Sie den Ereignismonitornamen und die Ereignistypen an, bevor Sie die Ausgabeoptionssyntax generieren.
Wenn sich der Ereignismonitorname oder die Ereignistypen nach der Generierung der Ausgabeoption ändern, wird eine Nachricht angezeigt, um den Benutzer daran zu erinnern, die Ausgabeoption vor der Erstellung des Ereignismonitors erneut zu generieren. Wenn die Ausgabeoption nicht erneut generiert wird, werden Ereignistabellen basierend auf dem Ereignismonitornamen generiert, der zuvor angegeben wurde.
Die Beispielprozeduren ICCConfig.jacl und ICCConfig.properties werden mit der Informationskatalogzentrale für das Web mit DB2 Embedded Application Server (integrierter Anwendungsserver von DB2) zur Verfügung gestellt. Sie können diese Beispielprozeduren verwenden, um die Informationskatalogzentrale für das Web mit WebSphere Application Server 5 zu konfigurieren. Diese Prozeduren befinden sich im Verzeichnis sqllib\samples\icweb.
Wenn Ihre Metadaten beim Konfigurieren der Informationskatalogzentrale für das Web mit DB2 Embedded Application Server URLs enthalten, die auf Dateien auf dem Server zugreifen, müssen Sie die URLs der richtigen Position zuordnen, indem Sie Aliasnamen in der Web-Server-Konfiguration verwenden. Sie müssen auch die Hilfe- und Copyright-Links zuordnen. Wenn Sie DB2 Embedded Application Server verwenden, muss ein Web-Server richtig konfiguriert und aktiv sein, damit diese Links funktionieren, obwohl Sie keinen Web-Server verwenden müssen.
Der Parameter resourcesetname wird nur unter AIX, HP-UX und Linux sowie in der Solaris-Betriebsumgebung unterstützt.
|Unter Linux-Betriebssystemen definiert die Spalte resourcesetname eine Zahl, die einem NUMA-Knoten (Non-Uniform Memory Access) auf dem System entspricht. Das Systemdienstprogramm numactl muss zusätzlich zum Kernel der Version 2.6 mit NUMA-Richtilinienunterstützung verfügbar sein. Weitere Informationen zur NUMA-Unterstützung unter Linux-Betriebssystemen finden Sie in der Man-Page zu numact1.
|Dieses Beispiel zeigt, wie Sie einen NUMA-Computer mit vier Knoten so konfigurieren können, dass jeder logische Knoten einem NUMA-Knoten zugeordnet ist.
|$ numactl --hardwareEs wird eine der folgenden Ausgabe ähnliche Ausgabe angezeigt: |
Verfügbar: 4 Knoten (0-3) |Knoten 0 Größe: 1901 MB |Knoten 0 frei: 1457 MB |Knoten 1 Größe: 1910 MB |Knoten 1 frei: 1841 MB |Knoten 2 Größe: 1910 MB |Knoten 2 frei: 1851 MB |Knoten 3 Größe: 1905 MB |Knoten 3 frei: 1796 MB
0 hostname 0 hostname 0 |1 hostname 1 hostname 1 |2 hostname 2 hostname 2 |3 hostname 3 hostname 3
Die DB2 Universal Database-Registrierdatenbankvariable DB2NOLIOAIO wird ab Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) nicht mehr unterstützt. Für Linux-Benutzer wurde die Registrierdatenbankvariable DB2NOLIOAIO durch DB2LINUXAIO ersetzt.
db2set DB2LINUXAIO=trueStarten Sie DB2 UDB anschließend erneut.
db2set DB2LINUXAIO=falseStarten Sie DB2 UDB anschließend erneut.
Der Anwendungsserver für DB2 Universal Database unterstützt die Fernverwaltung oder gespeicherte Prozeduren nicht mehr.
Aktualisierte Themen:
Durch die Aktivierung der Datenbank werden folgende Aktionen ausgeführt:
Unter Linux müssen Sie nach der Installation des Anwendungsservers und vor dem Aktivieren des Anwendungsservers die Linux-Java-Umgebung konfigurieren. Weitere Informationen zur Konfiguration der Linux-Java-Umgebung finden Sie im Handbuch Application Development Guide: Building and Running Applications.
Gehen Sie wie folgt vor, um den Anwendungsserver für DB2 zu aktivieren:
. /pfad_des_db2-exemplars/sqllib/db2profile
Dabei ist
pfad_des_db2-exemplars
der Pfad, in dem das DB2-Exemplar erstellt wurde.installationspfad_des_anwendungsservers/bin/enable.sh -db aliasname_der_datenbank -user datenbankbenutzer -password datenbankkennwort -db2path pfad_für_sqllib -instance exemplarname -easpath pfad_für_eas -fencedid abgeschirmte_benutzer-id
installationspfad_des_anwendungsservers\bin\enable -db aliasname_der_datenbank -user datenbankbenutzer -password datenbankkennwort -db2path pfad_für_sqllib -instance exemplarname -easpath pfad_für_eas
Nachdem Sie den Anwendungsserver für DB2 UDB aktiviert haben, erfolgt das Starten des Anwendungsservers automatisch.
Der Anwendungsserver sollte mit der abgeschirmten Benutzer-ID für Systeme gestartet werden, die Web-Services in einer .NET-Umgebung erstellen oder ausschließlich XML Metadata Registry (XMR) ausführen.
Dieser Abschnitt wurde entfernt. Der Anwendungsserver für DB2 UDB unterstützt die Fernverwaltung nicht mehr.
Der Anwendungsserver sollte mit der abgeschirmten Benutzer-ID für Systeme gestoppt werden, die Web-Services in einer .NET-Umgebung erstellen oder ausschließlich XML Metadata Registry (XMR) ausführen.
Dieser Abschnitt wurde entfernt. Der Anwendungsserver für DB2 UDB unterstützt die Fernverwaltung nicht mehr.
Dieser Abschnitt wurde entfernt. Der Anwendungsserver für DB2 UDB unterstützt die Fernverwaltung nicht mehr.
Die aktivierte Datenbank eines integrierten Anwendungsservers von DB2 (Embedded Application Server) muss sich in einem 32-Bit-Exemplar befinden. Datenbanken, auf die über DB2 Embedded Application Server zugegriffen wird, können sich in 32-Bit- oder 64-Bit-Exemplaren befinden.
Für Anwendungsserver, die JDK 1.4 verwenden, muss die Variable CLASSPATH nicht mehr während der Implementierung der DB2-Webtools angepasst werden. Alle Abhängigkeiten, einschließlich der für den XML-Parser und das XML-Umsetzungsprogramm, werden nun mit dem Webmodul implementiert und sollten entsprechend der J2EE-Spezifikation aus dem Verzeichnis WEB-INF\lib geladen werden. Diese Änderung betrifft zwei Informationsthemen:
Aktualisierte Themen:
In diesem Abschnitt wird beschrieben, wie die DB2-Webtools (einschließlich der Webbefehlszentrale und der Webdiagnosezentrale) auf BEA WebLogic 7.0 implementiert und konfiguriert werden. Diese Tools können als Webanwendungen auf einem Web-Server ausgeführt werden, um den Zugriff auf DB2-Server über Webbrowser verfügbar zu machen.
Bevor die DB2-Webtools auf WebLogic installiert werden können, müssen die folgenden Voraussetzungen erfüllt sein:
Für die Implementierung der DB2-Webtools gelten die folgenden Einschränkungen:
Gehen Sie wie folgt vor, um die DB2-Webtools auf WebLogic-Anwendungsservern zu installieren:
http://servername:portnummer_des_anwendungsservers/db2waBeispiel: http://servername:7001/db2wa.
In diesem Abschnitt wird beschrieben, wie die DB2-Webtools (einschließlich der Webbefehlszentrale und der Webdiagnosezentrale) auf anderen Anwendungsservern, wie beispielsweise Tomcat 4.0 oder Macromedia JRun 4.0, implementiert und konfiguriert werden. Diese Tools können als Webanwendungen auf einem Web-Server ausgeführt werden, um den Zugriff auf DB2-Server über Webbrowser verfügbar zu machen.
Bevor die DB2-Webtools installiert werden können, müssen die folgenden Voraussetzungen erfüllt sein:
Für die Implementierung der DB2-Webtools gelten die folgenden Einschränkungen:
Im Folgenden wird die Vorgehensweise für die Installation der DB2-Webtools auf Anwendungsservern, wie beispielsweise Tomcat 4.0 oder Macromedia JRun 4.0, beschrieben:
Das Erstellen eines neuen Anwendungsservers wird empfohlen, ist jedoch nicht obligatorisch. Zu Testzwecken kann der Standardserver verwendet werden. In diesem Fall ist es nur erforderlich, den JVM-Klassenpfad zu konfigurieren und die Webtools zu implementieren.
Für Linux-Varianten mit einem 2.6-Kernel wird die direkte Ein-/Ausgabe (Direct I/O) jetzt auf Dateisystemen und auf Blockeinheiten unterstützt. Die direkte Ein-/Ausgabe auf Blockeinheiten ist eine Alternative zum Angeben von Einheitenbehältern für den direkten Plattenzugriff oder zur unformatierten Ein-/Ausgabe. Die Leistung der direkten Ein-/Ausgabe ist äquivalent zur Methode mit unformatierten Zeicheneinheiten. DB2 Universal Database aktiviert die direkte Ein-/Aus- gabe beim Öffnen des Tabellenbereichs, wenn die Anweisung CREATE TABLE- SPACE einen Blockeinheitennamen für den Behälterpfad angibt. Bisher wurde dieselbe Leistung durch die Methode mit unformatierter Ein-/Ausgabe erreicht, bei der die Blockeinheit mit dem Dienstprogramm raw an eine Zeicheneinheit gebunden werden musste.
Unformatierte Ein-/Ausgabe unter Verwendung einer Blockeinheit mit DIO (neue Methode) | Unformatierte Ein-/Ausgabe unter Verwendung eines Zeicheneinheitentreiber und des Dienstprogramms raw (alte Methode) |
---|---|
CREATE TABLESPACE dms1 MANAGED BY DATABASE USING (DEVICE '/dev/sda5' 11170736) |
CREATE TABLESPACE dms1 MANAGED BY DATABASE USING (DEVICE '/dev/raw/raw1' 11170736) |
Obwohl DB2 UDB weiterhin die Verwendung des Dienstprogramms raw für unformatierte Ein-/Ausgabe unterstützt, ist dies in neueren Varianten veraltet und wird in Zukunft möglicherweise ganz entfernt. Die neue Methode, bei der die Einheiten direkt angegeben werden, wird bevorzugt verwendet.
Wenn Sie den direkten Plattenzugriff nutzen wollen, erstellen Sie Ihre DMS-Einheitenbehälter mit direkter Ein-/Ausgabe, um später Probleme bei der Migration zu vermeiden.
Der Dämon für DB2 Information - Unterstützung ist für die Steuerung des DB2-Dokumentationsservers zuständig. Der Dämon, der Teil der Installation von DB2 Information - Unterstützung ist, besteht aus zwei Dateien:
Diese Dateien werden an folgenden Positionen installiert:
/var/db2/v81/db2ic.conf
/var/opt/db2/v81/db2ic.conf
/var/db2/v81/db2ic.conf
/var/db2/v81/db2ic.conf
Sie sollten den Dämon nur manuell starten oder stoppen müssen, wenn Sie die Konfigurationsvariablen für den Dämon ändern wollen. Normalerweise wird der Dämon beim Systemstart gestartet, entsprechend der Ausführungsebenen, die während der Installation von DB2 Information - Unterstützung erstellt wurden.
Gehen Sie wie folgt vor, um den Dämon für DB2 Information - Unterstützung zu stoppen und zu starten:
INIT_DIR/db2icd stop
Dabei ist INIT_DIR das Installationsverzeichnis der Datei db2icd, die oben aufgeführt wird.INIT_DIR/db2icd start
Dabei ist INIT_DIR das Installationsverzeichnis der Datei db2icd, die oben aufgeführt wird.Wenn der Dämon startet, verwendet er die neuen Umgebungsvariablen.
Es gibt auch eine Option zum Beenden und unverzüglichen erneuten Starten des Dämons. Geben Sie in einer Befehlszeile Folgendes ein:
INIT_DIR/db2icd restart
Dabei ist INIT_DIR das Installationsverzeichnis der Datei db2icd, die oben aufgeführt wird.
Sie können den Status des Dämons jederzeit überprüfen. Geben Sie in einer Befehlszeile Folgendes ein:
INIT_DIR/db2icd status
Dabei ist INIT_DIR das Installationsverzeichnis der Datei db2icd, die oben aufgeführt wird. Der Dämon gibt den aktuellen Status zurück und zeigt die ID des Dämonprozesses oder der Dämonprozesse an, wenn er aktiv ist.
Verwenden Sie zur Installation von DB2 Information - Unterstützung Version 8.2 bei Verwendung einer Antwortdatei die folgenden Informationen:
Der folgende Fehlercode ist nur für Windows- und nicht für Linux- und UNIX-Betriebssysteme gültig.
Unter Linux (Kernel Version 2.6 und einige Versionen von 2.4) steht jetzt Unterstützung für asynchrone E/A (AIO) für unformatierte Einheiten und O_DIRECT-Dateisysteme zur Verfügung. AIO verbessert die Leistung der Seitenlöschfunktion. Mit dem Befehl db2set können Sie AIO unter Linux aktivieren oder inaktivieren.
Zur Verwendung von AIO müssen Benutzer libaio-0.3.98 oder eine spätere Version installieren und einen Kernel haben, der AIO unterstützt. Benutzer müssen außerdem den Befehl db2set DB2LINUXAIO=true ausführen und DB2 Universal Database erneut starten.
In früheren Stufen von DB2 Universal Database (UDB) Version 8 erstellte der Befehl db2ln bestimmte DB2-Programmverbindungen unter /usr/lib und /usr/include. Auf Plattformen, auf denen 32-Bit- und 64-Bit-DB2 UDB-Exemplare unterstützt werden, zeigen diese Programmverbindungen standardmäßig auf Bibliotheksdateien oder auf INCLUDE-Dateien in den Verzeichnissen DB2VERZ/lib64 oder DB2VERZ/include64. (Dabei steht DB2VERZ für das Verzeichnis, in dem DB2 UDB Version 8 installiert ist.) Wenn Sie den Standardwert nicht wünschen, können Sie die Bitbreite angeben, indem Sie den Befehl db2ln mit dem Flag -w ausführen:
db2ln -w 32|64
Dadurch wird verhindert, dass auf einigen Plattformen gleichzeitig 32-Bit-Exemplare und 64-Bit-Exemplare von DB2 UDB vorhanden sind.
Ab DB2 UDB Version 8.2 erstellt der Befehl db2ln auf diesen Plattformen in den entsprechenden Verzeichnissen DB2-64-Bit-Bibliotheksprogrammverbindungen. In diesem Fall wird das Flag -w nur zum Auffüllen von /usr/include verwendet. Wenn der Befehl db2ln die Programmverbindungen für DB2 UDB-Bibliotheksdateien erstellt, werden auf unterstützten Plattformen sowohl 32-Bit- als auch 64-Bit-Programmverbindungen erstellt. Dadurch können 32-Bit-Exemplare und 64-Bit-Exemplare vorhanden sein und gleichzeitig ausgeführt werden.
Einige Linux-Varianten enthalten den Entwickungs-RPM libc in der Bibliothek /usr/lib/libdb2.so oder /usr/lib64/libdb2.so. Diese Bibliothek wird für die Implementierung der Datenbank Berkeley DB von Sleepycat Software verwendet und ist nicht IBM DB2 UDB zugeordnet. Diese Datei bewirkt jedoch, dass die Befehle db2ln und db2rmln nicht funktionieren. Der Befehl db2ln setzt die Datei nicht außer Kraft, und der Befehl db2rmln entfernt die Datei nicht. Damit in dieser Situation unter Verwendung von DB2 UDB Anwendungen kompiliert werden können, müssen die Kompilierungs- und Verbindungsprozesse einen vollständigen Pfad zu den Kopfdaten bzw. den Bibliotheken von DB2 UDB bereitstellen. Dies ist die empfohlene Methode, weil dadurch das Kompilieren und Verbinden für mehrere Releases von DB2 UDB auf demselben Computer möglich ist.
Weitere Informationen zu Einschränkungen für den Befehl db2ln finden Sie im Handbuch Installation und Konfiguration von DB2 UDB Version 8.2.
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.
Für DB2 Universal Database (UDB) sind mindestens 256 MB Arbeitsspeicher erforderlich. Für ein System, auf dem nur DB2 UDB und die DB2-GUI-Tools ausgeführt werden, sind mindestens 512 MB Arbeitsspeicher erforderlich. Zur Leistungssteigerung wird jedoch 1 GB Hauptspeicher empfohlen. Speicherbedarf für weitere Software, die auf dem System ausgeführt wird, wird in diesen Angaben nicht berücksichtigt.
|Berücksichtigen Sie bei der Ermittlung des Speicherbedarfs Folgendes:
|Im Thema "Übersicht über DB2-Clients" des Handbuchs IBM DB2 UDB für DB2-Clients Einstieg Version 8.1 heißt es wie folgt:
DB2-Clients können eine Verbindung zu DB2-Servern, die zwei Releases höher bzw. ein Release niedriger als die Client-Release-Stufe liegen, und zu Servern auf derselben Releasestufe herstellen.
Eine Ergänzung zu dieser Aussage lautet wie folgt:
Verbindungen von Clients mit Version N zu Servern mit Version N+2 sind zwar in einigen Umgebungen möglich, diese Konfiguration wird jedoch nur so lange unterstützt, wie Version N vertrieben wird. Sobald Version N nicht mehr vertrieben wird, wird diese Konfiguration nicht mehr unterstützt.DB2-Clients der Version 7, die eine Verbindung zu einem DB2-Server der Version 8 herstellen, werden nicht mehr unterstützt, da DB2 Version 7 vom Markt genommen wurde.
Bevor Sie DB2 UDB installieren, sollten Sie die Linux-Kernelparameter aktualisieren. Die IPC-Begrenzungen werden im Bedarfsfall automatisch von DB2 Universal Database (UDB) erhöht. Sollten Sie jedoch besondere Anforderungen haben, können Sie diese Begrenzungen weiter erhöhen.
Um die Kernelparameter ändern zu können, müssen Sie über Rootberechtigung verfügen.
Um die Kernelparameter zu aktualisieren, gehen Sie wie folgt vor:
Der Befehl ipcs -l gibt die folgende Ausgabe zurück:
# ipcs -l ------ Shared Memory Limits -------- max number of segments = 4096 // SHMMNI max seg size (kbytes) = 262144 // SHMMAX max total shared memory (kbytes) = 8388608 // SHMALL min seg size (bytes) = 1 ------ Semaphore Limits -------- max number of arrays = 1024 // SEMMNI max semaphores per array = 250 max semaphores system wide = 256000 max ops per semop call = 32 semaphore max value = 32767 ------ Messages: Limits -------- max queues system wide = 1024 // MSGMNI max size of message (bytes) = 65535 // MSGMAX default max size of queue (bytes) = 16384 // MSGMNB
Dabei gilt Folgendes:
max semaphores system wide = max number of arrays x max semaphores/array
Ändern Sie die Kernelparameter für Linux-Kernels (32 Bit), indem Sie der standardmäßigen Konfigurationsdatei /etc/sysctl.conf zur Systemsteuerung die folgenden Einträge hinzufügen:
kernel.msgmni = 1024 kernel.sem = "250 256000 32 1024" kernel.shmmax=268435456
Ändern Sie die Kernelparameter für Linux-Kernels (64 Bit), indem Sie der standardmäßigen Konfigurationsdatei /etc/sysctl.conf zur Systemsteuerung die folgenden Einträge hinzufügen:
kernel.msgmni = 1024 kernel.sem = "250 256000 32 1024" kernel.shmmax=1073741824
Führen Sie sysctl mit dem Parameter -p aus, um Einstellungen aus der Standarddatei /etc/sysctl.conf in 'sysctl' zu laden:
sysctl -p
Die Einträge aus der Datei sysctl.conf werden beim Systemstart vom Script für die Netzwerkinitialisierung gelesen.
In einigen Varianten ist es unter Umständen erforderlich, einer der Systeminitialisierungsdateien sysctl -p hinzuzufügen, wie z. B. rc.local, damit Kernelparameter nach jedem Neustart gesetzt werden.
Die folgenden Informationen sind eine Ergänzung des Themas "Modifizieren von Kernelparametern (Solaris-Betriebsumgebung)" im Handbuch DB2 Universal Database für DB2-Server Einstieg:
Für einen ordnungsgemäßen Betrieb von DB2 Universal Database (UDB) wird die Aktualisierung der Kernelkonfigurationsparameter des Systems empfohlen. Sie können über das Dienstprogramm db2osconf empfohlene Einstellungen für die Kernelparameter vorschlagen lassen.
Damit Sie den Befehl db2osconf verwenden können, müssen Sie zuerst DB2 UDB installieren. Das Dienstprogramm db2osconf kann nur über $DB2DIR/bin ausgeführt werden.
Nach der Modifizierung von Kernelparametern muss das System erneut gestartet werden.
IBM DB2 Universal Database Express (DB2 UDB Express) ist das neueste Mitglied der Produktfamilie von DB2 Universal Database Version 8. Es vereint die Leistungsfähigkeit, Funktionalität und Zuverlässigkeit der mehrfach ausgezeichneten relationalen Datenbank DB2 UDB von IBM mit den Vorteilen einer einfachen Konfektionierung, Installation und Implementierung bei minimalen Investitionskosten, um den Bedürfnissen kleiner und mittlerer Unternehmen (Mittelstand) im Bereich Datenmanagement gerecht zu werden.
DB2 UDB Express wurde für Kunden mit minimalem internen Know-how im Bereich Datenbanken entwickelt, die eine einfach zu installierende und in-house in die jeweiligen Anwendungssoftwarelösungen integrierte Datenbank benötigen. Es handelt sich um eine DB2 UDB-Version für mehrere Benutzer, die lokale und ferne Anwendungen in eigenständigen Umgebungen (Standalone-Umgebungen) und LAN-Umgebungen unterstützt.
Wenn Sie weitere Informationen zu DB2 UDB Express benötigen, können Sie die Handbücher DB2 Universal Database Express Edition Einstieg und DB2 Universal Database Express Edition Version 8.2 Basics von der Webseite für DB2 UDB-Produkthandbücher unter http://www.ibm.com/software/data/db2/udb/support/manualsv8.html herunterladen.
Der folgende Voraussetzungsabschnitt ist in Version 8.2 in dem Thema dokumentiert, das die Prüfung Ihrer Datenbanken auf Bereitschaft für die Migration erklärt.
Diese Voraussetzung ist jedoch ein Schritt, der nach der Migration am Ende der Prozedur ausgeführt wird.
Die bestätigten Informationen für DB2 UDB-Konfigurationen, die für Common Criteria zertifiziert wurden, finden Sie unter http://niap.nist.gov/cc-scheme.
Das Beispielprogramm runGseDemo kann verwendet werden, um sich mit der Anwendungsprogrammierung für DB2 Spatial Extender vertraut zu machen. Eine Beschreibung der Schritte, die das Beispielprogramm ausführt, um eine Datenbank zu erstellen, die räumliche Daten verarbeiten kann, und eine räumliche Analyse von Daten in dieser Datenbank auszuführen, finden Sie in dem Thema mit dem Titel "Beispielprogramm von DB2 Spatial Extender". Dieses Thema finden Sie in DB2 Information - Unterstützung und dem Handbuch Spatial Extender und Geodetic Extender Benutzer- und Referenzhandbuch.
DB2 Spatial Extender stellt ein weiteres Beispielprogramm, seBankDemoRunBankDemo, zur Verfügung, das veranschaulicht, wie einem vorhandenen Informationssystem Funktionalität für räumliche Daten hinzugefügt wird.
Weitere Informationen zu beiden Beispielprogrammen finden Sie in den Readme-Dateien in folgenden Verzeichnissen:
~\sqllib\samples\spatial ~\sqllib\samples\spatial\bank
~/sqllib/spatial ~/sqllib/spatial/bank
Im Thema "Tabellenfunktion SNAP_GET_DYN_SQL" in Information - Unterstützung der Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) wird die Ergebnismenge für die Tabellenfunktion SNAP_GET_DYN_SQL falsch beschrieben.
Eine der Spalten wird fälschlicherweise als STMT_TXT bezeichnet.
Der richtige Name der Ausgabespalte lautet STMT_TEXT.
Versionsspezifische Sichten wurden für die folgenden Snapshot Monitor-Tabellenfunktionen definiert, die in DB2 Universal Database Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) eingeführt werden:
Die versionsspezifischen Sichten lauten wie folgt:
Da es keine Garantie dafür gibt, dass die Ergebnistabellen der Snapshot Monitor-Tabellenfunktionen von Release zu Release nicht geändert werden, wird die Verwendung von versionsspezifischen Sichten empfohlen, wenn Sie Ergebnistabellen bevorzugen, die garantiert nicht geändert werden. Jede Sicht enthält alle Spalten der Ergebnistabelle der zugehörigen Snapshot Monitor-Tabellenfunktion.
Die Prozedur GET_DB_CONFIG erfordert einen temporären Benutzertabellenbereich mit einer Seitengröße von mindestens 8 KB.
Das Beispiel zur Verwendung der Prozedur GET_DB_CONFIG muss durch das folgende Beispiel ersetzt werden.
Ändern Sie mit Hilfe des Befehlszeilenprozessors (CLP - Command Line Processor) den Wert der Datenbankkonfigurationsparameter logretain und userexit. Rufen Sie die Originalwerte (auf der Festplatte) sowie die aktualisierten Werte (im Speicher) ab, indem Sie die Prozedur GET_DB_CONFIG aufrufen.
UPDATE DB CFG USING LOGRETAIN RECOVERY USEREXIT YES CALL SYSPROC.GET_DB_CONFIG()
Das folgende Beispiel zeigt einen Teil der Ausgabe dieses Prozeduraufrufs:
Ergebnismenge 1 -------------- DBCONFIG_TYPE ... LOGRETAIN ... USEREXIT... ------------- ----------- ----------- 0 1 1 1 0 0 2 Satz/Sätze ausgewählt. Rückgabestatus = 0
Die Tabelle EXPLAIN_DIAGNOSTIC enthält einen Eintrag für jede Diagnosenachricht, die für ein bestimmtes Exemplar einer mit EXPLAIN bearbeiteten Anweisung in der Tabelle EXPLAIN_STATEMENT erstellt wurde.
Die Tabellenfunktion EXPLAIN_GET_MSGS fragt die EXPLAIN-Tabellen EXPLAIN_DIAGNOSTIC und EXPLAIN_DIAGNOSTIC_DATA ab und gibt formatierte Nachrichten zurück.
Spaltenname | Datentyp | Dateneingabe optional | Schlüssel 1 | Beschreibung |
---|---|---|---|---|
EXPLAIN_REQUESTER | VARCHAR(128) | Nein | PS, FS | Berechtigungs-ID des Initiators dieser EXPLAIN-Anforderung. |
EXPLAIN_TIME | TIMESTAMP | Nein | PS, FS | Startzeit der EXPLAIN-Anforderung. |
SOURCE_NAME | VARCHAR(128) | Nein | PS, FS | Name des Pakets, das ausgeführt wird, als die dynamische Anweisung mit EXPLAIN bearbeitet wurde, oder der Name der Quellendatei, als das statische SQL mit EXPLAIN bearbeitet wurde. |
SOURCE_SCHEMA | VARCHAR(128) | Nein | PS, FS | Schema oder Qualifikationsmerkmal der Quelle der EXPLAIN-Anforderung. |
SOURCE_VERSION | VARCHAR(64) | Nein | PS, FS | Version der Quelle der EXPLAIN-Anforderung. |
EXPLAIN_LEVEL | CHAR(1) | Nein | PS, FS | Ebene der EXPLAIN-Informationen, für die diese Zeile relevant ist.
Gültige Werte:
|
STMTNO | INTEGER | Nein | PS, FS | Nummer der Anweisung in einem Paket, zu der diese EXPLAIN-Informationen gehören. Wird für Dynamic Explain-SQL-Anweisungen auf 1 gesetzt. Für statische SQL-Anweisungen ist dieser Wert mit dem Wert identisch, der für die Katalogsicht SYSCAT.STATEMENTS verwendet wird. |
SECTNO | INTEGER | Nein | PS, FS | Nummer des Abschnitts in einem Paket, der diese SQL-Anweisung enthält. Für Dynamic Explain-SQL-Anweisungen ist dies die Nummer des Abschnitts, der den Abschnitt für diese Anweisung während der Ausführung enthält. Für statische SQL-Anweisungen ist dieser Wert mit dem Wert identisch, der für die Katalogsicht SYSCAT.STATEMENTS verwendet wird. |
DIAGNOSTIC_ID | INTEGER | Nein | PK | ID der Diagnosedaten für ein bestimmtes Exemplar einer Anweisung in der Tabelle EXPLAIN_STATEMENT. |
CODE | INTEGER | Nein | Nein | Eine eindeutige Nummer, die jeder Diagnosenachricht zugeordnet ist. Die Nummer kann von einer Nachrichten-API verwendet werden, um den vollständigen Text der Diagnosenachricht abzurufen. |
|
Die Tabelle EXPLAIN_DIAGNOSTIC_DATA enthält Nachrichtentoken für bestimmte Diagnosenachrichten, die in der Tabelle EXPLAIN_DIAGNOSTIC eingetragen sind. Die Nachrichtentoken enthalten zusätzliche Informationen zur Ausführung der SQL-Anweisung, die die Nachricht generiert hat.
Die Tabellenfunktion EXPLAIN_GET_MSGS fragt die EXPLAIN-Tabellen EXPLAIN_DIAGNOSTIC und EXPLAIN_DIAGNOSTIC_DATA ab und gibt formatierte Nachrichten zurück.
Spaltenname | Datentyp | Dateneingabe optional | Schlüssel 1 | Beschreibung |
---|---|---|---|---|
EXPLAIN_REQUESTER | VARCHAR(128) | Nein | FS | Berechtigungs-ID des Initiators dieser EXPLAIN-Anforderung. |
EXPLAIN_TIME | TIMESTAMP | Nein | FS | Startzeit der EXPLAIN-Anforderung. |
SOURCE_NAME | VARCHAR(128) | Nein | FS | Name des Pakets, das ausgeführt wird, als die dynamische Anweisung mit EXPLAIN bearbeitet wurde, oder der Name der Quellendatei, als das statische SQL mit EXPLAIN bearbeitet wurde. |
SOURCE_SCHEMA | VARCHAR(128) | Nein | FS | Schema oder Qualifikationsmerkmal der Quelle der EXPLAIN-Anforderung. |
SOURCE_VERSION | VARCHAR(64) | Nein | FS | Version der Quelle der EXPLAIN-Anforderung. |
EXPLAIN_LEVEL | CHAR(1) | Nein | FS | Ebene der EXPLAIN-Informationen, für die diese Zeile relevant ist.
Gültige Werte:
|
STMTNO | INTEGER | Nein | FS | Nummer der Anweisung in einem Paket, zu der diese EXPLAIN-Informationen gehören. Wird für Dynamic Explain-SQL-Anweisungen auf 1 gesetzt. Für statische SQL-Anweisungen ist dieser Wert mit dem Wert identisch, der für die Katalogsicht SYSCAT.STATEMENTS verwendet wird. |
SECTNO | INTEGER | Nein | FS | Nummer des Abschnitts in einem Paket, der diese SQL-Anweisung enthält. Für Dynamic Explain-SQL-Anweisungen ist dies die Nummer des Abschnitts, der den Abschnitt für diese Anweisung während der Ausführung enthält. Für statische SQL-Anweisungen ist dieser Wert mit dem Wert identisch, der für die Katalogsicht SYSCAT.STATEMENTS verwendet wird. |
DIAGNOSTIC_ID | INTEGER | Nein | PK | ID der Diagnosedaten für ein bestimmtes Exemplar einer Anweisung in der Tabelle EXPLAIN_STATEMENT. |
ORDINAL | INTEGER | Nein | Nein | Position des Tokens im vollständigen Nachrichtentext. |
TOKEN | VARCHAR(1000) | Ja | Nein | Nachrichtentoken, das in einen vollständigen Nachrichtentext eingefügt werden soll; ist möglicherweise abgeschnitten. |
TOKEN_LONG | BLOB(3M) | Ja | Nein | Genauere Informationen, sofern verfügbar. |
|
Die EXPLAIN-Einrichtung verwendet die folgenden IDs als Schema für die Qualifizierung der EXPLAIN-Tabellen, die gefüllt werden:
Das Schema kann einer Gruppe von EXPLAIN-Tabellen oder Aliasnamen zugeordnet werden, die auf eine Gruppe von EXPLAIN-Tabellen in einem anderen Schema zeigen.
Wenn unter dem Schema keine EXPLAIN-Tabellen gefunden werden, sucht die EXPLAIN-Einrichtung im Schema SYSTOOLS nach EXPLAIN-Tabellen und versucht, diese zu verwenden.
Eine Zeichenfolgedarstellung einer Zeit ist eine Zeichenfolge, die mit einer Ziffer beginnt und mindestens vier Zeichen hat. Folgende Leerzeichen können eingeschlossen werden; eine führende Null kann in dem Teil der Zeit, der die Stunde angibt, ausgelassen werden, und Sekunden können vollständig ausgelassen werden. Wenn Sekunden ausgelassen werden, wird eine implizite Angabe von null Sekunden angenommen. 13:30 ist also äquivalent zu 13:30:00.
In der folgenden Tabelle werden gültige Zeichenfolgeformate für Zeiten aufgelistet. Jedes Format wird mit einem Namen und einer zugeordneten Abkürzung angegeben.
Formatname | Abkürzung | Zeitformat | Beispiel |
---|---|---|---|
International Standards Organization | ISO | hh.mm.ss | 13.30.05 |
IBM USA-Standard | USA | hh:mm AM oder PM | 1:30 PM |
Europäischer IBM Standard | EUR | hh.mm.ss | 13.30.05 |
Japanese Industrial Standard (christliche Zeitrechnung) | JIS | hh:mm:ss | 13:30:05 |
Site-definiert | LOC | Abhängig vom Gebietscode der Anwendung | - |
Ab Version 8.2 können "AM" und "PM" in Kleinbuchstaben oder in Großbuchstaben dargestellt werden.
Im Thema "Diagnoseanzeiger - Zusammenfassung" in DB2 Information - Unterstützung für Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) wird als ID für den Diagnoseanzeiger der Auslastung des dynamischen Datenbankspeichers fälschlicherweise db.db_auto_storage_util angegeben.
Die richtige ID für den Diagnoseanzeiger der Auslastung des dynamischen Datenbankspeichers lautet db.auto_storage_util.
Es ist möglich, dass beim Absetzen des Befehls list applications Anwendungen ohne Verbindung angezeigt werden, selbst wenn der Verbindungskonzentrator nicht aktiviert ist.
Die Fortschrittsüberwachung des Laufzeit-ROLLBACK-Prozesses stellt Fortschrittsinformationen zu ROLLBACK-Ereignissen anhand von Anwendungsmomentauf- nahmen zur Verfügung. Es gibt zwei Typen von ROLLBACK-Ereignissen:
Die zur Verfügung gestellten Informationen umfassen die Startzeit des ROLLBACK-Ereignisses, die gesamte auszuführende Arbeit sowie die abgeschlossene Arbeit. Die Messgröße für die Arbeit ist Byte.
Die Einheiten von Gesamte Arbeit geben den Bereich im Protokolldatenstrom an, der für die Transaktion oder den Sicherungspunkt rückgängig gemacht werden muss.
Die Einheiten von Abgeschlossene Arbeit zeigen die relative Position der Daten im Protokolldatenstrom an, die rückgängig gemacht wurden.
Aktualisierungen an Abgeschlossene Arbeit werden nach der Verarbeitung jedes Protokollsatzes vorgenommen. Aktualisierungen werden nicht regelmäßig ausgeführt, da die Protokollsätze unterschiedliche Größen haben.
Momentaufnahme einer Anwendung Anwendungskennzeichen = 6 Anwendungsstatus = ROLLBACK-Operation aktiv Startzeit = 20/02/2004 12:49:27.713720 Abgeschlossene Arbeit = 1024000 Byte Gesamte Arbeit = 4084000 Byte Momentaufnahme einer Anwendung Anwendungskennzeichen = 10 Anwendungsstatus = Ausführung von Rollback zum Sicherungspunkt Startzeit = 20/02/2004 12:49:32.832410 Abgeschlossene Arbeit = 102400 Byte Gesamte Arbeit = 2048000 Byte
Für die folgenden gespeicherten Prozeduren hat sich die Beschreibung des Parameters override geändert:
|| |Die Änderung lautet wie folgt:
|Parameter | |Beschreibung | |IN/OUT-Parameter | |
---|---|---|
override | |Überschreibt die Bedingung in der DAD-Datei. Der Eingabewert basiert auf overrideType.
|
|
|IN | |
Über die RDB_node-Zuordnung wird bei der Zerlegung angegeben, wie durch Extrahieren der Element- und Attributwerte und durch Speichern dieser Werte in Tabellenzeilen ein XML-Dokument in einzelne DB2 UDB-Tabellen zerlegt wird. Die Werte aus den einzelnen XML-Dokumenten werden in mindestens einer DB2 UDB-Tabelle gespeichert. Jede Tabelle kann maximal 10240 Zeilen aufweisen, die aus jedem Dokument durch Zerlegung gewonnen werden.
|Wenn z. B. ein XML-Dokument in fünf Tabellen zerlegt wird, kann jede der fünf Tabellen bis zu 10240 Zeilen für dieses eine Dokument aufweisen. Wenn die Tabelle Zeilen für mehrere Dokumente enthält, kann Sie bis 10240 Zeilen für jedes Dokument aufweisen.
|Das mehrfache Vorkommen von Elementen (Elementen mit Standortpfaden, die in der XML-Struktur mehrmals vorkommen können) wirkt sich auf die Anzahl der Zeilen aus. Ein Dokument, das z. B. das Element <Part> 20 Mal enthält, kann in einer Tabelle in 20 Zeilen zerlegt werden. Wenn Sie mehrfach vorkommende Elemente verwenden, müssen Sie beachten, dass aus einem Dokument maximal 10240 Zeilen in einer einzige Tabelle zerlegt werden können.
Sie müssen die gespeicherte Prozedur dxxShredXML nicht löschen und erneut erstellen, um Dokumente zu zerlegen, die größer als 1 MB sind. Wenn Sie Dokumente zerlegen möchten, die größer als 1 MB sind, rufen Sie die gespeicherte Prozedur dxxShredXML100MB auf, die bis zu 100 MB große Dokumente zerlegen kann. Obwohl dxxShredXML100MB große Dokumente verarbeiten kann, müssen Sie u. U. andere Ressourcen vergrößern, um diese gespeicherte Prozedur erfolgreich ausführen zu können. Zum Aufruf der gespeicherten Prozedur über das Beispielprogramm dxxshrd können Sie das neue Flag "-large" verwenden. Beispiel:
dxxshrd -large meine_db xxx.xml
Wenn Ihre Version von DB2 Universal Database älter als Version 8 FixPak 6 ist, müssen Sie dxxMigv ausführen, um XML Extender auf die aktuelle Stufe zu migrieren und die neue gespeicherte Prozedur ausführen zu können.
Sie müssen benutzerdefinierte MQ-XML-Funktionen (UDFs) konfigurieren und aktivieren, bevor Sie sie verwenden können.
Installieren Sie die benutzerdefinierten Funktionen anhand der Prozedur im Thema "DB2 WebSphere MQ-Funktionen installieren" in DB2 Information - Unterstützung bzw. im entsprechenden Abschnitt des Handbuchs IBM DB2 Information Integrator Application Developer's Guide.
Gehen Sie wie folgt vor, um benutzerdefinierte MQ-XML-Funktionen mit XML Extender zu konfigurieren und zu aktivieren:
db2 connect to <datenbank>
db2 bind @dbxxbind.lst
db2 bind mqxml.bnd
db2 bind @db2cli.lst
DB2 XML Extender kann große Dokumente in temporären Dateien speichern, damit der Speicherbedarf während der Verarbeitung nicht zu hoch ist. Bei Systemen mit einer hohen physischen Speicherkapazität kann das Versetzen von Dokumenten in temporäre Dateien vermieden werden, so dass die Ein-/Ausgabeakti- vität reduziert wird. Die Umgebungsvariable DB2DXX_MIN_TMPFILE_SIZE veranlasst XML Extender dazu, zur Verarbeitung von Dokumenten, die kleiner sind als der angegebene Wert, anstelle von temporären Dateien Speicherpuffer zu verwenden. Die Variable ist nur auf dem Server gültig. Wenn in einer partitionierten Umgebung mehrere physische Knoten vorhanden sind, kann die Variable für jeden Knoten anders gesetzt werden, um die Speicherkapazität jedes Computers korrekt wiederzugeben. Wenn die Umgebungsvariable nicht gesetzt ist, werden Dokumente mit einer Größe von mehr als 128 KB während der Verarbeitung automatisch in temporären Dateien gespeichert. Dokumente, die kleiner als 128 KB sind, werden im Hauptspeicher verarbeitet.
Sie können den benutzerdefinierten Datentyp (User-Defined Type - UDT) DB2XML.XMLVarchar auf bis zu 32 KB erneut definieren. Zum Ändern der Größe eines benutzerdefinierten XMLVarchar-Datentyps erstellen Sie den benutzerdefinierten Datentyp, bevor Sie die Datenbank für XML Extender aktivieren.
Weitere Informationen finden Sie im Handbuch DB2 XML Extender Verwaltung und Programmierung.
[ Seitenanfang |Vorherige Seite | Inhaltsverzeichnis ]