Posted by This blog post was inspired by a DM on Twitter. A follower asked me for ideas on how to best interact with developers and how much expertise to give away. This is a big question with a vast array of correct answers. It is also a subject on which I have a lot of opinions that are wholly mine and do not belong to any employer, past or present.
Many Roles
While the DB2 LUW DBA may sometimes seem like a narrow specialty, there are actually a vast array of roles a DB2 DBA can play. This is true not just of the consultant, but also for in-house DBAs
The Database Expert / Architect
There are a lot of questions to answer when building a new DB2 system, even if the system is in support of a fully vended app. There are even more questions that should be asked at this point. This can be a fun role, but a challenging one – what licensing or edition is best? How long will it really take to build that system? How many test systems should there be? Should BLU be used? What encryption, compression, and security decisions need to be made, and by who? What are the high availability and disaster recovery questions that need to be asked and answered? This role really requires a senior person who doesn’t just answer the questions asked in a detailed way, but knows what questions to ask in return and what pitfalls to avoid.
Even once a system is up and running well, occasionally things go wrong, and it can be invaluable to have a database expert to dig in and help find the solution or the smoking gun.
DBA Support
Physical DB2 Support
Physical DB2 support is where I started my career. Larger companies, especially, sometimes divide up DBAs into physical and logical. The physical or systems DBAs are responsible for DB2 fixpacks and upgrades, backup and recovery, regular runstats and reorgs, managing storage and most aspects of database and RDBMS configuration. These DBAs may be strictly production, or may play roles in pre-production environments as well. Depending on the division of labor, they may implement some things prepared by the logical DBAs in the production environment.
The frustrating thing about this role is the definite lines on what you can and cannot do to help. You may be called in to work on performance issues, but many performance issues are logical ones that you may not be able to assist with. This role is great, though, for starting in the DB2 DBA world because there are definite answers and often processes in place that make it so you can learn and expand your knowledge, particularly if working on a team with other DB2 DBAs.
Logical DB2 Support
This role may be considered a DBA or may be considered an application developer. A logical DBA will often translate designs and details provided by developers into physical objects in a database. They create objects. They write SQL, often a lot of it. They may write stored procedures, functions, and triggers. Often they do not have access to production, but do work in various test environments and hand scripts off to either a physical DBA or an operations person for actual implementation in production.
Physical & Logical Support
In many medium and smaller organizations, the DBA plays a hybrid logical/physical role, and some of the logical DBA tasks are done by developers. This can be a satisfying role, as one can develop a real sense of ownership over the databases in their control. It also requires a lot of ability to talk with and work well with developers. This is most commonly what is meant by “DBA”.
Supporting Application Developers
In any DBA role, it is important to be able to integrate with other people. You will often be working with System Administrators, application specialists, developers, project managers and others. As a DBA, there is a careful balance to strike here. On one hand, you are the gate keeper, charged with keeping STUPID from getting into your database. On the other hand, your job includes making the database function as a seamless part of the ecosystem it supports.
Working with developers is often a daily occurrence. You will be educating them. If you’re lucky, your developers are curious and recognize you as the expert in DB2 and SQL. If you’re incredibly lucky, they’re thinking about database performance from the first hours of development and asking you questions to figure out not just how to make an application work, but how to make it scale both inside and outside of the database. If you get the latter, answer their questions to the best of your ability and prioritize their questions whenever possible – it will make your life easier in the long run.
Often you’re behind the 8-ball on performance. The application has already been written, and it may be your role to point out queries or structural issues that prevent the application getting full performance out of a database. Opportunities to ask these questions often come in the form of the dreaded statement “the database is slow!” Point your developers to http://use-the-index-luke.com/ Markus Winand speaks developer, and has a great approach to tuning developers for optimal database performance.
When the database is blamed for a performance problem, your role is not over once you have verified it is not a bug or DB2 system issue. Your role becomes finding the clues within the database that may help developers solve the real problem. Investigating locking, indexing, parsing through the DB2 diagnostic log – all of these can be done to support your developers.
Take every opportunity to teach developers about DB2 and databases – this time is rarely wasted.
Teacher
Any person with more than two weeks of experience with DB2 has lessons to share. With developers, certainly, but also with every individual you work with. Learn from others around you and take the opportunities to teach as well. As a consultant, there is sometimes a question: What if I teach my client too much and they don’t need me anymore? I rarely worry about this question. I find that the people I have taught as much as possible often come back for more expert discussion or support. They know where to go, and they know I won’t take an approach of guarding my knowledge.
If you have a client with the specific goal of learning from you and then no longer needing your services, any of the following may happen:
- That person may end up with too much DB2 work and still need your help.
- That person may be pulled in another direction and need you to handle the DB2 work.
- That person may not have the time, temperament, or detail orientation to build their skills to the level needed.
- That person may leave their current employer and need help at their new employer.
- That person may leave their current employer and their current employer may need your help to continue DB2 support.
In many years of consulting work, I have not once regretted teaching everything I possibly could to the people I was working with. I tend to go into too much detail at times as a result, but better to have someone stop me than to be silent when I am really needed. I have sometimes found such teaching frustrating when I feel like I’m being paid to teach the rare brick wall, but hey, at least I got paid for my time.
Eliminating the DBA
Some organizations seem to have a goal or an approach of not having a DBA. They think it is a role that can be played by System Administrators or by the people who support or even build applications. Database knowledge, and DB2 in particular is a specialty that can greatly benefit an organization if given enough authority and standing. With just a few conversations early in a project, I can help someone be on the right track. Quality DBA support and help costs money. But quality DBA support saves money when it comes to application performance, reliability, scalability, and recovery. In many situations, the money saved can easily be millions. Think about your system and what a loss of critical data or overall system availability would cost, and plan in the cost for quality DBA support.
The article clearly demarcates the underlying Roles and Responsibilities of a DBA based on differing kinds of tasks.With data volumes quadrupling year after year , the DBA role gets more and more of limelight and hence becomes exceedingly critical for operations and support. Knowledge is meant to be shared, i agree on his views on Teaching.Not sharing knowledge will give rise to a toxic environment and spoils the Technology work culture.End of the day, we are humans dependent on each other for survival and support.