This discussion is archived
1 2 Previous Next 15 Replies Latest reply: Sep 13, 2013 6:14 AM by Dude! RSS

SHMALL Sizing with Oracle Automatic Memory Management (AMM)

user10437903 Newbie
Currently Being Moderated

I have listed my environment, some pertinent information from Oracle and some non-sourced findings.
My questions are at the bottom.  Some questions may not be relevent based on the answers provided.

 

ENVIRONMENT

 

Three Node RAC Cluster
Single Database
Oracle Linux 5 Update 2
Oracle Grid Infrastructure 11gR2 (11.2.0.2.0)
- Oracle Automatic Storage Management 11gR2 (11.2.0.2.0)
Oracle Database 11gR2 (11.2.0.2.0) Enterprise Edition with RAC option
RAM  Currently: 16 Gb  Soon to be Upgraded to: 32 Gb

 

DEFINITION

 

SHMALL is the total amount of shared memory, in pages, that the system can use at one time.

 

ORACLE SIZING RECOMMENDATIONS


Oracle Doc ID 301830
Set shmall equal to the sum of all the SGAs on the system, divided by the page size.
Oracle Doc ID 1441282.1
kernel.shmall = physical RAM size / pagesize For most systems, this will be the value 2097152.
See Note 301830.1 for more information.
Oracle® Database Installation Guide 11g Release 2 (11.2) for Linux E24321-07
shmall 2097152 /proc/sys/kernel/shmall

 

NON-SOURCED FINDINGS

 

  • The total size cannot exceed available Physical RAM.
  • The value set should be short of using all physical memory accommodating other memory needs (i.e. OS, shadow processes).
  • Leave around 1 Gb of RAM for Linux OS

QUESTIONS

1)     I understand that SGA is shared memory and PGA is private memory in dedicated server processes.

        I read Doc ID 301830.
        I am not confusing MEMORY_TARGET which I know encompasses SGA and PGA.
        I've had two different responses from Oracle to the following question which is why I am here asking the question.
        If we're using AMM, do we need to size shmall accounting for SGA and PGA?

           a) If no, then according Doc ID 301830 we should size shmall to sum of all SGAs, correct?

           b) If yes, then why is shared memory being allocated for private memory (PGA)?

2)    When using AMM, the sizes for SGA and PGA can grow/shrink based on workload.
           a) If my system is up and running what is the best way to size the shmall given the SGA and PGA are targets (meaning they can grow)?
           b) Is there some buffer (percentage) that we should leave when sizing?
3)    ASM instance has an SGA of around 256 Mb.  Does this need to be included?
4)    Does dbcsonole, emagent or other oracle tools use shared memory in shmall?
5)    Other than the OS and shadow processes, what "other memory needs" would need to be accommodated OUTSIDE shmall?

 

