Skip navigation

Four Survival Tips for the Accidental DBA

Zack Kendra is Principal Software Engineer at Blue Medora.

Let’s be honest, most of us have inherited a database administrator gig. Either you’re a dev that’s deployed a new database platform to support your application, and now you’ve got to troubleshoot; or you’re a dedicated database administrator, familiar with a few platforms who’s been asked to work on one or more of the many number of new data platforms.

The number of DBA professionals across the country continues to rise. According to CNN Money, the DBA job market is expected to grow by more than 11 percent over the next 10 years. Many database professionals pursue their careers through a formal college degree or internal development on the job. Increasingly though, many of us end up in this profession by accident.

By 2018, Gartner predicts that more than 70 percent of new in-house applications will be developed on an open source database and 50 percent of closed-source databases will be on their way to conversion. These in-house applications and the growing number of open-source and cloud-based databases that drive them plays a major role in increasing the number of accidental DBAs among us. Nearly anyone can deploy a database on AWS or Azure. However, few of them know how to fix or manage one, beyond just increasing the instance size.

Demand for more DBAs is also on the rise because of the digital transformation efforts promoting cloud adoption and comfort with running production databases in the cloud. There is an increasing adoption of DevOps and proliferation of developer tools, as well. Even the role of a traditional DBA is transforming as new, inexperienced DBAs join their ranks from less traditional roles, such as a data scientist.

Accidental DBAs can quickly find themselves overwhelmed by demands for data and performance SLAs. They might lack the resources, policies or processes necessary to succeed . Not to mention, many accidental DBAs are often left to their own devices when it comes to training. Here are a few suggestions to help new DBAs survive the transition.

Don’t Solve Everything with Code

Developers turned accidental DBAs can quickly find themselves in over their heads if they try to address database issues. It’s only natural for a developer to turn back to their code as the most familiar path to resolve an issue. In most cases the database engine will do a better job at finding the most efficient way of completing a task than you could in code. Especially when it comes to things like making the results conditional on operations performed on the data.

Get to Know Your Databasics

For those DBAs that have come from less traditional roles, or even those who are working with a new platform, it’s important to get a good baseline for the unique KPIs for your specific DBMS. This can be incredibly challenging given the rapid amount of change taking place in this space today. Beyond the basics of querying execution time, each platform often has its own metrics you’ll want to keep an eye on for performance tuning. Make sure you’re tracking things like Cassandra’s keyspace or Couchbase’s buckets and nodes.

Databases with origins in open source, like PostgreSQL, can be particularly difficult to learn unless the DBA becomes an active member of the community that developed it. Documentation can sometimes be limited. So the new DBA should reach out to those colleagues with long histories of working with the database platform through multiple generations and version updates.

Find a Way to Visualize the Data

Managing multiple databases with different data sets can result in areas where the DBA lacks visibility into key data metrics and configuration. When faced with these database blind spots, many DBAs resort to developing their library of homegrown scripts. While these scripts can function as a bridge between the monitoring solutions implemented and the functionality required by the stakeholders, they are inevitably difficult to maintain and provide the required functionality.

Blind spots within database infrastructure wreak the most havoc during cause analysis. If a DBA is tracking down an issue’s source but has limited visibility into the database infrastructure, they may be unable to discover the cause and fully resolve the issue.

Stop Hoarding Monitoring Systems

New database software packages usually come with their own monitor solution. Add the multiple monitoring applications for cloud and on-premises infrastructure, and before you know it, your desk is littered with passwords on sticky notes.

Consolidating your database and infrastructure monitoring on a single platform can provide visibility across your entire data layer so DBAs can start to optimize database performance. Also, DBAs with a comprehensive view of their IT can pinpoint the cause of problems faster and reduce the time spent chasing down and putting out fires and focus instead on optimizing database performance.

Challenges for accidental DBAs will only increase as more organizations continue to migrate to the cloud and adopt DevOps initiatives. Professionals that find themselves working with databases in next few years will be challenged to keep up with multiple platforms, diverse workloads and impatient internal clients. With any luck, demand and complexity will drive up salaries and prestige to make the DBA the next big career sensation.

Opinions expressed in the article above do not necessarily reflect the opinions of Data Center Knowledge and Informa.

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish