Arbeiten mit SQL Postgre-Funktionen, die von Amazon RDS für Postgre unterstützt werden SQL

Amazon RDS for Postgre SQL unterstützt viele der gängigsten Postgre-FunktionenSQL. Postgre SQL verfügt beispielsweise über eine Autovacuum-Funktion, die routinemäßige Wartungsarbeiten an der Datenbank durchführt. Die Autovakuierungsfunktion ist standardmäßig aktiviert. Obwohl Sie diese Funktion deaktivieren können, empfehlen wir dringend, sie eingeschaltet zu lassen. Diese Funktion zu verstehen und zu verstehen, was Sie tun können, um sicherzustellen, dass sie ordnungsgemäß funktioniert, ist für jeden eine grundlegende Aufgabe. DBA Weitere Informationen zur Selbstbereinigung finden Sie unter Arbeiten mit dem SQL Postgre-Autovakuum auf Amazon RDS für Postgre SQL. Um mehr über andere allgemeine DBA Aufgaben zu erfahren,Häufige DBA-Aufgaben für Amazon RDS for PostgreSQL.

RDSfor Postgre unterstützt SQL auch Erweiterungen, die der DB-Instance wichtige Funktionen hinzufügen. Sie können beispielsweise die GIS Post-Erweiterung verwenden, um mit räumlichen Daten zu arbeiten, oder die Erweiterung pg_cron verwenden, um Wartungsarbeiten innerhalb der Instanz zu planen. Weitere Hinweise zu Postgre-Erweiterungen finden Sie unter. SQL Verwenden von SQL Postgre-Erweiterungen mit Amazon RDS for Postgre SQL

Foreign Data Wrapper sind ein spezieller Erweiterungstyp, mit dem Ihre RDS for SQL Postgre-DB-Instance mit anderen kommerziellen Datenbanken oder Datentypen funktioniert. Weitere Hinweise zu Fremddaten-Wrappern, die von RDS for Postgre unterstützt werden, finden Sie unter. SQL Arbeiten mit den unterstützten Foreign Data Wrappern für RDS SQL

Im Folgenden finden Sie Informationen zu einigen anderen Funktionen, die von RDS for Postgre unterstützt werden. SQL

Benutzerdefinierte Datentypen und Aufzählungen mit for Postgre RDS SQL

Postgre SQL unterstützt das Erstellen benutzerdefinierter Datentypen und das Arbeiten mit Aufzählungen. Weitere Informationen zum Erstellen von und Arbeiten mit Aufzählungen und anderen Datentypen finden Sie in der Postgre-Dokumentation unter Aufzählungstypen. SQL

Im Folgenden finden Sie ein Beispiel für das Erstellen eines Typs als Aufzählung und das anschließende Einfügen von Werten in eine Tabelle.

CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple');
CREATE TYPE
CREATE TABLE t1 (colors rainbow);
CREATE TABLE
INSERT INTO t1 VALUES ('red'), ( 'orange');
INSERT 0 2
SELECT * from t1;
colors
--------
red
orange
(2 rows)
postgres=> ALTER TYPE rainbow RENAME VALUE 'red' TO 'crimson';
ALTER TYPE
postgres=> SELECT * from t1;
colors
---------
crimson
orange
(2 rows)

Ereignisauslöser für Postgre RDS SQL

Alle aktuellen SQL Postgre-Versionen unterstützen Ereignisauslöser, ebenso wie alle verfügbaren Versionen von RDS for Postgre. SQL Sie können das Hauptbenutzerkonto nutzen (Standard, postgres), um Ereignisauslöser zu erstellen, zu ändern, umzubenennen und zu löschen. Ereignisauslöser befinden sich auf DB-Instance-Level und können so auf alle Datenbanken einer Instance angewendet werden.

Der folgende Code erstellt beispielsweise einen Event-Trigger, der den aktuellen Benutzer am Ende jedes Data Definition Language (DDL) -Befehls ausgibt.

