+ Reply to Thread
Results 1 to 5 of 5

When we need to remove Oracle share memory ID?

  1. When we need to remove Oracle share memory ID?

    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 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 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 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
    $



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

    On Aug 17, 11:35*am, "newbie" 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 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 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 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.

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

    On Aug 18, 5:27*am, hpuxrac wrote:

    > 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.


    Unless it's NUMA where several chunks are more effective.

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

    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"
    ??????:8964d501-432f-4872-9564-c8f6541a8155@m45g2000hsb.googlegroups.com...
    On Aug 17, 11:35 am, "newbie" 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 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 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 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.



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

    On Aug 17, 8:35*am, "newbie" 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?


    The easiest way is to shut down the instance. If there are any left,
    it is likely they should be removed. But like hpuxrac suggested, look
    on metalink for docs explaining it, especially look for the ones about
    figuring out the key value, even if some are way old. Note:123322.1,
    Note:1020329.6 and Note:153961.1 are a good start.

    >
    > 2. Do following outputs look like normal or abnormal?


    See http://marist89.blogspot.com/ for one person's journey on that
    question. Remember, there are things that apply to all unix/linux,
    some things that are very platform/hardware specific, and some things
    vary with kernel settings.

    jg
    --
    @home.com is bogus.
    http://forums.oracle.com/forums/thre...32619&tstart=0



+ Reply to Thread