FAQ
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


tell me I'm worrying for nothing
recommend a better way to stripe/distribute my files
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).

Search Discussions

  • Karniotis, Stephen at Oct 9, 2002 at 7:24 pm
    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

    tell me I'm worrying for nothing
    recommend a better way to stripe/distribute my files
    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).
  • DENNIS WILLIAMS at Oct 9, 2002 at 7:24 pm
    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.
    dwilliams_at_lifetouch.com

    -----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


    tell me I'm worrying for nothing
    recommend a better way to stripe/distribute my files
    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).
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: DENNIS WILLIAMS
    INET: DWILLIAMS_at_LIFETOUCH.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).
  • Anjo Kolk at Oct 9, 2002 at 7:43 pm
    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: 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).
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Anjo Kolk
    INET: anjo_at_oraperf.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).
  • Jared.Still_at_radisys.com at Oct 9, 2002 at 9: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"
    Sent by: root_at_fatcity.com
    10/09/2002 11:53 AM
    Please respond to ORACLE-L



    To: Multiple recipients of list ORACLE-L
    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


    tell me I'm worrying for nothing
    recommend a better way to stripe/distribute my files
    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).

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jared.Still_at_radisys.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).
  • Johnson, Michael at Oct 10, 2002 at 12:38 am
    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


    tell me I'm worrying for nothing
    recommend a better way to stripe/distribute my files
    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).
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Johnson, Michael
    INET: Michael.Johnson_at_oln-afmc.af.mil

    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).
  • Peter.McLarty_at_mincom.com at Oct 10, 2002 at 1:58 am
    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: Peter.Mclarty_at_mincom.com
    Technical Consultant WWW: http://www.mincom.com
    APAC Technical Services Phone: +61 (0)7 3303 3461
    Brisbane, Australia Mobile: +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
    Sent by: root_at_fatcity.com
    10-10-2002 05:43 AM
    Please respond to ORACLE-L

    To: Multiple recipients of list ORACLE-L
    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: 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).
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Anjo Kolk
    INET: anjo_at_oraperf.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).

    Content-Type: text/plain; name="ReadMe.txt"; charset="us-ascii"
    Content-Transfer-Encoding: 7bit

    The previous attachment was filtered out by the ListGuru mailing
    software at fatcity.com because binary attachments are not appropriate
    for mailing lists. If you want a copy of the attachment which was
    removed, contact the sender directly and ask for it to be sent to
    you by private E-mail.

    This warning is inserted into all messages containing binary
    attachments which have been removed by ListGuru. If you have questions
    about this message, contact Postmaster_at_fatcity.com for clarification.

    --=_mixed 0004EFA84A256C4E_=--
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Peter.McLarty_at_mincom.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).

    application/octet-stream attachment: STG18945
  • Deshpande, Kirti at Oct 10, 2002 at 3:28 am
    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: 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

    tell me I'm worrying for nothing
    recommend a better way to stripe/distribute my files
    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).
  • Tim Gorman at Oct 10, 2002 at 4:53 pm
    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"
    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"
    Sent by: root_at_fatcity.com
    10/09/2002 11:53 AM
    Please respond to ORACLE-L


    To: Multiple recipients of list ORACLE-L
    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: 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).



    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jared.Still_at_radisys.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: Tim Gorman
    INET: Tim_at_SageLogix.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).
  • Miller, Jay at Oct 11, 2002 at 4:14 pm
    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"
    Sent by: root_at_fatcity.com
    10/09/2002 11:53 AM
    Please respond to ORACLE-L



    To: Multiple recipients of list ORACLE-L
    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


    tell me I'm worrying for nothing
    recommend a better way to stripe/distribute my files
    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).

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jared.Still_at_radisys.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: 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).
  • Deshpande, Kirti at Oct 11, 2002 at 5:43 pm
    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"
    Sent by: root_at_fatcity.com
    10/09/2002 11:53 AM
    Please respond to ORACLE-L



    To: Multiple recipients of list ORACLE-L
    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


    tell me I'm worrying for nothing
    recommend a better way to stripe/distribute my files
    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).

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jared.Still_at_radisys.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: 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).
    --
    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).
  • Thomas Day at Oct 11, 2002 at 5:54 pm
    Why does "management" trust a salesman over their own IT professionals?

    "Miller, Jay"

    @TDWaterhouse cc:
    .com> Subject: 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"
    Sent by: root_at_fatcity.com
    10/09/2002 11:53 AM
    Please respond to ORACLE-L

    To: Multiple recipients of list ORACLE-L
    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

    tell me I'm worrying for nothing
    recommend a better way to stripe/distribute my files
    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).

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jared.Still_at_radisys.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: 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).

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Thomas Day
    INET: tday6_at_csc.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).
  • Deshpande, Kirti at Oct 11, 2002 at 6:14 pm
    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"

    @TDWaterhouse cc:

    .com> Subject: 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"
    Sent by: root_at_fatcity.com
    10/09/2002 11:53 AM
    Please respond to ORACLE-L

    To: Multiple recipients of list ORACLE-L
    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

    tell me I'm worrying for nothing
    recommend a better way to stripe/distribute my files
    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).

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jared.Still_at_radisys.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: 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).

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Thomas Day
    INET: tday6_at_csc.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).
  • Miller, Jay at Oct 11, 2002 at 6:19 pm
    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: ORACLE-L_at_fatcity.com
    Cc: JayMiller_at_TDWaterhouse.com

    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"
    Sent by: root_at_fatcity.com
    10/09/2002 11:53 AM
    Please respond to ORACLE-L



    To: Multiple recipients of list ORACLE-L
    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


    tell me I'm worrying for nothing
    recommend a better way to stripe/distribute my files
    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).

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jared.Still_at_radisys.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: 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).
    --
    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).
  • Stephen Lee at Oct 11, 2002 at 6:46 pm
    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: slee_at_dollar.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).
  • DENNIS WILLIAMS at Oct 11, 2002 at 7:30 pm
    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.
    dwilliams_at_lifetouch.com

    -----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"
    Sent by: root_at_fatcity.com
    10/09/2002 11:53 AM
    Please respond to ORACLE-L



    To: Multiple recipients of list ORACLE-L
    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


    tell me I'm worrying for nothing
    recommend a better way to stripe/distribute my files
    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).

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jared.Still_at_radisys.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: 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).
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: DENNIS WILLIAMS
    INET: DWILLIAMS_at_LIFETOUCH.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).
  • Markham, Richard at Oct 11, 2002 at 7:58 pm
    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-----
    Sent: Friday, October 11, 2002 2:46 PM
    To: Multiple recipients of list ORACLE-L

    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: slee_at_dollar.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: Markham, Richard
    INET: RMarkham_at_hafeleamericas.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).
  • Deshpande, Kirti at Oct 11, 2002 at 8:24 pm
    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: ORACLE-L_at_fatcity.com
    Cc: JayMiller_at_TDWaterhouse.com

    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"
    Sent by: root_at_fatcity.com
    10/09/2002 11:53 AM
    Please respond to ORACLE-L



    To: Multiple recipients of list ORACLE-L
    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


    tell me I'm worrying for nothing
    recommend a better way to stripe/distribute my files
    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).

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jared.Still_at_radisys.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: 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).
    --
    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).
    --
    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).
  • Miller, Jay at Oct 11, 2002 at 8:31 pm
    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.
    dwilliams_at_lifetouch.com

    -----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"
    Sent by: root_at_fatcity.com
    10/09/2002 11:53 AM
    Please respond to ORACLE-L



    To: Multiple recipients of list ORACLE-L
    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


    tell me I'm worrying for nothing
    recommend a better way to stripe/distribute my files
    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).

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jared.Still_at_radisys.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: 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).
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: DENNIS WILLIAMS
    INET: DWILLIAMS_at_LIFETOUCH.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: 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).
  • Cary Millsap at Oct 11, 2002 at 8:31 pm
    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: ORACLE-L_at_fatcity.com
    Cc: JayMiller_at_TDWaterhouse.com

    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"
    Sent by: root_at_fatcity.com
    10/09/2002 11:53 AM
    Please respond to ORACLE-L



    To: Multiple recipients of list ORACLE-L

    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


    tell me I'm worrying for nothing
    recommend a better way to stripe/distribute my files
    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).

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jared.Still_at_radisys.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: 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).
    --
    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).

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Cary Millsap
    INET: cary.millsap_at_hotsos.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).
  • Miller, Jay at Oct 11, 2002 at 8:48 pm
    Thanks, I'm reading the first one now.

    Jay

    -----Original Message-----
    Sent: Friday, October 11, 2002 3:19 PM
    To: ORACLE-L_at_fatcity.com
    Cc: JayMiller_at_TDWaterhouse.com

    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: ORACLE-L_at_fatcity.com
    Cc: JayMiller_at_TDWaterhouse.com

    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"
    Sent by: root_at_fatcity.com
    10/09/2002 11:53 AM
    Please respond to ORACLE-L



    To: Multiple recipients of list ORACLE-L
    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


    tell me I'm worrying for nothing
    recommend a better way to stripe/distribute my files
    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).

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jared.Still_at_radisys.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: 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).
    --
    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).
    --
    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).
  • Stephen Lee at Oct 11, 2002 at 8:54 pm
    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: slee_at_dollar.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).
  • Miller, Jay at Oct 11, 2002 at 9:58 pm
    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: ORACLE-L_at_fatcity.com
    Cc: JayMiller_at_TDWaterhouse.com

    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"
    Sent by: root_at_fatcity.com
    10/09/2002 11:53 AM
    Please respond to ORACLE-L



    To: Multiple recipients of list ORACLE-L

    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


    tell me I'm worrying for nothing
    recommend a better way to stripe/distribute my files
    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).

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jared.Still_at_radisys.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: 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).
    --
    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).

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Cary Millsap
    INET: cary.millsap_at_hotsos.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: 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).
  • Miller, Jay at Oct 11, 2002 at 9:58 pm
    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: slee_at_dollar.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: 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).
  • Stephen Lee at Oct 14, 2002 at 2:58 pm
    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: slee_at_dollar.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).
  • Johnson Poovathummoottil at Oct 14, 2002 at 3:08 pm
    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"
    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"

    Multiple recipients of list
    ORACLE-L
    @TDWaterhouse cc:

    .com> Subject:
    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"
    Sent by: root_at_fatcity.com
    10/09/2002 11:53 AM
    Please respond to ORACLE-L


    To: Multiple recipients of list ORACLE-L

    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
    === message truncated ===

    Do you Yahoo!?
    Faith Hill - Exclusive Performances, Videos & More
    http://faith.yahoo.com

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Johnson Poovathummoottil
    INET: joni_65_at_yahoo.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).

Related Discussions

People

Translate

site design / logo © 2022 Grokbase