Regeln und Operationen für Tabellen- und Sammlungseinstellungen - AWS Database Migration Service
Platzhalter in TabelleneinstellungenVerwendung des parallelen Ladens für ausgewählte Tabellen und AnsichtenAngeben von LOB-Einstellungen für eine ausgewählte Tabelle oder AnsichtBeispiele für Tabelleneinstellungen

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.

Regeln und Operationen für Tabellen- und Sammlungseinstellungen

Mit den Tabelleneinstellungen können Sie alle Einstellungen angeben, die Sie auf die ausgewählte Tabelle oder Ansicht für eine bestimmte Operation anwenden möchten. Regeln für Tabelleneinstellungen sind optional, je nach Endpunkt- und Migrationsanforderungen.

Anstelle des Konzepts von Tabellen und Ansichten speichern MongoDB- und Amazon-DocumentDB-Datenbanken Datensätze als Dokumente, die in Sammlungen zusammengefasst werden. Eine einzelne Datenbank für einen MongoDB- oder Amazon-DocumentDB-Endpunkt ist ein bestimmter Satz von Sammlungen, die durch den Datenbanknamen identifiziert werden.

Bei der Migration von einer MongoDB- oder Amazon-DocumentDB-Quelle arbeiten Sie etwas anders mit den Einstellungen für paralleles Laden. In diesem Fall sollten Sie den Typ „Autosegmentierung“ oder „Bereichssegmentierung“ der Einstellungen für paralleles Laden für ausgewählte Sammlungen und nicht für Tabellen und Ansichten in Betracht ziehen.

Für Termersetzungsregeln, die den Tabelleneinstellungsregeltyp geändert haben, können Sie die folgenden Parameter verwenden.

Parameter Mögliche Werte Beschreibung
rule-type table-settings Ein Wert, der die Regel auf die von der Auswahlregel festgelegte Tabelle, Ansicht oder Sammlung anwendet.
rule-id Ein numerischer Wert. Ein eindeutiger numerischer Wert zur Identifizierung der Regel.
rule-name Ein alphanumerischer Wert. Ein eindeutiger Name zur Identifizierung der Regel.
object-locator Ein Objekt mit den folgenden Parametern:

  • schema-name – Der Name des Schemas. Für MongoDB- und Amazon-DocumentDB-Endpunkte ist dies der Name der Datenbank, die eine Reihe von Sammlungen enthält.

  • table-name – Der Name der Tabelle, Ansicht oder Sammlung.

Der Name eines bestimmten Schemas und einer bestimmten Tabelle oder Ansicht oder der Name einer bestimmten Datenbank und Sammlung (keine Platzhalter).
parallel-load Ein Objekt mit den folgenden Parametern:

  • type – Gibt an, ob paralleles Laden aktiviert ist.

    Wenn dies der Fall ist, gibt dieser Parameter auch den Mechanismus zur Identifizierung der Tabellen- oder Ansichtspartitionen, Unterpartitionen oder andere Segmente, die parallel geladen werden, an. Partitionen sind Segmente, die bereits definiert und in der Quelltabelle oder -ansicht nach Name identifiziert sind.

    Für MongoDB- und Amazon DocumentDB DocumentDB-Endpoints sind Partitionen Segmente. AWS DMS kann diese automatisch angegebenen zugehörigen Autosegmentierungsparameter berechnen. Oder Sie können diese manuell mithilfe von Bereichssegmentierungsparametern angeben.

    Nur für Oracle-Endpunkte sind Unterpartitionen eine zusätzliche Ebene von Segmenten, die in der Quelltabelle oder -ansicht bereits definiert und nach Name identifiziert sind. Sie können andere Segmente in der table-settings-Regel identifizieren, indem Sie Grenzen für den Bereich der Werte für eine oder mehrere Tabellen- oder Ansichtsspalten angeben.

  • partitions – Wenn type partitions-list ist, gibt dieser Wert alle parallel zu ladenden Partitionen an.

  • subpartitions – Nur für Oracle-Endpunkte gilt: Wenn type partitions-list ist, gibt dieser Wert alle parallel zu ladenden Unterpartitionen an.

  • columns – Wenn type ranges ist, gibt dieser Wert die Namen der Spalten an, die für die Identifizierung bereichsbasierter und parallel zu ladender Segmente verwendet werden.

  • boundaries – Wenn type ranges ist, gibt dieser Wert die Werte der columns an, die für die Identifizierung bereichsbasierter und parallel zu ladender Segmente verwendet werden.

Ein Wert, der eine parallele (Multithread-) Ladeoperation auf der von der Option object-locator identifizierten Tabelle oder Ansicht angibt. In diesem Fall können Sie parallel geladen werden. Verwenden Sie dabei eine der folgenden Methoden:

  • Nach Segmenten, angegeben durch alle verfügbaren Partitionen oder Unterpartitionen.

  • Nach ausgewählten Partitionen und Unterpartitionen.

  • Per Autosegmentierung oder nach von Ihnen angegebenen bereichsbasierten Segmenten.

Weitere Informationen zum parallelen Laden finden Sie unter Verwendung des parallelen Ladens für ausgewählte Tabellen und Ansichten.

type Es gilt eine der folgenden Situationen für parallel-load:

  • partitions-auto – Alle Partitionen der Tabelle oder Ansicht werden parallel geladen. Jede Partition wird in ihrem eigenen Thread zugeordnet.

    Dies ist eine erforderliche Einstellung für MongoDB- und Amazon-DocumentDB-Quellendpunkte, um die Autosegmentierungsoption einer parallelen Volllast zu verwenden.

  • subpartitions-auto – (nur Oracle-Endpunkte) Alle Unterpartitionen der Tabelle oder Ansicht werden parallel geladen. Jede Unterpartition wird einem eigenen Thread zugeordnet.

  • partitions-list – Alle angegebenen Partitionen der Tabelle oder Ansicht werden parallel geladen. Nur für Oracle-Endpunkte: Alle angegebenen Unterpartitionen der Tabelle oder Ansicht werden parallel geladen. Jede Partition und Unterpartition, die Sie angeben, wird einem eigenen Thread zugeordnet. Sie identifizieren die parallel zu ladenden Partitionen und Unterpartitionen anhand der Partitionsnamen (partitions) und Unterpartitionsnamen (subpartitions).

  • ranges – Alle bereichsspezifischen Segmente der Tabelle, Ansicht oder Sammlung werden parallel geladen. Jedes Tabellen-, Ansichts- oder Sammlungssegment, das Sie identifizieren, wird seinem eigenen Thread zugeordnet. Sie geben diese Segmente nach Spaltennamen (columns) und Spaltenwerten (boundaries) an.

    PostgreSQL-Endpunkte unterstützen nur diese Art paralleler Ladevorgänge. MongoDB und Amazon DocumentDB als Quellendpunkte unterstützen sowohl diesen Bereichssegmentierungstyp als auch den Autosegmentierungstyp einer parallelen Volllast (partitions-auto).

  • none – Die Tabelle, Ansicht oder Sammlung wird unabhängig von ihren Partitionen oder Unterpartitionen in einer Single-Thread-Aufgabe (Standard) geladen. Weitere Informationen finden Sie unter Erstellen einer Aufgabe.

 Der Mechanismus zum Identifizieren der Tabellen-, Ansichts- oder Sammlungspartitionen, Unterpartitionen oder Segmente, die parallel geladen werden.
