Blog – Axxana

Database Auto Discovery

Catom — Thu, 30 May 2019 20:00:44 +0000

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. Identifying All Instances on the Current Machine Option 1: $ ps -ef |grep smon | grep -v grep oracle 3025 1 0 2016 ? 00:00:48 asm_smon_+ASM oracle 11459 1 0 17:24 ? 00:00:00 ora_smon_fdb Oracle SID is fdb and process ID is 11459. Option 2: $ pgrep -lf _pmon_ 3025 asm_pmon_+asm 11459 ora_pmon_fdb Oracle SID is fdb and process ID is 11459. Option 3: Here’s a cleaner way for the SID: $ ps -ef |grep ‘ora_smon_.*$’ | grep -v grep | awk -F_ ‘/ora_smon/{print $NF}’ fdb Oracle SID is fdb. Option 4: When we already know ASM home (grid infrastructure), we can use the cluster commands: $ /oracle/product/12.1.0.2/grid/bin/crsctl stat res -t -w “TYPE = ora.database.type”|awk ‘/^ora./ {l=$0;} !/^ora./ { if ( l > “” ) l=l ” ” $0; print l;l=””;}’|grep ${HOSTNAME%%.*} ora.pdb.db 1 ONLINE ONLINE primary_host Open,STABLE Option 5: $ cat /etc/oratab | grep -v ^’#’ | grep -v ^$ | awk -F “:” ‘ { print $1 }’ | grep -v ASM | uniq fdb Identify oracle_home Option 1: Using the process ID we already found in the previous run (look above for Option 1 or 2): $ grep -z ^ORACLE_HOME /proc/11459/environ ORACLE_HOME=/oracle/product/12.1.0.2/dbhome_1 Option 2: $ pwdx 11459 11459: /oracle/product/12.1.0.2/dbhome_1/dbs Option 3: $ strings /proc/11459/environ | grep ORACLE_HOME ORACLE_HOME_LISTNER=/oracle/product/12.1.0.2/grid ORACLE_HOME=/oracle/product/12.1.0.2/dbhome_1 Option 4: $ cat /etc/oratab | grep -v ^’#’ | grep -v ^$ | awk -F “:” ‘ { print $2 }’ | grep -v ASM | uniq /oracle/product/12.1.0.2/grid/oracle/product/12.1.0.2/dbhome_1 If more information is needed, the connection to the remote instances should be created via SQL*Net; for this we should have the sys password. Checking from the Far Sync Instance – What Is the Name of the Primary Database? select INST_ID,SOURCE_DB_UNIQUE_NAME from gv$dataguard_stats where NAME=’transport lag’; SOURCE DB INST UNIQUE ID NAME —- ——- 1 pdb Checking from the Far Sync Instance – What Is the Name of the Standby Database? SQL> SELECT db_unique_name FROM v$archive_dest WHERE destination IS NOT NULL and TARGET not in (‘LOCAL’,’PRIMARY’); DB UNIQUE NAME ——- sdb Identifying Primary and Standby Database Hosts and Ports via tnsping (from Previous Results) $ tnsping pdb TNS Ping Utility for Linux: Version 12.1.0.2.0 – Production on 06-FEB-2017 18:04:00 Copyright (c) 1997, 2014, Oracle. All rights reserved. Used parameter files: /oracle/product/12.1.0.2/dbhome_1/network/admin/sqlnet.ora Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST =primary_host)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = pdb))) OK (0 msec) Please let me know if you have any other tricks!

The post Database Auto Discovery appeared first on Axxana.

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

