2013 - Deploying Oracle RAC 11g R2 Database on Red Hat Enterprise Linux 6 - Recommended Practices

Updated -

This reference architecture provides a step-by-step deployment procedure with the latest recommended practices to install and configure an Oracle Real Application Clusters (RAC) Database 11g Release (11.2.0.3) with Oracle Automatic Storage Management (ASM). It is suited for system, storage, and database administrators deploying Oracle RAC Database 11g Release 2 (11.2.0.3) on Red Hat Enterprise Linux 6. It is intended to provide a Red Hat | Oracle reference architecture that focuses on the following tasks:

• Deploying Oracle Grid Infrastructure 11g R2 (11.2.0.3)
• Deploying Oracle RAC Database 11g R2 (11.2.0.3) with shared SAN disks
• Using Oracle ASM disks with udev rules
• Using Oracle ASM disks with Oracle ASMLib (RHEL 6.4 and above)
• Enabling the Oracle RAC Database 11gR2 environment with SELinux

Looking for Deploying Oracle Standalone Database 11g R2 on RHEL6? Visit https://access.redhat.com/site/articles/395013

Attachments

7 Comments

I miss changelog for this document - is it possible to provide it what has changed since last release ? Having that you don't need to read the whole document to know what has changed.

Actually the Changelog can be found at the tar.gz file.

Since this is the first iteration of the Deploying Oracle RAC Database 11g Release 2, the Appendix A: Revision History section will just mention Initial Release. For future revisions, check this section out to see what changes have been made. As for the .tar.gz, if a new tar.gz is released, the CHANGELOG file can be viewed to see what has been changed.

Regards,

Roger

Thanks, for the document. I wrote a short script to get the WWID and Multipath aliases, in order to provide a UDEV-rules file with all informations. Is there a way to distribute it here?

Hi Steven,

Definitely we can incorporate your script! :) Feel free to email refarch-feedback@redhat.com with the details.

Hi,Mr Roger,
In your artical (3.3.6 Setting Shared Memory),
The calculation of SHMMAX, is as follows:
HALF OF TOTAL RAM IN BYTES
For example, on a system with 48 GB of memory the SHMMAX calculation would look as follows:

echo “48 * 1024^3 / 2” | bc

25769803776

I have some question for consult:
RHEL6 use /dev/shm as shared memory,in default,it is half of total memory.But the configuration of /dev/shm is not involved in this artical,this is not necessary?
If so,there is a scene: I want 70% of total memory(10G) for shared memory.What should I do? Two points as follows:
1 sysctl -w kernel.shmmax = 10G * 70%
2 vim /etc/fstab,add " tmpfs /dev/shm tmpfs defaults,size=7G 0 0 " and then "mount -o remount /dev/shm"
Is that right?

Another question:What's the relationship of the shmmax and /dev/shm?

Hi,

The reason that /dev/shm is not involved in the article is because its really only related to when you are using Oracle Automatic Memory Management (AMM), and the preferred method is using Automatic Shared Memory Management (ASMM). The reason AMM is not used is because you cannot use Hugepages with AMM.

From the looks of your questions #2, if you wanted to have /dev/shm that seems correct.

With regards to shmmax, there is a better way to calculate and understand it. It's something I need to update in the existing 11g papers, but exists in my 12c papers. In the 11g papers, I discuss how Oracle provides a formula to calculate shmmax, but if the calculated value is lower than the existing shmmax value, to use the default value provided. For most cases, the default value will always be higher and meet customers needs. However, the real question is when do I need to increase shmmax larger than its default value?

Shared memory allows processes to communicate with each other by placing regions of
memory into memory segments. In the case of Oracle, shared memory segments are used
by the System Global Area (SGA) to store incoming data and control information. The size of
Oracle's SGA impacts the amount of shared memory pages and shared memory segments to
be set within a system. At the time of the reference architecture writing, a RHEL6 install provided a shmmax value of 68719476736 bytes, equivalent to 68GB of memory (this was the default in 6.5, not sure if that has changed since). If the Oracle SGA is larger than the value specified by SHMMAX, then Oracle will be required to create multiple smaller shared memory segments to completely fit Oracle's SGA. This can cause a significant performance penalty, especially in NUMA environments. In an optimal NUMA configuration, a single shared memory segment for Oracle's SGA is created on each NUMA node. If SHMMAX is not properly sized and creates multiple shared memory segments, SHMMAX limitations may keep the system from evenly distributing the shared memory segments across each NUMA node.

In a nutshell, to calculate SHMMAX, figure out the max SGA size for your DBs, and make sure that SHMMAX is larger than the biggest one, set in bytes. Remember, SHMMAX is just telling the OS what is the max size 1 memory shared segment can be. The end goal is to ensure that whatever size Oracle's SGA is, it can all fit in one memory segment. This is controlled by shmmax. It's OK to make this number very large.

Hope that helps,

Roger