DBA Job Classifications in Font

Creation Code 3 of 9 in Font DBA Job Classifications

Given the diverse nature of business, a DBA s job description is not exactly the same in all organizations. There are several variations in the job s classification and duties across organizations. In a small firm, a single DBA might be the UNIX or Windows administrator and the network administrator as well as the Oracle DBA, with all job functions rolled into one. A large company might have a dozen or more Oracle DBAs, each in charge of a certain database or a certain set of tasks. Sometimes you ll hear the terms production DBA and development (or logical ) DBA. Production DBA refers to database administrators in charge of production databases. Because a production database is already in production (meaning it is already serving the business functions), such DBAs aren t required to have design or other such developmental skills. DBAs who are involved in the preproduction design and development of databases are usually called development or logical DBAs. Ideally, you should strive to acquire the relevant skill sets for both development and production administration, but reality demands that you usually are doing more of one thing than the other at any given time. In general, large establishments usually have a number of DBAs and can afford to assign specialized tasks to their personnel. If you work for a small organization, chances are you ll be doing a little bit of everything. Individual preference, the availability of financial and technical resources, and the necessary skill sets determine whether a DBA is doing production or development work. A DBA who comes up from the developer ranks or who s happiest coding is usually more likely to be a development or logical DBA. This same person also may not really want to carry a pager day and night and be woken up in the dead of night to perform a database recovery. On the other hand, a person who likes to do production work and to work with business analysts to understand their needs is less likely to enjoy programming in SQL or in any other language. Although all of the preceding is true, both development and production DBAs are well advised to cross-train and learn aspects of the other side of Oracle database administration. Too often, people who characterize themselves as production DBAs do not do much beyond performing backups and restores and implementing the physical layout of databases. Similarly, development DBAs, due to their preference for the programming and design aspects of the job, may not be fully cognizant of the operational aspects of database management, such as storage and memory requirements.

In many organizations, you will be working with different types of databases daily, and thus with different types of data and management requirements. You may find yourself working on simple SQL queries with users and simultaneously wrestling with decision-support systems for management. Databases perform a variety of functions, but you can group all of those functions into two broad categories: online transaction processing (OLTP) and decision-support systems (DSSs; sometimes also called online analytical processing, or OLAP). Let s take a quick look at some of the basic classifications of Oracle databases.

Online transaction processing databases are the bread and butter of most consumer- and supplieroriented databases. This category includes order entry, billing, customer, supplier, and supply-chain databases. These databases are characterized by heavy transaction volume and a need to be online continuously, which today (given the use of the Internet to access such systems) means 24/7/365 availability, short maintenance intervals, and low tolerance for breakdowns in the system. Decision-support systems range from small databases to large data warehouses. These are typically not 24/7 operations, and they can easily manage with regularly scheduled downtime and maintenance windows. The extremely large size of some of these data warehouses necessitates the use of special techniques both to load and to use the data. There isn t a whole lot of difference between the administration of a DSS-oriented data warehouse and a transaction-oriented OLTP system from the DBA s perspective. The backup and recovery methodology is essentially the same, and database security and other related issues are also very similar. The big difference between the two types of databases occurs at the design and implementation stages. DSS systems usually involve a different optimization strategy for queries and different physical storage strategies. Oracle Database 11g provides you with the choice of implementing an OLTP database or a DSS database using the same database server software. Performance design considerations that may work well with one type of database may be entirely inappropriate for another type of database. For example, a large number of indexes can help you query a typical data warehouse efficiently while you are getting some reports out of that database. If you have the same number of indexes on a live OLTP system with a large number of concurrent users, you may see a substantial slowing down of the database, because the many updates, inserts, and deletes on the OLTP system require more work on the part of the database.