Oracle Replication Done Right..!!
Whether it is a cloud, an on-premises, or a hybrid environment, the question asked most often is “What is the right solution to protect my data from failures – with the least amount of downtime and data loss?” Well, one choice that comes to mind is to replicate the data to another physical site. This means all the data changes are physically copied to a remote location using some application-agnostic replication technology. You can then activate the remote site in the event of a primary failure. So far so good. Which means “replication” is the solution which fits the bill. The default replication choice is to just replicate all the changes happening to the data at the storage level. Simple enough. Right?
Not really. For most common deployments using generic storage-based replication, the replication simply stops at the storage level. It never gets deeper. When the replication happens at the block level, the storage system has no clue about the type of data it is replicating. It just replicates whatever you throw at the storage, faithfully. There is both a good and a really bad aspect to this method.
Peeling back some layers you will find that you opened a big can of worms. To start with, what if you accidentally delete a file? Guess what, that deletion gets replicated and the file is lost in the remote site too. What if there is a logical corruption on your production database? That too gets replicated faithfully. What if you want to offload your read-only analytical queries or reporting to the remote site while the replication is going on? Good luck with that, as mirrored copies of data are ‘dark’. The point is, while application agnostic storage replication seems to be easy, it just adds complexity when replicating databases that store your mission critical data.
To look at it in another way, take the database server as an example. The IO changes in the memory usually traverse through various layers – from memory to HBA to a storage switch to a storage controller and finally to an actual disk. All pieces of the stack have their own firmware. A software bug or any issue with any component in the stack can result in data corruption – which the storage is not aware of and it does not care about either. The corrupted data is replicated. I am not making this up, but there are real-world use cases. See the following:
to continue reading the article, click the link down below:
We hope the content could be useful for your Oracle DBA Tasks!