Re: UNIX hardware sizing for multiple instances

I know that sizing has to start some where, but what really drives the sizing in my opinion is:
- > what will the instances be used for, how many users and what kind of transaction load is required

       (average and maximum), and what kind of response time is required (average and maximum).

       That will drive the number if disks (as there can be a good estimate of the number of I/Os per tx),

        number of users will drive the memory requirements and number of CPU is driven by the response time.

That is the technical minimum requirement as I see it, there may be a completely different side to it that drives money/economic decisions.

Performance should be a consideration in your sizing, else how do you know that you buy enough disks ? Or fast enough CPUs or enough CPUs ?

Anjo.

Paul Vallee wrote:

> Hi Peter,
>
> disk space... you'll want a healthy margin here, enough to take hot backups,
> keep a day's worth of archived redo, etc. The other thing when buying disk
> nowadays is remembering that disk storage capacity (in MB) has increased
> dramatically faster than disk IO capacity (in MB/minute). You'll have to
> ensure that however much you buy, it can handle not only your storage
> requirements but also your IO requirements. Some SAs have been known to only
> format the inside 25% of each platter because of IO needs outweighing
> storage capacity.
>
> physical memory... don't forget to calculate additional memory for your
> instance processes and background processes!
>
> number of processors... although oracle was designed to use multiple
> processors (or multiple threads on NT) acting simultaneously, oracle's
> current pricing model encourages you to use few (or one!) very fast
> processors instead. My understanding is that a single very fast processor
> can give excellent oracle performance. Interestingly, I understand that
> there is a significant performance advantage to using 8MB secondary caches
> instead of 4MB caches, as the bulk of the active oracle executable code is
> then op-code cached.
>
> Hope this helps,
> Paul
> ---
> www.pythian.com -- vallee_at_pythian.com -- 877-PYTHIAN
> Smarter than adding another team member, Pythian has new services for
> supplementing DBAs: get our help with monitoring, 24x7 on-call, daily
> verifications, storage management, performance and more.
>
> ----- Original Message -----
> To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> Sent: Monday, April 15, 2002 3:18 PM
>
> My group has requirement to run three, possibly
> four, instances of Oracle (8.1.7, most likely) on a UNIX server
> (AIX, if that matters). We are considering separate instances
> because the software comes from three different vendors.
> The fourth database will be ours and may be able to run on one of
> the other three instances.
>
> For determining the size of the server we are using the following
> guidelines:
>
> disk space = amount needed for the o/s (including virtual memory) +
> Oracle software +
> data files
>
> physical memory = amount needed for the o/s +
> total sizes of the SGA for all instances
>
> number of processors = at least two
>
> processor speed = somewhere in the middle range
>
> We are assuming that the processors do not have to be blindingly fast for
> a database server. We are also assuming that the number of processors
> is more important than their speed.
>
> So my questions are:
>
> 1. Are we on the right track with the physical memory calculation?
>
> 2. Should we figure in an additional amount of memory for each dedicated
> server process,
> assuming that we will not be using MTS?
>
> 3. What criteria should we use to determine number of processors?
>
> 4. Any other comments about our calculations and assumptions?
>
> Thanks,
>
> Peter Schauss
> Northrop Grumman Corporation
> 516-346-3148
> schaupe_at_mail.northgrum.com
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Schauss, Peter
> INET: SCHAUPE_at_mail.northgrum.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: 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: Paul Vallee
> INET: dbalist_at_pythian.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: 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  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: 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).