The alter database replication definition syntax has been modified to
add
tables to the replication path and remove tables from the replication
path. You can
specify tables
inline
or in a
file list.
Syntax
alter database replication definition <db_repdef>
with primary at <data_server.database>
{[{not replicate DDL} |
{replicate DDL [{with | without} {auto_update_table_list |
auto_extend_table_list}]}] |
[not] replicate <setname> <setcont> |
[not] replicate {{SQLDML | DML_options} [in <table_list>]} |
[alter owner from <current_table_owner> to <new_table_owner> [for
<table_name>]] |
[{add | remove} tables {<setcont>}]}
[with dsi_suspended]
[user <username> password <pass>]
<setcont> ::= [[in] ([<owner1>.]<name1>[, [<owner2.>]<name2> [, ... ]])] | [in files ([<file1> [, <file2> [, ..]]])]
<setname> ::= {tables | functions | transactions | system procedures}
Usage
- When adding tables:
- If a table is already defined
as
replicating in the database replication definition,
nothing changes. Otherwise, this table is added to the replication
path.
- If
a
replicate site subscribes to
a
database replication
definition,
and the database subscription is created
with the
with
materialization
option,
the table materializes
automatically.
- If
multiple sites subscribe to a database replication definition, the table
is not updated in the rs_dbsubsets table until all sites finish
materialization.
- When removing tables, if a table is
defined as
not replicating in the database replication definition,
nothing changes. Otherwise, the table is removed from the replication path.
- If multiple replicate
sites subscribe to a database replication
definition, changing
the
definition affects all of them.
To
avoid
a
global change, use
a
different database replication definition.