number-of-partitions (Optional) Wenn type für bestimmte Sammlungen eines MongoDB- oder Amazon-Endpunkts partitions-auto ist, gibt dieser Parameter die Gesamtzahl der Partitionen (Segmente) an, die für die Migration verwendet werden. Der Standardwert ist 16. Gibt die Namen der Partitionen an, die parallel geladen werden.
collection-count-from-metadata (Optional) Wenn type gilt partitions-auto für bestimmte Sammlungen eines MongoDB- oder Amazon DocumentDB DocumentDB-Endpunkts und dieser Parameter auf gesetzt isttrue, AWS DMS verwendet eine geschätzte Sammlungsanzahl, um die Anzahl der Partitionen zu bestimmen. Wenn dieser Parameter auf gesetzt istfalse, wird die tatsächliche AWS DMS Anzahl der Sammlungen verwendet. Der Standardwert ist true. Gibt an, ob eine geschätzte Sammlungsanzahl oder die tatsächliche Sammlungsanzahl verwendet werden soll, um die Anzahl der Partitionen zu berechnen, die parallel geladen werden sollen.
max-records-skip-per-page (Optional) Wenn type für bestimmte Sammlungen eines MongoDB- oder Amazon-DocumentDB-Endpunkts partitions-auto ist, ist dies Anzahl der Datensätze, die bei der Ermittlung der Grenzen für jede Partition gleichzeitig übersprungen werden sollen. AWS DMS verwendet einen Ansatz zum seitenweisen Überspringen, um die Mindestgrenze für eine Partition zu bestimmen. Der Standardwert ist 10 000. Gibt die Anzahl der Datensätze an, die bei der Festlegung der Grenzen für jede Partition gleichzeitig übersprungen werden sollen. Das Festlegen eines relativ großen Werts vom Standard aus kann zu Cursor-Timeouts und Aufgabenfehlern führen. Das Festlegen eines relativ niedrigen Werts vom Standard aus führt zu mehr Operationen pro Seite und zu einem langsameren vollständigen Laden.
batch-size (Optional) Wenn type für bestimmte Sammlungen eines MongoDB- oder Amazon-Endpunkts partitions-auto ist, begrenzt dieser Ganzzahlwert die Anzahl der Dokumente, die in einem Round-Trip-Stapel zurückgegeben werden. Wenn die Stapelgröße Null (0) ist, verwendet der Cursor die vom Server definierte maximale Stapelgröße. Der Standardwert ist 0. Gibt die maximale Anzahl von Dokumenten an, die in einem Stapel zurückgegeben werden. Für jeden Stapel ist ein Roundtrip zum Server erforderlich.
partitions Wenn type partitions-list ist, handelt es sich um ein Array von Zeichenfolgen, die die Namen der parallel zu ladenden Partitionen angeben. Die Namen der Partitionen, die parallel geladen werden.
subpartitions (Nur Oracle-Endpunkte) Wenn type partitions-list ist, handelt es sich um ein Array von Zeichenfolgen, die die Namen der parallel zu ladenden Unterpartitionen angeben. Die Namen der Unterpartitionen, die parallel geladen werden.
columns Wenn type ranges ist, handelt es sich um ein Array von Zeichenfolgen, die die Ansicht der bereichsbasierten Tabellen-, Ansichts- oder Sammlungssegmente identifiziert, die parallel geladen werden sollen. Die Namen der Spalten, die bereichsbasierte Tabellen-, Ansichts- oder Sammlungssegmente angeben, die parallel geladen werden sollen.
boundaries Wenn type ranges ist, handelt es sich um ein Array mit Spalte-Wert-Arrays. Jedes Spalte-Wert-Array enthält Spaltenwerte in der von columns angegebenen Menge und Reihenfolge. Ein Spalte-Wert-Array gibt die obere Grenze eines Tabellen-, Ansichts- oder Sammlungssegments an. Jedes zusätzliche Spalte-Wert-Array fügt die obere Grenze für ein zusätzliches Tabellen-, Ansichts- oder Sammlungssegment hinzu. Alle derartigen bereichsbasierten Tabellen-, Ansichts- oder Sammlungssegmente werden parallel geladen. Spaltenwerte, die bereichsbasierte Tabellen-, Ansichts- oder Sammlungspartitionen identifizieren, die parallel geladen werden sollen.
lob-settings Ein Objekt mit den folgenden Parametern:

  • mode – Gibt den Migrationsbearbeitungs-Modus für LOBs an.

  • bulk-max-size – Gibt die maximale Größe der LOBs abhängig von der mode-Einstellung an.

 Ein Wert, der die LOB-Verarbeitung für die von der Option object-locator identifizierte Tabelle oder Ansicht angibt. Die angegebene LOB-Verarbeitung überschreibt alle Aufgaben-LOB-Einstellungen nur für diese Tabelle oder Ansicht. Weitere Informationen zum Verwendung der LOB-Einstellungsparameter finden Sie unter Angeben von LOB-Einstellungen für eine ausgewählte Tabelle oder Ansicht.
mode

