Erstellen von Skriptdateien (DB2ToSQL)
Der erste Schritt vor dem Starten der SSMA-Konsolenanwendung besteht darin, die Skriptdatei zu erstellen und ggf. die Variable-Wertdatei und die Serververbindungsdatei zu erstellen.
Die Skriptdatei kann in drei Abschnitte unterteilt werden, viz..,:
config: Ermöglicht dem Benutzer das Festlegen der Konfigurationsparameter für die Konsolenanwendung.
server: Ermöglicht es dem Benutzer, die Quell-/Zielserverdefinitionen festzulegen. Dies kann sich auch in einer separaten Serververbindungsdatei befinden.
Skriptbefehle: Ermöglicht es dem Benutzer, SSMA-Workflowbefehle auszuführen.
Jeder Abschnitt wird im Folgenden ausführlich beschrieben:
Konfigurieren von DB2-Konsoleneinstellungen
Die Konfigurationen eines Skripts werden in der Konsolenskriptdatei angezeigt.
Wenn eines der Elemente im Konfigurationsknoten angegeben ist, werden sie als globale Einstellung festgelegt, d. h. sie gelten für alle Skriptbefehle. Diese Konfigurationselemente können auch innerhalb jedes Befehls im Skriptbefehlsbereich festgelegt werden, wenn der Benutzer die globale Einstellung außer Kraft setzen möchte.
Zu den vom Benutzer konfigurierbaren Optionen gehören:
Ausgabefensteranbieter: Wenn das Attribut "suppress-messages" auf "true" festgelegt ist, werden die befehlsspezifischen Nachrichten nicht auf der Konsole angezeigt. Die Beschreibung der Attribute wird unten angegeben:
ziel: Gibt an, ob die Ausgabe in eine Datei oder ein Stdout gedruckt werden muss. Dies ist standardmäßig "false".
Dateiname: Der Pfad der Datei (optional).
Suppress-Messages: Unterdrückt Nachrichten auf der Konsole. Dies ist standardmäßig "false".
Beispiel:
<output-providers> <output-window suppress-messages="<true/false>" (optional) destination="<file/stdout>" (optional) file-name="<file-name>" (optional) /> </output-providers>or
<...All commands...> <output-window suppress-messages="<true/false>" (optional) destination="<file/stdout>" (optional) file-name="<file-name>" (optional) /> </...All commands...>Datenmigrationsverbindungsanbieter: Gibt an, welcher Quell-/Zielserver für die Datenmigration berücksichtigt werden soll. Der zuletzt verwendete Quellserver gibt an, dass der zuletzt verwendete Quellserver für die Datenmigration verwendet wird. In ähnlicher Weise gibt die Zielverwendung nach der letzten Verwendung an, dass der zuletzt verwendete Zielserver für die Datenmigration verwendet wird. Der Benutzer kann den Server (Quelle oder Ziel) auch mithilfe der Attribute Source-Server oder Target-Server angeben.
Es kann nur ein oder das andere angegebene Attribut verwendet werden, d. h.:
source-use-last-used="true" (Standard) oder source-server="source_servername"
target-use-last-used="true" (Standard) oder target-server="target_servername"
Beispiel:
<output-providers> <data-migration-connection source-use-last-used="true" target-server="<target-server-unique-name>"/> </output-providers>or
<migrate-data> <data-migration-connection source-server="<source-server-unique-name>" target-use-last-used="true"/> </migrate-data>Benutzereingabe-Popup: Dies ermöglicht die Behandlung von Fehlern, wenn die Objekte aus der Datenbank geladen werden. Der Benutzer stellt die Eingabemodi bereit, und im Falle eines Fehlers wird die Konsole wie vom Benutzer angegeben fortgesetzt.
Zu den Modi gehören:
ask-user : Fordert den Benutzer auf, den Vorgang fortzusetzen ('Ja') oder einen Fehler ('Nein').
error- Die Konsole zeigt einen Fehler an und hält die Ausführung an.
continue- The console continues with the execution.
Der Standardmodus ist ein Fehler.
Beispiel:
<output-providers> <user-input-popup mode="<ask-user/continue/error>"/> </output-providers>or
<!-- Connect to target database --> <connect-target-database server="<target-server-unique-name>"> <user-input-popup mode="<ask-user/continue/error>"/> </connect-target-database>Anbieter erneut verbinden: Dadurch kann der Benutzer die Einstellungen für die erneute Verbindung im Fall von Verbindungsfehlern festlegen. Dies kann sowohl für Quell- als auch für Zielserver festgelegt werden.
Die Modi für die erneute Verbindung sind:
reconnect-to-last-used-server: If the connection is not active, it tries to reconnect to the last server used at most 5 times.
generate-an-error: Wenn die Verbindung nicht aktiv ist, wird ein Fehler generiert.
Der Standardmodus wird als Fehler generiert.
Beispiel:
<output-providers> <reconnect-manager on-source-reconnect="<reconnect-to-last-used-server/generate-an-error>" on-target-reconnect="<reconnect-to-last-used-server/generate-an-error>"/> </output-providers>or
<!--synchronization--> <synchronize-target> <reconnect-manager on-target-reconnect="reconnect-to-last-used-server"/> </synchronize-target>or
<!--data migration--> <migrate-data server="<target-server-unique-name>"> <reconnect-manager on-source-reconnect="reconnect-to-last-used-server" on-target-reconnect="generate-an-error"/> </migrate-data>Konverterüberschreibanbieter: Dadurch kann der Benutzer Objekte verarbeiten, die bereits auf der Zielmetabasis vorhanden sind. Die möglichen Aktionen umfassen:
fehler: Die Konsole zeigt einen Fehler an und hält die Ausführung an.
überschreiben: Überschreibt vorhandene Objektwerte. Diese Aktion wird standardmäßig ausgeführt.
skip: Die Konsole überspringt die Objekte, die bereits in der Datenbank vorhanden sind.
ask-user: Fordert den Benutzer zur Eingabe auf ('ja'/ 'nein')
Beispiel:
<output-providers> <object-overwrite action="<error/skip/overwrite/ask-user>"/> </output-providers>or
<convert-schema object-name="<object-name>"> <object-overwrite action="<error/skip/overwrite/ask-user>"/> </convert-schema>Failed Prerequisites Provider: This enables the user to handle any prerequisites that are required for processing a command. Der Strict-Modus ist standardmäßig "false". Wenn sie auf "true" festgelegt ist, wird eine Ausnahme generiert, damit die Voraussetzungen nicht erfüllt werden.
Beispiel:
<output-providers> <prerequisites strict-mode="<true/false>"/> </output-providers>Stoppvorgang: Wenn der Benutzer den Vorgang während des Mittleren Vorgangs beenden möchte, kann der Hotkey "STRG+C" verwendet werden. SSMA für DB2-Konsole wartet auf den Abschluss des Vorgangs und beendet die Konsolenausführung.
Wenn der Benutzer die Ausführung sofort beenden möchte, kann der Hotkey "STRG+C" erneut zum abrupten Beenden der SSMA-Konsolenanwendung gedrückt werden.
Statusanbieter: Informiert den Fortschritt der einzelnen Konsolenbefehle. Diese Einstellung ist standardmäßig deaktiviert. Die Statusberichtsattribute umfassen:
aus
alle 1 %
alle 2 %
alle 5 %
alle 10 %
alle 20 %
Beispiel:
<output-providers> progress-reporting enable="<true/false>" (optional) report-messages="<true/false>" (optional) report-progress="every-1%/every-2%/every-5%/every-10%/every-20%/off" (optional)/> </output-providers>or
<...All commands...> <progress-reporting enable="<true/false>" (optional) report-messages="<true/false>" (optional) report-progress="every-1%/every-2%/every-5%/every-10%/every-20%/off" (optional)/> </...All commands...>Logger Verbosity: Legt die Ausführlichkeitsebene des Protokolls fest. Dies entspricht der Option "Alle Kategorien" auf der Benutzeroberfläche. Standardmäßig ist die Ausführlichkeitsebene des Protokolls "error".
Zu den Loggerebenenoptionen gehören:
schwerwiegender Fehler: Es werden nur schwerwiegende Fehlermeldungen protokolliert.
fehler: Nur Fehler- und schwerwiegende Fehlermeldungen werden protokolliert.
Warnung: Alle Ebenen mit Ausnahme von Debug- und Infomeldungen werden protokolliert.
Info: Alle Ebenen mit Ausnahme von Debugmeldungen werden protokolliert.
debug: Alle protokollierten Nachrichtenebenen.
Hinweis
Obligatorische Nachrichten werden auf jeder Ebene protokolliert.
Beispiel:
<output-providers> <log-verbosity level="fatal-error/error/warning/info/debug"/> </output-providers>or
<...All commands...> <log-verbosity level="fatal-error/error/warning/info/debug"/> </...All commands...>Überschreiben des verschlüsselten Kennworts: Wenn 'true', das im Abschnitt mit der Serverdefinition der Serververbindungsdatei oder in der Skriptdatei angegebene Klartextkennwort außer Kraft setzt, falls vorhanden, das verschlüsselte Kennwort außer Kraft. Wenn kein Kennwort im Klartext angegeben ist, wird der Benutzer aufgefordert, das Kennwort einzugeben.
Hier treten zwei Fälle auf:
Wenn die Option "False" ist, lautet die Reihenfolge der Suche "Protected storage-Script> File-Server Connection File-Server> Connection File-> Prompt User".
Wenn die Option "Außerkraftsetzung" zutrifft, lautet die Reihenfolge der Suche "Script File-Server> Connection File-Prompt> User".
Beispiel:
<output-providers> <encrypted-password override="<true/false>"/> </output-providers>
Die nicht konfigurierbare Option lautet:
- Maximale Wiederholungsversuche: Wenn eine etablierte Verbindung aufgrund eines Netzwerkfehlers ausfällt oder unterbrochen wird, muss der Server erneut verbunden werden. Die Wiederholungsversuche dürfen maximal 5 Wiederholungsversuche ausführen, danach führt die Konsole automatisch die erneute Verbindung aus. Die Einrichtung der automatischen Erneutverbindung reduziert ihren Aufwand beim erneuten Ausführen des Skripts.
Serververbindungsparameter
Serververbindungsparameter können in der Skriptdatei oder in der Serververbindungsdatei definiert werden. Weitere Informationen finden Sie im Abschnitt "Creating the Server Connection Files (OracleToSQL) ".
Skriptbefehle
Die Skriptdatei enthält eine Sequenz von Migrationsworkflowbefehlen im XML-Format. Die SSMA-Konsolenanwendung verarbeitet die Migration in der Reihenfolge der Befehle, die in der Skriptdatei angezeigt werden.
Beispielsweise folgt eine typische Datenmigration einer bestimmten Tabelle in einer DB2-Datenbank der Hierarchie von: Schema -> Tabelle.
Wenn alle Befehle in der Skriptdatei erfolgreich ausgeführt werden, wird die SSMA-Konsolenanwendung beendet und gibt das Steuerelement an den Benutzer zurück. Der Inhalt einer Skriptdatei ist mehr oder weniger statisch mit Variableninformationen, die entweder in einer Creating Variable Value Files (OracleToSQL) enthalten sind, oder in einem separaten Abschnitt in der Skriptdatei für Variablenwerte.
Beispiel:
<!--Sample of script file commands -->
<ssma-script-file>
<script-commands>
<create-new-project project-folder="<project-folder>"
project-name="<project-name>"
overwrite-if-exists="<true/false>"/>
<connect-source-database server="<source-server-unique-name>"/>
<save-project/>
<close-project/>
</script-commands>
</ssma-script-file>
Vorlagen, die aus drei Skriptdateien (für die Ausführung verschiedener Szenarien), variabler Wertdatei und einer Serververbindungsdatei bestehen, werden im Ordner "Beispielkonsolenskripts" des Produktverzeichnisses bereitgestellt:
AssessmentReportGenerationSample.xml
ConversionAndDataMigrationSample.xml
SqlStatementConversionSample.xml
VariableValueFileSample.xml
ServersConnectionFileSample.xml
Sie können die Vorlagen (Dateien) nach dem Ändern der dort angezeigten Parameter zur Relevanz ausführen.
Vollständige Liste der Skriptbefehle finden Sie unter Ausführen der SSMA-Konsole (DB2ToSQL)
Skriptdateiüberprüfung
Der Benutzer kann seine Skriptdatei ganz einfach anhand der Schemadefinitionsdatei "O2SSConsoleScriptSchema.xsd" überprüfen, die im Ordner "Schemas" verfügbar ist.
Nächster Schritt
Der nächste Schritt beim Ausführen der Konsole ist das Erstellen von Variablenwertdateien (DB2ToSQL).
Weitere Informationen
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für