This chapter contains the following sections:
Availability is the degree to which an application, service, or function is accessible on demand. Availability is measured by the perception of an application's end user. Users experience frustration when their data is unavailable or the computing system is not performing as expected, and they do not understand or care to differentiate between the complex components of an overall solution. Performance failures due to higher than expected usage create the same disruption as the failure of critical components in the architecture. If a user cannot access the system, it is said to be unavailable. Generally, the term downtime is used to refer to periods when a system is unavailable.
Users who want their systems to be ready to serve them at all times need high availability. A system that is highly available is designed to provide uninterrupted computing services during essential time periods, during most hours of the day, and most days of the week throughout the year; this measurement is often shown as 24x365. However, exceptions can be made for minimal downtime to perform certain operations such as upgrading the system's hardware or software.
Reliability, recoverability, timely error detection, and continuous operations are primary characteristics of a highly available solution:
Reliability: Reliable hardware is one component of a high availability solution. Reliable software—including the database, Web servers, and applications—is just as critical to implementing a highly available solution. A related characteristic is resilience. For example, low-cost commodity hardware, combined with software such as Oracle Real Application Clusters (Oracle RAC), can be used to implement a very reliable system. The resilience of an Oracle RAC database allows processing to continue even though individual servers may fail.
Recoverability: There may be many ways to recover from a failure. Therefore, it is important to determine what types of failures may occur in your high availability environment and how to recover from those failures in a timely manner that meets your business requirements. For example, if a critical table is accidentally deleted from the database, what action should you take to recover it? Does your architecture provide the ability to recover in the time specified in a service-level agreement (SLA)?
Timely error detection: If a component in your architecture fails, then fast detection is essential to recover from the unexpected failure. Although you may be able to recover quickly from an outage, if it takes an additional 90 minutes to discover the problem, then you may not meet your SLA. Monitoring the health of your environment requires reliable software to view it quickly and the ability to notify the database administrator of a problem.
Continuous operation: Providing continuous access to your data is essential when very little or no downtime is acceptable to perform maintenance activities. Activities, such as moving a table to another location in the database or even adding CPUs to your hardware, should be transparent to the end user in a high availability architecture.
More specifically, a high availability architecture should have the following traits:
Tolerate failures such that processing continues with minimal or no interruption
Be transparent to—or tolerant of—system, data, or application changes
Provide built-in preventive measures
Provide active monitoring and fast detection of failures
Provide fast recoverability
Automate detection and recovery operations
Protect the data to minimize or prevent data loss
Implement the operational best practices to manage your environment
Achieve the goals set in SLAs (for example, recovery time objectives (RTOs) and recovery point objectives (RPOs)) for the lowest possible total cost of ownership
The importance of high availability varies among applications. Databases and the Internet have enabled worldwide collaboration and information sharing by extending the reach of database applications throughout organizations and communities. This reach emphasizes the importance of high availability in data management solutions. Both small businesses and global enterprises have users all over the world who require access to data 24 hours a day. Without this data access, operations can stop, and revenue is lost. Users now demand service-level agreements from their information technology (IT) departments and solution providers, reflecting the increasing dependence on these solutions. Increasingly, availability is measured in dollars, euros, and yen, not just in time and convenience.
Enterprises have used their IT infrastructure to provide a competitive advantage, increase productivity, and empower users to make faster and more informed decisions. However, with these benefits has come an increasing dependence on that infrastructure. If a critical application becomes unavailable, then the business can be in jeopardy. The business might lose revenue, incur penalties, and receive bad publicity that has a lasting effect on customers and on the company's stock price.
It is important to examine the factors that determine how your data is protected and maximize availability to your users.
The need to deliver increasing levels of availability continues to accelerate as enterprises reengineer their solutions to gain competitive advantage. Most often, these new solutions rely on immediate access to critical business data. When data is not available, the operation can cease to function. Downtime can lead to lost productivity, lost revenue, damaged customer relationships, bad publicity, and lawsuits.
It is not always easy to place a direct cost on downtime. Angry customers, idle employees, and bad publicity are all costly, but not directly measured in currency. On the other hand, lost revenue and legal penalties incurred because SLA objectives are not met can easily be quantified. The cost of downtime can quickly grow in industries that are dependent on their solutions to provide service.
Other factors to consider in the cost of downtime are:
The maximum tolerable length of a single unplanned outage
If the event lasts less than 30 seconds, then it may cause very little impact and may be barely perceptible to end users. As the length of the outage grows, the effect may grow exponentially and negatively affect the business.
The maximum frequency of allowable incidents
Frequent outages, even if short in duration, may similarly disrupt business operations.
When designing a solution, it is important to recognize the true cost of downtime to understand how the business can benefit from availability improvements.
Oracle provides a range of high availability solutions to fit every organization regardless of size. Small workgroups and global enterprises alike are able to extend the reach of their critical business applications. With Oracle and the Internet, applications and data are reliably accessible everywhere, at any time.
One of the challenges in designing a high availability solution is examining and addressing all of the possible causes of downtime. It is important to consider causes of both unplanned and planned downtime when designing a fault-tolerant and resilient IT infrastructure. Planned downtime can be just as disruptive to operations as unplanned downtime, especially in global enterprises that support users in multiple time zones.
Table 1-1 describes unplanned outage types and provides examples of each type.
Table 1-1 Causes of Unplanned Downtime
| Type | Description | Examples |
|---|---|---|
|
A site failure may affect all processing at a data center, or a subset of applications supported by a data center. |
|
|
|
The whole cluster hosting an Oracle RAC database is unavailable or fails. This includes:
|
|
|
|
A computer failure outage occurs when the system running the database becomes unavailable because it has failed or is no longer accessible. |
|
|
|
A storage failure outage occurs when the storage holding some or all of the database contents becomes unavailable because it has shut down or is no longer accessible. |
|
|
|
A corrupt block is a block that has been changed so that it differs from what Oracle Database expects to find. Block corruptions fall under the following categories: physical and logical block corruptions:
Block corruptions can also be divided into interblock corruption and intrablock corruption:
A data corruption outage occurs when a hardware, software, or network component causes corrupt data to be read or written. The service-level impact of a data corruption outage may vary, from a small portion of the database (down to a single database block) to a large portion of the database (making it essentially unusable). |
|
|
|
A human error outage occurs when unintentional or other actions are committed that cause data in the database to become incorrect or unusable. The service-level impact of a human error outage can vary significantly, depending on the amount and critical nature of the affected data. |
|
|
|
A lost write is another form of data corruption, but it is much more difficult to detect and repair quickly. A data block stray or lost write occurs when:
|
|
|
|
Hang or slowdown occurs when the database or the application is unable to process transactions because of a resource or lock contention. A perceived hang can be caused by lack of system resources. |
|
Table 1-2 describes planned outage types and provides examples of each type.
Table 1-2 Causes of Planned Downtime
| Type | Description | Examples |
|---|---|---|
|
System and database changes |
Planned system changes occur when performing routine and periodic maintenance operations and new deployments. Planned system changes include any scheduled changes to the operating environment that occur outside the organizational data structure in the database. The service-level impact of a planned system change varies significantly depending on the nature and scope of the planned outage, the testing and validation efforts made before implementing the change, and the technologies and features in place to minimize the impact. |
|
|
Data changes |
Planned data changes occur when there are changes to the logical structure or physical organization of Oracle Database objects. The primary objective of these changes is to improve performance or manageability. |
|
|
Application changes |
Planned application changes may include data changes and schema and programmatic changes. The primary objective of these changes is to improve performance, manageability, and functionality. |
|
Oracle offers high availability solutions to help avoid both unplanned and planned downtime, and recover from failures. Chapter 3 and Chapter 4 discuss each of these high availability solutions in detail.
Oracle high availability solutions and sound operational practices are key to the successful implementation of IT infrastructure. However, technology alone is not enough.
Choosing and implementing an architecture that best fits your availability requirements can be a daunting task. MAA simplifies the process of choosing and implementing a high availability architecture to fit your business requirements. The MAA architecture:
Encompasses redundancy across all components
Provides protection and tolerance from computer failures, storage failures, human errors, data corruption, lost writes, system hangs or slowdowns, and site disasters
Recovers from outages as quickly and transparently as possible
Provides solutions to eliminate or reduce planned downtime
Provides consistent high performance and robust security
Is straightforward to deploy, can be managed efficiently, and scales easily
Achieves SLAs at the lowest possible total cost of ownership
To build, implement and maintain such an architecture, you need to:
Understand the key effects of the Oracle high availability features on businesses and applications, as described in Chapter 3 and Chapter 4.
Analyze your specific high availability requirements, including both the technical and operational aspects of your IT systems and business processes, as described in Chapter 2, "Determining Your High Availability Requirements"
Choose a high availability architecture, as described in Chapter 7, "High Availability Architectures and Solutions"
Implement a high availability architecture using the following resources:
MAA and high availability best practices white papers and other information
Oracle offers various best practices white papers, customer MAA papers with proof of concepts, customer case studies, recorded Web casts, demonstrations, and presentations. These resources provide technical details about the MAA various high availability technologies, along with best practice recommendations for configuring and using such technologies.
You can download these MAA resources from the following Web site
http://www.oracle.com/goto/maa
Oracle Database High Availability Best Practices
This book provides detailed best practice recommendations and information. It can help you to configure a new high availability environment, or migrate an existing configuration to create a redundant, reliable system without sacrificing simplicity and performance.
An enterprise with a well-articulated set of high availability best practices that encompass high availability analysis frameworks, business drivers, and system capabilities, enjoys an improved operational resilience and enhanced business agility.