Gibt die Migrationsverarbeitung für LOBs in der angegebenen Tabelle oder Ansicht unter Verwendung der folgenden Werte an:

  • limited – (Standard) Dieser Wert legt die Migration auf den eingeschränkten LOB-Modus fest, wobei alle LOBs gemeinsam mit allen anderen Spaltendatentypen in der Tabelle oder Ansicht migriert werden. Verwenden Sie diesen Wert, wenn Sie zumeist kleine LOBs (100 MB oder weniger) replizieren. Geben Sie außerdem einen bulk-max-size-Wert an (Null ist ungültig). Alle migrierten LOBs über bulk-max-size abgeschnitten, um der von Ihnen eingestellten Größe zu entsprechen.

  • unlimited – Dieser Wert legt die Migration auf den vollständigen LOB-Modus fest. Verwenden Sie diesen Wert, wenn alle oder die meisten LOBs, die Sie replizieren möchten, größer als 1 GB sind. Wenn Sie den bulk-max-size-Wert Null angeben, werden alle LOBs im Standard-LOB-Modus (vollständig) migriert. In dieser Form des unlimited-Modus werden alle LOBs getrennt von anderen Spaltendatentypen mithilfe einer Suche aus der Quelltabelle oder -ansicht migriert. Wenn Sie einen bulk-max-size-Wert größer als Null festlegen, werden alle LOBs im Kombinations-LOB-Modus (vollständig) migriert. In dieser Form des unlimited-Modus werden LOBs über bulk-max-size unter Verwendung einer Quelltabellen- oder Quellansichtssuche migriert, ähnlich wie im Standard-LOB-Modus (vollständig). Andernfalls werden LOBs bis einschließlich dieser Größe inline migriert, ähnlich dem einschränkten LOB-Modus. Kein LOB wird im unlimited-Modus abgeschnitten, unabhängig von der Form, die Sie verwenden.

  • none – Alle Tabellen oder Ansichten-LOBs werden entsprechend den LOB-Einstellungen der Aufgabe migriert.

    Weitere Informationen über die LOB-Einstellungen für Aufgaben finden Sie unter Ziel-Metadaten-Aufgabeneinstellungen.

    Weitere Informationen zur Migration von LOBs und der Angabe dieser LOB-Einstellungen für Aufgaben finden Sie unter Einstellung der LOB Unterstützung für Quelldatenbanken in einer AWS DMS Aufgabe.

Der Mechanismus zum Migrieren von LOBs.
bulk-max-size Der Effekt dieses Werts hängt vom mode ab. Die maximale Größe von LOBs in Kilobyte-Schritten. Geben Sie diese Option nur an, wenn Sie kleine LOBs replizieren müssen oder wenn der Zielendpunkt keine unbegrenzte LOB-Größe unterstützt.

Platzhalter in Tabelleneinstellungen sind eingeschränkt

Die Verwendung des Prozent-Platzhalters ("%") in-"table-settings" Regeln wird für Quelldatenbanken nicht unterstützt, wie im Folgenden dargestellt.

{
    "rule-type": "table-settings",
    "rule-id": "8",
    "rule-name": "8",
    "object-locator": {
        "schema-name": "ipipeline-prod",            
        "table-name": "%"
    },
    "parallel-load": {
        "type": "partitions-auto",
        "number-of-partitions": 16,
        "collection-count-from-metadata": "true",
        "max-records-skip-per-page": 1000000,
        "batch-size": 50000
    }
  }

Wenn Sie "%" in den "table-settings" Regeln wie in der Abbildung gezeigt verwenden, wird die folgende Ausnahme AWS DMS zurückgegeben.

Error in mapping rules. Rule with ruleId = x failed validation. Exact 
schema and table name required when using table settings rule.

AWS Empfiehlt außerdem, nicht mit einer einzigen Aufgabe eine große Anzahl großer Sammlungen zu ladenparallel-load. Beachten Sie, dass von AWS DMS der Ressourcenkonflikt sowie die Anzahl der parallel geladenen Segmente um den Wert des Parameters MaxFullLoadSubTasks für die Aufgabeneinstellungen begrenzt wird, wobei der Höchstwert 49 beträgt.

Geben Sie stattdessen alle Sammlungen für Ihre Quelldatenbank für die größten Sammlungen an, indem Sie sie "schema-name" und "table-name" einzeln angeben. Skalieren Sie Ihre Migration außerdem korrekt. Führen Sie beispielsweise mehrere Aufgaben auf einer ausreichenden Anzahl von Replikations-Instances aus, um eine große Anzahl großer Sammlungen in Ihrer Datenbank zu verwalten.

Verwendung des parallelen Ladens für ausgewählte Tabellen und Ansichten

Um die Migration zu beschleunigen und effizienter zu gestalten, können Sie für ausgewählte Tabellen, Ansichten und Sammlungen die parallele Ladung verwenden. Mit anderen Worten: Sie können eine einzelne segmentierte Tabelle, Ansicht oder Sammlung mit mehreren Threads parallel migrieren. Zu diesem Zweck AWS DMS teilt eine Vollladeaufgabe in Threads auf, wobei jedes Tabellensegment einem eigenen Thread zugewiesen wird.

Mit diesem parallelen Ladevorgang können mehrere Threads mehrere Tabellen, Ansichten und Sammlungen vom Quellendpunkt entladen. Anschließend können Sie mehrere Threads migrieren und die gleichen Tabellen, Ansichten und Sammlungen parallel auf den Zielendpunkt laden. Bei einigen Datenbank-Engines können Sie die Tabellen und Ansichten nach vorhandenen Partitionen oder Unterpartitionen aufteilen. Für andere Datenbank-Engines können Sie Sammlungen AWS DMS automatisch nach bestimmten Parametern segmentieren lassen (Autosegmentierung). Andernfalls können Sie jede Tabelle, Ansicht oder Sammlung nach den von Ihnen angegebenen Spaltenwertbereichen segmentieren.

Paralleles Laden wird für die folgenden Quellendpunkte unterstützt:

  • Oracle

  • Microsoft SQL Server

  • MySQL

  • PostgreSQL

  • IBM Db2 (LUW)

  • SAP Adaptive Server Enterprise (ASE)

  • MongoDB (unterstützt nur die Optionen Autosegmentierung und Bereichssegmentierung einer parallelen Volllast)

  • Amazon DocumentDB (unterstützt nur die Optionen Autosegmentierung und Bereichssegmentierung einer parallel Volllast)

AWS DMS Unterstützt für MongoDB- und Amazon DocumentDB DocumentDB-Endpoints die folgenden Datentypen für Spalten, die Partitionsschlüssel für die Bereichssegmentierungsoption einer parallel Volllast sind.

  • Double

  • String

  • ObjectId

  • 32-Bit-Ganzzahl

  • 64-Bit-Ganzzahl

