Defining Replication Elements
A classic replication scheme consists of one or more ELEMENT
descriptions that contain the name of the element, its type (DATASTORE
,
TABLE
, or SEQUENCE
), the master database on which it
is updated, and the subscriber databases to which the updates are replicated.
Note:
If you want to replicate a database with cache groups, see Administering an Active Standby Pair With Cache Groups.
These are restrictions on elements:
-
Do not include a specific object (table, sequence or database) in more than one element description.
-
Do not define the same element in the role of both master and propagator.
-
An element must include the database on the current host as either the master, subscriber or propagator.
-
Element names must be unique within a replication scheme.
The correct way to define elements in a multiple subscriber scheme is described in Multiple Subscriber Classic Replication Schemes. The correct way to propagate elements is described in Propagation Scheme.
The name of each element in a scheme can be used to identify the element if you decide later to drop or modify the element by using the ALTER REPLICATION
statement.
You can add tables, sequences, and databases to an existing replication scheme. See Altering a Classic Replication Scheme. You can drop a table or sequence from a database that is part of a replication scheme after you exclude the table or sequence from the replication scheme. See Dropping a Table or Sequence From a Classic Replication Scheme.
The rest of this section includes the following topics:
Defining the DATASTORE Element
You can replicate the entire contents of a master database to a subscriber by defining
the DATASTORE
element.
To replicate the entire contents of the master database (masterds
) to the subscriber database (subscriberds
), the ELEMENT
description (named ds1
) might look like the following:
ELEMENT ds1 DATASTORE MASTER masterds ON "system1" SUBSCRIBER subscriberds ON "system2"
Identify a database host using the host name returned by the hostname
operating system command. It is good practice to surround a host name with double quotes.
Note:
You cannot replicate a temporary database.
You can choose to exclude certain tables and sequences from the
DATASTORE
element by using the EXCLUDE TABLE
and
EXCLUDE SEQUENCE
clauses of the CREATE REPLICATION
statement. When you use the EXCLUDE
clauses, the entire database is
replicated to all subscribers in the element except for the objects that are specified
in the EXCLUDE
clauses. Use only one EXCLUDE TABLE
and one
EXCLUDE SEQUENCE
clause in an element description. For example, this
element description excludes two tables and one sequence:
ELEMENT ds1 DATASTORE MASTER masterds ON "system1" SUBSCRIBER subscriberds ON "system2" EXCLUDE TABLE ttuser.tab1, ttuser.tab2 EXCLUDE SEQUENCE ttuser.seq1
You can choose to include only certain tables and sequences in the database by using
the INCLUDE TABLE
and INCLUDE SEQUENCE
clauses of the
CREATE REPLICATION
statement. When you use the INCLUDE
clauses, only the objects that are specified in the INCLUDE
clauses
are replicated to each subscriber in the element. Use only one INCLUDE TABLE
and one INCLUDE SEQUENCE
clause in an element description. For example, this
element description includes one table and two sequences:
ELEMENT ds1 DATASTORE MASTER masterds ON "system1" SUBSCRIBER subscriberds ON "system2" INCLUDE TABLE ttuser.tab3 INCLUDE SEQUENCE ttuser.seq2, ttuser.seq3
Defining Table Elements
You can replicate tables from a master database to a subscriber database.
To replicate the ttuser.tab1
and ttuser.tab2
tables from a master database (named masterds
and located on a host named system1
) to a subscriber database (named subscriberds
on a host named system2
), the ELEMENT
descriptions (named a
and b
) might look like the following:
ELEMENT a TABLE ttuser.tab1 MASTER masterds ON "system1" SUBSCRIBER subscriberds ON "system2" ELEMENT b TABLE ttuser.tab2 MASTER masterds ON "system1" SUBSCRIBER subscriberds ON "system2"
For requirements for tables in classic replication schemes, see Restrictions and Table Requirements for Classic Replication Schemes.
Replicating Tables With Foreign Key Relationships in a Classic Replication Scheme
In a classic replication scheme, you may choose to replicate all or a subset of tables that have foreign key relationships with one another.
To do so, create the tables and the foreign key relationship on each master
and subscriber. Then, add the tables to the replication scheme with the ALTER
REPLICATION ADD ELEMENT
statement on each master and subscriber.
However, if the foreign key relationships have been configured with ON DELETE CASCADE
, then you must create all of the tables before the replication scheme is created. Then, configure the replication scheme with the CREATE REPLICATION
statment to include all tables with either the DATASTORE
element (that does not exclude any of the tables) or the TABLE
element for every table that is involved in the relationship.
You cannot add a table with a foreign key relationship configured with ON DELETE CASCADE
to the replication scheme after the replication scheme is created with the ALTER REPLICATION
statement. Instead, you must drop the replication scheme, create the new table with the foreign key relationship with ON DELETE CASCADE
, and then create a new replication scheme that includes all of the related tables.
If a table with a foreign key configured with ON DELETE CASCADE
is replicated, then the matching foreign key on the subscriber must also be configured with ON DELETE CASCADE
. In addition, you must replicate any other table with a foreign key relationship to that table. This requirement prevents foreign key conflicts from occurring on subscriber tables when a cascade deletion occurs on the master database.
TimesTen Classic replicates a cascade deletion as a single operation, rather than replicating to the subscriber each individual row deletion which occurs on the child table when a row is deleted on the parent. As a result, any row on the child table on the subscriber database, which contains the foreign key value that was deleted on the parent table, is also deleted, even if that row did not exist on the child table on the master database.
Replicating Sequences
Sequences are replicated unless you exclude them from the replication scheme or unless
they have the CYCLE
attribute.
Replication of sequences is optimized by reserving a range of sequence numbers on the standby database each time a sequence is updated on the active database. Reserving a range of sequence numbers reduces the number of updates to the transaction log. The range of sequence numbers is called a cache. Sequence updates on the active database are replicated only when they are followed by or used in replicated transactions.
Consider a sequence my.seq
with a MINVALUE
of 1, an INCREMENT
of 1 and the default Cache
of 20. The very first time that you use my.seq.NEXTVAL
, the current value of the sequence on the master database is changed to 2, and a new current value of 21 (20+1) is replicated to the subscriber. The next 19 references to my.seq.NEXTVAL
on the master database result in no new current value being replicated, because the current value of 21 on the subscriber database is still ahead of the current value on the master. On the twenty-first reference to my.seq.NEXTVAL
, a new current value of 41 (21+20) is transmitted to the subscriber database because the subscriber's previous current value of 21 is now behind the value of 22 on the master.
Sequence replication has these restrictions:
-
Sequences with the
CYCLE
attribute cannot be replicated. -
The definition of the replicated sequence on each peer database must be identical.
-
No conflict checking is performed on sequences. If you make updates to sequences in both databases in a bidirectional replication configuration without using the
RETURN TWOSAFE
service, it is possible for both sequences to return the identicalNEXTVAL
.
If you need to use sequences in a bidirectional replication scheme where updates may occur on either peer, you may instead use a nonreplicated sequence with different MINVALUE
and MAXVALUE
attributes on each database to avoid conflicts. For example, you may create sequence my.seq
on database DS1
with a MINVALUE
of 1 and a MAXVALUE
of 100, and the same sequence on DS2
with a MINVALUE
of 101 and a MAXVALUE
of 200. Then, if you configure DS1
and DS2
with a bidirectional replication scheme, you can make updates to either database using the sequence my.seq
with the guarantee that the sequence values never conflict. Be aware that if you are planning to use ttRepAdmin
-duplicate
to recover from a failure in this configuration, you must drop and then re-create the sequence with a new MINVALUE
and MAXVALUE
after you have performed the duplicate operation.
Operations on sequences such as SELECT my.seq.NEXTVAL FROM
sys.dual
, while incrementing the sequence value, are not replicated until they are
followed by transactions on replicated tables. A side effect of this behavior is that these
sequence updates are not purged from the log until followed by transactions on replicated
tables. This causes ttRepSubscriberWait
and ttRepAdmin
-wait
to fail when only these sequence updates are present at the end of the
log.
To replicate the ttuser.seq
sequence from a master database (named masterds
and located on a host named system1
) to a subscriber database (named subscriberds
on a host named system2
), the element description (named a
) might look like the following:
ELEMENT a SEQUENCE ttuser.seq MASTER masterds ON "system1" SUBSCRIBER subscriberds ON "system2"
Views and Materialized Views in a Replicated Database
A materialized view is a summary of data selected from one or more TimesTen tables, called detail tables. Although you cannot replicate materialized views directly, you can replicate their underlying detail tables in the same manner as you would replicate regular TimesTen tables.
The detail tables on the master and subscriber databases can be referenced by materialized views. However, TimesTen Classic replication verifies only that the replicated detail tables have the same structure on both the master and subscriber. It does not enforce that the materialized views are the same on each database.
If you replicate an entire database containing a materialized or non-materialized
view as a DATASTORE
element, only the detail tables associated with the
view are replicated. The view itself is not replicated. A matching view can be defined
on the subscriber database, but is not required. If detail tables are replicated,
TimesTen Classic automatically updates the corresponding view.
Materialized views defined on replicated tables may result in replication failures or inconsistencies if the materialized view is specified so that overflow or underflow conditions occur when the materialized view is updated.