CREATE OR REPLACE FUNCTION raise_notice_func()
    RETURNS event_trigger
    LANGUAGE plpgsql AS
$$
BEGIN
    RAISE NOTICE 'In trigger function: %', current_user;
END;
$$;

CREATE EVENT TRIGGER event_trigger_1 
    ON ddl_command_end
EXECUTE PROCEDURE raise_notice_func();

Weitere Informationen zu SQL Postgre-Ereignisauslösern finden Sie unter Ereignisauslöser in der Postgre-Dokumentation. SQL

Es gibt mehrere Einschränkungen bei der Verwendung von SQL Postgre-Event-Triggern bei AmazonRDS. Diese umfassen u. a. folgende:

• Auf Read Replicas können keine Ereignisauslöser erstellt werden. Sie können jedoch Ereignisauslöser auf einer Read Replica-Quelle erstellen. Die Ereignisauslöser werden dann in die Read Replica kopiert. Die Ereignisauslöser auf der Read Replica werden nicht bei Änderungen, die von der Quelle ausgehen, ausgelöst. Wenn jedoch die Read Replica verwendet wird, werden die vorhandenen Ereignisauslöser bei Datenbank-Operationen ausgelöst.

• Um ein Hauptversions-Upgrade für eine SQL Postgre-DB-Instance durchzuführen, die Ereignisauslöser verwendet, stellen Sie sicher, dass Sie die Ereignisauslöser löschen, bevor Sie die Instance aktualisieren.

Riesige Seiten RDS für Postgre SQL

Huge Pages ist eine Arbeitsspeicher-Verwaltungsfunktion, die den Overhead reduziert, wenn eine DB-Instance mit großen, zusammenhängenden Arbeitsspeicherblöcken arbeitet, wie sie von gemeinsam genutzten Puffern verwendet werden. Diese SQL Postgre-Funktion wird von allen derzeit RDS für SQL Postgre verfügbaren Versionen unterstützt. Sie können große Seiten für Ihre Anwendung zuordnen, indem Sie Aufrufe des freigegebenen Speichers mmap oder SYSV verwenden. RDSfor Postgre SQL unterstützt sowohl Seitengrößen von 4 KB als auch 2 MB.

Sie können Huge Pages ein- oder ausschalten, indem Sie den Wert des huge_pages-Parameters ändern. Die Funktion ist standardmäßig für alle DB-Instance-Klassen aktiviert, außer Micro, Small und Medium.

RDSfor Postgre SQL verwendet riesige Seiten, die auf dem verfügbaren gemeinsamen Speicher basieren. Wenn die DB-Instance aufgrund von Einschränkungen des gemeinsamen Speichers keine riesigen Seiten verwenden kann, RDS verhindert Amazon den Start der DB-Instance. In diesem Fall RDS setzt Amazon den Status der DB-Instance auf einen Status mit inkompatiblen Parametern. In diesem Fall können Sie den huge_pages Parameter auf setzen, off damit Amazon RDS die DB-Instance starten kann.

Der Parameter shared_buffers ist wichtig für die Einstellung des gemeinsam genutzten Speicherpools, der für die Verwendung von großen Seiten erforderlich ist. Der Standardwert für den shared_buffers-Parameter verwendet ein Makro für Datenbankparameter. Dieses Makro legt einen Prozentsatz der insgesamt verfügbaren 8 KB an Seiten fest, die für den Speicher der DB-Instance verfügbar sind, verfügbar. Wenn Sie riesige Seiten verwenden, werden diese Seiten in den riesigen Seiten zusammengefasst zugeordnet. Amazon RDS versetzt eine DB-Instance in einen Zustand mit inkompatiblen Parametern, wenn die Shared-Memory-Parameter so eingestellt sind, dass sie mehr als 90 Prozent des DB-Instance-Speichers beanspruchen.

Weitere Informationen zur SQL Postgre-Speicherverwaltung finden Sie unter Ressourcenverbrauch in der Postgre-Dokumentation. SQL

Durchführen einer logischen Replikation für Amazon RDS for Postgre SQL

