Most people in IT will tell you they are under-paid and over-worked. Few of us have that perfect work-life balance. Though I count myself one of the lucky ones where things are kinda balanced. Working for a smaller company many times means getting paid a smaller salary. This can be a dangerous thing when it comes to hiring the DBA. One of the areas a company with limited budget should not skimp on is the salary of their DBA. A lower salary range typically draws people with less experience or perhaps some past major failures. Do I really want a DBA who isn’t ready to handle a million buck ransomware attack, a failed disk array, accidentally deleted data, or a slow performing server?
Looking and finding the right person can be a daunting task. Too many times I’ve seen a job posting for a DBA, to only see it re-posted again two months later. Did the person they hire not workout? Many times, the person’s REAL-LIFE experiences take a back seat in an interview. How well the person “clicks” with interview team, certifications, or test scores many times take presidency over REAL-LIFE history. At a previous company I worked for, my manager hired a new guy who had certifications two-levels higher than mine. He had all the education, an impressive resume, and he could answer any technical question thrown at him. I was certain he would be replacing me within months. After a few days of his hire, it became apparent that he was really good at memorizing questions and answers, but not so good at executing those principals. And things really fell apart when he couldn’t understand the basic concept of a self-join. Something that was paramount with all the hierarchal data this international company used.
With so many of us moving from on-premises systems to the cloud, like Microsoft Azure and AWS RDS, the ability to just throw more RAM at a system, isn’t an option anymore. The services in the cloud are efficient, hardened, enterprise level, EXPENSIVE, and work really well — that is — unless I have some legacy mangled code that still needs that 256-GB of RAM I fed it for its twenty users. There are even companies who have moved to an AWS RDS system with 64-GB of RAM only to find out a few years later, with a business increase, that they needed 128-GB of RAM to handle the old code base. In cost terms, that can mean DOUBLE the monthly bill, or more than $120,000 a year for a small company database.
This type of scenario can be avoided by hiring a DBA who not only has experience in performance and index tuning, but also knows a little about how things work under the hood. Here are just a few tips that can help reduce the load on my RAM/memory.
- Cleaning up and removing nested cascade deletes
- Cleaning up and removing excessively coded triggers
- Archiving legacy data by removing it from the main database
- Identifying/fixing datatype mismatches in code
- Reducing over-provisioned column sizes and variables
- Moving tables off the PRIMARY file group and splitting data into separate files for Data, Indexes, and LOB data.
Here are some past posts to help with these ideas:
https://lovethesql.com/reducing-size-of-overprovisioned-columns/
https://lovethesql.com/move-table-to-another-new-or-different-file-group/
https://lovethesql.com/shrink-database/
https://lovethesql.com/trigger-only-updates-one-row/
https://lovethesql.com/archive-system-versioned-temporal-table-history-data/
The database is many times the most critical system to have up and running — 24/7 — perfectly — in a company. Why would one want to skimp on getting and keeping the best DBA they can find?