ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 11g memory management

11g memory management

原创 Linux操作系统 作者:handfree 时间:2013-10-07 21:17:51 0 删除 编辑
by Patrick Schwanke

During the last versions of Oracle database there have been several step-by-step changes in the way the database manages its memory.

The first step in this series was done in Oracle9i by merging the different process work areas (sort area, hash area etc.) to a single aggregate memory pool, controlled by the server parameter pga_aggregate_target.
With Oracle 10g a similar approach was taken for the shared memory area. The different pools like the buffer cache, shared pool etc. were integrated into a single pool. The corresponding server parameters are sga_target and sga_max_target.

Apart from this automatic management, in both cases it is still possible to manually manage the memory areas or – as a compromise – to set lower limits for some memory areas.

The same holds true for Oracle 11g. Additionally, there is another new option to manage the whole memory requirements of the Oracle instance, i.e. shared memory SGA and process memory PGA, in one single pool with the parameters memory_target and memory_max_target.

When one starts at looking how this is actually realized, it is a small surprise. In any database release up to version 10g Oracle makes use of the so-called System V-style. shared memory. Thus it always was and is possible to verify existence and size of the shared memory area by issuing Unix commands like ipcs, either manually or script-driven.

[root@ora11gr2 ~]# ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status 
0x00000000 65536 oracle 600 393216 2 dest 
0x00000000 98305 oracle 600 393216 2 dest 
0x00000000 131074 oracle 600 393216 2 dest 
0x00000000 163843 oracle 600 393216 2 dest 
0x00000000 196612 oracle 600 393216 2 dest 
0x00000000 229381 oracle 600 393216 2 dest 
0x00000000 262150 oracle 600 393216 2 dest 0x00000000 294919 oracle 600 393216 2 dest 0x00000000 327688 oracle 600 393216 2 dest 0x75fc1f04 285376521 oracle 660 348127232 34 0x00000000 425994 oracle 600 393216 2 dest

Listing 1: Shared Memory Segments until Oracle10g

The listing shows an SGA with a size of 332MB. The nattch column gives the number of processes sharing this shared memory area – 34 in this case. These are the server processes as well as the background processes like DBWR, LGWR etc. A performance tool like Quest Performance Analysis for Oracle also attaches to the SGA for getting performance data directly from memory, thereby incrementing the process count.

Now, if one switches on automatic memory management (AMM) in an Oracle 11g database by setting memory_target to some value, e.g. 500M, the picture gets completely different:

[root@ora11gr2 ~]# ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status 
0x00000000 65536 oracle 600 393216 2 dest 
0x00000000 98305 oracle 600 393216 2 dest 0x00000000 131074 oracle 600 393216 2 dest 0x00000000 163843 oracle 600 393216 2 dest 0x00000000 196612 oracle 600 393216 2 dest 0x00000000 229381 oracle 600 393216 2 dest 0x00000000 262150 oracle 600 393216 2 dest 0x00000000 294919 oracle 600 393216 2 dest 0x00000000 327688 oracle 600 393216 2 dest 0x00000000 285442057 oracle 660 4096 0 0x00000000 425994 oracle 600 393216 2 dest 0x00000000 285474827 oracle 660 4096 0 0x75fc1f04 285507596 oracle 660 4096 0

Listing 2: Shared Memory Segments in Oracle 11g

Here the SGA shows up with a size of only 4KB and without any attached process.

What Happened?

The background for this different behavior. is that – with System V-style. shared memory management – it is not easily possible to move memory between the monolithic shared memory segment and the private memory areas (PGA) of the processes. But exactly this was one of the objectives for Oracle 11g. Therefore, to make this possible, whenever one uses memory_target the Oracle instance internally changes to another management form. offered by the operating system, the so-called Posix-Style. shared memory management.

