The case of Oracle Study-- viewing the "strange phenomenon" of shared memory through IPCS

The case of Oracle Study-- viewing the "strange phenomenon" of shared memory through IPCS

Looking at the shared memory through the ipcs command in the Oracle 11gR2 environment, I found that only 4096Bytes was allocated to the Oracle, but this problem was never found in the Oracle 10g environment!

[root@rh7] # ipcs-a-Shared Memory Segments-key shmid owner perms bytes nattch status0x00000000 0 root 644 52 20x00000000 32769 root 644 16384 20x00000000 65538 root 644 268 20x00000000 98307 gdm 600 393216 2 dest0x00000000 131076 Gdm 393216 2 dest0x00000000 163845 gdm 393216 2 dest0x00000000 196614 gdm 600393216 2 dest0x00000000 229383 gdm 600393216 2 dest0x4b4218ec 557064 oracle 660 4096-Semaphore Arrays-key semid owner perms Nsems0x00000000 0 root 600 10x00000000 98305 root 98305 10x000000a7 327682 root 600 10xbe61d9cc 983043 oracle 660 154-Message Queues-key msqid owner perms used-bytes messages

Database version:

16:27:09 SYS@ test3 > select * from v$version BANNER----Oracle Database 11g Enterprise Edition Release 11.2.0.1.0-ProductionPL/SQL Release 11.2.0.1.0-ProductionCORE 11.2.0.1 .0 ProductionTNS for Linux: Version 11.2.0.1.0-ProductionNLSRTL Version 11.2.0.1.0-Production

Oraccle 11g realizes automatic memory management through the following two parameters:

16:27:19 SYS@ test3 > show parameter memNAME TYPE VALUE---hi_shared_memory_address Integer 0memory_max_target big integer 300Mmemory_target big integer 300Mshared_memory_address integer 0

1. Does the parameter memory_max_target have anything to do with it? Set it to 0 and restart the database.

16:28:11 SYS@ test3 > alter system set memory_target=0 System altered.16:36:44 SYS@ test3 > show parameter memNAME TYPE VALUE -hi_shared_memory_address integer 0memory_max_target big integer 300Mmemory_target big integer 0shared_memory_address integer 016 virtual 30 51 SYS@ test3 > startup force ORACLE instance started.Total System Global Area 313860096 bytesFixed Size 1336232 bytesVariable Size 205524056 bytesDatabase Buffers 100663296 bytesRedo Buffers 6336512 bytesDatabase mounted.Database opened.

Take a look at shared memory:

[oracle@rh7] $ipcs-a-Shared Memory Segments-key shmid owner perms bytes nattch status0x00000000 0 root 644 52 20x00000000 32769 root 644 16384 20x00000000 65538 root 644 268 20x4b4218ec 622600 oracle 660 4096-Semaphore Arrays -key semid owner perms nsems0xbe61d9cc 1114115 oracle 660 154-Message Queues-key msqid owner perms used-bytes messages

It is found that the shared memory allocated to Oracle is still very small, and it does not seem to be a problem with the memory_target parameter!

2. Try to adjust the memory_max_target parameter to restore it to the system default value:

16:39:49 SYS@ test3 > alter system set sga_max_size=300m scope=spfile;System altered.16:40:06 SYS@ test3 > alter system reset memory_max_target scope=spfile sid='*';System altered.16:40:40 SYS@ test3 > startup force nomount ORACLE instance started.Total System Global Area 313860096 bytesFixed Size 1336232 bytesVariable Size 205524056 bytesDatabase Buffers 100663296 bytesRedo Buffers 6336512 bytes16:40:52 SYS@ test3 > show parameter memNAME TYPE VALUE-- -hi_shared_memory_address integer 0memory_max_target big integer 0memory_target big integer 0shared_memory _ address integer 016 virtual 40 SYS@ test3 59 SYS@ test3 > show parameter sgaNAME TYPE VALUE -lock_sga boolean FALSEpre_page_sga boolean FALSEsga_max_size big integer 300Msga_target big integer 180m

View system shared memory:

[oracle@rh7] $ipcs-a-Shared Memory Segments-key shmid owner perms bytes nattch status0x00000000 0 root 644 52 20x00000000 32769 root 644 16384 20x00000000 65538 root 644 268 20x4b4218ec 884744 oracle 660 316669952 16-Semaphore Arrays-- -key semid owner perms nsems0xbe61d9cc 1638403 oracle 660 154-Message Queues-key msqid owner perms used-bytes messages

It seems that the reason for setting the memory_max_target parameter is that the memory allocated to Oracle is 4096Bytes!