Tutoriale Online

Tutoriale Online Invata Online cum se face si cum este corect. Learn Online How Must To Do !

Archive for the ‘Growing the Oracle SGA to 2.7/3.42 GB in x86 RHEL 3/4 Without VLM’ Category

Online Tutoriale Growing the Oracle SGA to 2.7/3.42 GB in x86 RHEL 3/4 Without VLM

Posted by ascultradio on September 3, 2009

Growing the Oracle SGA to 2.7/3.42 GB in x86 RHEL 3/4 Without VLM :

General

Due to 32-bit virtual address limitations workarounds have been implemented in Linux to increase the maximum size for shared memories. A workaround is to lower the Mapped Base Address for shared libraries and the SGA Attach Address for shared memory segments. This enables Oracle to attain an SGA larger than 1.7 GB. To get a better understanding of address mappings in Linux and what Mapped Base Address is, see Linux Memory Layout.

The following example shows how to increase the size of the SGA without a shared memory filesystem. A shared memory filesystem must be used on x86 to increase SGA beyond 3.42 GB, see Configuring Very Large Memory (VLM).

Mapped Base Address for Shared Libraries in RHEL 3 and RHEL 4

In RHEL 3/4 the mapped base for shared libraries does not need to be lowered since this operation is now done automatically.

To verify the mapped base (mapped_base) for shared libraries execute “cat /proc/self/maps” in a shell. The directory “self” in the proc filesytem always points to the current running process which in this example is the cat process:

# cat /etc/redhat-release
Red Hat Enterprise Linux AS release 3 (Taroon Update 6)
# cat /proc/self/maps
00a23000-00a38000 r-xp 00000000 08:09 14930      /lib/ld-2.3.2.so
00a38000-00a39000 rw-p 00015000 08:09 14930      /lib/ld-2.3.2.so
00b33000-00c66000 r-xp 00000000 08:09 69576      /lib/tls/libc-2.3.2.so
00c66000-00c69000 rw-p 00132000 08:09 69576      /lib/tls/libc-2.3.2.so
00c69000-00c6c000 rw-p 00000000 00:00 0
00ee5000-00ee6000 r-xp 00000000 08:09 32532      /etc/libcwait.so
00ee6000-00ee7000 rw-p 00000000 08:09 32532      /etc/libcwait.so
08048000-0804c000 r-xp 00000000 08:09 49318      /bin/cat
0804c000-0804d000 rw-p 00003000 08:09 49318      /bin/cat
099db000-099fc000 rw-p 00000000 00:00 0
b73e7000-b75e7000 r--p 00000000 08:02 313698     /usr/lib/locale/locale-archive
b75e7000-b75e8000 rw-p 00000000 00:00 0
bfff8000-c0000000 rw-p ffffc000 00:00 0
#
# cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 2)
# cat /proc/self/maps
00b68000-00b7d000 r-xp 00000000 03:45 1873128    /lib/ld-2.3.4.so
00b7d000-00b7e000 r--p 00015000 03:45 1873128    /lib/ld-2.3.4.so
00b7e000-00b7f000 rw-p 00016000 03:45 1873128    /lib/ld-2.3.4.so
00b81000-00ca5000 r-xp 00000000 03:45 1938273    /lib/tls/libc-2.3.4.so
00ca5000-00ca6000 r--p 00124000 03:45 1938273    /lib/tls/libc-2.3.4.so
00ca6000-00ca9000 rw-p 00125000 03:45 1938273    /lib/tls/libc-2.3.4.so
00ca9000-00cab000 rw-p 00ca9000 00:00 0
08048000-0804c000 r-xp 00000000 03:45 1531117    /bin/cat
0804c000-0804d000 rw-p 00003000 03:45 1531117    /bin/cat
08fa0000-08fc1000 rw-p 08fa0000 00:00 0
b7df9000-b7ff9000 r--p 00000000 03:45 68493      /usr/lib/locale/locale-archive
b7ff9000-b7ffa000 rw-p b7ff9000 00:00 0
bffa6000-c0000000 rw-p bffa6000 00:00 0
ffffe000-fffff000 ---p 00000000 00:00 0
#

The outputs show that the mapped base is already very low in RHEL 3 and RHEL 4. In the above example shared libraries start at 0x00a23000 (decimal 10629120) in RHEL 3 and 0xb68000 (decimal 11960320) in RHEL 4. This is much lower than 0x40000000 (decimal 1073741824) in RHEL 2.1:

# cat /etc/redhat-release
Red Hat Linux Advanced Server release 2.1AS (Pensacola)
# cat /proc/self/maps
08048000-0804c000 r-xp 00000000 08:08 44885      /bin/cat
0804c000-0804d000 rw-p 00003000 08:08 44885      /bin/cat
0804d000-0804f000 rwxp 00000000 00:00 0
40000000-40016000 r-xp 00000000 08:08 44751      /lib/ld-2.2.4.so
40016000-40017000 rw-p 00015000 08:08 44751      /lib/ld-2.2.4.so
40017000-40018000 rw-p 00000000 00:00 0
40022000-40155000 r-xp 00000000 08:08 47419      /lib/i686/libc-2.2.4.so
40155000-4015a000 rw-p 00132000 08:08 47419      /lib/i686/libc-2.2.4.so
4015a000-4015f000 rw-p 00000000 00:00 0
bffea000-bffee000 rwxp ffffd000 00:00 0
#

The above mappings show that the Mapped Base Address does not have to be lowered in RHEL 3/4 to gain more SGA space.

