-----------------Original Message---------------- I believe the forgone conclusion you are talking about is that "mirroring outside of Oracle MAY result in data loss" MAY is a very important word. The multiplexing of redo logs across multiple disks and controllers is a simple way protect your database from potential failure.
Your position appears to be that hardware mirroring, software mirroring, RAID hardware, and the controllers feeding them all are infallible. -------------------------------------------------------------------- For those of you who are averse to the acquisition of knowledge through muscular debate, I trust you know where the DELETE button is. For the rest of you .... As far as "MAY" goes, we can take that to any ridiculous extreme you wish to take it. The issue is NOT: "The multiplexing of redo logs across multiple disks and controllers". The issue is HOW one does this. Let's get this back to my original post. I was responding to the implication that there is some danger in using hardware mirroring such than one should not use it. As one who HAS ACTUALLY DONE BOTH and ACTUALLY USES BOTH and HAVE DONE SO FOR A LONG TIME (have you?) with both DATABASE and NON-DATABASE files, I felt it necessary to state that notwithstanding whatever armchair academia is floating around on the topic, I have NEVER experienced a loss with hardware mirroring; And have never seen a reason to imply that the practice has any inherent dangers. Does that mean that a problem can never occur? Certainly not. Have we ever had a controller or hard drive fail? Yes, indeed. But, have we ever lost a database as a result? Nope. Let me turn things around on you and look at Oracle multiplexing. Has anyone ever lost a database who was doing Oracle multiplexing? Sure. Well gosh! I thought this was supposed to keep this from happening. Why didn't it? The previous posts seemed to be totally preoccupied with this apparently ubiquitous phenomenon of corrupt blocks. Let me ask you this: How often does it occur that you run your rman backup, and it detects bad blocks that your OS missed or Oracle missed and failed to report? I'm just curious to know how prevalent these things are. Another thing that was stated by the original response was that there was some performance benefit to Oracle doing the multiplexing -- that Oracle somehow "optimizes" the process. In the case of software mirroring by the OS, this is a dubious statement. In the case of hardware mirroring, the statement is patently false and is the main reason why one would use hardware mirroring -- because performance demands on the system require it. Let's take this performance thing a little further. As we have read in many posts to the list, we even do such reckless and unthinkable things (at least it was a few years ago) as allow storage arrays to cache our writes ... even our redo writes (lions, tigers, and bears, oh my!) because performance demands require it. Now, you can peruse the database literature and find an abundance of text on what a hideously EVIILLLLL practice this is. But we do it anyway. And, saints preserve us! We don't have a landscape littered with lost databases. As one who has never lost a file of any kind to hardware or software mirroring (well ... except for the early releases of Veritas on the Motorola 88K system where Veritas was a complete abortion and worse than nothing at all) I am going to go with my own considerable experience on the subject. If you wish to quote chapter and verse from this doc or that doc, that's great. But I'm going to go with what I have actually seen tempered by any tangible, objective, hard evidence I come across. Now for those who are into this "worst scenario" thing let me ask you: What if I put your storage array between a 30HP air conditioning blower moter and a spot welder, and run a couple of paint shakers on top of the array to boot. What will your vaunted Oracle multiplexing do for you then? Huh? Well, smarty pants, I'm waiting! -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Stephen Lee INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