Thank you.

  • 1. Re: SHMALL Sizing with Oracle Automatic Memory Management (AMM)
    Dude! Guru
    Currently Being Moderated

    The following might answer your questions or doubts:

     

    Re: Get confused about how to calculate SHMMAX and SHMALL on Linux.

     

    SGA (System Global Area) and PGA (Program Global Area) are assigned and managed by Oracle depending on ASMM or AMM.

     

    Oracle database requires shared memory to share memory between different processes. This can either /dev/shm (POSIX), using standard 4 KB memory pages, or kernel hugepages, which uses 2 MB pages and is more efficient for databases with more than 4 GB of memory use.

  • 2. Re: SHMALL Sizing with Oracle Automatic Memory Management (AMM)
    user10437903 Newbie
    Currently Being Moderated

    Dude, thank you but your response did not directly answer any of my questions.  I would appreciate direct responses to each questions.

     

    Any help is appreciated.

  • 3. Re: SHMALL Sizing with Oracle Automatic Memory Management (AMM)
    Dude! Guru
    Currently Being Moderated

    SHMALL and SHMMAX are safeguard parameters that apply to System V shared memory (IPC) to prevent a process from occupying all available shared memory. SHMALL sets the total amount of shared memory pages that can be used system wide. SHMMAX sets the maximum shared memory a process can allocate. SHMALL should therefore be SHMMAX/PAGE_SIZE. Page size is usually 4k unless you use kernel Huge Pages (2 MB).

     

    Oracle AMM (memory_target) requires POSIX shared memory (/dev/shm). By default it is 50 % of physical RAM and only allocated as needed. /dev/shm uses standard 4k memory pages and can be swapped to disk. If you have an Oracle database with more than 4 GB of SGA, then performance can drop due to the amount of memory required to manage the memory pages and limited TLB cache.

     

    If you use Oracle Automatic Memory Management (AMM), System V kernel parameters do not apply. Oracle AMM manages SGA and PGA automatically. However, PGA is never allocated out of SGA. Since Oracle 9i, PGA/UGA memory is mapped to /dev zero. You can verify it with the pmap utility.

     

    With this in mind, answering your questions should not be difficult:

     

    1a) System V IPC parameters do not apply to Posix shared memory.

    1b) PGA is never allocated out of SGA.

     

    2a) Does not apply to AMM.

    2b) AMM uses /dev/shm, which is max. 50 % by default. The SGA under AMM needs to fit into /dev/shm.

     

    3) No, ASM requires AMM and does not use System V IPC parameters.

    4) Shared memory can be System V or Posix. SHMALL applies to System V only.

    5) Only a few processes use shared memory, Oracle is one of them.

  • 4. Re: SHMALL Sizing with Oracle Automatic Memory Management (AMM)
    user10437903 Newbie
    Currently Being Moderated

    SHMALL and SHMMAX are safeguard parameters that apply to System V shared memory (IPC) to prevent a process from occupying all available shared memory. SHMALL sets the total amount of shared memory pages that can be used system wide. SHMMAX sets the maximum shared memory a process can allocate. SHMALL should therefore be SHMMAX/PAGE_SIZE. Page size is usually 4k unless you use kernel Huge Pages (2 MB).

     

    Oracle AMM (memory_target) requires POSIX shared memory (/dev/shm). By default it is 50 % of physical RAM and only allocated as needed. /dev/shm uses standard 4k memory pages and can be swapped to disk. If you have an Oracle database with more than 4 GB of SGA, then performance can drop due to the amount of memory required to manage the memory pages and limited TLB cache.

     

    If you use Oracle Automatic Memory Management (AMM), System V kernel parameters do not apply. Oracle AMM manages SGA and PGA automatically. However, PGA is never allocated out of SGA. Since Oracle 9i, PGA/UGA memory is mapped to /dev zero. You can verify it with the pmap utility.

    SHMALL

    There may be more than one instance (multiple databases, ASM instance etc.) that needs to be considered so SHMMAX/PAGE_SIZE seems to be incomplete.

     

    Question:

    1)     I understand that SGA is shared memory and PGA is private memory in dedicated server processes.

            I read Doc ID 301830.
            I am not confusing MEMORY_TARGET which I know encompasses SGA and PGA.
            I've had two different responses from Oracle to the following question which is why I am here asking the question.
            If we're using AMM, do we need to size shmall accounting for SGA and PGA?

               a) If no, then according Doc ID 301830 we should size shmall to sum of all SGAs, correct?

               b) If yes, then why is shared memory being allocated for private memory (PGA)?

     

    Answer:

    1b) PGA is never allocated out of SGA.

    So If I understand this correctly, under AMM the SGA is allocated in Posix Shared Memory (/dev/shm) however, the PGA is not allocated in Posix Shared Memory.

     

    Question:

    2)    When using AMM, the sizes for SGA and PGA can grow/shrink based on workload.

               ...

               b) Is there some buffer (percentage) that we should leave when sizing?

    Answer:

    2b) AMM uses /dev/shm, which is max. 50 % by default. The SGA under AMM needs to fit into /dev/shm.

    Given that the SGA can grow/shrink based on workload, what is the best method to size /dev/shm?

     

    Question:

    3)    ASM instance has an SGA of around 256 Mb.  Does this need to be included?

    Answer:

    3) No, ASM requires AMM and does not use System V IPC parameters.

    AMM is recommended and configured by default for ASM but not required for Oracle Database - Enterprise Edition - Version 11.2.0.1 to 11.2.0.3.  Hugepages Not used when ASM is used Doc Id 1457842.1 indicates that RDBMS not using huge pages was because the ASM home was still using AMM.  This is the default for ASM instance.  The solution was to make sure the ASM home not using AMM so it appears to not be required.

    If AMM is used then ASM Instance should be accounted for in Posix Shared Memory, otherwise, it will need to accounted for in System V shared memory.

     

    Question:

    4) Does dbcsonole, emagent or other oracle tools use shared memory in shmall?

    Answer:

    4) Shared memory can be System V or Posix. SHMALL applies to System V only.

    The information regarding Shared Memory is clear; however, it is not clear what other applications/tools use Shared Memory.

     

    Question:

    5)    Other than the OS and shadow processes, what "other memory needs" would need to be accommodated OUTSIDE shmall?

    Answer:

    5) Only a few processes use shared memory, Oracle is one of them.

    Other than the OS and shadow processes, what "other memory needs" would need to be accommodated OUTSIDE /dev/shm?  I've read that PL/SQL collections can exceed target configuration.  Is this true?  Other things to consider?

     

    Thanks.

  • 5. Re: SHMALL Sizing with Oracle Automatic Memory Management (AMM)
    Dude! Guru
    Currently Being Moderated

    ASM requires AMM and will not run under ASMM.

     

    It is possible to run one database instance using AMM and another using ASMM on the same machine.

     

    The best way to increase /dev/shm is to add more RAM. By default, /dev/shm is max. 50 % of RAM, allocated on demand and can be swapped. The minimum size of /dev/shm needs to be as large as your database SGA. If you have several database, they will share the memory and overall usage will be less than the sum of all SGA's.

     

    I'm not aware of a list that outlines which Linux processes require Posix or other shared memory, but you can use ipcs and ls /dev/shm commands to analyze it's use. Sorry, I have no idea what you mean by Linux shadow processes or PL/SQL collections that exceed some target configuration.

     

    I recommend to use kernel hugepages under Linux for any large oracle SGA in order achive best performance. Exact sizing and limiting of memory use is often not necessary and does not account for the unforeseeable. RAM and disk space are not that expensive and precious anymore. The SHMMAX and SHMALL kernel parameters are only safeguard paramters and do not cause any process to preallocate memory. When using Oracle they are typcially set to the maximum theoretical hardware limit, at least for SHMMAX.

  • 6. Re: SHMALL Sizing with Oracle Automatic Memory Management (AMM)
    user10437903 Newbie
    Currently Being Moderated

    AMM required for ASM?

     

    Oracle Automatic Storage Management - Under-the-Hood & Practical Deployment Guide

    by Nitin Vengurlekar, Murali Vallath and Rich Long

    Pg 47 "Best Practice for ASM init.ora Parameters ... Although it is not recommended, if you want to set the individual memory parameters, disable MEMORY_TARGET by setting it to 0..."

     

    Shell Script to Calculate Values Recommended Linux HugePages/HugeTLB Configuration (Doc ID 401749.1)

    "SCRIPT ... Before proceeding with the execution please not following:  For ASM instance, it needs to configure ASMM instead of AMM."

     

    Hugepages Not Used when ASM is used (Doc ID 1457842.1)

    "Cause ... The RDBMS not using huge pages was because the ASM home was still using AMM.  This is the default for an ASM isntance Please refer to Note 749851.1 - HugePages and Oracle Datbase 11g Automatic Memory Management (AMM) on Linux ... Solution ... Make sure the ASM home not using AMM."

     

    Oracle Automatic Storage Management Administrator's Guide 11g Release 2 (11.2) E18951-03

    "Oracle strongly recommends that you use automatic memory management for Oracle ASM. ... Although it is not recommended, you can disable automatic memory management by either setting the value for MEMORY_TARGET=0 in the Oracle ASM parameter file or by running an ALTER SYSTEM SET MEMORY_TARGET=0 statement."

     

    The information I have researched indicates that AMM is strongly recommended by Oracle but not required (see above).  If you are using HugePages then it seems that AMM can't be used for ASM (11.2.0.1 to 11.2.0.3).  if you have any more recent or indepth source for AMM being required for ASM then please list source.

     

    Thank you for your help.  I am thinking of using HugePages based on your suggestion and some other information on the Web.  I am wondering whether moving from 16 Gb to 32 Gb would pose a problem for AMM.

  • 7. Re: SHMALL Sizing with Oracle Automatic Memory Management (AMM)
    Dude! Guru
    Currently Being Moderated

    I previously tried to configure an ASM instance using ASMM after reading that AMM and kernel hugepages are incompatible, however, as it turns out, this only applies to the database instance and not the server. You can certainly configure the OS to provide AMM and kernel hugepages, and install one instance using AMM and another on using ASMM on the same server.

     

    https://forums.oracle.com/thread/2409579

     

    I just tried to configure an ASM instance using ASMM again, and it seems to work. Not sure what previously caused the ORA-600 AND ORA-01078 failures. I have attached the protocol below.

     

    But why do you want to configure a ASM instance using ASMM? What's the idea or benefit behind it.

     

    You should configuring a database with 16 GB of SGA using kernel hugepages. It's is not that AMM has a problem with it, but your system will have to manage a lot of memory pages as previously outlined. It will drop performance and waste memory just for managing memory pages.

     

    You can do a simple math with 16 GB, resulting in 4000000 memory pages under AMM and 8192 pages under kernel hugepages.

    The following slideshow may help to understand how it works: http://www.slideshare.net/raghusiddarth/transparent-hugepages-in-rhel-6

     

     

    The following is an example how to configure ASM using ASMM.

     

    [root@ol1 ~]# su - oracle

    [oracle@ol1 ~]$ . oraenv

    ORACLE_SID = [oracle] ? +ASM

    The Oracle base has been set to /u01/app/oracle

     

     

    [oracle@ol1 ~]$ cd $ORACLE_HOME/dbs

    [oracle@ol1 ~]$ sqlplus / as sysasm

     

    SQL*Plus: Release 11.2.0.2.0 Production on Thu Aug 29 20:55:13 2013

     

    Copyright (c) 1982, 2010, Oracle.  All rights reserved.

     

     

    Connected to:

    Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production

    With the Automatic Storage Management option

     

    SQL> sho parameter memory

     

    NAME                     TYPE     VALUE

    ------------------------------------ ----------- -----

    memory_max_target             big integer 272M

    memory_target                 big integer 272M

     

    SQL> select name, value from v$pgastat;

     

    NAME                                      VALUE

    ---------------------------------------------------------------- ----------

    aggregate PGA target parameter                       96468992

    aggregate PGA auto target                          0

    global memory bound                              0

    total PGA inuse                            16798720

    total PGA allocated                           20529152

    maximum PGA allocated                           20529152

     

    SQL> create pfile from spfile;

     

    [oracle@ol1 dbs]$ vi init+ASM.ora

     

    memory_target=0

    sga_target=256M

    pga_aggregate_target=96M

    memory_target=0

     

    [oracle@ol1 dbs]$ sqlplus / as sysasm

     

    SQL> shutdown immediate;

    ASM diskgroups dismounted

    ASM instance shutdown

    SQL> connect / as sysasm

    Connected to an idle instance.

    SQL> startup pfile=/u01/app/oracle/product/112/grid/dbs/init+ASM.ora

     

    Total System Global Area  283930624 bytes

    Fixed Size            2225792 bytes

    Variable Size          256539008 bytes

    ASM Cache           25165824 bytes

    ASM diskgroups mounted

  • 8. Re: SHMALL Sizing with Oracle Automatic Memory Management (AMM)
    user10437903 Newbie
    Currently Being Moderated

    Hugepages Not used when ASM is used (Doc ID 1457842.1).

    Modified: Aug 14, 2013

    Applies to:

    Oracle Database - Enterprise Edition - Version 11.2.0.1 to 11.2.0.3

    Symptoms

    Followed Note 361468.1 - HugePages on Oracle LInux 64-bit but Oracle is still not using hugepages.

    Cause

    The RDBMS not using huge pages was because the ASM home was still using AMM.  This is the default for an ASM instance.  Please refer to Note: 749851.1 - HugePages and Oracle Database 11g Automatic Memory Management (AMM) on Linux.

    Solution

    Make sure the ASM home not using AMM.

     

    Why configure ASM with ASMM?  I am apparently missing something here.  My translation of the doc id above is that the ASM instance (ASM Home) CANNOT use AMM if you want the RDBMS instance to use HugePages.  So if you have an RDBMS instance using AMM then it must NOT be using ASM and will not be using hugepages.  If I have it wrong then please explain Doc ID 1457842.1.

  • 9. Re: SHMALL Sizing with Oracle Automatic Memory Management (AMM)
    Dude! Guru
    Currently Being Moderated

    AMM and kernel hugepages are mutually exclusive. It means you cannot use AMM with kernel hugepages. AMM uses posix shared memory, which is allocate on demand, swappable and relies on standard 4 KB kernel memory pages. Hugepages on the other hand is pre-allocated and reserved at system startup, cannot be swapped and uses 2 MB memory pages.

     

    ASM uses it's own database instance (+ASM). You can configure ASM using AMM (default), and install another database instance (ORCL) on the same machine using kernel hugepages and ASMM. The database connecting to the ASM instance to access the ASM diskgroups does not have to use the same memory management.

  • 10. Re: SHMALL Sizing with Oracle Automatic Memory Management (AMM)
    user10437903 Newbie
    Currently Being Moderated

    Please explain Doc ID 1457842.1 (see earlier reference)

    The ORACLE  Doc ID 1457842.1 says that the RDBMS will not use HugePages if the ASM instance (ASM home) is using AMM.  Meaning that if you want your RDBMS (using ASM for storage) to use hugepages then the ASM must be either ASMM or manually managed memory parameters.

    I very much appreciate your responses and I will very shortly be upgrading the memory on a set of 3 node RAC servers (test/prod) and installing a new single instance database server.  They all use ASM, 32 Gb of Physical RAM and will most likely be using hugepages.  Please explain Doc ID 1457842.1 as it is crucial to my configuration.

     

    Thanks.

  • 11. Re: SHMALL Sizing with Oracle Automatic Memory Management (AMM)
    Dude! Guru
    Currently Being Moderated

    I cannot explain it because it does not make sense to me. You have to ask Oracle support. It might be a typing error and RDBMS should read ASM instance. Generally, and this seems to be according to the symptoms explained, in order for any Oracle Instance under Linux to use ASMM with kernel hugepages, the parameter memory_target of the database instance must be unset, i.e. not just set to 0, but not defined at all. Unlike for ASM, where memory_target must be set to 0 in order for the ASM instance to use ASMM.

  • 12. Re: SHMALL Sizing with Oracle Automatic Memory Management (AMM)
    user10437903 Newbie
    Currently Being Moderated

    If you use HugePages for RDBMS then I don't believe you can use AMM with ASM.  I recieve the following information from a very reliable source from Oracle (SEE BELOW).

     

    DISCUSSION

     

    1) ASM works with AMM or without AMM, without AMM you can manually set the SGA parameters like shared_pool_size or large_pool (this is supported and valid).

     

    2) Keep in mind that AMM is the best option for ASM, but if you have plans to use Huge Pages, then AMM can be disabled and ASM SGA parameters can be manually set (without AMM).

     

    I hope this is clear

     

    Regards,

    < third party person's name removed by moderator because you failed to show their permission for you to reveal it >

     

    SUBSEQUENT DISCUSSION

     

    ...

    QUESTION

    =========

     

    1) What would you say is the preferred (best practice) for an RDBMS using ASMM (or manual parameters), HugePages and ASM?

     

      ASM using ASMM (or manual parameters) and HugePages.

      ASM using ASMM (or manual parameters)  and no HugePages.

      ASM using AMM.

     

    2) Does RAC change this equation at all?

     

    3) Can you explain this "Hugepages Not used when ASM is used (Doc ID 1457842.1)"?  It seems to say that the user wanted to use hugepages with RDBMS but the ASM was configured using AMM.  Therefore, the ASM using AMM caused the RDBMS to not use hugepages as desired.

     

        "The RDBMS not using huge pages was because the ASM home was still using AMM. This is the default for an ASM instance. Please refer to Note: 749851.1 - HugePages and Oracle Database 11g Automatic Memory Management (AMM) on Linux."

     

    ...

    ANSWER

    ========

     

    1) You have 2 valid options:

     

    1.1) ASM & RDBMS using AMM but without HugePages.

     

    Or

     

    1.2) Manual SGA parameters for both ASM & RDBMS instances (without AMM) + using HugePages.

     

    2) No, the same rule is applicable for both Standalone and RAC configurations.

     

    3) The simple answer for that is that AMM is not compatible with Huge Pages and vice versa, thus the combinations 1.1 & 1.2 above are valid.

     

    ...

     

    < third party person's name removed by moderator because you failed to show their permission for you to reveal it >

  • 13. Re: SHMALL Sizing with Oracle Automatic Memory Management (AMM)
    Dude! Guru
    Currently Being Moderated

    If you use HugePages for RDBMS then I don't believe you can use AMM with ASM.  I recieve the following information from a very reliable source from Oracle (SEE BELOW).

     

    Sorry, I'm afraid your interpretation of the information is incorrect. Did you read the complete thread?

     

    Why should a database instance not be able to use Kernel Hugepages if the ASM instance uses AMM? The RDBMS and ASM instance are separate instances and each can use their own memory management.

     

    And why shouldn't it? You can configure Enterprise Linux to provide Posix (/dev/shm) and Kernel HugePages.

     

    Kernel Hugepages is incompatible with AMM, meaning you cannot use AMM with Kernel Hugepages. You can however run two database instances on one and the same server and use different memory management.

     

    Below is an example, showing ASM (+ASM) configured for AMM (/dev/shm), which is used by a database (orclasm) configured to use Hugepages.

     

     

    $ grep -i huge /proc/meminfo

    HugePages_Total:    1029

    HugePages_Free:     1029

    HugePages_Rsvd:        0

    HugePages_Surp:        0

    Hugepagesize:       2048 kB

     

    $ df -Ph

    Filesystem            Size  Used Avail Use% Mounted on

    /dev/mapper/VolGroup00-LogVol00   31G   20G  9.8G  67% /

    /dev/sda1              99M   43M   52M  46% /boot

    tmpfs                 2.0G     0  2.0G   0% /dev/shm

     

    $ ORAENV_ASK=NO

    $ ORACLE_SID=+ASM

    $ . oraenv

    The Oracle base remains unchanged with value /u01/app/oracle

     

    $ sqlplus / as sysasm

    SQL*Plus: Release 11.2.0.2.0 Production on Wed Sep 11 22:03:59 2013

    SQL> startup

    ASM instance started

    Total System Global Area  283930624 bytes

    Fixed Size            2225792 bytes

    Variable Size          256539008 bytes

    ASM Cache           25165824 bytes

    ASM diskgroups mounted

     

    $ df -Ph

    Filesystem            Size  Used Avail Use% Mounted on

    /dev/mapper/VolGroup00-LogVol00   31G   20G  9.8G  67% /

    /dev/sda1              99M   43M   52M  46% /boot

    tmpfs                 2.0G  176M  1.8G   9% /dev/shm

     

    $ ls -l /dev/shm

    total 179352

    -rw-r----- 1 oracle oinstall 4194304 Sep 11 22:04 ora_+ASM_2392069_0

     

    $ ORACLE_SID=orclasm

    $ . oraenv

    The Oracle base remains unchanged with value /u01/app/oracle

     

    $ sqlplus / as sysdba

    SQL> startup

    ORACLE instance started.

    Total System Global Area  546992128 bytes

    Fixed Size            2228320 bytes

    Variable Size          335548320 bytes

    Database Buffers      201326592 bytes

    Redo Buffers            7888896 bytes

    Database mounted.

    Database opened.

     

    SQL> sho parameter use_large_pages

    use_large_pages              string     only

     

    SQL>SQL> SELECT NAME FROM V$DATAFILE;

    +DATA/orcl/datafile/system.256.741751677

    +DATA/orcl/datafile/sysaux.257.741751677

    +DATA/orcl/datafile/undotbs1.258.741751679

    +DATA/orcl/datafile/users.259.741751679

    +DATA/orcl/datafile/example.269.741751827

     

    $ grep -i huge /proc/meminfo

    HugePages_Total:    1029

    HugePages_Free:      850

    HugePages_Rsvd:       84

    HugePages_Surp:        0

    Hugepagesize:       2048 kB

  • 14. Re: SHMALL Sizing with Oracle Automatic Memory Management (AMM)
    user12273962 Pro
    Currently Being Moderated

    Interesting conversation. However, I don't know hardly anyone that recommends using AMM for much of anything. Maybe its okay for databases that serve huge swings in workloads on database servers that maybe performing more than just servicing a database. Even then, you must meet peak needs. Thus, to me, AMM is a convenient option for only small workloads.

     

    I don't know exactly what you're trying to accomplish with all your questions. In my honest opinion, you're better off having 2 node RAC and increasing each individual nodes resources.... than having resources split over 3 nodes. The only exception to this, would be if you serving huge amounts of data over extended periods of time. Even then, in a RAC environment, you HAVE to take into consideration tuning your requests to take advantage of the scale of the cluster. Running sequenced batches across each node will not get you anywhere. In small OLTP operations, you're never gone to get more than what one single RAC node will give you. Thus, my recommendation. This may change to some degree was interconnect bandwidth increases. The bandwidth available with technologies such as infiniband will make a difference.

1 2 Previous Next