Do you really need a DBA?

Let me say at the getgo: Every organization needs full-time database management.

Delaying the hiring of a full time DBA could lead to a bunch of problems that are festering and growing to the point where easy, non-intrusive fixes may not be possible anymore. Unfortunately, some organizations either have never had a DBA or do not have one presently. They are wingin’ it and hangin’ out near the cliff’s edge. It’s like the “out of sight, out of mind” mentality, the “if it ain’t broke, don’t fix it “fallacy. Usually this lack of database focus is due to an environment that is developer-focused where there have been few critical database issues or those issues were easily resolved. It may result in a false sense of security that encourages them to think that having good database programmers/application developers makes up for the lack of attention to the database backend details. What is worse is that this might be true in the initial short term, encouraging this deceptive reassurance for as long as a few months or even a few years!

The problem is that when the client side folks have a problem that they can’t deal with, they then bring in contractual database experts to try to fix the problem(s), the “put out the fire” folks. At this point, it may not be possible to remedy without requiring a significant amount of changes and downtime. That’s when the neglected, RPO/RTO and the “9s” come into play. They cannot meet these expectations. Everyone moves into CYA mode.

The main thing you need to consider here is the evolving dynamics of an SQL workload, which  is exacerbated at the application server level with many pods that spawn additional instances that create more groups of connections to the same database at the same time. The resulting heavy SQL workload hitting the database affects everything that needs to be managed on a regular basis. Here is my short list:
* architectural re-evaluation and changes (HA, DR, host platform: bare metal vs cloud, replicas, connection pooling, load balancing)
* Data Availability requirements (RPO/RTO)
* Security/bug patches (quarterly/semi-annually)
* Major upgrades (yearly to a few years)
* Configuration changes
* Performance tuning
* Real-time analysis and trouble-shooting (monitoring/alerting)
* Database growth (vertical/horizontal partitioning, denormalization)
* Data fragmentation (unnecessary data growth and increased IO fetches)
* Host resource requirements: cpu, memory, disk capacity and IO rates
* Scaling problems: connection activity, query conflicts/resource contention)
* Changing database query access plans (indexing, column cardinality)
* Access Control Management (database permissions)

At the minimum, develop a continuing relationship with a database services company to keep an eye on your databases.

In summary, everything needs to be constantly managed in the general 3-tiered architecture of CLIENT (presentation), SERVER (logic), and DATABASE (data). Unfortunately, in my opinion, the most neglected one is the last one, the database tier.