What tables should be avoided for replication besides the ones that are not supported. (4330173)

There are various types of tables in a database. Not considering the ones that are not supported, there are some tables that may be suitable for replication whereas there are others that may not be. This solution delves into this topic briefly.

General information.

In general the tables that contain transactions and other changes to the database that may be suitable for reporting purposes are good candidates for replication. There is another class of tables that also undergo changes but for a different purpose. The tables include temporary tables, staging tables, audit tables, sorting tables and tables that go through data insert and subsequent purge. Such tables should be avoided as it places unnecessary load on replication and the users do not need to query such tables on target. Such tables are only used to derive some information to be used by other tables which may then be queried by users. If at all there is a need, such tables can be created and populated on the target database rather than carry out such process on source database and unnecessarily increase the replication load since the tables themselves may not be large but the amount of data changes required to populate such tables (by way of data load, sort, purge, truncate or other process) can be huge.

Tables with DML on key columns should not be replicated because DML on key columns will cause out of sync.  See Shareplex For Oracle Administrator's Guide for more information and explanation why DML on key columns will cause out of sync.