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. # Verwendung einer PostgreSQL-Datenbank als Ziel für AWS Database Migration Service Sie können Daten zu PostgreSQL-Datenbanken migrieren AWS DMS, indem Sie entweder eine andere PostgreSQL-Datenbank oder eine der anderen unterstützten Datenbanken verwenden. Hinweise zu Versionen von PostgreSQL, die als Ziel AWS DMS unterstützen, 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 [Using Amazon Aurora Serverless v2](https://docs.aws.amazon.com//AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html) im *Amazon Aurora 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 verfolgt einen table-by-table Ansatz bei der Migration von Daten von der Quelle zum Ziel in der Volllastphase. 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 Vollladephase 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 nach PostgreSQL eine Spalte in Oracle ein NULL-Zeichen (Hexadezimalwert U\$10000) enthält, wird das NULL-Zeichen in ein Leerzeichen AWS DMS umgewandelt (Hexadezimalwert U\$10020). 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 zur Zieldatenbank. ## Einschränkungen bei der Verwendung von Amazon Aurora PostgreSQL Limitless als Ziel für AWS Database Migration Service Die folgenden Einschränkungen gelten, wenn Sie Amazon Aurora PostgreSQL Limitless als Ziel verwenden für: AWS DMS + AWS DMS Data Validation 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 dem offiziellen Konvertierungsleitfaden 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 durchzuführen. Weitere Informationen finden Sie in den folgenden Beispielen. ``` 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 oder mithilfe des `create-endpoint` Befehls in der mit der [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)`--postgre-sql-settings '{"EndpointSetting": "value", ...}'`JSON-Syntax erstellen. Sie geben dies 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. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/dms/latest/userguide/CHAP_Target.PostgreSQL.html) ## Zieldatentypen für PostgreSQL Der PostgreSQL-Datenbankendpunkt für AWS DMS unterstützt die meisten PostgreSQL-Datenbankdatentypen. Die folgende Tabelle zeigt die Zieldatentypen der PostgreSQL-Datenbank, die bei der Verwendung unterstützt werden, AWS DMS und die Standardzuordnung von AWS DMS Datentypen. 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** AWS DMS Erstellt bei der Replikation aus einer PostgreSQL-Quelle die Zieltabelle mit den gleichen Datentypen für alle Spalten, 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. Mithilfe von Babelfish versteht Aurora PostgreSQL T-SQL, 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 nennen Sie die Datenbank babelfish\$1db.** Fügen Sie im Abschnitt **Endpunkteinstellungen** Einstellungen hinzu, um für `DatabaseMode` `Babelfish`und für `BabelfishDatabaseName` den Namen der Babelfish-T-SQL-Zieldatenbank festzulegen. ### Hinzufügen von Transformationsregeln zu Ihrer Migrationsaufgabe Wenn Sie eine Migrationsaufgabe für ein Babelfish-Ziel definieren, müssen Sie Transformationsregeln einbeziehen, 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 von Tabellen, die Sie mit T-SQL erstellen, in Kleinbuchstaben im PostgreSQL-Katalog `pg_class`. Wenn Sie jedoch über SQL-Server-Tabellen mit Namen in Groß- und Kleinschreibung verfügen, erstellt DMS die Tabellen unter Verwendung von systemeigenen PostgreSQL-Datentypen anstelle der T-SQL-kompatiblen Datentypen. 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. Achten Sie darauf, das SQL-Server-Schema so umzubenennen, dass der Name den Namen der T-SQL-Datenbank beinhaltet. Wenn der ursprüngliche SQL Server-Schemaname beispielsweise dbo lautet und Ihr T-SQL-Datenbankname mydb lautet, benennen Sie das Schema mithilfe einer Transformationsregel in mydb\$1dbo um. **Anmerkung** Wenn Sie Babelfish für Aurora PostgreSQL 16 oder höher verwenden, ist der Standard-Migrationsmodus „Mutidatabase“. Achten Sie bei der Ausführung von 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 haben eine one-to-one Zuordnung zur T-SQL-Zieldatenbank in Babelfish. 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 T-SQL möglicherweise nicht erkennt. + AWS DMS unterstützt den Datentyp sql\$1variant nicht. + Babelfish unter dem Postgres-Endpunkt unterstützt keine Datentypen `HEIRARCHYID` `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 von T-SQL unterstützten Datentyp `BYTEA`. ``` [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. Ab Aurora PostgreSQL (Version 15.3/14.8 und höher) und Babelfish (Version 3.2.0 und höher) wird die Identitätsspalte unterstützt und es ist nicht mehr erforderlich, den Datentyp SERIAL 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 ``` Das Babelfish-kompatible Aurora PostgreSQL erstellt eine Sequenz mit der Standardkonfiguration und fügt der Spalte eine Einschränkung `NOT NULL` hinzu. 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 Spalten `IDENTITY` oder den Datentyp `SERIAL` verwenden, setzen Sie das PostgreSQL-basierte Sequenzobjekt auf der Grundlage des Maximalwerts für die Spalte zurück. Wenn die Tabellen vollständig geladen sind, verwenden Sie die folgende T-SQL-Abfrage, um Anweisungen zu generieren, um das zugehörige Sequenzobjekt zu setzen. ``` 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. Ab Aurora PostgreSQL (Version 15.3/14.8 und höher) und Babelfish (Version 3.2.0 und höher) wird die Datenvalidierung für nicht ganzzahlige Primärschlüssel 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" } ```