11g中自动内存管理(Automatic Memory Management ,amm), 令dba在数据库内存配置的相关工作更加简单. AMM现在将SGA与PGA整合到一起管理,而您只需要设置memory_target参数即可限定Oracle将使用到的内存尺寸,Oracle将自动分配这些内存空间.
您一定很困惑Oracle在unix平台上是如何对共享的sga内存空间与私有的pga内存空间进行切换的?这意味着Oracle需要经常释放sga中的部分内存以便允许pga去使用它们.传统的sys V 使用的共享内存shm接口不具备如此的灵活性.我们来看看Oracle是如何做到的?
先来获取我们需要的11g实例共享内存id(shared memory id)
[oracle@rh2 ~]$ sysresv // 该命令需要设置了正确的LD_LIBRARY_PATH
IPC Resources for ORACLE_SID “T11” :
Shared Memory:
ID KEY
65537 0x95c84bb8
Semaphores:
ID KEY
327681 0xdf521034
Oracle Instance alive for sid “T11”
试着找出对应的sys V共享内存段：
[oracle@rh2 ~]$ ipcs -m
—— Shared Memory Segments ——–
key shmid owner perms bytes nattch status
0x95c84bb8 65537 oracle 660 4096 0
对应的存在着共享内存段，但该段很小只有 4096 byte哦，既然Oracle不再把sga放到共享段中，那藏到哪里去了呢？
我们接下来检查Oracle实例进程的内存影射状况．
[oracle@rh2 ~]$ pmap `pgrep -f lgwr`|less
14889: ora_lgwr_T11
0000000000400000 155016K r-x– /usr/oracle/product/11g/db_1/bin/oracle
0000000009c62000 12404K rw— /usr/oracle/product/11g/db_1/bin/oracle
000000000a87f000 732K rwx– [ anon ]
0000000060000000 4K r–s- /dev/shm/ora_T11_65537_0
0000000060001000 16380K rw-s- /dev/shm/ora_T11_65537_0
0000000061000000 16384K rw-s- /dev/shm/ora_T11_65537_1
0000000062000000 16384K rw-s- /dev/shm/ora_T11_65537_2
0000000063000000 16384K rw-s- /dev/shm/ora_T11_65537_3
0000000064000000 16384K rw-s- /dev/shm/ora_T11_65537_4
0000000065000000 16384K rw-s- /dev/shm/ora_T11_65537_5
0000000066000000 16384K rw-s- /dev/shm/ora_T11_65537_6
0000000067000000 16384K rw-s- /dev/shm/ora_T11_65537_7
0000000068000000 16384K rw-s- /dev/shm/ora_T11_65537_8
0000000069000000 16384K rw-s- /dev/shm/ora_T11_65537_9
000000006a000000 16384K rw-s- /dev/shm/ora_T11_65537_10
000000006b000000 16384K rw-s- /dev/shm/ora_T11_65537_11
000000006c000000 16384K rw-s- /dev/shm/ora_T11_65537_12
000000006d000000 16384K rw-s- /dev/shm/ora_T11_65537_13
000000006e000000 16384K rw-s- /dev/shm/ora_T11_65537_14
000000006f000000 16384K rw-s- /dev/shm/ora_T11_65537_15
0000000070000000 16384K rw-s- /dev/shm/ora_T11_65537_16
0000000071000000 16384K rw-s- /dev/shm/ora_T11_65537_17
0000000072000000 16384K rw-s- /dev/shm/ora_T11_65537_18
0000000073000000 16384K rw-s- /dev/shm/ora_T11_65537_19
0000000074000000 16384K rw-s- /dev/shm/ora_T11_65537_20
0000000075000000 16384K rw-s- /dev/shm/ora_T11_65537_21
0000000076000000 16384K rw-s- /dev/shm/ora_T11_65537_22
0000000077000000 16384K rw-s- /dev/shm/ora_T11_65537_23
0000000078000000 16384K rw-s- /dev/shm/ora_T11_65537_24
0000000079000000 16384K rw-s- /dev/shm/ora_T11_65537_25
000000007a000000 16384K rw-s- /dev/shm/ora_T11_65537_26
000000007b000000 16384K rw-s- /dev/shm/ora_T11_65537_27
000000007c000000 16384K rw-s- /dev/shm/ora_T11_65537_28
000000007d000000 16384K rw-s- /dev/shm/ora_T11_65537_29
000000007e000000 16384K rw-s- /dev/shm/ora_T11_65537_30
000000007f000000 16384K rw-s- /dev/shm/ora_T11_65537_31
0000000080000000 16384K rw-s- /dev/shm/ora_T11_65537_32
0000000081000000 16384K rw-s- /dev/shm/ora_T11_65537_33
0000000082000000 16384K rw-s- /dev/shm/ora_T11_65537_34
0000000083000000 16384K rw-s- /dev/shm/ora_T11_65537_35
0000000084000000 16384K rw-s- /dev/shm/ora_T11_65537_36
0000000085000000 16384K rw-s- /dev/shm/ora_T11_65537_37
0000000086000000 16384K rw-s- /dev/shm/ora_T11_65537_38
0000000087000000 16384K rw-s- /dev/shm/ora_T11_65537_39
0000000088000000 16384K rw-s- /dev/shm/ora_T11_65537_40
0000000089000000 16384K rw-s- /dev/shm/ora_T11_65537_41
000000008a000000 16384K rw-s- /dev/shm/ora_T11_65537_42
．．．．．．．．．．．．
0000003e79109000 4K rw— /lib64/tls/librt-2.3.4.so
0000003e7910a000 64K rw— [ anon ]
0000003e79600000 84K r-x– /lib64/libnsl-2.3.4.so
0000003e79615000 1020K —– /lib64/libnsl-2.3.4.so
0000003e79714000 4K r—- /lib64/libnsl-2.3.4.so
0000003e79715000 4K rw— /lib64/libnsl-2.3.4.so
0000003e79716000 8K rw— [ anon ]
0000007fbfff3000 52K rwx– [ stack ]
ffffffffff600000 4K r-x– [ anon ]
total 2497724K
pmap工具诠释了进程相关共享内存的情况，可以看到许多个16MB的＂文件＂对应了Oracle服务进程的空间地址．这是linux上POSIX风格的共享内存管理模式，使用＂文件＂形式包含共享内存段．
借助于将sga分割成许多块，Oracle可以很容易地把sga部分内存返回给OS，而服务器进程即可以利用到这些内存．（当memory_max_target>1024时，颗粒为16MB,否则为4MB)．
接下来我们测试下Oracle是如何释放部分sga内存的．
对比实例启动前后：
启动前：
[oracle@rh2 ~]$ ls -l /dev/shm
总用量 0
启动后：
[oracle@rh2 ~]$ ls -l /dev/shm
总用量 1373704
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_0
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_1
-rw-r—– 1 oracle oinstall 0 9月 27 18:59 ora_T11_327680_10
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_100
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_101
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_102
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_103
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_104
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_105
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_106
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_107
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_108
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_109
-rw-r—– 1 oracle oinstall 0 9月 27 18:59 ora_T11_327680_11
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_110
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_111
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_112
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_113
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_114
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_115
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_116
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_117
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_118
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_119
-rw-r—– 1 oracle oinstall 0 9月 27 18:59 ora_T11_327680_12
可以看到启动后出现的16MB文件形式共享内存中部分大小为０，这些块被选出当发生内存交换时来被’destory’．使用pmap工具仍可以看到该部分影射，而实际上已经被Oracle释放了．
现在我们加大pga，观察其交换情况．
SQL> alter system set pga_aggregate_target=1900M ;
System altered.
[oracle@rh2 ~]$ ls -l /dev/shm
总用量 289984
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_0
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_1
-rw-r—– 1 oracle oinstall 0 9月 27 18:59 ora_T11_327680_10
-rw-r—– 1 oracle oinstall 0 9月 27 19:09 ora_T11_327680_100
-rw-r—– 1 oracle oinstall 0 9月 27 19:09 ora_T11_327680_101
-rw-r—– 1 oracle oinstall 0 9月 27 19:09 ora_T11_327680_102
-rw-r—– 1 oracle oinstall 0 9月 27 19:09 ora_T11_327680_103
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_104
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_105
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_106
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_107
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_108
-rw-r—– 1 oracle oinstall 16777216 9月 27 18:59 ora_T11_327680_109
-rw-r—– 1 oracle oinstall 0 9月 27 18:59 ora_T11_327680_11
-rw-r—– 1 oracle oinstall 0 9月 27 19:09 ora_T11_327680_110
-rw-r—– 1 oracle oinstall 0 9月 27 19:09 ora_T11_327680_111
-rw-r—– 1 oracle oinstall 0 9月 27 19:09 ora_T11_327680_112
-rw-r—– 1 oracle oinstall 0 9月 27 19:09 ora_T11_327680_113
-rw-r—– 1 oracle oinstall 0 9月 27 19:09 ora_T11_327680_114
-rw-r—– 1 oracle oinstall 0 9月 27 19:09 ora_T11_327680_115
-rw-r—– 1 oracle oinstall 0 9月 27 19:09 ora_T11_327680_116
-rw-r—– 1 oracle oinstall 0 9月 27 19:09 ora_T11_327680_117
-rw-r—– 1 oracle oinstall 0 9月 27 19:09 ora_T11_327680_118
-rw-r—– 1 oracle oinstall 0 9月 27 19:09 ora_T11_327680_119
-rw-r—– 1 oracle oinstall 0 9月 27 18:59 ora_T11_327680_12
-rw-r—– 1 oracle oinstall 0 9月 27 19:09 ora_T11_327680_120
-rw-r—– 1 oracle oinstall 0 9月 27 19:09 ora_T11_327680_121
可以看到出现了大量size为0的＂文件＂，期许的交换出现了．
可见在11g中Oracle采用了新的共享内存实现方式，区别于旧的＂一块式＂共享段，更为灵活了．
ORA-00845 When Starting Up An 11g Instance With AMM Configured
Applies to:
Oracle Server – Enterprise Edition – Version: 11.1.0.6 to 11.2.0.2.0 – Release: 11.1 to 11.2
Linux x86
Linux x86-64
Symptoms
On a Linux system, trying to start up an 11g instance could fail with the following error:
ORA-845: MEMORY_TARGET not supported on this system
In the alert log, you could or could not see the below messages:
ORA-04031 errors
OR
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 <size> bytes.The /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 <size> and used is <size> bytes.memory_target needs larger /dev/shm
If ORA-04031 is seen in the alert log, sometimes you can not establish new connections due to this problem.
Changes
Installed 11g, or created a new database on 11g and is starting to use the AMM (Automatic Memory Management) feature.
Cause
This feature requires the /dev/shm file system to be mounted for at least %llu bytes.
/dev/shm is either not mounted or is mounted with available space less than this size.
Explanation:
AMM (Automatic Memory Management) is a new feature in 11 which manages both SGA and PGA.
MEMORY_TARGET is used instead of SGA_TARGET and MEMORY_MAX_TARGET is used instead of SGA_MAX_SIZE (defaults to MEMORY_TARGET ).
It uses /dev/shm on Linux. If max_target set over /dev/shm size, you get the error messages.
Solution
1. If you are installing Oracle 11g on a Linux system, note that Memory Size (SGA and PGA), which sets
the initialization parameter MEMORY_TARGET or MEMORY_MAX_TARGET, cannot be greater than the shared memory filesystem (/dev/shm) on your operating system. To resolve the current error, increase the /dev/shm file size. For example:
# mount -t tmpfs shmfs -o size=7g /dev/shm
Also, to make this change persistent across system restarts, add an entry in /etc/fstab similar to the following:
shmfs /dev/shm tmpfs size=7g 0
2. This error may also occur if /dev/shm is not properly mounted. Make sure your df output is similar to the following:
$ df -k
Filesystem 1K-blocks Used Available Use% Mounted on
…
shmfs 6291456 832356 5459100 14% /dev/shm
3. If configuring AMM is not possible due to lack of space on /dev/shm mount point, you can configure ASMM instead of AMM, i.e. set SGA_TARGET, SGA_MAX_SIZE and PGA_AGGREGATE_TARGET instead of MEMORY_TARGET
HugePages and Oracle Database 11g Automatic Memory Management (AMM) on Linux
Applies to:
Oracle Server – Enterprise Edition – Version: 11.1.0.6 and later [Release: 11.1 and later ]
Linux OS – Version: 2.6 and later ]
Linux x86
IBM: Linux on System z
IBM: Linux on POWER Systems
IBM S/390 Based Linux (31-bit)
Linux x86-64
Linux Itanium
Purpose
This document discusses the interoperability of the Automatic Memory Management (AMM) feature introduced by Oracle DB 11g and the HugePages (HugeTLB) feature of the Linux OS kernel.
Scope and Application
This document is to be used by Linux system administrators and Oracle database administrators that work with Oracle Database Server 11g on Linux Operating System.
HugePages and Oracle Database 11g Automatic Memory Management (AMM) on Linux
The 11g AMM feature is enabled by the MEMORY_TARGET / MEMORY_MAX_TARGET instance initialization parameters (see Note 460506.1 for further information). That is also the case with a default database instance created using Database Configuration Assistant (DBCA).
With AMM all SGA memory is allocated by creating files under /dev/shm. When Oracle DB does SGA allocations that way HugePages are not reserved/used. The use of AMM is absolutely incompatible with HugePages.
Please also note that ramfs (instead of tmpfs mount over /dev/shm) is not supported for AMM at all. With AMM the Oracle database needs to grow and reduce the size of SGA dynamically. This is not possible with ramfs where it possible and supported with tmpfs (which is the default for the OS installation).
If you want to use HugePages make sure that both MEMORY_TARGET / MEMORY_MAX_TARGET initialization parameters are disabled (set to 0) for the database instance.(See also Oracle® Database Administrator’s Guide 11g)
/dev/shm Filled Up With Files In Format JOXSHM_EXT_xxx_SID_xxx
Applies to:
Oracle Server – Enterprise Edition – Version: 11.1.0.6 to 11.1.0.7 – Release: 11.1 to 11.1
Information in this document applies to any platform.
Symptoms
/dev/shm is being filled up with files in the format JOXSHM_EXT_???_SID_???? and eventually causing the DB to restart. Oracle is not automatically cleaning those files.
Please note that it is OS specific whether such segments are visible on a filesystem or not, and if so where they get placed. eg: On Solaris shm_open() internally creates a file in /tmp with the prefix .SHMD and less the leading “/” from the shm_open argument whereas on Linux it creates an entry in /dev/shm
Changes
Most probably the database has not been closed cleanly.
Cause
This issue has been described in
<< Bug.6820987 >> /DEV/SHM IS NOT BEING CLEANED UP ON NODE 1
which was closed as duplicate of
Unpulished Bug.6662381 JOXSHM_EXT LEFT AFTER SHUTDOWN IMMEDIATE
which was closed as duplicate of
Unpublished Bug 9021155 APPSST GSI 11G: NATIVE PL/SQL CACHE FILES MAKES /TMP SLOW AND UNUSABLE
It has been determined by development that the cause of such issue is due to the fact that the database has not be closed cleanly at some point in time.
Solution
1. The unpublished Bug 9021155 has been fixed in Oracle 12.1 which has not been released yet at the time this note was created therefore you can not upgrade to 12.1 yet. Instead, you can apply the one off Patch 9021155 is available on My Oracle Support for your Oracle version and platform.
OR
2. Use one of the workarounds provided below:
a. Rebooting the server from time to time as this clears those files
OR
b. In 11.1.0.7 the “id” part of the name is the shared memory id of the shared memory for the instance.
eg: “ipcs -ma” ID column value is the “id” part of the name. This is not documented / guaranteed but does
give a way to see if a file corresponds to a running instance. For the files that you have you should first check
if the tail number matches to a valid SHM ID (as reported by ipcs -ma) .If not then the files are probably stale old copies and you can go ahead and delete those files. If so then those files are related to a currently running instance and deleting those files can lead to unpredictable results. Instead you can add the following code before you startup or after you shutdown the instance:
rm -f /dev/shm/JOXSHM_EXT_*_<instance name>_*
rm -f /dev/shm/PESHM_EXT_*_<instance name>_*
Again please note that the directories referenced above are OS specific and should be modified according to your OS. The above applies to Linux.