Oracle 12c Database swapping after set up huge pages












1















I need to setup a Oracle Database 12c with 64GB RAM on Linux RedHet. I decided to use huge pages. Something must have went wrong. Altertlog:




WARNING: Heavy swapping observed on system in last 5 mins. pct of
memory swapped in [0.42%] pct of memory swapped out [1.82%]. Please
make sure there is no memory pressure and the SGA and PGA are
configured correctly. Look at DBRM trace file for more details.




Supported system pagesize(s):   PAGESIZE  AVAILABLE_PAGES  EXPECTED_PAGES  ALLOCATED_PAGES  ERROR(s) 
4K Configured 10 8192010 NONE
2048K 15946 16001 0 NONE


Seems like the Database is not using the huge pages? What could be the issue?



Update:



 grep Huge /proc/meminfo
AnonHugePages: 40960 kB
HugePages_Total: 16001
HugePages_Free: 16001
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB









share|improve this question
















bumped to the homepage by Community 8 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
















  • Would you care to add the output of a "vmstat 5 5" to your question? Just to see if your system is really "swapping". You've assigne 32Gb to hugepages, so there should be plenty of room for normal activity. Also, "grep Huge /proc/meminfo" would show if you're using it or not.

    – Gerard H. Pille
    Aug 29 '18 at 7:27











  • Unfortunately I cannot provide the vmstat because I restarted the System with new settings. I found that limits in the grep oracle /etc/security/limits.conf were set wrong: #oracle soft memlock 19857408 #oracle hard memlock 19857408. The limits should be set to something like 90% of the total RAM.

    – r0tt
    Aug 29 '18 at 8:05











  • Good for you! I was going to point you to oracle-base.com/articles/linux/…

    – Gerard H. Pille
    Aug 29 '18 at 8:42











  • They use the Formular HugePages * Hugepagesize.

    – r0tt
    Aug 29 '18 at 8:44











  • The issue here was that the Oracle Database wanted to use more RAM than the limit allowed.

    – r0tt
    Aug 29 '18 at 8:49
















1















I need to setup a Oracle Database 12c with 64GB RAM on Linux RedHet. I decided to use huge pages. Something must have went wrong. Altertlog:




WARNING: Heavy swapping observed on system in last 5 mins. pct of
memory swapped in [0.42%] pct of memory swapped out [1.82%]. Please
make sure there is no memory pressure and the SGA and PGA are
configured correctly. Look at DBRM trace file for more details.




Supported system pagesize(s):   PAGESIZE  AVAILABLE_PAGES  EXPECTED_PAGES  ALLOCATED_PAGES  ERROR(s) 
4K Configured 10 8192010 NONE
2048K 15946 16001 0 NONE


Seems like the Database is not using the huge pages? What could be the issue?



Update:



 grep Huge /proc/meminfo
AnonHugePages: 40960 kB
HugePages_Total: 16001
HugePages_Free: 16001
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB









share|improve this question
















bumped to the homepage by Community 8 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
















  • Would you care to add the output of a "vmstat 5 5" to your question? Just to see if your system is really "swapping". You've assigne 32Gb to hugepages, so there should be plenty of room for normal activity. Also, "grep Huge /proc/meminfo" would show if you're using it or not.

    – Gerard H. Pille
    Aug 29 '18 at 7:27











  • Unfortunately I cannot provide the vmstat because I restarted the System with new settings. I found that limits in the grep oracle /etc/security/limits.conf were set wrong: #oracle soft memlock 19857408 #oracle hard memlock 19857408. The limits should be set to something like 90% of the total RAM.

    – r0tt
    Aug 29 '18 at 8:05











  • Good for you! I was going to point you to oracle-base.com/articles/linux/…

    – Gerard H. Pille
    Aug 29 '18 at 8:42











  • They use the Formular HugePages * Hugepagesize.

    – r0tt
    Aug 29 '18 at 8:44











  • The issue here was that the Oracle Database wanted to use more RAM than the limit allowed.

    – r0tt
    Aug 29 '18 at 8:49














1












1








1








I need to setup a Oracle Database 12c with 64GB RAM on Linux RedHet. I decided to use huge pages. Something must have went wrong. Altertlog:




