Published in TDAN.com 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.
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.
(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
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 dbazine.com – The online portal for database issues and solutions – Sponsored by BMC
Software.
