I have a requirement to duplicate an Oracle DB over a WAN to a remote site. The data in that copy of the DB (along with many other databases of various platforms) will then be aggregated into a SQL Server database for reporting purposes.
The requirements are:
- there can be no noticeable performance impact on the primary DB
- the secondary DB must be as close to in sync with the primary as possible (i.e. little or no lag)
- the secondary DB must be readable at all times (precludes max performance physical standby)
- the primary is an 220.127.116.11 RAC database.
- there is already a physical standby at the remote site for DR purposes operating in maximum performance mode and using standby logs. It rarely falls more than 2-3 seconds behind the primary. If this server could be leveraged that would be great, but obviously a physical standby cannot be both readable and up to date.
with 11gR1 Oracle introduced Active DataGuard. Allowing you to open the database read only, while the apply is running.
So this is exactly what you need:
BTW: I would personally upgrade to 18.104.22.168 with the latest PSU.
(Unfortunately) Yes: Active Data Guard license.
But on the other side, you don't have to change a thing.... so it is worth the money instead of building up another standby (e.g. logical), which consumes the double disk space/double machine power, special setup and administration etc.etc.....
Sounds like Active Data Guard may be just what I need. Thanks.
Will it affect the performance of the standby or primary? Can it be configured so that applying logs gets top priority and everything else takes a back seat?
there is no difference on the primary site between ADG and normal DG. And there is also no difference in shipment of the redo logs.
The apply performance on the standby is minimally slower (< 2%) and only recognizable if you already have problems that the standby keeps up to date. But then again this does not effect your DR.
It only means that a switchover/failover will take minimally longer....
On the other side, there is always headroom to optimize apply performance. See here: