- The DBA: Revered or Reviled?
- Why Learn Database Administration?
- The Management Discipline of Database Administration
- Database, Data, and System Administration
- DBA Tasks
- Types of DBAs
- Staffing Considerations
- Multiplatform DBA Issues
- Test and Production
- New Technology and the DBA
- DBA Certification
- The Rest of the Book
- Review
This chapter is from the book
This chapter is from the book
This chapter is from the book
Multiplatform DBA Issues
Managing a multiplatform environment complicates the job of database administration. A whole batch of different problems and issues arise that need to be addressed. The first task is to define the scope of each DBA's job. Does a single DBA administer all of the different DBMSs or does each DBA focus on supporting only one DBMS?
This is a particularly thorny issue. On the one hand, the functionality of a DBMS is strikingly similar regardless of platform and vendor. A DBMS is designed to store, retrieve, and protect data. Programmers, programs, and end users all interact with the DBMS to access and modify data. Administration issues are similar—design, creation, optimization, and so on—though each DBMS implements these items differently. So, the case can be made that a DBA should support multiple DBMSs and databases, regardless of platform or vendor.
On the other hand, each DBMS offers different features, functionality, and technology. Keeping all of the differences and nuances straight is a monumental task. Wouldn't it be better to develop platform-expert DBAs? That way, your Oracle DBAs can focus on learning all there is to know about Oracle, your DB2 DBAs can focus on DB2, and so on.
Every organization will have to make this determination based on their particular mix of DBMSs, features, and DBA talent. If your organization uses one DBMS predominantly, with limited use of others, it may make sense for each DBA to support all of them, regardless of platform or vendor. Sparse usage of a DBMS usually means fewer problems and potentially less usage of its more sophisticated features. By tasking your DBAs to be multi-DBMS and multiplatform, you can ensure that the most skilled DBAs in your shop are available for all database administration issues. If your organization uses many different DBMSs, it is probably wise to create specialist DBAs for the heavily used platforms and perhaps share administration duties for the less frequently used platforms among other DBAs.
When DBA duties are shared, be sure to carefully document the skills and knowledge level of each DBA for each DBMS being supported. Take care to set up an effective and fair on-call rotation that does not unduly burden any particular DBA or group of DBAs. Furthermore, use the organizational structure to promote sharing of database standards and procedures across all supported DBMS environments.
Keep in mind, too, that when multiple DBMSs and platforms are supported, you should consider implementing DBA tools, performance monitors, and scripts that can address multiple platforms. For this reason, DBA tools from third-party vendors are usually better for heterogeneous environments than similar tools offered by the DBMS vendors.
When your organization supports multiple DBMSs, the DBA group should develop guidelines for which DBMS should be used in which situations. These guidelines should not be hard-and-fast rules, but instead should provide guidance for the types of applications and databases best supported by each DBMS. Forcing applications to a given DBMS environment is not a good practice. The guidelines should be used simply to assure best fit of application to DBMS. These guidelines should take into account:
Features of each DBMS
Features and characteristics of the operating system
Networking capabilities of the DBMS and operating system combination
DBMS skills of the application developers
Programming language support
Any other organizational issues and requirements