Re: When we need to remove Oracle share memory ID?

From: newbie <new_at_new.com>
Date: Tue, 19 Aug 2008 01:00:35 +0800
Message-ID: <g8c9ro$tem$1@news.cn99.com>


Thanks for help.

Yes, there is just one oracle instance running on the system.

How about kernel parameters?

spfileprod.ora:

*.background_dump_dest='/oracle/admin/prod/bdump'
*.compatible='9.2.0.0.0'
*.control_files='/oradata/prod/control01.ctl','/oralog1/prod/control02.ctl','/oralog2/prod/control03.ctl'
*.core_dump_dest='/oracle/admin/prod/cdump'
*.db_block_size=16384
*.db_cache_size=4000000000
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='prod'
*.fast_start_mttr_target=300
*.hash_join_enabled=TRUE
*.instance_name='prod'
*.java_pool_size=33554432
*.job_queue_processes=100
*.large_pool_size=268435456
*.log_archive_dest_1='LOCATION=/oraarch/prod'
*.log_archive_format='%t_%s.dbf'
*.log_archive_start=true
*.open_cursors=300
*.pga_aggregate_target=1000000000
*.processes=150
*.query_rewrite_enabled='FALSE'
*.remote_login_passwordfile='EXCLUSIVE'
*.shared_pool_size=805306368
*.sort_area_size=1048576
*.star_transformation_enabled='FALSE'
*.timed_statistics=TRUE
*.undo_management='AUTO'
*.undo_retention=10800
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/oracle/admin/prod/udump'

$ more top.log
load averages:  1.75,  1.71,  1.33;                    up 1+07:44:34 
00:46:26
109 processes: 107 sleeping, 2 on cpu

Memory: 16G phys mem, 4961M free mem, 10G swap, 10G free swap

   PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND

  6972 oracle    15  59    0   11G 9539M sleep   22:36  0.00% oracle
   561 oracle    11  59    0   11G 9527M sleep   15:39  0.00% oracle
   600 oracle    11  59    0   11G 9539M sleep   15:34  0.00% oracle
   559 oracle   198  59    0   11G 9532M sleep   14:27  0.00% oracle
   618 oracle    11  59    0   11G 9536M sleep   11:35  0.00% oracle
 17249 oracle     1  20    0   12G 9625M cpu     11:28  0.00% oracle
   606 oracle    11  59    0   11G 9539M sleep    7:22  0.00% oracle
   612 oracle    11  59    0   11G 9539M sleep    7:19  0.00% oracle
   630 oracle    11  59    0   11G 9537M sleep    7:14  0.00% oracle
   624 oracle    11  59    0   11G 9537M sleep    7:14  0.00% oracle
   571 oracle    11  54    0   11G 9529M sleep    3:50  0.00% oracle
   457 root       7  59    0 2840K 2560K sleep    1:19  0.00% mibiisa
  7047 oracle     1  59    0   11G 9534M sleep    1:08  0.00% oracle
 18242 oracle    15  32    0   11G 9553M sleep    0:48  0.00% oracle




"hpuxrac" <johnbhurley_at_sbcglobal.net>
??????:8964d501-432f-4872-9564-c8f6541a8155_at_m45g2000hsb.googlegroups.com... On Aug 17, 11:35 am, "newbie" <n..._at_new.com> wrote:
> Hi ,
>
> It's Oracle 9.2.0.8 on Solaris 9.
>
> 1. When do we need to remove those Oracle share memory ID to release more
> memory?
>
> 2. Do following outputs look like normal or abnormal?
>
> Thanks,
> Alan
>
> $ ipcs -am
> IPC status from <running system> as of Sun Aug 17 23:18:53 CST 2008
> T ID KEY MODE OWNER GROUP CREATOR CGROUP
> NATTCH SEGSZ CPID LPID ATIME DTIME CTIME
> Shared Memory:
> m 100 0 --rw-r----- oracle dba oracle dba
> 27 4194304 555 9106 23:18:30 23:18:39 17:06:18
> m 1 0 --rw-r----- oracle dba oracle dba
> 27 3053453312 555 9106 23:18:30 23:18:39 17:06:18
> m 2 0 --rw-r----- oracle dba oracle dba
> 27 2281701376 555 9106 23:18:30 23:18:39 17:06:18
> m 3 0 --rw-r----- oracle dba oracle dba
> 27 3422552064 555 9106 23:18:30 23:18:39 17:06:18
> m 4 0x9751468 --rw-r----- oracle dba oracle dba
> 27 3426746368 555 9106 23:18:30 23:18:39 17:06:18
>
> $ ipcs -am
> IPC status from <running system> as of Sun Aug 17 23:19:05 CST 2008
> T ID KEY MODE OWNER GROUP CREATOR CGROUP
> NATTCH SEGSZ CPID LPID ATIME DTIME CTIME
> Shared Memory:
> m 100 0 --rw-r----- oracle dba oracle dba
> 28 4194304 555 9118 23:19:01 23:18:39 17:06:18
> m 1 0 --rw-r----- oracle dba oracle dba
> 28 3053453312 555 9118 23:19:01 23:18:39 17:06:18
> m 2 0 --rw-r----- oracle dba oracle dba
> 28 2281701376 555 9118 23:19:01 23:18:39 17:06:18
> m 3 0 --rw-r----- oracle dba oracle dba
> 28 3422552064 555 9118 23:19:01 23:18:39 17:06:18
> m 4 0x9751468 --rw-r----- oracle dba oracle dba
> 28 3426746368 555 9118 23:19:01 23:19:01 17:06:18
>
> $ ipcs -am
> IPC status from <running system> as of Sun Aug 17 23:28:50 CST 2008
> T ID KEY MODE OWNER GROUP CREATOR CGROUP
> NATTCH SEGSZ CPID LPID ATIME DTIME CTIME
> Shared Memory:
> m 100 0 --rw-r----- oracle dba oracle dba
> 24 4194304 555 9329 23:28:33 23:28:33 17:06:18
> m 1 0 --rw-r----- oracle dba oracle dba
> 24 3053453312 555 9329 23:28:33 23:28:33 17:06:18
> m 2 0 --rw-r----- oracle dba oracle dba
> 24 2281701376 555 9329 23:28:33 23:28:33 17:06:18
> m 3 0 --rw-r----- oracle dba oracle dba
> 24 3422552064 555 9329 23:28:33 23:28:33 17:06:18
> m 4 0x9751468 --rw-r----- oracle dba oracle dba
> 24 3426746368 555 9329 23:28:33 23:28:33 17:06:18
> $

You only need to remove them when oracle has failed in some unusual manner or something like a kill -9 has occurred. In some cases you need to get rid of the shared memory and semaphore allocations.

In some cases like that as the oracle process(es) terminate they do not remove the shared memory segments created on oracle startup. ( If you have access to metalink then there's some fairly good tech notes from oracle in this area. )

It is fairly unusual anymore for that to happen but yes it can happen. You should do some experimenting on a test system with oracle and kill -9 to make sure you know how to diagnose and clear it up.

Is there just one oracle instance running on that system?

Looks like possibly the kernel parameters are not set correctly and that oracle has had to allocate muliple chunks of shared memory instead of ( more effectively ) getting it all in one chunk. Received on Mon Aug 18 2008 - 12:00:35 CDT

Original text of this message