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) 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: 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: 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: Deshpande, Kirti INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