Catom — Thu, 16 May 2019 20:00:38 +0000

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. Fortunately, Axxana’s Phoenix for Oracle offers the best of all worlds by enabling zero data loss and continuous application availability in a two-data-center topology. To find out how Axxana’s Phoenix for Oracle makes two-data-center solutions more secure, more efficient, and more cost-effective than traditional three-data-center solutions, see our latest tutorial, 2 DCs with Axxana Is Better Than 3 DCs. Eli Efrat, Axxana’s CEO and co-founder, discusses three-data-center topologies, dispels the myth that they guarantee zero data loss and continuous application availability, and shows why they no longer make good business sense for most organizations. He goes on to explain how Axxana’s Phoenix, used in a two-data-center environment, is actually a better solution because it helps organizations eliminate the tremendous cost and complexity of three-data-center topologies while achieving rapid recovery and continuous application availability at any distance. The total running time is 8:48. The tutorial is part of a new tutorial series airing on Axxana’s YouTube channel. Each tutorial explores a different topic that is important to achieving continuous application availability. Axxana experts with decades of IT experience lead the tutorials, which are designed to provide a quick, easy-to-understand overview for disaster recovery and business continuity specialists, compliance officers, risk managers, and business leaders. Each tutorial is supported by additional content such as web pages, blogs, white papers, technical notes, and video animations. For additional resources on this topic, please see the following links: Web page: Two-Data-Center Solutions White paper: Two DCs with Axxana Is Better Than 3 DCs Thanks for watching! For more information, please contact us at info@axxana.com

The post New Tutorial: 2 DCs with Axxana Is Better Than 3 DCs appeared first on Axxana.

New Tutorial: Overcoming Rolling Disasters with Axxana’s Phoenix

Catom — Fri, 03 May 2019 20:00:43 +0000

Many organizations mistakenly believe they are protected against rolling disasters because they use synchronous replication or some other high availability solution; however, this misconception puts them at great risk for data loss and downtime. A rolling disaster usually starts with a line cut, power outage, or other problem with network communication lines. It is an event in which replication to the secondary (disaster recovery) site fails before the primary (production) data center fails. During the interim between replication failure and failure of the primary data center, the primary data center’s production servers continue to produce data that is not being replicated (unless you have Axxana’s Phoenix). Suffice it to say, when data is created and not replicated, data loss and disruptions in availability are guaranteed. To learn how Axxana’s Phoenix ensures continuous availability in a rolling disaster, see our latest tutorial, Overcoming Rolling Disasters with Axxana’s Phoenix. In this tutorial, Eli Efrat, Axxana’s CEO and co-founder, shows why even synchronous replication environments cannot protect your organization against downtime in a rolling disaster. Then, he explains how Axxana’s Phoenix overcomes the pitfalls of traditional solutions to ensure rapid recovery and continuous application availability in any type of disaster. The total running time is 5:21. The tutorial is part of a new tutorial series airing on Axxana’s YouTube channel. Each tutorial explores a different topic that is important to achieving continuous application availability. Axxana experts with decades of IT experience lead the tutorials, which are designed to provide a quick, easy-to-understand overview for disaster recovery and business continuity specialists, compliance officers, risk managers, and business leaders. Each tutorial is supported by additional content such as web pages, blogs, white papers, technical notes, and video animations. For additional resources on this topic, please see the following links: Animated video: Rolling Disasters – And Why Your Current DR Solution Won’t Save You White paper: Rolling Disasters Blog: Why Even Your Synchronous Replication Solution Doesn’t Protect Against Rolling Disasters (And Don’t Say We Didn’t Warn You) Thanks for watching! For more information, please contact us at info@axxana.com

The post New Tutorial: Overcoming Rolling Disasters with Axxana’s Phoenix appeared first on Axxana.

Creating an Oracle Linux ASM Docker Image over Ubuntu 14.04

