Oracle database High Availability – Exadata and Oracle 12c

Going through different approaches in building Oracle database systems in best High Availability (HA) practices in my previous articles we went through following important topics:
understanding High Availability (HA) and SLA requirements; reviewing database Availability Levels based on industry standards; building High Availably (HA) database systems based on Oracle ASM, Clusterware and Cold Failover cluster; Oracle Data Guard, Standby and RAC; Extended RAC and MAA. Basically we finished everything but I wanted to give two more extras, which is Oracle Exadata and Oracle 12c High Availability features.

Oracle Exadata Database Machine

The integration of Oracle Maximum Availability Architecture (MAA) best practices with Oracle Exadata Database Machine (Exadata MAA) provides the most comprehensive Oracle High Availability (HA) solution available for the Oracle database. Exadata MAA is very matured and pre-optimized, pre-configured, integrated system of software, servers, storage and MAA configuration best practices that comes ready to implement the highest database High Availability.

Exadata MAA architecture shown in figure below is designed to tolerate unplanned outages of all types, providing both High Availability (HA) and data protection. Exadata MAA also minimizes planned downtime by performing maintenance in a rolling fashion.

Oracle Exadata MAA architecture

Oracle Exadata Maximum Availability Architecture (MAA) architecture

With Oracle Exadata X3 machine version 3 that was announced just before Oracle Open World 2012, Oracle extended the Exadata resources, features and the Support model that all improved the overall system High Availability (HA). The new Oracle Exadata X4 is going to be released in 2014.

See below some high-lights of Oracle Exadata X3
Read more »

Oracle database High Availability – Extended RAC and MAA

In my previous article I described some best practices in architecting database systems High Availability Levels (HA) 2 and 3 describing some technical solutions based on Data Guard, Standby database and Oracle Real Application Cluster (RAC). This time I’ll continue till Availability level 4 describing cluster database solutions based on Oracle Extended RAC and Oracle Maximum Availability Architecture (MAA) principles with combinations of Oracle RAC and Standby databases. I suggest reviewing a few of my previous articles on database High Availability including the Availability Continuum graph that illustrates and depicts the increases in availability that can be gained with the progression between levels of availability:
High Availability and SLA requirements for Oracle database
Oracle High Availability – ASM, Clusterware, Cold Failover
Oracle database High Availability – Data Guard, Standby, RAC

Availability Level 3b: Recovery via Redundant Components – Extended RAC

Oracle Database with Oracle RAC architecture is designed primarily as a scalability and availability solution that resides in a single data center. It is possible however, under certain circumstances, to build and deploy an Oracle RAC system where the nodes in the cluster are separated by up to 100 kilometers, to share the same RAC database with multiple RAC instances spread across two sites. This architecture is referred to as an Extended RAC or Metro cluster. We can consider this database architecture as an extension of Availability level 3.

Oracle Extended RAC Cluster

Oracle RAC Extended Cluster – Metro CLuster

The advantages of using Oracle RAC on extended clusters include: Read more »

Oracle database High Availability – Data Guard, Standby, RAC

In my previous article I described some best practices in architecting database systems for first 2,5 High Availability Levels (HA) describing some technical solutions based on SAN, cluster, Clusterware, Oracle ASM, Cold Failover Cluster (CFC). This time I’ll continue till Availability level 3 describing single and cluster database solutions including Data Guard, Standby database and Oracle Real Application Cluster (RAC). I suggest reviewing a few my previous articles on database High Availability including the Availability Continuum graph that illustrates and depicts the increases in availability that can be gained with the progression between levels of availability:
High Availability and SLA requirements for Oracle database
Oracle High Availability – ASM, Clusterware, Cold Failover

Availability Level 2b: Oracle Data Guard / Standby

Another option of Level 2 availability is employing Oracle Data Guard to replicate the database to the failover hardware. Some down time is incurred during the failover to the redundant system.
At this point we consider Data Guard at one physical location. Applying Data Guard for disaster recovery solutions refers to Availability Level 4.

Oracle Data Guard provides the benefits of system-level, site-level, and data-level protection, resulting in high levels of availability and disaster recovery without loss of data. Data Guard addresses primary servers / site failures and data protection through transactionally consistent Primary and Standby databases that do not share disks, enabling recovery from server / site disasters and data corruption.

Standby database architecture consists of the following key components

-  Primary database resides on server A.

-  Standby database resides on server B. If zero data loss is required with minimum performance impact on the primary database. Read more »

Oracle High Availability – ASM, Clusterware, Cold Failover

In my previous article High Availability and SLA requirements for Oracle database we discussed that the successful High Availability (HA) begins with the understanding of Service Level Agreements (SLA) required by the business along with each of these dimensions. This guides important decisions on IT technology and determines the appropriate level of investment in HA architecture. Choosing the right technical solution for database system design from scratch is difficult. You can follow some best practices in building High Available Oracle database systems based on Availability Levels that match database industry standards. In this article I’ll share some best practices and my experience in architecting database systems for first 2,5 Availability Levels describing some technical solutions based on SAN, cluster, Clusterware, Oracle ASM, Cold Failover Cluster (CFC).

I’ll start with a graph below that illustrates Availability Continuum and depicts the increases in availability that can be gained with the progression between levels of availability. It is not based on empirical data, and the percentage values used are for illustrative purposes only, but being close (based on my experience) to real figures in common IT infrastructure for Oracle database environments though.

Another way to interpret the y-axis scale is as a measure of acceptable down time – the lower end of the axis represents a reasonable amount of down time as tolerable, whereas the upper end of the axis represents even the smallest amount of down time as being intolerable.

Oracle database High Availability Levels

Availability Continuum – Oracle database High Availability Levels

Read more »

High Availability and SLA requirements for Oracle database

Oracle database HA - Unplanned downtime

Unplanned down time is primarily the result of computer failures or data failures.

After my presentation Oracle database High Availability strategy, architecture and solutions at German Oracle User Group (DOAG) meeting in Nuremberg a few days ago I decided to write about High Availability (HA) solutions for Oracle database on my DBMS Blog. I must admit that when I started preparing this topic I realized it’s so extensive and complex that I decided starting slowly describing the things that any DBA or Infrastructure architect should understand before building a high available database system with minim allowed downtime. This first article will focus on understanding the availability requirements and Service Level Agreement (SLA).

Understand and develop Service Level Agreement (SLA)

First, DBA needs to understand Service Level Agreements (SLA) or customer’s service requirements.
A Service Level Agreement (SLA) is a negotiated agreement between two or more parties, where one is the customer and the others are service providers. SLA usually is part of a service contract where a service is formally defined. As an example, IT service providers will commonly include Service Level Agreements within the terms of their contracts with customers to define the level(s) of service being sold in plain language terms. A database SLA typically has a technical definition in terms of following.

System Availability

This is a main SLA element and commonly expressed as a percentage, but is often more meaningful when expressed as hours. For example, 99.9% availability is roughly equivalent to 8 hours and 45 minutes of maintenance window, or allowed downtime, per year.

Availability Target Downtime Per Year (approx.)
90 % 36 days
98 % 7.3 days
99.7 % 26 hours
99.99 % 52 minutes
99.999 % 5 minutes

Read more »

Next Page »

DBMS Blog Updates : Subscribe RSS RSS: Subscribe to Articles · Subscribe to Comments Subscribe RSS Receive site updates via email