Table and collection settings rules and operations - AWS Database Migration Service

Table and collection settings rules and operations

You use table settings to specify any settings that you want to apply to the selected table or view for a specified operation. Table-settings rules are optional.

Note

Instead of the concept of tables and views, MongoDB and DocumentDB databases store data records as documents that are gathered together in collections. So then, when migrating from a MongoDB or DocumentDB source, consider the range segmentation type of parallel load settings for selected collections rather than tables and views.

For table-mapping rules that use the table-settings rule type, you can apply the following parameters.

Parameter Possible values Description
rule-type table-settings A value that applies the rule to a table or view specified by the selection rule.
rule-id A numeric value. A unique numeric value to identify the rule.
rule-name An alphanumeric value. A unique name to identify the rule.
object-locator An object with the following parameters:
  • schema-name – The name of the schema.

  • table-name – The name of the table or view.

The name of a specific schema and table or view (no wildcards).

parallel-load An object with the following parameters:
  • type – Specifies whether parallel loading is enabled. If it is, this parameter also specifies the mechanism to identify the table or view partitions, subpartitions, or other segments to load in parallel. Partitions are segments that are already defined and identified by name in the source table or view. For Oracle endpoints only, subpartitions are an additional level of segments that are already defined and identified by name in the source table or view. You can identify other segments in the table-settings rule by specifying boundaries in the range of values for one or more table or view columns.

  • partitions – When type is partitions-list, this value specifies all the partitions to load in parallel.

  • subpartitions – For Oracle endpoints only, when type is partitions-list this value specifies all the subpartitions to load in parallel.

  • columns – When type is ranges, this value specifies the names of columns used to identify range-based segments to load in parallel.

  • boundaries – When type is ranges, this value specifies the values of the columns used to identify range-based segments to load in parallel.

A value that specifies a parallel load (multithreaded) operation on the table or view identified by the object-locator option. In this case, you can load in parallel in any of these ways:

  • By segments specified by all available partitions or subpartitions.

  • By selected partitions and subpartitions.

  • By range-based segments that you specify.

For more information about parallel load, see Using parallel load for selected tables and views.

type One of the following for parallel-load:
  • partitions-auto – All partitions of the table or view are loaded in parallel. Every partition is allocated to its own thread.

  • subpartitions-auto – (Oracle endpoints only) All subpartitions of the table or view are loaded in parallel. Every subpartition is allocated to its own thread.

  • partitions-list – All specified partitions of the table or view are loaded in parallel. For Oracle endpoints only, all specified subpartitions of the table or view are loaded in parallel. Each partition and subpartition that you specify is allocated to its own thread. You specify the partitions and subpartitions to load in parallel by partition names (partitions) and subpartition names (subpartitions).

  • ranges – All specified segments of the table or view are loaded in parallel. Each table or view segment that you identify is allocated to its own thread. You specify these segments by column names (columns) and column values (boundaries).

    Note

    PostgreSQL, MongoDB, and DocumentDB as a source support only this type of parallel load.

  • none – The table or view is loaded in a single-threaded task (the default), regardless of its partitions or subpartitions. For more information, see Creating a task.

The mechanism to identify the table or view partitions, subpartitions, or segments to load in parallel.
partitions When type is partitions-list, this is an array of strings that specify the names of partitions to load in parallel. The names of partitions to load in parallel.
subpartitions (Oracle endpoints only) When type is partitions-list, this is an array of strings that specifies the names of subpartitions to load in parallel. The names of subpartitions to load in parallel.
columns When type is ranges, an array of strings set to the names of columns that identify range-based table or view segments to load in parallel. The names of columns that identify range-based table or view segments to load in parallel.
boundaries When type is ranges, an array of column-value arrays. Each column-value array contains column values in the quantity and order specified by columns. A column-value array specifies the upper boundary of a table or view segment. Each additional column-value array adds the upper boundary for one additional table or view segment. All such range-based table or view segments load in parallel. Column values that identify range-based table or view partitions to load in parallel.
lob-settings An object with the following parameters:
  • mode – Specifies the migration handling mode for LOBs.

  • bulk-max-size – Specifies the maximum size of LOBs, depending on the mode setting.