WARNING: Heavy swapping observed on system in last 5 mins. pct of
memory swapped in [0.42%] pct of memory swapped out [1.82%]. Please
make sure there is no memory pressure and the SGA and PGA are
configured correctly. Look at DBRM trace file for more details.




Supported system pagesize(s):   PAGESIZE  AVAILABLE_PAGES  EXPECTED_PAGES  ALLOCATED_PAGES  ERROR(s) 
4K Configured 10 8192010 NONE
2048K 15946 16001 0 NONE


Seems like the Database is not using the huge pages? What could be the issue?



Update:



 grep Huge /proc/meminfo
AnonHugePages: 40960 kB
HugePages_Total: 16001
HugePages_Free: 16001
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB









share|improve this question
















I need to setup a Oracle Database 12c with 64GB RAM on Linux RedHet. I decided to use huge pages. Something must have went wrong. Altertlog:




WARNING: Heavy swapping observed on system in last 5 mins. pct of
memory swapped in [0.42%] pct of memory swapped out [1.82%]. Please
make sure there is no memory pressure and the SGA and PGA are
configured correctly. Look at DBRM trace file for more details.




Supported system pagesize(s):   PAGESIZE  AVAILABLE_PAGES  EXPECTED_PAGES  ALLOCATED_PAGES  ERROR(s) 
4K Configured 10 8192010 NONE
2048K 15946 16001 0 NONE


Seems like the Database is not using the huge pages? What could be the issue?



Update:



 grep Huge /proc/meminfo
AnonHugePages: 40960 kB
HugePages_Total: 16001
HugePages_Free: 16001
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB






oracle memory






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Aug 29 '18 at 7:35







r0tt

















asked Aug 29 '18 at 7:06









r0ttr0tt

39031022




39031022





bumped to the homepage by Community 8 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.







bumped to the homepage by Community 8 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.















  • Would you care to add the output of a "vmstat 5 5" to your question? Just to see if your system is really "swapping". You've assigne 32Gb to hugepages, so there should be plenty of room for normal activity. Also, "grep Huge /proc/meminfo" would show if you're using it or not.

    – Gerard H. Pille
    Aug 29 '18 at 7:27











  • Unfortunately I cannot provide the vmstat because I restarted the System with new settings. I found that limits in the grep oracle /etc/security/limits.conf were set wrong: #oracle soft memlock 19857408 #oracle hard memlock 19857408. The limits should be set to something like 90% of the total RAM.

    – r0tt
    Aug 29 '18 at 8:05











  • Good for you! I was going to point you to oracle-base.com/articles/linux/…

    – Gerard H. Pille
    Aug 29 '18 at 8:42











  • They use the Formular HugePages * Hugepagesize.

    – r0tt
    Aug 29 '18 at 8:44











  • The issue here was that the Oracle Database wanted to use more RAM than the limit allowed.

    – r0tt
    Aug 29 '18 at 8:49



















  • Would you care to add the output of a "vmstat 5 5" to your question? Just to see if your system is really "swapping". You've assigne 32Gb to hugepages, so there should be plenty of room for normal activity. Also, "grep Huge /proc/meminfo" would show if you're using it or not.

    – Gerard H. Pille
    Aug 29 '18 at 7:27











  • Unfortunately I cannot provide the vmstat because I restarted the System with new settings. I found that limits in the grep oracle /etc/security/limits.conf were set wrong: #oracle soft memlock 19857408 #oracle hard memlock 19857408. The limits should be set to something like 90% of the total RAM.

    – r0tt
    Aug 29 '18 at 8:05











  • Good for you! I was going to point you to oracle-base.com/articles/linux/…

    – Gerard H. Pille
    Aug 29 '18 at 8:42











  • They use the Formular HugePages * Hugepagesize.

    – r0tt
    Aug 29 '18 at 8:44











  • The issue here was that the Oracle Database wanted to use more RAM than the limit allowed.

    – r0tt
    Aug 29 '18 at 8:49

















Would you care to add the output of a "vmstat 5 5" to your question? Just to see if your system is really "swapping". You've assigne 32Gb to hugepages, so there should be plenty of room for normal activity. Also, "grep Huge /proc/meminfo" would show if you're using it or not.

– Gerard H. Pille
Aug 29 '18 at 7:27





Would you care to add the output of a "vmstat 5 5" to your question? Just to see if your system is really "swapping". You've assigne 32Gb to hugepages, so there should be plenty of room for normal activity. Also, "grep Huge /proc/meminfo" would show if you're using it or not.

