How to run a database: some ground rules

So you think you want to be a database engineer/architect/maintainer/worker? Notice, I didn’t say “DBA.” THis is mostly because I have met so many that are not….Database engineers and architects that are good at what they do get paid well, but the term “DBA” has little meaning because there are many people who have minimal understanding of SQL who claim that title. Don’t claim that title unless you are at least MCSE. For an entry level application/database engineer of a big platform sitting on SQL, the expectation is that your pay may deviate from those who work on the front end of the application.

Depending on the industry and the application, you may expect to get paid slightly more than the people on the front side.  This is because it is expected that you will have the same skills as them, but also have knowledge of infrastructure systems, and also be somewhat more willing to receive calls at strange times of day. For example, someone who has five years experience may get paid $77,000.  Someone with the exact same certifications and industry experience, but who can solve real problems and find and fix a root cause that has dropped the entire system to its knees, may get paid anywhere from $80k to $180k, with $80k being entry level into the database/infrastructure work.

Ok, enough about that.  Here are a few ground rules for good database etiquette:
  1. There are very few, select problems that  necessitate a reboot or restart of SQL server to fix a problem. Don’t do it if you don’t know why you’re doing it.
  2. Know your backup strategy, know that it works, and make sure management knows it, too.
  3. Know your disk IO, and test and retest and have a history of tests of it.
  4. Know what your users are doing and why they are doing it.
  5. Database queries should be fast.
  6. Understand the difference between poor disk I/O and poor file I/O
  7. There are a few blogs that are good, plus a lot of misinformation. Know which ones are best. (Ask around).
  8. Read a book, take notes, make lists, have checklists,blog about your experience.
  9. Never test code in a production environment. Especially never test UPDATE, DELETE, or INSERT SQL.
  10. Key lookups, table valued functions, table scans, and clustered index scans are red flags that a query is not well designed. Understand how to fix them PROPERLY.

That’s all I have on this subject, folks.  Let me know if you have any questions!

 

Comments are closed.