Block or not?

Block or Not?

People are often asking me about the differences between block copy and replication. We have a great video about block copying versus log shipping. The video is short and simple. While it doesn’t cover all of the minute details of block copying, it does highlight some of the very important differences between these two different Disaster Recovery methods.

The video starts off by highlighting that changes made to the primary database are changed in multiple areas. When a user updates data in the Oracle database, those data changes are made to actual data files, to undo tablespace datafiles, and to Oracle redo logs.

Yes, Oracle actually changes block in three different places. Eventually, those redo log changes are copied into an archive log. That same data resides in four different places.

Oracle does this because losing data is a bad thing and Oracle wants to make sure that you can recover from crashes. The redo logs are named just that because they can 'redo' the data if there is a problem.

Block copy is often considered ‘zombie-like’. It doesn’t know the difference and copies all changes made. This may result in data being transferred 3-4 times from the primary site to the standby site. Contrast this with the log shipping method. Only archive logs are shipped. All changes to the database end up in the archive logs so there is no need to ship redundant changes. This means that in places with constricted bandwidth or databases that are extremely large, you can save considerable network costs.

These block copying methods are often an ‘all or nothing’ solution. The danger lies in the fact that if there was a corruption of the data on the primary, that would transfer right over to the secondary site. This would be both for logical corruption of the data as well as physical corruption from hardware failures. With the log shipping method, you can have the standby database be at a ‘set time’ behind the primary. You could build in a 2-3 hour delay if that is the preference. This would often give you time to stop any logical corruption before it got to the secondary site.

Physical corruption is often stopped in its tracks, as when the logs are shipped to the secondary site, the Oracle software is making sure that the archive logs are not corrupt before they are applied to the standby database, thus ensuring that no physical corruption extends from the primary to the standby site.

Block copy methods often require a Storage Area Network (SAN). Log shipping doesn’t require a SAN on either side and often can use a wide variety of storage devices. SANs can also be very expensive whereas, log shipping typically has affordable options. Just like the SAN, the whole block copy mechanism can be a very expensive software product. Many block copy tools are not necessarily compatible with all of the different cloud vendors available today.

Log shipping methods offer on-premises, hybrid, or cloud options. And maybe the last ‘best’ reason that log shipping is superior to block copying is that the log shipping method is the same method that the vendors themselves use. Oracle uses log shipping for their built-in product Oracle Data Guard for disaster recovery. As these products are built thinking about Oracle and thinking about the logs, they become Oracle aware, rather than just a zombie copying tool.

Enjoy the video!