Das parallele Laden zur Verwendung mit Tabelleneinstellungsregeln wird für die folgenden Zielendpunkte unterstützt:

  • Oracle

  • Microsoft SQL Server

  • MySQL

  • PostgreSQL

  • Amazon S3

  • SAP Adaptive Server Enterprise (ASE)

  • Amazon-Redshift

  • MongoDB (unterstützt nur die Optionen Autosegmentierung und Bereichssegmentierung einer parallelen Volllast)

  • Amazon DocumentDB (unterstützt nur die Optionen Autosegmentierung und Bereichssegmentierung einer parallel Volllast)

  • Db2 LUW

Verwenden Sie die MaxFullLoadSubTasks-Aufgabeneinstellung, um die maximale Anzahl an Tabellen und Ansichten anzugeben, die parallel geladen werden.

Um die maximale Anzahl von Threads pro Tabelle oder Ansicht für die unterstützten Ziele einer Aufgabe zum parallelen Laden anzugeben, definieren Sie mehr Segmente mithilfe von Spaltenwertgrenzen.

Wichtig

MaxFullLoadSubTasks steuert die Anzahl der Tabellen oder Tabellensegmente, die parallel geladen werden sollen. ParallelLoadThreads steuert die Anzahl der Threads, die von einer Migrationsaufgabe verwendet werden, um die Lasten parallel auszuführen. Diese Einstellungen sind multiplikativ. Daher ist die Gesamtzahl der Threads, die während einer Vollast-Aufgabe verwendet werden, ungefähr das Ergebnis des Werts ParallelLoadThreads multipliziert mit dem Wert von MaxFullLoadSubTasks (ParallelLoadThreads * MaxFullLoadSubtasks).

Wenn Sie Aufgaben mit einer hohen Anzahl von Volllast-Unteraufgaben und einer hohen Anzahl von parallelen Lade-Threads erstellen, kann Ihre Aufgabe zu viel Speicher verbrauchen und fehlschlagen.

Um die maximale Anzahl von Threads pro Tabelle für Amazon DynamoDB-, Amazon-Kinesis-Data-Streams-, Apache-Kafka- oder Amazon-Elasticsearch-Ziele anzugeben, verwenden Sie die Zielmetadaten-Aufgabeneinstellung ParallelLoadThreads.

Sie geben die Puffergröße für eine Aufgabe zum parallelen Laden bei Verwendung von ParallelLoadThreads mithilfe der Zielmetadaten-Aufgabeneinstellung ParallelLoadBufferSize an.

Die Verfügbarkeit von ParallelLoadThreads und ParallelLoadBufferSize sowie deren Einstellungen hängen vom Ziel-Endpunkt ab.

Weitere Informationen zu den Einstellungen ParallelLoadThreads und ParallelLoadBufferSize finden Sie unter Ziel-Metadaten-Aufgabeneinstellungen. Weitere Informationen zur MaxFullLoadSubTasks-Einstellung finden Sie unter Aufgabeneinstellungen für vollständiges Laden. Weitere Informationen zu den Zielendpunkten finden Sie unter den entsprechenden Themen.

Wenn Sie paralleles Laden verwenden möchten, können Sie mit der parallel-load-Option eine Tabellenzuweisungsregel des Typs table-settings angeben. In der table-settings-Regel können Sie die Segmentierungskriterien für eine einzelne Tabelle, Ansicht oder Sammlung, die parallel geladen werden soll, angeben. Um dies zu tun, setzen Sie den type-Parameter der parallel-load-Option auf eine der verschiedenen Optionen.

Wie Sie dies tun, hängt davon ab, wie Sie die Tabelle, Ansicht oder Sammlung für das parallele Laden segmentieren möchten.

  • Nach Partitionen (oder Segmenten) – Alle vorhandenen Tabellen- oder Ansichtspartitionen (oder Segmente) werden mithilfe des partitions-auto-Typs geladen. Oder Laden nur ausgewählter Partitionen mithilfe des partitions-list-Typs mit einem angegebenen Partitionen-Array.

    Nur für MongoDB- und Amazon DocumentDB DocumentDB-Endpoints laden Sie alle oder bestimmte Sammlungen nach Segmenten, die AWS DMS automatisch auch unter Verwendung des partitions-auto Typs und zusätzlicher optionaler Parameter berechnet werden. table-settings

  • (Nur Oracle-Endpunkte) Nach Unterpartitionen – Laden alle vorhandenen Tabellen- oder Ansichtsunterpartitionen mithilfe des subpartitions-auto-Typs. Oder Laden nur ausgewählter Unterpartitionen mithilfe des partitions-list-Typs mit einem subpartitions-Array.

  • Nach Segmenten, die Sie definieren – Laden von Ihnen definierter Tabellen-, Ansichts- oder Sammlungssegmente mithilfe von Spalte-Wert-Grenzen. Um dies zu tun, verwenden Sie den ranges-Typ mit angegebenen columns- und boundaries-Arrays.

    Anmerkung

    PostgreSQL-Endpunkte unterstützen nur diese Art paralleler Ladevorgänge. MongoDB und Amazon DocumentDB als Quellendpunkte unterstützen sowohl diesen Bereichssegmentierungstyp als auch den Autosegmentierungstyp einer parallelen Volllast (partitions-auto).

Um weitere Tabellen, Ansichten oder Sammlungen zum parallelen Laden zu identifizieren, geben Sie zusätzliche table-settings-Objekte mit parallel-load-Optionen an.

Die folgenden Verfahren beschreiben das Codieren von JSON für jeden parallelen Ladetyp, vom einfachsten zum kompliziertesten.

So geben Sie alle Tabellen-, Ansichts- oder Sammlungspartitionen oder alle Tabellen- oder Ansichts-Unterpartitionen an

  • Geben Sie parallel-load entweder mit dem partitions-auto-Typ oder dem subpartitions-auto-Typ an (aber nicht mit beiden).

    Jede Tabellen-, Ansichts- oder Sammlungspartition oder -unterpartition wird dann automatisch einem eigenen Thread zugeordnet.

    Bei manchen Endpunkten beinhaltet das parallele Laden nur dann Partitionen oder Unterpartitionen nur, wenn sie bereits für die Tabelle oder Ansicht definiert sind. Für MongoDB- und Amazon DocumentDB DocumentDB-Quellendpunkte können Sie die Partitionen (oder Segmente) anhand optionaler zusätzlicher Parameter AWS DMS automatisch berechnen lassen. Dies sind beispielsweise number-of-partitions, collection-count-from-metadata, max-records-skip-per-page und batch-size.

