Dbvisit replicate REDO_READ_METHOD

By Franck Pachot

.
A frequent question about replication is the overhead in the source, because in a lot of cases the source is production. Dbvisit replicate comes with the possibility to do the minimum on the source: only the FETCHER process is there to read de redo logs and sends it to the MINE process wich can be on another server.
But maybe even that – reading those critical online redo logs – is worrying you. That’s not a reason to avoid to do a PoC with the production as source. Let’s see how we can use the ‘archived logs only’.
When you don’t need real time replication – which reads redo from the online redo logs – you can configure Dbvisit replicate to read only the archived logs. This is for MINER, or for FETCHER when configured with that 3-tier architecture. Configuring FETCHER is as easy as replying ‘yes’ to the setup wizard:

Following databases are described:
1: ttorcl_src (Oracle)
2: ttorcl_trg (Oracle)
       Select source database: [1] 1
       Select target database: [2] 2
       Will DDL replication be enabled? [yes] yes
       Use fetcher to offload the mining to a different server? (yes/no) [no] yes

and of course you will have one more process to configure:

Following processes are defined:
1: FETCHER on ttorcl_src
  Host: source, SMTP: no, SNMP: no
2: MINE on ttorcl_src
  Host: target, SMTP: no, SNMP: no
3: APPLY on ttorcl_trg
  Host: target, SMTP: no, SNMP: no

I’ve put the FETCHER on the source and the MINE and APPLY on the target.
By default this configuration will read the online redo logs, so let’s change that before starting the processes:

dbvrep> set REDO_READ_METHOD=ARCHONLY
Variable REDO_READ_METHOD set to ARCHONLY for process *.

This is very simple. The setup wizard has setup all information about where the archived logs are, so we have nothing else to do here.
Let’s start the processes and see how it replicates:

The message is ‘FETCHER is running.’ without anything else. Because FETCHER is doing only minimal job, it doesn’t read the redo in the archived logs and doesn’t display anything about the sequence# or SCN.
Of course we have a gap here: the last log switch occured at 06:01:33 and we are at 06:02:31 as seen in the swingbench pane. MINER is at sequence# 386 – which is the current one – but at SCN 0 which just means that it is waiting for that redo to come.
This is the configuration where the overhead on source is minimized. Of course it may be sufficient for your needs if you can live with a 5 or 10 minutes gap. You can parameter the maximum time between two switches but you probably don’t want to checkpoint too often.
Ok, now you want to test what is the overhead if you read online redo logs. It is very easy to do. Just try it and you will see. this is the goal of the post: show how to switch easily between two modes.
I set the READ_READ_METHOD back to REDOFIRST and then stop and restart the FETCHER:

dbvrep> set REDO_READ_METHOD=REDOFIRST
dbvrep> ! shutdown FETCHER
dbvrep> ! /u01/app/oracle/dbvrep_XE/dbvrep_XE-run-source.sh

What has changed here is that the FETCHER status on the top shows the current sequence# of the redo. Of course, it has to know the sequence in order to send the right redo to the MINE process.
But look at the MINE process: still at SCN 0 and I have a gap.
We need to restart the MINE process as well:

I’ve shutdown the MINE from the dbvrep command line and I’ve restarted it from the bottom pane. I’ve just run the ‘run-target.sh’ script. I’ve a warning about the APPLY which is still running and the MINE is started.
Now look at the message status: each process knows the SCN and it is advancing. I’ve no gap. This is real-time apply.
Those screenshot comes from the ‘repattack‘ environment I have used to to a demo and some test to a customer this morning. Don’t hesitate to test it. It’s easy to setup. On your laptop for a demo. And then on production source to validate how it works with your data and workload.

Conclusion

A Proof of Concept for replication must be done on the real context. We want to see the behaviour of the replication on the real data, and with the real rate of DML that is occuring on the source. And that is very difficult to reproduce on test environement. Because if you are able to reproduce the production load on a test environment, then you probably already have a replication solution…
The fear you have to do the PoC directly on the production should not prevent you to do it. It’s non-intrusive. It’s read only. And it can be configured with very limited processing on the source.
Configure a FETCHER. Start with an ‘archived log only’ setup. Then switch to the ‘online redo log’ mode and observe. It’s easy to do. It’s easy to go back to the ‘archivelog only’ mode. It’s easy to stop the fetcher in case the server is overloaded. It’s safe.