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 »
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.
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.
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|
Last week on Tuesday, 17th of September on the occasion of 25 years anniversary of German Oracle User Group (DOAG), a DOAG Regional meetings around entire Germany took place. I visited the event in the Oracle Office in Nuremberg. It started with live broadcasting of DOAG chairman greeting Dr. Dietmar Neugebauer in all the German regions and DOAG groups at 17:00. Then it continued with a live presentation of Dierk Lenz on a subject Is it worth the migration from Oracle 5 to 12c. With one DOAG quiz the jointed part finished. After that I gave a presentation in Nuremberg on the subject Oracle database High Availability strategy, architecture and solutions. Since I architect, build and administer Oracle database environments for more a decade also doing service management I could manage to combine a 25 page presentation from my previous reports and experience. 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 in my next few articles on my DBMS Blog.
After my presentation we had an interesting discussion on the same topic. I also took a few pictures including a funny fridge in form of Oracle Exadata machine in Oracle office. I share them in this post as well as my presentation: Read more »
Often in a complex enterprise Infrastructure Oracle DBAs face issues by enabling SMTP mail traffic on the databases through corporate email gateway servers. Imagine you have to provide your database applications an ability to send emails via Simple Mail Transfer Protocol (SMTP) protocol from Oracle database. Below I give a detail action plan to accomplish the same. My test example includes an Oracle database 11gR2 running on Linux RedHat 6 and a Microsoft Exchange corporate server.
1. Oracle packages SYS.UTL_SMTP and SYS.UTL_TCP
Check if Oracle packages SYS.UTL_SMTP and SYS.UTL_TCP are available on Oracle database and you have EXECUTE grants on them.
2. Check SMTP access of database Linux server on mail server
– Check whether you are able to contact the email gateway server via SMTP from the database Linux box:
$ telnet smtp_server 25
If you see blank screen or an error: “telnet: Unable to connect to remote host: Connection refused”,
your DB server is not recognized by the SMTP server. In this case you have to apply for mail SMTP access.
Otherwise type the following commands to test sending email from Linux to your corporate email account:
helo mail from: my_email@my_company.com # you should see "Sender OK' rcpt to: my_email@my_company.com # you should see "Recipient OK" data # Start mail input test email via SMTP and orcl DB [Enter] . # mail should be sent [Enter] quit
3. Apply for mail SMTP access
Contact your mail (exchange) admins and apply for SMTP access on your corporate smtp mail gateway server. Below is an example: Read more »