So geben Sie ausgewählte Tabellen- oder Ansichtspartitionen, -unterpartitionen oder beides an:

  1. Geben Sie parallel-load mit dem partitions-list-Typ an.

  2. (Optional) Fügen Sie Partitionen ein, indem Sie ein Array von Partitionsnamen als den Wert für partitions angeben.

    Jede angegebene Partition wird dann einem eigenen Thread zugeordnet.

    Wichtig

    Stellen Sie bei Oracle-Endpunkten sicher, dass sich Partitionen und Unterpartitionen nicht überlappen, wenn Sie sie für das parallele Laden auswählen. Wenn Sie überlappende Partitionen und Unterpartitionen verwenden, um Daten parallel zu laden, werden Einträge dupliziert oder der Vorgang schlägt aufgrund einer Verletzung der Primärschlüssel-Duplikat-Regel fehl.

  3. (Optional, nur für Oracle-Endpunkte) Fügen Sie Unterpartitionen ein, indem Sie ein Array von Unterpartitionsnamen als den Wert für subpartitions angeben.

    Jede angegebene Unterpartition wird dann einem eigenen Thread zugeordnet.

    Anmerkung

    Paralleles Laden enthält Partitionen oder Unterpartitionen nur, wenn sie bereits für die Tabelle oder Ansicht definiert sind.

Sie können Tabellen- oder Ansichtssegmente als Bereiche von Spaltenwerten angeben. Wenn Sie dies tun, achten Sie auf diese Spalteneigenschaften:

  • Die Angabe indizierter Spalten verbessert die Leistung erheblich.

  • Sie können bis zu 10 Spalten angeben.

  • Sie können keine Spalten verwenden, um Segmentgrenzen mit den folgenden AWS DMS Datentypen zu definieren: DOUBLE, FLOAT, BLOB, CLOB und NCLOB

  • Datensätze mit Nullwerten werden nicht repliziert.

So geben Sie Tabellen-, Ansichts- oder Sammlungssegmente als Bereiche von Spaltenwerten an

  1. Geben Sie parallel-load mit dem ranges-Typ an.

  2. Definieren Sie eine Begrenzung zwischen Tabellen- oder Ansichtssegmenten, indem Sie ein Array von Tabellenspaltennamen als den Wert für columns angeben. Wiederholen Sie diese Schritte für jede Spalte, für die Sie eine Begrenzung zwischen Tabellen- oder Ansichtssegmenten definieren möchten.

    Beachten Sie, dass die Reihenfolge der Spalten von Bedeutung ist. Dabei ist die erste Spalte bei der Definition jeder Begrenzung am wichtigsten und die letzte Spalte ist am unwichtigsten. Einzelheiten dazu finden Sie in den folgenden Schritten und Abschnitten.

  3. Definieren Sie die Datenbereiche für alle Tabellen- oder Ansichtssegmente durch Angabe eines Begrenzungsarrays als Wert für boundaries. Bei einem Begrenzungsarray handelt es sich um ein Array mit Spalte-Wert-Arrays. Führen Sie dazu die folgenden Schritte aus:

    1. Geben Sie jedes Element eines Spalte-Wert-Arrays als Wert an, der jeder Spalte entspricht. Dabei stellt jedes Spalte-Wert-Array die obere Grenze für jedes Tabellen- oder Ansichtssegment dar, das Sie definieren möchten: Geben Sie jede Spalte in der gleichen Reihenfolge an, in der Sie diese Spalte in dem columns-Array angegeben haben.

      Geben Sie Werte für DATE-Spalten in dem von der Quelle unterstützten Format an.

    2. Geben Sie jedes Array mit Spaltenwerten der Reihe nach als obere Grenze für jedes Segment vom unteren zum Segment der Tabelle oder Ansicht an. next-to-top Wenn Zeilen oberhalb der von Ihnen angegebenen oberen Grenze vorhanden sind, stellend diese Zeilen die oberen Segment der Tabelle oder Ansicht dar. Damit ist die Anzahl der bereichsbasierten Segmente potentiell eins höher, als die Anzahl der Segmentgrenzen im Grenz-Array. Jedes dieser bereichsbasierten Segmente wird einem eigenen Thread zugeordnet.

      Alle Tabellendaten, die nicht Null sind, werden repliziert. Dies gilt auch, wenn Sie nicht für alle Spalten in der Tabelle oder Ansicht Datenbereiche definieren.

    Beispiel: Sie definieren drei Spalte-Wert-Arrays für die Spalten, COL1, COL2 und COL3 wie folgt.

    COL1 COL2 COL3
    10 30 105
    20 20 120
    100 12 99

    Sie haben drei Segmentgrenzen für einen möglichen Gesamtwert von vier Segmenten definiert.

    Um die Bereiche der für jedes Segment zu replizierenden Zeilen zu identifizieren, wendet die Replikations-Instance einen Suchalgorithmus auf diese drei Spalten für jedes der vier Segmente an. Die Suche sieht wie folgt aus:

    Segment 1

    Replizieren Sie alle Zeilen, in denen Folgendes zutrifft: Die ersten Werte mit zwei Spalten sind kleiner oder gleich den entsprechenden Werten für die Obergrenze für Segment 1. Außerdem sind die Werte der dritten Spalte kleiner als der Wert der Obergrenze für Segment 1 .

    Segment 2

    Replizieren Sie alle Zeilen (außer Segment 1-Zeilen), wobei Folgendes zutrifft: Die ersten Werte mit zwei Spalten sind kleiner oder gleich den entsprechenden Werten für die Obergrenze für Segment 2. Außerdem sind die Werte der dritten Spalte kleiner als der Wert der Obergrenze für Segment 2 .

    Segment 3

    Replizieren Sie alle Zeilen (außer Segment 2-Zeilen), wobei Folgendes zutrifft: Die ersten Werte mit zwei Spalten sind kleiner oder gleich den entsprechenden Werten für die Obergrenze für Segment 3. Außerdem sind die Werte der dritten Spalte kleiner als der Wert für den oberen Grenzwert für Segment 3 .

    Segment 4

    Replizieren Sie alle verbleibenden Zeilen (außer den Zeilen Segment 1, 2 und 3).

    In diesem Fall erstellt die Replikations-Instance wie folgt eine WHERE-Klausel zum Laden jedes Segment:

    Segment 1

    ((COL1 < 10) OR ((COL1 = 10) AND (COL2 < 30)) OR ((COL1 = 10) AND (COL2 = 30) AND (COL3 < 105)))

    Segment 2

    NOT ((COL1 < 10) OR ((COL1 = 10) AND (COL2 < 30)) OR ((COL1 = 10) AND (COL2 = 30) AND (COL3 < 105))) AND ((COL1 < 20) OR ((COL1 = 20) AND (COL2 < 20)) OR ((COL1 = 20) AND (COL2 = 20) AND (COL3 < 120)))

    Segment 3

    NOT ((COL1 < 20) OR ((COL1 = 20) AND (COL2 < 20)) OR ((COL1 = 20) AND (COL2 = 20) AND (COL3 < 120))) AND ((COL1 < 100) OR ((COL1 = 100) AND (COL2 < 12)) OR ((COL1 = 100) AND (COL2 = 12) AND (COL3 < 99)))

    Segment 4

    NOT ((COL1 < 100) OR ((COL1 = 100) AND (COL2 < 12)) OR ((COL1 = 100) AND (COL2 = 12) AND (COL3 < 99)))

