April 27, 2011 by Mike Hillwig
Knowing that I’m putting myself on the job market, I was recently asked to describe what I do. As a DBA, I realize that every DBA’s job is different. So it was an interesting exercise to put together a few paragraphs explaining what my current role is.
My company is rapidly growing. We’re in the process of replacing our current ERP system with a shiny new Oracle-based one in the next 10-12 months. While that happens, the company will grow another 40 percent. Our mandate from management is “Make it scale!” We have existing applications that need to grow and new applications that need to be put in place.
A friend referred to me as a jack-of-all-trades DBA. I think he’s onto something. As the only DBA in the company, I do it all. Or at least most. That means everything from managing applications to performance tuning to server management to scaling applications that we’ve outgrown. I’m also working on a consolidated reporting instance as well as designing a short-term data warehouse solution.
Let me explain that our entire IT infrastructure team is four people, and that includes our Director of IT. It means we all wear several hats. We have a network/sever guy, security/network guy, and a DBA. If it touches a database or database server, I’m involved.
Part of this growth (and a looming data center move) required virtualizing everything. And I mean everything. The only database server that hasn’t been virtualized is more of an appliance that runs on vendor-provided hardware. Every other sql server is virtual. During our virtualization project, we consolidated 14 servers down to four primary servers.
Another thing I’m doing is making systems scale that were never meant to. We have a homegrown Access “application” used by our manufacturing organization. It was this little database that is used to capture data for hardware testing. Like most applications of this vein, it grew into a beast. And somehow, it grew into a business critical beast. It had become the authoritative data source for products shipped. Recently, while looking at the design of the thing, I realized that the DBA who upsized the thing didn’t use clustered indexes. It was a HEAPing mess.
Most recently, I’ve been tasked making this database talk to its little brothers at some of our business partners’ locations. These remote locations need to get updated information about customer orders, parts, and BOMs. Not only that, we need to remote locations to report back to the mother ship.Historically, someone established a VPN connection and did this manually. Considering our tight network policies, automating this is quite a challenge.
Our existing collaboration/content management tool just isn’t going to work. We’re implementing Sharepoint. And we’re estimating the content databases to reach 500 GB within the next 18 months. I’ve had to prepare the database servers accordingly. This means content databases have to span multiple data files and multiple disks.
On top of all of this, we’re publicly traded and bound by Sarbanes Oxley. That means a good chunk of my time is spent satisfying auditors.