Professional Development/ Syndicated

T-SQL Tuesday – Sometimes DBAs Are Required – Even for the Amish

1 Comment

This is my first T-SQL Tuesday blog post. 

I keep meaning to participate, however my intentions are always superseded by work, family, travel, and so forth.  This topic, however, hits very close to home for me and when I first saw word of it (about 15 minutes ago) I knew I had to fire my salvo against the walls of the Internet.

Full disclosure on this election day in the United States  – I’m a DBA.  It serves my interest that I state, unequivocally, that you MUST HAVE A DBA IN EVERY OFFICE, STORE, BUNKER, HOVEL, HOME, KENNEL, KITCHEN, HEN HOUSE, OUTHOUSE, and BROTHEL in the world. 

However that would be a lie.   Not all organizations (using that term broadly) require a dedicated Database Administrator.  Not all even require someone with DBA-skills.  Any one of the follow situations would ensure you could exist peaceably without a DBA…

  •  Your company is not concerned about the amount of time it takes to return results from your database(s).
  • Your customers are not concerned about the speed at which they’re serviced via your website, point-of-sale devices, or other service points that rely upon a database.
  • The software you rely upon is developed, serviced, and hosted by a third party.
  • The data you rely upon is not mission-critical.
  • The data you store does not include PHI (Personal Health Information) or PCI (Personal Credit Information).
  • Your company’s data is retrievable or re-creatable via means either available to your or through processes you’re comfortable with.
  • You’re Amish.

Seriously though; not all nails require a sledgehammer – not all SQL Server, MySQL, or Sybase databases require a DBA.  All Oracle database installations require a DBA.

The base installation for SQL Server, particularly the free Express Edition of SQL Server, has now almost been relegated to the CLICK NEXT – CLICK NEXT – CLICK FINISH – LEFT – LEFT – RIGHT – RIGHT – B – A – START process.  (Note that I said base install.  Anything beyond that gets dicey without someone having familiarity with SQL Server, the Windows family of operating systems, and an understanding of storage requirements and architecting SQL installs for performance.)  A small operation can survive without someone on staff whose sole responsibilities focus upon data security, availability, integrity, and structure if the business meets the bullet points above – or is Amish.

Database Administrators spend almost as much time explaining what they do to those outside the Information Technology sector (including their families) as they do ensuring that their customer’s data is accessible, secure, and available at breakneck speeds.  They still find themselves relegated to tech support at family holiday gatherings: “You work with computers Tim, I can’t get Angry Birds to download to my Droid phone.  Can you fix that for me before we open presents?”  It does not mean they’re not important – it just means that most of their work goes unheralded.  DBAs that are visible in an organization are typically visible for all the wrong reasons – like not performing their jobs.  A good DBA should be constantly fighting the perception that they’re job is too easy.

The truest test of whether or not a DBA is required in an organization comes from the issues and symptoms of not having a DBA on staff over time.  I’ve experience with an organization that did not have someone who acted in the role of the DBA.  Database backups were spotty – sometimes going months without a database backup.  Thereby making recoverability upon failure questionable.  While statistics were being updated, indexes were never maintained.  There was almost, uniformly, a 1:1 relationship between databases and SQL instances.  Hardware, SQL Server configurations, and database settings were not uniform, were mis-sized, or in conflict with one another.  Coding standards were not enforced.  Security issues abounded: developers with system administration rights, service accounts shared amongst servers, service accounts with domain administrator privileges, and so forth.  These are advanced issues that – while extremely important – are often overlooked in an organization where there is no DBA or the Server Team or Security Team acts  in the role of Database Administrator.  Practices for the staff versed in those realms may not follow with best practices on the SQL Server platform (or any other RDBMS platform for that matter.)  To them they may see a nail in need of a hammer, when in fact closer inspection would show a screw that needs finessing.

Yes, DBAs are required – though only for organizations that require secure data, fast-access to that data, and assurances that the data is accurate and recoverable to the levels of expectations of the staff, customers, and owners that rely upon it.  Even if they are Amish.