Tech Stories: The DBA’s Dream Database


Back when I worked for the people search company out in Playa Vista, I met a DBA who was pretty condescending towards the developers. You have to understand back then, DBAs had significantly a lot more power since many companies were using Oracle for their core backend. A good DBA usually were certified and could command a fairly decent salary just because they were responsible for the uptime and tuning of Oracle (or other major RDBMS’s). We didn’t really have AWS with autoscaling and the documentation that would allow developers to focus more on the business code side of things. Anyway, he told me something that was both hilarious and somewhat common sense regarding his ideal database.

My ideal database is one with nothing in it.

It’s an odd statement but you have to look at where this DBA was coming from. A database with zero information is the most secure database you could ever see. It’s so boring no hacker would even bother trying to assault it. Because of that the DBA has absolutely nothing to do and can just spend the entire time surfing the web.

Of course, such a database is useless and any sane company would simply fire that DBA on the spot for being equally useless.

These days I kinda feel DBAs are still useless to a degree. AWS and the cloud pretty much have deprecated traditional IT departments. Instead, such an idea has consolidated into the dev ops type where you still get a separation of production and development with less political BS that might arise from an old school IT department.

That said, I could sympathize how he felt back then to a degree. Although things were simpler in terms of infrastructure, they were more fragile as a lot of the techniques for scaling weren’t as well known and still being developed. So for us, we used mod_perl which employed something called a persistent connection for performance gain.

Persistent connections with mod_perl were notorious for having an issue called “the morning bug.” The morning bug occurred as a result of the connections growing stale, forcing the DBAs to kill zombie connections in the morning. Some system administrators would issue restarts on Apache since mod_perl was closely linked with the web server. That would cause the connections to be refreshed without forcing a DBA to do an emergency wake up call.

Also, stored procedures seemed to be a little more prevalent back then as it was perceived to have a greater performance impact on the application. The idea was that having the database contain the logic would offload some of the work from the application server. The result was that the DBA again would have more responsibilities to manage that level along with triggers.

I suppose for a single person being responsible for these aspects it could get a little stressful. Not to mention how delicate and insecure systems could be back then with poorly written code. That meant that the database had to be even more tightly locked down.

Of course, the overarching ideas are still relevant. Security at the database is still critical and tuning is important. But the need for certifications really has been de-emphasized over time unless you’re doing a high end type of database. However, one thing is that the DBA’s dream of having an empty database never would even be considered these days. There’s just too much information going around that’s what tons of money.

(Visited 21 times, 1 visits today)

Comments

comments