Oracle 12c EE - ORA-27106: system pages not available to allocate memory

[marcelo-ochoa]

Using Oracle 12c EE version throws ORA-27106: system pages not available to allocate memory due missed parameter in sysctl.conf file. According to Oracle documentation this parameter should be: vm.hugetlb_shm_group=dba_gid for example, if groupadd -g 500 dba is Dockerfile.ee: vm.hugetlb_shm_group=500 at docker run time running as root is fixed by calling:

#!/bin/bash
# fix ORA-27106: system pages not available to allocate memory
sysctl vm.hugetlb_shm_group=500

At Dockerfile.ee script the effective user is oracle, so I propose fixed that using another script running as root user which call finally runOracle.sh script, for example: Dockerfile

USER    root

VOLUME ["/opt/oracle/oradata"]
EXPOSE  1521 5500

CMD [ "sh" , "-c" ,  "/home/oracle/manage-oracle.sh" ]

where manage-oracle.sh call sysctl command and then runOracle.sh as user oracle.

sysctl vm.hugetlb_shm_group=500

echo "export ORACLE_SID=$ORACLE_SID" >>/home/oracle/.bashrc
echo "export ORACLE_PDB=$ORACLE_PDB" >>/home/oracle/.bashrc
su - oracle -c "$ORACLE_BASE/runOracle.sh"

[gvenzl]

I don't think that it is good practice to explicitly modify kernel parameters inside a container as they may affect the unix host as well. And it may require to run the container in privileged mode which is also not desirable. Docker 1.12 has introduces a parameter for setting sysctl parameters inside the container at runtime: Configure namespaced kernel parameters (sysctls) at runtime. But it appears that the parameter posted above is not (yet) white listed:

[oracle@localhost dockerfiles]# sudo docker run --name oracle-test --sysctl vm.hugetlb_shm_group=500 -p 1521:1521 -v /home/oracle/oradata:/opt/oracle/oradata oracle/database:12.1.0.2-ee
invalid argument "vm.hugetlb_shm_group=500" for --sysctl: sysctl 'vm.hugetlb_shm_group=500' is not whitelisted
See 'docker run --help'.

I think for now the preferred method is to set host kernel parameters specifically to a value that is desired inside a container.

@Djelibeybi, do you have more input on this?

[Djelibeybi]

Can we confirm if setting this inside the container actually changes the host? To be honest, my DB knowledge is pretty slim, so I'm wondering if there is another workaround that doesn't require making this change.

The simplest change is to do at the host level though.

[marcelo-ochoa]

Changing this parameter at the container level change the host level value, here the test case:

root@localhost:/home/data/db# sysctl -a|grep vm.hugetlb_shm_group
vm.hugetlb_shm_group = 0
    -- start a container in another terminal using a regular user --
root@localhost:/home/data/db# sysctl -a|grep vm.hugetlb_shm_group
vm.hugetlb_shm_group = 54322

because by adding --privileged parameter we allow that. This could be a problem in a host with multiple containers requiring this parameter, if there is a workaround for this ora-error rather than changing hugetlb_shm_group any tip will be great. --sysctl parameter is not allowed at Oracle Container cloud service by now. Marcelo.

[brunoborges]

@marcelo-ochoa out of curiosity, what is the value of running Oracle DB on a Docker container inside Container CS, instead of DBCS ?

[marcelo-ochoa]

Well as in my blogpost a Docker image running in Oracle CS service run faster than in DBAAS, but is only just for fun. I am preparing another post with my personal test of the CS.

El 12/12/2016 21:39, "Bruno Borges" notifications@github.com escribió:

@marcelo-ochoa https://github.com/marcelo-ochoa out of curiosity, what is the value of running Oracle DB on a Docker container inside Container CS, instead of DBCS ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/oracle/docker-images/issues/222#issuecomment-266599763, or mute the thread https://github.com/notifications/unsubscribe-auth/AQNVhhFHU39pnOOiulqjwzhmB1CX1sGJks5rHeldgaJpZM4K_sk5 .

[brunoborges]

mind to share the URL to your blog post?

[marcelo-ochoa]

Sure.

El mar., 13 dic. 2016 a las 5:54, Bruno Borges (notifications@github.com) escribió:

mind to share the URL to your blog post?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/oracle/docker-images/issues/222#issuecomment-266681566, or mute the thread https://github.com/notifications/unsubscribe-auth/AQNVhvLrPI4hOXrTqmLf5OmmmanY97Trks5rHl1LgaJpZM4K_sk5 .

[gvenzl]

@marcelo-ochoa, can you also please share a test case and/or background to this?

[marcelo-ochoa]

Yes, my idea is to write another blog post similar to this test including other topics such as private registry usage.

[gvenzl]

I still struggle to understand the problem here. The container is created with use_large_pages=TRUE (the default) which means that the database may use large pages if available but doesn't have to, see the documentation.

That being said, the documentation for enabling HugePages support does not even mention the parameter vm.hugetlb_shm_group to be changed. So at this point I struggle to understand what would be accomplished by changing this parameter or whether this change is even needed.

[marcelo-ochoa]

OK, so as a workaround the instance created by this Docker image should be changed the dbca.rsp.tmpl file with a parameter USE_LARGE_PAGES=FALSE, because by default is TRUE. And telling users that this parameters will affect the performance when using large SGA values.

[gvenzl]

No. If you follow the link to the documentation you will find that TRUE means that the database can use huge pages if available and can even mix between huge pages and regular pages if there aren't enough huge pages available. However, if there are no huge pages available the database will use regular pages which means that huge pages are not mandatory to be there. Hence why TRUE is the default parameter. If there are huge pages available, use them, otherwise continue with regular pages. Only if the parameter is set to ONLY the database will accept huge pages and huge pages only. In the case that huge pages aren't available the database will raise an error on startup.

If you read my response above a second time you will also find that all of that has nothing to do with the Linux parameter vm.hugetlb_shm_group as per the second documentation link. So whatever issue you face is not related, at least not directly, to the parameter vm.hugetlb_shm_group.

But given that you still have not shared under what circumstances you do get this error it is hard for me to figure out why you get that error and whether it is legitimate. So please share a test case here in this issue thread and some explanation what you are trying to do that causes this error.

[marcelo-ochoa]

@gvenzl I remember the exception when trying to configure a large SGA and using it, I'll try to reproduce it with a simple test case.

[marcelo-ochoa]

FYI

• Some conclusion of 1 month usage of OCCS
• How to provisioning latest Oracle Apex distribution on Docker and 11gXE for course setup, development, testing and production environments
• Update of the previous post with Apex 5.1 support
• Comparing DBAAS with IAAS (Docker on Ubuntu) using 12cEE Docker images Best regards, Marcelo.

[gvenzl]

Thanks @marcelo-ochoa,

I will close this issue until you can reconfirm with a test case that this is indeed an issue.