– Gerard H. Pille
Aug 29 '18 at 7:27













Unfortunately I cannot provide the vmstat because I restarted the System with new settings. I found that limits in the grep oracle /etc/security/limits.conf were set wrong: #oracle soft memlock 19857408 #oracle hard memlock 19857408. The limits should be set to something like 90% of the total RAM.

– r0tt
Aug 29 '18 at 8:05





Unfortunately I cannot provide the vmstat because I restarted the System with new settings. I found that limits in the grep oracle /etc/security/limits.conf were set wrong: #oracle soft memlock 19857408 #oracle hard memlock 19857408. The limits should be set to something like 90% of the total RAM.

– r0tt
Aug 29 '18 at 8:05













Good for you! I was going to point you to oracle-base.com/articles/linux/…

– Gerard H. Pille
Aug 29 '18 at 8:42





Good for you! I was going to point you to oracle-base.com/articles/linux/…

– Gerard H. Pille
Aug 29 '18 at 8:42













They use the Formular HugePages * Hugepagesize.

– r0tt
Aug 29 '18 at 8:44





They use the Formular HugePages * Hugepagesize.

– r0tt
Aug 29 '18 at 8:44













The issue here was that the Oracle Database wanted to use more RAM than the limit allowed.

– r0tt
Aug 29 '18 at 8:49





The issue here was that the Oracle Database wanted to use more RAM than the limit allowed.

– r0tt
Aug 29 '18 at 8:49










1 Answer
1






active

oldest

votes


















0














The steps I did to setup this hugepage configuration on ReDHat 7.3 64GBRAM and the mistake. (Link from oracle base posted above provides a better Manual for reuse)
Check total RAM of OS:



grep MemTotal /proc/meminfo
MemTotal: 65809456 kB


Check Oracle Database – AMM needs to be off:
MEMORY_TARGET und MEMORY_MAX_TARGETneed to be set to zero.



SQL> select value from v$parameter where name = 'memory_target';
VALUE
---------------------------
0


Calculate SGA size, for example 32GB:



select value/1024 from v$parameter where name = 'sga_target';

VALUE/1024
----------
32768000


Calculate Huge Pages,
for a x86_64 Red Hat Enterprise Linux Server we can use a default 2MB hugepagesize:



SGA / Hugepagesize=Hugepage +1
32768000/2048=16001


This need to be set in /etc/sysctl.conf as root:



vm.nr_hugepages =16001


Also we need to set the /etc/security/limits.conf. This value hard and soft memlock should be greater than the the SGA and smaller than the total RAM.



Hugepages * Hugepagesize = minimum Memlock or something like 90% of total RAM.


Setting memlock to a lower value then SGA leads to unpredictable behavior of the Oracle Database. As commented above Oracle Database will allocate memory without using the huge pages. In my case this leaded to fatal errors when using impdp. Datapump did not provide errors which made sense.



grep oracle /etc/security/limits.conf
oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536
oracle soft stack 10240
#oracle soft memlock 19857408
#oracle hard memlock 19857408
oracle soft memlock 57671680
oracle hard memlock 57671680


For RedHat we also need to turn off Transparent Hugepages



cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
[always] madvise never

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag

cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
always madvise [never]


Reboot System and start Oracle Database check:



grep Huge /proc/meminfo
AnonHugePages: 40960 kB
HugePages_Total: 16001
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB





