Introduction
Well, the actual definition of the word “paranoid” is rather serious as it means that one might be suffering due to any psychological condition of paranoia. With respect to the job functions of Database Administrators, the term “paranoid” does not necessarily imply that they are under an extreme state of paranoia; however, perhaps in their zealous effort to carry out their job functions to the best of their capabilities, they may appear to be control freaks.
Do you hate DBAs?
DBAs are the team in the IT colony who are most of the time known to say “No” to things that do not conform to the standards defined by the respective software manufacturers. Also, the DBAs who have gotten the exposure to work in different platforms, and projects and faced on-job challenges, have learned many things over a period of time. A smooth road does not produce an efficient driver.
When it comes to a manager who strictly adheres to the corporate rules and guidelines, the DBA doesn’t look like the one bad guy when he enforces the guidelines and the best practices. On the other hand, for development teams who are on the verge of deploying something with last moment changes that do not appear right to the DBA, he is hated for not giving the proper sign-off.
Another example that I can think of is when it comes to the application design, a group of application programmers develop their software to directly carry out tasks to make the changes. However, when it comes to the database design it requires a lot of database structural changes so that it could meet the database standard requirement and work properly, maintaining the standard normalized rules to yield the optimal results.
The logical data model is designed to efficiently capture the business requirements of the application. But the physical database design is based on the logical data model in combination with the needed changes that the DBA feels are needed to make the most of the RDBMS. So, in simple terms, DBA plays a very critical role in organizations who know Database Design format and at the same time must have some knowledge about how all the components are connected to the databases to provide an effective solution.
If the design of the database is incorrect and is already turned over to production it is most likely to go through a series of data model changes over a period and may turn into a lot of issues. So, it is always beneficial to discuss things before making any abrupt changes. It is noticed that when such issues are observed, the DBA team is held responsible. However, the reality can be something different.
Can you think of any other reason? Do comment.
Do you see DBAs being rational at all?
The job duties performed by the DBAs are well understood by traditional developers and system administrators.
Let’s check out how
Many developers in small organizations perform many traditional DBA tasks themselves. They take backups, perform restores of the database, and install database management software. Unfortunately, developers often are unaware of the finest changes needed in the admin space and the best practices.
For example, they install the binaries in the operating system drive. They grant the highest permission to themselves and others, they don’t implement important database maintenance procedures, and avoid reviewing the critical execution plans.
System administrators are knowledgeable enough on the system side. They know about installing database software on the right path, how to stop and start services, how to set up maintenance procedures, and they know how to debug server issues. But when it comes to the point of providing guidance about which index can do a good job, how frequently query statistics should be updated, the best guidelines for writing an effective query, and getting a performance benefit, their expertise falls short. That’s where a DBA performance comes into play.
The DBA role typically bridges the gap between developers and system administrators. The DBA does not expand far into these other roles typically. A DBA is not usually a perfect coder or an expert at handling the complicated system task.
The typical DBA job is to manage the system, they know how to make it work better and how to get it back from a disaster or like situation. On the other hand, a developer knows how to build an application that does something specific. Depending on the situation the DBA must wear different hats – sometimes by writing scripts and then they wear the Developer Hat, or other times they do maintenance activities and they wear the Sysadmin Admin hat.
Because of the gaps between the developer and system administrator roles, the DBA may seem irrational to both groups.
Do you like to hear “No”?
When you approach a DBA and hear the word "No, can’t be done”, or a straight “no”. How does that sound to you? A junior DBA might say a straight “NO”, most of the time (s) as opposed to “It might work, if certain changes are done”, or “It does not meet standards, make the changes to approve and move on”.
A good DBA is found to be approachable and listens to the issues faced by the affected teams. If a DBA is full of anxiety and afraid of being blamed or losing the job, he is either not a very good DBA or is a Junior DBA.
What is vital for the DBAs?
It is always a good approach to reach out to the development team and other teams with whom a DBA frequently interacts. The best DBAs offer training sessions and/or documents to explain the proper usage of databases including meeting standards, proper security models, correct encryption methods, latest features, and so on.
When should DBAs be engaged?
It is always a good practice to engage DBAs right at the beginning of any development effort. DBAs should be involved starting from database design until rollout and delivery. DBAs can review or develop the database design and lend their expertise on all related database issues. Sometimes unknowingly you’ll find that other teams failed to consider a dependency which a DBA can easily find and save the project from failure at the time of delivery.
This is not to say that even after engaging the DBAs the solution will be perfect, but the chances of having project mistakes may be greatly reduced. At the end of the day, no one wants to see his company’s data breached and have the company name flagged in the media. So, a certain level of paranoia does help here. Therefore, engaging the right teams is always crucial for overall success. A very popular Chinese proverb may fit well in this context: “Better to light one candle than to curse the darkness”.
Conclusion
When we travel by plane or even train, we are informed of the security exits and emergency procedures. This information is disseminated so that if there is any state of emergency, travelers can execute a quick exit to save themselves. Similarly, DBAs are the folks who are available to help when it comes to databases. Being “super paranoid” is not something that is usually helpful, but at the same time “taking things for granted” is not going to help at all. A stable sense of paranoia may lead to better functioning DBA and can lead to your success. Your success leads to your organization’s success.
What do you think about this? Share your thoughts and ideas. Put your comments below.
Thanks to Bill Lescher for doing a peer review of this post. Bill has more than 20 yrs. of work exp in database administration and development. He is a co-founder of the Chicago chapter of the Professional Association for SQL Server (PASS), where he served as President for its first decade.