Monthly Archives: April 2019

What is synchronous replication?

In synchronous replication, all committed data at the primary location also exists simultaneously at the remote location. When a piece of data is being written to a disk at the primary location, it must also be written (replicated) at the secondary (remote) location, and the secondary location must acknowledge that it has received and written that piece of data. Only then, the next piece of data can be written to the primary location, replicated to the secondary location, and so on. The result is two identical copies of data, in real time, which is ideal for rapid disaster recovery and the highest application availability. However, synchronous replication has two important limitations: cost and distance. To sustain synchronous replication, the organization needs to invest in, maintain, and staff two data centers (the primary, production site and the secondary, disaster recovery site). The organization must also maintain extremely fast and costly communication lines between the two sites. Because synchronous replication is costly, this topology is unaffordable for many organizations. The second limitation of synchronous replication is that the primary and secondary locations must be close to each other in order to minimize latency when moving the data between the primary and DR sites. The maximum distance between the two sites is usually around 45 miles. This means that in case of a large, regional disaster, it is possible that both data centers will be hit; in this case, data will be lost, and application downtime is assured.

read more »

Creating an Oracle Linux ASM Docker Image over Ubuntu 14.04

Prerequisites 64-bit Ubuntu 14.04 server General Information In this setup we are: Installing Docker Creating a non-root user with Sudo and Docker privileges (axxana) ASM device is /dev/sdb1. Enabling SQLNET and SSH to the container The default ASM port is 1521. The SSH port is 2222. The password for root and grid OS users in the container is axxana. The password for sys ASM user is axxana. The grid software is 12.2 without any patches. The container operating system is Oracle Linux 7.5. Within the container, there is no use of UDEV / ASMLIB or ASMFD: asm_diskstring=’/dev/asm*’,’/bbx/data/*’,’/dev/*’ All tests are done on regular Ubuntu 14.04 and on Axxana’s ISO (based on 14.04). There is a crontab job to keep 15 days of trace files and remove audit files.

read more »

Tutorial: Maintaining Database Consistency Across Multiple Databases with Axxana’s Phoenix

When replicating CRM, ERP, data warehouse, and other mission-critical applications in an asynchronous environment, each application’s database is typically synchronized to a different point in time. Because there are frequently dependencies across these applications, the challenge when a disaster occurs and recovery begins is to synchronize all of these applications to one consistent point in time—that is, the exact time the disaster occurred in the primary site. Without Axxana’s Phoenix, doing so is extremely complex and time-consuming. In this scenario, disaster recovery—and therefore, application availability and uptime—can be delayed for minutes, if not hours, as the IT team works to restore consistency.

read more »

New Tutorial: Using Oracle Far Sync 12c with Axxana to Achieve Continuous Application Availability

Oracle Data Guard Far Sync has been an important solution for organizations seeking to reduce disaster recovery costs and complexity by moving from a three-data-center topology to a two-data-center topology. Although its lightweight model provides a less costly alternative to a three-data-center topology, Far Sync still has the other disadvantages of traditional synchronous replication solutions: Organizations need to invest in a nearby facility from which to run the Far Sync instance; the high-bandwidth communication lines between the production and nearby site are costly; and latency still impacts performance.

read more »