RE: disk subsystem performance question
I just started a couple days ago at this client. They're using Hitachi technology in the QA and prod environment with 181G disk. I asked the SA twice and he confirmed the 181 G disk. I'll ask more details to the SA as soon as I know him better. --- Deshpande, Kirti [EMAIL PROTECTED] a écrit : John, I agree with the 18GB drives implementation and pushing for more 'parity groups'. That's what we did. Now, HDS was back to sell more disk and backup soultions to us. I am not sure what we have agreed to purchase. A cache of 10GB for the 400GB database is nothing. I bet you will have tables larger than the cache size. A single FTS on these tables will flush the whole cache... We have 16GB cache (I think I remember that right, and is the max for 7700E), and that is not enough for several servers that the cabinet supports. - Kirti -Original Message- Sent: Wednesday, April 10, 2002 7:08 PM To: Multiple recipients of list ORACLE-L Thanks for all the replies. We are determined to lay out the data as well as we can across the disks we are about to purchase - with the goal of striping across array groups and smaller, faster drives. The real argument for us is 18GB vs. 73GB disk drives and how we can stripe. The Hitachi is configured into groups of 4 physical disks called parity groups and you can choose RAID 5 or RAID 1+0 for that 4 disk set.If you have 73GB drives in a 4-disk RAID 5 configuration you get roughly 219GB of usable space in each parity group (this is what we are being told is the best option for us).This means our heavily concurrently accessed 400GB production database goes on 2 parity groups (2 sets of 4 disks). To me, this sounds like a nightmare waiting to happen and we are trying to stop it.The 18GB drives are less capacity but we can get ourselves spread over more parity groups for better concurrency. We do have about 10GB of cache but it is being shared across the enterprise with various other applications. We as a DBA group are really trying to sell the 18GB RAID 1+0 drive solution especially after reading the groups' experiences - unfortunately we are fighting a lot of marketing hype. If anyone has additional experiences or feedback with Hitachi or EMC they would like to share or comments (agree/disagree) with my thoughts, I'd love to hear them. I'm open for learning! Thanks, John Dailey Oracle DBA ING Americas - Application Services Atlanta, GA Don GranamanTo: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] granaman@coxcc: .netSubject: Re: disk subsystem performance question Sent by: root@fatcity. com 04/10/2002 01:08 PM Please respond to ORACLE-L Short answer - NO! Nobody's disk subsystem is so fast that no intelligence is required in the layout. This is common vendor blather and one of the most popular myths. I have been hearing it for at least six years - and it still isn't true. Layout still makes a huge difference. RAID levels still make a huge difference. Cache won't solve all your problems (it does help though). I've redone the disk layout on some of the biggest, fastest fully-loaded with cache EMC Syms available that had some don't worry about it layout and seen database throughput go up by as much as 8x. See Gaja's whitepaper on RAID at http://www.quest.com/whitepapers/Raid1.pdf . Don Granaman [certifiable oraSaurus] - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, April 10, 2002 10:38 AM Hi all, We are running both a Hitachi 7700E and a 9960 disk subsystem here and we are getting ready to move our production DBs from the old(7700E) to the new(9960) Hitachi. We have had trouble in the past on the 7700E due to disk contention and layout, i.e. we weren't striped across the array groups very well this caused pretty poor I/O performance.This has been a learning experience for the DBAs and the SAs here for the logical vs. physical aspects of our disks. Anyway, to make a long story short, we are ordering disk for the move to the 9960 and we have 2 choices in disk sizes - 18GB and 73GB, and 2 choices in RAID - 1+0 and 5. I would like to get the smaller, faster 18GB drives in a RAID 1+0 configuration and stripe our data across the array groups as wide as possible. However, I am running into objections from the Hitachi people that their system is s fast we need not worry about such minor
Re: disk subsystem performance question
Marie, there is a thread going on this Oracle list about disk subsystem speed, I am going to forward a couple of the responses to you. I think that it is reiterating that we need to have raid 0+1 in our PROD environment. [EMAIL PROTECTED] 04/10/02 01:06PM James Howerton wrote: John, We have the Hitachi 5800 series with RAID 5. The sales guys also said their system is s fast we need not worry about such minor details. Don't believe them!!! Write speed is SLOW. After we added bare drives for redo log files, archive logs, conrtol files it made a dramatic difference in DB performance. Hitachi some Sa's don't want to set up RAID 1+0 because it makes more work for them than a RAID 5 install. Within the last month our development box was switched from RAID-1 to RAID-5 because additional disk capacity was required. The big data load job almost doubled in time from 150 minutes to 270 minutes due to the double writes incurred by RAID-5 overhead. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Charlie Mengler 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: CHRIS FARMER 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: disk subsystem performance question
Battery backup on the controller should help in this case. If there is none, write back mode should be used (instead of write through), loosing advantages of on-board caching (still helps with the reads). Igor Neyman, OCP DBA [EMAIL PROTECTED] - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, April 10, 2002 6:58 PM Much of the supposed 'speed' may come from onboard caching on the controller. There is the minor risk that a crash could come after Oracle commits the data and before it is actually written to disk. --- [EMAIL PROTECTED] wrote: Hi all, We are running both a Hitachi 7700E and a 9960 disk subsystem here and we are getting ready to move our production DBs from the old(7700E) to the new(9960) Hitachi. We have had trouble in the past on the 7700E due to disk contention and layout, i.e. we weren't striped across the array groups very well this caused pretty poor I/O performance.This has been a learning experience for the DBAs and the SAs here for the logical vs. physical aspects of our disks. Anyway, to make a long story short, we are ordering disk for the move to the 9960 and we have 2 choices in disk sizes - 18GB and 73GB, and 2 choices in RAID - 1+0 and 5. I would like to get the smaller, faster 18GB drives in a RAID 1+0 configuration and stripe our data across the array groups as wide as possible. However, I am running into objections from the Hitachi people that their system is s fast we need not worry about such minor details. I'm having a hard time believing that given our I/O problems on the 7700E. Performance is given a high priority here. What I would like to know is others' experience with disk subsystems - specifically Hitachi but EMC and others as well have you been able to throw the disk in and forget it or have you had success in getting to the dirty details? Have you tested or noticed an improvement with smaller, faster drives in a disk subsystem like the Hitachi or have you traveled that path and found no noticeable improvement? I'm looking for either a) ammunition that my view is correct, or b) I'm wrong and we can get bigger drives which will make Enterprise Planning very happy from a $$$ standpoint because our Hitachi capacity will last longer. We are running Oracle 8.1.7 / AIX 4.3.3 / Peoplesoft Financials version 8. 2 production databases , one 400 GB and the other about 1TB. We've got some other production DBs but these are our big guys. Thanks in advance for any and all input - any help is greatly appreciated. I'd be happy to share any info we have found up to this point and our experiences on the 7700E as well if anyone is interested - despite the fact I will probably bore you to death :-) John Dailey Oracle DBA ING Americas - Application Services Atlanta, GA -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: 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). = Pete Barnett Lead Database Administrator The Regence Group [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Peter Barnett 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: Igor Neyman 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]
Re: disk subsystem performance question
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] granaman@coxcc: .netSubject: Re: disk subsystem performance question Sent by: root@fatcity. com 04/10/2002 01:08 PM Please respond to ORACLE-L Short answer - NO! Nobody's disk subsystem is so fast that no intelligence is required in the layout. This is common vendor blather and one of the most popular myths. I have been hearing it for at least six years - and it still isn't true. Layout still makes a huge difference. RAID levels still make a huge difference. Cache won't solve all your problems (it does help though). I've redone the disk layout on some of the biggest, fastest fully-loaded with cache EMC Syms available that had some don't worry about it layout and seen database throughput go up by as much as 8x. See Gaja's whitepaper on RAID at http://www.quest.com/whitepapers/Raid1.pdf . Don Granaman [certifiable oraSaurus] - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, April 10, 2002 10:38 AM Hi all, We are running both a Hitachi 7700E and a 9960 disk subsystem here and we are getting ready to move our production DBs from the old(7700E) to the new(9960) Hitachi. We have had trouble in the past on the 7700E due to disk contention and layout, i.e. we weren't striped across the array groups very well this caused pretty poor I/O performance.This has been a learning experience for the DBAs and the SAs here for the logical vs. physical aspects of our disks. Anyway, to make a long story short, we are ordering disk for the move to the 9960 and we have 2 choices in disk sizes - 18GB and 73GB, and 2 choices in RAID - 1+0 and 5. I would like to get the smaller, faster 18GB drives in a RAID 1+0 configuration and stripe our data across the array groups as wide as possible. However, I am running into objections from the Hitachi people that their system is s fast we need not worry about such minor details. I'm having a hard time believing that given our I/O problems on the 7700E. Performance is given a high priority here. What I would like to know is others' experience with disk subsystems - specifically Hitachi but EMC and others as well have you been able to throw the disk in and forget it or have you had success in getting to the dirty details? Have you tested or noticed an improvement with smaller, faster drives in a disk subsystem like the Hitachi or have you traveled that path and found no noticeable improvement? I'm looking for either a) ammunition that my view is correct, or b) I'm wrong and we can get bigger drives which will make Enterprise Planning very happy from a $$$ standpoint because our Hitachi capacity will last longer. We are running Oracle 8.1.7 / AIX 4.3.3 / Peoplesoft Financials version 8. 2 production databases , one 400 GB and the other about 1TB. We've got some other production DBs but these are our big guys. Thanks in advance for any and all input - any help is greatly appreciated. I'd be happy to share any info we have found up to this point and our experiences on the 7700E as well if anyone is interested - despite the fact I will probably bore you to death :-) John Dailey Oracle DBA ING Americas - Application Services Atlanta, GA === message truncated === = Gaja Krishna Vaidyanatha Director, Storage Management Products, Quest Software, Inc. Co-author - Oracle Performance Tuning 101 http://www.osborne.com/database_erp/0072131454/0072131454.shtml __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Gaja Krishna Vaidyanatha 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: disk subsystem performance question
John - I haven't experienced the Hitachi disks. To me the key question is how much battery-backed cache the subsystem has. I believe there tends to be a gap in knowledge between DBAs and the disk people. The two don't always understand each other or speak the same language. The Oracle books tend to assume stand-alone disks and issues like raw partitions. The disk people keep coming with new innovations. Some of those innovations may help database performance and some may hurt. I'm still waiting for the definitive book or at least a white paper so I can understand the issues. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Wednesday, April 10, 2002 10:38 AM To: Multiple recipients of list ORACLE-L Hi all, We are running both a Hitachi 7700E and a 9960 disk subsystem here and we are getting ready to move our production DBs from the old(7700E) to the new(9960) Hitachi. We have had trouble in the past on the 7700E due to disk contention and layout, i.e. we weren't striped across the array groups very well this caused pretty poor I/O performance.This has been a learning experience for the DBAs and the SAs here for the logical vs. physical aspects of our disks. Anyway, to make a long story short, we are ordering disk for the move to the 9960 and we have 2 choices in disk sizes - 18GB and 73GB, and 2 choices in RAID - 1+0 and 5. I would like to get the smaller, faster 18GB drives in a RAID 1+0 configuration and stripe our data across the array groups as wide as possible. However, I am running into objections from the Hitachi people that their system is s fast we need not worry about such minor details. I'm having a hard time believing that given our I/O problems on the 7700E. Performance is given a high priority here. What I would like to know is others' experience with disk subsystems - specifically Hitachi but EMC and others as well have you been able to throw the disk in and forget it or have you had success in getting to the dirty details? Have you tested or noticed an improvement with smaller, faster drives in a disk subsystem like the Hitachi or have you traveled that path and found no noticeable improvement? I'm looking for either a) ammunition that my view is correct, or b) I'm wrong and we can get bigger drives which will make Enterprise Planning very happy from a $$$ standpoint because our Hitachi capacity will last longer. We are running Oracle 8.1.7 / AIX 4.3.3 / Peoplesoft Financials version 8. 2 production databases , one 400 GB and the other about 1TB. We've got some other production DBs but these are our big guys. Thanks in advance for any and all input - any help is greatly appreciated. I'd be happy to share any info we have found up to this point and our experiences on the 7700E as well if anyone is interested - despite the fact I will probably bore you to death :-) John Dailey Oracle DBA ING Americas - Application Services Atlanta, GA -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: 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: DENNIS WILLIAMS 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: disk subsystem performance question
John, We have the Hitachi 5800 series with RAID 5. The sales guys also said their system is s fast we need not worry about such minor details. Don't believe them!!! Write speed is SLOW. After we added bare drives for redo log files, archive logs, conrtol files it made a dramatic difference in DB performance. Hitachi some Sa's don't want to set up RAID 1+0 because it makes more work for them than a RAID 5 install. HTH ...JIM... [EMAIL PROTECTED] 4/10/02 10:38:26 AM Hi all, We are running both a Hitachi 7700E and a 9960 disk subsystem here and we are getting ready to move our production DBs from the old(7700E) to the new(9960) Hitachi. We have had trouble in the past on the 7700E due to disk contention and layout, i.e. we weren't striped across the array groups very well this caused pretty poor I/O performance.This has been a learning experience for the DBAs and the SAs here for the logical vs. physical aspects of our disks. Anyway, to make a long story short, we are ordering disk for the move to the 9960 and we have 2 choices in disk sizes - 18GB and 73GB, and 2 choices in RAID - 1+0 and 5. I would like to get the smaller, faster 18GB drives in a RAID 1+0 configuration and stripe our data across the array groups as wide as possible. However, I am running into objections from the Hitachi people that their system is s fast we need not worry about such minor details. I'm having a hard time believing that given our I/O problems on the 7700E. Performance is given a high priority here. What I would like to know is others' experience with disk subsystems - specifically Hitachi but EMC and others as well have you been able to throw the disk in and forget it or have you had success in getting to the dirty details? Have you tested or noticed an improvement with smaller, faster drives in a disk subsystem like the Hitachi or have you traveled that path and found no noticeable improvement? I'm looking for either a) ammunition that my view is correct, or b) I'm wrong and we can get bigger drives which will make Enterprise Planning very happy from a $$$ standpoint because our Hitachi capacity will last longer. We are running Oracle 8.1.7 / AIX 4.3.3 / Peoplesoft Financials version 8. 2 production databases , one 400 GB and the other about 1TB. We've got some other production DBs but these are our big guys. Thanks in advance for any and all input - any help is greatly appreciated. I'd be happy to share any info we have found up to this point and our experiences on the 7700E as well if anyone is interested - despite the fact I will probably bore you to death :-) John Dailey Oracle DBA ING Americas - Application Services Atlanta, GA -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: 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: James Howerton 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: disk subsystem performance question
Short answer - NO! Nobody's disk subsystem is so fast that no intelligence is required in the layout. This is common vendor blather and one of the most popular myths. I have been hearing it for at least six years - and it still isn't true. Layout still makes a huge difference. RAID levels still make a huge difference. Cache won't solve all your problems (it does help though). I've redone the disk layout on some of the biggest, fastest fully-loaded with cache EMC Syms available that had some don't worry about it layout and seen database throughput go up by as much as 8x. See Gaja's whitepaper on RAID at http://www.quest.com/whitepapers/Raid1.pdf . Don Granaman [certifiable oraSaurus] - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, April 10, 2002 10:38 AM Hi all, We are running both a Hitachi 7700E and a 9960 disk subsystem here and we are getting ready to move our production DBs from the old(7700E) to the new(9960) Hitachi. We have had trouble in the past on the 7700E due to disk contention and layout, i.e. we weren't striped across the array groups very well this caused pretty poor I/O performance.This has been a learning experience for the DBAs and the SAs here for the logical vs. physical aspects of our disks. Anyway, to make a long story short, we are ordering disk for the move to the 9960 and we have 2 choices in disk sizes - 18GB and 73GB, and 2 choices in RAID - 1+0 and 5. I would like to get the smaller, faster 18GB drives in a RAID 1+0 configuration and stripe our data across the array groups as wide as possible. However, I am running into objections from the Hitachi people that their system is s fast we need not worry about such minor details. I'm having a hard time believing that given our I/O problems on the 7700E. Performance is given a high priority here. What I would like to know is others' experience with disk subsystems - specifically Hitachi but EMC and others as well have you been able to throw the disk in and forget it or have you had success in getting to the dirty details? Have you tested or noticed an improvement with smaller, faster drives in a disk subsystem like the Hitachi or have you traveled that path and found no noticeable improvement? I'm looking for either a) ammunition that my view is correct, or b) I'm wrong and we can get bigger drives which will make Enterprise Planning very happy from a $$$ standpoint because our Hitachi capacity will last longer. We are running Oracle 8.1.7 / AIX 4.3.3 / Peoplesoft Financials version 8. 2 production databases , one 400 GB and the other about 1TB. We've got some other production DBs but these are our big guys. Thanks in advance for any and all input - any help is greatly appreciated. I'd be happy to share any info we have found up to this point and our experiences on the 7700E as well if anyone is interested - despite the fact I will probably bore you to death :-) John Dailey Oracle DBA ING Americas - Application Services Atlanta, GA -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: 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: Don Granaman 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: disk subsystem performance question
James Howerton wrote: John, We have the Hitachi 5800 series with RAID 5. The sales guys also said their system is s fast we need not worry about such minor details. Don't believe them!!! Write speed is SLOW. After we added bare drives for redo log files, archive logs, conrtol files it made a dramatic difference in DB performance. Hitachi some Sa's don't want to set up RAID 1+0 because it makes more work for them than a RAID 5 install. Within the last month our development box was switched from RAID-1 to RAID-5 because additional disk capacity was required. The big data load job almost doubled in time from 150 minutes to 270 minutes due to the double writes incurred by RAID-5 overhead. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Charlie Mengler 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: disk subsystem performance question
John, We use 7700E. Most all EMC is going out and being replaced by HDS RAID-5. (What it costs is more important that what it does). Everything we have is on RAID-5 these days. HDS Techies and our Capacity Planners (who do the disk assignments to Servers) told me the following: The 18GB drives are arranged by 'parity groups' inside the array and are striped at H/W level. Each such group is then chopped off as 7-8GB disk device for the target server (/dev/hdiskXX). Disk devices on the server with the same 'parity group' can be considered as one hard disk. Sys Admins then build the VGs of such hdisks with identical parity group. We then ask them to build LVs for FSs to be used for data and index separation. This scheme has been working well for us for the time being. I am still hoping to someday go back to RAID 1+0. Pl check with your HDS Techies about this 'parity group' theory and see what they are doing for you. Please update us if this theory (as was told to us) works or it was just to pacify us. The NV Cache gets immediately saturated. The db size and demand for data will always be way larger than the available cache (and cash;) Good Luck.. - Kirti -Original Message- Sent: Wednesday, April 10, 2002 12:09 PM To: Multiple recipients of list ORACLE-L Short answer - NO! Nobody's disk subsystem is so fast that no intelligence is required in the layout. This is common vendor blather and one of the most popular myths. I have been hearing it for at least six years - and it still isn't true. Layout still makes a huge difference. RAID levels still make a huge difference. Cache won't solve all your problems (it does help though). I've redone the disk layout on some of the biggest, fastest fully-loaded with cache EMC Syms available that had some don't worry about it layout and seen database throughput go up by as much as 8x. See Gaja's whitepaper on RAID at http://www.quest.com/whitepapers/Raid1.pdf . Don Granaman [certifiable oraSaurus] - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, April 10, 2002 10:38 AM Hi all, We are running both a Hitachi 7700E and a 9960 disk subsystem here and we are getting ready to move our production DBs from the old(7700E) to the new(9960) Hitachi. We have had trouble in the past on the 7700E due to disk contention and layout, i.e. we weren't striped across the array groups very well this caused pretty poor I/O performance.This has been a learning experience for the DBAs and the SAs here for the logical vs. physical aspects of our disks. Anyway, to make a long story short, we are ordering disk for the move to the 9960 and we have 2 choices in disk sizes - 18GB and 73GB, and 2 choices in RAID - 1+0 and 5. I would like to get the smaller, faster 18GB drives in a RAID 1+0 configuration and stripe our data across the array groups as wide as possible. However, I am running into objections from the Hitachi people that their system is s fast we need not worry about such minor details. I'm having a hard time believing that given our I/O problems on the 7700E. Performance is given a high priority here. What I would like to know is others' experience with disk subsystems - specifically Hitachi but EMC and others as well have you been able to throw the disk in and forget it or have you had success in getting to the dirty details? Have you tested or noticed an improvement with smaller, faster drives in a disk subsystem like the Hitachi or have you traveled that path and found no noticeable improvement? I'm looking for either a) ammunition that my view is correct, or b) I'm wrong and we can get bigger drives which will make Enterprise Planning very happy from a $$$ standpoint because our Hitachi capacity will last longer. We are running Oracle 8.1.7 / AIX 4.3.3 / Peoplesoft Financials version 8. 2 production databases , one 400 GB and the other about 1TB. We've got some other production DBs but these are our big guys. Thanks in advance for any and all input - any help is greatly appreciated. I'd be happy to share any info we have found up to this point and our experiences on the 7700E as well if anyone is interested - despite the fact I will probably bore you to death :-) John Dailey Oracle DBA ING Americas - Application Services Atlanta, GA -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Deshpande, Kirti 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).
Re: disk subsystem performance question
Much of the supposed 'speed' may come from onboard caching on the controller. There is the minor risk that a crash could come after Oracle commits the data and before it is actually written to disk. --- [EMAIL PROTECTED] wrote: Hi all, We are running both a Hitachi 7700E and a 9960 disk subsystem here and we are getting ready to move our production DBs from the old(7700E) to the new(9960) Hitachi. We have had trouble in the past on the 7700E due to disk contention and layout, i.e. we weren't striped across the array groups very well this caused pretty poor I/O performance.This has been a learning experience for the DBAs and the SAs here for the logical vs. physical aspects of our disks. Anyway, to make a long story short, we are ordering disk for the move to the 9960 and we have 2 choices in disk sizes - 18GB and 73GB, and 2 choices in RAID - 1+0 and 5. I would like to get the smaller, faster 18GB drives in a RAID 1+0 configuration and stripe our data across the array groups as wide as possible. However, I am running into objections from the Hitachi people that their system is s fast we need not worry about such minor details. I'm having a hard time believing that given our I/O problems on the 7700E. Performance is given a high priority here. What I would like to know is others' experience with disk subsystems - specifically Hitachi but EMC and others as well have you been able to throw the disk in and forget it or have you had success in getting to the dirty details? Have you tested or noticed an improvement with smaller, faster drives in a disk subsystem like the Hitachi or have you traveled that path and found no noticeable improvement? I'm looking for either a) ammunition that my view is correct, or b) I'm wrong and we can get bigger drives which will make Enterprise Planning very happy from a $$$ standpoint because our Hitachi capacity will last longer. We are running Oracle 8.1.7 / AIX 4.3.3 / Peoplesoft Financials version 8. 2 production databases , one 400 GB and the other about 1TB. We've got some other production DBs but these are our big guys. Thanks in advance for any and all input - any help is greatly appreciated. I'd be happy to share any info we have found up to this point and our experiences on the 7700E as well if anyone is interested - despite the fact I will probably bore you to death :-) John Dailey Oracle DBA ING Americas - Application Services Atlanta, GA -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: 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). = Pete Barnett Lead Database Administrator The Regence Group [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Peter Barnett 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: disk subsystem performance question
Thanks for all the replies. We are determined to lay out the data as well as we can across the disks we are about to purchase - with the goal of striping across array groups and smaller, faster drives. The real argument for us is 18GB vs. 73GB disk drives and how we can stripe. The Hitachi is configured into groups of 4 physical disks called parity groups and you can choose RAID 5 or RAID 1+0 for that 4 disk set.If you have 73GB drives in a 4-disk RAID 5 configuration you get roughly 219GB of usable space in each parity group (this is what we are being told is the best option for us).This means our heavily concurrently accessed 400GB production database goes on 2 parity groups (2 sets of 4 disks). To me, this sounds like a nightmare waiting to happen and we are trying to stop it.The 18GB drives are less capacity but we can get ourselves spread over more parity groups for better concurrency. We do have about 10GB of cache but it is being shared across the enterprise with various other applications. We as a DBA group are really trying to sell the 18GB RAID 1+0 drive solution especially after reading the groups' experiences - unfortunately we are fighting a lot of marketing hype. If anyone has additional experiences or feedback with Hitachi or EMC they would like to share or comments (agree/disagree) with my thoughts, I'd love to hear them. I'm open for learning! Thanks, John Dailey Oracle DBA ING Americas - Application Services Atlanta, GA Don GranamanTo: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] granaman@coxcc: .netSubject: Re: disk subsystem performance question Sent by: root@fatcity. com 04/10/2002 01:08 PM Please respond to ORACLE-L Short answer - NO! Nobody's disk subsystem is so fast that no intelligence is required in the layout. This is common vendor blather and one of the most popular myths. I have been hearing it for at least six years - and it still isn't true. Layout still makes a huge difference. RAID levels still make a huge difference. Cache won't solve all your problems (it does help though). I've redone the disk layout on some of the biggest, fastest fully-loaded with cache EMC Syms available that had some don't worry about it layout and seen database throughput go up by as much as 8x. See Gaja's whitepaper on RAID at http://www.quest.com/whitepapers/Raid1.pdf . Don Granaman [certifiable oraSaurus] - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, April 10, 2002 10:38 AM Hi all, We are running both a Hitachi 7700E and a 9960 disk subsystem here and we are getting ready to move our production DBs from the old(7700E) to the new(9960) Hitachi. We have had trouble in the past on the 7700E due to disk contention and layout, i.e. we weren't striped across the array groups very well this caused pretty poor I/O performance.This has been a learning experience for the DBAs and the SAs here for the logical vs. physical aspects of our disks. Anyway, to make a long story short, we are ordering disk for the move to the 9960 and we have 2 choices in disk sizes - 18GB and 73GB, and 2 choices in RAID - 1+0
Re: disk subsystem performance question
I believe RAID-1+0 has more cost than benefit. I want to see measure total I/O's to each spindle. While RAID-1 has higher cost to maintain, it gives me maximum flexibility to evenly distribute I/O loads. I contend that with proper table partitioning I can achieve sustain higher I/O rates with RAID-1 than can be gotten from RAID-1+0. HTH YMMV HAND! [EMAIL PROTECTED] wrote: Thanks for all the replies. We are determined to lay out the data as well as we can across the disks we are about to purchase - with the goal of striping across array groups and smaller, faster drives. The real argument for us is 18GB vs. 73GB disk drives and how we can stripe. The Hitachi is configured into groups of 4 physical disks called parity groups and you can choose RAID 5 or RAID 1+0 for that 4 disk set.If you have 73GB drives in a 4-disk RAID 5 configuration you get roughly 219GB of usable space in each parity group (this is what we are being told is the best option for us).This means our heavily concurrently accessed 400GB production database goes on 2 parity groups (2 sets of 4 disks). To me, this sounds like a nightmare waiting to happen and we are trying to stop it.The 18GB drives are less capacity but we can get ourselves spread over more parity groups for better concurrency. We do have about 10GB of cache but it is being shared across the enterprise with various other applications. We as a DBA group are really trying to sell the 18GB RAID 1+0 drive solution especially after reading the groups' experiences - unfortunately we are fighting a lot of marketing hype. If anyone has additional experiences or feedback with Hitachi or EMC they would like to share or comments (agree/disagree) with my thoughts, I'd love to hear them. I'm open for learning! Thanks, John Dailey Oracle DBA ING Americas - Application Services Atlanta, GA Don GranamanTo: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] granaman@coxcc: .netSubject: Re: disk subsystem performance question Sent by: root@fatcity. com 04/10/2002 01:08 PM Please respond to ORACLE-L Short answer - NO! Nobody's disk subsystem is so fast that no intelligence is required in the layout. This is common vendor blather and one of the most popular myths. I have been hearing it for at least six years - and it still isn't true. Layout still makes a huge difference. RAID levels still make a huge difference. Cache won't solve all your problems (it does help though). I've redone the disk layout on some of the biggest, fastest fully-loaded with cache EMC Syms available that had some don't worry about it layout and seen database throughput go up by as much as 8x. See Gaja's whitepaper on RAID at http://www.quest.com/whitepapers/Raid1.pdf . Don Granaman [certifiable oraSaurus] - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, April 10, 2002 10:38 AM Hi all, We are running both a Hitachi 7700E and a 9960 disk subsystem here and we are getting ready to move our production DBs from the old(7700E) to the new(9960) Hitachi. We have had trouble in the past on the 7700E due to disk contention and layout, i.e. we weren't striped across the array groups very well this caused pretty poor I/O performance.This has been a learning experience for the DBAs and the SAs here for the logical vs. physical aspects of our disks. Anyway, to make a long story short, we are ordering disk for the move to the 9960 and we have 2 choices in disk sizes - 18GB and 73GB, and 2 choices in RAID - 1+0 and 5. I would like to get the smaller, faster 18GB drives in a RAID 1+0 configuration and stripe our data across the array groups as wide as possible. However, I am running into objections from the Hitachi people that their system is s fast we need not worry about such minor details. I'm having a hard time believing that given our I/O problems on the 7700E. Performance is given a high priority here. What I would like to know is others' experience with disk subsystems - specifically Hitachi but EMC and others as well have you been able to throw the disk in and forget it or have you had success in getting to the dirty details? Have you tested or noticed an improvement with smaller, faster drives in a disk subsystem like the Hitachi or have you traveled that path and found no noticeable improvement? I'm looking for either a) ammunition that my view is correct, or b) I'm wrong and we can get bigger drives which will make Enterprise Planning
RE: disk subsystem performance question
John, I agree with the 18GB drives implementation and pushing for more 'parity groups'. That's what we did. Now, HDS was back to sell more disk and backup soultions to us. I am not sure what we have agreed to purchase. A cache of 10GB for the 400GB database is nothing. I bet you will have tables larger than the cache size. A single FTS on these tables will flush the whole cache... We have 16GB cache (I think I remember that right, and is the max for 7700E), and that is not enough for several servers that the cabinet supports. - Kirti -Original Message- Sent: Wednesday, April 10, 2002 7:08 PM To: Multiple recipients of list ORACLE-L Thanks for all the replies. We are determined to lay out the data as well as we can across the disks we are about to purchase - with the goal of striping across array groups and smaller, faster drives. The real argument for us is 18GB vs. 73GB disk drives and how we can stripe. The Hitachi is configured into groups of 4 physical disks called parity groups and you can choose RAID 5 or RAID 1+0 for that 4 disk set.If you have 73GB drives in a 4-disk RAID 5 configuration you get roughly 219GB of usable space in each parity group (this is what we are being told is the best option for us).This means our heavily concurrently accessed 400GB production database goes on 2 parity groups (2 sets of 4 disks). To me, this sounds like a nightmare waiting to happen and we are trying to stop it.The 18GB drives are less capacity but we can get ourselves spread over more parity groups for better concurrency. We do have about 10GB of cache but it is being shared across the enterprise with various other applications. We as a DBA group are really trying to sell the 18GB RAID 1+0 drive solution especially after reading the groups' experiences - unfortunately we are fighting a lot of marketing hype. If anyone has additional experiences or feedback with Hitachi or EMC they would like to share or comments (agree/disagree) with my thoughts, I'd love to hear them. I'm open for learning! Thanks, John Dailey Oracle DBA ING Americas - Application Services Atlanta, GA Don GranamanTo: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] granaman@coxcc: .netSubject: Re: disk subsystem performance question Sent by: root@fatcity. com 04/10/2002 01:08 PM Please respond to ORACLE-L Short answer - NO! Nobody's disk subsystem is so fast that no intelligence is required in the layout. This is common vendor blather and one of the most popular myths. I have been hearing it for at least six years - and it still isn't true. Layout still makes a huge difference. RAID levels still make a huge difference. Cache won't solve all your problems (it does help though). I've redone the disk layout on some of the biggest, fastest fully-loaded with cache EMC Syms available that had some don't worry about it layout and seen database throughput go up by as much as 8x. See Gaja's whitepaper on RAID at http://www.quest.com/whitepapers/Raid1.pdf . Don Granaman [certifiable oraSaurus] - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, April 10, 2002 10:38 AM Hi all, We are running both a Hitachi 7700E and a 9960 disk subsystem here and we are getting ready to move our production DBs from the old(7700E) to the new(9960) Hitachi. We have had trouble in the past on the 7700E due to disk contention and layout, i.e. we weren't striped across the array groups very well this caused pretty poor I/O performance.This has been a learning experience for the DBAs and the SAs here for the logical vs. physical aspects of our disks. Anyway, to make a long story short, we are ordering disk for the move to the 9960 and we have 2 choices in disk sizes - 18GB and 73GB, and 2 choices in RAID - 1+0 and 5. I would like to get the smaller, faster 18GB drives in a RAID 1+0 configuration and stripe our data across the array groups as wide as possible. However, I am running into objections from the Hitachi people that their system is s fast we need not worry about such minor details. I'm having a hard time believing that given our I/O problems on the 7700E. Performance is given a high priority here. What I would like to know is others' experience with disk subsystems - specifically Hitachi but EMC and others as well have you been able to throw the disk in and forget it or have you had success in getting to the dirty details? Have you tested or noticed an improvement with smaller, faster drives in a disk subsystem like