ORA-00845: MEMORY_TARGET not supported on this system

Hi All,

I Think lot of people might come across the error “ORA-00845”, in 11.2.0.3, when operating your instances with AMM (Automatic Memory Management), like me 😉

Yes, I too have encountered this problem last week when I was trying to re-size my instances which are running on AMM.

I actually have my instance with 6G of MEMORY_MAX_TARGET and now tried increasing it to 8G. I’v done that through a simple alter command

SQL> alter system set memory_max_target=8G scope=spfile;

System altered.

Now when I tried restarting my instance, it’s saying

ORA-00845: MEMORY_TARGET not supported on this system

I was really surprised on seeing this and started digging the documentation. Then I’ve found the actual reason which is,

You need to configure large enough shmfs/tmpfs on /dev/shm device to fit all memory up to MEMORY_MAX_TARGET.

You have to run the below commands as root user to do that.

# umount tmpfs

# mount -t shmfs shmfs -o size=8G /dev/shm
# df -k /dev/shm
Filesystem 1K-blocks Used Available Use% Mounted on
shmfs 10649600 0 10649600 0% /dev/shm

This has surfaced lot more questions in my mind and one of them is, why Oracle is taking the shared memory segments from a file (/dev/shm) !??

I’ve checked immediately the shared memory segments

[user@machine ~]# ipcs -m|grep oracle
0x00000000 3506181 oracle 640 4096 0
0x00000000 3538950 oracle 640 4096 0
0x91d2c260 3571719 oracle 640 4096 0

All the three of the Oracle’s shared memory segments are of 4KB in size. This really looks strange isn’t it? From where my dear Oracle if getting 8GB?

Then I tried this

[user@machine ~]# pmap `pgrep -f lgwr`

10662: ora_lgwr_CSMDB
0000000060000000 4K r-xs- /dev/shm/ora_CSMDB_3506181_0
0000000060001000 4092K rwxs- /dev/shm/ora_CSMDB_3506181_0
0000000060400000 4096K rwxs- /dev/shm/ora_CSMDB_3506181_1
0000000060800000 4096K rwxs- /dev/shm/ora_CSMDB_3506181_2
0000000060c00000 4096K rwxs- /dev/shm/ora_CSMDB_3506181_3
0000000061000000 4096K rwxs- /dev/shm/ora_CSMDB_3506181_4
0000000061400000 4096K rwxs- /dev/shm/ora_CSMDB_3506181_5
0000000061800000 4096K rwxs- /dev/shm/ora_CSMDB_3538950_0
0000000061c00000 4096K rwxs- /dev/shm/ora_CSMDB_3538950_1
0000000062000000 4096K rwxs- /dev/shm/ora_CSMDB_3538950_2
0000000062400000 4096K rwxs- /dev/shm/ora_CSMDB_3538950_3
0000000062800000 4096K rwxs- /dev/shm/ora_CSMDB_3538950_4
0000000062c00000 4096K rwxs- /dev/shm/ora_CSMDB_3538950_5
0000000063000000 4096K rwxs- /dev/shm/ora_CSMDB_3538950_6

……………………………………

……………………………………

and an ls -l /dev/shm also has given me this list as well.

SGA will be allocated in many smaller chunks so that Oracle is easily able to release some parts of SGA memory back to OS and server processes are allowed to increase their aggregate PGA size up to the amount of memory released.

But note that the PGA memory is still completely independent, allocated just by mmap’ing /dev/zero, it doesn’t really have anything to do with shared memory segments

You can see the PGA segments

00007fa3dc106000 1088K rwx– /dev/zero
00007fa3dc216000 1088K rwx– /dev/zero
00007fa3dc326000 1088K rwx– /dev/zero
00007fa3dc436000 832K rwx– /dev/zero
00007fa3dc506000 1088K rwx– /dev/zero
00007fa3dc616000 1088K rwx– /dev/zero
00007fa3dc726000 1088K rwx– /dev/zero
00007fa3dc836000 832K rwx– /dev/zero
00007fa3dc906000 1088K rwx– /dev/zero
00007fa3dca16000 960K rwx– /dev/zero
00007fa3dcb06000 1088K rwx– /dev/zero
00007fa3dcc16000 960K rwx– /dev/zero

So After going through all of this exercise, I came to know that Oracle has taken up the old POSIX-style shared memory allocation schemes where everything including shared memory if a file !!

The main point in putting so much stress on this point is to let you know the administrative implications because of this change.

1.  ipcs -m doesn’t show the full size of these segments anymore. You need to list /dev/shm contents for that.
2. pmap always reports that the memory is mapped even though it doesn not have physical backing storage on /dev/shm device.
3. And most importantly the error mentioned in the title of this post

Finally after reading all this a question should be revolving in your mind. What if we use LOCK_SGA to lock pages in memory?? How oracle be able to swap free memory segments across SGA and PGA in that case???

That’s the reason Oracle won’t allow you to use MEMORY_TARGET and MEMORY_MAX_TARGET if LOCK_SGA is enabled 😉

I always welcome your questions/feedback.

Regards,

CSM