We are replicating a lot of tables (170) and we are not seeing the prompt in the Dbvisit Replicate console.
Even when the console is listing all the tables being replicated, the command prompt is still available. However, the table listing can be so long that the prompt cannot be seen. By default, 30 tables are listed for each replication, thus for a 2-way replication, it takes up to 70 screen lines.
To change this, edit the *-MINE.ddc file and add line "set STATUS_BAR_ACTIVE_TABLES 5". Or enter this command at the console prompt. Restart the console for this change to take affect.
...
Why does the mine process have to go back to previous logs when it restarts?
The mine process always has to go back to the start of the oldest active transaction. That is why on re-start the mine has to go back to a previous log (plog) when it restarts. Note that Dbvisit Replicate will never remove a plog that still has an active transaction.
...
How do we see how the replication is going?
To asses how the replication is going, start the Dbvisit Replicate console. Then look at the first lines that display datetime, log sequence and SCN of the mine and apply processes. These numbers should be constantly updating as the replication is happening in real-time.
The first time you start the replication, it starts at the time as of when the *-apply.sh script was run; on subsequent restarts, it needs to go back to the start of the oldest active transaction.
...
How is 2-way (active-active) replication different to 1-way replication?
With 1-way replication there is a MINE process on the source database and an APPLY process on the target database.
With 2-way replication there is a MINE and APPLY process on the source database and an APPLY and MINE process on the target database. Each process name must be unique so the second MINE and APPLY processes are usually called MINE1 and APPLY1.
In the console these 4 processes will be displayed at the top of the screen:
| Section | |||||
|---|---|---|---|---|---|
|
...
|