The eDBA and Data Availability

Published in October 2000

What is meant by the term e-business? There is a lot of marketing noise surrounding e-business and sometimes the messages are confusing and disorienting. Basically, e-business can be thought of as
the transformation of key business processes through the use of Internet technologies.

Internet usage, specifically web usage, is increasing at a rapid pace and infiltrating most aspects of our lives. Web addresses are regularly displayed on television commercials, many of us buy
books, CDs, and even groceries on-line instead of going to traditional “bricks and mortar” stores, and the businesses where we work are conducting web-based transactions with both their customers
and suppliers.

Indeed, Internet technologies are pervasive and the Internet is significantly changing the way we do business. This column will discuss how the transformation of businesses to e-businesses impacts
the disciplines of data management and database administration. Please feel free to e-mail me with any burning issues you are experiencing in your shop and to share both successes and failures
along the way to becoming an eDBA, that is, a DBA who manages the data of an e-business.

The First Important Issue is Availability

Because an e-business is an online business, it can never close. There is no such thing as a batch window for an e-business application. Customers expect full functionality on the Web regardless of
the time of day. And remember, the Web is worldwide-when it is midnight in Chicago it is 3:00 PM in Sydney, Australia. An e-business must be available and operational 24 hours a day, 7 days a week,
366 days a year (do not forget leap years). It must be prepared to engage with customers at any time or risk losing business to a company whose Web site is more accessible. Some studies show that
if a web user clicks his mouse and does not receive a transmission back to his browser within seven seconds he will abandon that request and go somewhere else. On the web, your competitor is just a
simple mouse click away.

The net result is that e-businesses are more connected, and therefore must be more available in order to be useful. So as e-businesses integrate their Web presence with traditional IT services such
as database management systems, it creates heightened expectations for data availability. And the DBA will be charged with maintaining that high level of availability. In fact, BMC Software has
coined a word to express the increased availability requirements of web-enabled databases: e-vailability.

What is Implied by e-vailability?

The term e-vailability describes the level of availability necessary to keep an e-business continuously operational. Downtime and outages are the enemy of e-vailability. There are two general
causes of application downtime: planned outage and unplanned outage.

Historically, unplanned outages comprised the bulk of application downtime. These outages were the result of disasters, operating system crashes, and hardware failures. However, this is simply not
the case any more. In fact, today most outages are planned outages, caused by the need to apply system maintenance or make changes to the application, database, or software components. (Refer to
Figure 1.) Fully 70 per cent of application downtime is caused by planned outages to the system. Only 30 per cent is due to unplanned outages.


Figure 1: Downtime Versus Availability

Industry analysts at the Gartner Group estimate that as much as 80% of application downtime is due to application software failures and human error (see Figure 2). Hardware failures and operating
system crashes were common several years ago, but today’s operating systems are quite reliable, with a high mean time between failure.

What does all of this mean for the eDBA? Well, the first thing to take away from this discussion is: “Although it is important to plan for recovery from unplanned outages, it is even more
important to minimize downtime resulting from planned outages. This is true because planned outages occur more frequently and therefore can have a greater impact on e-vailability than unplanned

How can an eDBA reduce downtime associated with planned outages? The best way to reduce downtime is to avoid it. Consider the following technology and software to avoid the downtime traditionally
associated with planned outages.


Figure 2. Causes of Unplanned Application Downtime
(source: Gartner Group)

Whenever possible, avoid downtime altogether by managing databases while they are online. One example is concurrent database reorganization. Although traditional reorganization scripts and
utilities require the database objects to be offline (which results in downtime) new and more efficient reorganization utilities are available that can reorg data to a mirror copy and then swap the
copies when the reorg process is complete. If the database can stay online during the reorg process, downtime is eliminated. These techniques require significantly more disk space, but will not
disrupt an online business.

Another example of online database administration is tweaking system parameters. Every DBMS product provides system parameters that control the functionality and operation of the DBMS. For example,
the DSNZPARMs in DB2 for OS/390 or the init.ora parms in Oracle. Often it is necessary to bring the DBMS down and restart it to make changes to these parameters. In an e-business environment this
downtime can be unacceptable.

