This paper describes several best practices for minimizing or even potentially eliminating planned database outages. An outage is any situation in which the database is unable to serve user requests, either completely as in the case of an offline database or partially as in the case of unacceptable performance. Planned outages can include activities such as routine database maintenance activities or upgrades to your database environment.
Outages have a direct impact on the availability of your database environment. Availability is a measure of a system’s ability to serve user application requests. Some database environments can tolerate occasional interruptions in availability while others must be available around the clock. The availability strategy you choose, and the resources you spend to achieve your availability goals, should be driven by the needs of your business.
DB2 data server contains features that can help you eliminate some types of planned outages and reduce the impact of others. This paper will discuss those features as well as when and how to use them to help achieve a high level of availability.
This paper focuses on strategies for managing planned database outages, particularly when performing maintenance activities, with the goal of achieving a level of database availability that meets the needs of your business.
Areas of specific focus in this paper include:
- Table and index maintenance
- Data loading or data ingestion
This paper will also provide an overview of strategies for improving availability through:
- Tuning features and configuration
- Storage management
In the context of your business’ process and your underlying database solution, availability refers to the measure of the database’s ability to process transactions for user applications in a timely fashion.
The availability requirements of a database solution are determined by the needs of your business. For example, if a database solution serves a single storefront business that is open from 9:00am to 5:00pm, then the database could potentially be off-line from 5:01pm to 8:59am every night and still be considered highly available. On the other hand, if that same database solution serves a chain of stores that span multiple time zones, the window of possible down time becomes smaller. If the database solution serves an on-line business that needs to serve customers 24 hours every day, the database cannot be taken off-line at all without affecting customers.
An outage is any disruption in the ability of the database solution to serve user applications. Outages can be complete, as in the case of a database being offline, or partial, as in the case of unacceptably slow performance due to a high demand on the system’s resources.
Outages can be classified in two groups: planned outages, which are the focus of this best practices paper, and unplanned outages.
Examples of unplanned outages include:
- The failure of one or more key components of the system, including hardware or software failure.
- Inadvertent administrative or user application actions such accidentally dropping a table that is needed for business-critical transactions.
- Poor performance due to suboptimal database configuration, or inadequate hardware or software.
Examples of planned outages include:
- Maintenance activities that require you to take the database offline, or maintenance activities that can be performed without stopping the database but that can adversely affect performance. These are the most common types of planned outages.
- Upgrades to your software or hardware, such as the installation of a DB2 Fix Pack, that may require you to take a partial or complete database outage.
The availability strategy you choose should be based on the impact that planned outages will have on your business. In some cases, investing significant resources in a strategy that guarantees your database is highly available may be appropriate; in other cases you may not need a highly-available environment, if at all.
A crucial factor in determining your availability strategy is to ask how tolerant your business, or a specific system in your business, is to the occurrence of an outage. For example, a restaurant that has a website that contains menu information may be able to tolerate the occasional planned outage. On the other hand, any outage (planned or unplanned) on a stock exchange server that handles trade-related transactions would be catastrophic. Investing a significant amount of resources to ensure the restaurant’s server is 99.99% available may not be cost-effective, but it certainly would be in the case of the stock exchange. Quantifying the impact of outages, be it in terms of lost revenue, lost productivity, or even lost customer confidence and goodwill, will help you make decisions about the level of investment you should make in your availability strategy.
Of course, you should try to avoid planned outages whenever possible by performing routine maintenance tasks, like database backups, while the database is online. You can also greatly reduce the duration of planned outages when performing upgrades.
Some database maintenance tasks may always require full or partial planned outages but you may be able to take steps to reduce the impact of these outages in terms of the amount of time it takes to complete the maintenance task, or by minimizing the amount of system resources the task consumes. For example, excessive reorganization of tables or indexes can needlessly consume system resources to the point where your end users experience unacceptably slow response times to their queries. The database may still be theoretically online but suffering symptoms of a “brown out”, perhaps causing applications to time out before transactions can be committed. When it comes to upgrades, you can dramatically reduce the duration (and therefore the impact) of the outage by using DB2 features like High Availability Disaster Recovery (HADR) or by taking advantage of separate DB2 installations on the same system.Download the full report for more on Best Practices for Minimizing Planned Outages.Download the report to get started!#Db2