As a database developer, I normally focus on data structures and code, and not on database administration. Recently, I worked on a small project where I had to take on the database administration role as well. As such, the project reached a point where I had to make a backup of the data mart I had built. Later on, at lunch, I shared the experience with another developer friend.
Me: I just backed up a database.
Friend: How did you make sure the database was in a consistent state – or whatever it is? I hear that’s really difficult.
Me: I shut down the database.
Friend: Oh, then you cheated.
Me: How is that cheating?
Friend: What if the database had to be available 24×7? Then you’d have to take the backup with the database running – and that’s more difficult.
Me: But my database doesn’t need to be up 24×7. I have two users. I told both of them the database would be unavailable for a little while and had it back up in about fifteen minutes. No big deal.
The point my friend was trying to make was that if I had taken a hot backup, I would have learned a new marketable skill. I’m all for gaining new skills and always looking for opportunities to learn new things. However, I don’t believe in unnecessarily complicating a process in order to do so.
In this particular case, it wasn’t necessary for the database to run 24×7, so I shut it down to take a backup. If the database did need to be up 24×7, I would have taken a hot backup. Even in that case, I wouldn’t invent a hot backup process unless it was absolutely necessary. Most likely, I would consult the documentation and user forums of the particular database engine to mimic a procedure or best practice created by someone else.
In a classroom setting, using the easiest techniques or copying someone else’s solution may be considered cheating. If these practices are still considered cheating in business, then I will cheat whenever possible.
About Julius Campbell