My story might be like that of many Database Administrators. I started off in database development. I have not met too many DBAs that have started right out of school as a DBA, and it seemed normal for the DBA to come from development or infrastructure teams.
Database administration is not necessarily a first technology job because of the vast knowledge that is needed about databases, infrastructure, development, and even the business. Agreed that there are also beginning level DBAs that are part of the team or mentored by someone, and now with some of the technology advancements and features of the database, it is possible to see people starting on this path. The other question is if the DBA position was chosen by you, or did the position pick you? The accidental DBA or volunteered DBA probably received the job because the position was not able to be filled and with some additional training, you found yourself in that role.
It seemed like a good opportunity, especially to work with the various infrastructure and business teams. This is a major reason for my decision to move over into that role. Not only were you a significant part of many applications, but the database continued to advance and develop new features to support those demands. It was an environment that provided challenges, change, and constant learning. Relationships needed to be developed with the developers and the business to be able to support their needs. The infrastructure teams became our allies as we built systems to install the databases. Being in this role allowed me to learn about many areas in technology and refine what was needed for business requirements.
The skill set of the people to manage the databases and help teams get business data in and out quickly has been important in business. However, there are discussions with databases and infrastructure going to the cloud about whether DBAs are needed. Are we accidentally going to become Cloud DBAs? Or is there a different path where these skills are needed in an area that will provide different opportunities? This is not the first time that DBAs have had this discussion about transitioning, and if the role was even needed. It is also not the last time, but the goal here is to give direction on what the world of databases will bring as well as the surrounding environments of security, data integrations, and cloud. A view of the current state of the DBA will help us understand this transition.
The DBA job is not always clearly defined. Do the databases support the application development? Are they really part of the infrastructure? What about all the moving components from database options to just backups, and where are the lines between operating system to application code? There are some definite gray areas when it comes to defining what DBAs do. It might not always be even understood between teams. I believe that it might even be blurrier in the future. There has also been a shift in different database platforms too because of how they appear to be easier to install and build up and tear down in a development environment. Notice I did say appeared to be easier. This is critical in understanding what can be provided by the database and making sure that the right database is available for the job. DBAs can assist in these areas, but I will discuss that more in a later chapter.
I remember first supporting table changes and migrations for the development teams. I was also responsible for backups because how could I make those changes without the proper backups first. Other times there were just the system tasks of backups, restores, replication, server builds, and installations. There were also other components that played a part to that with high availability and disaster recovery. On the other side there are components for performance and tuning with partitioning and material or snapshot views.
Where Do DBAs Fit?
Organizational placement of the DBA probably gives the first clues as to what the tasks are for the DBA. Placement in the organization can show whether a DBA is going to be more system and infrastructure support, or work closely with the application teams to build and develop applications. DBAs can also be found on data services teams that can provide more insight around data management than around the database itself.
The organizational chart in Figure 1-1 shows that there are two branches that DBAs can be found under. The CIO branch contains database teams with the infrastructure teams. This doesn’t necessarily mean that all they will do was the infrastructure work, but where they are organized as part of the enterprise.
The CTO area should have more of the application direction and will find that the DBA teams work more with the developers and manage their teams with the database teams. DBAs can find themselves in groups or as an individual in these teams. But they seem to have been organized by tasks that they normally perform.
Figure 1-1 Organizational chart to find DBA teams
Along with the thought that it depends on their tasks, a data services team that functions as the DBA team can act as if they are under the Chief Data Officer (CDO) . This is even a fairly new branch of enterprise and not all companies will even have this group. They tend to be your data management, data analytics, data integrations, and basically anything data focused. They sound like a perfect group to partner with as the guardians of the data. Another branch that is getting even more popular is the Chief Security Officer (CSO) . The DBAs might be in the administration role or in the security engineering role under the CSO to make sure the databases are secure.
The newest group to join in as to where DBAs can fit in an organization is the Chief Cloud Officer (CCO) . The databases are going be part of the cloud solution, and this would make sense as they are either supporting the cloud infrastructure or the data that is in the cloud. The organization might be like that shown in Figure 1-2.
Figure 1-2 New Organizational chart to find DBA teams
The following chapters will talk about the different opportunities for a DBA to transition into several of these roles. But to transition into a different branch of the organization as a DBA or a database engineer takes justification. Transitioning varies by organization and what structures they already have in place. Even without some of the services or groups, transitioning doesn’t make it impossible to start a group, just a little more creativity is required. The point is to be in a group that makes it easy to communicate to the teams you need to work with and makes it clear what role you are playing. It would not make too much sense to be in the Data Management group if all you do are database installs. The different alignment will be based on how the group can get the best requirements, communication, and delivery of the databases.
As you can see from the different alignment of the DBAs, it might have made sense to have a centralized group under the CIO. But now with the diversification of the DBAs with skills and focus areas, it seems reasonable that there will be smaller groups of DBAs throughout the enterprise. The question will be whether they are still called DBAs or have transformed into another title. Movement in this direction demonstrates understanding of the business needs and how they are using data. It allows you to be a valuable part of the team to drive solutions and utilize the data assets.
After seeing where to find the DBA teams, let’s look at the different types of DBAs with their tasks so that we can move forward with the future transformation. And we can dive into what changes there are for the DBA from the current focus because of the databases and infrastructure we deal with, and a future state with database as service, as well as other services – cloud and even more data coming our way.
System DBAs
The team that is called in to increase the amount of storage to the database, or to restore the database or probably most importantly to patch and upgrade the database is most likely made up of system DBAs. System DBAs have the main task of taking care of the database infrastructure and the actual database instance. The configurations include database options, parameters, and features of the database.
With Oracle 12c the system DBAs are going to be taking care of the container database (CDB) . They will be creating the pluggable databases (PDB) and performing cloning and migrations of the pluggables as necessary. Depending on if there is a security team handing access, system DBAs will be adding users for the PDBs or at least monitoring the privileges. The storage will be part of creating the PDB and making sure that there is proper capacity for the PDBs in the CDB. The development of Oracle 12c naturally separates out the tasks of the system DBA from the application DBAs. Microsoft SQL Server also provides this separation from the database instance and the user databases.
Note
igh Availability options can split up System DBAs even more in managing cluster services, Automatic Storage Management (ASM) instances and data guard management. It depends on the size of the environment, but these roles allow for separation of duties or still part of the system DBA team.
As we look through areas that the system DBAs support, keep in mind the skills and knowledge it takes to support tasks in these areas. Skills are going to be discussed more in the next chapter.
Infrastructure. As part of their job function system, DBAs are performing the database creation and software maintenance. They have access to the database servers and managing the processes, file systems, and software binaries for the databases. They will be looking at server and network performance and verifying that the database processes are all working as expected by reviewing the alert and system logs.
Storage. Planning of capacity includes server resources and certainly storage. With ASM, management of disks groups and allocations to the databases and tablespaces can be part of an ASM administrator role, but more likely this falls into the skills of the system DBA.
High Availability. Making sure that the databases are supporting a 24x7 environment means that cluster services and Real Application Clusters (RAC) are part of the installation, configuration, and patching jobs. As the environment scales out provisioning servers and maintaining the cluster and performance, there are tasks that need to be addressed. Data Guard and standby servers are part of the maximum availability architecture and become the responsibility of the system DBA.
Manageability. Monitoring of the database servers and verifying that all the components of the databases are available are under management of the systems. Even after installs, the work for patching, upgrades, monitoring activity, and performance are needed to ensure a stable environment.
Recovery. It is not enough to just back up databases, but to plan and ensure that databases can be restored. There are other features of the database that allow for this besides backup and restore, such as flashback and failover. Recovery testing and planning for failover are included in these responsibilities.
There are, of course, tools that can assist in these areas and we will discuss the future state of the databases and the possibility of managing many of the databases as one and simplify these processes. Tools and standards are essential for the system DBAs, and they need to understand more than just the database, as they also work on the OS, networking, and storage.
The system DBAs support many database servers and provide a highly available and stable database system. They have the skills and tasks to install, deploy, and maintain these environments and provide normal maintenance tasks, storage allocations, and backups.
Application DBAs
Application DBAs are going to understand more of the application processes and data to support the business and developers. Instead of looking at the system processes and the availability of the database, the focus of application DBA is on database objects, data flows, and application performance.
PDBs are going to be the environment that the application DBAs find themselves in because the user and application objects and activity will be in PDBs. The application DBA does not work in isolation, and instead needs to work closely with system DBAs and application development teams.
Data modeling is another role that these DBAs will have as they assist with the application development. Some of these roles can be separated out into different teams and functions depending on the size of the organization and sensitivity of the environment. For example:
Database Objects. Modeling of the tables and database design for the application and assisting in writing scripts for the application code. The objects, including tables and procedures, can be developed to be part of the unit testing of the application. Planning of indexes and views can add value to the development teams.
Performance Tuning. Tuning the database code and implementing solutions for performance issues are responsibilities of the application DBAs. Here again, working with the system DBAs to coordinate activity of the database with application and database code is very useful for troubleshooting. There are skills here of working through issues, benchmarking, and understanding the workings of the database. Recommendations for indexes, database options, and parameters come out of tuning practices.
New Features. Besides the new features on the server side, normally there are database code and object enhancements. In understanding the application and what they are executing, the new features can be matched up to reduce development time or provide other benefits with performance. Constant learning with the new features and working with developers to understand gaps, problem areas, and requirements is one of the many challenges for the application DBA.
Migrations. Moving data from production to test for development might be a system task or for the application DBA to make sure that data is masked properly and refreshes happen regularly. Another migration is object code to production. This might be an operations task, but getting the code ready, reviewed, and tested is for the application DBA to handle.
Data Management. Data movement in production environments with data APIs to other systems is part of data management. Data workflows and how to get the needed data from one database to another is where the application DBAs have the knowledge of the different environments to provide the right way to move data or verify that there are data APIs available. With data management, there is more work with the CDO group or even other business teams.
Note
BAs are not normally the owners of data unless it is data about the databases. They are considered the guardians of the data. They can assist the other teams in tagging, classifying, and performing data quality steps but would not be the first group for data definitions and tying it back to the business.
With skills in data modeling and movement, the application DBAs work closely with the development and application teams to ensure the data is available and protected. All types of DBAs must continue to work with each other, communicate well with other teams, and continually learn about new features to implement in the databases.
Automation DBAs
Isn’t everyone supposed to be looking at automating processes and reducing manual efforts? Well, yes, they are. However, there might be tasks being performed as a one off to see if it works as needed, and then it can be handed off to the automation DBAs to include it in the processes. I would expect that these DBAs are working heavily in Oracle Enterprise Manager or Oracle Cloud Manager . They would have a scheduler tool to coordinate jobs and writing the wrappers around code that will automate what used to be one-off tasks or manual ones.
Automation DBAs might be part of one of the other teams, but this is a type of DBA that will look to make sure that the jobs are running as scheduled and implement processes around the maintenance and data tasks. They work to keep everything a smoothly as possible and that there is little manual intervention in production. Taking tasks from development and automating it would be the responsibility of this type of DBA. This can be the team that gets handed code from system and application DBAs to manage and automate. Verifying that code is running as expected and the jobs are executing would be in reports reviewed and audited from the automation DBAs. In separating this out, the separation of duties allows for handoffs from development to production and reduces the manual issues that can occur.
Scheduling. A schedule might be a simple thing, but realize that there are maintenance, data, ETL, and application jobs that might need to be coordinated. The scheduling of these tasks can be tricky so that they do not collide or slow down any of the production environments.
Code Automation. An automation DBA can have code that will wrap around tasks for automation so they can just plug in jobs. They can review other code to make sure the jobs are doing what they are supposed to do. They are looking to automate processes and workflows whereever possible. Automation of reporting should be under their responsibilities too.
Monitoring. Monitoring the execution and errors on the databases, the automation DBAs can report on timing and that the code is being maintained properly. Also in monitoring, they can find other opportunities for processes and work with the other teams to make sure that these tasks get rolled up into the automation.
The automation DBA can help enforce standards with processes, code, and database structures because automation is simpler if the standards are dependable. The skills here are to understand what processes can be automated and to take requirements from others to plug into the automation tasks. The understanding of the database activity and being able to write and maintain database code allow them to complete their responsibilities around automation.
Next
There might be other types of DBAs that have been developed for other organizations based on demand of tasks and types of applications they might be running. These are typical types of DBAs that are part of the current state of the environment. A couple of times I hinted to what is coming next or to pay attention to the skills that are being developed while working as one of these types of DBAs. The question is what is coming next, because there needs to be some sort of transformation since databases are obviously changing in where they are installed, how they are being managed, and an overall technology shift to service like and cloud systems.
The DBA must take the skills from these typical areas of focus and know that the expertise developed here is vital to continuing to support the databases even though the landscape of how and where it is going will be changing, if it has not already.
Conclusion
Before we start the transformation process, let’s look at the skills we can pull out of the current state DBAs as well as some other important skills and knowledge that will allow us to move forward in a world of cloud computing and automation.