A day in the life of a database administrator (DBA) really is a 24-hour one.
“Typically, systems are 24×7 now, so they never get shut down,” said Dwaine Snow, IBM database administrator. This means Snow is always on call — if a significant problem with his database arises in the middle of the night, he can be paged and have to address it. With any luck, this doesn’t happen, and a DBA’s standard business hours are conducted with this in mind.
Snow begins a day of database administration by checking for alerts.
“These are anything that could potentially have gone wrong overnight, whether that’s looking in the native database alert information, or you can set up alerts that are generated automatically for you,” Snow said. “Hopefully, it didn’t get so bad that I got paged in, but I always check to see if there’s a problem.”
Next, Snow looks ahead to the remainder of the day within his department to anticipate any fires that might need to be put out.
“I typically have scripts that will alert me when things are not performing well, so I look for any signs of impending doom,” he said. “If something hasn’t happened yet but might happen soon, I’ll fix it before it happens.” The remainder of Snow’s workday depends on whether his team is in a development or testing cycle.
“In a development cycle, what I’m going to do is help our developers write good DB2 (Database 2) code, good SQL, and tune the database, making sure that the right indexes are on the table or the right structure is in the database to support these new SQL statements that they’re working on,” Snow said. “If they’re in testing, then we’ll be populating or keeping the test database, trying to keep it in sync with production so that we’re testing realistic data. And then, if there are problems, we’re helping debug those problems with the performance and fixing them so that we don’t go into production with something that’s going to slow the system down or make it crawl.”
Whether in development or testing, Snow also takes care to actively study trends in the database to facilitate resource planning.
“I monitor performance and track its history every day to see trends in how performance and database usage are going, so that I know if I’m going to need more memory or more disks,” Snow said. “You’re tracking the history to forecast future trends.”
In shutting down at the end of the day, Snow takes care to check for anything that might need to be addressed before he leaves.
“Before I go, I just again double-check that there are no alerts that came in,” he said. “Typically, they’re going to come in as e-mails, so if they came in, I would have received them. But you take a final look before you go because the last thing you want to do is get paged at night. I’d rather spend an extra five or 10 minutes and fix it while I’m here than get paged and have to drive back and forth or sign on in the middle of the night.” This does happen, however. But with high-speed Internet connections now ubiquitous in residences, it’s become much less likely that an overnight problem would necessitate physically reporting to the office.
“If there’s a problem, and a page goes off, typically what I’ll do is just sign onto the system from home and again look at the alerts, look at the performance characteristics that DB2’s tracking for me and figure out what the problem is,” Snow said. “The only time you come in is if it’s a real disaster — the whole system is crashing and burning and blowing up. But then, typically, the system administrator would fix it before a DBA would have to do anything with it.”
With any luck, then, a day in the life of a database administrator ends where it began: in bed.