share|improve this answer























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "182"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f216161%2foracle-12c-database-swapping-after-set-up-huge-pages%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    The steps I did to setup this hugepage configuration on ReDHat 7.3 64GBRAM and the mistake. (Link from oracle base posted above provides a better Manual for reuse)
    Check total RAM of OS:



    grep MemTotal /proc/meminfo
    MemTotal: 65809456 kB


    Check Oracle Database – AMM needs to be off:
    MEMORY_TARGET und MEMORY_MAX_TARGETneed to be set to zero.



    SQL> select value from v$parameter where name = 'memory_target';
    VALUE
    ---------------------------
    0


    Calculate SGA size, for example 32GB:



    select value/1024 from v$parameter where name = 'sga_target';

    VALUE/1024
    ----------
    32768000


    Calculate Huge Pages,
    for a x86_64 Red Hat Enterprise Linux Server we can use a default 2MB hugepagesize:



    SGA / Hugepagesize=Hugepage +1
    32768000/2048=16001


    This need to be set in /etc/sysctl.conf as root:



    vm.nr_hugepages =16001


    Also we need to set the /etc/security/limits.conf. This value hard and soft memlock should be greater than the the SGA and smaller than the total RAM.



    Hugepages * Hugepagesize = minimum Memlock or something like 90% of total RAM.


    Setting memlock to a lower value then SGA leads to unpredictable behavior of the Oracle Database. As commented above Oracle Database will allocate memory without using the huge pages. In my case this leaded to fatal errors when using impdp. Datapump did not provide errors which made sense.



    grep oracle /etc/security/limits.conf
    oracle soft nproc 2047
    oracle hard nproc 16384
    oracle soft nofile 1024
    oracle hard nofile 65536
    oracle soft stack 10240
    #oracle soft memlock 19857408
    #oracle hard memlock 19857408
    oracle soft memlock 57671680
    oracle hard memlock 57671680


    For RedHat we also need to turn off Transparent Hugepages



    cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
    [always] madvise never

    echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
    echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag

    cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
    always madvise [never]


    Reboot System and start Oracle Database check:



    grep Huge /proc/meminfo
    AnonHugePages: 40960 kB
    HugePages_Total: 16001
    HugePages_Free: 0
    HugePages_Rsvd: 0
    HugePages_Surp: 0
    Hugepagesize: 2048 kB





    share|improve this answer




























      0














      The steps I did to setup this hugepage configuration on ReDHat 7.3 64GBRAM and the mistake. (Link from oracle base posted above provides a better Manual for reuse)
      Check total RAM of OS:



      grep MemTotal /proc/meminfo
      MemTotal: 65809456 kB


      Check Oracle Database – AMM needs to be off:
      MEMORY_TARGET und MEMORY_MAX_TARGETneed to be set to zero.



      SQL> select value from v$parameter where name = 'memory_target';
      VALUE
      ---------------------------
      0


      Calculate SGA size, for example 32GB:



      select value/1024 from v$parameter where name = 'sga_target';

      VALUE/1024
      ----------
      32768000


      Calculate Huge Pages,
      for a x86_64 Red Hat Enterprise Linux Server we can use a default 2MB hugepagesize:



      SGA / Hugepagesize=Hugepage +1
      32768000/2048=16001


      This need to be set in /etc/sysctl.conf as root:



      vm.nr_hugepages =16001


      Also we need to set the /etc/security/limits.conf. This value hard and soft memlock should be greater than the the SGA and smaller than the total RAM.



      Hugepages * Hugepagesize = minimum Memlock or something like 90% of total RAM.


      Setting memlock to a lower value then SGA leads to unpredictable behavior of the Oracle Database. As commented above Oracle Database will allocate memory without using the huge pages. In my case this leaded to fatal errors when using impdp. Datapump did not provide errors which made sense.



      grep oracle /etc/security/limits.conf
      oracle soft nproc 2047
      oracle hard nproc 16384
      oracle soft nofile 1024
      oracle hard nofile 65536
      oracle soft stack 10240
      #oracle soft memlock 19857408
      #oracle hard memlock 19857408
      oracle soft memlock 57671680
      oracle hard memlock 57671680


      For RedHat we also need to turn off Transparent Hugepages



      cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
      [always] madvise never

      echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
      echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag

      cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
      always madvise [never]


      Reboot System and start Oracle Database check:



      grep Huge /proc/meminfo
      AnonHugePages: 40960 kB
      HugePages_Total: 16001
      HugePages_Free: 0
      HugePages_Rsvd: 0
      HugePages_Surp: 0
      Hugepagesize: 2048 kB





      share|improve this answer


























        0












        0








        0







        The steps I did to setup this hugepage configuration on ReDHat 7.3 64GBRAM and the mistake. (Link from oracle base posted above provides a better Manual for reuse)
        Check total RAM of OS:



        grep MemTotal /proc/meminfo
        MemTotal: 65809456 kB


        Check Oracle Database – AMM needs to be off:
        MEMORY_TARGET und MEMORY_MAX_TARGETneed to be set to zero.



        SQL> select value from v$parameter where name = 'memory_target';
        VALUE
        ---------------------------
        0


        Calculate SGA size, for example 32GB:



        select value/1024 from v$parameter where name = 'sga_target';

        VALUE/1024
        ----------
        32768000


        Calculate Huge Pages,
        for a x86_64 Red Hat Enterprise Linux Server we can use a default 2MB hugepagesize:



        SGA / Hugepagesize=Hugepage +1
        32768000/2048=16001


        This need to be set in /etc/sysctl.conf as root:



        vm.nr_hugepages =16001


        Also we need to set the /etc/security/limits.conf. This value hard and soft memlock should be greater than the the SGA and smaller than the total RAM.



        Hugepages * Hugepagesize = minimum Memlock or something like 90% of total RAM.


        Setting memlock to a lower value then SGA leads to unpredictable behavior of the Oracle Database. As commented above Oracle Database will allocate memory without using the huge pages. In my case this leaded to fatal errors when using impdp. Datapump did not provide errors which made sense.



        grep oracle /etc/security/limits.conf
        oracle soft nproc 2047
        oracle hard nproc 16384
        oracle soft nofile 1024
        oracle hard nofile 65536
        oracle soft stack 10240
        #oracle soft memlock 19857408
        #oracle hard memlock 19857408
        oracle soft memlock 57671680
        oracle hard memlock 57671680


        For RedHat we also need to turn off Transparent Hugepages



        cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
        [always] madvise never

        echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
        echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag

        cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
        always madvise [never]


        Reboot System and start Oracle Database check:



        grep Huge /proc/meminfo
        AnonHugePages: 40960 kB
        HugePages_Total: 16001
        HugePages_Free: 0
        HugePages_Rsvd: 0
        HugePages_Surp: 0
        Hugepagesize: 2048 kB





        share|improve this answer













        The steps I did to setup this hugepage configuration on ReDHat 7.3 64GBRAM and the mistake. (Link from oracle base posted above provides a better Manual for reuse)
        Check total RAM of OS:



        grep MemTotal /proc/meminfo
        MemTotal: 65809456 kB


        Check Oracle Database – AMM needs to be off:
        MEMORY_TARGET und MEMORY_MAX_TARGETneed to be set to zero.



        SQL> select value from v$parameter where name = 'memory_target';
        VALUE
        ---------------------------
        0


        Calculate SGA size, for example 32GB:



        select value/1024 from v$parameter where name = 'sga_target';

        VALUE/1024
        ----------
        32768000


        Calculate Huge Pages,
        for a x86_64 Red Hat Enterprise Linux Server we can use a default 2MB hugepagesize:



        SGA / Hugepagesize=Hugepage +1
        32768000/2048=16001


        This need to be set in /etc/sysctl.conf as root:



        vm.nr_hugepages =16001


        Also we need to set the /etc/security/limits.conf. This value hard and soft memlock should be greater than the the SGA and smaller than the total RAM.



        Hugepages * Hugepagesize = minimum Memlock or something like 90% of total RAM.


        Setting memlock to a lower value then SGA leads to unpredictable behavior of the Oracle Database. As commented above Oracle Database will allocate memory without using the huge pages. In my case this leaded to fatal errors when using impdp. Datapump did not provide errors which made sense.



        grep oracle /etc/security/limits.conf
        oracle soft nproc 2047
        oracle hard nproc 16384
        oracle soft nofile 1024
        oracle hard nofile 65536
        oracle soft stack 10240
        #oracle soft memlock 19857408
        #oracle hard memlock 19857408
        oracle soft memlock 57671680
        oracle hard memlock 57671680


        For RedHat we also need to turn off Transparent Hugepages



        cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
        [always] madvise never

        echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
        echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag

        cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
        always madvise [never]


        Reboot System and start Oracle Database check:



        grep Huge /proc/meminfo
        AnonHugePages: 40960 kB
        HugePages_Total: 16001
        HugePages_Free: 0
        HugePages_Rsvd: 0
        HugePages_Surp: 0
        Hugepagesize: 2048 kB






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Aug 29 '18 at 9:38









        r0ttr0tt

        39031022




        39031022






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Database Administrators Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f216161%2foracle-12c-database-swapping-after-set-up-huge-pages%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Liste der Baudenkmale in Friedland (Mecklenburg)

            Single-Malt-Whisky

            Czorneboh