Blog - comments

Hi Perry, The spare CPU power is of course available for other processes ( i.e non-caged database)! ...
When I studied Oracle New Feature Guide "Media Failure: PDB SYSTEM Data File" , I was surprised tha...
Hayat Khan

Really a nice article to study.

Thanks,

Amol Bhoite

Bonjour,

Tout d'abord merci pour cet article. J'aimerai savoir si ACFS est gratuit ?

Chris

Chris
Hi Jerome.. I have a question. Suppose if we have 8 CPUs on server and we assign 2 CPUs to a databas...
Perry Kahlon
Blog Michael Schwalm Unable to resize tmpfs on Oracle Enterprise Linux 6 versions

dbi services Blog

Welcome to the dbi services Blog! This blog focuses on IT infrastructure - featuring news, troubleshooting, and tips & tricks. It covers database, middleware, and OS technologies such as Oracle, Microsoft SQL Server, Documentum, MySQL, PostgreSQL, Sybase, Unix/Linux, etc. The dbi services blog represents the view of our consultants, not necessarily that of dbi services. Feel free to comment on the postings!

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that have been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.

Unable to resize tmpfs on Oracle Enterprise Linux 6 versions

I recently helped to create a lab dedicated to a training about Oracle backup and recovery, with Oracle 11g databases. While creating several databases on an Oracle Enterprise Linux 6.1, I wanted to resize the tmpfs to allocate more memory to the databases for AMM (Automatic Memory Management). That was a small challenge :-) ...

By default, the value of the tmpfs is the half of the installed memory. So, on my 3 GB memory sized environment, the tmpfs was sized to 1,5 GB per default. This was not enough to run my 3 databases concurrently. In this case, resize the tmpfs was necessary.

The common way to resize the tmpfs is to edit the fstab file located in the /etc directory, and to add the "size=" attribute for the tmpfs row. Alter this file is supposed to allow the new size to be static, meaning that the tmpfs will keep the new value at each startup.

 

In the following example I tryed to resize the tmpfs to 2 GB:

tmpfs         /dev/shm       tmpfs   defaults,size=2g    0 0

 

But surprise, after saving the file and restarting the machine, tmpfs was still 1,5 GB sized:

 

[root@vmtestora11g ~]# df -h

Filesystem            Size  Used Avail Use% Mounted on

tmpfs                 1.5G  420M  1.1G  28% /dev/shm

...

 

However, if I hot resize the tmpfs with the following command, the size is updated successfully:

mount -o remount /dev/shm

 

[root@vmtestora11g ~]# df -h

Filesystem            Size  Used Avail Use% Mounted on

tmpfs                 2.0G  420M  1.6G  21% /dev/shm

...

 

In fact, from Oracle Enterprise Linux 6.0, this parameter is not persistent: at startup, the tmpfs value is set to its default value, regardless what is recorded in the fstab. This problem is also issued on Red Hat 6, and it seems to be a bug proper to this Linux distribution.

 

To fix this problem, a simple way is to automatically run the previous command mount -o remount /dev/shm at startup. Tmpfs must be resized before starting Oracle to avoid any risk of database shutdown. Two cases:

 

  • Database is not set to start automatically at server startup: the script /etc/rc.d/rc.local can be used. This script allows to execute commands or other scripts. It is executed after all other init scripts, but if Oracle is started manually it is not a problem.

  • Database is set to start automatically at server startup (using for example the dbi services DMK service_start_stop script): it is better to create a specific script to run the command, and to configure it with chkconfig to execute before the oracle services start script, at wanted run levels.

rc.local

 Example of using rc.local script

 

Some people prefer to use another way to fix the problem, modifying the /etc/rc.d/rc.sysinit file. This technique is not developped here, but just know that the sysinit file is responsible of few operations such as mounting filesystems or setup networking, and that it is the first script run by the /etc/inittab file, at /sbin/init process startup.

Alter this file is at your own risks, it is not advised to change it.

