Vorbereitung der Umstellung auf Oracle 12c sowie Unterstützung alltäglicher Aufgaben


Hallo und willkommen zu unserem ersten Newsletter 2017. In dieser Ausgabe wollen wir zwei neue Features von KeepTool vorstellen:

  • Ausführen eines Initialisierungs-Skripts nach der Datenbankanmeldung
  • Vermeiden von Zeichensatzproblemen bei der Migration nach Oracle 12c.

Darüber hinaus möchten wir Ihnen zeigen, wie Sie Reverse-DB mit einem Windows-Batchfile periodisch aufrufen können, um die Datenbankstruktur regelmäßig zu sichern.

Ausführen eines Initialisierungs-Skripts nach der Datenbankanmeldung

Seit KeepTool Version 12.1.3 kann nach dem Anmelden in Hora ein Initialisierungsskript ausgeführt werden.

Für jede Datenbankverbindung kann ein eigener Skriptname im erweiterten Bereich des Connect-Dialogs zugeordnet werden.

 

1-Initilization-script

 

Anregung beschreiben wir hier zwei Situationen, für die das Skript ausgesprochen hilfreich sein kann:

  • Beim Verbinden zur Datenbank über eine „SQL*Net“-Verbindung initialisiert der Oracle-Client die Session-Variablen für Spracheinstellungen aus Registry-Einträgen bzw. Umgebungsvariablen des Betriebssystems. Bei einer direkten TCP/IP-Verbindung müssen Variablen wie NLS_LANGUAGE oder NLS_TERRITORY manuell initialisiert werden. Mit Hilfe des Initialisierungsskripts kann das jetzt automatisiert werden.
  • In PL/SQL hinterlegte Geschäftslogik oder datensatzbezogene Anwenderberechtigungen (Virtual Private Database) benötigen unter Umständen eine Initialisierung, die normalerweise im Rahmen der Benutzeranmeldung durch die (Web-) Applikation durchgeführt wird. Damit die Geschäftslogik vom Entwickler auch innerhalb von Hora getestet werden kann, muss diese Initialisierung ebenfalls durchgeführt werden. Das kann über den Initialisierungsskript jetzt automatisiert werden.

 

Der folgende Beispielskript initialisiert zunächst zwei Session-Variablen mit nationalen Ländereinstellungen. Anschließend wird der Windows-Benutzername ermittelt und an die Geschäftslogik weiter gegeben:

Beispiel-Skript:

2-init-script

 

Nach der Benutzeranmeldung zeigt Hora das Ausführen des Skripts als Tooltipp-Hinweis an:

The script is shown as a tooltip notification after you connect:

 

3-running-window

 

Vermeiden von Zeichensatzproblemen bei der Migration nach Oracle 12c

 

Einige unserer Kunden haben im Laufe des vergangenen Jahres von ihren Erfahrungen bei der Migration ihrer Datenbanken nach Oracle 12c berichtet. In vielen Fällen wurde dabei kein direkter Upgrade der bestehenden Datenbank vorgenommen. Vielmehr wurde eine neue „pluggable“ 12c Datenbank eingerichtet. Anschließend wurden die Daten über die Export/Import-Werkzeuge migriert.

Ein in diesem Zusammenhang häufig genanntes Thema war die Frage, wie man möglichst fehlerfrei zu einem Multibyte-Zeichensatz wie AL32UTF8 (Voreinstellung in Oracle 12c) wechselt.

Vor allem in den westlichen Ländern werden in Oracle 11g-Datenbanken häufig noch sprachenabhängig 1-Byte-Zeichensätze wie WE8ISO8859P1 oder WE8MSWIN1252 benutzt. Hier wird jedes Zeichen, also auch länderspezifische Symbole wie die deutschen Umlaute ä, ö, ü und ß, in einem einzelnen Byte abgelegt, z.B. hexadezimal E4, F6, FC und DF.

Unicode-Zeichensätze wie AL32UTF8 sind in der Lage, eine Vielzahl von länderspezifischen Zeichen aus unterschiedlicher Sprachen einschließlich ideographischer Symbole abzubilden, wie sie in asiatischen Sprachen verwendet werden. Dieser Vorteil wird allerdings dadurch erkauft, dass für ein Zeichen ggf. mehr als ein Byte erforderlich wird.