Ab Version 10.4 SQL unterstützt RDS for Postgre die Veröffentlichungs- und SQL Abonnement-Syntax, die in Postgre 10 eingeführt wurde. SQL Weitere Informationen finden Sie unter Logische Replikation in der Postgre-Dokumentation. SQL

Anmerkung

Neben der systemeigenen Funktion zur SQL logischen Replikation von Postgre, die in Postgre SQL 10 eingeführt wurde, unterstützt RDS for Postgre SQL auch die Erweiterung. pglogical Weitere Informationen finden Sie unter Verwenden von pglogical, um Daten zwischen Instances zu synchronisieren.

Im Folgenden finden Sie Informationen zum Einrichten der logischen Replikation RDS für eine SQL Postgre-DB-Instance.

Themen

• Verständnis der logischen Replikation und logischen Decodierung
• Arbeiten mit logischen Replikations-Slots

Verständnis der logischen Replikation und logischen Decodierung

RDSfor Postgre SQL unterstützt das Streaming von Write-Ahead-Log (WAL) -Änderungen mithilfe der logischen Replikationssteckplätze von SQL Postgre. Es unterstützt auch die Verwendung logischer Decodierung. Sie können logische Replikations-Slots in Ihrer Instance einrichten und über diese Slots Datenbankänderungen auf einen Client wie z. B. streame pg_recvlogical. Sie erstellen logische Replikationsslots auf Datenbankebene, die Replikationsverbindungen zu einer einzelnen Datenbank unterstützen.

Die gängigsten Clients für die SQL logische Postgre-Replikation sind AWS Database Migration Service ein individuell verwalteter Host auf einer EC2 Amazon-Instance. Der logische Replikations-Slot enthält keine Informationen über den Empfänger des Streams. Es gibt auch keine Anforderung, dass das Ziel eine Replikatdatenbank sein muss. Wenn beim Einrichten eines Slots für die logische Replikation nicht vom Slot gelesen wird, können Daten in den Speicher Ihrer DB-Instance geschrieben werden und diesen schnell füllen.

Sie aktivieren die SQL logische Postgre-Replikation und logische Dekodierung für Amazon RDS mit einem Parameter, einem Replikationsverbindungstyp und einer Sicherheitsrolle. Der Client für die logische Dekodierung kann jeder Client sein, der eine Replikationsverbindung zu einer Datenbank auf einer SQL Postgre-DB-Instance herstellen kann.

Um die logische Dekodierung für eine Postgre-DB-Instance RDS zu aktivieren SQL

1. Stellen Sie sicher, dass das Benutzerkonto, das Sie verwenden, folgende Rollen hat:

   • Die rds_superuser-Rolle, damit Sie die logische Replikation aktivieren können

   • Die rds_replication-Rolle erteilt Berechtigungen zur Verwaltung von logischen Slots und zum Streamen von Daten mithilfe von logischen Slots

2. Setzen Sie den statischen Parameter rds.logical_replication auf 1. Setzen Sie bei der Anwendung dieses Parameters auch die Parameter wal_level, max_wal_senders, max_replication_slots und max_connections fest. Diese Parameteränderungen können die WAL Generierung erhöhen. Legen Sie den rds.logical_replication Parameter daher nur fest, wenn Sie logische Steckplätze verwenden.

3. Starten Sie die DB-Instance neu, damit der statische Parameter rds.logical_replication in Kraft tritt.

4. Erstellen Sie einen logischen Replikationsslot wie im nächsten Abschnitt erläutert. Für diesen Prozess ist es erforderlich, dass Sie ein Decodier-Plugin angeben. Derzeit SQL unterstützt RDS for Postgre die im Lieferumfang von Postgre enthaltenen Ausgabe-Plugins test_decoding und wal2json. SQL

Weitere Informationen zur logischen Postgre-Dekodierung finden Sie in der Postgre-Dokumentation. SQL SQL

Arbeiten mit logischen Replikations-Slots

