>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!
We do hardware mirroring to protect against controller and disk failures. We do redo log file multiplexing to protect against fat fingers and other odd-ball stuff that have caused problems for an entire file system. Call it an unreliable OS, poor SA (ok, maybe even DBA) practices, whatever. The fact is that I've experienced it and I've been grateful to have the redo logs multiplexed. Each DBA can weigh the pros/cons and decide for themselves. Given your scenario above, mirroring or multiplexing within the array would both be useless. The entire storage array would have to be mirrored. But I don't rely on my multiplexing for this type of disaster. The multiplexing is for other issues I've encountered over the years. I wish I could maintain only 1 member redo log groups. My OS is man-made and occassionally has a bug. Sometimes I'm brain-dead and make a stupid mistake. So I'm opting for all the protection I can get, because I don't want to tell our company executives that their data is unrecoverable. Jay >>> [EMAIL PROTECTED] 11/26/02 09:49PM >>> -----------------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 **DISCLAIMER This e-mail message and any files transmitted with it are intended for the use of the individual or entity to which they are addressed and may contain information that is privileged, proprietary and confidential. If you are not the intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received this communication in error, please notify the sender and delete this e-mail message. The contents do not represent the opinion of D&E except to the extent that it relates to their official business. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jay Hostetter 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).
