High Speed Transaction Recovery - Technology Information

Computer Technology Review, April, 2001 by Craig S. Mullins

Availability is the Holy Grail of database administrators. If your data is not available, your applications cannot run. If your applications cannot run, your company is losing business. Lost business translates into lower profitability and perhaps a lower stock valuation for your company. These are all detrimental to the business and therefore, the DBA is responsible to do everything in his or her power to ensure that databases are kept online and operational. This has been the duty of the DBA since the days of the first DBMS.

But the need for availability is increasing. The days of the long batch window where databases can be offline for extended periods to perform nightly processing are diminishing. Exacerbating this trend is the drive toward e-business. Coupling businesses to the Internet is dramatically altering the way we do business. It has created expectations for businesses to be more connected, more flexible, and importantly, more available.

When you integrate the Web with database management, heightened expectations are placed on DBAs to keep databases up and running more smoothly and for longer periods of time. When your business is on the World Wide Web, it never closes. People expect full functionality on Web sites they visit regardless of the time of day. Remember that the Web is worldwide. It may be three o'clock in the morning in New York, but it is always prime time somewhere in the world. So an e-business must be available and operational 24 hours a day, 7 days a week, 365 days a year (366 for leap years).

Of course, e-business is not the only driver for increased availability. Other factors include:

* The "fast food" mentality of customers who demand excellent service and demand it "now!"

* The desire to gain a competitive advantage in the marketplace by offering superior services at a time of the customer's choosing.

* The need to react to competitors who offer better service to customers because of higher data availability.

With demands for higher and higher availability, especially for e-commerce, traditional forms of database recovery are becoming more and more inadequate. Today, every DBA must become well versed in Transaction Recovery techniques in order to be ready to develop the optimal approach for each recovery situation. But what is "Transaction Recovery?" This article discusses Transaction Recovery from a DB2 for OS/390 point-of-view. Herein we will learn how Transaction Recovery provides the speed and ease of a point-in-time recovery with the selective capability provided by custom programming. Our discussion of Transaction Recovery will cover three areas:

1. The types of Transaction Recovery available and the general characteristics of the problems addressed.

2. The steps required to perform each type of Transaction Recovery, and the conditions and potential problems associated with Transaction Recovery are explained.

3. The features you will need for a high speed, accurate, and robust Transaction Recovery solution.

Types Of Recovery

There are many different types of recovery that can be performed. The first type of recovery that usually comes to mind is a recovery-to-current to handle some sort of disaster. This disaster could be anything from a simple media failure to a natural disaster destroying your data center. Applications are completely unavailable until the recovery is complete.

Another type of traditional recovery is a Point-in-Time (PIT) recovery. PIT recovery usually is performed to deal with an application level problem. Conventional techniques to perform a point in time recovery will remove the effects of all transactions since that specified point in time. This sometimes can cause problems if there were some valid transactions during that timeframe that still need to be applied.

Transaction Recovery is a third type of recovery that addresses the shortcomings of the traditional types of recovery: downtime and loss of good data. Thus Transaction Recovery is an application recovery whereby the effects of specific transactions during a specified timeframe are removed from the database.

Bad Transactions Happen To Good Databases

Historically, recovery was performed mostly because of disasters and hardware failures. However, this is simply not the case anymore. In fact, application level recovery needs to be performed the majority of the time, not hardware recovery. Industry analysts estimate that as much as 80% of application errors are due to application software failures and human error. Although hardware failures and operating system panics were common several years ago, today's operating systems are quite reliable, with a high mean time between failure.

In reality, except for disaster recovery tests, very few DBAs ever need to perform true disaster recovery. While media does fail, it's actually quite rare in this day and age. So, user errors and application failures are the most common causes of problems that require recovery. Therefore, these types of errors also are the primary cause for system unavailability. As databases grow in size and complexity, so, too, do the chances that bad transactions will corrupt the data on which your business depends.