The Enterprise DBA

In a couple of other posts, I’ve covered some of the challenges and strategies for dealing with those challenges that DBAs face. I mentioned that in my experience, the answers depend on the “kind” of DBA you are. I’ve covered the “single-seat” DBA and the Organization DBAs and today I’ll talk a little about the Enterprise DBA. I want to make sure that you understand that I’m well aware that everyone doesn’t fit neatly into these categories, but they do give us a place to start the discussion.


I define the “Enterprise” DBA as one in a large shop, usually part of a larger team, and someone who focuses on fewer areas in the Product.


The reason you focus on fewer areas is the same as the first of your challenges in this area. Large organizations usually squeeze every drop of functionality out of their platforms, and they will look to you for that. So how do you deal with this challenge? Study and experiment.  You’ll need to be the one filing the most bugs on the Connect site for Books Online in the topic areas you’re responsible for. You need to buy every book for your area, good or bad. Hey, you may even want to write one. Nothing teaches you about a subject more than teaching it to someone else. Set up a group of virtual machines to imitate your network, and experiment. VM systems are great for this since they can be “reset” periodically.


Another challenge at this level is that you’re part of a team. That means you need to learn to communicate, and I don’t mean just verbally. You’ll need to learn a few modeling languages such as Entity Relationship Diagrams (ERD) and the Unified Modeling Language (UML). These tools allow a lot of information to flow accurately through a group.


Another challenge you will face is size. You’ll often work with huge data sets, which complicate everything from maintenance to performance, once again, reading is the key. It’s more difficult to experiment with large data, due to cost and time. You’ll need to plan a lot more before you try something.