Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Advice needed on move to Sun 15K (losing spindles)

RE: Advice needed on move to Sun 15K (losing spindles)

From: Deshpande, Kirti <kirti.deshpande_at_verizon.com>
Date: Wed, 09 Oct 2002 19:28:31 -0800
Message-ID: <F001.004E5370.20021009192831@fatcity.com>


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.

-----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:	Stephen.Karniotis_at_Compuware.com
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

  1. tell me I'm worrying for nothing
  2. recommend a better way to stripe/distribute my files
  3. 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: JayMiller_at_TDWaterhouse.com

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: ListGuru_at_fatcity.com (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: Stephen_Karniotis_at_compuware.com

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: ListGuru_at_fatcity.com (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: kirti.deshpande_at_verizon.com
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: ListGuru_at_fatcity.com (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). Received on Wed Oct 09 2002 - 22:28:31 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US