0

Is there a way to keep an exact clone of a database in real-time? (Or very close to real time)

The use case is for data reporting. I'm currently limited in it to make sure the application performance isn't impacted. If there was a real-time clone I could query then application performance becomes less of an issue.

I don't really know what to ask for in Oracle terminology when I approach our DBA folks about a solution, and things always go much more smoothly if I can speak their language from the outset without having to hash out precisely what I'm asking for.

3
  • have you read hevodata.com/learn/oracle-real-time-replication
    – nbk
    Commented Apr 13, 2021 at 15:26
  • 1
    There are two packaged options, both of which are extra cost: Active DataGuard, and GoldenGate. Which is best will depend on exactly which version and edition of Oracle you are using and your specific business case. See here: oracle.com/technetwork/database/availability/…; oracle.com/integration/goldengate
    – pmdba
    Commented Apr 13, 2021 at 18:40
  • "to make sure the application performance isn't impacted" Sounds like you would be fine using the existing database but just have resource manager set up to make sure that your important application processes always have the CPU they require. You'd still need to make sure you don't blow out your cache - but you're going to need more memory for a new server if you go down the replication route anyway. Commented Apr 14, 2021 at 10:47

2 Answers 2

1

Short answer: Data Guard.

Note, this isn't "Active" Data Guard, which costs ready money, but good, "old-fashioned" Data Guard.
It's a Recovery technology, intended to keep standby databases up-to-date and supports three "flavours":

A Physical Standby is only for Recovery purposes, giving you a complete, separate copy of your database that you can switch/fail over to in the event of the Primary database going "Pop!" (and can even happen automatically, if you configure an Observer). Transport and redo apply can be real-time, depending on how the Data Guard configuration is set up.
Downside is that it's only for Recovery purposes and you can't do anything "useful" with it, like query it. (BTW, that's the extra bit that "Active" Data Guard provides - it "cons" a Physical Standby database into allowing queries).

A Logical Standby is probably what you want.
Logical standbys are meant to be readable, all the time.
Downsides are that the transport mechanism is a bit different and can be a bit slower, (transport and apply lag in the handfuls of seconds instead of real-time), some [structural/DDL] changes don't get carried through (so you have to apply them in multiple places) and some of the more "esoteric" Data Types aren't supported (although that list shrinks with every version).

If you wanted to, you could even create a "farm" of Logical Standbys, accessed by clients in a round-robin fashion (as defined in their TNS Naming files), to spread the "read" load even further. (Possibly overkill, given how powerful Oracle Database is, but it's another option. YMMV).

A Snapshot Standby (just for completeness, here) is a "halfway-house" between the two.
Most of the time, it behaves like a regular database, allowing queries to be run against it. Then, periodically, you close it, "plug" it back into the Data Guard infrastructure (which silently converts it into an unreadable, Physical Standby) and it will automatically receive and apply redo logs from the Primary. Then, when you need to use the Snapshot again, you "unplug" it and open it (which silently converts it into a [readable] Snapshot Standby) with data as of the Point-in-Time of the "unplugging".
Useful if you wanted, say, a daily snapshot of your financial transactions to support offline data analytics.
Redo Apply is fast and a whole day's worth of redo can easily be applied in a couple of hours (or less) but, of course, you have to have the extra disk space to store it until it gets applied.
Not for everybody, admittedly, but it's another option.

1
  • Logical standby is it then. Structural changes aren't common: It's a monolithic ERP, and we don't do many customizations or bolt-ons. Most changes are vendor upgrades, and unless they're urgent we let them pile up & apply them in sequence quarterly. But what's the overhead on making a logical copy? Could we simply trash the old one and make a new one after vendor upgrades relatively fast? We're talking maybe 20GB, nothing huge as db's go.
    – Odj fourth
    Commented Apr 15, 2021 at 14:19
0

Dataguard (Physical standby) - Exact physical replica of original database used for high availability and DR solution but not suitable for reporting.It is an active passive replication tool where secondary node cant be connected to application.

Dataguard(Active dataguard(read only),snapshot standby(read write) - Snapshot standby and active dataguard are extended features of Physical standby dataguard,which can be used for offloading and reporting purpose but needs license

Streams - Streams is an old replication tool used only in certain industry which is outdated.

Goldengate - Goldengate is expensive replication tool used for cross platform and active-active replication.Zero downtime migration can be achieved with this tool.

DBvisit - DBvisit is an underrated third party replication tool which is cost effective and easy to manage.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.