By Martin Wendler in DB2 —

The Ten Commandments for DBAs

I recently read a great blog entry from Fritz Lechnitz, who wrote about the Ten Commandments for a SQL Server DBA.

As I am - and mostly was over many years - an Oracle DBA, who had some excursions to other RDBMS (SQL Server, DB/2, Informix, MySQL, PostgreSQL ), I'd like to add my own thoughts about that.

  1. "Thou shalt have no other server beside me.Keep your data on stable and secure SQL Servers, and do not run a proliferation of instances."

If you ask me if you should use SQL Server or Oracle, I'd mostly prefer Oracle. But if your applications run fine on SQL Server, and your database server management fulfills all your needs, I'm completely fine with it. But keep in mind that you should always have not only a production server, but also at least a QAS system to test the quality of the data and the application using it. And also a test system to train your DBA skills and test security updates and release upgrades.

But if you're a DBA for more than just one application, you'll also need additional database in your company - i. e. for your website, or other applications. And you know how to install, administer, monitor and backup these systems.

  1. "Thou shalt not misuse the name of thy SQL Server. Name your servers clearly, unambiguously and sensibly - not SERVER123 or TEST_FINAL_FINAL."

When I was in education to become an IT expert, my team leader was a Star Trek fan (I also am, by the way). So all the servers were named after Star Trek characters. Some customers use cities as names for their servers, or - which feels more like being an adult - use sequential numbers and adding prefixes to indicate server type, operating system, and kind of usage for it.

But I also saw hostnames like server, server2, server_new. These weren't very inventive. And what happens to server_new when it's getting old and has to be replaced by server_never?

  1. "Thu shalt remember the maintenance day, that you sanctify it. Schedule regular maintenance windows, updates and backups - and keep them."

Nothing to add here. Always keep your system up to date.

  1. "Thou shalt honour your backups and their recoverability.Because without recoverability, you are lost in an emergency. Test your backups regularly!"

Backups are essential. Backup your data, keep these backups as long as they are needed, and be sure to know how to restore them.

  1. "Thou shalt not kill any data. Don't delete anything without a double bottom, backup or confirmation. Not even in the production environment."

Again, nothing to add here.

  1. "Thou shalt not make any untested changes. Check everything in the test environment first. Production changes without testing are a sin."

This is completely right: always test everything before implementing on production. Although the test system can never be a complete copy of the production, especially when it comes to user load.

  1. "Thou shalt not steal resources. Avoid bad queries, lazy indexes and inefficient jobs that steal CPU and RAM."

Sure. But you'll need any kind of monitoring for that.

  1. "Thou shalt not do wrong monitoring.Monitor with care and knowledge - don't just stare at percentages, understand what's happening."

Yes. Monitoring is extremely important. And some knowledge of what's happening. And about things monitoring does not show.

  1. "Thou shalt not covet thy colleague's query. Learn from others, but write and optimise your own queries with understanding."

As I'm not very good at SQL, I very often copy from colleagues or from other persons who blog their knowledge. This makes it even more important to understand what's happening, what the results of the statements show - and what they don't show.

  1. "Thou shalt not covet thy neighbour's admin rights. Only give rights that are necessary. Least privilege is the law."

This is very important. Sure, it's easy to just give admin rights to the application, so that users dont bother the DBA with extending tablespace. But application users are not the DBA - the DBA is responsible for security and integrity, application users are not. So why give them the rights for things they are nor responsible for?