AMM (sga_target) vs Linux HugePages

I was told by the engineer of Redhat Linux Linux HugePages cannot be used with AMM (sga_target) on Oracle 10 g or 11g?

I prefer to use the AMM.

What is the best - with AMM (sga_target) or Linux HugePages?

You can find the following interest: question of SGA Linux/cache

"HugePages are a significant server use (memory and processing) resources, while the AMM adds even more software to give the appearance of this feature."

The General recommendation in accordance with the Oracle AMM documentation, which is easier to manage.

Tags: Database

Similar Questions

  • Disable the AMM for Linux Hugepages

    Hi guys,.

    In order to use Linux hugepages, I try to disable the AMM by setting the MEMORY_MAX_TARGET to 0 and the MEMORY_TARGET. I have successfully MEMORY_TARGET to zero, but cannot be the MEMORY_MAX_TARGET with:

    ALTER system set MEMORY_MAX_TARGET is 0 scope = spfile;.

    immediate stop

    startup

    view the memory_max_target parameter is greater than zero (never reset).

    When I try to calculate the core of vm.nr_hugepages using MOSC setting Document 401749.1 (hugepages_settings.sh), I get:

    ***********
    * ERROR *.
    ***********
    Sorry! There is not enough total allocated for shared memory segments
    Setting up HugePages. HugePages cannot be used for shared memory segments
    You can browse by command:

    # ipcs m

    a size that can match an LMS of Oracle database. Please make sure that:
    * Instance of oracle database is running
    * Oracle Database 11 g (AMM), automatic management of memory is not configured

    Oracle version:

    Oracle Database 11 g Release 11.2.0.1.0 - 64 bit Production

    PL/SQL Release 11.2.0.1.0 - Production

    CORE 11.2.0.1.0 Production

    AMT for Linux: Version 11.2.0.1.0 - Production

    NLSRTL Version 11.2.0.1.0 - Production

    Any ideas would be appreciated.

    Rather than setting these parameters to zero, I would remove them from the spfile:

    change the system reset memory_max_target;

    change the system reset memory_target;

    --

    John Watson

    Oracle Certified Master s/n

    http://skillbuilders.com

  • LOCK_SGA on 11.2 and Linux

    Hello everyone

    is it possible to use LOCK_SGA = true on Oracle Linux 6.2 and UEK (64 bit)?
    I guess LOCK_SGA = true is required if I use Hugepages on Linux 6 and turn-off AMM and use EAMA

    I'm trying to spend and do not...

    using Oracle 11.2.0.3 and Oracle Linux 6.2 with UEK R2 64-bit

    LOCK_SGA = true requires that MEMORY_MAX_TARGET = 0 and MEMORY_TARGET = 0, but even when I specify everything in a file PFILE, his zero and instance does not start.
    I tried SGA_TARGET and SGA_MAX_SIZE and PGA_AGGREGATE_TARGET > 0 and no joy.

    I have to do something wrong - wanted Oracle 11.2 guides - specific relative to the LOCK_SGA nothing.

    This requires perhaps SPFILE and custom work on PFILE not at all?


    Sorry, I don't have MOS, there may be a white paper on "how to enable LOCK_SGA on 11.2 on Linux Hugepages?

    Thank you

    You cannot use memory_target or memory_max_target with HugePages. I suggest to delete these settings completely.

    LOCK_SGA prevents the permutation of the SGA, which is not applicable when using the kernel hugepages as hugepages (shared memory) cannot be exchanged. (Not to be confused with transparent OL6 hugepages with applies to private/anonymous memory only)

  • Help with ORA-00845

    Hello, I'm under GR 11, 2 on Fedora 15 64 bits.
    DB has worked for 1 week, but today, I'm getting ORA-00845 during an attempt to start.
    Acccording to the Documentation, I checked my init.ora and/dev/shm sizes:

    init.ora:
    memory_target = 1 G

    DF k/dev/shm:
    2022956K

    What else can cause this error?

    Thank you in advance.

    Salvation;

    Please see:
    HugePages and Oracle Database 11 g automatic management (AMM) memory on Linux [749851.1 ID]

    ORA-00845 when starting an Instance of 11 g with AMM configured. [460506.1 ID]

    Respect of
    HELIOS

  • size of SGA on hugemem kernel

    Hello

    I am running oracle 10.2.0.4 on RHELAS U4.6 and the kernel is Linux 2.6.9 - 67.ELhugemem #1 SMP i686 i686 i386 GNU/Linux.

    Course of the system's RAM is 32 GB and the current size of the sga is 3G.

    My question here is that it is possible that I can increase the size of the sga up to 8 GB?


    Thank you for your cooperation.

    Kind regards

    Adnan Hamdus Salam.

    Salvation;

    Please see:
    How to configure RHEL/OEL 4 32 bits for very large memory with ramfs and HugePages [317141.1 ID]< step="">
    Linux HugePages: what it is... and what is not... [361323.1 ID]

    Respect of
    HELIOS

  • HugePages - Instance ASM

    Hi all, I have a doubt on the HugePage, we have allowed huge Pages on our Linux Red Hat 5 of 64-bit server. My doubt is because the documentation says I can't use memory_target my databases are therefore with pga_aggregate_target and sga_target but my what ASM instance is with memory_target and it works normally. I have IG + DB version 11.2.0.2.
    So I want to ask if I can have the ASM instance in memory_target with a huge Pages configured under Linux without problems?

    Concerning

    Huge pages and MSA are mutually exclusive, but this does not mean that you cannot run a database using the MSA and the other using huge pages or standard memory shared on the same computer. If you set pga_aggregate_target and sga_target parameters in an Instance that is configured for the AMM, these values set the minimum values. The ASM instance requires AMM.

  • In what kind of environment we prefer use AMM (Memory_target) on manual management of the memory?

    Hi all

    I am not able to classify what type of environment we prefer to use the AMM (memory_target) parameter to manual memory management. I've seen even on oracle 11g several customers use no memory_target parameter.

    Please rank the situation in order to differentiate these.

    Thank you

    -RAJ

    AMM does not work with HugePages.

    Large and complex environments on Linux would be to use HugePages.  In addition, the DBA would prefer better controls the size of the SGA and PGA in such environments.

    AMM can be used for small, medium environments with predictable usage patterns, less complex.

    Hemant K Collette

  • Oracle DB 11 g 2 controls prerequisites failed - Oracle Linux 6.5

    Hi all

    Once again stuck with questions during the installation of 11 GR 2 DB.

    1. Swap size - failed
      Details:
      Size of swap - it is a prerequisite to check if sufficient total swap space is available on the system.
      Expected value: 7.74 GB (8120228,0 KB)
      Real value: 7.7 GB (8077308,0 KB)

      My checks:
      # SH - 4.1 swapon s
      Size of the characters in filename used priority
      / dev/DM-1 partition 8077308 0-1
      SH - 4.1 # cat/proc/swaps
      Size of the characters in filename used priority
      / dev/DM-1 partition 8077308 0-1
      SH - 4.1 # cat/etc/fstab. grep swap
      / dev/map/vg_vssdbserver-lv_swap swap swap defaults 0 0

      I thought that 8 GB of swap space was enough, my system has 8gbRAM.

    As a general rule, swap space is usually configured to twice the RAM if you use 8 GB or less and equal to the amount of RAM if you have 16 GB or more. If you have 64 GB of RAM, however, it is useless to have 64 GB of swap space, because the loss of performance so you never need to swap space will be very bad.

    However, you probably want to configure your Oracle database to use the kernel Hugepages using EAMA instead of the AMM for optimal performance and efficient use of memory. Hugepages kernel, unlike the POSIX memory shared (/ dev/shm) used by the AMM will be pre-allocate memory to start the system upward and can not use swap space. Don't forget that the swap space is not a substitute for the lack of physical memory (RAM).

    On the Oracle database installation, there should be a button to ignore warnings or errors and continue the installation or if you feel more comfortable with it, to meet this control, simply create a temporary swap file to increase your swap space, which later can be removed when you no longer need. It is certainly much easier than to the resize your swap partition.

    For example:

    [root@vm213 ~] # lsb_release d

    Description: Oracle Linux Server version 6.5

    [root@vm213 ~] # swapon s

    Size of the characters in filename used priority

    / dev/DM-1 partition 2097148 0-1

    Create a pagefile of 1 GB in / Home

    [root@vm213 ~] # dd if = \u003d/dev/zero of / home/swapfile bs = 1024 count = 1048576

    1048576 + 0 records in

    1048576 + 0 records out

    1073741824 bytes (1.1 GB) copied, 4.32366 s, 248 MB/s

    [root@vm213 ~] # chmod 600/home/swapfile

    [root@vm213 ~] # ls-l/home/swapfile

    -rw-------. 1 root root 1073741824 28 May 03:07 / home/swapfile

    [root@vm213 ~] # home/mkswap/swapfile

    mkswap: / home/swapfile: caution: do not erase the sectors bootbits

    all over the disk. Use f to force.

    Implementation of version 1 of swapspace, size = 1048572 KiB

    no label, UUID = d26f4d5f-af46-4567-b836-0d5d0b1661cb

    [root@vm213 ~] # home/swapon/swapfile

    [root@vm213 ~] # swapon - a

    [root@vm213 ~] # swapon s

    Size of the characters in filename used priority

    / dev/DM-1 partition 2097148 0-1

    / home/file swapfile 1048572 0-2

    If you want to enable the pagefile at system startup:

    [root@vm213 ~] # cp/etc/fstab /etc/fstab.backup_'date + %N '

    [root@vm213 ~] # echo "/ home/swap file, swap swap defaults 0 0' > / etc/fstab"

  • Oracle 11g AMM (automatic memory management)

    Hi all

    I have a very powerful server 24 processors 6 hearts of each and 74 GB of RAM for my production database. The server will host what a single database of production. I wanted to use the AMM for this database and maximum memory allocation to Oracle by defining memory_target. By default, / dev/SHM has 37 GB but I wanted to increase it less 55GO. I know I can get it changed by my system administrator, but I wanted to know how much memory should leave BONES?

    Please help me on this design.

    Thank you

    Arun Singh

    The POSIX or/dev/SHM shared memory is 50% of physical RAM by default. If you want to change the default, you need to specify your OS version, because it depends on.

    However, thanks to WMA or/dev/shm in a system with more than 16 GB of RAM you are going to lose a lot of performance and memory, which, according to Oracle Linux engineering is the reason number 1 for poor Oracle database performance. Memory POSIX shared in your configuration will result in the loss of performance due to TLB misses and waste memory only to manage the memory of 4 KB pages.

    I recommended that configure the system using the kernel hugepages, which use memory 2 MB pages, remove memory_target and memory_max_target of your instance settings file and configure the database to use EAMA.

  • Linux kernel parameters and Oracle memory allocations.

    I'm currently creating an Oracle 11 G R2 in database, on a Linux (SLES 11) OS. The software OS and DB are the two 64-bit.
    I wondered about the optimal method of memory allocation shared, such that I can get the automatic memory management to recognize 12G of memory (which allows 4 g for the operating system and other pieces).

    I put the kernel parameters are:
    SHMMAX: 8589934592 (the recommended physical memory/2).
    SHMALL: 3145728 (giving a total of 12 GB of shared memory allocation that the page size is 4096).

    The way I read the documentation, it must free up enough shared memory to allow the specification of a memory_max_target and memory_target "11 g". I'm getting 11G to ensure that I am not ruin by a few bytes (if it all works, I will develop to 12G).
    However, whenever I try a startup, I get the ' ORA-00845: not supported on this system MEMORY_TARGET' error.
    It disappears if I create a great shmfs block using a mount command, but I was under the impression you had is no longer to do with 64-bit and Oracle 11 G system.

    Could someone clarify a little bit about what I'm doing wrong and where I should be looking for the answer?

    See you soon,.

    Rich

    Note 749851.1 ID and ID 460506.1:

    AMM all SGA memory is attributed by creating the files under/dev/SHM. When Oracle DB not allowances of SGA that HugePages reserved/does not serve. The use of the AMM is absolutely incompatible with HugePages.

    eseentially, AMM requires that/dev/SHM.

  • Implementation of VLM and HugePages on production

    Hello, experts.

    This method that I'll give you has been tested on the following test system:
    32-bit Linux Redhat 5.3 - Kernel 2.6PAE
    6 GB OF RAM
    Oracle: 10.2.0.2

    And is about to be implemented in production:
    32-bit Linux Redhat 5.3 - Kernel 2.6PAE
    8 GB RAM
    Oracle: 10.2.0.2

    I would be happy if review you my work sequence and stop me if something seems to be far away. Even if we can work on the test system, you experts can see something that would inflict problem in a busy production database. I'll post a few (but not the part of HugePages) puts in scene and two I have questions.

    I highly appreciate your input.

    We will try of a LMS in 6 GB with a 4 GB Database Buffer Cache and a Variable to 2 GB size.


    # /etc/rc.local
    umount /dev/shm
    mount –t ramfs ramfs /dev/shm
    chown oracle:oinstall /dev/shm
    # /etc/security/limits.conf
    oracle           soft    memlock         2297152
    oracle           hard    memlock         2297152
    Question: To my knowledge, memlock must be to the same value as my desired shared_pool, since I want a 2 GB I've set the memlock shared_pool according to this calc: (2 * 1024 * 1024 = 2097152). But the recommendations say it takes more size it a little, as you can see in my code above. Sounds good and my understanding of this is correct, should I put it even higher?

    # Change Oracle
    use_indirect_data_buffers=true
    sga_target=0
    db_2k_cache_size=0
    db_4k_cache_size=0
    db_8k_cache_size=0
    db_16k_cache_size=0
    db_32k_cache_size=0
    sga_max_size=6GB
    db_block_buffers=524288
    To my knowledge, db_block_buffers is what will decide the size of the Cache buffers data base now, and for the value above, ive used this calc: ((4 * 1024 * 1024) / 8) = 524288

    Question: If I try to start the Oracle Instance with the above configuration, it will fail, saying that I need to put the shared_pool, but it does not matter how mutch I put to size Variable gets 2GB. It's a safe assumption to say that the size Variable will get left memory (if we don't count fixed size and redo buffers), if you take (sga_max_size - database buffer cache)?


    Live long and prosper, Johan

    Developers want more SGA on Oracle data.

    But WHY they want more? Is there a problem? If Yes, you can change this part...

    And when Ive looked on the internet it seems to me that people generally have Variable size on half of what is the database buffer.

    It's all nonsense. The variable part of BMG consists mainly of shared, large pool of java and. How to set these values depends entirely on your configuration. Most of the bases will work perfectly with much lower values - some require larger values. For example, really huge database of 30 GB or more database buffers do not have a variable part of 15 GB...

    So, if the "old" system works with much lower values it would be a good starting point for shared, large and pool of java. From here, you should monitor memory areas and increase if necessary to.

    --
    Ronny Egner
    My blog: http://ronnyegner.wordpress.com

  • Monitoring hugepages

    Is it possible to monitor the hugepages on a Linux server? I found the KB 66451 article that mentions an enhancement request for this to the cartridge of the BONE (OS-1055), I guess that it was not in the cartridge of the Infrastructure.

    If it is not part of the output of the box cartridges is it possible to create a custom agent and associate the metrics to the host?

    Thank you

    Kris

    I checked with the support, it does not make the cartridge of the infrastructure.

    An agent script is probably the way forward, with Foglight any script that writes to standard output may be packaged as a script and data can be send to http://en.community.dell.com/techcenter/performance-monitoring/foglight-administrators/w/admins-wiki/5787.custom-agents-introduction-to-script-agents Foglight

    Hope this helps

    Golan

  • test DB has no AMM, the request takes 5 seconds, the prod DB has AMM query takes 5 minutes

    I created a copy of test of production for a long time, when I was creating the test I have not activated AMM.

    A developer created a new report and told me that it took seconds to run on the Pb test, as he was taking up to 10 minutes on the Pb of the production. I got it to extract the SQL code for the report and he ran from a command line, and on the Pb test, it took 5 seconds and more than 5 minutes on the Pb of the production.

    I then checked the AMM with the show memory_target parameter to see if AMM was activated and on the Pb of the prod is 1 GB on the DB test is 0

    memory allocation requests show this for prod:

    NAME                                     VALUE

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

    PGA maximum allowed 578929664

    pga_aggregate_target 0

    SGA_TARGET 0

    MEMORY_TARGET

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

    578929664

    for the BP to test:

    NAME                                       VALUE

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

    PGA maximum allowed 214604800

    pga_aggregate_target 101711872

    SGA_TARGET 624951296

    MEMORY_TARGET

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

    839556096

    I have not dbcontrol currently enabled on the Pb test, so I could not watch the advisors of the memory, but it is enabled on the Pb of the prod, that tells me it should be to the 1 GB is currently at.

    Two of these db are on the same server.

    Now I wonder if I should disable the AMM on the prod server and allocate manually to match the test, or should I change the AMM if possible so that it can perform as good as the Pb of test?

    Thanks in advance.

    I tried the suggestion of Geert earlier but I forgot to mention that it made no difference.

    However, I managed to find out what it is, starting at the beginning by looking at all the init parameters. It was then that I noticed the Prod OPTIMIZER_FEATURES_ENABLE was set to 9.2.0.8, while the test was 11.2.0.3, a quick alter system set optimizer_features_enable = '11.2.0.3' scope = both and the query ran<5 seconds,="" just="" like="" the="" test.="" it="" also="" got="" rid="" of="" the="" note="" that="" the="" cpu="" costing="" was="" not="">

    I thought a bit more wording accurate in the order note explain plan could be useful - but in any case, it makes sense, I guess...

    However, this has been a useful exercise for me, I have a better idea how they use the remote database for retrieving information and will make suggestions, it may be easier to create views of the side remote (SQL Server), rather than on the side of the Oracle.

    Still do not know how the test done with the right parameter and the prod has not, I used to create the init.ora file to create the test instance by getting a carbon copy of the production spfile, but I missed this setting this time.

    In any case, it's a good thing I had the right parameter under test - otherwise the Developer & users may have accepted, he was going to be a slow and left...

    Thanks again for all your help

    PS. Now here is the plan explain of production:

    SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST'));
    SQL_ID  bqh1aq71rshpp, child number 1
    -------------------------------------
    SELECT /*+ GATHER_PLAN_STATISTICS */
    DOMCUST.CUSTOMER,DOMHEADER.WOODTYPE,DOMHEADER.ISSUEDATE ISSUEDATE,
    vw_testlots.TLOT_PREV PREV_LOT, VW_TESTLOTS.TLOT_NEXT NEXT_LOT,
    DOMLOTS.lotno ship_lot,       VW_PTMS_LOTS.AIRDRY
    AIRDRY,VW_PTMS_LOTS.BRIGHTNESS BRIGHT,VW_PTMS_LOTS.DIRT
    DIRT,VW_PTMS_LOTS.VISCOSITY VISCOSITY,
    (A.CCSF_0+B.CCSF_0)/2 CCSF_0,
    (A.TEAR1_0+B.TEAR1_0)/2 TEAR1_0,
    (A.BL_0+B.BL_0)/2 BL_0,
    (A.BURST_0+B.BURST_0)/2 BURST_0,
    (A.BULK_0+B.BULK_0)/2 BULK_0,
    (A.POROSITY_0+B.POROSITY_0)/2 POROSITY_0,
      (A.BOND_0+B.BOND_0)/2 BOND_0,
    (A.OPACITY_0+B.OPACITY_0)/2 OPACITY_0,
    (A.CCSF_1+B.CCSF_1)/2 CCSF_400,
    (A.TEAR1_1+B.TEAR1_1)/2 TEAR1_400,                                 (
    
    Plan hash value: 2207188603
    
    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    | Id  | Operation                              | Name         | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  | Writes |  OMem |  1Mem | Used-Mem | Used-Tmp|
    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT                       |              |      1 |        |    255 |00:00:05.90 |    1091K|     45 |     45 |       |       |          |         |
    |   1 |  SORT AGGREGATE                        |              |    255 |      1 |    255 |00:00:00.91 |     385K|      0 |      0 |       |       |          |         |
    |*  2 |   FILTER                               |              |    255 |        |  57880 |00:00:01.11 |     385K|      0 |      0 |       |       |          |         |
    |*  3 |    TABLE ACCESS BY INDEX ROWID         | LOTTEST      |    255 |      1 |  57880 |00:00:00.99 |     385K|      0 |      0 |       |       |          |         |
    |*  4 |     INDEX RANGE SCAN                   | UK_LOTNO     |    255 |     45 |    767K|00:00:00.85 |    5015 |      0 |      0 |       |       |          |         |
    |   5 |  SORT AGGREGATE                        |              |    255 |      1 |    255 |00:00:00.52 |     158K|      0 |      0 |       |       |          |         |
    |*  6 |   FILTER                               |              |    255 |        |  55792 |00:00:00.47 |     158K|      0 |      0 |       |       |          |         |
    |*  7 |    TABLE ACCESS BY INDEX ROWID         | LOTTEST      |    255 |      1 |  55792 |00:00:00.36 |     158K|      0 |      0 |       |       |          |         |
    |*  8 |     INDEX RANGE SCAN                   | UK_LOTNO     |    255 |     45 |    516K|00:00:00.55 |    1372 |      0 |      0 |       |       |          |         |
    |   9 |  SORT ORDER BY                         |              |      1 |      1 |    255 |00:00:05.90 |    1091K|     45 |     45 | 70656 | 70656 |63488  (0)|         |
    |  10 |   NESTED LOOPS                         |              |      1 |        |    255 |00:00:04.47 |     547K|     45 |     45 |       |       |          |         |
    |  11 |    NESTED LOOPS                        |              |      1 |      1 |    255 |00:00:04.47 |     546K|     45 |     45 |       |       |          |         |
    |  12 |     NESTED LOOPS                       |              |      1 |      1 |    255 |00:00:03.88 |     383K|     45 |     45 |       |       |          |         |
    |  13 |      NESTED LOOPS                      |              |      1 |      1 |    255 |00:00:03.02 |     979 |     45 |     45 |       |       |          |         |
    |  14 |       NESTED LOOPS                     |              |      1 |      1 |    255 |00:00:03.01 |     712 |     45 |     45 |       |       |          |         |
    |* 15 |        HASH JOIN                       |              |      1 |      1 |    255 |00:00:03.01 |     527 |     45 |     45 |   858K|   858K| 1283K (0)|         |
    |  16 |         NESTED LOOPS                   |              |      1 |     19 |    255 |00:00:00.01 |      28 |      0 |      0 |       |       |          |         |
    |  17 |          NESTED LOOPS                  |              |      1 |      1 |      9 |00:00:00.01 |      17 |      0 |      0 |       |       |          |         |
    |  18 |           TABLE ACCESS BY INDEX ROWID  | DOMCUST      |      1 |      1 |      1 |00:00:00.01 |       2 |      0 |      0 |       |       |          |         |
    |* 19 |            INDEX UNIQUE SCAN           | PK_DOMCUST   |      1 |      1 |      1 |00:00:00.01 |       1 |      0 |      0 |       |       |          |         |
    |* 20 |           TABLE ACCESS FULL            | DOMHEADER    |      1 |      1 |      9 |00:00:00.01 |      15 |      0 |      0 |       |       |          |         |
    |* 21 |          INDEX RANGE SCAN              | PK_DOMLOTS   |      9 |     21 |    255 |00:00:00.01 |      11 |      0 |      0 |       |       |          |         |
    |  22 |         VIEW                           | VW_PTMS_LOTS |      1 |    101 |  15101 |00:00:03.05 |     499 |     45 |     45 |       |       |          |         |
    |  23 |          SORT UNIQUE                   |              |      1 |    101 |  15101 |00:00:03.02 |     499 |     45 |     45 |  1328K|   587K| 1180K (0)|         |
    |  24 |           UNION-ALL                    |              |      1 |        |  15101 |00:00:03.06 |     499 |     45 |     45 |       |       |          |         |
    |  25 |            HASH GROUP BY               |              |      1 |    100 |  15101 |00:00:02.98 |       0 |     45 |     45 |  3004K|   982K| 3262K (1)|    1024 |
    |* 26 |             FILTER                     |              |      1 |    100 |  15842 |00:00:02.99 |       0 |      0 |      0 |       |       |          |         |
    |  27 |              REMOTE                    |              |      1 |        |  16563 |00:00:02.95 |       0 |      0 |      0 |       |       |          |         |
    |* 28 |            TABLE ACCESS FULL           | PTMSLOTS     |      1 |      1 |      0 |00:00:00.01 |     499 |      0 |      0 |       |       |          |         |
    |* 29 |        INDEX UNIQUE SCAN               | PK_DOMLOTS   |    255 |      1 |    255 |00:00:00.01 |     185 |      0 |      0 |       |       |          |         |
    |  30 |       TABLE ACCESS BY INDEX ROWID      | DOMHEADER    |    255 |      1 |    255 |00:00:00.01 |     267 |      0 |      0 |       |       |          |         |
    |* 31 |        INDEX UNIQUE SCAN               | PK_DOMHEADER |    255 |      1 |    255 |00:00:00.01 |      12 |      0 |      0 |       |       |          |         |
    |  32 |      TABLE ACCESS BY INDEX ROWID       | LOTTEST      |    255 |      1 |    255 |00:00:00.91 |     383K|      0 |      0 |       |       |          |         |
    |* 33 |       INDEX UNIQUE SCAN                | PK_LOTTEST   |    255 |      1 |    255 |00:00:00.91 |     382K|      0 |      0 |       |       |          |         |
    |  34 |        SORT AGGREGATE                  |              |    255 |      1 |    255 |00:00:00.91 |     382K|      0 |      0 |       |       |          |         |
    |  35 |         TABLE ACCESS BY INDEX ROWID    | LOTTEST      |    255 |      1 |    261 |00:00:00.90 |     382K|      0 |      0 |       |       |          |         |
    |* 36 |          INDEX RANGE SCAN              | UK_LOTNO     |    255 |      1 |    261 |00:00:00.90 |     382K|      0 |      0 |       |       |          |         |
    |  37 |           SORT AGGREGATE               |              |    255 |      1 |    255 |00:00:00.90 |     382K|      0 |      0 |       |       |          |         |
    |* 38 |            FILTER                      |              |    255 |        |  57880 |00:00:01.09 |     382K|      0 |      0 |       |       |          |         |
    |* 39 |             TABLE ACCESS BY INDEX ROWID| LOTTEST      |    255 |      1 |  57880 |00:00:00.97 |     382K|      0 |      0 |       |       |          |         |
    |* 40 |              INDEX RANGE SCAN          | UK_LOTNO     |    255 |     45 |    767K|00:00:00.85 |    1798 |      0 |      0 |       |       |          |         |
    |* 41 |     INDEX UNIQUE SCAN                  | PK_LOTTEST   |    255 |      1 |    255 |00:00:00.53 |     162K|      0 |      0 |       |       |          |         |
    |  42 |      SORT AGGREGATE                    |              |    255 |      1 |    255 |00:00:00.53 |     162K|      0 |      0 |       |       |          |         |
    |  43 |       TABLE ACCESS BY INDEX ROWID      | LOTTEST      |    255 |      1 |    264 |00:00:00.52 |     162K|      0 |      0 |       |       |          |         |
    |* 44 |        INDEX RANGE SCAN                | UK_LOTNO     |    255 |      1 |    264 |00:00:00.52 |     162K|      0 |      0 |       |       |          |         |
    |  45 |         SORT AGGREGATE                 |              |    255 |      1 |    255 |00:00:00.52 |     162K|      0 |      0 |       |       |          |         |
    |* 46 |          FILTER                        |              |    255 |        |  55792 |00:00:00.46 |     162K|      0 |      0 |       |       |          |         |
    |* 47 |           TABLE ACCESS BY INDEX ROWID  | LOTTEST      |    255 |      1 |  55792 |00:00:00.35 |     162K|      0 |      0 |       |       |          |         |
    |* 48 |            INDEX RANGE SCAN            | UK_LOTNO     |    255 |     45 |    516K|00:00:00.57 |    5282 |      0 |      0 |       |       |          |         |
    |  49 |    TABLE ACCESS BY INDEX ROWID         | LOTTEST      |    255 |      1 |    255 |00:00:00.01 |     255 |      0 |      0 |       |       |          |         |
    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - filter(:B1-365<=:B2+365)
       3 - filter(("WOODTYPE"=:B1 AND "PRODDATE">=:B2-365 AND "PRODDATE"<=:B3+365))
       4 - access("LOTNO"<:B1)
       6 - filter(:B1-365<=:B2+365)
       7 - filter(("WOODTYPE"=:B1 AND "PRODDATE">=:B2-365 AND "PRODDATE"<=:B3+365))
       8 - access("LOTNO">=:B1)
      15 - access("DOMLOTS"."LOTNO"="VW_PTMS_LOTS"."LOTID")
      19 - access("DOMCUST"."DOMCUSTID"=1)
      20 - filter(("DOMHEADER"."DOMCUSTID"=1 AND "DOMHEADER"."ISSUEDATE">=TO_DATE(' 2014-05-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "DOMHEADER"."WOODTYPE"='H'
                  AND TRUNC(INTERNAL_FUNCTION("DOMHEADER"."ISSUEDATE"))<=TO_DATE(' 2015-05-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss')))
      21 - access("DOMHEADER"."DOMID"="DOMLOTS"."DOMID")
      26 - filter("A"."StartTime">GREATEST(SYSDATE@!-730,TO_DATE(' 2013-04-16 13:00:00', 'syyyy-mm-dd hh24:mi:ss')))
      28 - filter("PRODTIME">SYSDATE@!-730)
      29 - access("DOMHEADER"."DOMID"="DOMLOTS"."DOMID" AND "DOMLOTS"."LOTNO"="DOMLOTS"."LOTNO")
      31 - access("DOMLOTS"."DOMID"="DOMHEADER"."DOMID")
      33 - access("A"."LOTID"=)
      36 - access("LOTTEST"."LOTNO"=)
      38 - filter(:B1-365<=:B2+365)
      39 - filter(("WOODTYPE"=:B1 AND "PRODDATE">=:B2-365 AND "PRODDATE"<=:B3+365))
      40 - access("LOTNO"<:B1)
      41 - access("B"."LOTID"=)
      44 - access("LOTTEST"."LOTNO"=)
      46 - filter(:B1-365<=:B2+365)
      47 - filter(("WOODTYPE"=:B1 AND "PRODDATE">=:B2-365 AND "PRODDATE"<=:B3+365))
      48 - access("LOTNO">=:B1)
    
    105 rows selected.
    
    Elapsed: 00:00:00.12
    
  • Question of the AMM

    As a general rule, I've heard it is best to analyze usage of your DB and manually set the memory settings, however, I decided to give the AMM a test and the results are confusing.

    OS: OEL 6.5

    DB: EE 11.2.0.3.0

    CPU: 16

    RAM: 96 GB

    I put the following settings on a simulated production DB and restarted.

    memory_max_target = 47G

    memory_target = 45G

    SGA_MAX_SIZE = 0

    SGA_TARGET = 0

    pga_aggregate_target = 0

    To my surprise, the sga_max_size changed to 5G with the PGA dominating the memory allocated to about 40G. I would have assumed that the buffer cache and shared pool would have been a much bigger part of memory instead of the skinny 1184 M (shared pool) and 3776 M (buffer cache) which was attributed. I ran a few significantly heavy read/write IO operations that consumed the SGA to simulate a heavy load for a full day, then stop and restarted, under the assumption that the AMM would 'learn' and increase the sga_max_size during restart. He did not. Clearly, I am missing in some basic concept of operation AMM determines the effectiveness and memory allocation (and Yes, I read the online documentation of SGA/PGA/AMM/EAMA).

    If anyone can provide insight as to why AMM puts BMG so small I would be very happy!

    Thank you

    > I ran a few considerably heavy read/write IO operations

    It is quite possible that most of your operations are either / some / all of

    a. direct Path reads (series or parallel) a "broad" table

    b. sort / group by operations

    The two would not need or use the cache buffers.  That they would use PGA.

    Hemant K Collette

  • Do not know if Hugepages installed and configured the right to the CCR 11.2.0.2

    OS: redhat linux 5

    DB: 11.2.0.2

    Cluster: 11.2.0.4

    I hugepages SA helped, and it seems that a little weird for me the message in the alerts log:

    Starting ORACLE instance (normal)

    Huge information Pages *.

    Huge pool of detected memory Pages (total: 21508 free: 21220)

    Allocation of LTVDS Pages huge success (allocated: 20481)

    ***********************************************************

    However, in 11.2.0.3 environment, I saw these formulations in the alerts log that seems normal to me:

    Starting ORACLE instance (normal)

    Large information Pages *.

    Total shared global area in large Pages = 0 KB (0%)

    Large Pages used by this instance: 0 (0 KB)

    Large wide Pages unused system = 0 (0 KB) (alloc incr 128 MB)

    Large Pages configured wide system = 0 (0 KB)

    The Page Size = 2048 KB

    RECOMMENDATION:

    Total size of the shared Global area is 40 GB. For optimal performance,

    before next restart of the instance, to increase the number

    big unused Pages by atleast 20481 2048 KB large Pages (40 GB)

    scale to get 100% of the Shared System

    Global area allocated by using large pages

    ***********************************************************

    I would really appreciate any entry here. The hugepages is configured right?

    OK, this shows that huge Pages are configured and valid. I guess it's the first system with the 11.2.0.2 database.

    A little back to the original question.

    Starting ORACLE instance (normal)

    Huge information Pages *.

    Huge pool of detected memory Pages (total: 21508 free: 21220)

    Allocation of LTVDS Pages huge success (allocated: 20481)

    ***********************************************************

    This above is normal when the huge Pages are used by the instance.

    This is what you see, when the huge Pages are not configured at the level of the BONE (your 11.2.0.3 environment):

    Starting ORACLE instance (normal)

    Large information Pages *.

    Total shared global area in large Pages = 0 KB (0%)

    Large Pages used by this instance: 0 (0 KB)

    Large wide Pages unused system = 0 (0 KB) (alloc incr 128 MB)

    Large Pages configured wide system = 0 (0 KB)

    The Page Size = 2048 KB

    In fact, if huge Pages have been set up at the level of the BONE, even if the instance has been said to not use them, he would still list the number of pages at the start, like this:

    Large information Pages *.

    Setting use_large_pages = FALSE

    Large pages unused system wide = 10000 (20000 MB)

    Large pages configured system wide = 10000 (20000 MB)

    The large page size = 2048 KB

    Note that the message has changed in 11.2.0.3 and later versions.

Maybe you are looking for