Database Administrator

Background and Job Description Database Administrator (DBA) duties vary depending on the organization of which the job is a part. Extremely large companies usually have a number of DBAs working in several business units, and most of these people use different database management systems to do their jobs. Large government, educational or financial institutions with a need to store and retrieve hundreds of thousands of records for many employees have DBAs trained to use the central mainframe computer. That system will undoubtedly use DB2, Oracle, Ingress or other large relational database software. Other departments in such organizations may use Paradox, Visual FoxPro, or Access running on networked workstations or servers. In many cases company employees have PCs at their workstations allowing them to login to the mainframe as if the PC were actually a mainframe terminal (called emulation).

“The experienced database administrator is an adept, responsible, and ever-alert watchdog of the system used for reporting by the company, department, division or business unit. ”
Because long-time workers at such companies are familiar with the mainframe (or legacy system), and because huge systems hold so much data, the terminals are used for them to sign-up for training, meetings, etc. Reporting to senior management, however, is generally produced from the business unit servers or workstations that run smaller database management systems. The database administrator in the business unit must "download" the mainframe data, "scrub" it (remove any formatting), and finally "upload" the data into the smaller server or workstation database software. Company departments vary as to the timing for this process. Because it can be time consuming and often deals with large chunks of data, updates are usually done at "off-peak" times of the business day. The busiest times for mainframe operations are usually between the hours of 10:00 a.m. and 4:00 p.m. System back-up (writing data files to magnetic tape) operations commence sometime after 10:00 p.m. For that reason, the updating process from the mainframe to say an Access database is planned early in the morning (before 9:00 a.m.) or late in the day (after 5:00 p.m.). Microsoft Access is a popular database management system used in businesses today because reports can be easily custom designed to suit any need or management style. Crystal Reports (owned by Seagate, Inc.) is another reporting system that can use Access data. Some companies with multiple "platforms" (e.g., mainframes, mini-computers, many types of microcomputer networks) using various operating systems may use "middleware." Middleware is software designed to retrieve massive amounts of data from central mainframes, "scrub" all formatting, and then pass the data on to the system or database server for the business unit. This crucial middle step allows for a relatively "quick" update into the business unit database for reporting. These middle pieces of software can be complex to use. Training for use by database administrators may be offered by companies attempting to guarantee smooth daily operations. Assuming the business unit database administrator knows the necessary pieces of software used in the regular update procedure, the next and largest portion of the job is reporting to management in various formats. Depending upon the time of year, quarter, or scheduling of company-wide events, reports may number from one to twenty! Often senior management requires that colorful graphs be produced from extracted data to "advertise" the hard work of the unit in charge of the data. In other cases the extracted data may be used to determine employee skill levels, promotion worthiness, salary increase determinations and other vital details to the company and each worker within it. This kind of "mission critical" information is most often a required "deliverable" by the DBA at fiscal or calendar year-end. Obviously, this time of the year is the wrong time to discover that previous updates were not successful! The experienced database administrator is an adept, responsible, and ever-alert watchdog of the system used for reporting by the company, department, division or business unit.

Database Administrator

Typical Situation Unfortunately, one situation that can occur more often than planned, or more accurately, more than it should, is when the database does not update despite the careful steps taken or the time involved in trying to accomplish a successful update. Bad news usually comes from a co-worker who emails the DBA or otherwise (often angrily) informs the administrator that the database seems filled with "old" information. This precipitates a long, tedious search for reasons why or how the network reported a successful "set" of updates over a period of time, but now that report (or reports!) has been discovered to be in error. The first step is to investigate the problem to learn the true "age" of the data. Next, the DBA would attempt to update a recent set of data to determine what may have occurred. It could have been a malfunction that day, or the evening the update was attempted. Assuming the situation does not improve by this upload, the next step is to contact the network administrator about possible server malfunctions, changes in standard record settings, or other changes that might affect the upload of data. Occasionally, the network server record lock settings were changed to "disallow" any upload to a network server over a certain limit. While such settings are positive virus-prohibiting security precautions, they can play havoc with the conduct of legitimate business. If the DBA is lucky, or has positive karma due for collection, all that may be required is for the network administrator to reset the record lock setting at a higher level. Updates can then be repeated and will result in current data within the business unit database for purposes of management reporting. However, on a bad day, the DBA may learn from the network administrator that the server was or is malfunctioning, or worse, crashed at the precise time of the attempted update. Ah well! Life presents these situations to develop "character," if not a colorful vocabulary. In this situation the investigation must retrace the steps of data accumulation to determine the validity of the dataset for backup and experimental upload (network administrators at ringside) to watch for any type of malfunction. Because everyone is watching, updates usually occur without incident and life will continueeven for the DBA-although s/he has aged more than would have otherwise been the case.