Angeben von LOB-Einstellungen für eine ausgewählte Tabelle oder Ansicht

Sie können die LOB-Aufgabeneinstellungen für eine oder mehrere Tabellen einrichten, indem Sie eine Tabellenzuordnungsregel des Typs table-settings mit der lob-settings-Option für ein oder mehrere table-settings-Objekte erstellen.

Das Angeben von LOB-Einstellungen für ausgewählte Tabellen oder Ansichten wird für die folgenden Quell-Endpunkte unterstützt:

  • Oracle

  • Microsoft SQL Server

  • MySQL

  • PostgreSQL

  • IBM Db2, abhängig von den mode- und bulk-max-size-Einstellungen, wie im Folgenden beschrieben

  • SAP Adaptive Server Enterprise (ASE), abhängig von den mode-und bulk-max-size-Einstellungen, wie im Folgenden beschrieben

Das Angeben von LOB-Einstellungen für ausgewählte Tabellen oder Ansichten wird für die folgenden Zielendpunkte unterstützt:

  • Oracle

  • Microsoft SQL Server

  • MySQL

  • PostgreSQL

  • SAP ASE, je nach den mode- und bulk-max-size-Einstellungen, wie im Folgenden beschrieben

Anmerkung

Sie können LOB-Datentypen nur mit Tabellen und Ansichten verwenden, die einen Primärschlüssel enthalten.

Wenn Sie LOB-Einstellungen für eine ausgewählte Tabelle oder Ansicht verwenden möchten, erstellen Sie eine Tabellenzuweisungsregel des Typs table-settings mit der lob-settings-Option. Damit wird die LOB-Behandlung für die Tabelle oder Ansicht angegeben, die von der object-locator-Option identifiziert wird. In der table-settings-Regel können Sie mit den folgenden Parametern ein lob-settings-Objekt angeben:

  • mode – Gibt den Mechanismus für die Behandlung der LOB-Migration für die ausgewählte Tabelle oder Ansicht wie folgt an:

    • limited – Der eingeschränkte LOB-Standardmodus ist der schnellste und effizienteste Modus. Verwenden Sie diesen Modus nur dann, wenn alle Ihre LOBs klein (unter 100 MB) sind oder der Ziel-Endpunkt keine unbegrenzte LOB-Größe unterstützt. Weiterhin gilt: Wenn Sie limited verwenden, müssen alle LOBs in dem Größenbereich liegen, den Sie für bulk-max-size eingerichtet haben.

      In diesem Modus für eine vollständige Ladungsaufgabe migriert die Replikations-Instance alle LOBs inline zusammen mit anderen Spaltendatentypen als Teil des Haupttabellen-oder -ansichtsspeichers. Die Instance kürzt allerdings jedes LOB, das größer als Ihr bulk-max-size-Wert ist, auf die angegebene Größe. Für eine Change Data Capture (CDC)-Ladeaufgabe migriert die Instance alle LOBs mithilfe einer Quelltabellensuche unabhängig von der LOB-Größe als vollständigen LOB-Standardmodus (siehe unten).

      Anmerkung

      Sie können Ansichten nur für Full-Load-Aufgaben migrieren.

    • unlimited – Der Migrationsmechanismus für den vollständigen LOB-Modus hängt von dem Wert ab, den Sie wie folgt für bulk-max-size festgelegt haben:

      • Vollständiger LOB-Standardmodus – Wenn Sie bulk-max-size auf Null festlegen, migriert die Replikations-Instance alle LOBs mithilfe des vollständigen LOB-Standardmodus. Dieser Modus erfordert eine Suche in der Quelltabelle oder -ansicht, um jedes LOB unabhängig von seiner Größe zu migrieren. Dies führt in der Regel zu einer sehr viel langsameren Migration als im eingeschränkten LOB-Modus. Verwenden Sie diesen Modus nur, wenn alle oder die meisten Ihrer LOBs groß sind (1 GB oder größer).

      • Vollständiger LOB-Kombinationsmodus – Wenn Sie bulk-max-size auf einen Wert ungleich Null festlegen, verwendet dieser vollständige LOB-Modus eine Kombination aus eingeschränktem LOB-Modus und vollständigem LOB-Standardmodus. Das heißt, wenn eine LOB-Größe innerhalb Ihres bulk-max-size-Werts liegt, migriert die Instance das LOB inline wie im eingeschränkten LOB-Modus. Wenn die LOB-Größe diesen Wert übersteigt, migriert die Instance das LOB mithilfe einer Quelltabellen- oder Quellansichtssuche wie im vollständigen LOB-Standardmodus. Für eine Change Data Capture (CDC)-Ladeaufgabe migriert die Instance alle LOBs mithilfe einer Quelltabellensuche unabhängig von der LOB-Größe als vollständigen LOB-Standardmodus (siehe unten). Dies geschieht unabhängig von der LOB-Größe.

        Anmerkung

        Sie können Ansichten nur für Full-Load-Aufgaben migrieren.

        Dieser Modus resultiert in einem Kompromiss bei der Migrationsgeschwindigkeit. Sie liegt zwischen dem schnelleren eingeschränkten LOB-Modus und dem langsameren vollständigen LOB-Standardmodus. Verwenden Sie diesen Modus nur bei einer Mischung aus kleinen und großen LOBs, wobei die meisten LOBs klein sind.

        Dieser kombinierte vollständige LOB-Modus ist nur verfügbar für die folgenden Endpunkte:

        • IBM Db2 als Quelle

        • SAP ASE als Quelle oder Ziel

      Unabhängig davon, welchen Mechanismus Sie für den unlimited-Modus angeben, migriert die Instance alle LOBs vollständig und ohne Kürzung.

    • none – Die Replikations-Instance migriert LOBs in der ausgewählten Tabelle oder Ansicht anhand Ihrer LOB-Einstellungen für Aufgaben. Sie können diese Option verwenden, um Migrationsergebnisse mit und ohne LOB-Einstellungen besonders für die ausgewählte Tabelle oder Ansicht zu vergleichen.

    Wenn die angegebene Tabelle oder Ansicht LOBs in die Replikation einschließt, können Sie die BatchApplyEnabled-Aufgabeneinstellung nur bei Verwendung des limited-LOB-Modus auf true setzen.

    In einigen Fällen könnten Sie BatchApplyEnabled auf true und BatchApplyPreserveTransaction auf false setzen. In diesen Fällen setzt die Instance BatchApplyPreserveTransaction auf true, wenn die Tabelle oder Ansicht LOBs besitzt und die Quell- und Ziel-Endpunkte Oracle sind.

  • bulk-max-size – Legen Sie diesen Wert in Kilobyte auf Null oder ungleich Null fest. Dies ist, wie bereits für vorherige Elemente beschrieben, vom mode abhängig. Im limited-Modus müssen Sie für diesen Parameter einen Wert ungleich Null setzen.

    Die Instance konvertiert LOBs in das Binärformat. Aus diesem Grund multiplizieren Sie die Größe der größten LOBs, die Sie replizieren müssen, mit drei. Beispiel: Wenn Ihr größtes LOB 2 MB groß ist, legen Sie bulk-max-size auf 6.000 (6 MB) fest.

