Probleme beim Datenzugriff - DB2-Datenbank
Dieser Artikel enthält Tipps zur Fehlerbehebung beim Zugriff auf DB2-Datenbanken.
Welches Problem tritt beim Zugriff auf die DB2-Datenbank auf?
- Kerberos-Anmeldefehler während der Verbindungsherstellung zur Datenbank
- SQL0567N "DB2ADMIN" is not a valid authorization ID. SQLSTATE=42602
- SQL0805N Package package-name was not found
- SQL0805N Package "NULLID.SQLLC300" was not found. SQLSTATE=51002
- SQL30082N Attempt to establish connection failed with security reason "17" ("UNSUPPORTED FUNCTION") SQLSTATE=08001
- SQL-Ausnahmebedingung mit Fehlercode -99,999; SQLState 58004; Java StaleConnectionException: COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] CLI0119E Unexpected system failure.
- Fehlernachricht java.lang.reflect.InvocationTargetException: com.ibm.ws.exception.WsException: DSRA0023E
- CLI0119E System error
- COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0911N
- "COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource“ could not be found for data source ("[data-source-name]“)"
Error 10500 (E_Fatal) returns when an attempt is made to either publish or inquire on an entity exceeding 255 characters in one of its fields.
- java.sql.SQLException: Failure in loading T2 native library db2jcct2 DSRA0010E: SQL State = null, Error Code = -99,999
- Es tritt eine Ausnahme vom Typ Zugriffskonflikt in der Datenbank ein, wenn die Implementierung der Datenquelle den Typ XA hat.
- Ausnahme “DSRA8050W: Die angegebene DataStoreHelper-Klasse wurde nicht gefunden“ tritt ein, wenn Sie versuchen, eine DB2 Universal Datasource in einer Zelle mit unterschiedlichen Releases zu verwenden.
- Nachricht "'SYSTEM' is not a valid authorization ID" wird angezeigt beim Versuch, auf einer Windows-Maschine, auf der auch WebSphere Application Server installiert ist, auf DB2 zuzugreifen
- XAException: XAER_NOTA on XA prepare call in DB2 Universal JDBC Driver type 4 after one phase transaction rollback
- Ausnahme des Typs java.rmi.MarshalException für Anwendungsclient aufgrund der Inkompatibilität der Versionen der JDBC-Treiberdateien
- Datenbankfehler löst kritische Ausnahme -99999 für Anwendungen aus, die den Treiber für DB2 Universal Typ 4 verwenden
- Zugriff auf DB2 bei Verwendung des JDBC-Treibers für DB2 Universal unter Linux nicht möglich
- Ungültige Konvertierung in der Spalte VARCHAR FOR BIT DATA für CMP-Beans
Kerberos-Anmeldefehler während der Verbindungsherstellung zur Datenbank
- Die Injektionsanweisungen in einer Bean der Enterprise JavaBeans (EJB) Version 3.0 arbeiten auf Attributebene.
- Die Datei persistence.xml sendet keine Metadateninformationen zu der Datenbank, zu der eine Verbindung hergestellt wird.
- Der komponentengesteuerte Alias in der Datenquelle ist nicht gültig.
- Die Datenbank ist so konfiguriert, dass ein aktivierbarer und inaktivierbarer Sicherheitsmechanismus verwendet wird, z. B. ein anderer Mechanismus als der Mechanismus mit Benutzer-ID und Kennwort, z. B. kerberos.
Während der Injektion einer Bean der EJB Version 3.0 versucht die JPA-Datei (Java Persistence API) persistence.xml, eine Verbindung zur Datenbank herzustellen, um Metadaten zu suchen. Zum Herstellen der Verbindung fordert ein Java 2 Connector (J2C) ein Subject-Objekt aus dem Sicherheitskontext an. In diesem Szenario wurde die API für Sicherheits-Collaboration, die zum Speichern von Informationen im Sicherheitskontext verwendet wird, nicht aufgerufen, und das Subject-Objekt wurde ohne GSSCredentials-Berechtigungsnachweise zurückgegeben.
Der Aufruf hätte eigentlich im EJB-Container stattfinden müssen, aber der EJB-Container hat die Collaboration-API nicht aufgerufen, weil die Sicherheits-APIs eine vollständige Bean erfordern, die nicht vorhanden ist. Außerdem ist in der Spezifikation EJB 3.0 explizit angegeben, dass die Bean-Erstellung nicht in einem definierten Sicherheitskontext vorgenommen werden darf. Aufgrund des Designs der Sicherheits-API und der Anweisung in der Spezifikation EJB 3.0 hat der EJB-Container die APIs für Sicherheits-Collaboration nicht aufgerufen. Deshalb wusste der Sicherheitskontext nicht, wie er das Subject-Objekt konfigurieren sollte, und darum enthält das Objekt keine GSSCredentials-Berechtigungsnachweise.
Das Fehlen der GSSCredentials-Berechtigungsnachweise bewirkt, dass die RRA-Implementierung (Relational Resource Adapter) den falschen Codepfad verwendet. Anstatt DB2 anzuweisen, die Verbindung über die GSSCredential-Berechtigungsnachweise herzustellen, verwendet die Implementierung die Identität, die dem komponentengesteuerten Alias zugeordnet ist. Das Ergebnis ist, dass der komponentengesteuerte Alias als Identität konfiguriert wird, die kerberos nicht bekannt ist. Deshalb tritt ein Fehler auf, wenn der DB2-Treiber diese Identität an die Datenbank weitergibt.
Caused by: javax.security.auth.login.FailedLoginException: Login error: com.ibm.security.krb5.KrbException, status code: 6
message: Client not found in Kerberos database
at com.ibm.security.jgss.i18n.I18NException.throwFailedLoginException(I18NException.java:25)
at com.ibm.security.auth.module.Krb5LoginModule.b(Krb5LoginModule.java:733)
at com.ibm.security.auth.module.Krb5LoginModule.c(Krb5LoginModule.java:610)
at com.ibm.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:433)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:795)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:209)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:709)
at java.security.AccessController.doPrivileged(AccessController.java:251)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:706)
at javax.security.auth.login.LoginContext.login(LoginContext.java:603)
at com.ibm.db2.jcc.a.ud.a(ud.java:25)
- Stellen Sie sicher, dass die Injektionsanweiungen für die "Klassenebene" gelten.
Dies hindert Sie zu versuchen, die Injektion vorzunehmen, wenn die Bean erstellt wird. Die Persistenzkontextelemente werden weiterhin in Java Naming and Directory Interface (JNDI) gespeichert, aber nicht in lokalen Variablen im Bean-Objekt. Die Bean-Methode sucht diese Persistenzkontextobjekte in JNDI, und zu diesem Zeitpunkt sollte die Bean im richtigen Sicherheitskontext ausgeführt werden, weil der EJB-Container die APIs für Sicherheits-Collaboration aufgerufen hat.
- Lassen Sie die Datei persistence.xml die Metadateninformationen der Datenbank senden.
Wenn die Datei persistence.xml die erforderlichen Metadateninformationen der Datenbank sendet, muss JPA keine Verbindung zur Datenbank herstellen, um diese Informationen abzurufen. Das bedeutet, die Verbindung wird erst hergestellt, wenn auf die Bean-Methode zugegriffen wird. Durch diesen Schritt wird der Sicherheitskontext ordnungsgemäß eingerichtet, und die Verbindung funktioniert.
- Validieren Sie den komponentengesteuerten Alias in der Datenquelle.
Wenn JPA versucht, eine Verbindung zur Datenbank herzustellen, um Metadaten zu erfassen, greift der Treiber auf den komponentengesteuerten Alias zurück, der in der Datenquelle definiert ist, weil der Sicherheitskontext nicht konfiguriert wurde. Wenn Sie sicherstellen, dass der komponentengesteuerte Alias validiert wird, ist die Verbindung erfolgreich.
- Verwenden Sie keinen aktivierbaren und inaktivierbaren Sicherheitsmechanismus für die Datenbanksicherheit.
Dies ist keine Option, wenn Sie einen aktivierbaren und inaktivierbaren Sicherheitsmechanis, wie z. B. kerberos, verwenden möchten. Dieses Problem tritt nicht auf, wenn die Datenbank nicht so konfiguriert ist, dass sie die Standardbenutzer-ID und das zugehörige Kennwort akzeptiert. Dieses Problem tritt nur auf, wenn Ihr System eine spezielle Sicherheitskonfiguration erfordert.
SQL0567N "DB2ADMIN" is not a valid authorization ID. SQLSTATE=42602
- Überprüfen Sie den Benutzernamen und das Kennwort auf der Seite für die Datenquelleneigenschaften in der Administrationskonsole.
- Vergewissern Sie sich, dass die Benutzer-ID und das Kennwort keine Leerzeichen enthalten (davor, dazwischen oder dahinter).
SQL0805N Package package-name was not found
- Wenn der Paketname NULLID.SQLLC300 ist, ziehen Sie die Nachricht SQL0805N Package "NULLID.SQLLC300" was not found. SQLSTATE=51002. zu Rate.
- Sie versuchen, einen XA-fähigen JDBC-Treiber für eine DB2-Datenbank zu verwenden, die XA nicht unterstützt.
- DB2 bind @db2ubind.lst blocking all grant public
- DB2 bind @db2cli.lst blocking all grant public
Die Dateien db2ubind.lst und db2cli.lst sind im Verzeichnis bnd des DB2-Installationsstammverzeichnisses gespeichert. Führen Sie die Befehle aus diesem Verzeichnis heraus aus.
SQL0805N Package "NULLID.SQLLC300" was not found. SQLSTATE=51002
- Die zugrunde liegende Datenbank wurde gelöscht und erneut erstellt.
- DB2 wurde aktualisiert, und die Pakete wurden nicht ordnungsgemäß erneut gebunden.
Sie können dieses Problem beheben, indem Sie die DB2-Pakete mit dem Script db2cli.lst im Verzeichnis bnd erneut binden. Beispiel: db2>@db2cli.lst.
SQL30082N Attempt to establish connection failed with security reason "17" ("UNSUPPORTED FUNCTION") SQLSTATE=08001
- Der Client sendet ein neues Kennwort an einen Server, der die Funktion für das Ändern von Kennwörtern nicht unterstützt.
- Der Client sendet Authentifizierungsdaten für SERVER_ENCRYPT an einen Server, der keine Kennwortverschlüsselung unterstützt.
- Der Client sendet eine Benutzer-ID, aber kein Kennwort an einen Server, der die Authentifizierung auf Basis einer Benutzer-ID allein nicht unterstützt.
- Der Client hat keinen Authentifizierungstyp angegeben, und der Server hat nicht mit einem unterstützten Typ geantwortet. Der Server kann mehrere Typen zurückgegeben, die der Client alle nicht wählen kann.
Stellen Sie zur Behebung dieses Fehlers sicher, dass Client und Server denselben Sicherheitsmechanismus verwenden. Wenn beispielsweise ein Fehler in der Datenquelle auftritt, vergewissern Sie sich, dass eine Benutzer-ID und ein Kennwort oder ein Authentifizierungsalias zugeordnet wurden.
SQL-Ausnahmebedingung mit Fehlercode -99,999; SQLState 58004; Java StaleConnectionException: COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] CLI0119E Unexpected system failure.
SQL-Ausnahmebedingung mit Fehlercode -99,999; SQLState 58004; Java™ "StaleConnectionException: COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] CLI0119E Unexpected system failure. SQLSTATE=58004" bei Verwendung einer Datenquelle vom Typ WAS40
- Ein ungültiger Benutzername oder ein ungültiges Kennwort wurde angegeben.
- Der Datenbankname ist falsch.
- Einige DB2-Pakete sind beschädigt.
2002-07-26-14.19.32.762905 Instance:db2inst1 Node:000
PID:9086(java) Appid:*LOCAL.db2inst1.020726191932
XA DTP Support sqlxa_open Probe:101
DIA4701E Database "POLICY2" could not be opened for distributed transaction processing.
String Title: XA Interface SQLCA PID:9086 Node:000
SQLCODE = -1403
- Korrigieren Sie Benutzernamen und Kennwort. Wenn Sie Ihr Kennwort in der GUI für eine Datenquelle eingeben, müssen Sie sicherstellen, dass die Angaben für die Bean korrekt sind. Der Benutzername und das Kennwort, das sie für die Bean angeben, überschreiben die Angaben, die Sie beim Erstellen der Datenquellen angegeben haben.
- Verwenden Sie den richtigen Datenbanknamen.
- Binden Sie die Pakete (im Verzeichnis bnd) wie folgt erneut:
db2connect to dbname c:\SQLLIB\bnd>DB2 bind @db2ubind.lst blocking all grant public c:\SQLLIB\bnd>DB2 bind @db2cli.lst blocking all grant public
- Vergewissern Sie sich, dass für \WebSphere\AppServer\properties\wsj2cdpm.properties die richtige Benutzer-ID und das richtige Kennwort angegeben wurden.
Fehlernachricht java.lang.reflect.InvocationTargetException: com.ibm.ws.exception.WsException: DSRA0023E
Beim Versuch, auf eine DB2-Datenbank zuzugreifen, erscheint die Fehlernachricht "java.lang.reflect.InvocationTargetException: com.ibm.ws.exception.WsException: DSRA0023E: Die DataSource-Implementierungsklasse "COM.ibm.db2.jdbc.DB2XADataSource" wurde nicht gefunden."
Eine mögliche Ursache für diese Ausnahme ist, dass ein Benutzer versucht, auf eine JDBC-2.0-Datenquelle zuzugreifen, DB2 jedoch nicht für JDBC 2.0 aktiviert ist. Dieser Fall tritt häufig bei Neuinstallationen von DB2 ein, da DB2 unterschiedliche Treiber für JDBC 1.X und 2.0 mit demselben physischen Dateinamen verwendet. Standardmäßig ist der Treiber für JDBC 1.X im Klassenpfad enthalten.
- Suchen Sie auf Windows-Systemen im Verzeichnis java12 des DB2-Installationsstammverzeichnisses nach der Datei inuse. Sollte diese Datei nicht vorhanden sein, verwenden Sie den Treiber für JDBC 1.x.
- Betriebssysteme wie AIX oder Linux überprüfen den Klassenpfad Ihrer Datenquelle. Sollte der Klassenpfad nicht auf die Datei db2java.zip im Verzeichnis java12 verweisen, verwenden Sie den Treiber für JDBC 1.x.
- Auf Windows-Systemen müssen Sie DB2 stoppen. Führen Sie usejdbc2.bat im Verzeichnis java12 des DB2-Installationsstammverzeichnisses aus. Setzen Sie diese Datei in einer Befehlszeile ab, um sicherzustellen, dass er ausgeführt wird.
- Ändern Sie unter Betriebssystemen wie AIX oder Linux den Klassenpfad für die Datenquelle so, dass er auf die Datei db2java.zip im Verzeichnis java12 Ihres DB2-Installationsstammverzeichnisses zeigt.
CLI0119E System error
CLI0119E System error. SQLSTATE=58004 - DSRA8100:
XAconnection kann nicht abgerufen werden oder DSRA0011E: Ausnahme:
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI
Driver] CLI0119E Unexpected system failure. SQLSTATE=5800
- Vergewissern Sie sich auf der Administrationskonsolseite mit Eigenschaften für die Datenquelle, dass der korrekte Datenbankname für die Datenquelle definiert wurde.
- Überprüfen Sie auf der Seite mit den angepassten Eigenschaften Ihren Benutzernamen und Ihr Kennwort. Vergewissern Sie sich, dass die Angaben richtig sind.
- Vergewissern Sie sich, dass die Benutzer-ID und das Kennwort keine Leerzeichen enthalten, weder vor noch in noch hinter der Angabe.
- Stellen Sie sicher, dass die Datei WAS.policy für die Anwendung vorhanden ist, z. B. D:\WebSphere\AppServer\installedApps\markSection.ear\META-INF\was.policy.
- Zeigen Sie alle Ausnahmen für einen zugrunde liegenden SQL-Fehler an, und bearbeiten Sie ihn anhand der Nachrichtenreferenz des DBM-Lieferanten.
Wenn dieser Fehler während der Ausführung von DB2 unter Red Hat Linux ausgegeben wird, ist der Wert des Parameters max queues system wide zu klein für DB2, um die erforderlichen Ressourcen für die Durchführung der Transaktion anzufordern. Wenn dieses Problem vorhanden ist, können die Ausnahmen J2CA0046E und DSRA0010E vor der Ausnahme DSRA8100E angezeigt werden.
Möchten Sie diesen Fehler beheben, müssen Sie die Datei /proc/sys/kernal/msgmni editieren und den Wert für den Parameter max queues system wide mit einer Zahl größer als 128 angeben.
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0911N
ERROR CODE: -911
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0911N
The current transaction has been rolled back because of a deadlock or timeout.
Reason code "2". SQLSTATE=40001
- Führen Sie die folgenden DB2-Befehle aus:
- db2 update monitor switches using LOCK ON
- db2 get snapshot for LOCKS on dbName >
- Aktivieren Sie den Sperrenmonitor mit dem folgenden Befehl: db2 update monitor switches using LOCK OFF
- Suchen Sie nach einer Anwendungskennung, die sich im Wartestatus für Sperre befindet, und suchen Sie dann nach der ID des Agenten, der die Sperre hält, um diese zu überprüfen.
- Überprüfen Sie das Handle, um sich zu vergewissern, dass es einen Wartestatus für Sperre hat, und um die ID des Agenten festzustellen, der die Sperre hält. Wenn diese Agenten-ID mit der vorherigen identisch ist, wissen Sie, dass ein Deadlock vorliegt.
- Überprüfen Sie die Anwendung, und verwenden Sie eine weniger restriktive Isolationsstufe, wenn keine Parallelität erforderlich ist.
- Lassen Sie Vorsicht walten, wenn Sie den Wert für accessIntent auf eine niedrigere Isolationsstufe heruntersetzen. Diese Änderung kann Probleme bei der Datenintegrität zur Folge haben.
- Für DB2/UDB Version 7.2 und frühere Releases können Sie das Flag DB2_RR_TO_RS
über das DB2-Befehlszeilenfester so einstellen, dass nicht erforderliche Deadlocks
ausgeschaltet werden, beispielsweise wenn der für die Bean-Methode definierte
accessIntent zu restriktiv ist (z. B. PessimisticUpdate). Die Einstellung
von DB@_RR_TO_RS hat zwei Auswirkungen:
- Wenn Sie RR als Isolationsstufe auswählen, wird diese auf RS heruntergestuft.
- Wenn Sie eine andere Isolationsstufe auswählen und die Einstellung DB2_RR_TO_RS aktiviert ist, werden beim Suchen die Zeilen übersprungen, die zwar gelöscht, aber noch nicht festgeschrieben wurden. Dies passiert auch dann, wenn eine Zeile den Suchkriterien entspricht. Dieses Überspringen von Zeilen betrifft die Isolationsstufen RR, Read Stability (RS) und Cursor Stability (CS).
Stellen Sie sich ein Szenario vor, in dem Transaktion A die Zeile mit "column1=10" löscht und Transaktion B eine Suche mit "column1>8" und "column1<12" durchführt. Wenn DB2_RR_TO_RS inaktiviert ist, wartet Transaktion B, bis Transaktion A festgeschrieben oder rückgängig gemacht wird. Falls Transaktion A rückgängig gemacht wird, wird die Zeile mit column1=10 in die Ergebnismenge der Abfrage von Transaktion B aufgenommen. Wenn DB2_RR_TO_RS aktiviert ist, wartet Transaktion B nicht, bis Transaktion A festgeschrieben oder rückgängig gemacht wird. Transaktion B empfängt sofort die Abfrageergebnisse, zu denen die gelöschte Zeile nicht gehört. Eine angemessene Einstellung von DB2_RR_TO_RS ändert das Sperrverhalten und trägt dazu bei, dass Deadlocks vermieden werden.
"COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource“ could not be found for data source ("[data-source-name]“)"
Dieser Fehler wird durch die Nachricht "DSRA8040I: Die Verbindung zur DataSource konnte nicht hergestellt werden." kommentiert.
Dieser Fehler tritt in der Regel auf, wenn der Klassenpfad des DB2-JDBC-Treibers ordnungsgemäß auf ${DB2_JDBC_DRIVER_PATH}/db2java.zip, gesetzt ist, die Umgebungsvariable DB2_JDBC_DRIVER_PATH jedoch nicht gesetzt ist.
Dieser Fehler kann auch auftreten, wenn Sie DB2 Version 7.1 oder 7.2 verwenden und usejdbc2 noch nicht ausgeführt wurde. Das Problem kann darauf zurückzuführen sein, wenn Ihr Pfad zwar korrekt ist, der Fehler aber weiterhin angezeigt wird.
- Rufen Sie die Seite "WebSphere-Variablen verwalten" auf.
- Wählen Sie Umgebung aus, um sicherzustellen, dass kein Eintrag für die Variable DB2_JDBC_DRIVER_PATH existiert.
Fügen Sie zur Behebung dieses Fehlers die Variable DB2_JDBC_DRIVER_PATH mit dem Wert für den Verzeichnispfad, der die Datei db2java.zip enthält, hinzu.
![[z/OS]](../images/ngzos.gif)
Error 10500 (E_Fatal) returns when an attempt is made to either publish or inquire on an entity exceeding 255 characters in one of its fields.
Dieser Fehler tritt in der Regel auf, wenn Sie versuchen, eine Entität zu veröffentlichen oder abzurufen, in der ein Feld die Länge von 255 Zeichen überschreitet. Dieser Fehler ist bei der Verwendung von Zeichen, die nicht aus dem Englischen stammen, weniger offensichtlich, weil der eigentliche Grenzwert erreicht wird, bevor 255 Zeichen angezeigt werden.
Sie können diesen Fehler beheben, indem Sie diese Einschränkung bei der Verwendung von DB2 Version 7 unter z/OS berücksichtigen. Überschreiten Sie nicht den Grenzwert von 255 Zeichen.
java.sql.SQLException: Failure in loading T2 native library db2jcct2 DSRA0010E: SQL State = null, Error Code = -99,999
- Nach der Installation von DB2 auf einer Maschine wurde kein Warmstart durchgeführt. Führen Sie einen Warmstart auf der Maschine durch, für die der Fehler angezeigt wird, und wiederholen Sie die Operation.
- Es wurde eine Datenbankoperation ausgeführt, die einen anderen Geltungsbereich hat als die konfigurierte Datenbank. Der Befehl testConnection wird beispielsweise auf Knotenebene für eine Datenquelle ausgeführt, die auf Serverebene vorhanden ist. Führen Sie das Script "db2profile" auf der Maschine aus, und vergewissern Sie sich, dass die Umgebung Zeiger auf die nativen DB2-Bibliotheken enthält. Das Script "db2profile" befindet sich im Stammverzeichnis der DB2-Benutzer-ID. Weitere Informationen zum Befehl "testConnection" finden Sie in der Dokumentation zum Service für Verbindungstests.
- Der DB2-Kontext wird für den Benutzer, der WebSphere Application Server ausführt, nicht ordnungsgemäß eingerichtet. Führen Sie das Script "db2profile" auf der Maschine aus, und vergewissern Sie sich, dass die Umgebung Zeiger auf die nativen DB2-Bibliotheken enthält.
Es tritt eine Ausnahme vom Typ Zugriffskonflikt in der Datenbank ein, wenn die Implementierung der Datenquelle den Typ XA hat.
Symptom | Problem | Beschreibung | Empfohlene Maßnahmen |
---|---|---|---|
Eine Ausnahme wegen Zugriffskonflikten tritt in einer DB2-Datenbank ein, auf die Ihre Anwendung mit einer Datenquelle des Implementierungstyps XA zugreift. | Ihre Anwendung versucht, auf Datenbanksätze zuzugreifen, die durch eine XA-Transaktion gesperrt, die den Status "Beendet" (e) hat, aber vom Transaktionsmanager nicht vorbereitet werden kann. | Eine XA-Transaktion mit DB2, die beendet ist, aber nicht vorbereitet werden kann, hat den Status "Beendet" (e).
Da die Transaktion nicht als unbestätigt eingestuft ist, kann der
Transaktionsmanager diese Transaktion nicht wiederherstellen. DB2 gibt die Transaktion nicht in der Liste der
unbestätigten Transaktionen zurück.
DB2 führt auch keine sofortige Rollback-Operation für die Transaktion durch, sondern wartet, bis alle Verbindungen zur Datenbank freigegeben sind. In diesem Zeitraum der Inaktivität hält die Transaktion die Datenbanksperre aufrecht. Aufgrund bestimmter WLM-Richtlinien von WebSphere Application Server kann Ihr Anwendungsserver unter Umständen nicht alle Verbindungen zur Datenbank trennen, um eine Rollback-Operation für die Transaktion durchzuführen. Deshalb sperrt die Transaktion die Datenbanksätze weiter. Wenn Ihre Anwendung versucht, auf diese gesperrten Datensätze zuzugreifen, tritt in DB2 eine Ausnahme wegen eines Zugriffskonflikts ein. |
Mit DB2 Version 8.2 wird eine Beispielanwendung bereitgestellt, die eine Verbindung zu einem definierten DB2-Server herstellt und die verfügbaren DB2-APIs verwendet, um eine Liste der beendeten Transaktionen abzurufen. Die Anwendung bietet eine Konfigurationseinstellung an, mit der Sie festlegen können, wann die Anwendung solche Transaktionen rückgängig macht. Sie finden die Beispielanwendung im Verzeichnis sqllib/samples/db2xamon.c von DB2 Version 8.2. Führen Sie diese Anwendung aus. |
Ausnahme “DSRA8050W: Die angegebene DataStoreHelper-Klasse wurde nicht gefunden“ tritt ein, wenn Sie versuchen, eine DB2 Universal Datasource in einer Zelle mit unterschiedlichen Releases zu verwenden.
Dieser Fehler tritt gewöhnlich auf, wenn Sie WebSphere Application Server Version 6.0 oder höher zusammen mit einer früheren Version verwenden und versuchen, eine DB2-Universal-Datenquelle in der früheren Version zu erstellen.
Der Fehler ist darauf zurückzuführen, dass keine DB2-Universal-Datenquelle in Version 5 und früher vorhanden ist, aber die Administrationskonsole der Version 6 eine Option zum Erstellen einer solchen Datenquelle anbietet.
Sie können dieses Problem beheben, indem Sie die Datenquelle in Version 6.0 oder höher erstellen.
Nachricht "'SYSTEM' is not a valid authorization ID" wird angezeigt beim Versuch, auf einer Windows-Maschine, auf der auch WebSphere Application Server installiert ist, auf DB2 zuzugreifen
Die Nachricht "'SYSTEM' is not a valid authorization ID" wird angezeigt, wenn Sie versuchen, auf einer Windows-Maschine, auf der auch WebSphere Application Server installiert ist, auf DB2 zuzugreifen.
Symptom | Problem | Beschreibung | Empfohlene Maßnahmen |
---|---|---|---|
Wenn Sie mit einer Installation von WebSphere Application Server
unter Windows arbeiten, die
DB2 als Back-End verwendet, wird die folgende Ausnahme im JVM-Protokoll aufgezeichnet:
|
Diese Ausnahme tritt in Konfigurationen auf, in denen WebSphere Application Server ein Client des DB2-Servers ist. Das Problem ist auf einen Berechtigungskonflikt zwischen WebSphere Application Server unter Windows und DB2 zurückzuführen, der entsteht, wenn eine Anwendung versucht, ohne Angabe einer Benutzer-ID und eines Kennworts eine Verbindung zu DB2 herzustellen. | Wenn ein DB2-Client und die DB2-Datenbank auf derselben Maschine ausgeführt werden, lässt DB2 die Clientverbindung ohne Angabe einer Benutzer-ID und eines Kennworts zu. Die Verbindung wird unter Verwendung der Berechtigungsnachweise des Benutzers hergestellt, der Eigner des Clientprozesses ist. Dies ist hier die JVM des Anwendungsservers. Wenn WebSphere Application Server jedoch als Windows-Dienst ausgeführt wird und die Option "Anmelden als" auf "Lokales Systemkonto" eingestellt ist, wird die JVM des Anwendungsservers als Unterkomponente eines speziellen Windows-Benutzers mit dem Namen SYSTEM eingestuft. Dieser Benutzer darf keine Verbindung zu DB2 herstellen. Deshalb wird die angezeigte Ausnahme ausgelöst. | Hierfür gibt es zwei Möglichkeiten:
|
XAException: XAER_NOTA on XA prepare call in DB2 Universal JDBC Driver type 4 after one phase transaction rollback
Symptom
Bei Anwendungen, die den für DB2 Version 8.2 verfügbaren JDBC-Treiber für DB2 Universal des Typs 4 XA (DB2 Universal JDBC Driver Type 4 XA) verwenden, kann eine Verbindungsherstellung scheitern und ein Fehler vom Typ XAER_NOTA XAException ausgegeben werden. Der folgende Codeblock ist ein Beispiel für diese Ausnahme:
J2CA0027E: An exception occurred while invoking prepare on an
XA Resource Adapter from dataSource jdbc/SDOSVT, within
transaction ID {XidImpl: formatId(57415344), gtrid_length(36), bqual_length(54),
data(000000ff5191398200000001000000296cac5c42fe3c6838631cbaafc8b5a9253b846544
000000ff5191398200000001000000296cac5c42fe3c6838631cbaafc8b5a9253b8465440000000
10000000000000000000000000002)}:
javax.transaction.xa.XAException: XAER_NOTA
at com.ibm.db2.jcc.a.xb.a(xb.java:1682)
at com.ibm.db2.jcc.a.xb.a(xb.java:841)
at com.ibm.db2.jcc.a.xb.prepare(xb.java:812)
at com.ibm.ws.rsadapter.spi.WSRdbXaResourceImpl.prepare(WSRdbXaResourceImpl.java:837)
...
Problem
Wenn eine Verbindung über einen JDBC-Treiber für DB2 Universal des Typs 4 XA in einer einphasigen Transaktion, z. B. einer Transaktion, in der die automatische Festschreibung inaktiviert ist, verwendet wird, und diese einphasige Transaktion rückgängig gemacht wird, scheitert die Wiederverwendung der Verbindung in einer zweiphasigen Transaktion beim prepare-Aufruf.
Das Scheitern des XA-Aufrufs prepare ist auf ein Problem im JDBC-Treiber für DB2 Universal des Typs 4 XA zurückzuführen. Dieses Problem tritt nicht auf, wenn die einphasige Transaktion festgeschrieben wird oder wenn der JDBC-Treiber für DB2 Universal im Modus Typ 2 ausgeführt wird.
Lösung
Führen Sie einen Upgrade auf DB2 Version 8.2 Fixpack 1 durch, der dem Version 8.1 Fixpack 8 entspricht. Der JDBC-Treiber Treiber für Universal XA, der mit diesen Releases bereitgestellt wird, löst das zuvor beschriebene Problem mit Modus Typ 4.
Ausnahme des Typs java.rmi.MarshalException für Anwendungsclient aufgrund der Inkompatibilität der Versionen der JDBC-Treiberdateien
Symptom
Für eine Anwendung, die einen Java EE-Anwendungsclient enthält, wird die folgende Fehlernachricht in der Clientprotokolldatei des Anwendungsservers angezeigt:
java.rmi.MarshalException: CORBA MARSHAL 0x4942f89a No; nested exception is:
org.omg.CORBA.MARSHAL: Unable to read value from underlying bridge : Mismatched serialization
UIDs : Source (Rep.
IDRMI:com.ibm.db2.jcc.c.SqlException:63EEE52211DCD763:82CE0C0DA2B0A000)
= 82CE0C0DA2B0A000 whereas Target (Rep. ID
RMI:com.ibm.db2.jcc.c.SqlException:63EEE52211DCD763:91C6171BC645E41B)
= 91C6171BC645E41B vmcid: 0x4942f000 minor code: 2202 completed: No
Problem
Die Dateien db2jcc.jar auf der Anwendungsclientmaschine und in Ihrem Anwendungsserver stammen aus Versionen von DB2, die nicht miteinander oder nicht mit der Version von DB2 kompatibel sind, die als Datenspeicher verwendet wird.
Lösung
Überprüfen Sie die Dateien db2jcc.jar auf der Anwendungsclientmaschine, im Anwendungsserver und auf Ihrem DB2-Server. Installieren Sie auf der Clientmaschine und im Anwendungsserver Dateien derselben Version, die mit dem DB2-Server kompatibel sind.
Datenbankfehler löst kritische Ausnahme -99999 für Anwendungen aus, die den Treiber für DB2 Universal Typ 4 verwenden
Symptom
Wenn Sie den Treiber für DB2 Universal Typ 4 für den Zugriff auf DB2 Network Server verwenden und ein Fehler in der Datenbank auftritt, setzt der Datenbankserver eine generische Ausnahme des Typs -99999 als Antwort auf jede JDBC-Anforderung getConnection ab. Diese Ausnahme, die im folgenden Codeauszug gezeigt wird, kann ein nicht erwartetes Verhalten in Ihren Anwendungen auslösen.
java.sql.SQLException: IO Exception opening socket to
server bs8.rchland.ibm.com on port 1527.
The DB2 Server may be down.DSRA0010E: SQL State = null,
Error Code = -99,999DSRA0010E: SQL State = null,
Error Code = -99,999
at com.ibm.db2.jcc.b.a.<init>(a.java:125)
at com.ibm.db2.jcc.b.b.a(b.java:1011)
at com.ibm.db2.jcc.c.l.<init>(l.java:197)
at com.ibm.db2.jcc.b.b.<init>(b.java:258)
at com.ibm.db2.jcc.DB2PooledConnection.
<init>(DB2PooledConnection.java:44)
at com.ibm.db2.jcc.DB2ConnectionPoolDataSource.getPooledConnectionX
(DB2ConnectionPoolDataSource.java:80)
at com.ibm.db2.jcc.DB2ConnectionPoolDataSource.getPooledConnection
(DB2ConnectionPoolDataSource.java:45)
at com.ibm.ws.rsadapter.DSConfigurationHelper$1.run
(DSConfigurationHelper.java:945)
Problem
Wenn Sie im Typ-4-Modus arbeiten, lösen einige Versionen des Treibers für DB2 Universal eine generische Ausnahme zu einem Datenbankfehler und keinen spezifischen Fehler aus, den WebSphere Application Server einer Ausnahme für veraltete Verbindungen zuordnen kann. Dieses Problem tritt in Versionen des Treibers für DB2 8.1 Fixpack 6 oder Fixpack 7 und DB2 8.2 auf.
Lösung
Führen Sie einen Upgrade auf DB2 Version 8.2 Fixpack 1 (äquivalent zu Version 8.1 Fixpack 8) durch. In dieser Version wird im zuvor beschriebenen Szenario ein gültiger Fehlercode ausgegeben. WebSphere Application Server ordnet diesen Fehlercode wie erwartet einer Ausnahme des Typs StaleConnectionException zu.
Zugriff auf DB2 bei Verwendung des JDBC-Treibers für DB2 Universal unter Linux nicht möglich
Symptom
java.security.AccessControlException: Access denied (java.lang.RuntimePermission accessClassInPackage.sun.io)
- 64-Bit-Linux:
com.ibm.db2.jcc.b.SqlException: Failure in loading T2 native library db2jcct2
Problem
Die Konfiguration von DB2 unter Linux mit dem JDBC-Treiber für Universal ist nicht vollständig.
Lösung
- Vergewissern Sie sich, dass die Konfigurationsanforderungen für das Java SDK 1.4.2 für die Linux-Plattform erfüllt sind.
- Konfigurieren Sie Ihre Entwicklungsumgebung für die Erstellung von Java-Anwendungen unter Linux mit DB2-JDBC-Unterstützung. Weitere Informationen finden Sie in den Artikeln zur Anwendungsentwicklung für DB2.
- Wenn Sie DB2 auf der Plattform Linux/IA64 ausführen und DB2 Version 8.1 Fix Pack 7A verwenden, führen Sie den zusätzlichen Schritt aus, der im technischen Hinweis zu DB2 UDB Version 8 FixPak 7a für Linux on IA64 beschrieben ist und ausgeführt werden muss, wenn eine libdb.so.3-Bibliothek fehlt. Dieser Schritt ist nur für Fixpack 7A erforderlich. Für DB2 Version 8.1 Fixpack 7 und frühere Versionen von DB2 und für DB2 Version 8.1 Fixpack 8 und höhere Versionen von DB2 muss dieser Schritt nicht ausgeführt werden.
Ungültige Konvertierung in der Spalte VARCHAR FOR BIT DATA für CMP-Beans
Wenn Enterprise-Beans vom Typ CMP (Container-Managed Persistence, containergesteuerte Persistenz), für die in einer DB2-Tabelle Spalten des Typs VARCHAR FOR BIT DATA definiert sind, im JDBC-Treiber für DB2 Universal Typ 4 implementiert werden, um die Daten zu bewahren, wird zur Laufzeit eine SQL-Ausnahme wegen ungültiger Konvertierung ausgelöst. Diese Ausnahme wird nur ausgelöst, wenn Sie den JDBC-Treiber für DB2 Universal Typ 4 verwenden und die Eigenschaft "deferPrepares" auf "true" gesetzt ist. Wenn die Eigenschaft "deferPrepares" auf "true" gesetzt ist, verwendet der JDBC-Treiber für DB2 Universal Typ 4 die JDBC-Standarddatenzuordnung.
Derzeit folgt der generierte implementierte Code nicht der Standardzuordnung der JCBC-Spezifikation. Der Fehler zur Ausführungszeit ist auf einen Fehler in dem Tool zurückzuführen, das die Enterprise-Bean für die Ausführung vorbereitet.
- Setzen Sie die Eigenschaft "deferPrepares" in der Konfiguration der Datenquelle auf "false".
- Verwenden Sie den JDBC-Treiber für DB2 Universal Typ 4 nicht, wenn Ihre Tabelle die Spalte VARCHAR FOR BIT DATA oder LONG VARCHAR FOR BIT DATA enthält. Nähere Einzelheiten hierzu finden Sie in der Readme-Datei zu DB2 Version 8.1.