I have been working on issues that relate to security certification at a number of our clients, and I can’t say that I have anything good to say about it.. Compliance standards are set such that you are protecting against the bulk of the people out there. This is generally very good practice, but when you rely on standardization alone, you open yourself to real danger.
The latest release of DBD::Oracle is now ready and can be found at CPAN DBD::Oracle
Recently we’ve had quite a few migrations to 10g Release 2 and several times been hit by one issue some users consistently get locked with status LOCKED(TIMED). One good example is with the DBSNMP and SYSMAN users, but more important are locked production accounts.
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.
When I read Note: 391116.1 with the full list, I noticed the following bugs that we’ve encountered are fixed. Unfortunately, an important bug in 10.2.0.2 posted on the Sept. 29 is not listed as fixed in this patch list.