RE: redo log file setup with mirrored drives
> -Original Message- > We hope by > eliminating redo log multiplex, but with OS mirroring we > can speed up this loading process. -- We deal with this by: 1. Hardware mirroring of archives. 2. Archives go to device on which no other I/O is present and, if there is a difference in the speed of devices in the system (for example 7200 rpm drives and 1 rpm drives), the archives get the faster drives. 3. Alternating online redo between different devices, the theory being that when a log switch occurs then the log being archived will be on a device that is not being written to, so (we hope) the reads from that device will be faster. Even after making the archiving as fast as possible, you still might be required to have a very large amount of online redo available in order to handle the backlog built up during peak times. We have found that archiving is so much slower than online redo writing in a case like this, that we can Oracle multiplex online redo to hardware RAID (redundant redundancy) and the archiving will still be the slow point. I wouldn't worry about the fault tolerance aspect of online redo mirroring, since whatever would blow away both sides of a hardware or OS mirror would also blow away both sides of Oracle multiplexing. However, my experience has shown that, as far as any debate on how one mirrors online redo the point is moot. My experience is that, in this scenario, the archiving is what will snag things. -- 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).
Re: redo log file setup with mirrored drives
Hello Guang >From your note about weekly one day long import I think that you are dealing with DW. 1) Am I correct? 2) Are there other updates to the database while the import is in progress? Yechiel Adar Mehish - Original Message - To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Sent: Wednesday, November 27, 2002 6:34 PM > Hi: > > I am the original poster and thanks for all your inputs on this topic. Now I > know more about what "might" happen if something goes wrong. The main > purpose of we thinking doing this was to gain some performance. We have a > weekly schema imp process which takes about a day to finish. We hope by > eliminating redo log multiplex, but with OS mirroring we can speed up this > loading process. We are going to do some tests to see how much we would > gain. > > BTW, our unix system admin is very good, I can trust him that we would never > delete any redo log files or any oracle files. > > So the only "practical danger" is that the redo file might get corrupted. > This means we need to balance the "performance" vs "file curruption". > > Thanks again. > > Guang > > > > _ > MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. > http://join.msn.com/?page=features/virus > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Guang Mei > 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). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Yechiel Adar 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).
RE: redo log file setup with mirrored drives
I script and test as well. But sometimes you can't think of every possible problem. My point wasn't to have a contest of who had worse problems or who had a problem that the other didn't. merely that sometimes hardware mirroring is not the be-all/end-all solution. We all could swap war stories for hours. But I need a beer before I start that, that's thirsty work :) --- Stephen Lee <[EMAIL PROTECTED]> wrote: > > -Original Message- > > have you NEVER accidentally, at 3AM, after having been woken from a > > sound sleep to a crisis that needs to be fixed RIGHT NOW, > > made a typo? > > > > Actually no. But we usually script our actions and test the scripts > prior > to doing anything in production. As a sys admin, I've restored > enough > casualties of the "rm -rf *" command to be rather careful about it > myself. > > > Um, I have. > > I was wondering if anyone had. But I could turn this around too and > give an > example of when duplexing the redos failed to save me. One so-called > patch > that Compaq released for Tru64 actually caused disk writes to be > unreliable > (OH MY GOD!!). And we wound up with a G.D. mess in spite of the > redos being > duplexed all nice and official. > -- > 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). > __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rachel Carmichael 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).
RE: redo log file setup with mirrored drives
> -Original Message- > Sorry if you took offense at some attempted humor. -- No offense taken here. I've always worked in large environments where there were multiple DBA's, sys admins, developers, and testers. One cannot be easily offended and survive in these environments. You have your debates; break a few chairs in the ensuing fight; then go out for lunch. It's all a nice break from the daily routine. -- 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).
RE: redo log file setup with mirrored drives
Good point! I'll take that one step further and suggest "select * from v$instance" as that will also display the node that the DB is on. Good to know, especially if you have 3rd party apps that name the DBs the same. Rich Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA > -Original Message- > From: Rachel Carmichael [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 27, 2002 9:54 AM > To: Multiple recipients of list ORACLE-L > Subject: RE: redo log file setup with mirrored drives > [snip] > it. I've learned to ALWAYS do a "pwd" at the OS level and a "select * > from v$database" when I am connected to a database. [snip] -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jesse, Rich 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).
RE: redo log file setup with mirrored drives
> I was amazed at the non-security that seems to be rampant out there, > with mischievous people running around deleting files. I kept reading > about it and thinking you've got to be kidding. Steven, have you NEVER accidentally, at 3AM, after having been woken from a sound sleep to a crisis that needs to be fixed RIGHT NOW, made a typo? if not, wow, I'm in awe. All you need to do is forget which directory you are in... and not include the path when do you an "rm". I've done it. I've learned to ALWAYS do a "pwd" at the OS level and a "select * from v$database" when I am connected to a database. In any case, in another post you asked if anyone had ever lost a database due to hardware mirroring. Um, I have. Okay, we recovered the database via Data Unloader, but essentially it was lost, because we couldn't open the database. The current redo log and its hardware mirror failed. To this day, I don't know why, there was a lot of finger pointing going on, including "you mirrored it onto itself" and "you had both disks on the same controller and it failed". Regardless of WHY it happened, it happened. We could not switch the current log, we could not open the database, we couldn't access anything. Tech support finally mentioned that there was this product that field support had... and two DAYS later I had a database again. In this case, Oracle mirroring (no, we were not using multiplexed redo logs) would possibly have saved us time, money and I might have had a few less gray hairs. Rachel --- Stephen Lee <[EMAIL PROTECTED]> wrote: > > -Original Message- > > 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 > > I do it because it's a CYA thing of doing it by the book. I've > listened to > a lot of debates about database things and been amazed at the > reasoning > behind why people do what they do. I've lost count of how many > debates I've > heard about extent sizes and numbers of extents, the majority of it > pure > superstition. In the end, no matter how scientific or superstitious > the > reasoning, CYA trumps all. So that's why I do it. But, in fact, > this whole > thing about corrupt blocks is flawed reasoning. If an OS cannot do > disk > writes in an absolutely reliable way, then the OS is unusable. The > bad > writes will occur throughout the system. This includes when your > logs get > archived and writes to data files. Put those two together and what > do you > get? > > Actually, there is one advantage to hardware mirroring of archives. > On > Oracle duplexed archives, my experience is that it is inevitable that > you > will have one destination fill up while the other one doesn't. In > which > case Oracle quietly quits using the one destination even after the > files are > removed during a backup. I wrote a script to monitor when Oracle has > stopped duplexing archived logs for those where we don't have > hardware > mirroring. > > I was amazed at the non-security that seems to be rampant out there, > with > mischievous people running around deleting files. I kept reading > about it > and thinking you've got to be kidding. > -- > 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). > __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rachel Carmichael 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).
Re: redo log file setup with mirrored drives
Hi: I am the original poster and thanks for all your inputs on this topic. Now I know more about what "might" happen if something goes wrong. The main purpose of we thinking doing this was to gain some performance. We have a weekly schema imp process which takes about a day to finish. We hope by eliminating redo log multiplex, but with OS mirroring we can speed up this loading process. We are going to do some tests to see how much we would gain. BTW, our unix system admin is very good, I can trust him that we would never delete any redo log files or any oracle files. So the only "practical danger" is that the redo file might get corrupted. This means we need to balance the "performance" vs "file curruption". Thanks again. Guang _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Guang Mei 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).
RE: redo log file setup with mirrored drives
> -Original Message- > have you NEVER accidentally, at 3AM, after having been woken from a > sound sleep to a crisis that needs to be fixed RIGHT NOW, > made a typo? > Actually no. But we usually script our actions and test the scripts prior to doing anything in production. As a sys admin, I've restored enough casualties of the "rm -rf *" command to be rather careful about it myself. > Um, I have. I was wondering if anyone had. But I could turn this around too and give an example of when duplexing the redos failed to save me. One so-called patch that Compaq released for Tru64 actually caused disk writes to be unreliable (OH MY GOD!!). And we wound up with a G.D. mess in spite of the redos being duplexed all nice and official. -- 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).
RE: redo log file setup with mirrored drives
Settle down. ";)" means "joking". Sheeesh. And last I checked, base 2 is still a natural integer, although I'm obviously an idiot as I only took up to pre-calc. Sorry if you took offense at some attempted humor. Rich Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA > -Original Message- > From: Stephen Lee [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 26, 2002 5:26 PM > To: Multiple recipients of list ORACLE-L > Subject: RE: redo log file setup with mirrored drives > > > -Original Message- > > Of course, you'll need Tom Kyte's binary conversion program > > here to execute this very weak proof: > > Yeah, well this didn't come from Stephen Hawking. And let's > not forget the > part about "in the natural integers". Homey didn't take a > bunch of 5000 and > 6000 level math courses and come away entirely untrained. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jesse, Rich 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).
RE: redo log file setup with mirrored drives
> -Original Message- > 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 I do it because it's a CYA thing of doing it by the book. I've listened to a lot of debates about database things and been amazed at the reasoning behind why people do what they do. I've lost count of how many debates I've heard about extent sizes and numbers of extents, the majority of it pure superstition. In the end, no matter how scientific or superstitious the reasoning, CYA trumps all. So that's why I do it. But, in fact, this whole thing about corrupt blocks is flawed reasoning. If an OS cannot do disk writes in an absolutely reliable way, then the OS is unusable. The bad writes will occur throughout the system. This includes when your logs get archived and writes to data files. Put those two together and what do you get? Actually, there is one advantage to hardware mirroring of archives. On Oracle duplexed archives, my experience is that it is inevitable that you will have one destination fill up while the other one doesn't. In which case Oracle quietly quits using the one destination even after the files are removed during a backup. I wrote a script to monitor when Oracle has stopped duplexing archived logs for those where we don't have hardware mirroring. I was amazed at the non-security that seems to be rampant out there, with mischievous people running around deleting files. I kept reading about it and thinking you've got to be kidding. -- 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).
Re: redo log file setup with mirrored drives
Amen to that! Stephen, It seems like you keep this discussion on just for the sake of discussion. And also, it seems like you live in some kind of "ideal" world, where hardware and software is 100% error-free and is 100% "bullet-proof" and "fool-proof", and SAs, DBAs, developers, etc... never make a single mistake. Good for you! But most of us live in real world, where everything listed above is not happening (yes, we, DBAs, make mistakes too). So, we are TRYING to make our databases as reliable as possible (in particular situation), using all the features provided with oracle db including RedoLogs multiplexing (of course, using some common sense, and not creating 20 members in one group). Igor Neyman, OCP DBA [EMAIL PROTECTED] - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Wednesday, November 27, 2002 8:43 AM > >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 mirro
RE: redo log file setup with mirrored drives
>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 EVIIL 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
RE: redo log file setup with mirrored drives
I suppose I should come clean on this deal and admit that we do indeed have Oracle duplex the redo files. The only time we would not do this is if some user with sufficient bureaucratic power has some suckwad app and was demanding that everything be done to bump up performance. If it comes to that, we'll do it and not lose any sleep over it. Even though we have Oracle duplexing, we still have had it happen that some storage array maintenance person went in and managed to hose up both sides of the duplex. Of course, this doesn't result in the loss of the database, but rather the loss of some data. But wasn't it fun debate. What I found interesting was that nobody brought up what to do about the archived logs -- how much mirroring is "enough" and how long to wait before shoving them off onto tape. Now, the loss of these babies can get you into deep doodoo. But, here again, we must sometimes make compromises for the sake of a rotten application and overtaxed hardware. At our shop here, we are forced to rely on hardware mirroring of archives. We have no choice. You just try to get as many people to sign off on the setup as you can. None of this changes the truth of anything I wrote. I have found hardware and software mirroring to be extremely reliable. I have never lost a file to it, and it has saved my butt many times. At one place I worked, we regularly tested yanking out power cords, I/O cables, storage array drawers, anything we could think of, while the database and application were running full blast. It never failed once (except for early Veritas on Motorola 88K which was a mess). -- 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).
RE: redo log file setup with mirrored drives
-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 EVIIL 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).
RE: redo log file setup with mirrored drives
I agree. And this is why Oracle has the capability to manage many redo log members in the same group and many copies of the control file. It does not offer the same for regular data files. Regards, Waleed -Original Message- Sent: Tuesday, November 26, 2002 6:05 PM To: Multiple recipients of list ORACLE-L "While all this is true, this is all based on the forgone conclusion that mirroring outside Oracle will result in file loss. It is that conclusion with which I disagree." 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. It is simply irresponsible to dismiss it out of hand. Sure you might cite performance concerns, but for most databases in most enterprises redo log multiplexing does not constitute a performance bottleneck. Your position appears to be that hardware mirroring, software mirroring, RAID hardware, and the controllers feeding them all are infallible. Multiplexing redo logs is simply a form of insurance, and should be considered a default element of Oracle database design. Steve -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Steve McClure 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Khedr, Waleed 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).
RE: redo log file setup with mirrored drives
"While all this is true, this is all based on the forgone conclusion that mirroring outside Oracle will result in file loss. It is that conclusion with which I disagree." 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. It is simply irresponsible to dismiss it out of hand. Sure you might cite performance concerns, but for most databases in most enterprises redo log multiplexing does not constitute a performance bottleneck. Your position appears to be that hardware mirroring, software mirroring, RAID hardware, and the controllers feeding them all are infallible. Multiplexing redo logs is simply a form of insurance, and should be considered a default element of Oracle database design. Steve -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Steve McClure 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).
RE: redo log file setup with mirrored drives
> -Original Message- > Of course, you'll need Tom Kyte's binary conversion program > here to execute this very weak proof: Yeah, well this didn't come from Stephen Hawking. And let's not forget the part about "in the natural integers". Homey didn't take a bunch of 5000 and 6000 level math courses and come away entirely untrained. -- 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).
RE: redo log file setup with mirrored drives
Theory: 2 + 2 = 15 SELECT 2 + 2 FROM DUAL; SELECT 1+1 + 1+1 FROM DUAL; SELECT TO_CHAR(1)||TO_CHAR(1)||TO_CHAR(1)||TO_CHAR(1) FROM DUAL; SELECT to_dec(TO_CHAR(1)||TO_CHAR(1)||TO_CHAR(1)||TO_CHAR(1),2) FROM DUAL; Of course, you'll need Tom Kyte's binary conversion program here to execute this very weak proof: http://govt.oracle.com/~tkyte/hexdec/hexdec.sql ;) Rich Beer-free for almost 17 hours. Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA > -Original Message- > From: Fink, Dan [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 26, 2002 2:25 PM > To: Multiple recipients of list ORACLE-L > Subject: RE: redo log file setup with mirrored drives > > > Stephen, > Nothing is gained by personal attacks in this forum. > This forum is > intended to be a learning experience for all (myself > included). I suggest > that you review the archived list and examine the quality of > posts by Kirti, > Jared, et.al. They speak for themselves. > > BTW, 2 + 2 does equal 15 for very large values of 2 and > very small > values of 15. ;) > Dan Fink > -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jesse, Rich 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).
RE: redo log file setup with mirrored drives
> -Original Message- > Stephen, > Nothing is gained by personal attacks in this forum. Please enlighten me. Exactly what personal attack was made? -- 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).
RE: redo log file setup with mirrored drives
On Tue, 2002-11-26 at 10:50, Stephen Lee wrote: And from another post ... > > Because my OS/hardware IS reliable a corrupted > > log file that is mirrored outside of Oracle will be corrupt - > > the original is corrupt, so is the mirror. > > In one sentence you have claimed that your "OS/hardware IS reliable" and > talk about it corrupting log files. Are we having a problem with the > definition of "reliable" here? > Hmmm..I don't think the original poster is saying the OS corrupted the log file. The post is merely mentioning that if a non-oracle mirrored redo log was to become corrupted(by any means) the mirror copy will be corrupted as well, but an Oracle multiplexed copy might not be. > This goes back to an old post of using NT versus Unix. If you recall, my > reply was that security on NT was so bad, that it is not a good choice. > This stems primarily from the fact that NT is essentially a single-user OS, > built around the administrator, with some multi-user extensions kludged on > to support non-administrator pseudo-users. > Going back to the original post on this topic: There was nothing that > suggested they were in a pathological environment. For what it's worth, > when we had databases on NT, we followed a strict directory naming routine > and made it clear to the NT admins that any directory with certain names > were not to be touched. If anything needed to be done with those > directories, they were to page us. Last time I checked most SA's have root access. Therefore they can delete(accidentally or otherwise) any of your Oracle files. Granted, Joe Schmoe user won't be able to do this, but how often is user Joe Schmoe logging on to an NT Oracle box? So I would say your NT point is moot. The same security precautions from admins is needed in a Unix environment as well. If you read the original post again, the poster asked if there was any "danger" to just using OS mirroring. I think the potential dangers were addressed and the question was answered. I don't think anyone was questioning the reliability of OS mirroring, but as an administrator, I think it is in my best interest to take worst case scenarios into account. > Concluding remarks: > While the scenarios of gloom and doom that have been painted by some seem to > be credible, I've have yet to witness, in my years of personal experience as > a sys admin and a database admin the unreliability that some claim to exist. > That being the case, I must go with the arrangement that I think offers > fault tolerance with the best performance. As with any database installation the old "it depends" works every time. There are best practices, but each situation is different and has different requirements for reliability, uptime,security, etc. If just using OS mirroring is the best choice for your installation that's great, but it might not be the best choice for all. -Brian -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Brian Haas 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).
RE: redo log file setup with mirrored drives
Precisely why I name all Oracle files with ".dbf" extension. Who ever thought naming a redo log with ".log" was a good idea??? With all DB files the same, it's a simple rule: Don't touch .dbf files. No confusion there. If you need to mess with them (backups, etc), write and test a script. Try to prevent yourself from making a mistake. "If at first you don't succeed, you had better be in test." My $.02, Rich Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA > -Original Message- > From: Fink, Dan [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 26, 2002 10:05 AM > To: Multiple recipients of list ORACLE-L > Subject: RE: redo log file setup with mirrored drives > [snip] > not protect against the accidental deletion of the file. I > have had to deal > with situations where people deleted the redo logs (disk > space at 90%, let's > clear out the log files...). Another copy on another device [snip] -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jesse, Rich 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).
RE: redo log file setup with mirrored drives
Stephen, Nothing is gained by personal attacks in this forum. This forum is intended to be a learning experience for all (myself included). I suggest that you review the archived list and examine the quality of posts by Kirti, Jared, et.al. They speak for themselves. BTW, 2 + 2 does equal 15 for very large values of 2 and very small values of 15. ;) Dan Fink -Original Message- Sent: Tuesday, November 26, 2002 11:50 AM To: Multiple recipients of list ORACLE-L I was going to let the differences of opinion stand, but I suppose this requires an answer. > -Original Message- > > Redo and archived redo logs are the most important files in > the database. > Lose a datafile? You can still recover the database. > Lose all controlfiles? They can be recreated. > Lose a single redo entry? Your recovery is terminated. Yes, there are > unsupported methods to bypass this condition, but they are > kludges and may > be very, very expensive. While all this is true, this is all based on the forgone conclusion that mirroring outside Oracle will result in file loss. It is that conclusion with which I disagree. > So, why do I still multiplex my redo logs (even on my 'test' > Win2k databases > at home)? O/S level mirroring protects against some failures, > but it does > not protect against the accidental deletion of the file. I > have had to deal > with situations where people deleted the redo logs (disk > space at 90%, let's > clear out the log files...). Another copy on another device > (usually with a > separate controller), saved the database. In your case, your problems are not related to mirroring technique. Yours deal with how best to handle pathological situations, shops with non-existent security, and incompetent administration. That's certainly a valid topic for discussion, but isn't the topic of my discussion. > > Considering the small size of the redo logs and their > critical importance to > the database, I'll both multiplex (oracle) and mirror (o/s). > The redo logs on our production databases are from 100 Mb to 1 Gb. Hence, the issue is not just one of how bullet proof things can be made, but one of performance too. > > "1. This is pure speculation." > Kirti is one of the many people on this list who has shown > time and time > again that he does not engage in "pure speculation". In this case he was. He was speculating about how OS's and RAIDing hardware go about their business and how reliably they do it. He was speculating that, if one does not mirror via Oracle, then one will get bad redo files. As is commonly the case, there is some tendency to assign human qualities to computer things; things such as "knowing" about something; and the capacity to reason and make decisions; and the ability to have a moment of inattention when it just "forgot" to do something right. Computers (other than ones named HAL) don't work this way. The original question was posed by someone who we can safely assume is NOT running a database on some crapola OS with rickety, unreliable, and outdated hardware (in which case, I don't think ANY kind of mirroring will help). If this discussion were ten years ago, you might have a point. But this isn't ten years ago. > While a skeptical > attitude is good and helps you develop, I tend to accept > Kirti's posts (and > Cary's, Tim's, Jared's, Robert's, and others on the 10 list) > at face value > until I put together a test case and can prove it or disprove it. It sounds to me like you don't intend to do either. If Stephen Hawking attempted to tell me that, in the natural integers, 2 + 2 = 15, I would know immediately that what he was telling me was incorrect. I have no knowledge of Kirti's expertise in computer operating systems and hardware. But I do know the facts. In my past life as a Unix sys admin, I worked with OS's and RAID hardware enough to know that file maintenance isn't the roll of the dice that you are making it out to be. The suggestion that an EMC array can't be trusted to properly mirror files raises the question: Why did you spend a million bucks on it then? And from another post ... > Because my OS/hardware IS reliable a corrupted > log file that is mirrored outside of Oracle will be corrupt - > the original is corrupt, so is the mirror. In one sentence you have claimed that your "OS/hardware IS reliable" and talk about it corrupting log files. Are we having a problem with the definition of "reliable" here? And from another post > Ditto. > > The biggest problem with non-Oracle-mirrored redo log is > a personnel issue. > > Take it from someone who's experienced a SA deleting all > files from a 500 Gig DW during the middle of the day. This goes back to an old post of using NT versus Unix. If you recall, my reply was that security on NT was so bad, that it is not a good choice. This stems primarily from the fact that NT is essentially a single-user OS, built around the administrator, wit
RE: redo log file setup with mirrored drives
I was going to let the differences of opinion stand, but I suppose this requires an answer. > -Original Message- > > Redo and archived redo logs are the most important files in > the database. > Lose a datafile? You can still recover the database. > Lose all controlfiles? They can be recreated. > Lose a single redo entry? Your recovery is terminated. Yes, there are > unsupported methods to bypass this condition, but they are > kludges and may > be very, very expensive. While all this is true, this is all based on the forgone conclusion that mirroring outside Oracle will result in file loss. It is that conclusion with which I disagree. > So, why do I still multiplex my redo logs (even on my 'test' > Win2k databases > at home)? O/S level mirroring protects against some failures, > but it does > not protect against the accidental deletion of the file. I > have had to deal > with situations where people deleted the redo logs (disk > space at 90%, let's > clear out the log files...). Another copy on another device > (usually with a > separate controller), saved the database. In your case, your problems are not related to mirroring technique. Yours deal with how best to handle pathological situations, shops with non-existent security, and incompetent administration. That's certainly a valid topic for discussion, but isn't the topic of my discussion. > > Considering the small size of the redo logs and their > critical importance to > the database, I'll both multiplex (oracle) and mirror (o/s). > The redo logs on our production databases are from 100 Mb to 1 Gb. Hence, the issue is not just one of how bullet proof things can be made, but one of performance too. > > "1. This is pure speculation." > Kirti is one of the many people on this list who has shown > time and time > again that he does not engage in "pure speculation". In this case he was. He was speculating about how OS's and RAIDing hardware go about their business and how reliably they do it. He was speculating that, if one does not mirror via Oracle, then one will get bad redo files. As is commonly the case, there is some tendency to assign human qualities to computer things; things such as "knowing" about something; and the capacity to reason and make decisions; and the ability to have a moment of inattention when it just "forgot" to do something right. Computers (other than ones named HAL) don't work this way. The original question was posed by someone who we can safely assume is NOT running a database on some crapola OS with rickety, unreliable, and outdated hardware (in which case, I don't think ANY kind of mirroring will help). If this discussion were ten years ago, you might have a point. But this isn't ten years ago. > While a skeptical > attitude is good and helps you develop, I tend to accept > Kirti's posts (and > Cary's, Tim's, Jared's, Robert's, and others on the 10 list) > at face value > until I put together a test case and can prove it or disprove it. It sounds to me like you don't intend to do either. If Stephen Hawking attempted to tell me that, in the natural integers, 2 + 2 = 15, I would know immediately that what he was telling me was incorrect. I have no knowledge of Kirti's expertise in computer operating systems and hardware. But I do know the facts. In my past life as a Unix sys admin, I worked with OS's and RAID hardware enough to know that file maintenance isn't the roll of the dice that you are making it out to be. The suggestion that an EMC array can't be trusted to properly mirror files raises the question: Why did you spend a million bucks on it then? And from another post ... > Because my OS/hardware IS reliable a corrupted > log file that is mirrored outside of Oracle will be corrupt - > the original is corrupt, so is the mirror. In one sentence you have claimed that your "OS/hardware IS reliable" and talk about it corrupting log files. Are we having a problem with the definition of "reliable" here? And from another post > Ditto. > > The biggest problem with non-Oracle-mirrored redo log is > a personnel issue. > > Take it from someone who's experienced a SA deleting all > files from a 500 Gig DW during the middle of the day. This goes back to an old post of using NT versus Unix. If you recall, my reply was that security on NT was so bad, that it is not a good choice. This stems primarily from the fact that NT is essentially a single-user OS, built around the administrator, with some multi-user extensions kludged on to support non-administrator pseudo-users. Going back to the original post on this topic: There was nothing that suggested they were in a pathological environment. For what it's worth, when we had databases on NT, we followed a strict directory naming routine and made it clear to the NT admins that any directory with certain names were not to be touched. If anything needed to be done with those directories, they were to page us. Concluding rem
RE: redo log file setup with mirrored drives
Ditto.
The biggest problem with non-Oracle-mirrored redo log is
a personnel issue.
Take it from someone who's experienced a SA deleting all
files from a 500 Gig DW during the middle of the day.
Jared
"Fink, Dan" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
11/26/2002 08:04 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject: RE: redo log file setup with mirrored drives
"Pending further evidence to the contrary, I'll take mirroring external to
Oracle as the better choice."
Redo and archived redo logs are the most important files in the database.
Lose a datafile? You can still recover the database.
Lose all controlfiles? They can be recreated.
Lose a single redo entry? Your recovery is terminated. Yes, there are
unsupported methods to bypass this condition, but they are kludges and may
be very, very expensive.
So, why do I still multiplex my redo logs (even on my 'test' Win2k
databases
at home)? O/S level mirroring protects against some failures, but it does
not protect against the accidental deletion of the file. I have had to
deal
with situations where people deleted the redo logs (disk space at 90%,
let's
clear out the log files...). Another copy on another device (usually with
a
separate controller), saved the database.
Considering the small size of the redo logs and their critical importance
to
the database, I'll both multiplex (oracle) and mirror (o/s).
"1. This is pure speculation."
Kirti is one of the many people on this list who has shown time and time
again that he does not engage in "pure speculation". While a skeptical
attitude is good and helps you develop, I tend to accept Kirti's posts
(and
Cary's, Tim's, Jared's, Robert's, and others on the 10 list) at face value
until I put together a test case and can prove it or disprove it.
Dan Fink
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Fink, Dan
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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
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).
RE: redo log file setup with mirrored drives
Also stand by that "corrupted write will be restricted to just the affected member" Hence one can simply overwrite the BAD (Corrupted) member with the Good one -Original Message- Sent: Tuesday, November 26, 2002 9:40 PM To: Multiple recipients of list ORACLE-L Sure... What I posted came from my discussions with others and from various resources on Metalink and from Oracle Training Classes. Note #45042.1 titled Archiver Best Practices summarizes it all. Agreed, that RAID and disk technologies have improved over the years, however, I would still continue using multiple redo log members on any OS. Redo log files serve different purpose in an Oracle database, and so should be treated differently. - Kirti -Original Message- Sent: Tuesday, November 26, 2002 9:24 AM To: Multiple recipients of list ORACLE-L If I may offer another view > -Original Message- > Having multiple redo log members has its advantages. The > archiver process 'knows' these multiple members and it will > optimize the archiving process, Is there any supporting documentation about this "optimizing"? Are you saying that the makers of hardware-based and software-based RAID have not "optimized" their RAIDing? If I were a betting man, I would bet that a hardware device can do mirrored writes faster than Oracle. > but it does not know about > the mirrored copies of these logs. Know? What does it need to "know"? Mirroring is mirroring. A mirrored copy either exists, or it doesn't. "Knowing" about it has no effect on the existence of the copy. Computer operations aren't based on faith (although there are many times we are tempted to question that). > The other important thing > to know is that Oracle issues a separate write for these log > members And this improves performance? > and in an unlikely event a corrupted write will be > restricted to just the affected member. Such corruption will > affect all the mirrored copies. Two things: 1. This is pure speculation. 2. If your OS can't do reliable disk writes, then it's time to get a new OS. A database consists of more than just redo logs. It also has pesky little things like data files. Should we have Oracle mirror those too rather than rely on RAIDing for fault tolerance? Why would we expect the OS to reliably write data files and detect hardware errors when it can't reliably maintain redo logs? Pending further evidence to the contrary, I'll take mirroring external to Oracle as the better choice. -- 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Deshpande, Kirti 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: VIVEK_SHARMA 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).
RE: redo log file setup with mirrored drives
Sure... What I posted came from my discussions with others and from various resources on Metalink and from Oracle Training Classes. Note #45042.1 titled Archiver Best Practices summarizes it all. Agreed, that RAID and disk technologies have improved over the years, however, I would still continue using multiple redo log members on any OS. Redo log files serve different purpose in an Oracle database, and so should be treated differently. - Kirti -Original Message- Sent: Tuesday, November 26, 2002 9:24 AM To: Multiple recipients of list ORACLE-L If I may offer another view > -Original Message- > Having multiple redo log members has its advantages. The > archiver process 'knows' these multiple members and it will > optimize the archiving process, Is there any supporting documentation about this "optimizing"? Are you saying that the makers of hardware-based and software-based RAID have not "optimized" their RAIDing? If I were a betting man, I would bet that a hardware device can do mirrored writes faster than Oracle. > but it does not know about > the mirrored copies of these logs. Know? What does it need to "know"? Mirroring is mirroring. A mirrored copy either exists, or it doesn't. "Knowing" about it has no effect on the existence of the copy. Computer operations aren't based on faith (although there are many times we are tempted to question that). > The other important thing > to know is that Oracle issues a separate write for these log > members And this improves performance? > and in an unlikely event a corrupted write will be > restricted to just the affected member. Such corruption will > affect all the mirrored copies. Two things: 1. This is pure speculation. 2. If your OS can't do reliable disk writes, then it's time to get a new OS. A database consists of more than just redo logs. It also has pesky little things like data files. Should we have Oracle mirror those too rather than rely on RAIDing for fault tolerance? Why would we expect the OS to reliably write data files and detect hardware errors when it can't reliably maintain redo logs? Pending further evidence to the contrary, I'll take mirroring external to Oracle as the better choice. -- 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Deshpande, Kirti 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).
RE: redo log file setup with mirrored drives
Addressing the corruption issue, Kirti's statement is not speculation. Because my OS/hardware IS reliable a corrupted log file that is mirrored outside of Oracle will be corrupt - the original is corrupt, so is the mirror. If I mirror my log files using Oracle, logfile A may be corrupt, but log file B may NOT be corrupt, depending on what caused the corruption (if it is some Oracle bug, then you're out of luck either way). We had a case where all files that were open on a particular file system became corrupt. The cause was related to a bug in the cluster software during a system crash. This file system was RAID 0+1 - which meant that my file was "safe", corruption and all. Fortunately, I had Oracle mirroring the redo log on another file system which was unaffected by the crash. Jay >>> [EMAIL PROTECTED] 11/26/02 10:23AM >>> If I may offer another view > -Original Message- > Having multiple redo log members has its advantages. The > archiver process 'knows' these multiple members and it will > optimize the archiving process, Is there any supporting documentation about this "optimizing"? Are you saying that the makers of hardware-based and software-based RAID have not "optimized" their RAIDing? If I were a betting man, I would bet that a hardware device can do mirrored writes faster than Oracle. > but it does not know about > the mirrored copies of these logs. Know? What does it need to "know"? Mirroring is mirroring. A mirrored copy either exists, or it doesn't. "Knowing" about it has no effect on the existence of the copy. Computer operations aren't based on faith (although there are many times we are tempted to question that). > The other important thing > to know is that Oracle issues a separate write for these log > members And this improves performance? > and in an unlikely event a corrupted write will be > restricted to just the affected member. Such corruption will > affect all the mirrored copies. Two things: 1. This is pure speculation. 2. If your OS can't do reliable disk writes, then it's time to get a new OS. A database consists of more than just redo logs. It also has pesky little things like data files. Should we have Oracle mirror those too rather than rely on RAIDing for fault tolerance? Why would we expect the OS to reliably write data files and detect hardware errors when it can't reliably maintain redo logs? Pending further evidence to the contrary, I'll take mirroring external to Oracle as the better choice. **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).
RE: redo log file setup with mirrored drives
"Pending further evidence to the contrary, I'll take mirroring external to Oracle as the better choice." Redo and archived redo logs are the most important files in the database. Lose a datafile? You can still recover the database. Lose all controlfiles? They can be recreated. Lose a single redo entry? Your recovery is terminated. Yes, there are unsupported methods to bypass this condition, but they are kludges and may be very, very expensive. So, why do I still multiplex my redo logs (even on my 'test' Win2k databases at home)? O/S level mirroring protects against some failures, but it does not protect against the accidental deletion of the file. I have had to deal with situations where people deleted the redo logs (disk space at 90%, let's clear out the log files...). Another copy on another device (usually with a separate controller), saved the database. Considering the small size of the redo logs and their critical importance to the database, I'll both multiplex (oracle) and mirror (o/s). "1. This is pure speculation." Kirti is one of the many people on this list who has shown time and time again that he does not engage in "pure speculation". While a skeptical attitude is good and helps you develop, I tend to accept Kirti's posts (and Cary's, Tim's, Jared's, Robert's, and others on the 10 list) at face value until I put together a test case and can prove it or disprove it. Dan Fink -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Fink, Dan 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).
RE: redo log file setup with mirrored drives
If I may offer another view > -Original Message- > Having multiple redo log members has its advantages. The > archiver process 'knows' these multiple members and it will > optimize the archiving process, Is there any supporting documentation about this "optimizing"? Are you saying that the makers of hardware-based and software-based RAID have not "optimized" their RAIDing? If I were a betting man, I would bet that a hardware device can do mirrored writes faster than Oracle. > but it does not know about > the mirrored copies of these logs. Know? What does it need to "know"? Mirroring is mirroring. A mirrored copy either exists, or it doesn't. "Knowing" about it has no effect on the existence of the copy. Computer operations aren't based on faith (although there are many times we are tempted to question that). > The other important thing > to know is that Oracle issues a separate write for these log > members And this improves performance? > and in an unlikely event a corrupted write will be > restricted to just the affected member. Such corruption will > affect all the mirrored copies. Two things: 1. This is pure speculation. 2. If your OS can't do reliable disk writes, then it's time to get a new OS. A database consists of more than just redo logs. It also has pesky little things like data files. Should we have Oracle mirror those too rather than rely on RAIDing for fault tolerance? Why would we expect the OS to reliably write data files and detect hardware errors when it can't reliably maintain redo logs? Pending further evidence to the contrary, I'll take mirroring external to Oracle as the better choice. -- 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).
RE: redo log file setup with mirrored drives
Having multiple redo log members has its advantages. The archiver process 'knows' these multiple members and it will optimize the archiving process, but it does not know about the mirrored copies of these logs. The other important thing to know is that Oracle issues a separate write for these log members and in an unlikely event a corrupted write will be restricted to just the affected member. Such corruption will affect all the mirrored copies. - Kirti -Original Message- Sent: Monday, November 25, 2002 7:54 PM To: Multiple recipients of list ORACLE-L Hi: We have oracle 8173 running on Sun Solaris box. The current redo files are: /oracle/oradata/RPT1/redo101.log /oracle/oradata/RPT1/redo201.log /oracle/oradata/RPT1/redo301.log /oracle/u01/oradata/RPT1/redo102.log /oracle/u01/oradata/RPT1/redo202.log /oracle/u01/oradata/RPT1/redo302.log The members of the same group are in different disks. Now we are going to set up new disks soon and they are mirrored drives (the sys admin told me). Because they are already mirrored, can I just create ONE redo member for each group (instead of two) in the new setup? Is there any "danger" to do that? TIA. Guang _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Guang Mei 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Deshpande, Kirti 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).
redo log file setup with mirrored drives
Hi: We have oracle 8173 running on Sun Solaris box. The current redo files are: /oracle/oradata/RPT1/redo101.log /oracle/oradata/RPT1/redo201.log /oracle/oradata/RPT1/redo301.log /oracle/u01/oradata/RPT1/redo102.log /oracle/u01/oradata/RPT1/redo202.log /oracle/u01/oradata/RPT1/redo302.log The members of the same group are in different disks. Now we are going to set up new disks soon and they are mirrored drives (the sys admin told me). Because they are already mirrored, can I just create ONE redo member for each group (instead of two) in the new setup? Is there any "danger" to do that? TIA. Guang _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Guang Mei 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).
