Re: RAID5+
Not a silly analogy - a very good one. Yechiel Adar Mehish - Original Message - To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Sent: Wednesday, October 30, 2002 3:29 AM > As with any "cached" I/O subsystem technology (i.e. RAID-S, NetApps, etc), > please visualize a water tank. The water tank represents the cache, the > drain from the tank represents I/O throughput rates from the cache to the > hard-drives, and the faucet filling the tank represents the I/O volumes from > the server to the I/O subsystem. The faucet filling the water tank is on a > valve, so that when the tank is full, it does not overflow. Let's say that > the water tank holds 100 gallons (about 400 liters???). The faucet filling > the water tank can vary its rate, anywhere from 1 gal/min to 30 gals/min. > The drain from the water tank operates at 5 gals/min and can not be blocked > or closed. > > Got that pictured in your mind? Now for some scenarios... > > 1) What happens when the faucet is filling the water tank 24x7 at a rate > of 1 gallons/minute? No problem -- the tank never fills, so the flow into > it is never impeded... > > 2) What happens when the faucet is filling the water tank 24x7 at a rate > of 5 gallons/minute? Still no problem -- the tank never fills, so the flow > into it is never impeded... > > 3) What happens when the faucet is filling the water tank 24x7 at a rate > of 6 gallons/minute? Uh oh. In less than two hours, the water tank will > fill, causing the flow of water to be limited to the output rate of 5 > gals/min. Too bad, because we really need to move 360 gallons/hour, or 8640 > gallons/day, through this system... > > 4) What happens when the faucet is filling the water tank for an hour at > 10 gallons/minute for 15 minutes, then at 1 gal/min for the next 45 minutes? > Not a problem -- the capacity of the tank was able to hold the excess input > rate during the first 15 minutes, and whatever accumuated was drained off > before the next "spike" or surge... > > 5) What happens when the faucet tries to run for an hour at 30 gals/min, > then 11 hours at 1 gal/min? Uh oh again. We were only able to run at 30 > gals/min for about 4-5 mins, and then the flow rate got cut back to 5 > gals/min for the rest of the hour. We really wanted 1800 gals to go through > the system during that hour, but it actually took 6 hours to get all 1800 > gallons through; too bad... > > Sorry for the silly analogy, but that's how my brain works... > > - Original Message - > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > Sent: Tuesday, October 29, 2002 9:58 AM > > > Russ: > > We're using EMC Clariion disk arrays. These are using EMC's version > of RAID-5; they call it RAID-S. There is 2GB of cache if front of > the disks. They claim that the cache is write guaranteed so that > we'll never lose an update. So far, so good, and the performance > has been acceptable, except (you knew this was coming, huh?) when > we do large file moves from one tray to another, or when doing a > refresh of our SAP stage system. This activity kinda buries the > internal bus as well as the fiber, so that other users suffer. > > I guess to make a short answer even longer, this RAID-S technology > seems to work a lot better than RAID-5 used to. > > Remember, though, YMMV. > > Cheers, > Mike > > -Original Message- > Sent: Monday, October 28, 2002 5:24 PM > To: Multiple recipients of list ORACLE-L > > > Hi, > I just got forwarded a whitepaper from Hitachi and Oracle, that compairs > raid 5+ and raid 1 using the TPC-C benchmark test suite. The claim is that > raid 5 is as fast or faster. While I'm waiting for a comparison or raid 5+ > with raid 0+1, I thought I'd take a poll with the list. The benchmark is > using the Hitachi 7700E. > Has anyone heard other recommendations attributed to Oracle that are > pushing raid 5+ as the configuraton for "unrivaled performance"? Has new > disk technology changed the general conception that raid 0 or 0+1 provides > better performance than other raid levels? > > Thanks, > Russ > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Brooks, Russ > 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: Vergara, Michael (TEM) > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http:
Re: RAID5+
Tim - excellent analogy! its good one to tell da'mgrs. >>> [EMAIL PROTECTED] 10/29/02 08:29PM >>> As with any "cached" I/O subsystem technology (i.e. RAID-S, NetApps, etc), please visualize a water tank. The water tank represents the cache, the drain from the tank represents I/O throughput rates from the cache to the hard-drives, and the faucet filling the tank represents the I/O volumes from the server to the I/O subsystem. The faucet filling the water tank is on a valve, so that when the tank is full, it does not overflow. Let's say that the water tank holds 100 gallons (about 400 liters???). The faucet filling the water tank can vary its rate, anywhere from 1 gal/min to 30 gals/min. The drain from the water tank operates at 5 gals/min and can not be blocked or closed. Got that pictured in your mind? Now for some scenarios... 1) What happens when the faucet is filling the water tank 24x7 at a rate of 1 gallons/minute? No problem -- the tank never fills, so the flow into it is never impeded... 2) What happens when the faucet is filling the water tank 24x7 at a rate of 5 gallons/minute? Still no problem -- the tank never fills, so the flow into it is never impeded... 3) What happens when the faucet is filling the water tank 24x7 at a rate of 6 gallons/minute? Uh oh. In less than two hours, the water tank will fill, causing the flow of water to be limited to the output rate of 5 gals/min. Too bad, because we really need to move 360 gallons/hour, or 8640 gallons/day, through this system... 4) What happens when the faucet is filling the water tank for an hour at 10 gallons/minute for 15 minutes, then at 1 gal/min for the next 45 minutes? Not a problem -- the capacity of the tank was able to hold the excess input rate during the first 15 minutes, and whatever accumuated was drained off before the next "spike" or surge... 5) What happens when the faucet tries to run for an hour at 30 gals/min, then 11 hours at 1 gal/min? Uh oh again. We were only able to run at 30 gals/min for about 4-5 mins, and then the flow rate got cut back to 5 gals/min for the rest of the hour. We really wanted 1800 gals to go through the system during that hour, but it actually took 6 hours to get all 1800 gallons through; too bad... Sorry for the silly analogy, but that's how my brain works... - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Tuesday, October 29, 2002 9:58 AM Russ: We're using EMC Clariion disk arrays. These are using EMC's version of RAID-5; they call it RAID-S. There is 2GB of cache if front of the disks. They claim that the cache is write guaranteed so that we'll never lose an update. So far, so good, and the performance has been acceptable, except (you knew this was coming, huh?) when we do large file moves from one tray to another, or when doing a refresh of our SAP stage system. This activity kinda buries the internal bus as well as the fiber, so that other users suffer. I guess to make a short answer even longer, this RAID-S technology seems to work a lot better than RAID-5 used to. Remember, though, YMMV. Cheers, Mike -Original Message- Sent: Monday, October 28, 2002 5:24 PM To: Multiple recipients of list ORACLE-L Hi, I just got forwarded a whitepaper from Hitachi and Oracle, that compairs raid 5+ and raid 1 using the TPC-C benchmark test suite. The claim is that raid 5 is as fast or faster. While I'm waiting for a comparison or raid 5+ with raid 0+1, I thought I'd take a poll with the list. The benchmark is using the Hitachi 7700E. Has anyone heard other recommendations attributed to Oracle that are pushing raid 5+ as the configuraton for "unrivaled performance"? Has new disk technology changed the general conception that raid 0 or 0+1 provides better performance than other raid levels? Thanks, Russ -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Brooks, Russ 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: Vergara, Michael (TEM) 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
Re: RAID5+
As with any "cached" I/O subsystem technology (i.e. RAID-S, NetApps, etc), please visualize a water tank. The water tank represents the cache, the drain from the tank represents I/O throughput rates from the cache to the hard-drives, and the faucet filling the tank represents the I/O volumes from the server to the I/O subsystem. The faucet filling the water tank is on a valve, so that when the tank is full, it does not overflow. Let's say that the water tank holds 100 gallons (about 400 liters???). The faucet filling the water tank can vary its rate, anywhere from 1 gal/min to 30 gals/min. The drain from the water tank operates at 5 gals/min and can not be blocked or closed. Got that pictured in your mind? Now for some scenarios... 1) What happens when the faucet is filling the water tank 24x7 at a rate of 1 gallons/minute? No problem -- the tank never fills, so the flow into it is never impeded... 2) What happens when the faucet is filling the water tank 24x7 at a rate of 5 gallons/minute? Still no problem -- the tank never fills, so the flow into it is never impeded... 3) What happens when the faucet is filling the water tank 24x7 at a rate of 6 gallons/minute? Uh oh. In less than two hours, the water tank will fill, causing the flow of water to be limited to the output rate of 5 gals/min. Too bad, because we really need to move 360 gallons/hour, or 8640 gallons/day, through this system... 4) What happens when the faucet is filling the water tank for an hour at 10 gallons/minute for 15 minutes, then at 1 gal/min for the next 45 minutes? Not a problem -- the capacity of the tank was able to hold the excess input rate during the first 15 minutes, and whatever accumuated was drained off before the next "spike" or surge... 5) What happens when the faucet tries to run for an hour at 30 gals/min, then 11 hours at 1 gal/min? Uh oh again. We were only able to run at 30 gals/min for about 4-5 mins, and then the flow rate got cut back to 5 gals/min for the rest of the hour. We really wanted 1800 gals to go through the system during that hour, but it actually took 6 hours to get all 1800 gallons through; too bad... Sorry for the silly analogy, but that's how my brain works... - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Tuesday, October 29, 2002 9:58 AM Russ: We're using EMC Clariion disk arrays. These are using EMC's version of RAID-5; they call it RAID-S. There is 2GB of cache if front of the disks. They claim that the cache is write guaranteed so that we'll never lose an update. So far, so good, and the performance has been acceptable, except (you knew this was coming, huh?) when we do large file moves from one tray to another, or when doing a refresh of our SAP stage system. This activity kinda buries the internal bus as well as the fiber, so that other users suffer. I guess to make a short answer even longer, this RAID-S technology seems to work a lot better than RAID-5 used to. Remember, though, YMMV. Cheers, Mike -Original Message- Sent: Monday, October 28, 2002 5:24 PM To: Multiple recipients of list ORACLE-L Hi, I just got forwarded a whitepaper from Hitachi and Oracle, that compairs raid 5+ and raid 1 using the TPC-C benchmark test suite. The claim is that raid 5 is as fast or faster. While I'm waiting for a comparison or raid 5+ with raid 0+1, I thought I'd take a poll with the list. The benchmark is using the Hitachi 7700E. Has anyone heard other recommendations attributed to Oracle that are pushing raid 5+ as the configuraton for "unrivaled performance"? Has new disk technology changed the general conception that raid 0 or 0+1 provides better performance than other raid levels? Thanks, Russ -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Brooks, Russ 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: Vergara, Michael (TEM) 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 wan
RE: RAID5+
Russ: We're using EMC Clariion disk arrays. These are using EMC's version of RAID-5; they call it RAID-S. There is 2GB of cache if front of the disks. They claim that the cache is write guaranteed so that we'll never lose an update. So far, so good, and the performance has been acceptable, except (you knew this was coming, huh?) when we do large file moves from one tray to another, or when doing a refresh of our SAP stage system. This activity kinda buries the internal bus as well as the fiber, so that other users suffer. I guess to make a short answer even longer, this RAID-S technology seems to work a lot better than RAID-5 used to. Remember, though, YMMV. Cheers, Mike -Original Message- Sent: Monday, October 28, 2002 5:24 PM To: Multiple recipients of list ORACLE-L Hi, I just got forwarded a whitepaper from Hitachi and Oracle, that compairs raid 5+ and raid 1 using the TPC-C benchmark test suite. The claim is that raid 5 is as fast or faster. While I'm waiting for a comparison or raid 5+ with raid 0+1, I thought I'd take a poll with the list. The benchmark is using the Hitachi 7700E. Has anyone heard other recommendations attributed to Oracle that are pushing raid 5+ as the configuraton for "unrivaled performance"? Has new disk technology changed the general conception that raid 0 or 0+1 provides better performance than other raid levels? Thanks, Russ -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Brooks, Russ 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: Vergara, Michael (TEM) 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: RAID5+
Thanks Greg. I'd be very interested in what you find. To address the other responses, 1. the raid-1 configuration had 24 mirrored disk sets (48 spindles total). The raid-5 configuration also had a total of 48 spindles. 2. I'll be glad to send the whitepaper to anyone who requests it. Russ -Original Message- Sent: Tuesday, October 29, 2002 7:47 AM To: Brooks, Russ Russ- The hardware architects within our shop have pointed out similar performance information to me... We are using HDS 9960 boxes, and the file systems will be setup as a RAID5 on the SAN as compared to RAID0+1 on the EMC frames that we have.. I believe the RAID5 issue is related on to aHDS disk sub-system.. I'm trying to get some info from our HDS rep now. greg -Original Message- Sent: Monday, October 28, 2002 5:24 PM To: Multiple recipients of list ORACLE-L Hi, I just got forwarded a whitepaper from Hitachi and Oracle, that compairs raid 5+ and raid 1 using the TPC-C benchmark test suite. The claim is that raid 5 is as fast or faster. While I'm waiting for a comparison or raid 5+ with raid 0+1, I thought I'd take a poll with the list. The benchmark is using the Hitachi 7700E. Has anyone heard other recommendations attributed to Oracle that are pushing raid 5+ as the configuraton for "unrivaled performance"? Has new disk technology changed the general conception that raid 0 or 0+1 provides better performance than other raid levels? Thanks, Russ -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Brooks, Russ 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: RAID5+
This is a multi-part message in MIME format. --=002_Dragon751246812548_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Brooks, Russ=A3=AC=C4=FA=BA=C3=A3=A1 =A1=A1=A1=A1Can you show us your whitepaper? Where did you get it? =3D=3D=3D=3D=3D=3D=3D=3D 2002-10-28 14:23:00 =C4=FA=D4=DA=C0=B4=D0=C5=D6=D0=D0=B4=B5=C0=A3=BA =3D=3D=3D=3D=3D=3D=3D=3D Hi, I just got forwarded a whitepaper from Hitachi and Oracle, that= compairs raid 5+ and raid 1 using the TPC-C benchmark test= suite. The claim is that raid 5 is as fast or faster. While= I'm waiting for a comparison or raid 5+ with raid 0+1, I thought= I'd take a poll with the list. The benchmark is using the= Hitachi 7700E. Has anyone heard other recommendations attributed to Oracle= that are pushing raid 5+ as the configuraton for "unrivaled= performance"? Has new disk technology changed the general= conception that raid 0 or 0+1 provides better performance than= other raid levels? Thanks, Russ =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=D6=C2 =C0=F1=A3=A1 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1chao_ping [EMAIL PROTECTED] =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12002-10-29 --=002_Dragon751246812548_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable Brooks,= Russ=A3=AC=C4=FA=BA=C3=A3=A1 =A1=A1=A1=A1Can you show us your= whitepaper? Where did you get it? =3D=3D=3D=3D=3D=3D=3D=3D= 2002-10-28 14:23:00 =C4=FA=D4=DA=C0=B4=D0=C5=D6=D0=D0=B4=B5=C0=A3=BA =3D=3D=3D=3D=3D=3D=3D=3D Hi, I just got forwarded a whitepaper from Hitachi and Oracle,= that compairs raid 5+ and raid 1 using the TPC-C benchmark test= suite. The claim is that raid 5 is as fast or faster. While I'm= waiting for a comparison or raid 5+ with raid 0+1, I thought I'd take a= poll with the list. The benchmark is using the Hitachi 7700E. Has anyone heard other recommendations attributed to Oracle= that are pushing raid 5+ as the configuraton for "unrivaled= performance"? Has new disk technology changed the general conception that raid= 0 or 0+1 provides better performance than other raid= levels? Thanks, Russ =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D= =3D =3D =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=D6=C2=C0=F1=A3=A1 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1chao_ping =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1mailto:chao_ping@;vip.163.com">[EMAIL PROTECTED] =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12002-10-29= --=002_Dragon751246812548_=-- -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: chao_ping 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: RAID5+
And the date of the paper. Excuse my ignorance: I know what RAID 5 is, but what is 5+ ? -Original Message-From: Anjo Kolk [mailto:[EMAIL PROTECTED]]Sent: Monday, October 28, 2002 4:59 PMTo: Multiple recipients of list ORACLE-LSubject: RE: RAID5+ What would interest me is the number of disks used in each test. Anjo. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Brooks, RussSent: Monday, October 28, 2002 11:24 PMTo: Multiple recipients of list ORACLE-LSubject: RAID5+ Hi, I just got forwarded a whitepaper from Hitachi and Oracle, that compairs raid 5+ and raid 1 using the TPC-C benchmark test suite. The claim is that raid 5 is as fast or faster. While I'm waiting for a comparison or raid 5+ with raid 0+1, I thought I'd take a poll with the list. The benchmark is using the Hitachi 7700E. Has anyone heard other recommendations attributed to Oracle that are pushing raid 5+ as the configuraton for "unrivaled performance"? Has new disk technology changed the general conception that raid 0 or 0+1 provides better performance than other raid levels? Thanks, Russ
RE: RAID5+
What would interest me is the number of disks used in each test. Anjo. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Brooks, Russ Sent: Monday, October 28, 2002 11:24 PM To: Multiple recipients of list ORACLE-L Subject: RAID5+ Hi, I just got forwarded a whitepaper from Hitachi and Oracle, that compairs raid 5+ and raid 1 using the TPC-C benchmark test suite. The claim is that raid 5 is as fast or faster. While I'm waiting for a comparison or raid 5+ with raid 0+1, I thought I'd take a poll with the list. The benchmark is using the Hitachi 7700E. Has anyone heard other recommendations attributed to Oracle that are pushing raid 5+ as the configuraton for "unrivaled performance"? Has new disk technology changed the general conception that raid 0 or 0+1 provides better performance than other raid levels? Thanks, Russ
RE: RAID5 question, take 2
This actually depends on the drives, if they are cheetahs, yeah you will be pinched. But if it is anything but perhaps not. I would hope they would be, but very possible they are not. "Walking on water and developing software from a specification are easy if both are frozen." Christopher R. Spence Oracle DBA Fuelspot -Original Message- Sent: Monday, June 11, 2001 12:20 AM To: Multiple recipients of list ORACLE-L Gary, Here is where we have to know more details. a 9 drive array on a single channel sounds like your peak I/O rate for reads would be throttled by the controller channel speed. Now, if the SCSI interface is ultra 160/m, and the drive support a sustained rate of 20 MB/sec - you're not pinched. But if the RAID controller interface is FC - and only 100MB/sec - you're going to be seriously pinched during index range, fast full and full table scans - bulk reads. Are you using fine-grained striping - such that a FTS will be using the multiblock_read_count and will hit all 8 drives (net)? what's your: db_block_size multiblock_read_count OS I/O size If your OS I/O size is 128 KB and your db_block_size is 16 KB then a multiblock_read_count = 8 and a stripe size of 128 KB - or 16 KB depth per stripe member. (as the parity drive is ignored) and each member in the stripe contributes one block in each read request for a FTS. SAME methodology would imply that your OS I/O size has been cranked up to 1 MB, and that your stripe size is also 1 MB. On a FC interface - the transfer speed for a 1 MB read would be 10 ms - on par with the average seek time. But SAME is not geared for RAID 5 - as RAID 5 supports having the drive heads out of sync to satisfy mutliple independent requests concurrently. SAME is geared more for RAID 0+1 - where the drive heads in an array move in unison - with all drives returning the results of one request at a time. What do you want to return for your read requests - (1 db_block, multiblock_read_count, 1 MB)? This will depend entirely on the access paths that are used in YOUR application. Basically - a 3 drive RAID 5 array is useless. Don't even consider it. Better off to have a single RAID 1 volume with a hot spare. If I were to break the 9 drives up (it would be as a RAID 0+1 of 4 drives each) - it would be as a 5 drive and 4 drive array (assuming that 2 channels are available). if most of the read requests have been driven by an index - and only one block is being requested - the 9 disk RAID 5 config is the way to go - as seek time will dominate transfer time. just my opinion. Paul Gary Weber wrote: > > The reply below was a great post! As were replies prior to it. But, none of > the replies were for the original question. > > The issue in hand is not which raid level to use or whether to use at all. > > The question is, and I promise this is the very last time I post it: given 9 > hard drives dedicated for RAID5, should data reside on 6 drives via volume > group A and indexes on the other 3 drives via volume group B, or should data > and indexes be placed on all 9 drives via one volume group? The data is > absolutely static. > > Gary > > - Original Message - > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > Sent: Sunday, June 10, 2001 7:15 PM > > > Since RAID5 means that data is striped, of course read performance is OK. > As > > soon as you talk write performance, however, RAID5 becomes something of a > joke > > since it was invented back in the 70's to offer a cheap alternative to the > fast, > > extremely expensive disks offered by IBM back then. So the focus was on > limiting > > the number of disks. Today, where disks in general are cheap and caches > are > > expensive, I really have a hard time figuring out why people buy RAID5 > (few > > disks, cache required to compensate for the horrible write penalty) > instead of > > RAID1+0 (more disks, no cache required). And I have a hard time figuring > out why > > the vendors are pushing RAID5 solutions, if RAID1+0 means selling more > disks to > > the customers :-). The answer, of course, is that they are making money on > > caches, not disks. > > > > Technically speaking, RAID1+0 will always be better than RAID5, of course. > Oh, > > they will try to compensate with caches and talk of RAID3 techniques and > what > > have you. RAID1+0 is still superior to RAID5 in any techinal aspect. > > > > It becomes really absurd when you look at the SAN offerings on the market. > For > > instance, IBM's Shark only offers the customer the choice between JBOD > (Just a > > Bunch Of Disks, ie., Non-RAID) and RAID5. IBM has a red book out regarding > this > > and on page 127 out of 228 or so you can read the headline: "JBOD or > RAID5?" and > > that's when it dawns on you that Shark (which is very expensive) cannot > under > > any circumstances be configured for anything else than RAID5 or non-RAID. > > Workaround: Place a file system on top that at least can be striped > (Veritas,
RE: RAID5 question, take 2
Mogens, the super-market analogy does not apply - this is for SQL Server database. I'm not sure how far I'll be able to tweak that rdbms, hence my question did not contain many details - it was simply a request for opinions. Btw, to sum up current responses: Option 1: split 9 drives to separate data/index I/O Option 2: stripe everything across 9 drives for better throughput. So, methinks the Windoz admin is going to try both ways and monitor i/o... Thanks to Paul, Jared, Christopher for great input, Gary Weber Senior DBA Charles Jones, LLC 609-530-1144, ext 5529 -Original Message- Nørgaard Sent: Monday, June 11, 2001 3:15 AM To: Multiple recipients of list ORACLE-L Indeed, Paul. Very good points. Gary - you're asking us to determine the number of bags we'll need at the supermarket without knowing what we're going to buy. If we had IO-stats for your datafiles/tablespaces, ie reads/writes and their size, and your availability requirements on the system, we could tell you more. Paul Drake wrote: > Gary, > > Here is where we have to know more details. > > a 9 drive array on a single channel sounds like your peak I/O rate for > reads would be throttled by the controller channel speed. Now, if the > SCSI interface is ultra 160/m, and the drive support a sustained rate of > 20 MB/sec - you're not pinched. But if the RAID controller interface is > FC - and only 100MB/sec - you're going to be seriously pinched during > index range, fast full and full table scans - bulk reads. > > Are you using fine-grained striping - such that a FTS will be using the > multiblock_read_count and will hit all 8 drives (net)? > what's your: > db_block_size > multiblock_read_count > OS I/O size > > If your OS I/O size is 128 KB > and your db_block_size is 16 KB > then a multiblock_read_count = 8 > and a stripe size of 128 KB - or 16 KB depth per stripe member. > (as the parity drive is ignored) > and each member in the stripe contributes one block in each read request > for a FTS. > > SAME methodology would imply that your OS I/O size has been cranked up > to 1 MB, and that your stripe size is also 1 MB. On a FC interface - the > transfer speed for a 1 MB read would be 10 ms - on par with the average > seek time. > But SAME is not geared for RAID 5 - as RAID 5 supports having the drive > heads out of sync to satisfy mutliple independent requests concurrently. > SAME is geared more for RAID 0+1 - where the drive heads in an array > move in unison - with all drives returning the results of one request at > a time. > > What do you want to return for your read requests - (1 db_block, > multiblock_read_count, 1 MB)? > This will depend entirely on the access paths that are used in YOUR > application. > > Basically - a 3 drive RAID 5 array is useless. Don't even consider it. > Better off to have a single RAID 1 volume with a hot spare. If I were to > break the 9 drives up (it would be as a RAID 0+1 of 4 drives each) > - it would be as a 5 drive and 4 drive array (assuming that 2 channels > are available). > > if most of the read requests have been driven by an index - and only one > block is being requested - the 9 disk RAID 5 config is the way to go - > as seek time will dominate transfer time. > > just my opinion. > > Paul -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Gary Weber INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists 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: RAID5 question, take 2
Indeed, Paul. Very good points. Gary - you're asking us to determine the number of bags we'll need at the supermarket without knowing what we're going to buy. If we had IO-stats for your datafiles/tablespaces, ie reads/writes and their size, and your availability requirements on the system, we could tell you more. Paul Drake wrote: > Gary, > > Here is where we have to know more details. > > a 9 drive array on a single channel sounds like your peak I/O rate for > reads would be throttled by the controller channel speed. Now, if the > SCSI interface is ultra 160/m, and the drive support a sustained rate of > 20 MB/sec - you're not pinched. But if the RAID controller interface is > FC - and only 100MB/sec - you're going to be seriously pinched during > index range, fast full and full table scans - bulk reads. > > Are you using fine-grained striping - such that a FTS will be using the > multiblock_read_count and will hit all 8 drives (net)? > what's your: > db_block_size > multiblock_read_count > OS I/O size > > If your OS I/O size is 128 KB > and your db_block_size is 16 KB > then a multiblock_read_count = 8 > and a stripe size of 128 KB - or 16 KB depth per stripe member. > (as the parity drive is ignored) > and each member in the stripe contributes one block in each read request > for a FTS. > > SAME methodology would imply that your OS I/O size has been cranked up > to 1 MB, and that your stripe size is also 1 MB. On a FC interface - the > transfer speed for a 1 MB read would be 10 ms - on par with the average > seek time. > But SAME is not geared for RAID 5 - as RAID 5 supports having the drive > heads out of sync to satisfy mutliple independent requests concurrently. > SAME is geared more for RAID 0+1 - where the drive heads in an array > move in unison - with all drives returning the results of one request at > a time. > > What do you want to return for your read requests - (1 db_block, > multiblock_read_count, 1 MB)? > This will depend entirely on the access paths that are used in YOUR > application. > > Basically - a 3 drive RAID 5 array is useless. Don't even consider it. > Better off to have a single RAID 1 volume with a hot spare. If I were to > break the 9 drives up (it would be as a RAID 0+1 of 4 drives each) > - it would be as a 5 drive and 4 drive array (assuming that 2 channels > are available). > > if most of the read requests have been driven by an index - and only one > block is being requested - the 9 disk RAID 5 config is the way to go - > as seek time will dominate transfer time. > > just my opinion. > > Paul > > Gary Weber wrote: > > > > The reply below was a great post! As were replies prior to it. But, none of > > the replies were for the original question. > > > > The issue in hand is not which raid level to use or whether to use at all. > > > > The question is, and I promise this is the very last time I post it: given 9 > > hard drives dedicated for RAID5, should data reside on 6 drives via volume > > group A and indexes on the other 3 drives via volume group B, or should data > > and indexes be placed on all 9 drives via one volume group? The data is > > absolutely static. > > > > Gary > > > > - Original Message - > > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > > Sent: Sunday, June 10, 2001 7:15 PM > > > > > Since RAID5 means that data is striped, of course read performance is OK. > > As > > > soon as you talk write performance, however, RAID5 becomes something of a > > joke > > > since it was invented back in the 70's to offer a cheap alternative to the > > fast, > > > extremely expensive disks offered by IBM back then. So the focus was on > > limiting > > > the number of disks. Today, where disks in general are cheap and caches > > are > > > expensive, I really have a hard time figuring out why people buy RAID5 > > (few > > > disks, cache required to compensate for the horrible write penalty) > > instead of > > > RAID1+0 (more disks, no cache required). And I have a hard time figuring > > out why > > > the vendors are pushing RAID5 solutions, if RAID1+0 means selling more > > disks to > > > the customers :-). The answer, of course, is that they are making money on > > > caches, not disks. > > > > > > Technically speaking, RAID1+0 will always be better than RAID5, of course. > > Oh, > > > they will try to compensate with caches and talk of RAID3 techniques and > > what > > > have you. RAID1+0 is still superior to RAID5 in any techinal aspect. > > > > > > It becomes really absurd when you look at the SAN offerings on the market. > > For > > > instance, IBM's Shark only offers the customer the choice between JBOD > > (Just a > > > Bunch Of Disks, ie., Non-RAID) and RAID5. IBM has a red book out regarding > > this > > > and on page 127 out of 228 or so you can read the headline: "JBOD or > > RAID5?" and > > > that's when it dawns on you that Shark (which is very expensive) cannot > > under > > > any circumstances be configured for anything else
Re: RAID5 question, take 2
Gary, Here is where we have to know more details. a 9 drive array on a single channel sounds like your peak I/O rate for reads would be throttled by the controller channel speed. Now, if the SCSI interface is ultra 160/m, and the drive support a sustained rate of 20 MB/sec - you're not pinched. But if the RAID controller interface is FC - and only 100MB/sec - you're going to be seriously pinched during index range, fast full and full table scans - bulk reads. Are you using fine-grained striping - such that a FTS will be using the multiblock_read_count and will hit all 8 drives (net)? what's your: db_block_size multiblock_read_count OS I/O size If your OS I/O size is 128 KB and your db_block_size is 16 KB then a multiblock_read_count = 8 and a stripe size of 128 KB - or 16 KB depth per stripe member. (as the parity drive is ignored) and each member in the stripe contributes one block in each read request for a FTS. SAME methodology would imply that your OS I/O size has been cranked up to 1 MB, and that your stripe size is also 1 MB. On a FC interface - the transfer speed for a 1 MB read would be 10 ms - on par with the average seek time. But SAME is not geared for RAID 5 - as RAID 5 supports having the drive heads out of sync to satisfy mutliple independent requests concurrently. SAME is geared more for RAID 0+1 - where the drive heads in an array move in unison - with all drives returning the results of one request at a time. What do you want to return for your read requests - (1 db_block, multiblock_read_count, 1 MB)? This will depend entirely on the access paths that are used in YOUR application. Basically - a 3 drive RAID 5 array is useless. Don't even consider it. Better off to have a single RAID 1 volume with a hot spare. If I were to break the 9 drives up (it would be as a RAID 0+1 of 4 drives each) - it would be as a 5 drive and 4 drive array (assuming that 2 channels are available). if most of the read requests have been driven by an index - and only one block is being requested - the 9 disk RAID 5 config is the way to go - as seek time will dominate transfer time. just my opinion. Paul Gary Weber wrote: > > The reply below was a great post! As were replies prior to it. But, none of > the replies were for the original question. > > The issue in hand is not which raid level to use or whether to use at all. > > The question is, and I promise this is the very last time I post it: given 9 > hard drives dedicated for RAID5, should data reside on 6 drives via volume > group A and indexes on the other 3 drives via volume group B, or should data > and indexes be placed on all 9 drives via one volume group? The data is > absolutely static. > > Gary > > - Original Message - > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > Sent: Sunday, June 10, 2001 7:15 PM > > > Since RAID5 means that data is striped, of course read performance is OK. > As > > soon as you talk write performance, however, RAID5 becomes something of a > joke > > since it was invented back in the 70's to offer a cheap alternative to the > fast, > > extremely expensive disks offered by IBM back then. So the focus was on > limiting > > the number of disks. Today, where disks in general are cheap and caches > are > > expensive, I really have a hard time figuring out why people buy RAID5 > (few > > disks, cache required to compensate for the horrible write penalty) > instead of > > RAID1+0 (more disks, no cache required). And I have a hard time figuring > out why > > the vendors are pushing RAID5 solutions, if RAID1+0 means selling more > disks to > > the customers :-). The answer, of course, is that they are making money on > > caches, not disks. > > > > Technically speaking, RAID1+0 will always be better than RAID5, of course. > Oh, > > they will try to compensate with caches and talk of RAID3 techniques and > what > > have you. RAID1+0 is still superior to RAID5 in any techinal aspect. > > > > It becomes really absurd when you look at the SAN offerings on the market. > For > > instance, IBM's Shark only offers the customer the choice between JBOD > (Just a > > Bunch Of Disks, ie., Non-RAID) and RAID5. IBM has a red book out regarding > this > > and on page 127 out of 228 or so you can read the headline: "JBOD or > RAID5?" and > > that's when it dawns on you that Shark (which is very expensive) cannot > under > > any circumstances be configured for anything else than RAID5 or non-RAID. > > Workaround: Place a file system on top that at least can be striped > (Veritas, > > for instance). > > > > EMC has a standard offering where they'll suggest RAID-S (S looks a lot > like 5, > > doesn't it?) and the standard answer if write performance is not good > enough is: > > "Add more cache". Well, we had a customer who reached 32 GB of cache (not > MB, > > mind you, but GB) and write performance was still bad (of course) for > restores > > and recovery operations and file copying and all those things wh
Re: RAID5 question, take 2
On Sunday 10 June 2001 20:15, Gary Weber wrote: > The question is, and I promise this is the very last time I post it: given > 9 hard drives dedicated for RAID5, should data reside on 6 drives via > volume group A and indexes on the other 3 drives via volume group B, or > should data and indexes be placed on all 9 drives via one volume group? The > data is absolutely static. > > Gary Given the choices, I would consider whether the access is heavily weighted towards full table scans. If so, the 9 disk array would sound good. If more heavily weighted toward table access via indexes, then separating the data and indexes would get the nod. HTH Jared -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists 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: RAID5 - to split or not to split
On Sunday 10 June 2001 16:15, Mogens Nørgaard wrote: > It becomes really absurd when you look at the SAN offerings on the market. > For instance, IBM's Shark only offers the customer the choice between JBOD > (Just a Bunch Of Disks, ie., Non-RAID) and RAID5. IBM has a red book out > regarding this and on page 127 out of 228 or so you can read the headline: > "JBOD or RAID5?" and that's when it dawns on you that Shark (which is very > expensive) cannot under any circumstances be configured for anything else > than RAID5 or non-RAID. Workaround: Place a file system on top that at > least can be striped (Veritas, for instance). I've worked on the Shark systems. They're are pretty fast, especially when you're used to 5 year old Sun SSA's. :) It was disconcerting to discover that the only HA disk array was RAID 5. I didn't have any say in the vendor however. It is important to work with the vendor and your storage admin on the configuration of these, otherwise they *will* give you one very large disk volume to work with. Their idea of benchmarking is 'how fast can I read a single file'. I'm not making this up. :-( One thing to watch for on their throughput numbers as well. You have to do the math, cuz they won't do it for you. If you examine them carefully by examining the max disk throughput and the cache throughput, you'll see that the only way to achieve their claimed throughput rate is with a near 100% cache hit rate. And we *know* about cache hit rates, don't we folks. ;) I didn't get the chance to stress test this system, it would be nice to hear from someone that has pushed the Shark to the limit. Jared -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists 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: RAID5 - to split or not to split
Since RAID5 means that data is striped, of course read performance is OK. As soon as you talk write performance, however, RAID5 becomes something of a joke since it was invented back in the 70's to offer a cheap alternative to the fast, extremely expensive disks offered by IBM back then. So the focus was on limiting the number of disks. Today, where disks in general are cheap and caches are expensive, I really have a hard time figuring out why people buy RAID5 (few disks, cache required to compensate for the horrible write penalty) instead of RAID1+0 (more disks, no cache required). And I have a hard time figuring out why the vendors are pushing RAID5 solutions, if RAID1+0 means selling more disks to the customers :-). The answer, of course, is that they are making money on caches, not disks. Technically speaking, RAID1+0 will always be better than RAID5, of course. Oh, they will try to compensate with caches and talk of RAID3 techniques and what have you. RAID1+0 is still superior to RAID5 in any techinal aspect. It becomes really absurd when you look at the SAN offerings on the market. For instance, IBM's Shark only offers the customer the choice between JBOD (Just a Bunch Of Disks, ie., Non-RAID) and RAID5. IBM has a red book out regarding this and on page 127 out of 228 or so you can read the headline: "JBOD or RAID5?" and that's when it dawns on you that Shark (which is very expensive) cannot under any circumstances be configured for anything else than RAID5 or non-RAID. Workaround: Place a file system on top that at least can be striped (Veritas, for instance). EMC has a standard offering where they'll suggest RAID-S (S looks a lot like 5, doesn't it?) and the standard answer if write performance is not good enough is: "Add more cache". Well, we had a customer who reached 32 GB of cache (not MB, mind you, but GB) and write performance was still bad (of course) for restores and recovery operations and file copying and all those things where a cache can never help you. Fortunately, EMC can be re-configured for RAID1+0, which the customer finally did, and all went well. They could then return the expensive cache and save some money :). Same problem with HP (Hitachi) - they'll try to pursuade you to buy a very expensive RAID5 system. It's like trying to talk you into paying a lot of money for a WWII Spitfire, claiming that the avionics have been upgraded a great deal and that for the general user, this is much better than todays aircraft :-))). We have lots of horror stories like this regarding RAID5. Of course it's good enough in a lot of situations. But you should know the reason why it's good enough. And the moment you have to restore or recover anything, you will discover the true price (factor 4, usually) of RAID5, namely the write penalty. No amount of cache can help you in those situations. Christopher Spence wrote: > Static data raid 5 is a very good option, it has great read performance and > very inexpensive. > > "Walking on water and developing software from a specification are easy if > both are frozen." > > Christopher R. Spence > Oracle DBA > Fuelspot > > -Original Message- > Sent: Friday, June 08, 2001 6:20 PM > To: Multiple recipients of list ORACLE-L > > My apologies, I should've been much more explicit... This is for a specific > tablespace, with VERY static data... > > > Size of data, size of stripe size/width are very important in detirmining > > how many spindles to use and if they will be effective. Using a > write-back > > caching controller (and not saturating it's cache) will generally write > out > > data trying to take advantage of the full stripe width. Reads are > effected > > in this manor as well. > > Yeah...I'm thinking 80/20 Read/Write for Controller cache, but again, this > is not the puzzle > > Case: one tablespace (regardless of how many datafiles) for data, one tbs > for indexes. 9 hard drives to deal with, with RAID 5 as level of choice. > Should DATA reside on 6-drive volume and indexes on separate 3-drive volume, > or should these two tbs live on same physical R5 volume? > > Gary > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Gary Weber > INET: [EMAIL PROTECTED] > > Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 > San Diego, California-- Public Internet access / Mailing Lists > > 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: Christopher Spence > INET: [EMAIL PROTECTED] > > Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 > San
RE: RAID5 - to split or not to split
Static data raid 5 is a very good option, it has great read performance and very inexpensive. "Walking on water and developing software from a specification are easy if both are frozen." Christopher R. Spence Oracle DBA Fuelspot -Original Message- Sent: Friday, June 08, 2001 6:20 PM To: Multiple recipients of list ORACLE-L My apologies, I should've been much more explicit... This is for a specific tablespace, with VERY static data... > Size of data, size of stripe size/width are very important in detirmining > how many spindles to use and if they will be effective. Using a write-back > caching controller (and not saturating it's cache) will generally write out > data trying to take advantage of the full stripe width. Reads are effected > in this manor as well. Yeah...I'm thinking 80/20 Read/Write for Controller cache, but again, this is not the puzzle Case: one tablespace (regardless of how many datafiles) for data, one tbs for indexes. 9 hard drives to deal with, with RAID 5 as level of choice. Should DATA reside on 6-drive volume and indexes on separate 3-drive volume, or should these two tbs live on same physical R5 volume? Gary -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Gary Weber INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists 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: Christopher Spence INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists 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: RAID5 - to split or not to split
My apologies, I should've been much more explicit... This is for a specific tablespace, with VERY static data... > Size of data, size of stripe size/width are very important in detirmining > how many spindles to use and if they will be effective. Using a write-back > caching controller (and not saturating it's cache) will generally write out > data trying to take advantage of the full stripe width. Reads are effected > in this manor as well. Yeah...I'm thinking 80/20 Read/Write for Controller cache, but again, this is not the puzzle Case: one tablespace (regardless of how many datafiles) for data, one tbs for indexes. 9 hard drives to deal with, with RAID 5 as level of choice. Should DATA reside on 6-drive volume and indexes on separate 3-drive volume, or should these two tbs live on same physical R5 volume? Gary -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Gary Weber INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists 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: RAID5 - to split or not to split
What about redo logs, rbs, temp, system, exe's? Number of spindles doesn't necessarly mean faster performance. Depends on the data and the controller. If you set 6 disks with 64 Kb stripe size, your stripe width is 384 Kb with Raid 0. If your not using a write-back caching controller, you will need to use that size transaction or better to fully use the capacity of the volume performance wise. If you send a 32Kb transaction, your only going to use a single disk. Or if you do 400 KB stripe width, your going to write to all the disks once and one disk twice to handle the second set of data in the stripe width. Size of data, size of stripe size/width are very important in detirmining how many spindles to use and if they will be effective. Using a write-back caching controller (and not saturating it's cache) will generally write out data trying to take advantage of the full stripe width. Reads are effected in this manor as well. "Walking on water and developing software from a specification are easy if both are frozen." Christopher R. Spence Oracle DBA Fuelspot -Original Message- Sent: Friday, June 08, 2001 4:26 PM To: Multiple recipients of list ORACLE-L All, 9 drives + hot spare Would you stripe 6 for data and other 3 for indexes, or use one 9-drive volume for both? One side of me says the more spindles the merrier - keep them together, the other side says - separate data and indexes. The third, evil SA side is waiting for the first two to make up their minds... Help Gary Weber Senior DBA Charles Jones, LLC 609-530-1144, ext 5529 -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Gary Weber INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists 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: Christopher Spence INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists 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).
