Re: When we need to remove Oracle share memory ID?
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:3400: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