RE: Advice needed on move to Sun 15K (losing spindles)
We too are moving to a Sun Fire 15 K box, with 8 partitions and 40 CPUs. But Our storage is on EMC. And since we have many partitions they are like separate machines. We will be housing two production warehouse databases and 5 production OLTP databases, with all other environments supporting these databases. --- Deshpande, Kirti [EMAIL PROTECTED] wrote: Salesmen/Saleswomen tell them what they want to hear! - Kirti -Original Message- Sent: Friday, October 11, 2002 12:54 PM To: Multiple recipients of list ORACLE-L Why does management trust a salesman over their own IT professionals? Miller, Jay JayMiller To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] @TDWaterhousecc: .comSubject: RE: Advice needed on move to Sun 15K (losing spindles) Sent by: root 10/11/2002 12:14 PM Please respond to ORACLE-L I obviously left out a lot of information :). We would be using server partitioning, with seperate ORACLE_HOMES for each database (necessary since we have a variety of versions running). The box would be running 1+0, the Sun reps suggest striping across all disks (my first red flag). I hadn't even thought of the problem of not being able to reboot the server, that's an excellent point. Currently we have absolutely no performance problems on our OLTP database. This whole kerfuffle was an outgrowth of my pushing really hard to get a backup box for our datawarehouse (which currently has no standby, no box that it can restored to and no QA box). The suggestion was made that rather than get a separate box for the datawarehouse - get the 15K and have the OLTP and datawarehouse on different partitions. This would certainly speed up the data transfer between them (data is transferred from OLTP - Data Warehouse on a daily basis). We could then put other databases that access my databases on other partitions (several other databases have snapshots on some of my tables). So this would make some processes more efficient, but i/o on my OLTP database is currently tuned so well that it hurts every time I think of giving it up. One spindle has the Oracle executables with the redo logs on the outside of the disk. Another has the various .dat files, shell scripts, etc, with the archive logs on the outside of the disk. Even when we run really intensive updates our wio rarely gets very high. Regarding the load question: We have fairly active transaction activity during the day but most connections are managed by Microsoft Transaction Server in a middle tier so while there are usually app. 200 sessions (including some old client server apps) we rarely have more than 20 or so active at any one time. The datawarehouse has fewer sessions but often has some resource intensive queries running. If anyone can point me to docs/websites saying that a large caches does *not* make up for fewer disks/spindles I would greatly appreciate it. Currently I'm being told that Sun must know what they're talking about. Thanks again, Jay Miller -Original Message- Sent: Wednesday, October 09, 2002 5:19 PM To: Multiple recipients of list ORACLE-L Others have addressed the performance issues. What about the admin issues? If consolidate to a single server, consider a separate ORACLE_HOME for each database. You may need to apply different patches to fix different problems in various databases. You have this ability now, but will lose it if you consolidate without separate ORACLE_HOME's. Something else you will lose is the ability to reboot the server if needed for a single database. Since you may be moving to a 15k, investigate server partitioning to retain this functionality. Jared Miller, Jay [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/09/2002 11:53 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:Advice needed on move to Sun 15K (losing spindles) Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping 2 and 2). We could
RE: Advice needed on move to Sun 15K (losing spindles)
Theoretically, if the activity of the database doesn't involve too much disk writing, and the cache is large enough, etc., etc., you can use parity. When disk drives cost a lot of money, there was some justification for it. Now that drives are cheap, there really is no justification. To cripple the processing power of an E15K in order to save some money on hard drives really is a case of being penny wise and dollar foolish. You would probably be better off buying a less powerful computer and using the savings to increase the drive count. The performance of the RAID 5 systems at my shop here is terrible. Remember the story of that Sparc 4500? (Actually, now that I think about it, I think it was a 4000.) Well, that box was for the test lab. The production box was 10 CPU's of an E10K with an EMC tower. (I have forgotten the CPU speed -- probably either 250 Mhz or 300 Mhz.) The 4000 had 4 Gb RAM, the production box 6 Gb. The production box was set up by Oracle consultants to be completely OFA compliant. At this time, EMC was still using RAID-S (Uh-oh). The same 80 Gb cesspool of a database was put on both boxes. On the production box, the Oracle consultants along with the EMC people worked to distribute the database I/O over the drives in the EMC tower. On the test box, the entire database and all the Oracle binaries were dumped on the big mirrored stripe. When the testers ran the benchmarks, the test box was processing transactions at THREE TIMES rate of the production box. Feel free to correct me if I am wrong, but I think, now that drives are cheap, EMC no longer uses RAID-S. I suppose, in certain circumstances, a RAID 5 arrangement might work OK. But, in every case that I have seen, it's performance has always sucked the moose. -Original Message- Fortunately my SA believes that so we were able to present a united front at the presentation (and yes, the Sun rep said that with a large enough cache RAID 5 works just as well as 1+0 - which is what we would be using). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Stephen Lee INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Advice needed on move to Sun 15K (losing spindles)
I obviously left out a lot of information :). We would be using server partitioning, with seperate ORACLE_HOMES for each database (necessary since we have a variety of versions running). The box would be running 1+0, the Sun reps suggest striping across all disks (my first red flag). I hadn't even thought of the problem of not being able to reboot the server, that's an excellent point. Currently we have absolutely no performance problems on our OLTP database. This whole kerfuffle was an outgrowth of my pushing really hard to get a backup box for our datawarehouse (which currently has no standby, no box that it can restored to and no QA box). The suggestion was made that rather than get a separate box for the datawarehouse - get the 15K and have the OLTP and datawarehouse on different partitions. This would certainly speed up the data transfer between them (data is transferred from OLTP - Data Warehouse on a daily basis). We could then put other databases that access my databases on other partitions (several other databases have snapshots on some of my tables). So this would make some processes more efficient, but i/o on my OLTP database is currently tuned so well that it hurts every time I think of giving it up. One spindle has the Oracle executables with the redo logs on the outside of the disk. Another has the various .dat files, shell scripts, etc, with the archive logs on the outside of the disk. Even when we run really intensive updates our wio rarely gets very high. Regarding the load question: We have fairly active transaction activity during the day but most connections are managed by Microsoft Transaction Server in a middle tier so while there are usually app. 200 sessions (including some old client server apps) we rarely have more than 20 or so active at any one time. The datawarehouse has fewer sessions but often has some resource intensive queries running. If anyone can point me to docs/websites saying that a large caches does *not* make up for fewer disks/spindles I would greatly appreciate it. Currently I'm being told that Sun must know what they're talking about. Thanks again, Jay Miller -Original Message- Sent: Wednesday, October 09, 2002 5:19 PM To: Multiple recipients of list ORACLE-L Others have addressed the performance issues. What about the admin issues? If consolidate to a single server, consider a separate ORACLE_HOME for each database. You may need to apply different patches to fix different problems in various databases. You have this ability now, but will lose it if you consolidate without separate ORACLE_HOME's. Something else you will lose is the ability to reboot the server if needed for a single database. Since you may be moving to a 15k, investigate server partitioning to retain this functionality. Jared Miller, Jay [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/09/2002 11:53 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:Advice needed on move to Sun 15K (losing spindles) Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping 2 and 2). We could then at least seperate the redo logs from the datafiles (probably putting them with the oracle executables and some other files). The Sun rep kept talking up how much more powerful the CPUs were and I kept saying, but we're not CPU bound, we don't need any more CPU. If anyone can either a) tell me I'm worrying for nothing b) recommend a better way to stripe/distribute my files c) provide references or experience to show this is a bad idea I'd really appreciate it. Thanks, Jay Miller -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Miller, Jay INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051
RE: Advice needed on move to Sun 15K (losing spindles)
I suggest reviewing James Morle's paper 'Sane SAN' at http://www.oraperf.com/whitepapers.html. - Kirti -Original Message- Sent: Friday, October 11, 2002 11:15 AM To: Multiple recipients of list ORACLE-L I obviously left out a lot of information :). We would be using server partitioning, with seperate ORACLE_HOMES for each database (necessary since we have a variety of versions running). The box would be running 1+0, the Sun reps suggest striping across all disks (my first red flag). I hadn't even thought of the problem of not being able to reboot the server, that's an excellent point. Currently we have absolutely no performance problems on our OLTP database. This whole kerfuffle was an outgrowth of my pushing really hard to get a backup box for our datawarehouse (which currently has no standby, no box that it can restored to and no QA box). The suggestion was made that rather than get a separate box for the datawarehouse - get the 15K and have the OLTP and datawarehouse on different partitions. This would certainly speed up the data transfer between them (data is transferred from OLTP - Data Warehouse on a daily basis). We could then put other databases that access my databases on other partitions (several other databases have snapshots on some of my tables). So this would make some processes more efficient, but i/o on my OLTP database is currently tuned so well that it hurts every time I think of giving it up. One spindle has the Oracle executables with the redo logs on the outside of the disk. Another has the various .dat files, shell scripts, etc, with the archive logs on the outside of the disk. Even when we run really intensive updates our wio rarely gets very high. Regarding the load question: We have fairly active transaction activity during the day but most connections are managed by Microsoft Transaction Server in a middle tier so while there are usually app. 200 sessions (including some old client server apps) we rarely have more than 20 or so active at any one time. The datawarehouse has fewer sessions but often has some resource intensive queries running. If anyone can point me to docs/websites saying that a large caches does *not* make up for fewer disks/spindles I would greatly appreciate it. Currently I'm being told that Sun must know what they're talking about. Thanks again, Jay Miller -Original Message- Sent: Wednesday, October 09, 2002 5:19 PM To: Multiple recipients of list ORACLE-L Others have addressed the performance issues. What about the admin issues? If consolidate to a single server, consider a separate ORACLE_HOME for each database. You may need to apply different patches to fix different problems in various databases. You have this ability now, but will lose it if you consolidate without separate ORACLE_HOME's. Something else you will lose is the ability to reboot the server if needed for a single database. Since you may be moving to a 15k, investigate server partitioning to retain this functionality. Jared Miller, Jay [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/09/2002 11:53 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:Advice needed on move to Sun 15K (losing spindles) Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping 2 and 2). We could then at least seperate the redo logs from the datafiles (probably putting them with the oracle executables and some other files). The Sun rep kept talking up how much more powerful the CPUs were and I kept saying, but we're not CPU bound, we don't need any more CPU. If anyone can either a) tell me I'm worrying for nothing b) recommend a better way to stripe/distribute my files c) provide references or experience to show this is a bad idea I'd really appreciate it. Thanks, Jay Miller -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Miller, Jay 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
RE: Advice needed on move to Sun 15K (losing spindles)
Why does management trust a salesman over their own IT professionals? Miller, Jay JayMiller To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] @TDWaterhousecc: .comSubject: RE: Advice needed on move to Sun 15K (losing spindles) Sent by: root 10/11/2002 12:14 PM Please respond to ORACLE-L I obviously left out a lot of information :). We would be using server partitioning, with seperate ORACLE_HOMES for each database (necessary since we have a variety of versions running). The box would be running 1+0, the Sun reps suggest striping across all disks (my first red flag). I hadn't even thought of the problem of not being able to reboot the server, that's an excellent point. Currently we have absolutely no performance problems on our OLTP database. This whole kerfuffle was an outgrowth of my pushing really hard to get a backup box for our datawarehouse (which currently has no standby, no box that it can restored to and no QA box). The suggestion was made that rather than get a separate box for the datawarehouse - get the 15K and have the OLTP and datawarehouse on different partitions. This would certainly speed up the data transfer between them (data is transferred from OLTP - Data Warehouse on a daily basis). We could then put other databases that access my databases on other partitions (several other databases have snapshots on some of my tables). So this would make some processes more efficient, but i/o on my OLTP database is currently tuned so well that it hurts every time I think of giving it up. One spindle has the Oracle executables with the redo logs on the outside of the disk. Another has the various .dat files, shell scripts, etc, with the archive logs on the outside of the disk. Even when we run really intensive updates our wio rarely gets very high. Regarding the load question: We have fairly active transaction activity during the day but most connections are managed by Microsoft Transaction Server in a middle tier so while there are usually app. 200 sessions (including some old client server apps) we rarely have more than 20 or so active at any one time. The datawarehouse has fewer sessions but often has some resource intensive queries running. If anyone can point me to docs/websites saying that a large caches does *not* make up for fewer disks/spindles I would greatly appreciate it. Currently I'm being told that Sun must know what they're talking about. Thanks again, Jay Miller -Original Message- Sent: Wednesday, October 09, 2002 5:19 PM To: Multiple recipients of list ORACLE-L Others have addressed the performance issues. What about the admin issues? If consolidate to a single server, consider a separate ORACLE_HOME for each database. You may need to apply different patches to fix different problems in various databases. You have this ability now, but will lose it if you consolidate without separate ORACLE_HOME's. Something else you will lose is the ability to reboot the server if needed for a single database. Since you may be moving to a 15k, investigate server partitioning to retain this functionality. Jared Miller, Jay [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/09/2002 11:53 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:Advice needed on move to Sun 15K (losing spindles) Our CIO has suggested that we get a Sun 15K to house all of our
RE: Advice needed on move to Sun 15K (losing spindles)
Salesmen/Saleswomen tell them what they want to hear! - Kirti -Original Message- Sent: Friday, October 11, 2002 12:54 PM To: Multiple recipients of list ORACLE-L Why does management trust a salesman over their own IT professionals? Miller, Jay JayMiller To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] @TDWaterhousecc: .comSubject: RE: Advice needed on move to Sun 15K (losing spindles) Sent by: root 10/11/2002 12:14 PM Please respond to ORACLE-L I obviously left out a lot of information :). We would be using server partitioning, with seperate ORACLE_HOMES for each database (necessary since we have a variety of versions running). The box would be running 1+0, the Sun reps suggest striping across all disks (my first red flag). I hadn't even thought of the problem of not being able to reboot the server, that's an excellent point. Currently we have absolutely no performance problems on our OLTP database. This whole kerfuffle was an outgrowth of my pushing really hard to get a backup box for our datawarehouse (which currently has no standby, no box that it can restored to and no QA box). The suggestion was made that rather than get a separate box for the datawarehouse - get the 15K and have the OLTP and datawarehouse on different partitions. This would certainly speed up the data transfer between them (data is transferred from OLTP - Data Warehouse on a daily basis). We could then put other databases that access my databases on other partitions (several other databases have snapshots on some of my tables). So this would make some processes more efficient, but i/o on my OLTP database is currently tuned so well that it hurts every time I think of giving it up. One spindle has the Oracle executables with the redo logs on the outside of the disk. Another has the various .dat files, shell scripts, etc, with the archive logs on the outside of the disk. Even when we run really intensive updates our wio rarely gets very high. Regarding the load question: We have fairly active transaction activity during the day but most connections are managed by Microsoft Transaction Server in a middle tier so while there are usually app. 200 sessions (including some old client server apps) we rarely have more than 20 or so active at any one time. The datawarehouse has fewer sessions but often has some resource intensive queries running. If anyone can point me to docs/websites saying that a large caches does *not* make up for fewer disks/spindles I would greatly appreciate it. Currently I'm being told that Sun must know what they're talking about. Thanks again, Jay Miller -Original Message- Sent: Wednesday, October 09, 2002 5:19 PM To: Multiple recipients of list ORACLE-L Others have addressed the performance issues. What about the admin issues? If consolidate to a single server, consider a separate ORACLE_HOME for each database. You may need to apply different patches to fix different problems in various databases. You have this ability now, but will lose it if you consolidate without separate ORACLE_HOME's. Something else you will lose is the ability to reboot the server if needed for a single database. Since you may be moving to a 15k, investigate server partitioning to retain this functionality. Jared Miller, Jay [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/09/2002 11:53 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:Advice needed on move to Sun 15K (losing spindles) Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping 2 and 2). We could then at least seperate the redo logs from the datafiles (probably putting them with the oracle executables and some other files). The Sun rep kept talking up how much more powerful the CPUs were and I kept saying, but we're not CPU bound, we don't need any more CPU. If anyone can either a) tell me I'm worrying for nothing b) recommend a better way to stripe/distribute my files c) provide references or experience to show this is a bad idea I'd really appreciate it. Thanks, Jay Miller -- Please see the official ORACLE-L FAQ: http
RE: Advice needed on move to Sun 15K (losing spindles)
Thanks Kirti! I loved the line The first thing to do, regardless of platform or claims by the vendor, is to completely forget the existence of a cache Any similar references will be greatly appreciated. The more ammunition I have the likelier I am to kill something :) Jay -Original Message- Sent: Friday, October 11, 2002 12:36 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] I suggest reviewing James Morle's paper 'Sane SAN' at http://www.oraperf.com/whitepapers.html. - Kirti -Original Message- Sent: Friday, October 11, 2002 11:15 AM To: Multiple recipients of list ORACLE-L I obviously left out a lot of information :). We would be using server partitioning, with seperate ORACLE_HOMES for each database (necessary since we have a variety of versions running). The box would be running 1+0, the Sun reps suggest striping across all disks (my first red flag). I hadn't even thought of the problem of not being able to reboot the server, that's an excellent point. Currently we have absolutely no performance problems on our OLTP database. This whole kerfuffle was an outgrowth of my pushing really hard to get a backup box for our datawarehouse (which currently has no standby, no box that it can restored to and no QA box). The suggestion was made that rather than get a separate box for the datawarehouse - get the 15K and have the OLTP and datawarehouse on different partitions. This would certainly speed up the data transfer between them (data is transferred from OLTP - Data Warehouse on a daily basis). We could then put other databases that access my databases on other partitions (several other databases have snapshots on some of my tables). So this would make some processes more efficient, but i/o on my OLTP database is currently tuned so well that it hurts every time I think of giving it up. One spindle has the Oracle executables with the redo logs on the outside of the disk. Another has the various .dat files, shell scripts, etc, with the archive logs on the outside of the disk. Even when we run really intensive updates our wio rarely gets very high. Regarding the load question: We have fairly active transaction activity during the day but most connections are managed by Microsoft Transaction Server in a middle tier so while there are usually app. 200 sessions (including some old client server apps) we rarely have more than 20 or so active at any one time. The datawarehouse has fewer sessions but often has some resource intensive queries running. If anyone can point me to docs/websites saying that a large caches does *not* make up for fewer disks/spindles I would greatly appreciate it. Currently I'm being told that Sun must know what they're talking about. Thanks again, Jay Miller -Original Message- Sent: Wednesday, October 09, 2002 5:19 PM To: Multiple recipients of list ORACLE-L Others have addressed the performance issues. What about the admin issues? If consolidate to a single server, consider a separate ORACLE_HOME for each database. You may need to apply different patches to fix different problems in various databases. You have this ability now, but will lose it if you consolidate without separate ORACLE_HOME's. Something else you will lose is the ability to reboot the server if needed for a single database. Since you may be moving to a 15k, investigate server partitioning to retain this functionality. Jared Miller, Jay [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/09/2002 11:53 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:Advice needed on move to Sun 15K (losing spindles) Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping 2 and 2). We could then at least seperate the redo logs from the datafiles (probably putting them with the oracle executables and some other files). The Sun rep kept talking up how much more powerful the CPUs were and I kept saying, but we're not CPU bound, we don't need any more CPU. If anyone can either a) tell me I'm worrying for nothing b) recommend a better way to stripe/distribute my files c) provide references or experience to show this is a bad idea I'd really appreciate it. Thanks, Jay Miller -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Miller, Jay INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego,
RE: Advice needed on move to Sun 15K (losing spindles)
I've cussed and discussed the topic of one big stripe versus multiple small stripes with different people and have yet to come across anyone who has conducted a real test of various scenarios. If you stripe across all disks, then you have the advantage of guaranteed, perfectly balance I/O -- there's certainly something to be said for that! But, then you have a mix of reads and writes going across all drives too. A good argument can be made for taking those parts of the database that tend to be only one kind of operation -- for example, archive logs are writes -- and putting them in their own area. So the drives handling the writing of archived logs are doing only one kind of operation (or are they?!), but you subtract from the drives allocated for other operations. But then there is the issue of: Just exactly how do hard drives work? For example, when doing a large write only operation (like creating an archived log) is the drive really doing this neat and tidy write only, one track after the next, each track right beside the other? Or does the drive actually write a little bit, read a little bit (like a check sum or verify operation), then write some more. And when writing, does it do this smooth, nicely contiguous write, all in one operation? Or does it write a little bit (like an OS buffer full), then move to a different track to update an allocation table (then perhaps read the allocation table), then perhaps go pick up a timing mark, etc.? I suspect some of the answer is dependent on the number of drives and controllers available. (And I must say, that when I read your original question, I wondered why on earth would an organization ready to drop a bundle on a 15K be scrounging for drives -- if I interpreted your post correctly. Is this a Dilbert sort of thing?) The only time I have striped across all drives was the only time I was in a position to make that decision. This was a few years ago, and it was when I did Solaris/AIX admin. It was on a Sparc 4500 with 6 250Mhz CPU's. Since we did not have an Oracle DBA, and I didn't have the time or inclination to devote to setting up and maintaining and official OFA compliant structure, I just made one giant (considered giant at the time) 250 Gb filesystem that would hold all things Oracle and be done with it. I made two 30-drive (8.4 Gb drives) stripes and mirrored them using Solstice Disk Suite. There were 10 wide scsi controllers. Each controller had a 6-drive JBOD attached to it. An eleventh controller had an additional JBOD to be used for hot spares. As you might guess, with a I/O pipe this big, there was no way the 6 CPU's could generate enough I/O to bog things down or even cause a hint of an I/O wait. So the stripe across all drives does work. In my case, I had 60 drives on 10 controllers to work with. Could this have been made more efficient by making a collection of smaller stripes? I have never found anyone who could answer that. The Disk Suite folk can tell you that there is an optimal striping configuration for Disk Suite if we leave Oracle out of the picture. But with Oracle in the picture, who knows? One configuration that sounds reasonable is to put data files with random reads and writes on one stripe, put even numbered redo logs on a stripe, put odd numbered redo logs on a stripe, put archived logs on a stripe. The reasoning (or arm-chair theory) behind the even/odd redo logs is that at a log switch, one file system can be doing writes, while the other is doing reads for the log archiving. This is sorta kinda the way we do things at our shop here with some modifications depending on the app -- like maybe dedicate a stripe to servicing the outrageous temp requirements of a data warehouse (more correctly, a data landfill). If you have only a few drives, my inclination (with no proof whatsoever) is that the one big stripe approach might be a good idea. Thus far, all I have ever gotten on this subject is a lot of religion and very few proven facts. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Stephen Lee INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Advice needed on move to Sun 15K (losing spindles)
Jay - Will your server partitioning protect the OLTP users from the DW queries? In the normal situation, a company first adds their DW to an existing system. Then they find that the DW doesn't make a good neighbor and buy a separate server. The DW typically does a LOT of full-table scans, so if you share disks, that may not be good for your OLTP. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Friday, October 11, 2002 11:15 AM To: Multiple recipients of list ORACLE-L I obviously left out a lot of information :). We would be using server partitioning, with seperate ORACLE_HOMES for each database (necessary since we have a variety of versions running). The box would be running 1+0, the Sun reps suggest striping across all disks (my first red flag). I hadn't even thought of the problem of not being able to reboot the server, that's an excellent point. Currently we have absolutely no performance problems on our OLTP database. This whole kerfuffle was an outgrowth of my pushing really hard to get a backup box for our datawarehouse (which currently has no standby, no box that it can restored to and no QA box). The suggestion was made that rather than get a separate box for the datawarehouse - get the 15K and have the OLTP and datawarehouse on different partitions. This would certainly speed up the data transfer between them (data is transferred from OLTP - Data Warehouse on a daily basis). We could then put other databases that access my databases on other partitions (several other databases have snapshots on some of my tables). So this would make some processes more efficient, but i/o on my OLTP database is currently tuned so well that it hurts every time I think of giving it up. One spindle has the Oracle executables with the redo logs on the outside of the disk. Another has the various .dat files, shell scripts, etc, with the archive logs on the outside of the disk. Even when we run really intensive updates our wio rarely gets very high. Regarding the load question: We have fairly active transaction activity during the day but most connections are managed by Microsoft Transaction Server in a middle tier so while there are usually app. 200 sessions (including some old client server apps) we rarely have more than 20 or so active at any one time. The datawarehouse has fewer sessions but often has some resource intensive queries running. If anyone can point me to docs/websites saying that a large caches does *not* make up for fewer disks/spindles I would greatly appreciate it. Currently I'm being told that Sun must know what they're talking about. Thanks again, Jay Miller -Original Message- Sent: Wednesday, October 09, 2002 5:19 PM To: Multiple recipients of list ORACLE-L Others have addressed the performance issues. What about the admin issues? If consolidate to a single server, consider a separate ORACLE_HOME for each database. You may need to apply different patches to fix different problems in various databases. You have this ability now, but will lose it if you consolidate without separate ORACLE_HOME's. Something else you will lose is the ability to reboot the server if needed for a single database. Since you may be moving to a 15k, investigate server partitioning to retain this functionality. Jared Miller, Jay [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/09/2002 11:53 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:Advice needed on move to Sun 15K (losing spindles) Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping 2 and 2). We could then at least seperate the redo logs from the datafiles (probably putting them with the oracle executables and some other files). The Sun rep kept talking up how much more powerful the CPUs were and I kept saying, but we're not CPU bound, we don't need any more CPU. If anyone can either a) tell me I'm worrying for nothing b) recommend a better way to stripe/distribute my files c) provide references or experience to show this is a bad idea I'd really appreciate it. Thanks, Jay Miller -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Miller, Jay INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services
RE: Advice needed on move to Sun 15K (losing spindles)
Title: RE: Advice needed on move to Sun 15K (losing spindles) Lets say a guy only has one finger on each hand to tie his shoe (mirroring). If he had five fingers (striping) he can accomplish the job quite a bit faster. Now give him 1000 shoes to tie and listen to him bitch about how he could use a work partner (spindle). Now give him the ability to lie so when management asks the team many shoes they have tied, they can stretch the truth a little bit (cacheing) =) -Original Message- From: Stephen Lee [mailto:[EMAIL PROTECTED]] Sent: Friday, October 11, 2002 2:46 PM To: Multiple recipients of list ORACLE-L Subject: RE: Advice needed on move to Sun 15K (losing spindles) I've cussed and discussed the topic of one big stripe versus multiple small stripes with different people and have yet to come across anyone who has conducted a real test of various scenarios. If you stripe across all disks, then you have the advantage of guaranteed, perfectly balance I/O -- there's certainly something to be said for that! But, then you have a mix of reads and writes going across all drives too. A good argument can be made for taking those parts of the database that tend to be only one kind of operation -- for example, archive logs are writes -- and putting them in their own area. So the drives handling the writing of archived logs are doing only one kind of operation (or are they?!), but you subtract from the drives allocated for other operations. But then there is the issue of: Just exactly how do hard drives work? For example, when doing a large write only operation (like creating an archived log) is the drive really doing this neat and tidy write only, one track after the next, each track right beside the other? Or does the drive actually write a little bit, read a little bit (like a check sum or verify operation), then write some more. And when writing, does it do this smooth, nicely contiguous write, all in one operation? Or does it write a little bit (like an OS buffer full), then move to a different track to update an allocation table (then perhaps read the allocation table), then perhaps go pick up a timing mark, etc.? I suspect some of the answer is dependent on the number of drives and controllers available. (And I must say, that when I read your original question, I wondered why on earth would an organization ready to drop a bundle on a 15K be scrounging for drives -- if I interpreted your post correctly. Is this a Dilbert sort of thing?) The only time I have striped across all drives was the only time I was in a position to make that decision. This was a few years ago, and it was when I did Solaris/AIX admin. It was on a Sparc 4500 with 6 250Mhz CPU's. Since we did not have an Oracle DBA, and I didn't have the time or inclination to devote to setting up and maintaining and official OFA compliant structure, I just made one giant (considered giant at the time) 250 Gb filesystem that would hold all things Oracle and be done with it. I made two 30-drive (8.4 Gb drives) stripes and mirrored them using Solstice Disk Suite. There were 10 wide scsi controllers. Each controller had a 6-drive JBOD attached to it. An eleventh controller had an additional JBOD to be used for hot spares. As you might guess, with a I/O pipe this big, there was no way the 6 CPU's could generate enough I/O to bog things down or even cause a hint of an I/O wait. So the stripe across all drives does work. In my case, I had 60 drives on 10 controllers to work with. Could this have been made more efficient by making a collection of smaller stripes? I have never found anyone who could answer that. The Disk Suite folk can tell you that there is an optimal striping configuration for Disk Suite if we leave Oracle out of the picture. But with Oracle in the picture, who knows? One configuration that sounds reasonable is to put data files with random reads and writes on one stripe, put even numbered redo logs on a stripe, put odd numbered redo logs on a stripe, put archived logs on a stripe. The reasoning (or arm-chair theory) behind the even/odd redo logs is that at a log switch, one file system can be doing writes, while the other is doing reads for the log archiving. This is sorta kinda the way we do things at our shop here with some modifications depending on the app -- like maybe dedicate a stripe to servicing the outrageous temp requirements of a data warehouse (more correctly, a data landfill). If you have only a few drives, my inclination (with no proof whatsoever) is that the one big stripe approach might be a good idea. Thus far, all I have ever gotten on this subject is a lot of religion and very few proven facts. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Stephen Lee INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services
RE: Advice needed on move to Sun 15K (losing spindles)
Well, there are Gaja's papers : Proactive Storage Management - A Method to Predictable System Performance, and Implementing RAID on Oracle systems available at http://www.quest.com/whitepapers. Scan the page for Title and for not Gaja's name. - Kirti -Original Message- Sent: Friday, October 11, 2002 1:20 PM To: Multiple recipients of list ORACLE-L Thanks Kirti! I loved the line The first thing to do, regardless of platform or claims by the vendor, is to completely forget the existence of a cache Any similar references will be greatly appreciated. The more ammunition I have the likelier I am to kill something :) Jay -Original Message- Sent: Friday, October 11, 2002 12:36 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] I suggest reviewing James Morle's paper 'Sane SAN' at http://www.oraperf.com/whitepapers.html. - Kirti -Original Message- Sent: Friday, October 11, 2002 11:15 AM To: Multiple recipients of list ORACLE-L I obviously left out a lot of information :). We would be using server partitioning, with seperate ORACLE_HOMES for each database (necessary since we have a variety of versions running). The box would be running 1+0, the Sun reps suggest striping across all disks (my first red flag). I hadn't even thought of the problem of not being able to reboot the server, that's an excellent point. Currently we have absolutely no performance problems on our OLTP database. This whole kerfuffle was an outgrowth of my pushing really hard to get a backup box for our datawarehouse (which currently has no standby, no box that it can restored to and no QA box). The suggestion was made that rather than get a separate box for the datawarehouse - get the 15K and have the OLTP and datawarehouse on different partitions. This would certainly speed up the data transfer between them (data is transferred from OLTP - Data Warehouse on a daily basis). We could then put other databases that access my databases on other partitions (several other databases have snapshots on some of my tables). So this would make some processes more efficient, but i/o on my OLTP database is currently tuned so well that it hurts every time I think of giving it up. One spindle has the Oracle executables with the redo logs on the outside of the disk. Another has the various .dat files, shell scripts, etc, with the archive logs on the outside of the disk. Even when we run really intensive updates our wio rarely gets very high. Regarding the load question: We have fairly active transaction activity during the day but most connections are managed by Microsoft Transaction Server in a middle tier so while there are usually app. 200 sessions (including some old client server apps) we rarely have more than 20 or so active at any one time. The datawarehouse has fewer sessions but often has some resource intensive queries running. If anyone can point me to docs/websites saying that a large caches does *not* make up for fewer disks/spindles I would greatly appreciate it. Currently I'm being told that Sun must know what they're talking about. Thanks again, Jay Miller -Original Message- Sent: Wednesday, October 09, 2002 5:19 PM To: Multiple recipients of list ORACLE-L Others have addressed the performance issues. What about the admin issues? If consolidate to a single server, consider a separate ORACLE_HOME for each database. You may need to apply different patches to fix different problems in various databases. You have this ability now, but will lose it if you consolidate without separate ORACLE_HOME's. Something else you will lose is the ability to reboot the server if needed for a single database. Since you may be moving to a 15k, investigate server partitioning to retain this functionality. Jared Miller, Jay [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/09/2002 11:53 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:Advice needed on move to Sun 15K (losing spindles) Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping 2 and 2). We could then at least seperate the redo logs from the datafiles (probably putting them with the oracle executables and some other files). The Sun rep kept talking up how much more powerful the CPUs were and I kept saying, but we're not CPU bound, we don't need any more CPU. If anyone can either a) tell me I'm worrying for nothing b)
RE: Advice needed on move to Sun 15K (losing spindles)
Check out www.hotsos.com/dnloads/1.Littlefield2000.01.03-Specs.pdf, written a couple of years ago by Jim Littlefield of Real Networks. Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Hotsos Clinic, Oct 15-17 Dallas, Dec 9-11 Honolulu - 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas - Jonathan Lewis' Optimising Oracle, Nov 19-21 Dallas -Original Message- Jay Sent: Friday, October 11, 2002 1:20 PM To: Multiple recipients of list ORACLE-L Thanks Kirti! I loved the line The first thing to do, regardless of platform or claims by the vendor, is to completely forget the existence of a cache Any similar references will be greatly appreciated. The more ammunition I have the likelier I am to kill something :) Jay -Original Message- Sent: Friday, October 11, 2002 12:36 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] I suggest reviewing James Morle's paper 'Sane SAN' at http://www.oraperf.com/whitepapers.html. - Kirti -Original Message- Sent: Friday, October 11, 2002 11:15 AM To: Multiple recipients of list ORACLE-L I obviously left out a lot of information :). We would be using server partitioning, with seperate ORACLE_HOMES for each database (necessary since we have a variety of versions running). The box would be running 1+0, the Sun reps suggest striping across all disks (my first red flag). I hadn't even thought of the problem of not being able to reboot the server, that's an excellent point. Currently we have absolutely no performance problems on our OLTP database. This whole kerfuffle was an outgrowth of my pushing really hard to get a backup box for our datawarehouse (which currently has no standby, no box that it can restored to and no QA box). The suggestion was made that rather than get a separate box for the datawarehouse - get the 15K and have the OLTP and datawarehouse on different partitions. This would certainly speed up the data transfer between them (data is transferred from OLTP - Data Warehouse on a daily basis). We could then put other databases that access my databases on other partitions (several other databases have snapshots on some of my tables). So this would make some processes more efficient, but i/o on my OLTP database is currently tuned so well that it hurts every time I think of giving it up. One spindle has the Oracle executables with the redo logs on the outside of the disk. Another has the various .dat files, shell scripts, etc, with the archive logs on the outside of the disk. Even when we run really intensive updates our wio rarely gets very high. Regarding the load question: We have fairly active transaction activity during the day but most connections are managed by Microsoft Transaction Server in a middle tier so while there are usually app. 200 sessions (including some old client server apps) we rarely have more than 20 or so active at any one time. The datawarehouse has fewer sessions but often has some resource intensive queries running. If anyone can point me to docs/websites saying that a large caches does *not* make up for fewer disks/spindles I would greatly appreciate it. Currently I'm being told that Sun must know what they're talking about. Thanks again, Jay Miller -Original Message- Sent: Wednesday, October 09, 2002 5:19 PM To: Multiple recipients of list ORACLE-L Others have addressed the performance issues. What about the admin issues? If consolidate to a single server, consider a separate ORACLE_HOME for each database. You may need to apply different patches to fix different problems in various databases. You have this ability now, but will lose it if you consolidate without separate ORACLE_HOME's. Something else you will lose is the ability to reboot the server if needed for a single database. Since you may be moving to a 15k, investigate server partitioning to retain this functionality. Jared Miller, Jay [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/09/2002 11:53 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:Advice needed on move to Sun 15K (losing spindles) Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping 2 and 2). We could then at least seperate the redo logs from the datafiles (probably putting them with the oracle executables and some other files). The Sun rep kept talking up how much more powerful the CPUs were
RE: Advice needed on move to Sun 15K (losing spindles)
Yes, it's entirely separate CPUs and disks. If I can believe the Sun rep (ehem) there should be no interference. -Original Message- Sent: Friday, October 11, 2002 3:30 PM To: Multiple recipients of list ORACLE-L Jay - Will your server partitioning protect the OLTP users from the DW queries? In the normal situation, a company first adds their DW to an existing system. Then they find that the DW doesn't make a good neighbor and buy a separate server. The DW typically does a LOT of full-table scans, so if you share disks, that may not be good for your OLTP. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Friday, October 11, 2002 11:15 AM To: Multiple recipients of list ORACLE-L I obviously left out a lot of information :). We would be using server partitioning, with seperate ORACLE_HOMES for each database (necessary since we have a variety of versions running). The box would be running 1+0, the Sun reps suggest striping across all disks (my first red flag). I hadn't even thought of the problem of not being able to reboot the server, that's an excellent point. Currently we have absolutely no performance problems on our OLTP database. This whole kerfuffle was an outgrowth of my pushing really hard to get a backup box for our datawarehouse (which currently has no standby, no box that it can restored to and no QA box). The suggestion was made that rather than get a separate box for the datawarehouse - get the 15K and have the OLTP and datawarehouse on different partitions. This would certainly speed up the data transfer between them (data is transferred from OLTP - Data Warehouse on a daily basis). We could then put other databases that access my databases on other partitions (several other databases have snapshots on some of my tables). So this would make some processes more efficient, but i/o on my OLTP database is currently tuned so well that it hurts every time I think of giving it up. One spindle has the Oracle executables with the redo logs on the outside of the disk. Another has the various .dat files, shell scripts, etc, with the archive logs on the outside of the disk. Even when we run really intensive updates our wio rarely gets very high. Regarding the load question: We have fairly active transaction activity during the day but most connections are managed by Microsoft Transaction Server in a middle tier so while there are usually app. 200 sessions (including some old client server apps) we rarely have more than 20 or so active at any one time. The datawarehouse has fewer sessions but often has some resource intensive queries running. If anyone can point me to docs/websites saying that a large caches does *not* make up for fewer disks/spindles I would greatly appreciate it. Currently I'm being told that Sun must know what they're talking about. Thanks again, Jay Miller -Original Message- Sent: Wednesday, October 09, 2002 5:19 PM To: Multiple recipients of list ORACLE-L Others have addressed the performance issues. What about the admin issues? If consolidate to a single server, consider a separate ORACLE_HOME for each database. You may need to apply different patches to fix different problems in various databases. You have this ability now, but will lose it if you consolidate without separate ORACLE_HOME's. Something else you will lose is the ability to reboot the server if needed for a single database. Since you may be moving to a 15k, investigate server partitioning to retain this functionality. Jared Miller, Jay [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/09/2002 11:53 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:Advice needed on move to Sun 15K (losing spindles) Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping 2 and 2). We could then at least seperate the redo logs from the datafiles (probably putting them with the oracle executables and some other files). The Sun rep kept talking up how much more powerful the CPUs were and I kept saying, but we're not CPU bound, we don't need any more CPU. If anyone can either a) tell me I'm worrying for nothing b) recommend a better way to stripe/distribute my files c) provide references or experience to show this is a bad idea I'd really appreciate it. Thanks, Jay Miller -- Please see the official ORACLE-L FAQ:
RE: Advice needed on move to Sun 15K (losing spindles)
Thanks, I'm reading the first one now. Jay -Original Message- Sent: Friday, October 11, 2002 3:19 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Well, there are Gaja's papers : Proactive Storage Management - A Method to Predictable System Performance, and Implementing RAID on Oracle systems available at http://www.quest.com/whitepapers. Scan the page for Title and for not Gaja's name. - Kirti -Original Message- Sent: Friday, October 11, 2002 1:20 PM To: Multiple recipients of list ORACLE-L Thanks Kirti! I loved the line The first thing to do, regardless of platform or claims by the vendor, is to completely forget the existence of a cache Any similar references will be greatly appreciated. The more ammunition I have the likelier I am to kill something :) Jay -Original Message- Sent: Friday, October 11, 2002 12:36 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] I suggest reviewing James Morle's paper 'Sane SAN' at http://www.oraperf.com/whitepapers.html. - Kirti -Original Message- Sent: Friday, October 11, 2002 11:15 AM To: Multiple recipients of list ORACLE-L I obviously left out a lot of information :). We would be using server partitioning, with seperate ORACLE_HOMES for each database (necessary since we have a variety of versions running). The box would be running 1+0, the Sun reps suggest striping across all disks (my first red flag). I hadn't even thought of the problem of not being able to reboot the server, that's an excellent point. Currently we have absolutely no performance problems on our OLTP database. This whole kerfuffle was an outgrowth of my pushing really hard to get a backup box for our datawarehouse (which currently has no standby, no box that it can restored to and no QA box). The suggestion was made that rather than get a separate box for the datawarehouse - get the 15K and have the OLTP and datawarehouse on different partitions. This would certainly speed up the data transfer between them (data is transferred from OLTP - Data Warehouse on a daily basis). We could then put other databases that access my databases on other partitions (several other databases have snapshots on some of my tables). So this would make some processes more efficient, but i/o on my OLTP database is currently tuned so well that it hurts every time I think of giving it up. One spindle has the Oracle executables with the redo logs on the outside of the disk. Another has the various .dat files, shell scripts, etc, with the archive logs on the outside of the disk. Even when we run really intensive updates our wio rarely gets very high. Regarding the load question: We have fairly active transaction activity during the day but most connections are managed by Microsoft Transaction Server in a middle tier so while there are usually app. 200 sessions (including some old client server apps) we rarely have more than 20 or so active at any one time. The datawarehouse has fewer sessions but often has some resource intensive queries running. If anyone can point me to docs/websites saying that a large caches does *not* make up for fewer disks/spindles I would greatly appreciate it. Currently I'm being told that Sun must know what they're talking about. Thanks again, Jay Miller -Original Message- Sent: Wednesday, October 09, 2002 5:19 PM To: Multiple recipients of list ORACLE-L Others have addressed the performance issues. What about the admin issues? If consolidate to a single server, consider a separate ORACLE_HOME for each database. You may need to apply different patches to fix different problems in various databases. You have this ability now, but will lose it if you consolidate without separate ORACLE_HOME's. Something else you will lose is the ability to reboot the server if needed for a single database. Since you may be moving to a 15k, investigate server partitioning to retain this functionality. Jared Miller, Jay [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/09/2002 11:53 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:Advice needed on move to Sun 15K (losing spindles) Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping 2 and 2). We could then at least seperate the redo logs from the datafiles (probably putting them with the oracle executables and some other files). The Sun rep kept talking up how much more
RE: Advice needed on move to Sun 15K (losing spindles)
One thing that should be made clear: Never, ever, stripe with parity (i.e. RAID 5, etc.) unless you are force, at gunpoint, to do it. That is BAD. Your database will run faster on an abacus ... well ... maybe a slide rule. -Original Message- Yes, it's entirely separate CPUs and disks. If I can believe the Sun rep (ehem) there should be no interference. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Stephen Lee INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Advice needed on move to Sun 15K (losing spindles)
Thank you very much! I can tell what I'll be reading this weekend :). With highlighter in hand... Jay -Original Message- Sent: Friday, October 11, 2002 4:31 PM To: Multiple recipients of list ORACLE-L Check out www.hotsos.com/dnloads/1.Littlefield2000.01.03-Specs.pdf, written a couple of years ago by Jim Littlefield of Real Networks. Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Hotsos Clinic, Oct 15-17 Dallas, Dec 9-11 Honolulu - 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas - Jonathan Lewis' Optimising Oracle, Nov 19-21 Dallas -Original Message- Jay Sent: Friday, October 11, 2002 1:20 PM To: Multiple recipients of list ORACLE-L Thanks Kirti! I loved the line The first thing to do, regardless of platform or claims by the vendor, is to completely forget the existence of a cache Any similar references will be greatly appreciated. The more ammunition I have the likelier I am to kill something :) Jay -Original Message- Sent: Friday, October 11, 2002 12:36 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] I suggest reviewing James Morle's paper 'Sane SAN' at http://www.oraperf.com/whitepapers.html. - Kirti -Original Message- Sent: Friday, October 11, 2002 11:15 AM To: Multiple recipients of list ORACLE-L I obviously left out a lot of information :). We would be using server partitioning, with seperate ORACLE_HOMES for each database (necessary since we have a variety of versions running). The box would be running 1+0, the Sun reps suggest striping across all disks (my first red flag). I hadn't even thought of the problem of not being able to reboot the server, that's an excellent point. Currently we have absolutely no performance problems on our OLTP database. This whole kerfuffle was an outgrowth of my pushing really hard to get a backup box for our datawarehouse (which currently has no standby, no box that it can restored to and no QA box). The suggestion was made that rather than get a separate box for the datawarehouse - get the 15K and have the OLTP and datawarehouse on different partitions. This would certainly speed up the data transfer between them (data is transferred from OLTP - Data Warehouse on a daily basis). We could then put other databases that access my databases on other partitions (several other databases have snapshots on some of my tables). So this would make some processes more efficient, but i/o on my OLTP database is currently tuned so well that it hurts every time I think of giving it up. One spindle has the Oracle executables with the redo logs on the outside of the disk. Another has the various .dat files, shell scripts, etc, with the archive logs on the outside of the disk. Even when we run really intensive updates our wio rarely gets very high. Regarding the load question: We have fairly active transaction activity during the day but most connections are managed by Microsoft Transaction Server in a middle tier so while there are usually app. 200 sessions (including some old client server apps) we rarely have more than 20 or so active at any one time. The datawarehouse has fewer sessions but often has some resource intensive queries running. If anyone can point me to docs/websites saying that a large caches does *not* make up for fewer disks/spindles I would greatly appreciate it. Currently I'm being told that Sun must know what they're talking about. Thanks again, Jay Miller -Original Message- Sent: Wednesday, October 09, 2002 5:19 PM To: Multiple recipients of list ORACLE-L Others have addressed the performance issues. What about the admin issues? If consolidate to a single server, consider a separate ORACLE_HOME for each database. You may need to apply different patches to fix different problems in various databases. You have this ability now, but will lose it if you consolidate without separate ORACLE_HOME's. Something else you will lose is the ability to reboot the server if needed for a single database. Since you may be moving to a 15k, investigate server partitioning to retain this functionality. Jared Miller, Jay [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/09/2002 11:53 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:Advice needed on move to Sun 15K (losing spindles) Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping
RE: Advice needed on move to Sun 15K (losing spindles)
Fortunately my SA believes that so we were able to present a united front at the presentation (and yes, the Sun rep said that with a large enough cache RAID 5 works just as well as 1+0 - which is what we would be using). Jay Miller -Original Message- Sent: Friday, October 11, 2002 4:54 PM To: Multiple recipients of list ORACLE-L One thing that should be made clear: Never, ever, stripe with parity (i.e. RAID 5, etc.) unless you are force, at gunpoint, to do it. That is BAD. Your database will run faster on an abacus ... well ... maybe a slide rule. -Original Message- Yes, it's entirely separate CPUs and disks. If I can believe the Sun rep (ehem) there should be no interference. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Stephen Lee INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Miller, Jay 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: Advice needed on move to Sun 15K (losing spindles)
More than separate ORACLE_HOMEs, you might also consider individual oracle software owner accounts and dba and oper groups for each database... Folks often install all Oracle distributions under a single account, oracle, specifying a single SYSDBA group (dba) and a single SYSOPER group (oper). The intent is usually to have database instances share ORACLE_HOMEs where possible... There are several practical downsides to this: * different applications may require different patch levels of the same version (i.e. same ORACLE_HOME) * it is difficult to track resource consumption (i.e. cpu, memory, I/O) using OS utilities if numerous Oracle database instances run under the single oracle account * if administration of different database instances is to be performed by separate individuals or teams, there is no way to isolate/protect each team's territory from another Although HW vendors (including Sun) have developed partitioning schemes for servers, it is perhaps overkill. A form of server partitioning has always been possible by making creative use of OS accounts and groups. The major difference between the HW vendors server partitioning scheme and using OS accounts to separate things is the fact that the former actually assigns groups of CPUs and allocates memory to each partition. Dividing by OS accounts allows all resources to be shared amongst the partitions. The trade-offs should be obvious... - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, October 09, 2002 3:18 PM Others have addressed the performance issues. What about the admin issues? If consolidate to a single server, consider a separate ORACLE_HOME for each database. You may need to apply different patches to fix different problems in various databases. You have this ability now, but will lose it if you consolidate without separate ORACLE_HOME's. Something else you will lose is the ability to reboot the server if needed for a single database. Since you may be moving to a 15k, investigate server partitioning to retain this functionality. Jared Miller, Jay [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/09/2002 11:53 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:Advice needed on move to Sun 15K (losing spindles) Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping 2 and 2). We could then at least seperate the redo logs from the datafiles (probably putting them with the oracle executables and some other files). The Sun rep kept talking up how much more powerful the CPUs were and I kept saying, but we're not CPU bound, we don't need any more CPU. If anyone can either a) tell me I'm worrying for nothing b) recommend a better way to stripe/distribute my files c) provide references or experience to show this is a bad idea I'd really appreciate it. Thanks, Jay Miller -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Miller, Jay INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Tim Gorman INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051
RE: Advice needed on move to Sun 15K (losing spindles)
Jay - I share your concerns. Can you elaborate more on how heavily loaded the system is? Is it somewhat I/O bound? Basically you're saying that it would have a single RAID0 set? If you divided the disks differently to create 2 or 4 RAID sets, would there be enough room for your application? I've run Oracle systems with a single RAID set, but not with a significant load. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Wednesday, October 09, 2002 1:54 PM To: Multiple recipients of list ORACLE-L Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping 2 and 2). We could then at least seperate the redo logs from the datafiles (probably putting them with the oracle executables and some other files). The Sun rep kept talking up how much more powerful the CPUs were and I kept saying, but we're not CPU bound, we don't need any more CPU. If anyone can either a) tell me I'm worrying for nothing b) recommend a better way to stripe/distribute my files c) provide references or experience to show this is a bad idea I'd really appreciate it. Thanks, Jay Miller -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Miller, Jay 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: DENNIS WILLIAMS 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: Advice needed on move to Sun 15K (losing spindles)
This one is so easy that even a high school student could answer it. Use the theory of constraints (book called The Goal) to this one. When you reduce the number of resources to process a job, sequentially or concurrently, you induce bottlenecks within the process. Thus, by reducing the number of available spindles, you reduce the overall capabilities of the system. Not hard to accomplish. All of the vendors sell their caching technology as a way to avoid bottlenecks. First, shoot the sales rep from Sun and make him explain all of the performance bottlenecks to the CEO. Next, buy more disk. I truly wish disk vendors would stop increasing the minimum storage amount for disks, selling that to CIO's as a way to perform server consolidation, and then not taking the blame for the performance mess. Cache does not work, never worked and will never continue to work until the pipeline is the same size. Use basic theories and you will see the light. Thank You Stephen P. Karniotis Product Architect Compuware Corporation Direct: (248) 865-4350 Mobile: (248) 408-2918 Email: [EMAIL PROTECTED] Web:www.compuware.com -Original Message- Sent: Wednesday, October 09, 2002 2:54 PM To: Multiple recipients of list ORACLE-L Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping 2 and 2). We could then at least seperate the redo logs from the datafiles (probably putting them with the oracle executables and some other files). The Sun rep kept talking up how much more powerful the CPUs were and I kept saying, but we're not CPU bound, we don't need any more CPU. If anyone can either a) tell me I'm worrying for nothing b) recommend a better way to stripe/distribute my files c) provide references or experience to show this is a bad idea I'd really appreciate it. Thanks, Jay Miller -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Miller, Jay 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). The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Karniotis, Stephen 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: Advice needed on move to Sun 15K (losing spindles)
Jay, You will hit performance problems because of not having I/O bandwidth. Databases don't need storage, they need IO operations. Two important pieces of info that are missing from your post: - How many databases in total are going to run on this Sun 15K ? - How many concurrent users on all databases at the same time ? Anjo. Miller, Jay wrote: Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping 2 and 2). We could then at least seperate the redo logs from the datafiles (probably putting them with the oracle executables and some other files). The Sun rep kept talking up how much more powerful the CPUs were and I kept saying, but we're not CPU bound, we don't need any more CPU. If anyone can either a) tell me I'm worrying for nothing b) recommend a better way to stripe/distribute my files c) provide references or experience to show this is a bad idea I'd really appreciate it. Thanks, Jay Miller -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Miller, Jay 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: Anjo Kolk 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: Advice needed on move to Sun 15K (losing spindles)
Others have addressed the performance issues. What about the admin issues? If consolidate to a single server, consider a separate ORACLE_HOME for each database. You may need to apply different patches to fix different problems in various databases. You have this ability now, but will lose it if you consolidate without separate ORACLE_HOME's. Something else you will lose is the ability to reboot the server if needed for a single database. Since you may be moving to a 15k, investigate server partitioning to retain this functionality. Jared Miller, Jay [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/09/2002 11:53 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:Advice needed on move to Sun 15K (losing spindles) Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping 2 and 2). We could then at least seperate the redo logs from the datafiles (probably putting them with the oracle executables and some other files). The Sun rep kept talking up how much more powerful the CPUs were and I kept saying, but we're not CPU bound, we don't need any more CPU. If anyone can either a) tell me I'm worrying for nothing b) recommend a better way to stripe/distribute my files c) provide references or experience to show this is a bad idea I'd really appreciate it. Thanks, Jay Miller -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Miller, Jay INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Advice needed on move to Sun 15K (losing spindles)
I bet you Sun rep , while trying to unload some hardware on you, has never heard of the term Logical I/O.Many times when upgrading, one can make things worse , not better. If you are having performance problems, then zero in on what those could be and fix it there. Take some snapshots, 10046 data traces and or look at the session / system events for where you waits may be.Then fix them ... then tell your management you saved them 100's of 1000's of . Then they will give you a great big raise yah right !!! fwiw ... Mike -Original Message- Sent: Wednesday, October 09, 2002 11:54 AM To: Multiple recipients of list ORACLE-L Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping 2 and 2). We could then at least seperate the redo logs from the datafiles (probably putting them with the oracle executables and some other files). The Sun rep kept talking up how much more powerful the CPUs were and I kept saying, but we're not CPU bound, we don't need any more CPU. If anyone can either a) tell me I'm worrying for nothing b) recommend a better way to stripe/distribute my files c) provide references or experience to show this is a bad idea I'd really appreciate it. Thanks, Jay Miller -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Miller, Jay 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: Johnson, Michael 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: Advice needed on move to Sun 15K (losing spindles)
Ask the Sun guys if they will sign a document saying they will pay all cost including hardware to fix the performance problems, if after you make the change and performance is worse. It will show that you are serious and if they seriously believe they are right then they have nothing to fear, I never understand why these vendors insist in building systems with so little hardware Cheers -- = Peter McLarty E-mail: [EMAIL PROTECTED] Technical ConsultantWWW: http://www.mincom.com APAC Technical Services Phone: +61 (0)7 3303 3461 Brisbane, AustraliaMobile: +61 (0)402 094 238 Facsimile: +61 (0)7 3303 3048 = A great pleasure in life is doing what people say you cannot do. - Walter Bagehot (1826-1877 British Economist) = Mincom The People, The Experience, The Vision = This transmission is for the intended addressee only and is confidential information. If you have received this transmission in error, please delete it and notify the sender. The contents of this e-mail are the opinion of the writer only and are not endorsed by the Mincom Group of companies unless expressly stated otherwise. Anjo Kolk [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10-10-2002 05:43 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:Re: Advice needed on move to Sun 15K (losing spindles) Jay, You will hit performance problems because of not having I/O bandwidth. Databases don't need storage, they need IO operations. Two important pieces of info that are missing from your post: - How many databases in total are going to run on this Sun 15K ? - How many concurrent users on all databases at the same time ? Anjo. Miller, Jay wrote: Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping 2 and 2). We could then at least seperate the redo logs from the datafiles (probably putting them with the oracle executables and some other files). The Sun rep kept talking up how much more powerful the CPUs were and I kept saying, but we're not CPU bound, we don't need any more CPU. If anyone can either a) tell me I'm worrying for nothing b) recommend a better way to stripe/distribute my files c) provide references or experience to show this is a bad idea I'd really appreciate it. Thanks, Jay Miller -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Miller, Jay 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: Anjo Kolk 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). STG18945 Description: Binary data
RE: Advice needed on move to Sun 15K (losing spindles)
Stephen hit it right on the head !! Buy your CEO a copy of 'The Goal' ! It will be very useful in this and all future for such 'adventures'. How big is this Cache? And how big are all the databases that will be running on this big server? If database size is cache, then cash goes to the Vendor to buy more cache !! We have experienced this and are living with mixed out cache that gets saturated in less than an hour after we bring up the databases for business. Also, please keep in mind that faster CPUs can amplify your existing I/O bottlenecks. We went through this Sever Consolidation not too long ago. After an interesting 'finger pointing' game, we are now re-deploying 'selected' databases in their own environments. - Kirti -Original Message- Sent: Wednesday, October 09, 2002 2:24 PM To: Multiple recipients of list ORACLE-L This one is so easy that even a high school student could answer it. Use the theory of constraints (book called The Goal) to this one. When you reduce the number of resources to process a job, sequentially or concurrently, you induce bottlenecks within the process. Thus, by reducing the number of available spindles, you reduce the overall capabilities of the system. Not hard to accomplish. All of the vendors sell their caching technology as a way to avoid bottlenecks. First, shoot the sales rep from Sun and make him explain all of the performance bottlenecks to the CEO. Next, buy more disk. I truly wish disk vendors would stop increasing the minimum storage amount for disks, selling that to CIO's as a way to perform server consolidation, and then not taking the blame for the performance mess. Cache does not work, never worked and will never continue to work until the pipeline is the same size. Use basic theories and you will see the light. Thank You Stephen P. Karniotis Product Architect Compuware Corporation Direct: (248) 865-4350 Mobile: (248) 408-2918 Email: [EMAIL PROTECTED] Web:www.compuware.com -Original Message- Sent: Wednesday, October 09, 2002 2:54 PM To: Multiple recipients of list ORACLE-L Our CIO has suggested that we get a Sun 15K to house all of our databases. This has some advantages (communication between the various boxes would be much faster) but I have some performance concerns. Specifically, our main OLTP database would go down from 18 spindles to 8 spindles. Mirroring will take away 4 of those leaving 4 spindles. The vendor (Sun) was recommending striping across all 4 spindles. He said we don't need to worry about i/o issues because there will be a large cache. I'm skeptical and argued for cutting them in half (striping 2 and 2). We could then at least seperate the redo logs from the datafiles (probably putting them with the oracle executables and some other files). The Sun rep kept talking up how much more powerful the CPUs were and I kept saying, but we're not CPU bound, we don't need any more CPU. If anyone can either a) tell me I'm worrying for nothing b) recommend a better way to stripe/distribute my files c) provide references or experience to show this is a bad idea I'd really appreciate it. Thanks, Jay Miller -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Miller, Jay 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). The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Karniotis, Stephen INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Deshpande, Kirti INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051
