| Front Page | News Headlines | Technical Headlines | Planning Features | Advanced Search |
Click for HP Sponsor Page News Icon

January 2003

Migration choices carry DBA costs

By Amy Anderson

Most migration choices carry a higher cost of ownership than sticking with an HP 3000. But you might avoid some expense in switching, if you choose the right database to replace IMAGE.

A DBA’s job is to manage objects, ensure the security and integrity of the database, and optimize the performance of the queries accessing the database. If we analyze these tasks in relation to the tasks required to manage an IMAGE database on the HP 3000, then it should become more apparent why a DBA is required on other platforms when it hasn’t been on the HP 3000.

First, IMAGE is well-integrated with the operating system, and the two components are able to share information about the organization of data on disk. By contrast, most relational databases on Windows and Unix operating systems do not use the operating system’s native file structure to manage data. The result is that DBAs must manage the placement of data on disk. For example, Oracle DBAs must create volumes, volume groups, and tablespaces, and map these data structures to physical disk towers, and then assign databases to tablespaces.

The exceptions to this lack of integration are DB2 UDB for iSeries and future releases of SQL Server. On the iSeries, the relational database is the native file structure, and the operating system automatically stripes objects across disk to eliminate any manual placement, rebalancing or de-fragmenting activities. Microsoft has announced their intent to integrate SQL Server into the Windows .Net operating system, but this capability will not be available until 2004 at the earliest.

For databases that are not integrated with the operating system, database security is an additional requirement beyond system security, with its own security packages, procedures, and protocols. Ignoring database security can have perilous results, even if the system is well protected. For example, a security flaw discovered in SQL Server last summer could, if exploited, render the whole server unbootable. A fix was made available, but the management of these exposures belongs to the DBA.

Integrity within the database is yet another task for the DBA. Because of the nature of relational data, DBAs can choose whether to maintain multiple copies of the same data element in different tables, or to maintain a single copy of every data element in one and only one table. There are trade offs to both choices, and they require a thorough understanding of the system and its use. It is in making these critical choices about referential integrity that DBAs become invaluable to the success of an application.

But a DBA’s job does not end with good design. Performance tuning is a critical, and increasingly, a constant task. In the online transaction processing (OLTP) world of green screen interfaces and COBOL programs, most applications could be tuned once at application design time. With OLTP, users generally run the same types of queries, changing only one or two variables, such as customer number or order number. Unless there is a drastic change in the query, tuning is not required.

But in the world of e-business applications, users tend to have more choices for the queries they run. Many applications, for example, let users choose from a list of variables, such as customer number, product number, or date range. For these dynamic queries, the DBA must monitor the system to watch user behavior and adjust the tuning parameters accordingly. The DBA must watch for spikes in use, such as at the beginning of the work day or the end of month, and balance system resources to account for the fluctuations in demand. To be effective at this task, the DBA can always benefit from intelligent tools that advise and simplify. The table above summarizes the relative effort required for each of the high-level DBA tasks described.

Because the iSeries automates so many management tasks, its database requires fewer DBAs to manage it. Likewise, Oracle’s lack of integration forces the DBA to manually adjust more performance variables.

While a good DBA is worth her weight in gold, businesses that are used to running without any DBA might be less than enchanted by the costs of hiring DBAs. It is important, therefore, to select a database that minimizes the cost of DBAs by providing the greatest amount of automation and self-management.

Amy Anderson is IBM’s eServer iSeries Competitive Marketing Manager.

 


Copyright The 3000 NewsWire. All rights reserved.