Click on our Sponsors to help Support SunWorld
Unix Enterprise by Harris Kern & Randy Johnson

Supporting distributed databases

Database administration in a distributed environment
is manageable with this handy guide

September  1995
[Next story]
[Table of Contents]
Subscribe to SunWorld, it's free!

"Controlling and supporting a central, mission-critical database is hard enough. How do you support distributed, mission-critical databases?" The answer is simple: Policies. A distributed environment does not have to mean chaos. This month, we outline our database administration roles, responsibilities, and physical policies. (1,600 words)

Mail this
article to
a friend

A question we hear often from administrators of mainframe-based databases is "Controlling and supporting a central, mission-critical database is hard enough. How do you support distributed, mission-critical databases?"

Our answer: Policies.

The inevitable follow-up question is, "Can you send me your policy manual?"

While we can't share the manual itself, this month we outline roles, responsibilities, and considerations of physical database administration in distributed environments. Consider this our database policy manual in brief. Since we've presented the responsibilities portion in a handy outline form, we've split this section off as a responsibilities sidebar.

Before getting into the meat of this month's column, we need to remind you we've discussed data center organization before. (See "Getting organized," our July 1994 column in Advanced Systems magazine.) The Database Administration (DBA) Group reports to the top Information Technology (IT) management within the Data Center, along with Systems Programming, Production Control, and Computer Operations. The DBA Group is responsible for supporting the database functions of applications and takes ownership of database servers and software.

We'd like to thank Linda Flores for her contributions to this column. Flores served as DBA's manager during Sun's recent rightsizing effort.


`Management' means...
Database Administration has typically carried two meanings:

  1. The design, definition, and support of the logical database.

  2. The design, definition, and support of the physical database.

In the age of monolithic mainframe computing, these roles were filled by a single person or staff. Database designs were hierarchical. Relationships between objects were defined in a parent-child structure. Together, this allowed for a centralized computing environment with centralized staff.

As the technology moves from holy glass houses to scattered secular server rooms, the purpose of database administration also changes. Relational databases reign today. This requires design and definition issues to be an integral part of application development. (We expect this to continue with object-oriented technology.) As such, the logical database administration tasks fall within a development group, and the physical database administration tasks belong to an operations/support organization.

The physical
Databases should be distributed to allow critical information to be located as closely to users as possible. This allows the production environment to be more reliable due to the removal of multiple points of failure.

For example, if users work in Boston with their server in Colorado, their data traverses myriad network connections. A network failure in Chicago means transactions will either be queued or re-routed through a less expedient path.

Long-distance client/server database design can also fall prey to a more insidious malady -- network saturation. An overburdened WAN dampens the response time to the user. This, of course, exposes the IT department to accusations of undermining that location's success.

So how do you support distributed databases inexpensively? You got it -- policies. Servers need standardized configuration to allow high DBA-to-server ratios. In the event of database outages or errors, it is key that a DBA can access the machines quickly, navigate through the file system structure and obtain information necessary to take corrective action lickety-split.

If the directory structure for the production machines is not established according to guidelines, problem diagnosis and resolution will take longer than normal. We recommend the following guidelines for database servers:

A DBA's role
A good database administrator goes to sleep thinking about tuning and wakes up with thoughts of performance. Although most performance gains are found in clever and logical application and database design, a crafty DBA can optimize performance by balancing a database across physical resources.

For example, allocating data space and index space across separate drives and controllers can remove processing bottlenecks. But to accomplish this tuning, a DBA needs the tools to collect performance statistics.

There are programs available today that track logical and physical writes and reads on an object by object basis for our Oracle databases. We are evaluating similar products for Sybase. We'll discuss our findings in an upcoming column.

Click on our Sponsors to help Support SunWorld


What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
-Too long
-Just right
-Too short
-Too technical
-Just right
-Not technical enough

[Table of Contents]
Subscribe to SunWorld, it's free!
[Next story]
Sun's Site

[(c) Copyright  Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact

Last modified:

SidebarBack to story

DBA responsibilities

DBMS software support

Database support

Vendor interface

Application support

Security/access support

Request response

SidebarBack to story