Einschränkungen beim Debugging von Routinen

Auf dieser Seite werden Einschränkungen beschrieben, auf die Sie beim Debugging für Routinen stoßen können. Außerdem werden Methoden beschrieben, die zur Umgehung dieser Einschränkungen vorgeschlagen werden. Lesen Sie ebenfalls die Readme-Datei des Produkts, die weitere Einschränkungen für diesen Debugger enthalten kann.

Allgemein

Aktualisierungen finden Sie in Bekannte Probleme mit dem Debugger für Routinen.

Routinennamen mit Begrenzer
Der Debugger für Routinen bietet eingeschränkte Unterstützung für Routinen mit Schema- oder Routinennamen mit Begrenzer. Solche Routinen müssen im Dialogfeld Debug für Startkonfigurationen und nicht über das Kontextmenü in der Datendefinitionssicht gestartet werden.
Schrittaktionen aktivieren
Wenn beim Start einer Debugsitzung die Schrittaktionsschaltflächen (z. B. die Schaltfläche Step-Over) nicht aktiviert sind, wählen Sie den obersten Stack-Frame aus, um die Schaltflächen zu aktivieren.
Sitzungsmanager
Verwenden Sie den Sitzungsmanager, der im Produktumfang enthalten ist. Der Sitzungsmanager kann sich auf dem Server, im Netz oder auf dem Client befinden. Die folgenden Schritte beschreiben, wie Sie den Sitzungsmanager auf dem Client konfigurieren, wobei der im Produktumfang enthaltene Sitzungsmanager verwendet wird. Diese Anweisung gilt nicht für DB2-PL/SQL- und Oracle-Konfigurationen.
  1. Öffnen Sie ein Befehlsfenster und wechseln Sie in das Produktinstallationsverzeichnis. Standardmäßig wird das Produkt im Verzeichnis C:\Programme\IBM\SDP70 unter Windows installiert.
  2. Führen Sie im Befehlsfenster db2dbgm.bat aus und notieren Sie die IP-Adresse und die Portnummer für den Sitzungsmanager.
  3. Starten Sie die Workbench und ändern Sie die Benutzervorgaben für den Debugger so, dass der lokale Sitzungsmanager verwendet wird:
    1. Klicken Sie auf Fenster > Benutzervorgaben, erweitern Sie den Knoten Ausführen/Debug und klicken Sie auf Routinendebugger.
    2. Wählen Sie im Fenster Debugger die Option Bereits aktiven Sitzungsmanager verwenden aus.
    3. Geben Sie im Feld Host die IP-Adresse des Systems an. Sie können die IP-Adresse auch über das Befehls- oder Terminalfenster beziehen, in dem der Sitzungsmanager ausgeführt wird.
    4. Geben Sie im Feld Port den Port für den lokalen Sitzungsmanager an. Standardmäßig lautet die Portnummer 4554. Sie können die Portnummer auch über das Befehls- oder Terminalfenster beziehen, in dem der Sitzungsmanager ausgeführt wird.
Variablennamen
Variablennamen, die Anführungszeichen enthalten, werden für das Debugging für Routinen in Datenbanken von DB2 for Linux, UNIX, and Windows nicht unterstützt.
Unterbrechungspunkte
Für Optim Development Studio Version 2.2.1.1 können einzelne Unterbrechungspunkte nicht inaktiviert werden.
Features, die nur für Datenbanken von DB2 for Linux, UNIX, and Windows Version 10.1 Fixpack 2 oder höher verfügbar sind
Die folgenden Debugging-Features sind nur verfügbar, wenn ein Debugging für Routinen in einer Datenbank von DB2 for Linux, UNIX, and Windows Version 10.1 Fixpack 2 oder höher ausgeführt wird:
  • Debugging für deklarierte Routinen
  • Debugging für Trigger
  • Debugging für anonyme PL/SQL-Blöcke
  • Starten des Debuggers aus dem SQL- und XQuery-Editor
  • Setzen von permanenten Unterbrechungspunkten im Routineneditor
  • Neukompilieren von Routinen mit der Debugging-Option ohne erneutes Implementieren der Routine
  • Anzeigen der folgenden Typen von Variablen in der Sicht Variablen:
    • Globale Variablen und Paketvariablen
    • Assoziative Arrays
    • Array von Zeilen