Catom — Thu, 25 Apr 2019 20:00:41 +0000

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. Apply UDEV rules to make sure the device has permissions of the same container IDs: vi /etc/udev/rules.d/100-asm.rules KERNEL==”sdb1“, NAME=”ASM_DISK”, OWNER=”54421″, GROUP=”54421″, MODE=”0660″ udevadm trigger –sysname-match=sdb1 –verbose Verify the device has ASM labels: DISK_GROUP=$( blkid | grep oracleasm | sed ‘s/.*LABEL=\”$[^\”]*$\” TYPE=\”oracleasm\”/\1/’) if [ -z “$DISK_GROUP” ] then echo “device /dev/sdb1 has not asm metadata” else echo “device /dev/sdb1 has diskgroup $DISK_GROUP” fi Install Docker On Black Box as root: curl -fsSL https://get.docker.com/ | sh or: curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add – add-apt-repository “deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable” apt-get update apt-cache policy docker-ce apt-get install -y docker-ce service docker status Add Users On Black Box as root: Add equivalent user IDs to the docker to follow (will be identified from outside): groupadd -g 54422 asmadmin useradd -u 54421 -g 54422 grid Add a dedicated user to manage the docker: adduser axxana -g 54422 echo “axxana:axxana” | chpasswd usermod -aG docker axxana usermod -aG sudo axxana sed -i ‘/PasswordAuthentication/d’ /etc/ssh/sshd_config ; echo “PasswordAuthentication no” >> /etc/ssh/sshd_config sed -i ‘/PubkeyAuthentication/d’ /etc/ssh/sshd_config ; echo “PubkeyAuthentication yes” >> /etc/ssh/sshd_config sed -i ‘/ChallengeResponseAuthentication/d’ /etc/ssh/sshd_config ; echo “ChallengeResponseAuthentication no” >> /etc/ssh/sshd_config service ssh reload Build a New Image If you already have an image file, skip to the section below, titled Load Image. In this step, we will create a new image from scratch, and then pack it at the end. Ensure you have the following file: \\nas\shared\oracle_tools\DockerASM\docker_asm_build_scripts.tar.gz You can run /depo/build.sh + /depo/export.sh or you can run the following manual steps: Prepare the Files On Black Box as root: scp docker_asm_build_scripts.tar.gz /tmp mkdir /depo/ chown -R root:54422 /depo/ chmod 775 /depo tar xvfz –same-owner /tmp/docker_asm_build_scripts.tar.gz -C /depo/ rm -f /tmp/docker_asm_build_scripts.tar.gz List of the files Script Description adrci_script.sh Runs for crontab to delete trace files periodically build.sh Builds a docker image clean.sh Cleans all docker containers and an image crontab.setup A crontab job script for grid users; deletes trace files periodically disks.sql An SQL script for listing disks docker_descendants.py Checks docker images dependencies docker_folder/Dockerfile Builds instruction for docker image export.sh Exports a docker image and compresses it glogin.sql Establishes settings for proper formatting of SQL*Plus output grants.sql Grants database permission during the build process init+ASM.ora The initialization file for ASM instance install_grid.sh Installs script for grid linuxx64_12201_grid_home.zip Oracle 12.2 grid software (no patches) listener.ora Listener file oracle_asm Logrotate for Oracle logfiles rlwrap-0.42-1.el7.x86_64.rpm Handy tool to enable history in SQL*Plus, asmcmd run.sh Starts a container status.sh Provides images and container status Run the Build Image On Black Box as root/axxana: cd /depo/docker_folder docker build -t ynixon/docker_grid_asm . Run the image detached (at background): docker run –rm –privileged –detach –name asm_grid_build -h gridserver -p 1521:1521 -p 2222:22 –shm-size 2048m -e TZ=UTC -v /sys/fs/cgroup:/sys/fs/cgroup:ro –volume /depo:/software –volume /boot:/boot –device=/dev/sdb1 ynixon/docker_grid_asm Install the grid software: docker exec -it asm_grid_build su – grid -c ‘/software/install_grid.sh’ Save the image with the grid: docker commit -m “oracle linux 7.5 standalone grid infrastructure with ASM” -a “Yossi Nixon <Yossi.Nixon@Axxana.com>” asm_grid_build ynixon/axxana_asm_server Remove the intermediate image (without the grid): docker rm -f asm_grid_build Optional – Check the New Image Run the container at the background: docker run –privileged –detach –name asm_grid -h gridserver -p 1521:1521 -p 2222:22 –shm-size 2048m -e TZ=UTC -v /sys/fs/cgroup:/sys/fs/cgroup:ro –volume /depo:/software –volume /boot:/boot –device=/dev/sdb1 –restart always ynixon/axxana_asm_server Connect to the new container to verify the environment: docker exec -it –user grid asm_grid bash -l Export the image and compress it: docker save -o /depo/export/docker_axxana_asm_server.tar ynixon/axxana_asm_server:latest gzip docker_axxana_asm_server.tar Optional – Load the Image Copy the file \\nas\shared\oracle_tools\DockerASM\docker_axxana_asm_server.tar.gz to /tmp Uncompress the file: gunzip /tmp/docker_axxana_asm_server.tar.gz Load the file into the local container repository: docker load -i /depo/export/docker_axxana_asm_server.tar Run a container based on the loaded image: docker run –privileged –detach –name asm_grid -h gridserver -p 1521:1521 -p 2222:22 –shm-size 2048m -e TZ=UTC -v /sys/fs/cgroup:/sys/fs/cgroup:ro –volume /boot:/boot –device=/dev/sdb1 –restart always ynixon/axxana_asm_server Test connection from remote machines: ssh root@<Black Box IP> -p 2222 sqlplus sys/axxana@<Black Box IP>:1521/+ASM as sysasm Deploy web interface – Portainer: $ docker volume create portainer_data $ docker run -d -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer Open browser at: http://<docker server>:9000/

