Friday, February 17, 2012

8 Simple Rules for Modifying Production Database

  1. Make sure you have a backup!
  2. And by that I mean a fresh backup, made just now, not an idea that there may exist a person who knows where a backup is stored!
  3. Make sure you can restore from the backup!
  4. And by that I mean that you have tested the restore procedure. On the backup that you have just created. And that you have tried accessing restored backup with the program that usually operates on it!
  5. Don’t type any SQL commands. Use only scripts/programs that were previously tested on a development/test database.
  6. And by that I mean tested by yourself, not by a fictitious somebody who may have tested a script three years before on a database used by a completely different program!
  7. Don’t modify production database!
  8. And by that I mean DON’T MODIFY PRODUCTION DATABASE!
Posted by at
Labels: ,

8 comments:

  1. lGuzzon19:46

    What happens ... your nuclear-plant application crashed as Fukushima did?
    ;)

    ReplyDelete
  2. Anonymous19:50

    Or simply just start using LiquiBase and stop worring!
    http://www.liquibase.org/

    --
    fabio vitale

    ReplyDelete
  3. gabr4219:57

    IGuzzon, nah, nothing like that. I was training, listening to podcasts and this just popped into my mind. I should probably tag it with subconsciousness_at_work.

    ReplyDelete
  4. François20:07

    You forgot rules 9 and 10 (10 rules make a better number than 8 if you need to be above 7; there's a famous precedent):
    9. DON’T MODIFY PRODUCTION DATABASE!
    10. DON’T MODIFY PRODUCTION DATABASE!

    :)

    ReplyDelete
  5. gabr4220:19

    @François, 8 is such a nice round number :) (and a title was meant as a TV series reference).

    ReplyDelete
  6. LDS18:46

    The fear of changes is what makes hackers' job easy. People don't upgrade and patch, and vulnerabilities stays there waiting to be exploited. Of course changes must be planned and properly managed, but there should be not any fear of them. People should start to fear about what happens *if they don't upgrade and patch*. If maybe ten years ago the say "if it works don't change it" could have sometimes been true, today it's "if you don't patch it will be exploited". And a good backup is useful not only when upgrading...

    ReplyDelete
  7. Anonymous23:07

    A related set of rules, called the DARN Principles, learned from experience:

    http://www.emetra.no/FastTrak/Help/index.html?the_darn_principles.htm

    ReplyDelete
  8. Anonymous17:08

    @LDS : vendors even publish the weaknesses
    @gabr: have you ever told this to a business user ? they only ever work on production databases (except for testing)

    ReplyDelete

Subscribe to: Post Comments (Atom)