Beim Aufbau einer Tabellenstruktur können Sie die Länge von VARCHAR2-Spalten entweder als Anzahl Bytes oder als Anzahl Zeichen definieren. Solange Sie mit einem Zeichensatz von einem Byte Länge arbeiten, brauchen Sie sich nicht um den Unterschied zwischen BYTE und CHAR –Semantik zu kümmern. Wenn Sie nun den Umstieg auf Oracle 12c mit einhergehender Zeichensatzkonvertierung zu AL32UTF8 vorbereiten, ist es empfehlenswert vorher sicherzustellen, dass alle Daten ins Zielsystem passen.

Im ersten Schritt kann man noch im abgelösten System die Spalten per ALTER TABLE in CHAR-Semantics überführen, und ggf. auch den Datenbankparameter nls_length_semantics mit ändern. Damit ist sichergestellt, dass später die Ziel-Struktur dieselbe Anzahl Zeichen aufnehmen kann, und zwar unabhängig von der tatsächlichen Anzahl Bytes.

Leider reicht das noch nicht aus. Unabhängig von der gewählten NLS_LENGTH_SEMANTICS-Einstellung darf die Länge von VARCHAR2-Spalten die Grenze von 4.000 Bytes nicht überschreiten. In Oracle 12c ist es zwar möglich, die maximale Länge auf bis zum 32.767 Bytes durch entsprechendes Setzen des Initialisierungsparameters MAX_STRING_SIZE auf EXTENDED zu erhöhen, was wir im Rahmen dieses Beispiels aber nicht tun wollen.

Da Sonderzeichen wie ä, ö, ü und ß nun zwei Bytes belegen, kann es also beispielsweise dazu kommen, dass nicht mehr alle Daten aus einer VARCHAR2(4000)-Spalte in die Zielstruktur passen. Da hilft nur, die Daten ausfindig zu machen und bereits vor dem Export zu kürzen, ansonsten werden die betroffenen Zeilen beim Import übergangen und eine entsprechende Fehlermeldung ausgegeben.

Nun kommen wir dazu zu zeigen, was unser neuer Dialog leistet. Um zu zeigen, wie Hora sie beim Auffinden der entsprechenden Daten unterstützt, nehmen wir an,

  • Die Datenbank benutzt den Zeichensatz WE8MSWIN1252
  • Der Datenbankparameter nls_length_semantics steht noch auf BYTE
  • Der Session-Parameter wurde auf CHAR geändert,
    B. per after-logon Trigger oder Hora’s login-Initialisierungsskript.

Sie können diese Einstellungen in Hora auf der Database-Seite, Lasche NLS parameters überprüfen.

 

4-nls-parameter

 

Nehmen wir weiter an, dass es in der Ausgangs-Datenbank eine Tabelle DIALOG_TEST mit folgenden Spalten gibt:

 

5-column-definition

Die Spalte SHORT2 benutzt nls_length_semantics entsprechend des gesetzten Session-Parameters, d.h. CHAR.

 

Wir füllen die Tabelle mit den hier gezeigten Werten:

6-insert-statements

 

Die lange Zeichenkette in der ersten Zeile (ID=1) enthält 133 mal den String ‘abcdefghijklmnopqrstuvwxyzäöüß’, der eine Länge von 30 Zeichen bzw. 30 Bytes  hat. Daraus ergibt sich eine gesamte Feldlänge von 133*30 = 3.990 Zeichen bzw. Bytes. Wenn der Inhalt der Tabelle in eine AL32UTF8-Datenbank exp/importiert wird, erhöht sich der Speicherbedarf auf 133*(30+4) = 4.522 Bytes, womit das Standard-Maximum von 4.000 Bytes überschritten wird.

Die Zeichenketten in SHORT und SHORT2 sind jeweils 30 Zeichen lang. In einer AL32UTF8-Datenbank müssen diese CHAR semantics benutzen, damit alle 30 Zeichen hinein passen.

Der neue Dialog kann von Horas“Schema”-Menü aufgerufen werden:

 

7-find-varchar

 

Der Kopfbereich des Dialogs zeigt

  • Die NLS_LENGTH_SEMANTICS-Einstellung der Session
  • Parameterwert für max string size“
    Der Wert STANDARD zeigt an, dass 4.000 die maximale Bytelänge für Spalten vom Typ VARCHAR2 ist.
  • Zeichensatz der aktuellen Datenbank.
  • In einer Kombobox können Sie den Zielzeichensatz für die beabsichtigte Konvertierung auswählen.
    Hier haben wir uns für AL32UTF8 entschieden:

 

