Re: Strange error when resizing MEMORY_TARGET
Date: Thu, 17 Jan 2013 15:24:04 +1000
Message-ID: <50F78AF4.7010704_at_tpg.com.au>
On Solaris /dev/shm does not exist. Instead Oracle uses DISM, which works pretty much the same it seems. At startup all memory up to memory_max_target is allocated in SWAP and the used memory is allocated again in resident memory. Ultimately one can end up with the database occupying 2 * max_memory_target in virtual memory. In my experience, if AMM is configured (and possibly even if it's not), the instance will not even start if swap is too small.
I may have hit on the part that needs shrinking, though. Using pmap on the ora_dism_MYDB process, I can see that dism memory chunks up to the size of the SGA_TARGET are locked (almost - 122M is missing), and the remaining variable memory (dism shmid 0xa000074), except for one 4M block, is gathered in one large 15G chunk:
$ sudo pmap -xs 3763|grep 'dism shmid'|awk 'BEGIN{ tot=0; tl=0;} { tot += $2;tl += $5; print $0;} END{ print "Total: "tot" Kb - Locked: "tl" Kb" ; } '
Address Kbytes RSS Anon Locked Pgsz Mode
Mapped File
0000000380000000 49152 49152 - 4096 4M rwxs- [
dism shmid=0xa000073 ]
0000000383000000 36864 - - - - rwxs- [
dism shmid=0xa000073 ]
0000000385400000 45056 45056 - 45056 4M rwxs- [
dism shmid=0xa000073 ]
00000003C0000000 16187392 - - - - rwxs- [
dism shmid=0xa000074 ]
000000079C000000 3280896 3280896 - 3280896 4M rwxs- [
dism shmid=0xa000074 ]
0000000864400000 61440 61440 - 61440 - rwxs- [
dism shmid=0xa000074 ]
0000000868000000 69632 69632 - 69632 4M rwxs- [
dism shmid=0xa000074 ]
000000086C400000 16384 16384 - 16384 - rwxs- [
dism shmid=0xa000074 ]
000000086D400000 651264 651264 - 651264 4M rwxs- [
dism shmid=0xa000074 ]
0000000895000000 49152 49152 - 49152 - rwxs- [
dism shmid=0xa000074 ]
0000000898000000 61440 61440 - 61440 4M rwxs- [
dism shmid=0xa000074 ]
000000089BC00000 4096 4096 - 4096 - rwxs- [
dism shmid=0xa000074 ]
000000089C000000 53248 53248 - 53248 4M rwxs- [
dism shmid=0xa000074 ]
000000089F400000 12288 12288 - 12288 - rwxs- [
dism shmid=0xa000074 ]
00000008A0000000 135168 135168 - 135168 4M rwxs- [
dism shmid=0xa000074 ]
00000008A8400000 8192 8192 - 8192 - rwxs- [
dism shmid=0xa000074 ]
00000008A8C00000 57344 57344 - 57344 4M rwxs- [
dism shmid=0xa000074 ]
00000008AC400000 20480 20480 - 20480 - rwxs- [
dism shmid=0xa000074 ]
00000008AD800000 45056 45056 - 45056 4M rwxs- [
dism shmid=0xa000074 ]
00000008B0400000 4096 4096 - 4096 - rwxs- [
dism shmid=0xa000074 ]
00000008B0800000 118784 118784 - 118784 4M rwxs- [
dism shmid=0xa000074 ]
00000008B7C00000 4096 4096 - 4096 - rwxs- [
dism shmid=0xa000074 ]
00000008C0000000 4096 4096 - - 4M rwxs- [
dism shmid=0xa000075 ]
Total: 20975616 Kb - Locked: 4702208 Kb
If I am correct, that chunk is used to allocate PGA memory from? The size is exactly the size that Oracle reports as free dynamic memory:
select * from v$sga_dynamic_free_memory;
CURRENT_SIZE
16,575,889,408
1 row selected.
Since all other SGA memory is allocated as small chunks, it stands to reason that Oracle wants to split a part off this memory segment when allocating newmemory to the SGA (by default 60% of new memory goes to the SGA according to doc id 443746.1). If it is in use for the PGA, that would probably fail. The weak point in my reasoning is that I can't think of a reason why Oracle would want to do this. Certainly not to lock the new segment in memory, as DISM allows discrete parts of the segment to be locked. For example the firstsegment (at 0000000380000000) in the table above is 48MB, but only 4MB is locked.
Anyone with more in-depth Solaris knowledge then I can shed some light on this?
Cheers,
Tony
On 17/01/13 8:17 AM, CRISLER, JON A wrote: I don't work on Solaris that much,but on Linux this would be mapped against /dev/shm- if /dev/shm was onlyset to less than 20gb you would run into odd errors. Also, are you tryingto mix hugepages and ASMM together? Perhaps there is a limit and its not allowing enough hugepages to be allocated. In linux you cannot mix hugepages and /dev/shm together but I think you can in Solaris. -----OriginalMessage----- From: oracle-l-bounce_at_freelists.org[1] [mailto:oracle-l-bounce_at_freelists.org[2]] On Behalf Of De DBA Sent: Tuesday, January 15, 2013 9:01 PM To: Oracle Discussion List Subject: Re: Strange error when resizing MEMORY_TARGET Thanks Han. Unfortunately that did not work. I set all targets to the exact value that they currently occupy, i.e.: shared pool = 1280M large pool = 128M streams pool = 128M java pool = 256M pga_aggregate_target = 2496M sga_target = 4672M db_cache_size = 2752M Settingmemory_target to 16G and even to 20G ( i.e. memory_max_target) still gives the same error "ORA-00846: could not shrink MEMORY_TARGET to specified value" :( Cheers, Tony On 16/01/13 11:16 AM, Xie, Han wrote: Hi Tony, Oracle normally gives all new memory to default buffer cache, then dynamically adjust other components later. What is your shared_pool_size parameter value please? Is it possible that shared_pool has grown, now oracle wants/needs to shrink it back to its parameter size first before add new memory? My 2 cents.Cheers, Han <snip due to overquoting> -- http://www.freelists.org/webpage/oracle-l[3] -- http://www.freelists.org/webpage/oracle-l[4]
- Links --- 1 mailto:oracle-l-bounce_at_freelists.org 2 mailto:oracle-l-bounce_at_freelists.org 3 http://www.freelists.org/webpage/oracle-l 4 http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l