You probably wouldn’t expect a technical Oracle post here. 
But I can’t call it Oracle blog without relevant content so here it goes. Let’s call it a late birthday present — my first post came on the 2nd of May, 2006 so it’s now one year, one month and one week old.
Today, purely by accident, I came across Metalink Note 413098.1 Extremely Poor RMAN Backup Performance to NFS After Upgrade to 10.2 on Solaris. It seems that it also affects HP-UX at least.
What I love the best from that note is the workaround for RAC environments:
Do not write backups to NFS at 10.2. Backup to tape using Oracle Secure Backup or an alternative Media Manager or backup to a local disk drive.
Oracle Secure Backup?!?! Does it mean mean it has fewer bugs? Nice ad.
I.e. if my backup infrastructure is based on NFS - I’m screwed. The advice basically turns into “do not backup your databases - it’s slow”. Where are the other workarounds like stay on 10.1 or 9i? “Don’t use big databases” would be just as appropriate. 
If I have time, I’m going to test it on Linux but if someone has interest - benchmark backups from 10.1. and 10.2 on NFS and let us know. Better yet, run it through strace and check the system calls.
In yesterday’s post, “VLDB with ASM?”, I showed problems with ASM mirroring for high volume database. Today, I want to emphasize that you should be very careful placing flash recovery area (FRA) on ASM diskgroup with normal or high redundancy.
The reason is the same as before. Whenever all or majority of disks in a failure group are “broken”, ASM starts immediately rebalancing. If there is no enough space left in failed failure group (well, zero is all disks fail) than ASM will mark those disks as HUNG and no files can be created on that particular disk group. For flash recovery area this is very bad state - no files can be create on this diskgroup, i.e. ARCx processes couldn’t backup online redo logs so at some point the DB will just freeze if situation is not resolved promptly. Flash back logs also couldn’t be written. Any database backups will fail. Resolution requires manual intervention and might actually take a while.
If FRA needs to be placed on ASM than consider using external redundancy even for relatively small size FRAs. Use mirroring inside storage box or between storage boxes as some vendors support that.
In fact, the latter looks like a good approach for mirroring of large ASM database over different storage boxes - using external redundancy and let SAN boxes to mirror using vendor’s technology (though, it might require additional licensing).
I got so excited about ORADEBUG feature I described in the previous post that completely forgot to mention the main news of the day - the second day of Tom’s seminar. It was an excellent day packed with lot of useful tricks and tips plus I cleaned quite a few things in my mind. The best one that I got straight now - so called “Write Consistency” in Tom’s terms.
Small but neat 10g R2 feature:
SQL> SET SERVEROUTPUT ON SIZE UNLIMITED
I can also put up to 32K lines using DBMS_OUTPUT.PUT_LINE. No comments.
And by the way, Tom’s story with Best Buy was real as he mentioned today.
Recent Comments