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') and in the
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://www.fatcity.com San Diego, California-- Mailing list and web hosting services
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+
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+
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 want to be
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+
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+
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 !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN HTMLHEAD META content=3Dtext/html; charset=3Dgb2312= http-equiv=3DContent-Type META content=3DMSHTML 5.00.3315.2870 name=3DGENERATOR/HEAD BODY bgColor=3D#eaeaeaFONT size=3D2FONT face=3D=CB=CE=CC=E5Brooks,= Russ=A3=AC=C4=FA=BA=C3=A3=A1/FONT /FONT DIVnbsp;/DIV DIVFONT face=3D=CB=CE=CC=E5 size=3D2=A1=A1=A1=A1Can you shownbsp;us your= whitepaper? Where did you get it? /FONT/DIV DIVFONT face=3D=CB=CE=CC=E5 size=3D2nbsp;nbsp;nbsp; /FONT/DIV DIVnbsp;/DIV DIVFONT face=3D=CB=CE=CC=E5 size=3D2=3D=3D=3D=3D=3D=3D=3D=3D= 2002-10-28nbsp;14:23:00nbsp;=C4=FA=D4=DA=C0=B4=D0=C5=D6=D0=D0=B4=B5=C0=A3=BA =3D=3D=3D=3D=3D=3D=3D=3D/FONT/DIV DIVnbsp;/DIV DIVFONT size=3D2 TABLE width=3D100% TBODY TR TD width=3D100% BLOCKQUOTE style=3DBORDER-LEFT: #00 2px solid; MARGIN-LEFT: 5px;= MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px DIVSPAN class=3D791442421-28102002FONT face=3DArial size=3D2Hi,/FONT/SPAN/DIV DIVSPAN class=3D791442421-28102002FONT face=3DArial= size=3D2nbsp; I just got forwarded a whitepaper from Hitachi and Oracle,= that compairs raid 5+ and raid 1 using the TPC-C benchmark test= suite.nbsp; The claim is that raid 5 is as fast or faster.nbsp; While I'm= waiting for a comparison or raid 5+ with raid 0+1, I thought I'd take a= poll with the list.nbsp;nbsp;/FONT/SPANSPAN= class=3D791442421-28102002FONT face=3DArial size=3D2The benchmark is using the Hitachi 7700E./FONT/SPAN/DIV DIVSPAN class=3D791442421-28102002FONT face=3DArial= size=3D2nbsp; Has anyone heard other recommendations attributed to Oracle= that are pushing raid 5+ as the configuraton for unrivaled= performance?nbsp; Has new disk technology changed the general conception that raid= 0 or 0+1 provides better performance than other raid= levels?/FONT/SPAN/DIV DIVSPAN class=3D791442421-28102002FONT face=3DArial size=3D2/FONT/SPANnbsp;/DIV DIVSPAN class=3D791442421-28102002FONT face=3DArial size=3D2Thanks,/FONT/SPAN/DIV DIVSPAN class=3D791442421-28102002FONT face=3DArial = size=3D2Russ/FONT/SPAN/DIV/BLOCKQUOTE/TD/TR/TBODY/= TABLE/FONT/DIV DIV PFONT face=3D=CB=CE=CC=E5 size=3D2=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D= =3D =3D /FONT/P PFONT face=3D=CB=CE=CC=E5 size=3D2=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=D6=C2BR=C0=F1=A3=A1/FONT/P DIVnbsp;/DIV DIVFONT face=3D=CB=CE=CC=E5= size=3D2=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/FONT/DIV DIVFONT face=3D=CB=CE=CC=E5 size=3D2FONT face=3D=CB=CE=CC=E5= size=3D2=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/FONTA href=3Dmailto:chao_ping;vip.163.com[EMAIL PROTECTED]/A/FO= NT/DIV DIVFONT face=3D=CB=CE=CC=E5= size=3D2=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/FONT/DIV= DIVnbsp;/DIV/DIV/BODY/HTML --=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
Strip size recomendations for RAID5
Hi List, I'm looking for recomendations, best practice, etc about setting strip size for RAID5 arrays. We have a hybrid system (mainly OLTP) with prevelant reads operations and have limited number of disks. My question is should I merely setup the stip size equal to Oracle block size or should I set it larger considering size of maxphys. I/O operation for certain OS? I've read some articles and haven't found clear recommendations yet. We are on 8.1.7, Linux Thank you for your help. Ed -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Edward Shevtsov 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 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
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
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, for instance). EMC has a standard offering where they'll suggest RAID-S (S looks
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
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 Diego, California-- Public Internet access / Mailing Lists
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).
RAID5 question, take 2
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 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 -- 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
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 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 where a cache can never help you. Fortunately, EMC can be re-configured for RAID1+0, which
RAID5 - to split or not to split
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).
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).
RE: The good old RAID5 argument...
Thanks to all for your input. I am assuming that there will not be a problem in splitting some disks out of the RAID-5 Array for use as Redo Log storage. Martin -Original Message- Sent: 22 May 2001 15:06 To: Multiple recipients of list ORACLE-L If that is the cause, RAID 5 does not suffer the performance hits during read operations, but can prove as much as 60% performance loss than a single disk on writes. With write-back cache (accellerated controller) it can be significantly less depending on the controller. If it is truely near read only, Raid 5 is acceptable as you will get good performance but if you do decide to write it will be slower. But concidering there are very few writes, there will also be little contention. I would stick keep my logs off Raid 5 if at all possible. -Original Message- Sent: Tuesday, May 22, 2001 6:32 AM To: Multiple recipients of list ORACLE-L Guys, this is not an attempt to start that old discussion but:- I have been told to install Oracle + a DB on an IBM RS6000 box with nothing but a RAID5 disk array on it. I have explained my misgivings on this but I am told that the DB will be used mainly for read-only operations with very few modifications to the data (apart from the initial load of 100GB). Any ideas on the best approach, given the circumstances Thanks all Martin Kendall -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Martin Kendall 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Martin Kendall 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).
The good old RAID5 argument...
Guys, this is not an attempt to start that old discussion but:- I have been told to install Oracle + a DB on an IBM RS6000 box with nothing but a RAID5 disk array on it. I have explained my misgivings on this but I am told that the DB will be used mainly for read-only operations with very few modifications to the data (apart from the initial load of 100GB). Any ideas on the best approach, given the circumstances Thanks all Martin Kendall -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Martin Kendall 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: The good old RAID5 argument...
A lot of people bag raid-5 but for read only environments its fine. The initial load may suffer a bit - but for this, if you can isolate your redo logs onto something other than the raid-5 then you should see large benefits. Also if its ONLY raid-5 then that would suggest the the OS and swap/paging space will be in the mix as well. You'll want to do you best (particular with the swap) to ensure that this doesn't get out of hand.. hth connor --- Martin Kendall [EMAIL PROTECTED] wrote: Guys, this is not an attempt to start that old discussion but:- I have been told to install Oracle + a DB on an IBM RS6000 box with nothing but a RAID5 disk array on it. I have explained my misgivings on this but I am told that the DB will be used mainly for read-only operations with very few modifications to the data (apart from the initial load of 100GB). Any ideas on the best approach, given the circumstances Thanks all Martin Kendall -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Martin Kendall 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). = Connor McDonald http://www.oracledba.co.uk (mirrored at http://www.oradba.freeserve.co.uk) Some days you're the pigeon, some days you're the statue Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: =?iso-8859-1?q?Connor=20McDonald?= 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: The good old RAID5 argument...
If that is the cause, RAID 5 does not suffer the performance hits during read operations, but can prove as much as 60% performance loss than a single disk on writes. With write-back cache (accellerated controller) it can be significantly less depending on the controller. If it is truely near read only, Raid 5 is acceptable as you will get good performance but if you do decide to write it will be slower. But concidering there are very few writes, there will also be little contention. I would stick keep my logs off Raid 5 if at all possible. -Original Message- Sent: Tuesday, May 22, 2001 6:32 AM To: Multiple recipients of list ORACLE-L Guys, this is not an attempt to start that old discussion but:- I have been told to install Oracle + a DB on an IBM RS6000 box with nothing but a RAID5 disk array on it. I have explained my misgivings on this but I am told that the DB will be used mainly for read-only operations with very few modifications to the data (apart from the initial load of 100GB). Any ideas on the best approach, given the circumstances Thanks all Martin Kendall -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Martin Kendall 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: Tuning, RAID5, and fragmentation and DBWR
Thanks Dave, Don, and Patrice. It's hardware RAID, a Compaq GS140 machine, and Oracle on VMS [not my choice of OS/hardware]. Limited to one large RAID5 volume. I'd like to make the most of what's there, because for political reasons nothing else will change. Does it make any sense to increase the number of database writer processes on a system with nothing but RAID5 space? Looks like there's a bit of slowdown on checkpoints. Thanks. - Dana __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: dana mn 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: Tuning, RAID5, and fragmentation and DBWR
Hey Dana, Are you kidding? A GS140 running OVMS would be my choice of OS/Hardware! OK, OS bigotry aside... ;) The RAID5 *WILL* give you performance problems! RAID5 is the worst performer for write operations. The LGWR,and associated slave processes (and to a somewhat lesser extent, the DBWR) WILL complain LOUDLY. I hope for your sake that the GS140 at least has a lotta memory. CPU-wise, it's 2.5-to-3 times faster than our 4100 5/400, depending on MHz. CPU's not going to be your bottleneck, though. But, if that's all you have to work with, try a few of these: 1) Make your LOG_BUFFER huge. In the 10s of MB, perhaps. Redo log buffer space requests STOP your DB from running, even if for only a very short time (milliseconds to seconds). And with the long write times you can expect, you'll probably need a large LOG_BUFFER to help prevent this. 2) Consider not duplexing your redo logs and control files. KNOW THAT THIS CAN ADD CONSIDERABLE RISK OF LOSS OF DATA! Basically, by not duplexing redo logs and control files you are relying solely on the RAID5 array and it's controllers to not trash your DB. But without duplicating the I/O, you will be saving a bunch on performance. You will have to weigh the risks and benefits. Personally, I'd wait for more drives before doing this, because it's my butt on the line if the data's gone, but that's just me. 3) I'm guessing that there's the potential that a really huge DB_BLOCK_BUFFERS and a BUFFER_POOL_KEEP with table/index caching could help. You know the data and your users better than I. 4) Once you have the SGA sized properly, make sure you make use of VMS's Resident Memory Registry for the DB's SGA. See the Oracle Install Guide for more info. Be prepared to reboot if you need to make changes to the RMR. 5) Don't use Oracle7. Get at least Oracle 8.0, preferrably 8i -- 8.1.6.2.0 with patches. 6) Get Spotlight on Oracle from http://www.quest.com to help you monitor your DB performance, so you can show your bosses/co-workers why the hell you can't run an entire DB on a single RAID5. Ideally, if you could get them to just keep your datafiles on the RAID5, but have at least 5 more JBOD (non-RAIDed) drives to put the other Oracle files on -- 1 for each of 2 control files, 1 for each of 2 sets of redo logs, and at least 1 more for the archives, preferrably 2 if you can, for duplexing them as well. Yes, that's one 9GB or 18GB drive to store a single 10-100MB control file. Drives SAs nuts, unless you happen to be an SA/DBA. :) If you can, have them get you the 15K-spin Seagates. Those puppies fly! Ahh, if only in a perfect world... HTH! Good luck! Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA Disclaimer: This is just my opinion. Do what you want with it, but don't hold me, Quad/Graphics, it's subsidiaries or employees accountable for your (in)actions based on what's in this email! -Original Message- From: dana mn [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 27, 2001 11:51 To: Multiple recipients of list ORACLE-L Subject: Re: Tuning, RAID5, and fragmentation and DBWR Thanks Dave, Don, and Patrice. It's hardware RAID, a Compaq GS140 machine, and Oracle on VMS [not my choice of OS/hardware]. Limited to one large RAID5 volume. I'd like to make the most of what's there, because for political reasons nothing else will change. Does it make any sense to increase the number of database writer processes on a system with nothing but RAID5 space? Looks like there's a bit of slowdown on checkpoints. --- This message has been scanned for viruses with Trend Micro's Interscan VirusWall. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jesse, Rich 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: Tuning, RAID5, and fragmentation
I would try to benchmark the system to show where the bottleneck(s) is(are).
Probably I/O, possibly the CPU if you are using NT RAID5 instead of a
hardware solution. If your machines aren't real servers, then the disk
controller will slow things down as well, in many PCs there is one
controller for everything, even if you have two slots for plugging devices
like hard disks. It just flip flops between the two constantly.
At least benchmarking will help get rid of the perception that "Oracle is
slow".
Is this on NT? If it is RAID5 implemented at the NT level, the MS SQL
Server 7 Administration Training Kit manual, p. 128 says that its
disadvantage is that is "uses system processing resources". So you may be
overutilizing your CPU as well.
RAID5 is good for reading data, but not for writing because the parity info
has to be updated.
To avoid having to defrag or coalesce your extents, just make sure all your
extents are exactly the same size within the tablespace, and that the
extents are a multiple of your db_block_size. There is an Oracle paper on
this concept, if you want it send me an e-mail.
I guess this isn't Oracle Enterprise Edition...
Regards,
Patrice Boivin
Systems Analyst (Oracle Certified DBA)
Systems Admin Operations | Admin. et Exploit. des systmes
Technology Services| Services technologiques
Informatics Branch | Direction de l'informatique
Maritimes Region, DFO | Rgion des Maritimes, MPO
E-Mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
-Original Message-
From: dana mn [SMTP:[EMAIL PROTECTED]]
Sent: Sunday, February 25, 2001 6:20 PM
To: Multiple recipients of list ORACLE-L
Subject: Tuning, RAID5, and fragmentation
Presuming a DBA is forced to use RAID5, what elements of tuning
become
irrelevant? (in the sense that if you're stuck with RAID5, warts and
all, then trying to tune X, Y, and Z would be a waste of time /
ineffective).
Load balancing files would be one thing.. no way to put indexes and
tables on different disks (ditto redo log file members, etc) with
one
massive RAID5 volume.
What about fragmentation and coalescing? Are these still a concern
for
tablespaces located on RAID5 volumes?
Has anyone written an article about Oracle and "living with RAID5"?
I'm
finding that a customer has several Oracle databases on systems with
nothing else but RAID5 storage for everything.
Thanks very much.
- Dana
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: dana mn
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: Boivin, Patrice J
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).
Tuning, RAID5, and fragmentation
Presuming a DBA is forced to use RAID5, what elements of tuning become irrelevant? (in the sense that if you're stuck with RAID5, warts and all, then trying to tune X, Y, and Z would be a waste of time / ineffective). Load balancing files would be one thing.. no way to put indexes and tables on different disks (ditto redo log file members, etc) with one massive RAID5 volume. What about fragmentation and coalescing? Are these still a concern for tablespaces located on RAID5 volumes? Has anyone written an article about Oracle and "living with RAID5"? I'm finding that a customer has several Oracle databases on systems with nothing else but RAID5 storage for everything. Thanks very much. - Dana __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: dana mn 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: Tuning, RAID5, and fragmentation
dana mn wrote: Presuming a DBA is forced to use RAID5, what elements of tuning become irrelevant? (in the sense that if you're stuck with RAID5, warts and all, then trying to tune X, Y, and Z would be a waste of time / ineffective). Load balancing files would be one thing.. no way to put indexes and tables on different disks (ditto redo log file members, etc) with one massive RAID5 volume. What about fragmentation and coalescing? Are these still a concern for tablespaces located on RAID5 volumes? Has anyone written an article about Oracle and "living with RAID5"? I'm finding that a customer has several Oracle databases on systems with nothing else but RAID5 storage for everything. Thanks very much. - Dana __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: dana mn 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). Personally, I like the fail safe that RAID5 provides, however, it is nice if asked, to have a mixed RAID, i.e., 5 and 10. 10 for indexs. Fragmentation is generally more a function of segment extensions, that is, the more you have to extend the more likely you will fragment. If you can, plan your tablespaces so table with similar growth expectations are placed together. Ideally, the initial and next extensions should be identical. Avoid setting pctincrease to anything but zero to keep extents the same within a table space. Non contiguous extents will occur, however the hope is the extent space will be contiguous. Set the tablespace default settings appropriate for the tables they contain. Coalesce tablespaces manually rather than configuring SMON to do it, as that process requires pctincrease to be greater than zero. Tablespace fragmentation may not be perceptable, however, segment fragmentation can be depending on the activity of the table. I personally like to set minextents equal to the number of datafiles I have, and I have note less scattering of free space blocks. I can only assume then that contiguous space is being allocated. 8x offering partioned indexes and tables helps as well, and depending on the availability requirements of the instance partitioned tables may be exported and imported to really clean up an area if there was a miss on the settings for the inital sizing. I am assuming you have a number of RAID volumes and can apply archive and redo with tables that are not as active as others, which will help further distribute I/0 over the volumes. I like RAID5 since it has saved my neck on more than on occasion, however, RAID 10 (1 0) is very nice if you need the speed for indexes and can afford to loose and reconstruct an index if necessary. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Dave 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).