Sie können SQL Befehle verwenden, um mit logischen Steckplätzen zu arbeiten. Mit dem folgenden Befehl wird beispielsweise ein logischer Slot erstellt, der test_slot mithilfe des SQL Standard-Postgre-Ausgabe-Plug-ins test_decoding benannt wird.

SELECT * FROM pg_create_logical_replication_slot('test_slot', 'test_decoding');
slot_name    | xlog_position
-----------------+---------------
regression_slot | 0/16B1970
(1 row)

Mit dem folgenden Befehl können Sie die logischen Slots auflisten.

SELECT * FROM pg_replication_slots;

Mit dem folgenden Befehl können Sie einen logischen Slot entfernen.

SELECT pg_drop_replication_slot('test_slot');
pg_drop_replication_slot
-----------------------
(1 row)

Weitere Beispiele für die Arbeit mit logischen Replikationssteckplätzen finden Sie in der SQL Postgre-Dokumentation unter Beispiele für logische Dekodierung.

Sobald Sie den logischen Replikationsslot erstellt haben, können Sie mit dem Streaming beginnen. Das folgende Beispiel zeigt, wie die logische Decodierung über das Streaming-Replikationsprotokoll gesteuert wird. In diesem Beispiel wird das Programm pg_recvlogical verwendet, das in der Postgre-Distribution enthalten ist. SQL Dazu muss die Client-Authentifizierung so eingerichtet sein, dass Replikationsverbindungen zugelassen werden.

pg_recvlogical -d postgres --slot test_slot -U postgres
    --host -instance-name.111122223333.aws-region.rds.amazonaws.com 
    -f -  --start

Fragen Sie die Funktion pg_replication_origin_status ab, um den Inhalt der pg_show_replication_origin_status Ansicht anzuzeigen.

SELECT * FROM pg_show_replication_origin_status();
local_id | external_id | remote_lsn | local_lsn
----------+-------------+------------+-----------
(0 rows)

RAMFestplatte für das stats_temp_directory

Sie können den SQL Parameter RDS for Postgre verwenden, rds.pg_stat_ramdisk_size um den Systemspeicher anzugeben, der einer RAM Festplatte zum Speichern von Postgre zugewiesen ist. SQL stats_temp_directory Der RAM Festplattenparameter ist nur in RDS SQL Postgre-Version 14 und niedrigeren Versionen verfügbar.

Bei bestimmten Workloads kann durch die Einstellung dieses Parameters die Leistung verbessert und die I/O-Anforderungen können gesenkt werden. Weitere Informationen zu finden Sie in der stats_temp_directory Postgre-Dokumentation. SQL .

Um eine RAM Festplatte für Ihre einzurichtenstats_temp_directory, setzen Sie den rds.pg_stat_ramdisk_size Parameter auf einen ganzzahligen Literalwert in der Parametergruppe, die von Ihrer DB-Instance verwendet wird. Dieser Parameter wird in MB angegeben, daher müssen Sie einen ganzzahligen Wert verwenden. Ausdrücke, Formeln und Funktionen sind für den Parameter rds.pg_stat_ramdisk_size nicht gültig. Starten Sie die DB-Instance neu, damit die Änderung wirksam wird. Weitere Informationen zum Festlegen von Parametern finden Sie unter Parametergruppen für Amazon RDS.

Mit dem folgenden AWS CLI Befehl wird beispielsweise der RAM Festplattenparameter auf 256 MB festgelegt.

aws rds modify-db-parameter-group \
    --db-parameter-group-name pg-95-ramdisk-testing \
    --parameters "ParameterName=rds.pg_stat_ramdisk_size, ParameterValue=256, ApplyMethod=pending-reboot"

Nach dem Neustart führen Sie den folgenden Befehl aus, um den Status des stats_temp_directory anzuzeigen:

postgres=> SHOW stats_temp_directory;

Der Befehl sollte Folgendes zurückgeben.

stats_temp_directory
---------------------------
/rdsdbramdisk/pg_stat_tmp
(1 row)

Tablespaces für Postgre RDS SQL