A value that specifies LOB handling for the table or view identified by the object-locator option. The specified LOB handling overrides any task LOB settings for this table or view only. For more information about using the LOB settings parameters, see Specifying LOB settings for a selected table or view.
mode Specifies the migration handling for LOBs in the specified table or view using the following values:
  • limited – (Default) This value sets migration to limited LOB mode, with all LOBs migrated inline together with all other column data types in the table or view. Use this value when replicating mostly small LOBs (100 MB or less). Also, specify a bulk-max-size value (zero is invalid). All migrated LOBs greater than bulk-max-size are truncated to the size that you set.

  • unlimited – This value sets migration to full LOB mode. Use this value when all or most of the LOBs that you want to replicate are larger than 1 GB. If you specify a bulk-max-size value of zero, all LOBs are migrated in standard full LOB mode. In this form of unlimited mode, all LOBs are migrated separately from other column data types using a lookup from the source table or view. If you specify a bulk-max-size value greater than zero, all LOBs are migrated in combination full LOB mode. In this form of unlimited mode, LOBs greater than bulk-max-size are migrated using a source table or view lookup, similar to standard full LOB mode. Otherwise, LOBs up to and including this size are migrated inline, similar to limited LOB mode. No LOB is ever truncated in unlimited mode, regardless of the form you use.

  • none – All table or view LOBs are migrated according to the task LOB settings.

    For more information about the task LOB settings, see Target metadata task settings.

    For more information about how to migrate LOBs and how to specify these task LOB settings, see Setting LOB support for source databases in an AWS DMS task.

The mechanism used to migrate LOBs.
bulk-max-size The effect of this value depends on the mode. The maximum size of LOBs in kilobyte increments. Specify this option only if you need to replicate small LOBs or if the target endpoint doesn't support unlimited LOB size.

Using parallel load for selected tables and views

To speed up migration and make it more efficient, you can use parallel load for selected relational tables and views. In other words, you can migrate a single segmented table or view using several threads in parallel. To do this, AWS DMS splits a full-load task into threads, with each table segment allocated to its own thread.

Using this parallel-load process, you can first have multiple threads unload multiple tables and views in parallel from the source endpoint. You can then have multiple threads migrate and load the same tables and views in parallel to the target endpoint. For some database engines, you can segment the tables and views by existing partitions or subpartitions. Otherwise, you can segment any table or view by ranges of column values that you specify.

Parallel load is supported for the following source endpoints:

  • Oracle

  • Microsoft SQL Server

  • MySQL

  • PostgreSQL

  • IBM Db2

  • SAP Adaptive Server Enterprise (ASE)

  • MongoDB (only supports range segmentation option of parallel full load)

  • Amazon DocumentDB (only supports range segmentation option of parallel full load)

For MongoDB and DocumentDB endpoints, AWS DMS supports the following data types for columns as partition keys of range segmentation.

  • Double

  • String

  • ObjectId

  • 32 bit integer

  • 64 bit integer

Parallel load for use with table-setting rules are supported for the following target endpoints:

  • Oracle

  • Microsoft SQL Server

  • MySQL

  • PostgreSQL

  • SAP Adaptive Server Enterprise (ASE)

  • Amazon DocumentDB (only supports range segmentation option of parallel full load)

To specify the maximum number of tables and views to load in parallel, use the MaxFullLoadSubTasks task setting. To specify the maximum number of threads per table or view for a parallel-load task, use the ParallelLoadThreads task setting. To specify the buffer size for a parallel load task, use the ParallelLoadBufferSize task setting. The availability and settings of ParallelLoadThreadsand ParallelLoadBufferSize depend on the target endpoint.

For more information about the ParallelLoadThreads and ParallelLoadBufferSize settings, see Target metadata task settings. For more information about the MaxFullLoadSubTasks setting, see Full-load task settings. For information specific to target endpoints, see the related topics.

