Greetings and welcome to a new regular column in DBAzine that explores the skills required of DBAs as their companies move from traditional business models to become e-businesses. This, of course, begs the question: 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 outages.”

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 tool.

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 hours)

·        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 down. 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.

Conclusion