This allows breaking up the shared memory into small portions which are called “granules” by Oracle. Each granule can then easily be de-allocated from SGA and reallocated into PGA or vice versa, effectively moving memory between SGA and PGA. Unfortunately, Posix-managed shared memory is not visible with the mentioned tools like ipcs. Instead of that it is managed by the means of a virtual file system called shmfs or tmpfs. On Linux-based systems this is most often mounted on /dev/shm. So the current Posix-style. shared memory usage is identical with the used space in this virtual file system.

[oracle@ora11gr2 ~]$ df -k /dev/shm
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 614400 335688 278712 55% /dev/shm

Listing 3: Shared Memory virtual file system

A look into the directory /dev/shm also shows the granules. Depending on the overall memory size each granule is either 4MB or 16MB in size. Some granules have size 0, indicating that this memory area is currently attached to PGA, but could be called back into SGA at any time.

[oracle@ora11gr2 ~]$ df ls -la /dev/shm

-rw-r----- 1 oracle oinstall 4194304 Jan 5 19:51 ora_PS112_285474827_68
-rw-r----- 1 oracle oinstall 4194304 Jan 5 19:51 ora_PS112_285474827_69
-rw-r----- 1 oracle oinstall 0 Jan 5 19:51 ora_PS112_285474827_7
-rw-r----- 1 oracle oinstall 4194304 Jan 5 19:51 ora_PS112_285474827_70

Listing 4: Directory /dev/shm

Useful tools for Troubleshooting in this environment are the OS commands fuser and pmap. 
fuser takes a shared memory granule (i.e. a file in the virtual directory) as argument and lists all processes accessing this granule, i.e. all processes attached to this shared memory segment, e.g.:

sbin/fuser -v /dev/shm/ora_PS112_285507596_9
USER PID ACCESS COMMAND
oracle 22848 ....m oracle
oracle 22850 ....m oracle
oracle 22854 ....m oracle

Listing 5: Process structure

The opposite direction is covered by by pmap which lists the shared memory granules belonging to a given process.

For the database administrator it is important to know that, prior to starting the Oracle instance, the underlying virtual file system has to be sized accordingly. The determining factor here is the value of the memory_max_target parameter. If not set explicitly it defaults to the memory_target parameter value.

At first try the Oracle instance often gives back the following error message:

SQL> startup 
ORA-00845: MEMORY_TARGET not supported on this system

Listing 6: Error message when starting the Oracle instance

Contrary to the wording of this error message the root cause is not at all a lack of support for memory_target. A quick look into Oracle’s alert log gives a better description of what happened:

[oracle@ora11gr2 trace]$ tail -3 alert_PS112.log

Starting ORACLE instance (normal)

WARNING: You are trying to use the MEMORY_TARGET feature. This feature requires the /dev/shm file system to be mounted for at least 2097152000 bytes. /dev/shm is either not mounted or is mounted with available space less than this size. Please fix this so that MEMORY_TARGET can work as expected. Current available is 629145600 and used is 0 bytes. Ensure that the mount point is /dev/shm for this directory.

memory_target needs larger /dev/shm

Listing 7: Error message in alert log

The solution is to un-mount the file system /dev/shm and re-mount it with a higher size, which is specified by the mount parameter size.

[root@ora11gr2 ~]# umount /dev/shm
# Adjust entry in /etc/fstab, e.g.:
# tmpfs /dev/shm tmpfs size=2000m 0 0
[root@ora11gr2 ~]# mount /dev/shm

Listing 8: Change of /dev/shm file system

Summary

In the course of introducing Automatic Memory Management (AMM) in version 11g, Oracle performed a major change in the internal memory management on OS level. This affects the prerequisites for setting up a database. Also it has an impact on troubleshooting processes, e.g. other diagnostic tools and OS commands have to be used.

Nevertheless, as soon as one gets an understanding for the How and Why of the changes, the new behavior. is quite reasonable and consistent.

source: http://www.toadworld.com/Newsletter/TWPIPELINEMay2009/PIPEMay09Oracle/tabid/575/Default.aspx

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/133958/viewspace-773833/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2013-10-07

  • 博文量
    2
  • 访问量
    13320