The post Creating an Oracle Linux ASM Docker Image over Ubuntu 14.04 appeared first on Axxana.

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

Catom — Thu, 18 Apr 2019 20:00:40 +0000

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. To find out how Axxana’s Phoenix overcomes this challenge and ensures continuous availability by synchronizing all these databases to the exact same point in time, see our new tutorial, Maintaining Database Consistency Across Multiple Databases with Axxana’s Phoenix. Eli Efrat, Axxana’s CEO and co-founder, discusses application/database consistency, how data loss impacts consistency, and how lack of consistency impacts failover, availability, and application uptime. He also explains how Axxana’s Phoenix eliminates consistency issues and the need for data reconciliation in disaster scenarios. The result is full consistency across multiple applications, rapid recovery, and continuous availability—even in an asynchronous environment. The total running time is 8:13. The tutorial is part of a new tutorial series airing on Axxana’s YouTube channel. Each tutorial explores a different topic that is important to achieving continuous application availability. Axxana experts with decades of IT experience lead the tutorials, which are designed to provide a quick, easy-to-understand overview for disaster recovery and business continuity specialists, compliance officers, risk managers, and business leaders. Each tutorial is supported by additional content such as web pages, blogs, white papers, technical notes, and video animations. For additional resources on this topic, please see the following links: Web page: Phoenix for Oracle Data sheet: Phoenix for Oracle White paper: Axxana’s Phoenix for Oracle Animated video: Phoenix System for Oracle – Full Consistency Web page: Phoenix Black Box Web page: PhoenixOS™ Thanks for watching! For more information, please contact us at info@axxana.com

The post Tutorial: Maintaining Database Consistency Across Multiple Databases with Axxana’s Phoenix appeared first on Axxana.

Data Guard / Far Sync Best Practice – Control Protection Levels

Catom — Thu, 11 Apr 2019 20:00:53 +0000

The following meta parameter, called DB_ULTRA_SAFE, sets the values for all of the mentioned parameters in Far Sync Best Practice Recommendations (for Oracle 12.1). When DB_ULTRA_SAFE=DATA_ONLY • DB_BLOCK_CHECKING => MEDIUM. • DB_LOST_WRITE_PROTECT => TYPICAL. • DB_BLOCK_CHECKSUM => FULL. When DB_ULTRA_SAFE=DATA_AND_INDEX • DB_BLOCK_CHECKING => FULL. • DB_LOST_WRITE_PROTECT => TYPICAL. • DB_BLOCK_CHECKSUM => FULL. When DB_ULTRA_SAFE=OFF • When any of DB_BLOCK_CHECKING, DB_BLOCK_CHECKSUM, or DB_LOST_WRITE_PROTECT are explicitly set, no changes are made.

The post Data Guard / Far Sync Best Practice – Control Protection Levels appeared first on Axxana.

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