To use parallel load, create a table-mapping rule of type table-settings with the parallel-load option. Within the table-settings rule, you can specify the segmentation criteria for a single table or view that you want to load in parallel. To do so, set the type parameter of the parallel-load option to one of several options. How to do this depends on how you want to segment the table or view for parallel load:

  • By partitions – Load all existing table or view partitions using the partitions-auto type. Or load only selected partitions using the partitions-list type with a specified partitions array.

  • (Oracle endpoints only) By subpartitions – Load all existing table or view subpartitions using the subpartitions-auto type. Or load only selected subpartitions using the partitions-list type with a specified subpartitions array.

  • By segments that you define – Load table or view segments that you define by using column-value boundaries. To do so, use the ranges type with specified columns and boundaries arrays.

    Note

    PostgreSQL, MongoDB, and DocumentDB as a source support only this type of parallel load.

To identify additional tables or views to load in parallel, specify additional table-settings objects with parallel-load options.

In the following procedures, you can find out how to code JSON for each parallel-load type, from the simplest to the most complex.

To specify all table or view partitions, or all table or view subpartitions

  • Specify parallel-load with either the partitions-auto type or the subpartitions-auto type (but not both).

    Every table or view partition or subpartition is then automatically allocated to its own thread.

    Note

    Parallel load includes partitions or subpartitions only if they are already defined for the table or view.

To specify selected table or view partitions, subpartitions, or both

  1. Specify parallel-load with the partitions-list type.

  2. (Optional) Include partitions by specifying an array of partition names as the value of partitions.

    Each specified partition is then allocated to its own thread.

  3. (Optional, for Oracle endpoints only) Include subpartitions by specifying an array of subpartition names as the value of subpartitions.

    Each specified subpartition is then allocated to its own thread.

    Note

    Parallel load includes partitions or subpartitions only if they are already defined for the table or view.

You can specify table or view segments as ranges of column values. When you do so, be aware of these column characteristics:

  • Specifying indexed columns significantly improves performance.

  • You can specify up to 10 columns.

  • You can't use columns to define segment boundaries with the following AWS DMS data types: DOUBLE, FLOAT, BLOB, CLOB, and NCLOB

  • Records with null values aren't replicated.

To specify table or view segments as ranges of column values

  1. Specify parallel-load with the ranges type.

  2. Define a boundary between table or view segments by specifying an array of column names as the value of columns. Do this for every column for which you want to define a boundary between table or view segments.

    The order of columns is significant. The first column is the most significant and the last column is least significant in defining each boundary, as described following.

  3. Define the data ranges for all the table or view segments by specifying a boundary array as the value of boundaries. A boundary array is an array of column-value arrays. To do so, take the following steps:

    1. Specify each element of a column-value array as a value that corresponds to each column. A column-value array represents the upper boundary of each table or view segment that you want to define. Specify each column in the same order that you specified that column in the columns array.

      Note

      Enter values for DATE columns in the format supported by the source.

    2. Specify each column-value array as the upper boundary, in order, of each segment from the bottom to the next-to-top segment of the table or view. If any rows exist above the top boundary that you specify, these rows complete the top segment of the table or view. Thus, the number of range-based segments is potentially one more than the number of segment boundaries in the boundary array. Each such range-based segment is allocated to its own thread.

      Note

      All of the non-null data is replicated, even if you don't define data ranges for all of the columns in the table or view.

    For example, suppose you define three column-value arrays for columns COL1, COL2, and COL3 as follows.

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

    You have defined three segment boundaries for a possible total of four segments.

    To identify the ranges of rows to replicate for each segment, the replication instance applies a search to these three columns for each of the four segments. The search is like the following:

    Segment 1

    Replicate all rows where the following is true: The first two-column values are less than or equal to their corresponding Segment 1 upper boundary values. Also, the values of the third column are less than its Segment 1 upper boundary value.

    Segment 2

    Replicate all rows (except Segment 1 rows) where the following is true: The first two-column values are less than or equal to their corresponding Segment 2 upper boundary values. Also, the values of the third column are less than its Segment 2 upper boundary value.

    Segment 3

    Replicate all rows (except Segment 2 rows) where the following is true: The first two-column values are less than or equal to their corresponding Segment 3 upper boundary values. Also, the values of the third column are less than its Segment 3 upper boundary value.

    Segment 4

    Replicate all remaining rows (except the Segment 1, 2, and 3 rows).

    In this case, the replication instance creates a WHERE clause to load each segment as follows:

    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)))