RDSfür Postgre SQL unterstützt Tablespaces aus Kompatibilitätsgründen. Da sich der gesamte Speicher auf einem einzigen logischen Volume befindet, können Sie keine Tablespaces für I/O-Splitting oder -Isolierung verwenden. Unsere Benchmarks und Erfahrung zeigen, dass ein einzelnes logisches Volume für die meisten Anwendungsfälle das beste Setup ist.

Um Tablespaces mit Ihrer RDS for Postgre-DB-Instance zu erstellen und zu verwenden, ist die Rolle erforderlichSQL. rds_superuser Das Hauptbenutzerkonto Ihrer RDS for SQL Postgre-DB-Instance (Standardnamepostgres) ist Mitglied dieser Rolle. Weitere Informationen finden Sie unter SQLPostgre-Rollen und -Berechtigungen verstehen.

Wenn Sie beim Erstellen eines Tablespace einen Dateinamen angeben, lautet das Pfadpräfix /rdsdbdata/db/base/tablespace. Im folgenden Beispiel werden Tablespace-Dateien in abgeleg /rdsdbdata/db/base/tablespace/data. In diesem Beispiel wird angenommen, dass ein dbadmin-Benutzer (Rolle) existiert und ihm die rds_superuser-Rolle gewährt wurde, die zur Arbeit mit Tablespaces benötigt wird.

postgres=> CREATE TABLESPACE act_data
  OWNER dbadmin
  LOCATION '/data';
CREATE TABLESPACE

Weitere Informationen zu Postgre-Tablespaces finden Sie unter SQL Tablespaces in der Postgre-Dokumentation. SQL

RDSfür Postgre-Kollationen für und andere Mainframe-Migrationen SQL EBCDIC

RDSZu den SQL Postgre-Versionen 10 und höher gehört ICU Version 6.0.2, die auf Unicode 10.0 basiert und Kollationen aus dem Unicode Common Locale Data Repository 32 enthält. CLDR Diese Software-Internationalisierungsbibliotheken stellen sicher, dass Zeichenkodierungen unabhängig vom Betriebssystem oder der Plattform einheitlich dargestellt werden. Weitere Informationen zu Unicode CLDR -32 finden Sie in den Versionshinweisen zu Version CLDR 32 auf der Unicode-Website. CLDR Weitere Informationen zu den Internationalisierungskomponenten für Unicode (ICU) finden Sie auf der Website des ICUTechnical Committee (ICU-TC). Informationen zu ICU -60 finden Sie unter Download 60. ICU

Ab Version 14.3 enthält RDS für Postgre SQL auch Kollationen, die bei der Datenintegration und Konvertierung aus basierten Systemen helfen. EBCDIC Der erweiterte binärkodierte dezimale Austauschcode oder die EBCDICCodierung wird häufig von Mainframe-Betriebssystemen verwendet. Diese von Amazon RDS bereitgestellten Sortierungen sind eng definiert, sodass nur die Unicode-Zeichen sortiert werden, die direkt Codepages zugeordnet sind. EBCDIC Die Zeichen werden in der Reihenfolge der EBCDIC Codepunkte sortiert, um eine Datenvalidierung nach der Konvertierung zu ermöglichen. Diese Sortierungen enthalten weder denormalisierte Formen noch Unicode-Zeichen, die nicht direkt einem Zeichen auf der Quellcodepage zugeordnet sind. EBCDIC

