What's your #1 way to be careful with a live database? [closed]

Answer 1

• Nobody wants backup but everyone cries for recovery
• Create your DB with foreign key references, because you should:
• make it as hard as possible for yourself to update/delete data and destroying the structural integrity / something else with that
• If possible, run on a system where you have to commit the changes before you permanently store them (i.e. deactivate autocommit while repairing the db)
• Try to identify your problem's classes so that you get an understanding how to fix without trouble
• Get a routine in playing backups into a database, always have a second database on a test server at hand so you can just work on that
• Because remember: If something fails totally, you need to be up and running again as fast as any possible

Well, that's about all I can think of now. Take the bold passages and you see whats #1 for me. ;-)

Answer 2

Maybe consider not using any deletes or drops at all. Or maybe reduce the user permissions so that only a special DB user can delete/drop things.

Answer 3

1. Check, recheck, and check again any statment that is doing updates. Even if you think you're just doing a simple, single column update, sooner or later you will not have enough coffee and forget a 'where' clause, nuking a whole table.

A couple other things I've found helpful:

• if using MySQL, enable Safe updates

• If you have a DBA, ask them to do it.

I 've found these 3 things have kept me from doing any serious harm.

Answer 4

My #1 way to be careful with a live database? Don't touch it. :)

Backups can undo damage that you inflict on the database, but you're still likely to introduce negative side effects during that span of time.

No matter how solid you think the script you're working with is, run it through a test cycle. Even if a "test cycle" means running the script against your own instance of the database, make sure you do it. It's much better to introduce defects on your local box than a production environment.

Answer 5

I always comment out any destructive queries (insert, update, delete, drop, alter) when writing out adhoc queries in Query Analyzer. That way, the only way to run them, is to highlight them, without selecting the commented part, and press F5.

I also think it's a good idea, as already mentioned, to write your where statement first, with a select, and ensure that you are altering the right data.

Answer 6

If I'm updating a database with a script, I always make sure I put a breakpoint or two at the start of my script, just in case I hit the run/execute by accident.