To conclude with something interesting: I tried to relocate the tmpfs from /dev/shm to /mnt/shm (for example). This time, the size parameter was loaded successfully at startup. But I quickly realized that after starting an instance, the new path of tmpfs remained empty and unused.

What is strange is that the instance was running correctly with AMM, which mode is supposed to require the shared memory file system /dev/shm (tmpfs):

SQL> show parameter memory

NAME                                 TYPE        VALUE
------------------------------------ ----------- -----------
memory_max_target                    big integer 800M
memory_target                        big integer 800M

 

[root@vmtestora11g ~]# df -h

Filesystem            Size  Used Avail Use% Mounted on
tmpfs                 2.0G     0  2.0G   0% /mnt/shm

 

So if the instance is running, and no tmpfs appears to be used, where can be loaded the SGA ? The response is in /dev/shm ! Yes, no matter if a tmpfs filesystem is declared or not in the fstab, Oracle still uses the /dev/shm path for SGA with AMM.

[root@vmtestora11g ~]# ls -altr /dev/shm
total 490836
-rw-r-----. 1 oracle oinstall 4194304 Oct 31 13:45 ora_DBTEST1_425984_0
-rw-r-----. 1 oracle oinstall 4194304 Oct 31 13:45 ora_DBTEST1_425984_1
-rw-r-----. 1 oracle oinstall       0 Oct 31 13:45 ora_DBTEST1_458753_0

...

 

And tmpfs still gets the default size value:

[root@vmtestora11g ~]# df -h /dev/shm
Filesystem            Size  Used Avail Use% Mounted on
-                     1.5G  480M  1.1G  32% /dev/shm

Rate this blog entry:
1

Michael Schwalm is Consultant at dbi Services and has more than two years of experience in Oracle database administration. He has a broad knowledge in the realization of virtualization infrastructures such as vMware vSphere. He took his first steps in database administration as an integrator of a web applications on Unix, Oracle, and Websphere environments. Michael Schwalm is Oracle Certified Professional 11g. Prior to joining dbi services, Michael Schwalm was application administrator at SOGETI Est (F) on behalf of PSA Peugeot Citroen and responsible for the realization and managing of Unix environments and Oracle databases in the context of migration projects. Michael Schwalm holds a BTS diploma in Information System Management from Belfort (F) and a TSAR diploma in advanced network administration from Strasbourg (F). His branch-related experience covers Automotive, Software industry, Financial Services / Banking, etc.

Comments

  • Guest
    Davide Tuesday, 20 November 2012

    Thank you Michael, I'm experiencing the same issue with CentOS 6.3.
    A good trick is to insert

    mount -o remount /dev/shm

    at the beginning of the dbora file inside /etc/init.d , in case Oracle is started automatically!

  • Michael Schwalm
    Michael Schwalm Tuesday, 20 November 2012

    Hi Davide, thanks for your feedback. It is a good way to avoid to create a dedicated script. I personaly prefer to let the dbora file to its original state, and create the dedicated script, in case of script upgrade (new release of DMK for example) or a bug fix provided by Linux teams. No need to alter the script again in this case..

  • Guest
    Johannes Ahrends Thursday, 29 November 2012

    There is another way (which I guess is simpler) to change the behavior of the mount for tmpfs: change the entry in /etc/rc.d/rc.sysinit from "mount -f /dev/shm >/dev/null 2>&1" to "mount /dev/shm >/dev/null 2>&1" (so remove the -f option).

Leave your comment

Guest Friday, 25 April 2014
AddThis Social Bookmark Button
Deutsch (DE-CH-AT)   French (Fr)
NewsOfficesContact

Contact

Contact us now!

Send us your request!

Our workshops

dbi FlexService SLA - ISO 20000 certified.

dbi FlexService SLA ISO 20000

Expert insight from insiders!

Fixed Price Services

dbi FlexService SLA - ISO 20000 certified.

dbi FlexService SLA ISO 20000

A safe investment: our IT services at fixed prices!

Your flexible SLA

dbi FlexService SLA - ISO 20000 certified.

dbi FlexService SLA ISO 20000

ISO 20000 certified & freely customizable!

dbi services Newsletter