Die Zeichenzuordnungen zwischen EBCDIC Codepages und Unicode-Codepunkten basieren auf Tabellen, die von veröffentlicht wurden. IBM Der komplette Satz steht IBM als komprimierte Datei zum Herunterladen zur Verfügung. RDSfor Postgre SQL verwendete diese Zuordnungen mit den von ihnen bereitgestellten Tools, ICU um die in den Tabellen in diesem Abschnitt aufgeführten Sortierungen zu erstellen. Die Sortierungsnamen enthalten eine Sprache und ein Land, wie es von der verlangt wird. ICU In EBCDIC Codepages werden jedoch keine Sprachen angegeben, und einige EBCDIC Codepages decken mehrere Länder ab. Das bedeutet, dass der Sprach- und Länderteil der Sortierungsnamen in der Tabelle willkürlich sind und nicht mit dem aktuellen Gebietsschema übereinstimmen müssen. Mit anderen Worten, die Codepage-Nummer ist der wichtigste Teil des Sortierungsnamens in dieser Tabelle. Sie können jede der in den folgenden Tabellen aufgelisteten Sortierungen in einer beliebigen RDS for Postgre-Datenbank verwenden. SQL

• Unicode to EBCDIC collations table— Einige Mainframe-Datenmigrationstools verwenden LATIN1 oder intern, um Daten zu kodieren und LATIN9 zu verarbeiten. Solche Tools verwenden Roundtrip-Schemata, um die Datenintegrität zu wahren und die umgekehrte Konvertierung zu unterstützen. Die Sortierungen in dieser Tabelle können von Tools verwendet werden, die Daten mithilfe von LATIN1 Kodierung verarbeiten, was keine besondere Behandlung erfordert.

• Unicode to LATIN9 collations table— Sie können diese Kollationen in jeder beliebigen Datenbank RDS für SQL Postgre verwenden.

In der folgenden Tabelle finden Sie Kollationen, die RDS für Postgre verfügbar sind und Codepages SQL EBCDIC Unicode-Codepunkten zuordnen. Es wird empfohlen, die Sortierungen in dieser Tabelle für die Anwendungsentwicklung zu verwenden, für die eine Sortierung auf der Grundlage der Reihenfolge der IBM Codepages erforderlich ist.

Name der Postgre-Sortierung SQL	Beschreibung der Code-Page-Zuordnung und Sortierreihenfolge
DA-DK-CP277-x-Intensivstation	Unicode-Zeichen, die direkt der IBM EBCDIC Codepage 277 (gemäß den Konvertierungstabellen) zugeordnet sind, werden in der Reihenfolge der IBM CP 277-Codepunkte sortiert
de-DE-cp273-x-icu	Unicode-Zeichen, die direkt der IBM EBCDIC Codepage 273 (gemäß den Konvertierungstabellen) zugeordnet sind, werden in der Reihenfolge der IBM CP 273-Codepunkte sortiert
en-GB-cp285-x-icu	Unicode-Zeichen, die direkt der IBM EBCDIC Codepage 285 (gemäß den Konvertierungstabellen) zugeordnet sind, werden in der Reihenfolge der IBM CP 285-Codepunkte sortiert
en-US-cp037-x-icu	Unicode-Zeichen, die direkt der IBM EBCDIC Codepage 037 (gemäß den Konvertierungstabellen) zugeordnet sind, werden in der Reihenfolge der IBM CP 37-Codepunkte sortiert
es-ES-cp284-x-icu	Unicode-Zeichen, die direkt der IBM EBCDIC Codepage 284 (gemäß den Konvertierungstabellen) zugeordnet sind, werden in der Reihenfolge der IBM CP 284-Codepunkte sortiert
fi-FI-cp278-x-icu	Unicode-Zeichen, die direkt der IBM EBCDIC Codepage 278 (gemäß den Konvertierungstabellen) zugeordnet sind, werden in der Reihenfolge der IBM CP 278-Codepunkte sortiert
fr-FR-cp297-x-icu	Unicode-Zeichen, die direkt der IBM EBCDIC Codepage 297 (gemäß den Konvertierungstabellen) zugeordnet sind, werden in der Reihenfolge der IBM CP 297-Codepunkte sortiert
it-IT-cp280-x-icu	Unicode-Zeichen, die direkt der IBM EBCDIC Codepage 280 (gemäß den Konvertierungstabellen) zugeordnet sind, werden in der Reihenfolge der IBM CP 280-Codepunkte sortiert
nl-BE-cp500-x-icu	Unicode-Zeichen, die direkt der IBM EBCDIC Codepage 500 (gemäß den Konvertierungstabellen) zugeordnet sind, werden in der Reihenfolge der IBM CP 500-Codepunkte sortiert