Specifying LOB settings for a selected table or view

You can set task LOB settings for one or more tables by creating a table-mapping rule of type table-settings with the lob-settings option for one or more table-settings objects.

Specifying LOB settings for selected tables or views is supported for the following source endpoints:

  • Oracle

  • Microsoft SQL Server

  • MySQL

  • PostgreSQL

  • IBM Db2, depending on the mode and bulk-max-size settings, described following

  • SAP Adaptive Server Enterprise (ASE), depending on the mode and bulk-max-size settings, as described following

Specifying LOB settings for selected tables or views is supported for the following target endpoints:

  • Oracle

  • Microsoft SQL Server

  • MySQL

  • PostgreSQL

  • SAP ASE, depending on the mode and bulk-max-size settings, as described following

Note

You can use LOB data types only with tables and views that include a primary key.

To use LOB settings for a selected table or view, you create a table-mapping rule of type table-settings with the lob-settings option. Doing this specifies LOB handling for the table or view identified by the object-locator option. Within the table-settings rule, you can specify a lob-settings object with the following parameters:

  • mode – Specifies the mechanism for handling LOB migration for the selected table or view as follows:

    • limited – The default limited LOB mode is the fastest and most efficient mode. Use this mode only if all of your LOBs are small (within 100 MB in size) or the target endpoint doesn't support an unlimited LOB size. Also if you use limited, all LOBs need to be within the size that you set for bulk-max-size.

      In this mode for a full load task, the replication instance migrates all LOBs inline together with other column data types as part of main table or view storage. However, the instance truncates any migrated LOB larger than your bulk-max-size value to the specified size. For a change data capture (CDC) load task, the instance migrates all LOBs using a source table lookup, as in standard full LOB mode (see the following). It does so regardless of LOB size.

      Note

      You can migrate views for full-load tasks only.

    • unlimited – The migration mechanism for full LOB mode depends on the value you set for bulk-max-size as follows:

      • Standard full LOB mode – When you set bulk-max-size to zero, the replication instance migrates all LOBs using standard full LOB mode. This mode requires a lookup in the source table or view to migrate every LOB, regardless of size. This approach typically results in a much slower migration than for limited LOB mode. Use this mode only if all or most of your LOBs are large (1 GB or larger).

      • Combination full LOB mode – When you set bulk-max-size to a nonzero value, this full LOB mode uses a combination of limited LOB mode and standard full LOB mode. That is for a full load task, if a LOB size is within your bulk-max-size value, the instance migrates the LOB inline as in limited LOB mode. If the LOB size is greater than this value, the instance migrates the LOB using a source table or view lookup as in standard full LOB mode. For a change data capture (CDC) load task, the instance migrates all LOBs using a source table lookup, as in standard full LOB mode (see the following). It does so regardless of LOB size.

        Note

        You can migrate views for full-load tasks only.

        This mode results in a migration speed that is a compromise between the faster, limited LOB mode and the slower, standard full LOB mode. Use this mode only when you have a mix of small and large LOBs, and most of the LOBs are small.

        This combination full LOB mode is available only for the following endpoints:

        • IBM Db2 as source

        • SAP ASE as source or target

      Regardless of the mechanism you specify for unlimited mode, the instance migrates all LOBs fully, without truncation.

    • none – The replication instance migrates LOBs in the selected table or view using your task LOB settings. Use this option to help compare migration results with and without LOB settings for the selected table or view.

    If the specified table or view has LOBs included in the replication, you can set the BatchApplyEnabled task setting to true only when using limited LOB mode.

    In some cases, you might set BatchApplyEnabled to true and BatchApplyPreserveTransaction to false. In these cases, the instance sets BatchApplyPreserveTransaction to true if the table or view has LOBs and the source and target endpoints are Oracle.

  • bulk-max-size – Set this value to a zero or non-zero value in kilobytes, depending on the mode as described for the previous items. In limited mode, you must set a nonzero value for this parameter.

    The instance converts LOBs to binary format. Therefore, to specify the largest LOB you need to replicate, multiply its size by three. For example, if your largest LOB is 2 MB, set bulk-max-size to 6,000 (6 MB).

