Oracle

Many people would like to know how well their application will run in RAC. Would it be faster or slower? Would it run at all? Well, I have a query that can answer that question. There’s a caveat however. You have to first put your application in RAC, then the query can tell you how well it runs.

One of our more stable clients had some serious “mystery” production problems. To paraphrase, their app that was running “OK” starting running “sucky”. I knew that nothing had changed from our end and so being the intrepid super-sleuths that we are, we determined that the problems were related to I/O.

If you are using Oracle Data Pump to backup tables containing LONG or LONG RAW columns, then you might be surprised when trying a recovery. Well, you tested it already. Didn’t you? ;-) Right now I’m in the middle of a production migration. Earlier this week while testing this migration, I noticed couple strange errors during Data Pump import:

While testing a migration, I figured out that schema export using Data Pump doesn’t capture public synonyms on the objects in this schema. Does anyone know how to make Data Pump include public synonyms with schema export? Update: This is actually the same behavior as old Export utility.

This will help when you need to investigate some past changes to your database when auditing was not enabled. This doesn’t imply that you don’t need auditing. On the contrary, I see no reason not to use it in any and every database. However, often we get systems “as is” and we need a working method now and not the next time it happens.

As I was poking around metalink, I found the following extremely interesting section. It’s in a very obvious place, but it’s new, so many of you may have not noticed it. It’s called “Support case studies” and provides some amazing articles.