Starting and Stopping the Replication Agents
After you have defined a replication scheme, you can start the replication agents for
each database involved in the replication scheme. You must have the ADMIN
privilege to start or stop a replication agent.
You can start and stop a replication agent by using the ttAdmin
utility with the -repStart
or -repStop
option. You
can also use the ttRepStart
and ttRepStop
built-in
procedures to start and stop a replication agent from the ttIsql
command line.
To start the replication agents for the DSNs named masterDSN
and
subscriberDSN
, with ttAdmin
, enter:
ttAdmin -repStart masterDSN ttAdmin -repStart subscriberDSN
To stop the replication agents, enter:
ttAdmin -repStop masterDSN ttAdmin -repStop subscriberDSN
To start and stop the replication agent for the DSN named masterDSN
from ttIsql
, enter:
> ttIsql masterDSN Command> call ttRepStart; Command> call ttRepStop;
You can also use the ttAdmin
utility to set the replication restart
policy. By default the policy is manual
, which enables you to start
and stop the replication agents as described above. Alternatively, you can set the
replication restart policy for a database to always
or
norestart
.
Restart Policy | Start Replication Agent When the TimesTen Daemon Starts | Restart Replication Agent on Errors or Invalidation |
---|---|---|
|
Yes |
Yes |
|
No |
Yes |
|
No |
No |
Note:
The TimesTen daemon manages the replication agents. It must be running to start or stop the replication agents.
When the restart policy is always
, the replication agent is
automatically started when the database is loaded into memory. See Specifying a
RAM Policy in Oracle TimesTen In-Memory Database Operations
Guide to determine when a database is
loaded into memory.
To use ttAdmin
to set the replication restart policy to always
, enter:
ttAdmin -repPolicy always DSN
To reset the policy back to manual, enter:
ttAdmin -repPolicy manual DSN
Following a database invalidation, both manual
and
always
policies cause the replication agent to be automatically
restarted. When the agent restarts automatically, it is often the first connection
to the database. This happens after a fatal error that, for example, requires all
applications to disconnect. The first connection to a database usually has to load
the most recent checkpoint file and often needs to do recovery. For a very large
database, this process may take several minutes. During this period, all activity on
the database is blocked so that new connections cannot take place and any old
connections cannot finish disconnecting. This may also result in two copies of the
database existing at the same time because the old one stays around until all
applications have disconnected. For very large databases for which the first-connect
time may be significant, you may want to wait for the old database to become
inactive first before starting up the new one. You can do this by setting the
restart policy to norestart
to specify that the replication agent
is not to be automatically restarted. For more information on setting policies that
would prevent the database from being reloaded, see Specifying a RAM Policy in
Oracle TimesTen In-Memory Database Operations
Guide.