8-empty-varchar-dialog

 

Das erste Kontrollkästchen “ Target byte length > 4000“ ist immer angekreuzt. Nachdem der Schalter „Find columns“ geklickt wurde, zeigt die Tabellendarstellung darunter alle Tabellenspalten an, deren Daten im Ziel-Zeichensatz die Byte-Länge von 4.000 Zeichen überschreiten.

 

8-empty-varchar-dialog

 

Im Beispiel wurde die Spalte LONG_TEXT gefunden. Der längste Wert im Multi-Byte-Zeichensatz 4.522 Bytes erfordern würde. Sie können das Problem lösen, indem Sie entweder die Daten vor der Konvertierung beschneiden oder den Datenbankparameter MAX_STRING_SIZE auf EXTENDED ändern.

 

Wenn beide Kontrollkästchen ausgewählt sind, führt der Dialog eine zusätzliche Überprüfung durch, um Spalten zu finden, deren Byte-Länge in der Zieldatenbank die Anzahl von Bytes bezogen auf die Spaltendefinition basierend auf der BYTE-Semantik überschreiten würde. Die Spalte SHORT wird als betroffen angezeigt, während SHORT2 nicht gemeldet wird. SHORT war mit 30 Byte Länge definiert. In AL32UTF8 würde es aber 33 Bytes benötigen wegen der drei Umlaute am Anfang der Zeichenkette ‘ÄÖÜ456789012345678901234567890‘. SHORT2 wird nicht als betroffen angezeigt, weil es als Ergebnis der aktuellen Datenbankeinstellung NLS_LENGTH_SEMANTICS bereits als 30 Zeichen definiert war.

 

10-find-columns

 

Das Memofeld im unteren Teil des Dialogs zeigt eine SQL-Abfrage. Wird diese ausgeführt, werden die Daten angezeigt, die zu einer Verletzung der Längenüberprüfung der Bezugsspalte führen, in diesem Fall  DIALOG_TEST.LONG_TEXT . Das Ergebnis der Abfrage erscheint im SQL-Ergebnisfenster:

 

11-query-results

 

 

Zusammengefasst gesagt, erspart Ihnen der neue Dialog viel Zeit, um Spalten und deren Daten zu identifizieren, die Probleme beim Umstieg in einen Mehrbyte-Zeichensatz verursachen können.

Ausführen von Reverse DB von einem Batchfile aus

In diesem Beispiel zeigen wir Ihnen ein Beispiel, wie der Reverse DB Engineer aus einem Windows-Batchfile periodisch aufgerufen werden kann, um DDL-Skripte mit Zeitstempel-basiertem Dateinamen zu erzeugen:

set year=%date:~6,4%

set month=%date:~3,2%

set day=%date:~0,2%

set database=pdbora12c4

set schema=hr

set pwd=hr

set target="D:\MyDLLs\%year%_%month%_%day%_%schema%_%database%.sql"

"%ProgramFiles%\KeepTool\KeepTool-12\RevDDL.exe" %target% %schema%/%pwd%@%database%

pause

RevDDL bekommt hier zwei Parameter übergeben: Der Name inkl. Pfadangabe der .sql-Datei und die Anmeldedaten des Benutzers.

Der Name der generierten .sql-Datei ist in diesem Fall:

D:\MyDDLs\2017_01_09_hr_pdbora12c4.sql

Sie können das Batchfile an Ihr eigenes Datumsformat anpassen. Im Beispiel ist es YYYY-MM-DD. Geben Sie einfach “date“ in der Kommandozeile an, um die aktuelle Einstellung auf Ihrem Rechner anzuzeigen.

Abschließende Überlegungen:

Weitere neuen Features finden Sie unter https://keeptool.com/de/release-notes/. Wir hoffen, dass Sie die Themen unseres heutigen Newsletters nutzbringend einsetzen können. Bitte teilen Sie uns Ihre Vorschläge für zukünftige Themen mit. Schreiben Sie uns einfach eine E-Mail an support@keeptool.com. Wir melden uns mit einem neuen Newsletter im April.