Catom — Thu, 04 Apr 2019 20:00:41 +0000

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. More important, the solution is not immune to regional or rolling disasters, in which power and communication outages can cause synchronous replication to fail. In fact, without Axxana’s Phoenix, no DR solution is immune to these types of disaster. To find out how only Axxana’s Phoenix can solve this industry-wide challenge, watch our new tutorial, Using Oracle Far Sync 12c with Axxana to Achieve Continuous Application Availability, In this tutorial, Eli Efrat, Axxana’s CEO and co-founder, starts by describing how Oracle Data Guard Far Sync typically operates, its cost and distance limitations, and why it alone cannot guarantee continuous availability in a regional or rolling disaster. He then explains how storing the Far Sync instance in Axxana’s disaster-proof Black Box (which resides in the organization’s primary data center) overcomes these limitations to provide continuous availability—while eliminating the need for costly data fiber and a third site for the Far Sync instance. The total running time is 8:25. The tutorial is part of a new tutorial series airing on Axxana’s YouTube channel. Each tutorial explores a different topic that is important to achieving continuous application availability. Axxana experts with decades of IT experience lead the tutorials, which are designed to provide a quick, easy-to-understand overview for disaster recovery and business continuity specialists, compliance officers, risk managers, and business leaders. Each tutorial is supported by additional content such as web pages, blogs, white papers, technical notes, and video animations. For additional resources on this topic, please see the following links: Web page: Phoenix for Oracle Far Sync Data sheet: Phoenix for Oracle Far Sync White paper: Oracle Active Data Guard Far Sync with Axxana Phoenix for Oracle Thanks for watching! For more information, please contact us at info@axxana.com.

The post New Tutorial: Using Oracle Far Sync 12c with Axxana to Achieve Continuous Application Availability appeared first on Axxana.

New Tutorial: Continuous Availability over Async Infrastructure

Catom — Thu, 21 Mar 2019 20:00:02 +0000

Until now, organizations using asynchronous replication have had to settle for application inconsistencies, protracted recovery times, downtime, and poor application availability when disaster strikes. These risks are a result of the inevitable data loss that occurs in asynchronous environments—unless Axxana’s Phoenix is present. If you’re wondering how Axxana’s Phoenix guarantees continuous availability in any topology, Axxana’s new tutorial, Continuous Application Availability over Async Infrastructure, will answer your questions. Eli Efrat, Axxana’s CEO and co-founder, walks through the application recovery process in an asynchronous Oracle Exadata environment where Axxana’s Phoenix has been implemented. The total running time is 6:45. The tutorial is part of a new tutorial series airing on Axxana’s YouTube channel. Each tutorial explores a different topic that is important to achieving continuous application availability. Axxana experts with decades of IT experience lead the tutorials, which are designed to provide a quick, easy-to-understand overview for disaster recovery and business continuity specialists, compliance officers, risk managers, and business leaders. Each tutorial is supported by additional content such as web pages, blogs, white papers, technical notes, and video animations. For additional resources on this topic, please see the following links: Data sheet: Phoenix for Oracle Web page: Phoenix for Oracle Web page: Phoenix Black Box Web page: PhoenixOS™ 3D video journey inside the Phoenix Black Box Thanks for watching! For more information, please contact us at info@axxana.com

The post New Tutorial: Continuous Availability over Async Infrastructure appeared first on Axxana.

Disaster Recovery: Understanding the Path Forward

Catom — Thu, 14 Mar 2019 06:37:32 +0000

