New Tutorial: When HW Goes Bust and WAN Still Works

Disasters aren’t the only reason that organizations need to fail over to another data center. Hardware failures can also occur.  In these scenarios, organizations using asynchronous replication typically lose yet-to-be-replicated data and files, resulting in application inconsistences, protracted reconciliation, and extended downtime. However, with Axxana’s Phoenix, they can avoid these risks and continue operations without interruption.

read more »
Database Auto Discovery

Database Auto Discovery

Hi, I was asked by our development team to provide the best way to identify database parameters from the database host. I was surprised to find so many options.

read more »

New Tutorial: 2 DCs with Axxana Is Better Than 3 DCs

To ensure continuous application availability in the event of a disaster, organizations operating mission-critical databases typically implement solutions that revolve around synchronous replication in a three-data-center topology; however, these solutions come at a high price in terms of dollars and risk. That’s because three-data-center solutions cannot guarantee zero data loss and therefore continuous availability in the event of a rolling or regional disaster. In addition, maintaining a nearby data center to host the synchronous replication instance imposes significant Capex and Opex costs, as well as the costs associated with using fiber optic lines to connect the primary data center and the nearby facility.

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 »