I have one production database left on 8.1.7.4, although it's pretty irrelavent at this point. The plans are in the works to upgrade that particular database to 9.2, so it's time to "decommission" it's 8.1.7.4 development database.
Part of the decommissioning process is to truncate all the tables in the development database, but leave the structure in place just in case we have to do any quick compiles. Although I know it's running on my development database, my pulse still quickens when I see all those tables whirring by knowing they're being truncated. I double and triple checked that I was on development, but still I was a little nervous pressing the "Enter" key...
Subscribe to:
Post Comments (Atom)
5 comments:
Same here. That's good practice though, always double-check or triple-check before deleting/truncating.
=)
--Emily--
I think the word export comes to mind. These days even if they say "drop it", I make an export whihc I keep for a week or two. I had a number of cases over the years where they come back two days later and ask if I can bring back something. Also it gives me a double check that I am pointing to the right database.
and while we are talking about exports:
always take one *without* data (rows=n)
Takes only a coupla minutes even on a VLDB. The number of times I've been able to quickly go to a dmp file with rows=n and grab a quick SQL to fix up a table, view, index, constraint, whatever, is just mind-boggling.
Instead of waiting for hours while the import churns through all the data, this is a very quick operation. Worth it.
I've gotten major amounts of work following up people who've done major amounts of production damage :-/
The odd thing is I'm probably klutzier than average. That makes me paranoid enough to be able to recover quickly from common catastrophes.
vstcxio
In such circumstances I log off and on again - prod & dev/test passwords being different.
Post a Comment