Dr. Alex Winokur, Axxana’s co-founder and chief technology officer, is a world-renowned innovator in the areas of data management, data protection, and storage. With more than 30 years’ experience and as an author/co-author of more than 15 patents in the areas of storage, network management, and telecommunications, he has not only helped shape the recent history of disaster recovery (DR) but is also instrumental in creating DR and high-availability solutions that are leading the way into the future. His recent article, Disaster Recovery: Past, Present, and Future—published in the February 2019 issue of The NoCOUG Journal—takes a fascinating look at the technologies that formed the foundation for DR as we know it today, the historic events that escalated the need for more advanced DR capabilities, and the basic approaches that are currently in use. It also points out some of the key shortcomings of current approaches and discusses how they lead to protracted recoveries and longer downtime. Drawing on details that aren’t typically conveyed in discussions of DR and application availability, the article provides a rich context for understanding the current state of DR and what is needed for the future. The article also suggests how organizations can use new technologies—including Axxana’s Phoenix—to overcome shortcomings and create a high-availability DR solution that ensures rapid recovery and continuous application availability. To read the full article, click here. Here are two important takeaways from the article: Recovery point objective (RPO) is about more than data loss. The duration and complexity of the data reconciliation process (which must be performed whenever data loss occurs) is proportional to the amount of data lost. Organizations should think of recovery point objective (RPO) as the number of minutes of missing data that they will need to reconstruct and reconsolidate (i.e., reconcile)—not the number of minutes of data they are willing to lose. The higher the RPO rises (and therefore, the greater the data loss), the costlier the reconciliation process and the longer the downtime. Typical DR configurations—including synchronous replication and cloud-based solutions—cannot guarantee zero data loss and therefore they cannot ensure continuous application availability. DR configurations that separate the primary and secondary center have predominated in the past decade or so; however these solutions cannot ensure zero data loss in rolling disasters and other disaster scenarios. New cloud-based solutions reduce the costs and complexity of DR, but they too are incapable of ensuring zero data loss and continuous application availability. As climate change, terrorist threats, and cyberattacks escalate, organizations that want to thrive in the future will need to embrace artificial intelligence, machine automation, new approaches to cybersecurity, and revolutionary technology such as Axxana’s Phoenix. Read the full article, Disaster Recovery: Past, Present, and Future.

The post Disaster Recovery: Understanding the Path Forward appeared first on Axxana.

Disaster Recovery in the Hybrid Cloud: Enabling High Availability

Catom — Thu, 07 Mar 2019 06:35:15 +0000

As organizations increasingly adopt cloud-based solutions, it’s no surprise that a growing number of organizations are using a hybrid cloud model, including disaster recovery as a service (DRaaS), for disaster recovery. In this model, organizations host mission-critical applications on premises while outsourcing disaster recovery operations to a cloud services provider. The advantage of this strategy is that organizations maintain control of data management even as they offload the capital expenses and operational burdens associated with a standby disaster recovery site. Although the hybrid cloud for DR gives organizations important advantages, it still has one serious drawback: It cannot guarantee high availability (HA) when disaster strikes, because (without Axxana’s Phoenix) data loss will always occur. That’s because synchronous replication to the cloud is not feasible; the latency and high cost of communication lines associated with synchronous replication between the primary site and the distant DR site are too great. In the event of a disaster in a typical hybrid DR model, operations use asynchronous replication to fail over to the standby site. In this scenario, the organization will lose data, causing availability and business continuity to plummet while the organization races to recover and reconcile transactions. Enabling High Availability in Hybrid DR Environments The good news is that Axxana’s Phoenix offers a solution for achieving high availability in hybrid cloud DR environments. The solution leverages Axxana’s Phoenix for Oracle Far Sync, standard Oracle components, and creation of a dedicated Oracle service to automate application failover. To arrive at the solution, Axxana engineers conducted research to assess options for plugging Axxana’s Phoenix for Oracle Far Sync into Oracle RDBMS-based application stacks in order to automate failover and achieve extremely high availability without requiring human intervention or extensive changes to code—and without impacting the application running in the primary site. The main components of the proposed solution, shown in Figure 1, include: Phoenix for Oracle Far Sync Oracle Broker and its Observer component A dedicated Oracle service that manages failover under a single session; the service detects a disaster, performs the failover, and replays the failed transactions, and does so in a transparent manner that practically eliminates impact on the application Figure 1- HA over DR in the Hybrid Cloud Most applications require complex coding to ensure that high-availability solutions address every possible disaster scenario; however, using the solution, organizations do not have to develop complex code for each new application. Once the underlying service configuration is created, organizations can achieve both disaster recovery and high availability on any application out of the box. Essentially, the service layer is application agnostic. It manages high availability and application failover without requiring staff to lift a finger. Using the solution to master seamless application failover, organizations can boost availability even higher to meet aggressive service level agreements (SLAs), while alleviating staffing burdens related to both development and management. For in-depth technical information about Axxana’s high availability solution for the hybrid cloud, read the white paper: Disaster Recovery and High Availability in the Hybrid Cloud.

The post Disaster Recovery in the Hybrid Cloud: Enabling High Availability appeared first on Axxana.