Calling all technology people who like to have control over the environment. That could be most us, especially if we are DBAs. It is difficult to confess that you became a DBA because you like to have control over the data and who, how, when, where, and what happens to the data. I will speak for myself here, but you are welcome to join me in that statement if you so desire. Anyhow, some of the best skill sets can also be a weakness in dealing with a transitioning role, which we will work through in Chapters 8 and 9. It is difficult to give up or perceive that we are giving up something that we enjoy and feel is a very valuable set of skills. The great news is that most of the skills and knowledge we have as DBAs can help us become even better DBAs and be used as leverage to move in a different direction.
As we went through the types of DBAs in the previous chapter, I hope you were thinking about some of the skills that are needed in these different roles as they are going to be our baseline skill set that we have as DBAs. Depending on the opportunities, skills can always be developed and improved. And with some of actions and activities that we do, the syntax is not the skill that is being sought after. It is the skill to google the right version of Oracle or the database to get the correct syntax that is important.
Relationship building is a must for allowing DBAs to be able to work with all of the various teams. This is not always something easy to accomplish as there are challenges with communication, resources, and different priorities between the teams. It is a skill that can be mastered with practice and learning effective communication.
We can break down these skills into the technical skills that are still required for any changes and transformations, as well as the soft skills that absolutely must come with the changes.
The technical skills are going to vary to go along with the types of DBAs. Having spent time in the different groups will continue to round out the skill set. Having worked with the application teams gives more of an application understanding and provides coding opportunities. The technical skills that are needed to administer databases are different than coding full applications, but there is quite a bit of code that can be database specific. The DBA is not necessarily the one writing the application, again pointing back to the separation of duties, but to understand how to read through and interpret code helps with working on database development.
There are database platform-specific skills such as Data Guard and RAC and even some performance tuning. Even different versions of the database can require additional knowledge, such as CDBs and PDBs. Of course, there are database core skills, just changes in syntax, which are needed for any database: backup and recovery, object creation and modification, and monitoring. Patching and upgrading databases follows similar processes, plans, tests, backups, and executes the plan. Table 2-1 shows a list of the core DBA skills versus Oracle-specific skills.
Table 2-1 Technical skills Core vs. Oracle
Different syntax and possible options, but backup and recovery needed for any database
Data movement and extracting data and inputting data
Database Maintenance plans and schedules
Analyzing indexes, validating objects
Always should read the files with the installation
Notes to apply patches
Need to understand some specific database platform rules and query plans to implement solution but process to tune the database similar
Know where the error logs, alert, and system logs are to provide information
Disk groups, ASM instances, and tablespaces
Connections to the database and working on Windows and Linux/Unix platforms
Active Data Guard
Need to be able to model objects. Just indexes, tables, and coding features are different
Not just parameters and indexes but tuning the query to perform well
Stored procedures, triggers, views
Oracle has PL/SQL and where you might use a trigger in Oracle or function, it might be a procedure in another platform
This is general here, but it will be expanded in Chapter 6.
Monitor activity, performance
This is not a complete list for all the databases, but it is a significant list providing good detail about the tasks and knowledge that would be needed. Most of these are core database skills with differences in code or options that would be available.
Testing and Implementation
A technical skill that might be overlooked is testing and implementing unit testing. Developing test plans is part of the development code for the procedures, tables, and validation of the processes. There is skill in integrating the database testing with the application code. Plugging in code and details about the objects will get you validation before going to production.
Installs and Upgrades
Technical skills have been what you have been practicing as a DBA. The technical side of performance tuning and implementing high availability systems might be the coding areas that you really enjoy doing. It is good to know a skill that will always be needed. The DBAs that really enjoy installs and upgrades is in a good position because with changes to the cloud, these skills will need to be transferred over also. Even the Oracle has been simplifying the install and patching processes. They have announced a couple of times over the years with releases that the database is easier to set up, configure, and manage, but the technical skills of the workings of the database, and how to use the features for other processes are the technical skills to possess.
DBAs , whether we wanted to or not, have developed soft skills along the way. We have had to communicate with other teams, plan very large environments, and make the connections between the business all the way down to the OS and servers. There are not going to be opportunities to work in isolation. As a DBA, there are opportunities to lead in changes and development processes. Even with security, the DBAs should be educating and leading with practices for protecting the data in the database systems.
The soft skills are something that can be worked on, and it is a constant personal growth opportunity. As our soft skills improve, it is not just our work lives that benefit but also our personal lives outside the working hours. An SQL query may not matter to our family but better communication does. Volunteering for the user community and other organizations provides a safe environment to practice these skills. Sharing our technical skills in written or presentation format keeps the growth going.
Communication means more than just talking with others. This requires understanding the audience and detailing with issues, requirements, and expectations. Agreeing with and planning and then turning around and ignoring the priorities is very poor communication. There is a reason why I list communication first: because the better we can communicate what we do and the work we can do, the easier it will be for us to be in a position where we enjoy working, feel challenged, and know that we are adding value because of the communication we give and receive.
In the world of emails and Instant Messaging or text, we have developed another way to communicate that is not as formal, and we can pull in others that may or may not be needed in the conversation. There are already several books written on communication, business communication, even how disruptive miscommunication can be. Any time spent improving how we communicate with each other, including writing effective emails is well worth the time.
There are a couple of areas in which I feel are extremely important to have great communication skills.
Develop communication plans that can be used as part of any change or project. The communication plan would include how to get the audience and how to communicate so that the details are specifically stated. The plan should include what the reason or issues are for the communication, why it is being stated now, what the call to action is, and any other expectations or details that belong with the message being delivered. A standard template is usually the best way to do this because it makes sure that all the pieces of the communication are included and it is recognizable by others.
Understand the audience to provide the right details. A more technical email for other engineers and more high level and key points for management (they can always ask questions if they want some technical details) would be appropriate. This can also apply to sending emails back and forth in which the audience may not have been part of other discussions or meetings and questions should be asked to understand what they need or what they are asking so that details do not get missed.
Communicate an agenda for a meeting. It is very easy to get off track or not know what the meeting is for, so the agenda helps and allows others to be prepared. Sending out notes afterwards captures the highlights, which makes it easier to track; fill in others not attending; and believe it or not captures what the time was spent doing, which is useful for timekeeping, year-end review, and management briefs.
Notify of changes and project milestones. There is probably a change process, but there might be additional information to educate and deliver other meaningful information to the developers and applications. This should be part of the communication plan, but it might be going to smaller audience first or even management as this is being decided upon.
To show the importance of the communication, three out of the next five skills depend on it. This is a skill that you probably don’t know that you have been using, but examine how you are communicating, look for ways that it is currently being used, as it is a skill to bring with in any transition.
As DBAs, we have read a ton of documentation or at least, more than we can count, the release notes. It is a skill that some of us find easier than others to write but we all do it in some fashion. The details of what is being executed, how and why, in documentation format for others to understand the details of the system for others to support. We create runbooks, detailed information about our set of scripts, and the databases with configurations.
DBAs tend to document the owners of the databases and application owners as we use these in communications about the environment. Chances are that most of these details are in a database but we can pull reports and use the information for other processes.
Documentation is normally created to outline steps for installations, upgrades, and health checklists. Test plans are also documented with plenty of test cases to have the successful upgrades and installs. Needing to know how to restore a database, the DBA of course has documentation of scripts and steps, including the logs from the last practice restore.
Data flows and database objects line our walls as we work to understand the data model and internalize all the intricacies of the application and how they are using the data. This information equips us to provide the optimal support for the database system.
As data flows become more complex with the cloud and other integrations, this type of documentation along with processes will be needed in future environments.
Relationship Building (Interpersonal Skills)
The good news is that we are dependent on working with others because the databases need servers, network, and other infrastructure. The data also comes from the business and application teams. It does also make it challenging to have to coordinate and work peacefully with these teams, but the DBA teams seem to make it happen.
Communication is key to building these relationships. I find it easier when expectations are set properly and any changes are communicated as quickly as possible. Other teams respect that and start to work closely with the DBAs because they get honest answers and details as things happen.
DBA teams can assist in making connections with other teams and serve as a liaison either to application teams or infrastructure teams. This also comes from understanding what it takes to keep the system running along with the business requirements and SLAs. This knowledge can translate into reviewing SLAs and requirements for cloud infrastructure too. And it provides the needed education for the business to validate they are meeting their demands in the cloud architecture.
The DBA might not appear as one to adapt to new environments because we have carried a toolset along with us for many years. However, the toolset can and in many cases has been updated along the way to account for new features and changes in how the database performs. As we went through the technical skills, the core items for databases has not changed much over the years, but how to effectively run those tasks and adapt to the new features for completion of these tasks.
Many of the manageability options of the database have become part of the internals of the systems, which have been automated, but in understanding the workings of the environment we are looking for the next issue. There have been many times that a script or monitoring has found something new to look for, and we add that to our arsenal.
We are already not the same DBAs from 10 years ago. We have adapted to new OS, new database platforms, and virtualization. These shifts to our environments have developed our abilities to shift and adapt to how we configure and administer the databases, even include other platforms in the data flows and integrations .
The continuous learning that is part of the excitement of being a DBA has encouraged us to move along with new options and add this variety in the tool belt. Even with some of the old scripts we remember how the processes have functioned and now can adjust and keep moving forward with the small and major shifts.
Welcome to control freaks anonymous, where we have organizational skills . This is a skill that most DBAs possess and are very proud of. Nothing wrong with that, especially since it is absolutely needed to manage all the databases, processes, activities, and users.
We stay organized to make sure that gaps are being covered and that steps are being followed to ensure repeatable processes. The organized steps can be tested, repeated, and reused for other areas too. It is rare that a DBA really has a one-off process, because chances are that it will need to be used again. It could be administration tasks or performance-tuning steps, but repeatable processes are typical for the databases. Organization is used for this because it follows a specific flow; you cannot backup a database after starting the upgrade. It’s too late at that time to restore. Having a couple of backup or rollback plans is normal for the DBA.
Being process oriented and organized allows you to think through the details and then execute them. In reviewing architecture designs and discussing different infrastructure, DBAs can ask several great questions to help get to gaps or figure out what is missing in a process to make it work. These questions come from the understanding of the processes and being organized to know what the order in steps should be. Organizing questions to evaluate new environments, plan cloud migrations, and prepare data integrations are future skills for the DBA, which is a soft skill that we are already possess.
Leadership is not about a position, because we are not all DBA managers or team leads. We have databases that we manage and teams that we work with. We lead with our skills and knowledge in that we contribute to provide database systems that support the enterprise.
We are proactive or decide to work toward that goal. We lead in this way instead of being reactive, even if it can be difficult at times. Modifying what we do to work in a way for standards and being able to provide answers before being asked is a goal and can lead in the right direction. There are opportunities with future direction to lead other DBAs and prepare for moving databases to the cloud or other services. Understanding the benefits of these moves and providing explanations to other teams will lead the changes. The transition to another type of DBA is using these skills and will challenge us to grow them.
We have presented information about new features, storage capacity, and hardware choices. Not only are these communication skills, but they demonstrate how we lead in our area. Without the discussion about hardware and database improvements, we would be falling behind the curve. We lead in the areas of making our environments better and current to provide what is needed in the enterprise. These are details that allow us to talk with management to be proactive with our environments.
As DBAs, we are passionate about databases. We are driven by goals to have a secure, stable, highly available database, and we are protective of the system to keep it tuned as we have planned. As leaders, we should be sharing this with others, mentoring other administrators and developers to understand and appreciate the databases. This passion can carry over into other areas that we are serving and allows us to lead with example as we approach the new database world.
In building teams we have DBAs exhibit leadership. The team-building effort flows over into what happens in the database. It inspires us to learn and become even better in our talents and craft, and pass it along to others. Let’s look at a few leadership qualities in building these teams that will be needed in transition:
Mentor what inspires us. We are passionate and inspired by people around us in the database profession. Share that passion. Share the reasons for enjoying this profession. Explain why and use that to inspire others.
Team building. Putting together a team is not easy, and they need to work together to achieve the goals. Building a team means to be using the different talents of the individuals to work for the benefit of the team. It will make a stronger team. In building a team, it is also worth looking into what happens with the team when things change. If goals change or the direction of the project and system, the team needs to work to adapt and continue along the new path.
Team goals. Defining the goals might be related to the current projects and activities or what the team needs to become for the environment. Individuals might have goals to continue to learn, advance in their careers, and be able to add value in the team. Team goals need to include all of the individual members, and it might take working with each one to understand the goals and where they fit into the picture. The goals of the team should be apparent and discussed how to obtain. Goals to shift the database environment to the cloud or migrate to different a platform should at least be planned as a team; even if not everyone agrees with the goal at first, they can agree with the plan to achieve it.
Developing skills. We have been discussing technical skills and soft skills, and leading will not only be developing these skills in yourself but also helping others to see what skills need attention. There is always something more to learn and work on in these areas. In teaching and mentoring others, we actually learn more.
Technical and soft skills have been developed over the years as a DBA. The technical skills have allowed us to support and maintain the mission-critical database environment effectively. They gave us the understanding of the internals and how the database applications function. We have learned from application owners and developers the requirements and how to implement them. The communication, leadership, and other soft skills are going to be critical for moving forward, assessing the direction to plan for, and making the change.