Array-Variablen
Der Debugger für Routinen listet nur die ersten 100.000 Elemente einer Array-Variablen in der Sicht Variablen auf.
BLOB-Datentypen
Wenn der Datentyp eines Ausgabeparameters ein großes Binärobjekt (BLOB) ist, wird die Ausgabe in Großbuchstaben zurückgegeben. Da der zurückgegebene Wert eine Hexadezimalzahl darstellt, verursacht dies keine Probleme.
DB2-Rolle SYSDEBUG
Wenn Sie ein Debugging für Routinen ausführen wollen, die in einer Datenbank von DB2 for Linux, UNIX, and Windows Version 10.1 Fixpack 2 oder höher implementiert sind, muss die Datenbankbenutzer-ID, mit der die Routine implementiert wird, ein Member der Rolle SYSDEBUG sein.

SQL- und Java-Routinen

Trigger

Wenn Sie in einer DB2-Datenbank ein Debugging für Trigger ausführen, können Sie nur für einen Trigger gleichzeitig ein Debugging ausführen. Ein gleichzeitiges Debugging für zwei oder mehr Trigger wird nicht unterstützt.

PL/SQL- und Oracle-Datentypen

Siehe Vom Debugger für Routinen nicht unterstützte PL/SQL- und Oracle-Datentypen.

PL/SQL-Routinen

Oracle-Einschränkung

Wenn beim Debugging eine Prozedur mit dem Typ CURSOR bei einem Unterbrechungspunkt mitten in der Prozedur gestoppt wird und Sie auf Beenden klicken, kann es vorkommen, dass der Eintrag in der Ausgabesicht blockiert ist. Zur Umgehung dieser Einschränkung klicken Sie auf Wieder aufnehmen anstatt auf Beenden.

Informix-Einschränkungen

Die folgende Liste enthält Beschreibungen zu Einschränkungen beim Debugging von gespeicherten Prozeduren in einer Informix-Datenbank:
  • Wenn Sie ein Debugging für eine gespeicherte Prozedur in einer Informix-Datenbank ausführen, müssen Sie den integrierten Debugger oder einen bereits aktiven Sitzungsmanager verwenden. Die Standardbenutzervorgabe, den Sitzungsmanager auf jedem verbundenen Server auszuführen, wird nicht unterstützt.

    Zur Änderung der Benutzervorgabe für die Position von Routine Debug Session Manager wählen Sie Fenster > Benutzervorgaben aus. Wählen Sie in Benutzervorgaben die Option Ausführen/Debug > Debugger für Routinen aus, um die Benutzervorgaben für das Debugging auszuwählen. Wählen Sie den Datenbankserver für die Routinen aus, für die Sie ein Debugging ausführen. Wählen Sie im Abschnitt Position von Routine Debug Session Manager entweder Integrierten Sitzungsmanager verwenden oder Bereits aktiven Sitzungsmanager verwenden aus.

  • Wenn Sie in der Sicht Datenprojektexplorer mit der rechten Maustaste auf eine gespeicherte Informix-Prozedur klicken und keine Verbindung zur Informix-Datenbank besteht, ist Debug nicht aktiviert. Zur Aktivierung des Debugging stellen Sie eine Verbindung zur Datenbank her. Sie können für die gespeicherte Prozedur auch ein Debugging aus der Sicht Datenquellenexplorer ausführen.

Einschränkung unter Linux

Wenn Sie das Debugging für eine Routine für eine lokale DB2-Datenbank ausführen, erhalten Sie möglicherweise die Fehlernummer SQL1224N:

COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] SQL1224N Ein Datenbankagent konnte nicht für die Anforderung gestartet werden oder er wurde aufgrund eines Systemabschlusses der Datenbank bzw. durch den Befehl FORCE beendet. SQLSTATE-Wert=55032

Dieser Fehler wird vom Linux-Kernel (Linux Kernel Bugzilla Bug #351) verursacht. Die folgenden Anweisungen dienen als Fehlerumgehung, bei der die DB2-Verbindungsaufbaumethode TCPIP (als Rückschleife) statt CLI (Call Level Interface) verwendet wird. Bei dieser Vorgehensweise verwendet der Debugger denselben Aliasnamen der Datenbank wie zuvor:

  1. Wenn für ferne DB2-Clients kein Port konfiguriert wurde, melden Sie sich als Root an und erstellen Sie in /etc/services einen TCP/IP-Port (z. B. db2c_db2inst1 50000/tcp). Alternativ dazu können Sie in der Steuerzentrale einen TCP/IP-Port erstellen (indem Sie die Kommunikationseigenschaften für die Datenbankinstanz festlegen). Sie können für ferne DB2-Clients einen vorhandenen Port verwenden.

    Für die Schritte 2 bis 7 müssen Sie sich als DB2-Instanzeigner anmelden.

  2. Konfigurieren Sie den Datenbankmanager so, dass er den Verbindungsmanager für das Kommunikationsprotokoll TCP/IP startet. Wenn Sie nicht sicher sind, ob dies bereits erfolgt ist, setzen Sie den folgenden Befehl ab:
    db2set db2comm

    Wenn die Ausgabe nicht das Schlüsselwort tcpip enthält, müssen Sie den folgenden Befehl eingeben, um die Registry-Variable db2comm mit der Angabe tcpip zu aktualisieren:

    db2set db2comm=<vorhandene_protokollnamen>,tcpip

    Die Registry-Variable db2comm bestimmt das Protokoll, dessen Verbindungsmanager beim Start des Datenbankmanagers aktiviert wird. Sie können diese Variable für mehrere Kommunikationsprotokolle festlegen, indem Sie die Schlüsselwörter mit Kommata trennen.

    Sie müssen den Befehl db2start erneut absetzen, damit die Verbindungsmanager für die vom Registry-Parameter db2comm angegebenen Protokolle gestartet werden. Da Sie DB2 in Schritt 7 erneut starten, müssen Sie das jetzt nicht tun.

    .
  3. Aktualisieren Sie den Konfigurationsparameter SVCENAME für den Datenbankmanager, indem Sie den in /etc/services definierten Verbindungsservicenamen angeben (siehe Schritt 1).

    Geben Sie den folgenden Befehl ein, um die aktuelle Einstellung des Parameters SVCENAME zu überprüfen:

    db2 get dbm cfg | grep -i svcename

    Wenn Sie die Einstellung des Parameters SVCENAME aktualisieren müssen, können Sie den folgenden Befehl eingeben:

    db2 update dbm cfg using svcename <verbindungsservicename>

    Dabei muss bei <verbindungsservicename> die Groß-/Kleinschreibung beachtet werden und der Name muss mit dem Namen des Service-Ports übereinstimmen, den Sie in /etc/services gestellt haben (z. B. db2 update dbm cfg using svcename db2c_db2inst1).

    Die Aktualisierung der Datenbankmanagerkonfiguration wird erst wirksam, wenn der Befehl db2start das nächste Mal abgesetzt wird. Diese Aktion werden Sie in Schritt 7 durchführen.

  4. Geben Sie den folgenden Befehl ein, um den Rückschleifenknoten zu katalogisieren:
    db2 catalog tcpip node <knotenname> remote <hostname> server <verbindungsservicename>

    Dabei gilt Folgendes:

    • <knotenname> steht für einen lokalen Aliasnamen für den zu katalogisierenden Knoten. Dies ist ein beliebiger Name für die Workstation, mit dem der Knoten identifiziert wird (z. B. db2 catalog tcpip node mynode remote 127.0.0.1 server db2c_db2inst1).
    • <hostname> steht für den Namen des Systems, auf dem DB2 installiert ist. Der Hostname, den Sie angeben, muss dem Systemnamen mit derselben Groß-/Kleinschreibung entsprechen. Wenn Sie nicht sicher sind, wie der Name des Systems lautet, können Sie in der Steuerzentrale nachsehen.

    Setzen Sie den folgenden Befehl ab, um zu überprüfen, ob der Katalogisierungsbefehl ordnungsgemäß ausgeführt wurde:

    db2 list node directory

    Beispielausgabe dieses Befehls, in der zur besseren Lesbarkeit Leerzeilen entfernt wurden:

    Knotenverzeichnis
    Anzahl Einträge im Verzeichnis = 1
    Eintrag für Knoten 1:
    Knotenname = MYNODE
    Kommentar =
    Protokoll = TCPIP
    Hostname = 127.0.0.1
    Servicename = db2c_db2inst1
  5. Katalogisieren Sie die Datenbank wie folgt. Im Folgenden finden Sie Befehle zur Generierung von Beispielausgaben, falls Sie die Auswirkungen der einzelnen Befehle verfolgen möchten:
    1. db2 catalog db <datenbankname> as <aliasname_der_datenbank>
    2. db2 uncatalog db <datenbankname>
    3. db2 catalog db <aliasname_der_datenbank> as <datenbankname> at node <knotenname>
    Beispiel:
    db2 catalog db WAS as WASLOOP
    db2 uncatalog db WAS
    db2 catalog db WASLOOP as WAS at node MYNODE

    Anmerkungen:

    • Der Aliasname der Datenbank kann ein beliebiger Name sein, er darf jedoch nicht mit dem Datenbanknamen übereinstimmen. Der Aliasname darf höchstens acht Zeichen lang sein.
    • Wenn Sie die Datenbank nicht ordnungsgemäß katalogisiert haben, erhalten Sie die Fehlernummer SQL1334N.
    • Sie müssen die Schritte 5a bis 5c für jede Datenbank wiederholen, für die Sie den Debugger für eine Routine ausführen möchten.

    Beispielausgabe für die Schritte 5a bis 5c

    Vor Schritt 5a war bereits eine lokale Datenbank mit dem Namen WAS erstellt worden. Der Befehl db2 list db directory ergibt eine Ausgabe, die der folgenden Nachricht ähnelt:

    Systemdatenbankverzeichnis
    Anzahl Einträge im Verzeichnis = 1
    
    Eintrag für Datenbank 1:
    
    Aliasname der Datenbank = WAS
    Datenbankname = WAS
    Lokales Datenbankverzeichnis = /home/ctsui
    Releasestand der Datenbank = 9.00
    Kommentar =
    Verzeichniseintragungstyp = Indirekt
    Katalogknotenummer = 0

    Nach Schritt 5a ergibt db2 list db directory eine Ausgabe, die der folgenden Nachricht ähnelt:

    Systemdatenbankverzeichnis
    Anzahl Einträge im Verzeichnis = 2
    
    Eintrag für Datenbank 1:
    
    Aliasname der Datenbank = WAS
    Datenbankname = WAS
    Lokales Datenbankverzeichnis = /home/ctsui
    Releasestand der Datenbank = 9.00
    Kommentar =
    Verzeichniseintragungstyp = Indirekt
    Katalogknotenummer = 0
    
    Eintrag für Datenbank 2:
    
    Aliasname der Datenbank = WASLOOP
    Datenbankname = WAS
    Lokales Datenbankverzeichnis = /home/ctsui
    Releasestand der Datenbank = 9.00
    Kommentar =
    Verzeichniseintragungstyp = Indirekt
    Katalogknotenummer = 0

    Nach Schritt 5b ergibt db2 list db directory eine Ausgabe, die der folgenden Nachricht ähnelt:

    Systemdatenbankverzeichnis
    Anzahl Einträge im Verzeichnis = 1
    
    Eintrag für Datenbank 1:
    
    Aliasname der Datenbank = WASLOOP
    Datenbankname = WAS
    Lokales Datenbankverzeichnis = /home/ctsui
    Releasestand der Datenbank = 9.00
    Kommentar =
    Verzeichniseintragungstyp = Indirekt
    Katalogknotenummer = 0

    Nach Schritt 5c ergibt db2 list db directory eine Ausgabe, die der folgenden Nachricht ähnelt:

    Systemdatenbankverzeichnis
    Anzahl Einträge im Verzeichnis = 2
    
    Eintrag für Datenbank 1:
    
    Aliasname der Datenbank = WAS
    Datenbankname = WASLOOP
    Knotenname = MYNODE
    Releasestand der Datenbank = 9.00
    Kommentar =
    Verzeichniseintragungstyp = Fern
    Katalogknotenummer = -1
    
    Eintrag für Datenbank 2:
    
    Aliasname der Datenbank = WASLOOP
    Datenbankname = WAS
    Lokales Datenbankverzeichnis = /home/ctsui
    Releasestand der Datenbank = 9.00
    Kommentar =
    Verzeichniseintragungstyp = Indirekt
    Katalogknotenummer = 0

    Setzen Sie die folgenden zwei Befehle ab, um zu überprüfen, ob der Befehl catalog db ordnungsgemäß ausgeführt wurde (siehe auch die folgende Beispielausgabe):

    db2 connect to wasloop
    db2 connect to was

    Dabei gibt db2 connect to wasloop die Verbindungsinformationen aus und db2 connect to was ergibt den Fehler SQL1403N.

    Beispielausgabe von db2 connect to wasloop:

    Datenbankverbindungsinformationen
    Systemdatenbankverzeichnis
    
    Datenbankserver = DB2/6000 6.1.0
    SQL-Berechtigungs-ID = CTSUI
    Aliasname der lokalen Datenbank = WASLOOP

    Beispielausgabe von db2 connect to was:

    Datenbankverbindungsinformationen
    Systemdatenbankverzeichnis
    
    Datenbankserver = DB2/6000 6.1.0
    SQL-Berechtigungs-ID = CTSUI
    Aliasname der lokalen Datenbank = WAS
  6. Ändern Sie das Authentifizierungsverfahren in Clientauthentifizierung. Geben Sie den folgenden Befehl ein:
    db2 update dbm cfg using authentication client

    Zeigen Sie die neue Einstellung mit dem folgenden Befehl an, um zu überprüfen, ob der Befehl ordnungsgemäß ausgeführt wurde:

    db2 get dbm cfg

    Beispielausgabe:

    ....
    Datenbankmanagerauthentifizierung     (AUTHENTICATION) = CLIENT
    ....
  7. Starten Sie DB2 erneut, um den Verzeichniscache zu aktualisieren. Beispiel:
    db2stop
    db2start

    Anmerkung: Sie müssen unter Umständen den Befehl db2stop force verwenden, um alle aktiven Datenbankverbindungen zu schließen.

  8. Für WAS müssen Sie die Datei admin.config nicht aktualisieren. Für eine WebSphere-Anwendung müssen Sie die vorhandene Datenquellenkonfiguration nicht ändern.
  9. Setzen Sie die folgenden Befehle ab, falls Sie die Datenbank löschen möchten:
    1. db2 attach to <knotenname> user <benutzer-ID> using <kennwort>
    2. db2 drop db <datenbankname>
      Beispiel:
      db2 attach to KNOTEN user ottomueller using kennwort
      db2 drop db WAS

Feedback