Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Verwenden einer PostgreSQL-Datenbank als Ziel für AWS Database Migration Service Sie können Daten entweder aus einer anderen PostgreSQL-Datenbank oder aus einer der anderen unterstützten Datenbanken in PostgreSQL-Datenbanken migrieren. AWS DMS Hinweise zu Versionen von PostgreSQL, die als Ziel AWS DMS unterstützt werden, finden Sie unter. [Ziele für AWS DMS](CHAP_Introduction.Targets.md) **Anmerkung** Amazon Aurora Serverless ist als Ziel für Amazon Aurora mit PostgreSQL-Kompatibilität verfügbar. Weitere Informationen zu Amazon Aurora Serverless finden Sie unter [ Verwenden von Amazon Aurora Serverless v2 ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html) im Amazon Aurora-Benutzerhandbuch. * * Aurora-Serverless-DB-Cluster sind nur von einer Amazon VPC aus zugänglich und können keine [öffentliche IP-Adresse](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.requirements.html) verwenden. Wenn Sie also eine Replikations-Instance in einer anderen Region als Aurora PostgreSQL Serverless haben möchten, müssen Sie [VPC-Peering](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.VPC.html#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCPeer) konfigurieren. Prüfen Sie andernfalls die Verfügbarkeit von Aurora-PostgreSQL-Serverless-[Regionen](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.AuroraFeaturesRegionsDBEngines.grids.html#Concepts.Aurora_Fea_Regions_DB-eng.Feature.Serverless) und entscheiden Sie sich, eine dieser Regionen sowohl für Aurora PostgreSQL Serverless als auch für Ihre Replikations-Instance zu verwenden. Die Babelfish-Funktion ist in Amazon Aurora integriert. Hierfür entstehen keine zusätzlichen Kosten. Weitere Informationen finden Sie unter [Verwendung von Babelfish für Aurora PostgreSQL als Ziel für AWS Database Migration Service](#CHAP_Target.PostgreSQL.Babelfish). AWS DMS verwendet bei der Migration von Daten von der Quelle zum Ziel in der Volllastphase einen tabellenweisen Ansatz. Die Tabellenreihenfolge kann während der Volllastphase nicht garantiert werden. Die Tabellen sind während der Vollastphase und während des Anwendens der zwischengespeicherten Transaktionen für einzelne Tabellen nicht synchron. Dies hat zur Folge, dass aktive referentielle Integritätseinschränkungen während der Volllastphase zu Aufgabenfehlern führen können. In PostgreSQL werden Fremdschlüssel (referentielle Integritätseinschränkungen) mithilfe von Auslösern implementiert. AWS DMS Lädt während der Volllastphase jede Tabelle einzeln. Es wird ausdrücklich empfohlen, dass Sie Fremdschlüsseleinschränkungen während eines vollständigen Ladevorgangs mit einer der folgenden Methoden deaktivieren: + Deaktivieren Sie vorübergehend alle Auslöser aus der Instance und beenden Sie den vollständigen Ladevorgang. + Verwenden Sie den `session_replication_role`-Parameter in PostgreSQL. Ein Auslöser kann sich zu jedem beliebigen Zeitpunkt in einem der folgenden Zustände befinden: `origin`, `replica`, `always` und `disabled`. Wenn der `session_replication_role`-Parameter auf `replica` gesetzt ist, sind nur Auslöser aktiv, die sich im Status `replica` befinden, und sie werden ausgelöst, wenn sie aufgerufen werden. Andernfalls bleiben die Auslöser inaktiv. PostgreSQL verfügt über einen ausfallsicheren Mechanismus, um zu verhindern, dass eine Tabelle gekürzt wird, auch dann, wenn `session_replication_role` festgelegt ist. Sie können diesen als Alternative zur Deaktivierung von Auslösern verwenden, um den vollständigen Ladevorgang abzuschließen. Legen Sie hierfür den Vorbereitungsmodus der Zieltabelle auf `DO_NOTHING` fest. Andernfalls schlagen DROP- und TRUNCATE-Operationen fehl, wenn Fremdschlüsseleinschränkungen bestehen. In Amazon RDS können Sie diesen Parameter mithilfe einer Parametergruppe steuern/festlegen. Für eine PostgreSQL-Instance, die in Amazon EC2 ausgeführt wird, können Sie den Parameter direkt festlegen. Weitere Informationen zur Arbeit mit einer PostgreSQL-Datenbank als Ziel für AWS DMS finden Sie in den folgenden Abschnitten: **Topics** + [Einschränkungen bei der Verwendung von PostgreSQL als Ziel für AWS Database Migration Service](#CHAP_Target.PostgreSQL.Limitations) + [Einschränkungen bei der Verwendung von Amazon Aurora PostgreSQL Limitless als Ziel für AWS Database Migration Service](#CHAP_Target.PostgreSQL.Aurora.Limitations) + [Sicherheitsanforderungen bei der Verwendung einer PostgreSQL-Datenbank als Ziel für AWS Database Migration Service](#CHAP_Target.PostgreSQL.Security) + [Endpunkteinstellungen und zusätzliche Verbindungsattribute (ECAs) bei Verwendung von PostgreSQL als Ziel für AWS DMS](#CHAP_Target.PostgreSQL.ConnectionAttrib) + [Zieldatentypen für PostgreSQL](#CHAP_Target.PostgreSQL.DataTypes) + [Verwendung von Babelfish für Aurora PostgreSQL als Ziel für AWS Database Migration Service](#CHAP_Target.PostgreSQL.Babelfish) ## Einschränkungen bei der Verwendung von PostgreSQL als Ziel für AWS Database Migration Service Bei der Verwendung einer PostgreSQL-Datenbank als Ziel für AWS DMS gelten die folgenden Einschränkungen: + Bei heterogenen Migrationen wird der JSON-Datentyp intern in den nativen CLOB-Datentyp konvertiert. + Wenn bei einer Migration von Oracle zu PostgreSQL eine Spalte in Oracle ein NULL-Zeichen (Hex-Wert U\+0000) enthält, wird das NULL-Zeichen in ein Leerzeichen (Hex-Wert U\+0020) AWS DMS konvertiert. Der Grund hierfür ist eine PostgreSQL-Einschränkung. + AWS DMS unterstützt keine Replikation in eine Tabelle mit einem eindeutigen Index, der mit der Coalesce-Funktion erstellt wurde. + Wenn Ihre Tabellen Sequenzen verwenden, aktualisieren Sie den Wert von `NEXTVAL` für jede Sequenz in der Zieldatenbank, nachdem Sie die Replikation aus der Quelldatenbank beendet haben. AWS DMS kopiert Daten aus Ihrer Quelldatenbank, migriert aber während der laufenden Replikation keine Sequenzen zum Ziel. ## Einschränkungen bei der Verwendung von Amazon Aurora PostgreSQL Limitless als Ziel für AWS Database Migration Service Die folgenden Einschränkungen gelten bei der Verwendung von Amazon Aurora PostgreSQL Limitless als Ziel für: AWS DMS + AWS DMS Die Datenvalidierung unterstützt Amazon Aurora PostgreSQL Limitless nicht. + AWS DMS migriert Quelltabellen als Standardtabellen, die nicht verteilt werden. Nach der Migration können Sie diese Standardtabellen in Limitless-Tabellen konvertieren, indem Sie der offiziellen Konvertierungsanleitung folgen. ## Sicherheitsanforderungen bei der Verwendung einer PostgreSQL-Datenbank als Ziel für AWS Database Migration Service Aus Sicherheitsgründen muss das für die Datenmigration verwendete Benutzerkonto ein registrierter Benutzer in einer PostgreSQL-Zieldatenbank sein. Ihr PostgreSQL-Zielendpunkt erfordert Mindestbenutzerberechtigungen, um eine AWS DMS Migration auszuführen. Sehen Sie sich die folgenden Beispiele an. ``` CREATE USER newuser WITH PASSWORD 'your-password'; ALTER SCHEMA schema_name OWNER TO newuser; ``` Oder ``` GRANT USAGE ON SCHEMA schema_name TO myuser; GRANT CONNECT ON DATABASE postgres to myuser; GRANT CREATE ON DATABASE postgres TO myuser; GRANT CREATE ON SCHEMA schema_name TO myuser; GRANT UPDATE, INSERT, SELECT, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA schema_name TO myuser; GRANT TRUNCATE ON schema_name."BasicFeed" TO myuser; ``` ## Endpunkteinstellungen und zusätzliche Verbindungsattribute (ECAs) bei Verwendung von PostgreSQL als Ziel für AWS DMS Sie können Endpunkteinstellungen und zusätzliche Verbindungsattribute (ECAs) verwenden, um Ihre PostgreSQL-Zieldatenbank zu konfigurieren. Sie geben die Einstellungen an, wenn Sie den Zielendpunkt mithilfe der AWS DMS Konsole erstellen, oder indem Sie den `create-endpoint` Befehl in der mit der [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html) `--postgre-sql-settings '{"{{EndpointSetting}}": {{"value"}}, {{...}}}'` JSON-Syntax verwenden. Sie geben ECAs mithilfe des `ExtraConnectionAttributes` Parameters für Ihren Endpunkt an. Die folgende Tabelle zeigt die Endpunkteinstellungen, die Sie mit PostgreSQL als Ziel verwenden können. | Name | Description | | --- | --- | | `ConnectionTimeout` | Verwenden Sie dieses zusätzliche Verbindungsattribut (ECA), um das Endpunkt-Verbindungs-Timeout für die PostgreSQL-Instance in Sekunden festzulegen. Der Standardwert liegt bei 10 Sekunden. ECA-Beispiel:. `ConnectionTimeout=30` | | `MaxFileSize` | Gibt die maximale Größe (in KB) der CSV-Datei zum Übertragen von Daten nach PostgreSQL an.
Standardwert: 32768 KB (32 MB)
Gültige Werte: 1 bis 1 048 576 KB (bis zu 1,1 GB)
Beispiel: `--postgre-sql-settings '{"MaxFileSize": 512}'` | | `ExecuteTimeout` | Stellt die Zeitbeschränkung der Client-Anweisung für die PostgreSQL-Instance in Sekunden ein. Der Standardwert liegt bei 60 Sekunden.
Beispiel: `--postgre-sql-settings '{"ExecuteTimeout": 100}'` | | `AfterConnectScript= SET session_replication_role = replica` | Dieses Attribut verfügt über AWS DMS Bypass-Fremdschlüssel und Benutzer-Trigger, um die Zeit zu reduzieren, die für das Massenladen von Daten benötigt wird. | | `MapUnboundedNumericAsString` | Dieser Parameter behandelt Spalten mit unbegrenzten NUMERIC-Datentypen als STRING, um eine erfolgreiche Migration ohne Verlust der Präzision des numerischen Werts zu ermöglichen. Verwenden Sie diesen Parameter nur für die Replikation von einer PostgreSQL-Quelle zu einem PostgreSQL-Ziel oder für Datenbanken mit PostgreSQL-Kompatibilität.
Standardwert: false
Gültige Werte: false/true
Beispiel: `--postgre-sql-settings '{"MapUnboundedNumericAsString": "true"}`
Die Verwendung dieses Parameters kann zu einer gewissen Beeinträchtigung der Replikationsleistung führen, da eine Transformation von numerischen Werten in Zeichenfolgen und zurück in numerische Werte erfolgt. Dieser Parameter wird für DMS-Version 3.4.4 und höher unterstützt Verwenden Sie `MapUnboundedNumericAsString` nur in PostgreSQL-Quell- und -Zielendpunkten gemeinsam.
Bei Verwendung von `MapUnboundedNumericAsString` für PostgreSQL-Quellendpunkte wird die Präzision während CDC auf 28 beschränkt. Bei Verwendung von `MapUnboundedNumericAsString` für Zielendpunkte werden Daten mit einer Präzision von 28 und einer Skalierung von 6 migriert.
Verwenden Sie `MapUnboundedNumericAsString` nicht mit Nicht-PostgreSQL-Zielen.
Bei CDC werden unbegrenzte NUMERIC-Werte auf 1.000 Zeichen gekürzt, wenn ihre Zeichenfolgendarstellung diese Grenze überschreitet. | | `loadUsingCSV` | Verwenden Sie dieses zusätzliche Verbindungsattribut (ECA), um Daten für Volllastvorgänge mithilfe des Befehls\\ COPY zu übertragen.
Standardwert: `true`
Gültige Werte: true/false
ECA-Beispiel: `loadUsingCSV=true;`
**Hinweis: ** Wenn diese ECA auf „False“ gesetzt wird, kann dies zu einer gewissen Beeinträchtigung der Replikationsleistung führen, da INSERTS direkt ausgeführt werden. | | `DatabaseMode` | Verwenden Sie dieses Attribut, um das Standardverhalten der Replikationsverarbeitung von Postgresql-kompatiblen Endpunkten zu ändern, die eine zusätzliche Konfiguration erfordern, wie z. B. Babelfish-Endpunkte.
Standardwert: `DEFAULT`
Zulässige Werte: `DEFAULT`, `BABELFISH`
Beispiel: `DatabaseMode=default;` | | `BabelfishDatabaseName` | Verwenden Sie dieses Attribut, um den Namen der T-SQL Babelfish-Zieldatenbank anzugeben, in die migriert wird. Dieser ist erforderlich, wenn `DatabaseMode` auf `Babelfish` festgelegt ist. Es handelt sich hier nicht um die reservierte `babelfish_db`-Datenbank.
Beispiel: `BabelfishDatabaseName=TargetDb;` | ## Zieldatentypen für PostgreSQL Der PostgreSQL-Datenbank-Endpunkt für AWS DMS unterstützt die meisten PostgreSQL-Datenbankdatentypen. Die folgende Tabelle zeigt die PostgreSQL-Datenbank-Zieldatentypen, die bei der Verwendung unterstützt werden, AWS DMS und die Standardzuordnung von Datentypen. AWS DMS Weitere Hinweise zu AWS DMS Datentypen finden Sie unter. [Datentypen für den AWS Database Migration Service](CHAP_Reference.DataTypes.md) | AWS DMS Datentyp | PostgreSQL-Datentyp | | --- | --- | | BOOLEAN | BOOLEAN | | BLOB | BYTEA | | BYTES | BYTEA | | DATE | DATE | | TIME | TIME | | DATETIME | Wenn die Skalierung 0 bis 6 ist, verwenden Sie TIMESTAMP.
Wenn die Skalierung 7 bis 9 ist, verwenden Sie VARCHAR (37). | | INT1 | SMALLINT | | INT2 | SMALLINT | | INT4 | INTEGER | | INT8 | BIGINT | | NUMERIC | DECIMAL (P,S) | | REAL4 | FLOAT4 | | REAL8 | FLOAT8 | | STRING | Ist die Länge 1 bis 21.845, verwenden Sie VARCHAR (Länge in Byte).
Ist die Länge 21.846 bis 2.147.483.647, verwenden Sie VARCHAR (65535). | | UINT1 | SMALLINT | | UINT2 | INTEGER | | UINT4 | BIGINT | | UINT8 | BIGINT | | WSTRING | Ist die Länge 1 bis 21.845, verwenden Sie VARCHAR (Länge in Byte).
Ist die Länge 21.846 bis 2.147.483.647, verwenden Sie VARCHAR (65535). | | NCLOB | TEXT | | CLOB | TEXT | **Anmerkung** Beim Replizieren aus einer PostgreSQL-Quelle AWS DMS wird die Zieltabelle mit den gleichen Datentypen für alle Spalten erstellt, mit Ausnahme von Spalten mit benutzerdefinierten Datentypen. In solchen Fällen wird der Datentyp als "character varying" im Ziel erstellt. ## Verwendung von Babelfish für Aurora PostgreSQL als Ziel für AWS Database Migration Service Sie können SQL-Server-Quelltabellen unter Verwendung von AWS Database Migration Service zu einem Babelfish-für-Amazon-Aurora-PostgreSQL-Ziel migrieren. Mit Babelfish versteht T-SQL Aurora PostgreSQL den proprietären SQL-Dialekt von Microsoft SQL Server und unterstützt dasselbe Kommunikationsprotokoll. Somit können für SQL Server geschriebene Anwendungen jetzt mit weniger Codeänderungen mit Aurora verwendet werden. Die Babelfish-Funktion ist in Amazon Aurora integriert. Hierfür entstehen keine zusätzlichen Kosten. Sie können Babelfish über die Amazon-RDS-Konsole in Ihrem Amazon-Aurora-Cluster aktivieren. Wenn Sie Ihren AWS DMS Zielendpunkt mithilfe der AWS DMS Konsolen-, API- oder CLI-Befehle erstellen, geben Sie als Ziel-Engine ** Amazon Aurora PostgreSQL ** an und geben Sie der Datenbank den Namen babelfish\_db. ** ** Fügen Sie im ** Abschnitt ** Endpoint-Einstellungen Einstellungen hinzu, die auf `Babelfish` und für den Namen der `DatabaseMode` `BabelfishDatabaseName` Babelfish-Zieldatenbank festgelegt werden sollen. T-SQL ### Hinzufügen von Transformationsregeln zu Ihrer Migrationsaufgabe Wenn Sie eine Migrationsaufgabe für ein Babelfish-Ziel definieren, müssen Sie Transformationsregeln hinzufügen, die sicherstellen, dass DMS die vorab erstellten T-SQL Babelfish-Tabellen in der Zieldatenbank verwendet. Fügen Sie Ihrer Migrationsaufgabe zunächst eine Transformationsregel hinzu, die alle Tabellennamen in Kleinbuchstaben umschreibt. Babelfish speichert die Namen der Tabellen, die Sie verwenden, im `pg_class` PostgreSQL-Katalog in Kleinbuchstaben. T-SQL Wenn Sie jedoch SQL Server-Tabellen mit Namen in Groß- und Kleinschreibung haben, erstellt DMS die Tabellen mit nativen PostgreSQL-Datentypen anstelle der kompatiblen Datentypen. T-SQL Aus diesem Grund sollten Sie unbedingt eine Transformationsregel hinzufügen, die alle Tabellennamen in Kleinbuchstaben umschreibt. Beachten Sie, dass Spaltennamen nicht in Kleinbuchstaben umgewandelt werden sollten. Wenn Sie bei der Definition Ihres Clusters den Migrationsmodus für mehrere Datenbanken verwendet haben, fügen Sie als Nächstes eine Transformationsregel hinzu, die das ursprüngliche SQL-Server-Schema umbenennt. Stellen Sie sicher, dass Sie den SQL Server-Schemanamen so umbenennen, dass er den Namen der Datenbank enthält. T-SQL Wenn der ursprüngliche SQL Server-Schemaname beispielsweise dbo ist und Ihr T-SQL Datenbankname mydb ist, benennen Sie das Schema mithilfe einer Transformationsregel in mydb\_dbo um. **Anmerkung** Wenn Sie Babelfish für Aurora PostgreSQL 16 oder höher verwenden, ist der Standard-Migrationsmodus „Multidatabase“. Achten Sie bei der Ausführung von AWS DMS Migrationsaufgaben darauf, den Parameter für den Migrationsmodus zu überprüfen und die Transformationsregeln bei Bedarf zu aktualisieren. Wenn Sie den Einzeldatenbankmodus verwenden, benötigen Sie keine Transformationsregel, um Schemanamen umzubenennen. Schemanamen werden der T-SQL Zieldatenbank in Babelfish eins zu eins zugeordnet. Die folgende Beispieltransformationsregel schreibt alle Tabellennamen in Kleinbuchstaben um und benennt den ursprünglichen SQL-Server-Schemanamen von `dbo` in `mydb_dbo` um. ``` { "rules": [ { "rule-type": "transformation", "rule-id": "566251737", "rule-name": "566251737", "rule-target": "schema", "object-locator": { "schema-name": "dbo" }, "rule-action": "rename", "value": "mydb_dbo", "old-value": null }, { "rule-type": "transformation", "rule-id": "566139410", "rule-name": "566139410", "rule-target": "table", "object-locator": { "schema-name": "%", "table-name": "%" }, "rule-action": "convert-lowercase", "value": null, "old-value": null }, { "rule-type": "selection", "rule-id": "566111704", "rule-name": "566111704", "object-locator": { "schema-name": "dbo", "table-name": "%" }, "rule-action": "include", "filters": [] } ] } ``` ### Einschränkungen bei der Verwendung eines PostgreSQL-Zielendpunkts mit Babelfish-Tabellen Bei der Verwendung eines PostgreSQL-Zielendpunkts mit Babelfish-Tabellen gelten folgende Einschränkungen: + Verwenden Sie für den **Zieltabellen-Vorbereitungsmodus** nur die Modi **Nichts unternehmen** oder **Kürzen**. Verwenden Sie nicht den Modus **Tabellen am Ziel ablegen**. In diesem Modus erstellt DMS die Tabellen als PostgreSQL-Tabellen, die sie möglicherweise nicht erkennen. T-SQL + AWS DMS unterstützt den Datentyp sql\_variant nicht. + Babelfish unter dem Postgres-Endpunkt unterstützt keine Datentypen `HIERARCHYID` `GEOMETRY` (vor 3.5.4) und `GEOGRAPHY` (vor 3.5.4). Um diese Datentypen zu migrieren, können Sie Transformationsregeln hinzufügen, um den Datentyp in wstring (250) zu konvertieren. + Babelfish unterstützt nur die Migration der Datentypen `BINARY`, `VARBINARY` und `IMAGE` unter Verwendung des Datentyps `BYTEA`. Für frühere Versionen von Aurora PostgreSQL können Sie DMS verwenden, um diese Tabellen zu einem [Babelfish-Zielendpunkt](CHAP_Target.Babelfish.md) zu migrieren. Sie müssen keine Länge für den Datentyp `BYTEA` angeben, wie im folgenden Beispiel zu sehen. ``` [Picture] [VARBINARY](max) NULL ``` Ändern Sie den vorherigen T-SQL Datentyp in den T-SQL unterstützten `BYTEA` Datentyp. ``` [Picture] BYTEA NULL ``` + Wenn Sie in früheren Versionen von Aurora PostgreSQL Babelfish eine Migrationsaufgabe für die laufende Replikation von SQL Server zu Babelfish unter Verwendung des PostgreSQL-Zielendpunkts erstellen, müssen Sie den Datentyp `SERIAL` allen Tabellen zuweisen, die Spalten `IDENTITY` verwenden. Beginnend mit Aurora PostgreSQL (Version 15). 3/14.8 und höher) und Babelfish (Version 3.2.0 und höher), die Identitätsspalte wird unterstützt und es ist nicht mehr erforderlich, den SERIAL-Datentyp zuzuweisen. Weitere Informationen finden Sie unter [Verwendung von SERIAL](https://docs.aws.amazon.com/dms/latest/sql-server-to-aurora-postgresql-migration-playbook/chap-sql-server-aurora-pg.tsql.sequences..html) im Abschnitt zu Sequenzen und Identität des *Playbooks zur Migration von SQL Server zu Aurora PostgreSQL*. Wenn Sie dann die Tabelle in Babelfish erstellen, ändern Sie die Spaltendefinition der folgenden Angabe. ``` [IDCol] [INT] IDENTITY(1,1) NOT NULL PRIMARY KEY ``` Ändern Sie die vorherige Angabe in Folgendes. ``` [IDCol] SERIAL PRIMARY KEY ``` Babelfish-compatible Aurora PostgreSQL erstellt eine Sequenz unter Verwendung der Standardkonfiguration und fügt der Spalte eine Einschränkung hinzu. `NOT NULL` Die neu erstellte Sequenz verhält sich wie eine reguläre Sequenz (um 1 erhöht) und enthält keine zusammengesetzte Option `SERIAL`. + Nachdem Sie Daten mit Tabellen migriert haben, die `IDENTITY` Spalten oder den `SERIAL` Datentyp verwenden, setzen Sie das PostgreSQL-based Sequenzobjekt auf der Grundlage des Maximalwerts für die Spalte zurück. Nachdem Sie die Tabellen vollständig geladen haben, verwenden Sie die folgende T-SQL Abfrage, um Anweisungen zum Seeding des zugehörigen Sequenzobjekts zu generieren. ``` DECLARE @schema_prefix NVARCHAR(200) = '' IF current_setting('babelfishpg_tsql.migration_mode') = 'multi-db' SET @schema_prefix = db_name() + '_' SELECT 'SELECT setval(pg_get_serial_sequence(''' + @schema_prefix + schema_name(tables.schema_id) + '.' + tables.name + ''', ''' + columns.name + ''') ,(select max(' + columns.name + ') from ' + schema_name(tables.schema_id) + '.' + tables.name + '));' FROM sys.tables tables JOIN sys.columns columns ON tables.object_id = columns.object_id WHERE columns.is_identity = 1 UNION ALL SELECT 'SELECT setval(pg_get_serial_sequence(''' + @schema_prefix + table_schema + '.' + table_name + ''', ''' + column_name + '''),(select max(' + column_name + ') from ' + table_schema + '.' + table_name + '));' FROM information_schema.columns WHERE column_default LIKE 'nextval(%'; ``` Die Abfrage generiert eine Reihe von SELECT-Anweisungen, die Sie ausführen, um die maximalen IDENTITY- und SERIAL-Werte zu aktualisieren. + Bei Babelfish-Versionen vor 3.2 kann **Vollständiger LOB-Modus** zu einem Tabellenfehler führen. Erstellen Sie in diesem Fall eine separate Aufgabe für die Tabellen, die nicht geladen werden konnten. Verwenden Sie dann **Limitierter LOB-Modus**, um den entsprechenden Wert für **Maximale LOB-Größe (KB)** anzugeben. Eine weitere Option besteht darin, für das SQL-Server-Endpunkt-Verbindungsattribut die Einstellung `ForceFullLob=True` festzulegen. + Bei Babelfish-Versionen vor 3.2 wird bei der Datenvalidierung mit Babelfish-Tabellen, die keine auf Ganzzahlen basierenden Primärschlüssel verwenden, eine Meldung generiert, dass kein geeigneter eindeutiger Schlüssel gefunden werden kann. Beginnend mit Aurora PostgreSQL (Version 15). 3/14.8 und höher) und Babelfish (Version 3.2.0 und höher), die Datenvalidierung für Primärschlüssel ohne Ganzzahl wird unterstützt. + Aufgrund von Genauigkeitsunterschieden bei der Anzahl der Dezimalstellen für Sekunden meldet DMS Datenvalidierungsfehler für Babelfish-Tabellen, die Datentypen `DATETIME` verwenden. Um diese Fehler zu unterdrücken, können Sie den folgenden Validierungsregeltyp für Datentypen `DATETIME` hinzufügen. ``` { "rule-type": "validation", "rule-id": "3", "rule-name": "3", "rule-target": "column", "object-locator": { "schema-name": "dbo", "table-name": "%", "column-name": "%", "data-type": "datetime" }, "rule-action": "override-validation-function", "source-function": "case when ${column-name} is NULL then NULL else 0 end", "target-function": "case when ${column-name} is NULL then NULL else 0 end" } ```