Direct Load Materialization

Use direct load materialization to materialize data between different kinds of primary and replicate databases.

Direct load materialization differs from other automatic materialization methods:

No materialization queue is used with direct load materialization. Data is loaded directly from a primary table into a replicate table.
Replication to other tables is not suspended during direct load materialization. DML operations on a primary table being materialized are stored in a catch-up queue and applied to the replicate table after the initial materialization phase. DML operations on a primary table that is not being materialized are replicated into the replicate table as the DSI receives them. Multiple tables can be concurrently materialized with direct load materialization.When DML operations in a catch-up queue are applied to the replicate table, each insert operation is converted into a delete followed by an insert. Materialization fails when an update changes the primary key.
Note: (For primary IBM DB2 UDB or Oracle database only) If a subscription is created with the direct_load option and if you are anticipating updates to the primary table during materialization time, you must enable the ra_set_autocorrection Replication Agent command to allow Replication Agent to send the values for all columns to the downstream Replication Server.
See Replication Agent Reference Manual > Command Reference > Replication Agent Commands Table > ra_set_autocorrection.
When subscription materialization stops due to an error, regular replication to other tables is not suspended.
Multiple parallel threads can be used to load data from one primary table to its corresponding replicate table. You can tune this multi-threaded behavior with max_mat_load_threads.
When a subscription is materialized using direct_load, you can use the configuration parameter dsi_check_unique_key to control the SAP Replication Server behavior on checking the no unique key criteria. This configuration parameter is available at the server-level through configuration replication server and at the connection-level through alter connection. Its possible values are on and off, and on is its default value.
If dsi_check_unique_key is on, the primary tables with no unique key must not have any activity until the subscription is VALID. If the activity occurs, the subscription may fail during the catch-up phase and the subscription is aborted, and marked with error. When the subscription is aborted, it must be dropped and recreated. Before recreating the subscription, cleaning up the replicate table (like truncate table) is required.
When you set dsi_check_unique_key to off, the subscription may be created successfully, but may potentially have data inconsistency. Turn off this configuration parameter only under these circumstances to ensure data is correct following subscription validation:
- There cannot be any delete statements at the primary table with no unique key.
- There cannot be any insert statements of duplicate rows at the primary table with no unique key.
(For primary DB2 UDB 9.7 and later, or Oracle database only) You can enable more than one thread to select data from the primary table by specifying num_of_selects selects in the create subscription command. See create subscription in the Reference Manual.

The atomic and nonatomic materialization methods described here are only supported for an SAP ASE primary. For an explanation of the different types and methods of materialization, see Types of Materialization in the Heterogeneous Replication Guide and the Subscription Materialization Methods in the Administration Guide: Volume 1.

Direct load materialization can be used to materialize data from:

SAP ASE to SAP ASE
SAP ASE to SAP HANA database
Microsoft SQL Server to SAP HANA database
Oracle to SAP HANA database
DB2 UDB to SAP HANA database

Restrictions and Limitations for create subscription

When the direct_load option is used, no other subscription can be created or defined at the same time for the same replicate table.
The direct_load option is for subscriptions to table replication definitions only and is used with without holdlock. It cannot be used with without materialization or incrementally.
The user and password options are used only with direct_load.
You can only use the direct_load option against a physical database connection, not an alternate or logical connection. This is the case for both the primary connection—the connection specified in the replication definition—and the replicate connection—the connection specified in the subscription.
The maintenance user of the primary database cannot be used in the user and password options to create subscriptions.
You cannot use atomic materialization if the primary database is not SAP ASE. For a primary database other than SAP ASE, the only automatic materialization option supported is direct load.You cannot drop a subscription with the with purge option if the replicate database is not SAP ASE.
This direct_load option is available only if the replicate SAP Replication Server site version and route version to its primary SAP Replication Server are 1571100 or later.
You can use row filtering, name mapping, customized function strings and datatype mapping with subscriptions created using the direct_load option.
If you create a subscription with the direct_load option and if the number of concurrent subscription requests exceeds num_concurrent_subs, Replication Server marks the subscription as PENDING. Replication Server processes the subscription only after the number of concurrent subscription requests falls below num_concurrent_subs.