There are products on the market that enable DBMS system parameters to be modified without recycling the DBMS address spaces. Depending upon the e-business applications impacts, the affected system
parameters, and the severity of the problem, a single instance where the system parameters can be changed without involving an outage can cost justify the investment in this type of management

Sometimes downtime can not be avoided. If this is the case, you should strive to minimize downtime by performing tasks faster. Be sure that you are using the fastest and least error-prone
technology and methods available to you. For example, if a third party RECOVER, LOAD, or REORG utility can run from one half to one quarter of the time of a traditional database utility, consider
migrating to the faster technology. In many cases the faster technology will pay for itself much quicker in an e-business because of the increased availability requirements.

Another way to minimize downtime is to automate routine maintenance tasks. For example, changing the structure of a table can be a difficult task. The structure of relational databases can modified
using the ALTER statement, but the ALTER statement, however, is a functionally crippled statement. It cannot alter all of the parameters that can be specified for an object when it is created. Most
RDBMS products enable you to add columns to an existing table but only at the end; further you can not remove columns from a table. The table must be dropped, then re-created without the columns
targeted for removal. Another problem that DBAs encounter in modifying relational structures is the cascading drop effect. If a change to a database object mandates it being dropped and re-created,
all dependent objects are dropped when the database object is dropped. This includes tables, all indexes on the tables, all primary and foreign keys, any related synonyms and views, any triggers,
and all authorization. Tools are available that allow you to make any desired change to a relational database using a simple online interface. By pointing, clicking, and selecting using the tool,
scripts are generated that understand the correct way to make changes to the database. When errors are avoided using automation, downtime is diminished, resulting in greater e-vailability.

The Impact of Downtime on an e-business

Downtime is truly the insidious villain out to ruin e-businesses. To understand just how damaging downtime can be to an e-business, consider the series of outages taken by eBay in 1999. As the
leading auction site on the Internet, eBay’s customers are both the sellers and buyers of items put up for bid on its Web site. The company’s business model relies on the Web as a mechanism for
putting buyers in touch with sellers. If buyers can not view the items up for sale, the model ceases to work.

From December 1998 to June 1999 the eBay web site was inaccessible for at least 57 hours caused by the following:

December 7                 Storage software fails (14 hours)
December 18               Database server fails (3 hours)
March 15                     Power outage shuts down ISP
May 20                        CGI Server fails (7 hours)
May 30                        Database server fails (3 hours)
June 9                          New UI goes live; database server fails (6
June 10                        Database server fails (22 hours)
June 12                        New UI and personalization killed
June 13-15                   Site taken offline for maintenance (2 hours)

These problems resulted in negative publicity and lost business. Some of these problems required data to be restored. eBay customers could not reliably access the site for several days. Auction
timeframes had to be extended. Bids that might have been placed during that timeframe were lost. eBay agreed to refund all fees for all auctions on its site during the time when its systems were

To recover from this series of outages eBay’s profits were impacted by an estimated $5 million in refunds and auction extensions. This, in turn, caused the stock to drop from a high of $234 in
April to the $130 range in mid-July. Don’t misunderstand and judge eBay too harshly though. eBay is a great site, a good business model, and a fine example of an e-business. But better planning
and preparation for “e-database administration” could have reduced the number of problems they encountered.


These are just a few techniques eDBAs can use to maintain high e-vailability for their web-enabled applications. Read this column every month for more tips, tricks, and techniques on achieving
e-vailability, and migrating your DBA skills to the web.

This article was previously published in – The online portal for database issues and solutions – Sponsored by BMC

Share this post

Craig Mullins

Craig Mullins

Craig S. Mullins is a data management strategist and principal consultant for Mullins Consulting, Inc. He has three decades of experience in the field of database management, including working with DB2 for z/OS since Version 1. Craig is also an IBM Information Champion and is the author of two books: DB2 Developer’s Guide and Database Administration:The Complete Guide to Practices and Procedures. You can contact Craig via his website.

scroll to top
We use technologies such as cookies to understand how you use our site and to provide a better user experience. This includes personalizing content, using analytics and improving site operations. We may share your information about your use of our site with third parties in accordance with our Privacy Policy. You can change your cookie settings as described here at any time, but parts of our site may not function correctly without them. By continuing to use our site, you agree that we can save cookies on your device, unless you have disabled cookies.
I Accept