Unterstützte Vorgänge mit automatischer Schemaentwicklung

Automatic Schema Evolution wird auf Oracle-, MySQL-, PostgreSQL-, SQL Server-, Db2 LUW-, DB2400-, Teradata- und Oracle TimesTen-Zielen unterstützt.

Automatic Schema Evolution wird auf Oracle-, MySQL-, PostgreSQL-, SQL Server-, Db2 LUW-, Db2 zOS-, DB2400-, Sybase-, Teradata-, Oracle TimesTen- und Snowflake-Quellen unterstützt.

Folgende Vorgänge werden unterstützt:

Die Standardantwort "Automatische Schemaentwicklung" kann mit AUTOSCHEMAOPTIONS überschrieben werden. Folgende Optionen werden unterstützt:
- TYPEMAP: Verwenden Sie diese Option, um die standardmäßige Datentypzuordnung außer Kraft zu setzen
- IGNORE_DATA_TRUNCATION: Wenn bei der Standarddatentypzuordnung mögliche Daten abgeschnitten werden, wird Replicat standardmäßig mit dem entsprechenden Fehler beendet. Um diese Datenabschneidungsfehler zu ignorieren und zuzulassen, dass das Replicat ohne Abbruch fortgesetzt wird, können Sie AUTOSCHEMAOPTIONS IGNORE_DATA_TRUNCATION in der Replicat-Parameterdatei angeben.
- IGNORE_MODIFY_KEY_COLUMN: Standardmäßig lässt die automatische Schemaentwicklung nicht zu, dass die Primärschlüsselspalten geändert werden, und Replicat wird in solchen Fällen mit einem entsprechenden Fehler abgebrochen. Sie können AUTOSCHEMAOPTIONS IGNORE_MODIFY_KEY_COLUMN angeben, um alle Änderungen an den Schlüsselspalten zu überspringen.
- ALLOW_MODIFY_KEY_COLUMN: Standardmäßig lässt Automatic Schema Evolution das Ändern der Primärschlüsselspalte(n) nicht zu, und Replicat wird in solchen Fällen abgebrochen. Sie können AUTOSCHEMAOPTIONS ALLOW_MODIFY_KEY_COLUMN angeben, um Änderungen an den Schlüsselspalten zuzulassen.
- MODIFY_COLUMN_NULLABILITY_ONLY: Sie können AUTOSCHEMAOPTIONS MODIFY_COLUMN_NULLABILITY_ONLY angeben, wenn sie nur an einer Änderung der Nichtigbarkeit der Spalte und nicht an einer Typänderung interessiert sind.

Automatic Schema Evolution unterstützt die folgenden Vorgänge basierend auf den Schemaänderungen, die aus den Metadatendatensätzen in den Traildateien ermittelt werden, um das Schema der Quelle und der Zieltabellen zu synchronisieren:

Fehlende Tabelle in der Zieldatenbank erstellen
Ändern der Zieltabelle durch Ausführen von ADD/MODIFY/DROP-Spalten

Basierend auf allen Metadaten der Quellspalte wird standardmäßig der am besten geeignete Datentyp für die entsprechende Zielspalte ausgewählt.

HINWEIS: Prüfen Sie die Standarddatentypzuordnungen für das jeweilige Replikationsszenario von Quelldatenbank zu Zieldatenbank aus der Datentypzuordnung, bevor Sie die automatische Schemaentwicklung implementieren.

Die Zieldatentypen sind in allen Fällen möglicherweise nicht identisch mit dem Quelldatentyp. Wo immer möglich, wird der Zieldatentyp so gewählt, dass der Zieltyp immer kompatibel und groß genug (mit derselben Größe wie die Quellspalte oder breiter) ist, um die Daten der entsprechenden Quellspalte aufnehmen zu können. In einigen Fällen, in denen kein geeigneter Typ für den entsprechenden Quellspalten-Datentyp in der Zieldatenbank verfügbar ist (wie die verfügbaren Typen in der Zieldatenbank das Abschneiden von Daten verursachen können), wird ein Fehler mit einer entsprechenden Empfehlung an den Benutzer zurückgegeben.

Fehlende Tabelle erstellen

AutoSchema unterstützt die folgenden Anwendungsfälle:

