Materialization and Resynchronization

Materialization is copying data specified by a subscription from a primary or source database or table, to a replicate or target database or table. Resynchronization makes all of the data in the primary database or table and the replicate database or table identical. You can resynchronize a database, a table, or individual rows. The materialization process causes resynchronization.

The materialization method depends upon the amount of data to be transmitted, the portion of the data that resides at the replicate site, the time available for the process, and whether the primary database or table can have any activity against it.

The provided scenarios make several assumptions and considerations:

Marking tables with text or image columns can take a long time. In Adaptive Server 15.0 ESD #1 and later, the use_index option can significantly speed up marking these columns. When text in a table is marked for replication using one method, those text pages are not remarked if a different method is added. For example, if a database is marked for replication, marking a table containing text columns in that database does not require all the text pages to be re-marked for replication.
The database materialization and synchronization options discussed in the examples use the Adaptive Server database dump and load method. See the Adaptive Server manuals for any requirements for using these routines.
When you dump a database, the secondary truncation point and the RepAgent for the database are included in the dump. Users and permissions are copied; but logins and roles are not.
Adding and dropping a subscription requires the Data Server Interface (DSI) to be active or awaiting command to the replicate database.
These scenarios assume that the connections from the Replication Server to the database exists and that replication definitions are already defined.

See the Replication Server Administration Guide Volume 1 > Manage Subscriptions for complete descriptions of various materializations methods.

Scenario 1
The primary and the replicate database can be refreshed from a different database source while existing replication definitions and subscriptions continue to be used.
Scenario 2
You can materialize a replicate database from a primary database where all user activity has stopped at the primary database.
Scenario 3
You can materialize a replicate database from a primary database where user activity cannot be stopped and using MSA replication.
Scenario 4
You can materialize a primary database from a replicate database where user activity can be stopped and the replicate database is a duplicate of the primary database.
Scenario 5
You can materialize a table to the replicate database where the Replication Server is doing the materialization. In this scenario there are either no users using the table or the primary table can be locked while the materialization is taking place and there are few rows in the table. This scenario lets Replication Server populate the replicate table.
Scenario 6
You can materialize a table where activity to the primary table is going on while the materialization takes place. Use this option when there is a more than a small amount of data to synchronize between the primary and replicate table. This scenario assumes that the table has already been marked using sp_setreptable or sp_setreplicate.