Beware the hidden parameters... magic comes at a cost!

I was reading a series of posts on Oracle-L which had to do with a database that would not come up due to undo tablespace corruption.

http://www.freelists.org/archives/oracle-l/04-2008/msg00821.html

There are some undocumented ways to respond to undo corruption. An example of one way is mentioned in the following blog (you can find this solution many places, but this is just one example I found):

http://priyambodo.blogspot.com/2007/03/oracle-undo-tablespace-corrupt-in.html

(note there are other solutions for other specific conditions, but the same basic principles exist - I also have not taken painstaking measures to review the technical content of this blog entry, so use it at your own risk!!).

Now, the point of this post is this. The magic UNDO solution suggested here, using hidden parameters is all well and good, you might well get your database open again. I've been in places where this method was used just fine, and the database opened.

Unfortunately, afterwards folks didn't want to consider the potential negative ramifications to the database having used this method. What is the problem you ask? Well think about what UNDO is all about. Undo is the before image of a block that has been changed. It's used during recovery to rollback any uncommitted changes. The implication here then is that your data may well be inconsistent after you open the database using the method outlined above.

Want more? Think about the system tablespace and the Oracle metadata. IT used UNDO also, and so the SYSTEM tablespace data may well be inconsistent. Thus, you essentially have a corrupted SYSTEM tablespace. Not a good situation.

So, if you are going to use this big hammer, consider these implications. What I'd do is if you manage to get your database open, use exp or expdp to do a backup, recreate the thing and then load the data into the database. Your data may still be corrupt, but at least the system tablespace will be pure.

You can go fix your own data yourself.

Finally, this can all be magically solved if you introduce a sound and TESTED BACKUP STRATEGY before you have the failure. If you have a sound backup strategy I can almost assure you that you will never run into this kind of situation.

Oh yeah, I wrote a book on just that topic, backing up your database with RMAN....

http://www.amazon.com/Oracle-Database-RMAN-Backup-Recovery/dp/0072263172/ref=pd_ts_b_9?ie=UTF8&s=books

I have HAD IT!!! And I'm not going to take it anymore.

Ok... time to vent. I like to read. Magazines are among my favorite form of reading (I like science magazines, airplane magazines, train magazines, financial and the like). I like them because the information is generally current, up to date and always interesting.

But I'm SICK AND TIRED of this.... I'm reading in my favorite magazine. I turn the page, and this STUPID CARD comes flying out and lands on the floor. With each stupid magazine maybe 2-4 of these buzz bombs falls out. This is IRRITATING to me. Not only is it irritating when they just fall to the floor and mess it up, but I like to sit in my bath and read from time to time too... so then the cards get wet. Plus it's just killing more trees.

So, I have a plan. I think we should all take these cards, shred them up and then send a bulk set of them to each publisher once a month with a letter that says, STOP PUTTING LOOSE SUBSCRIPTION CARDS IN MY MAGAZINE!!

Does anyone hate this as much as I do?