Beispiele für Tabelleneinstellungen

Im Folgenden finden Sie einige Beispiele, die die Verwendung der Tabelleneinstellungen illustrieren.

Beispiel Laden einer nach Partitionen segmentierten Tabelle

Im folgenden Beispiel wird eine SALES-Tabelle effizienter in Ihre Quelle geladen, indem basierend auf allen Partitionen sie parallel geladen wird.

{
   "rules": [{
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "%",
                "table-name": "%"
            },
            "rule-action": "include"
        },
        {
            "rule-type": "table-settings",
            "rule-id": "2",
            "rule-name": "2",
            "object-locator": {
                "schema-name": "HR",
                "table-name": "SALES"
            },
            "parallel-load": {
                "type": "partitions-auto"
            }
        }
     ]
}
Beispiel Laden einer nach Unterpartitionen segmentierten Tabelle

Im folgenden Beispiel wird eine SALES-Tabelle effizienter in Ihre Oracle-Quelle geladen, indem sie auf allen Unterpartitionen parallel geladen wird.

{
   "rules": [{
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "%",
                "table-name": "%"
            },
            "rule-action": "include"
        },
        {
            "rule-type": "table-settings",
            "rule-id": "2",
            "rule-name": "2",
            "object-locator": {
                "schema-name": "HR",
                "table-name": "SALES"
            },
            "parallel-load": {
                "type": "subpartitions-auto"
            }
        }
     ]
}
Beispiel Laden einer segmentierten Tabelle entsprechend einer Partitionsliste

Im folgenden Beispiel wird eine SALES-Tabelle in Ihre Quelle geladen, indem sie entsprechend einer bestimmten Partitionsliste parallel geladen wird. Hier werden die angegebenen Partitionen nach Werten benannt, beginnend mit Teilen des englischen Alphabets, z. B. ABCD, EFGH usw. 

{
    "rules": [{
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "%",
                "table-name": "%"
            },
            "rule-action": "include"
        },
        {
            "rule-type": "table-settings",
            "rule-id": "2",
            "rule-name": "2",
            "object-locator": {
                "schema-name": "HR",
                "table-name": "SALES"
            },
            "parallel-load": {
                "type": "partitions-list",
                "partitions": [
                    "ABCD",
                    "EFGH",
                    "IJKL",
                    "MNOP",
                    "QRST",
                    "UVWXYZ"
                ]
            }
        }
    ]
}
Beispiel Laden einer segmentierten Oracle-Tabelle entsprechend einer ausgewählten Liste mit Partitionen und Unterpartitionen

Im folgenden Beispiel wird eine SALES-Tabelle in Ihre Oracle-Quelle geladen, indem sie entsprechend einer ausgewählten Liste mit Partitionen und Unterpartitionen parallel geladen wird. Hier werden die angegebenen Partitionen nach Werten benannt, beginnend mit Teilen des englischen Alphabets, z. B. ABCD, EFGH usw. Die angegebenen Unterpartitionen sind nach mit Zahlen beginnenden Werten benannt, z. B. 01234 und 56789.

{
    "rules": [{
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "%",
                "table-name": "%"
            },
            "rule-action": "include"
        },
        {
            "rule-type": "table-settings",
            "rule-id": "2",
            "rule-name": "2",
            "object-locator": {
                "schema-name": "HR",
                "table-name": "SALES"
            },
            "parallel-load": {
                "type": "partitions-list",
                "partitions": [
                    "ABCD",
                    "EFGH",
                    "IJKL",
                    "MNOP",
                    "QRST",
                    "UVWXYZ"
                ],
                "subpartitions": [
                    "01234",
                    "56789"
                ]
            }
        }
    ]
}
Beispiel Laden einer durch Spaltenwertbereiche segmentierten Tabelle

Im folgenden Beispiel wird eine SALES-Tabelle in Ihre Quelle geladen, indem sie nach den durch Bereich der SALES_NO- und REGION-Spaltenwerte angegebenen Segmente parallel geladen wird.

{
    "rules": [{
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "%",
                "table-name": "%"
            },
            "rule-action": "include"
        },
        {
            "rule-type": "table-settings",
            "rule-id": "2",
            "rule-name": "2",
            "object-locator": {
                "schema-name": "HR",
                "table-name": "SALES"
            },
            "parallel-load": {
                "type": "ranges",
                "columns": [
                    "SALES_NO",
                    "REGION"
                ],
                "boundaries": [
                    [
                        "1000",
                        "NORTH"
                    ],
                    [
                        "3000",
                        "WEST"
                    ]
                ]
            }
        }
    ]
}

