While reviewing some material in advance of my presentation at UKOUG Conference 2006, I found an interesting change in RMAN behavior in Oracle 10g. The difference is in the way RMAN handles the case when an incremental level 1 backup is taken without an available level 0 backup. This probably won’t affect anyone much, but I found it interesting. And actually, there are scenarios in which it might cause issues.
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.
In the last month, we have been hit with two clients’ large-scale failures. The first involved network issues; the second, disk failures. What happened?. We took one of the standbys and turned it into a primary. The other standby then automatically started recovering from the new primary! That was it. What a let down! No magical status updates, no little “dots” going across the screen. Just one line and 15 seconds. Oracle, get your act together! I even had to use bold text to make it stand out.
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.
Welcome to the 17th edition of Log Buffer, the weekly, human-edited review of news from the database blogosphere. There’s a lot to cover this week and not a moment to waste, so let’s begin.
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.