Amazon RDS bietet eine Reihe zusätzlicher Sortierungen, die Unicode-Codepunkte, die LATIN9 Zeichen anhand der von veröffentlichten Tabellen zugeordnet sindIBM, in der Reihenfolge der ursprünglichen Codepunkte gemäß der EBCDIC Codepage der Quelldaten sortieren.

Name der Postgre-Sortierung SQL	Beschreibung der Code-Page-Zuordnung und Sortierreihenfolge
DA-DK-CP1142 m-x-icu	Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC Codepage 1142 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der CP-1142-Codepunkte sortiert IBM
DE-DE-CP1141 m-x-icu	Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC Codepage 1141 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der CP-1141-Codepunkte IBM sortiert
de-GB-CP1146 m-x-icu	Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC Codepage 1146 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der CP-1146-Codepunkte sortiert IBM
en-US-CP1140 m-x-icu	Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC Codepage 1140 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in IBM der Reihenfolge der CP 1140-Codepunkte sortiert
es-ES-CP1145 m-x-icu	Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC Codepage 1145 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der CP-1145-Codepunkte IBM sortiert
fi-FI-CP1143 m-x-icu	Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC Codepage 1143 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der CP-1143-Codepunkte sortiert IBM
fr-FR-CP1147 m-x-icu	Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC Codepage 1147 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der CP-1147-Codepunkte sortiert IBM
it-IT-CP1144 m-x-icu	Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC Codepage 1144 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der CP-1144-Codepunkte IBM sortiert
nl-BE-CP1148 m-x-icu	Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC Codepage 1148 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der CP-1148-Codepunkte sortiert IBM

Im Folgenden finden Sie ein Beispiel für die Verwendung einer RDS for SQL Postgre-Kollatierung.

db1=> SELECT pg_import_system_collations('pg_catalog');
 pg_import_system_collations
-----------------------------
                          36
db1=> SELECT '¤' < 'a' col1;
 col1
------
 t  
db1=> SELECT '¤' < 'a' COLLATE "da-DK-cp277-x-icu" col1;
 col1
------
 f

Es wird empfohlen, die Sortierungen in den Unicode to EBCDIC collations table und in der für die Anwendungsentwicklung zu verwenden, Unicode to LATIN9 collations table für die eine Sortierung auf der Grundlage der Reihenfolge der IBM Codepages erforderlich ist. Die folgenden Sortierungen (mit dem Suffix „b“) sind auch in sichtbarpg_collation, sind aber für die Verwendung durch Mainframe-Datenintegrations- und Migrationstools vorgesehen. Sie ordnen Codepages bestimmten Codepunktverschiebungen zu und erfordern eine besondere Behandlung bei AWS der Sortierung. Mit anderen Worten: Die folgenden Sortierungen werden nicht empfohlen.

• DA-DK-277 b-x-icu

• DA-DK-1142 b-x-icu

• DE-DE-CP273 b-x-icu

• DE-DE-CP1141 b-x-icu

• de-GB-CP1146 b-x-icu

• de-GB-CP285 b-x-icu

• de-US-CP037 b-x-icu

• de-US-CP1140 b-x-icu

• es-ES-CP1145 b-x-icu

• Es-ES-CP284 b-x-icu

• fi-FI-CP1143 b-x-icu

• fr-FR-CP1147 b-x-icu

• fr-FR-CP297 b-x-icu

• it-IT-CP1144 b-x-icu

• it-IT-CP280 b-x-icu

• NL-BE-CP1148 b-x-icu

• NL-BE-CP500 b-x-icu

Weitere Informationen zur Migration von Anwendungen aus Mainframe-Umgebungen zu finden Sie unter Was ist Mainframe-Modernisierung AWS? AWS .

Weitere Informationen zur Verwaltung von Kollationen in Postgre SQL finden Sie unter Collation Support in der Postgre-Dokumentation. SQL