Hier werden zwei Spalten für die Segmentbereiche mit den Namen SALES_NO und REGION angegeben. Es werden zwei Grenzen mit den beiden Spaltenwertsätzen ["1000","NORTH"] und ["3000","WEST"] angegeben.

Diese beiden Grenzen identifizieren somit die folgenden drei Tabellensegmente, die parallel geladen werden:

Segment 1

Zeilen mit SALES_NO kleiner oder gleich 1.000 und mit REGION kleiner als "NORTH" sind. Mit anderen Worten: Verkaufszahlen bis zu 1.000 in der EAST-Region.

Segment 2

Andere Zeilen als Segment 1 mit SALES_NO kleiner oder gleich 3.000 und REGION kleiner als "WEST". Mit anderen Worten: Verkaufszahlen zwischen 1.000 und 3.000 in den Regionen „NORTH“ und „SOUTH“.

Segment 3

Alle verbleibenden Zeilen außer Segment 1 und Segment 2. Mit anderen Worten: Verkaufszahlen über 3.000 in der WEST-Region.

Beispiel Laden von zwei Tabellen: Eine segmentiert nach Bereichen, die andere nach Partitionen

Das folgende Beispiel lädt eine SALES-Tabelle parallel nach Segmentgrenzen, die Sie identifizieren. Es lädt außerdem eine ORDERS-Tabelle parallel nach allen ihren Partitionen, wie in früheren Beispielen.

{
    "rules": [{
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "%",
                "table-name": "%"
            },
            "rule-action": "include"
        },
        {
            "rule-type": "table-settings",
            "rule-id": "2",
            "rule-name": "2",
            "object-locator": {
                "schema-name": "HR",
                "table-name": "SALES"
            },
            "parallel-load": {
                "type": "ranges",
                "columns": [
                    "SALES_NO",
                    "REGION"
                ],
                "boundaries": [
                    [
                        "1000",
                        "NORTH"
                    ],
                    [
                        "3000",
                        "WEST"
                    ]
                ]
            }
        },
        {
            "rule-type": "table-settings",
            "rule-id": "3",
            "rule-name": "3",
            "object-locator": {
                "schema-name": "HR",
                "table-name": "ORDERS"
            },
            "parallel-load": {
                "type": "partitions-auto" 
            }
        }
    ]
}
Beispiel Laden einer Tabelle mit LOBs mithilfe des eingeschränkten LOB-Modus

Im folgenden Beispiel wird eine ITEMS-Tabelle, einschließlich LOBs in Ihre Quelle mithilfe des eingeschränkten LOB-Modus (Standard) mit einer maximalen nicht gekürzten Größe von 100 MB geladen. Alle LOBs, die größer als dieser Wert sind, werden auf 100 MB gekürzt. Alle LOBs werden inline mit allen anderen Spaltendatentypen geladenen.

{
   "rules": [{
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "%",
                "table-name": "%"
            },
            "rule-action": "include"
        },
        {
            "rule-type": "table-settings",
            "rule-id": "2",
            "rule-name": "2",
            "object-locator": {
                "schema-name": "INV",
                "table-name": "ITEMS"
            },
            "lob-settings": {
                "bulk-max-size": "100000"
            }
        }
     ]
}
Beispiel Laden einer Tabelle mit LOBs mithilfe des vollständigen LOB-Standardmodus

Im folgenden Beispiel wird eine ITEMS-Tabelle einschließlich aller ihrer LOBs ohne Kürzung in Ihre Quelle geladen. Dies erfolgt über den vollständigen LOB-Standardmodus. Es werden alle LOBs unabhängig ihrer Größe getrennt von anderen Datentypen geladen, die eine Suche für jedes LOB in der Quelltabelle verwenden.

{
   "rules": [{
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "%",
                "table-name": "%"
            },
            "rule-action": "include"
        },
        {
            "rule-type": "table-settings",
            "rule-id": "2",
            "rule-name": "2",
            "object-locator": {
                "schema-name": "INV",
                "table-name": "ITEMS"
            },
            "lob-settings": {
                "mode": "unlimited",
                "bulk-max-size": "0"
            }
        }
     ]
}
Beispiel Laden einer Tabelle mit LOBs mithilfe des vollständigen LOB-Kombinationsmodus

Im folgenden Beispiel wird eine ITEMS-Tabelle einschließlich aller ihrer LOBs ohne Kürzung in Ihrer Quelle geladen. Dies erfolgt über de vollständigen LOB-Kombinationsmodus. Alle LOBs mit einer Maximalgröße von 100 MB werden-zusammen mit anderen Datentypen inline geladen, wie im eingeschränkten LOB-Modus. Alle LOBs mit einer Größe von über 100 MB werden getrennt von anderen Datentypen geladen. Dieser separate Ladevorgang verwendet eine Suche für jedes dieser LOB in der Quelltabelle, wie im standardmäßigen vollständigen LOB-Modus.

{
   "rules": [{
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "%",
                "table-name": "%"
            },
            "rule-action": "include"
        },
        {
            "rule-type": "table-settings",
            "rule-id": "2",
            "rule-name": "2",
            "object-locator": {
                "schema-name": "INV",
                "table-name": "ITEMS"
            },
            "lob-settings": {
                "mode": "unlimited",
                "bulk-max-size": "100000"
            }
        }
     ]
}
Beispiel Laden einer Tabelle mit LOBs über die LOB-Einstellungen für Aufgaben

Im folgenden Beispiel wird eine ITEMS-Tabelle mithilfe der LOB-Einstellungen für Aufgaben einschließlich aller LOBs in Ihre Quelle geladen. Die bulk-max-size-Einstellung von 100 MB wird ignoriert und nur für ein schnelles Zurücksetzen auf den limited- oder unlimited-Modus beibehalten.

{
   "rules": [{
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "%",
                "table-name": "%"
            },
            "rule-action": "include"
        },
        {
            "rule-type": "table-settings",
            "rule-id": "2",
            "rule-name": "2",
            "object-locator": {
                "schema-name": "INV",
                "table-name": "ITEMS"
            },
            "lob-settings": {
                "mode": "none",
                "bulk-max-size": "100000"
            }
        }
     ]
}