Table-settings examples

Following, you can find some examples that demonstrate the use of table settings.

Example Load a table segmented by partitions

The following example loads a SALES table in your source more efficiently by loading it in parallel based on all its partitions.

{ "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" } } ] }

Example Load a table segmented by subpartitions

The following example loads a SALES table in your Oracle source more efficiently by loading it in parallel based on all its subpartitions.

{ "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" } } ] }

Example Load a table segmented by a list of partitions

The following example loads a SALES table in your source by loading it in parallel by a particular list of partitions. Here, the specified partitions are named after values starting with portions of the alphabet, for example ABCD, EFGH, and so on.

{ "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" ] } } ] }

Example Load an Oracle table segmented by a selected list of partitions and subpartitions

The following example loads a SALES table in your Oracle source by loading it in parallel by a selected list of partitions and subpartitions. Here, the specified partitions are named after values starting with portions of the alphabet, for example ABCD, EFGH, and so on. The specified subpartitions are named after values starting with numerals, for example 01234 and 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" ] } } ] }

Example Load a table segmented by ranges of column values

The following example loads a SALES table in your source by loading it in parallel by segments specified by ranges of the SALES_NO and REGION column values.

{ "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" ] ] } } ] }

Here, two columns are specified for the segment ranges with the names, SALES_NO and REGION. Two boundaries are specified with two sets of column values (["1000","NORTH"] and ["3000","WEST"]).

These two boundaries thus identify the following three table segments to load in parallel:

Segment 1

Rows with SALES_NO less than or equal to 1,000 and REGION less than "NORTH". In other words, sales numbers up to 1,000 in the EAST region.

Segment 2

Rows other than Segment 1 with SALES_NO less than or equal to 3,000 and REGION less than "WEST". In other words, sales numbers over 1,000 up to 3,000 in the NORTH and SOUTH regions.

Segment 3

All remaining rows other than Segment 1 and Segment 2. In other words, sales numbers over 3,000 in the "WEST" region.

Example Load two tables: One segmented by ranges and another segmented by partitions

The following example loads a SALES table in parallel by segment boundaries that you identify. It also loads an ORDERS table in parallel by all of its partitions, as with previous examples.

{ "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" } } ] }

Example Load a table with LOBs using limited LOB mode

The following example loads an ITEMS table including LOBs in your source using limited LOB mode (the default) with a maximum nontruncated size of 100 MB. Any LOBs that are larger than this size are truncated to 100 MB. All LOBs are loaded inline with all other column data types.

{ "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" } } ] }

Example Load a table with LOBs using standard full LOB mode

The following example loads an ITEMS table in your source, including all its LOBs without truncation, using standard full LOB mode. All LOBs, regardless of size, are loaded separately from other data types using a lookup for each LOB in the source table.

{ "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" } } ] }

Example Load a table with LOBs using combination full LOB mode

The following example loads an ITEMS table in your source, including all its LOBs without truncation, using combination full LOB mode. All LOBs within 100 MB in size are loaded inline along with other data types, as in limited LOB mode. All LOBs over 100 MB in size are loaded separately from other data types. This separate load uses a lookup for each such LOB in the source table, as in standard full LOB mode.

{ "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" } } ] }

Example Load a table with LOBs using the task LOB settings

The following example loads an ITEMS table in your source, including all LOBs, using its task LOB settings. The bulk-max-size setting of 100 MB is ignored and left only for a quick reset to limited or unlimited mode.

{ "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" } } ] }