Oracle 10g SGA Sizes in RHEL 3 and RHEL 4

The following table shows how large the Oracle 10g SGA can be configured in RHEL 3/4 without using a shared memory filesystem. Shared memory filesystems for the SGA are covered at Configuring Very Large Memory (VLM).

RHEL 3/4 Kernel 10g DB Version Default Supported SGA
without VLM
Max Supported SGA
without VLM
Comments
smp kernel (x86) 10g Release 1 Up to 1.7 GB Up to 2.7 GB 10g R1 must be relinked to increase the SGA size to approx 2.7 GB
hugemem kernel (x86) 10g Release 1 Up to 2.7 GB Up to 3.42 GB 10g R1 must be relinked to increase the SGA size to approx 3.42 GB
smp kernel (x86) 10g Release 2 Up to ~2.2 GB (*) Up to ~2.2 GB (*) No relink of 10g R2 is necessary but the SGA Attach Address is a little bit higher than in R1
hugemem kernel (x86) 10g Release 2 Up to ~3.3 GB (*) Up to ~3.3 GB (*) No relink of 10g R2 is necessary but the SGA Attach Address is a little bit higher than in R1

In Oracle 10g R2 the SGA size can be increased to approximately 2.7 GB using the smp kernel and to approximately 3.42 GB using the hugemem kernel. The SGA attach address does not have to be changed for that. To accommodate the same SGA sizes in Oracle 10g R1, the SGA Attach Address must be lowered.

(*) In my test scenarios I was not able to startup a 10g R2 database if sga_target was larger than 2350000000 bytes on a smp kernel, and if sga_target was larger than 3550000000 bytes on a hugemem kernel.

NOTE: Lowering the SGA attach address in Oracle restricts the remaining 32-bit address space for Oracle processes. This means that less address space will be available for e.g. PGA memory. If the application uses a lot of PGA memory, then PGA allocations could fail even if there is sufficient free physical memory. Therefore, in certain cases it may be prudent not to change the SGA Attach Address to increase the SGA size but to use Very Large Memory (VLM) instead. Also, if the SGA size is larger but less than 4GB to fit in memory address space, then the Very Large Memory (VLM) solution should be considered first before switching to the hugemem kernel on a small system, unless the system has lots of physical memory. The hugemem kernel is not recommended on systems with less than 8GB of RAM due to some overhead issues in the kernel, see also 32-bit Architecture. If larger SGA sizes are needed than listed in the above table, then Very Large Memory (VLM) must obviously be used on x86 platforms.

Lowering the SGA Attach Address in Oracle 10g

Starting with Oracle 10g R2 the SGA attach address does not have to be lowered for creating larger SGAs. However, Oracle 10g R1 must be relinked for larger SGAs.

The following commands were executed on a 10g R1 database system:

# ps -ef | grep "[o]ra_ckpt"
oracle    3035     1  0 23:21 ?        00:00:00 ora_ckpt_orcl
# cat /proc/3035/maps | grep SYSV
50000000-aa200000 rw-s 00000000 00:04 262144     /SYSV8b1d1510 (deleted)
#

The following commands were executed on a 10g R2 database system:

# ps -ef | grep "[o]ra_ckpt"
oracle    4998     1  0 22:29 ?        00:00:00 ora_ckpt_orcl
# cat /proc/4998/maps | grep SYSV
20000000-f4200000 rw-s 00000000 00:04 4390912    /SYSV950d1f70 (deleted)
#

The output shows that the SGA attach address in 10g R2 is already lowered to 0x20000000 vs. 0x50000000 in 10g R1. This means that Oracle 10g R2 does not have to be relinked for creating larger SGAs. For 10g R1 the SGA attach address must be lowered from 0x50000000 to e.g. 0xe000000. You could also set it a little bit higher like 0x20000000 as its done by default in 10g Release 2.

The following example shows how to lower the SGA attach address to 0xe000000 in 10g R1 (see also Metalink Note:329378.1):

su - oracle
cd $ORACLE_HOME/rdbms/lib
[[ ! -f ksms.s_orig ]] && cp ksms.s ksms.s_orig
genksms -s 0Xe000000 > ksms.s
make -f ins_rdbms.mk ksms.o
make -f ins_rdbms.mk ioracle

For a detailed description of these commands, see Lowering the SGA Attach Address for Shared Memory Segments in Oracle 9i.

You can verify the new lowered SGA attach address by running the following command:

$ objdump -t $ORACLE_HOME/bin/oracle |grep sgabeg
0e000000 l       *ABS*  00000000              sgabeg
$

Now when 10g R1 is restarted the SGA attach address should be at 0xe000000:

# ps -ef | grep "[o]ra_ckpt"
oracle    4998     1  0 22:29 ?        00:00:00 ora_ckpt_orcl
# cat /proc/4998/maps | grep SYSV
0e000000-c1200000 rw-s 00000000 00:04 0          /SYSV8b1d1510 (deleted)
#

Now you should be able to create larger SGAs.

NOTE: If you increase the size of the SGA, essentially using more process address space for the SGA, then less address space will be available for PGA memory. This means that if your application uses a lot of PGA memory, PGA allocations could fail even if you have sufficient RAM. In this case, you need to set the SGA attach address to a higher value which will lower the SGA size.

Advertisements

Posted in Growing the Oracle SGA to 2.7/3.42 GB in x86 RHEL 3/4 Without VLM, Tutoriale RedHat | Tagged: | Leave a Comment »