This editorial was originally published on November 10, 2014. It is being re-published as Steve is traveling.

What information ought DBAs to retain about the databases they are responsible for? It is a question that intrigues me because I get so many different answers when I ask the question. I’ve never found a definitive source that gives me a firm ‘best practice’ answer, but I find it to be a good interview question just because it gives me an insight into the way that the candidates think about the servers they manage. I’ve been wondering rather more recently about this after reading the series of articles ‘The Mindset of the Enterprise DBA’ on Simple-Talk. Joshua Feierman makes the good point that there is no point trying to automate processes until you’ve completed the task of identifying, standardising, documenting and centralising these processes.

‘Once you have both standardized and documented all your processes, and centralized them wherever possible, you will then be able to fully exploit a method of decreasing the amount of busy work you have to suffer every working day, namely automating many of these processes’

Combine this with the obvious point made by William Brewer in ‘Database Configuration Management for SQL Server’ that these documents and scripts should, along with all configuration information, be kept in source control so one can track changes, and be absolutely certain of the canonical, or signed-off / accepted status of a script or document.

I hate to write any document, script or list to do with my database work without a clear purpose. I’ve only got a finite supply of enthusiasm for communicating with myself. I find it easiest to think about the reasons for documenting DBA work. There are several good reasons, but if a reason doesn’t pop out of the woodwork, I don’t do the documentation. By archiving versions of databases, and all the scripts required to deploy them, it is possible to check for drift. By keeping baseline performance information, problem resolution and capacity planning is easier and more objective. By keeping build instructions for every component, it allows disaster recovery to be planned and executed more easily. By documenting all processes in detail, it means that if I’m ill or on holiday, I’m unlikely to be bothered. By keeping as much information as possible about changes, I’m sometimes thanked by auditors, but more often thanked by anyone tracking problems. By keeping configuration information and scripts as complete as possible, I help project managers to track development projects.

For me, however, the most compelling reason is that it helps to automate as much deployment, and administration processes as possible. To meet the demands of continuous delivery, one has to adopt the automation mindset, and nothing helps this more if all the materials for a database application are stored in one place and available to colleagues. If the major processes are listed and understood, then one can identify similarities and thereby be more economical in the scripting.

So, in general, what information (Scripts, configuration information, lists and documents) ought DBAs to retain about the databases they are responsible for?

Join the debate, and respond to today's editorial on the forums

The bracket notation can filter the data frame by using the name of the column and an expression. In this case, we use HR.hitters$Hr > 660. This filters rows. Using a comma at the end will return all rows.

Ref: Subset data frame - click here

» Discuss this question and answer on the forums