Erstellen Sie die fehlende Tabelle auf dem Ziel, während Sie die von CDC Extract generierten Traildaten anwenden.
Erstellen Sie die fehlende Tabelle auf dem Ziel, während Sie die Traildaten anwenden, die beim erstmaligen Laden von Extract generiert werden.
Wenn Sie den Trail nur anwenden, der von initialLoad Extract generiert wird, können Sie die vorhandene Zieltabelle löschen und einen weiteren Extract erstellen, indem Sie OPTYPE RECREATE als Teil der Einschlusskriterien für DDL AUTOSCHEMA angeben.
Wenn alle entsprechenden Quellschlüsselspalten aus den Trailmetadaten nicht auf Null gesetzt werden können, erstellt Automatic Schema die Zieltabelle mit einer PRIMARY KEY-Klausel mit allen entsprechenden Spalten.
Wenn eine der entsprechenden Quellschlüsselspalten aus den Trailmetadaten auf Null gesetzt werden kann, erstellt Automatic Schema die Zieltabelle mit einer UNIQUE KEY-Klausel mit allen entsprechenden Spalten.

Vorhandene Tabelle ändern

Wenn Spalten in der Quelle hinzugefügt/ausgelöscht/geändert werden, werden die entsprechenden ALTER TABLE-DDLs generiert und in den entsprechenden zugeordneten Zieltabellen ausgeführt. Das automatische Schema unterstützt Änderungen, die sich nur auf den Typ (einschließlich Datentypname, Länge, Nachkommastellen, Skalierung) und das Nullbarkeits-Constraint beziehen. Es werden jedoch keine Änderungen an anderen Spaltenattributen berücksichtigt. Wenn typ-/nullfähigkeitsbezogene Schemaänderungen in den Quellspalten ermittelt werden, werden sie in die Zielspalten propagiert.

Eine oder mehrere Schemaänderungen in der Quelltabelle können zu einzelnen oder mehreren ALTER TABLE-DDLs in den zugeordneten Zieltabellen führen, wie von der jeweiligen Zieldatenbank unterstützt. Die Anzahl der DDLs auf dem Ziel hängt von der Syntax ab, die in einer bestimmten Zieldatenbank unterstützt wird, z.B. in den folgenden Fällen:

In wenigen Datenbanken ist das Hinzufügen/Löschen/Ändern mehrerer Spalten in einer einzelnen ALTER TABLE DDL nicht zulässig.
Nur wenige Datenbanken erlauben keine Änderung des Typs und der Nullierbarkeit von Spalten in einer einzelnen ALTER TABLE DDL-Anweisung.

In diesen Fällen wird die erforderliche Anzahl von ALTER TABLE DDL-Anweisungen basierend auf den Zieldatenbankanforderungen in der Zieltabelle ausgeführt.

Es ist möglich, dass sich das automatische Schema auf die Zieldatenbank auswirkt, die weitere Aktionen erfordert. Beispiel: Wenn eine ALTER TABLE MODIFY COLUMN dazu führen kann, dass Daten abgeschnitten werden, können verschiedene Datenbanken dies auf unterschiedliche Weise verarbeiten. Eine Datenbank kann erkennen, dass einige vorhandene Daten durch den Vorgang abgeschnitten werden können. Dadurch wird das Replicat gestoppt. Dies geschieht normalerweise zwischen Oracle und MySQL, wenn MySQL mit aktiviertem Strict-Modus ausgeführt wird. Wenn MySQL jedoch im nicht strengen Modus konfiguriert ist, kann die Traktion ohne Warnung erfolgen.

Je nachdem, wie das System konfiguriert ist, kann das Replicat für IBM i hängen bleiben. Für einige Aktionen auf Db2 (früher Db2 LUW) und Db2 z/OS ist bei bestimmten Aktionen möglicherweise eine Tabellenreorganisation erforderlich. Unter Db2 z/OS wird eine Drop-Spalte erst erkannt, wenn eine Reorganisation ausgeführt wird. Für Db2 könnte die Tabelle in einem Status mit ausstehender Reorganisation enden und keine weiteren Vorgänge mehr zulassen.

HINWEIS: Bei Bedarf können Sie den Ein-/Ausschlusskriterien für DDL AUTOSCHEMA selektiv OPTYPE ADDCOLUMN, OPTYPE DROPCOLUMN und OPTYPE MODIFYCOLUMN hinzufügen.