STRAY TEMPORARY SEGMENT CLEANUP

제품 : ORACLE SERVER
작성날짜 : 2003-07-30
STRAY TEMPORARY SEGMENT CLEANUP
===============================
- Introduction
Oracle 7의 어떤 버전에서는 temporary segment가 release되지 않고 남아 있는
경우가 있다. 여기서는 이러한 temporary segment를 어떻게 없앨 것인지에 대해
설명하고자 한다.
- Temporary segment 확인 방법
temporary segment는 그것의 용도를 다한 다음에는 항상 없어져야 정상이지만
그렇지 경우가 발생할 수 있다.
현재 어떤 temporary segment가 존재하는지 확인하기 위해 다음과 같은 문장으로
확인할 수 있다.
select * from dba_segments where segment_type='TEMPORARY';
이것은 현재 sort, index creation과 같은 작업 시 이용되는 모든 temporary
segment들을 보여준다. 이러한 temporary segment들은 SMON에 의해 clean up
되기까지 약간의 시간이 소요되며 만약 15분 이상 남아있게 된다면 아래 내용을
참조하기 바랍니다.
- Deleting stray Temporary Segment
note: 아래의 조치사항은 7.3.2.1에서는 적용되지 않는다. (see note: 38388.1)
a) dba_segments에서 tablespace_name을 확인한다.
b) temporary segment를 가지고 있는 tablespace에 사용가능한 최대 extent의
크기를 확인한다.
select * from dba_free_space
where tablespace_name = 'YOUR_TABLESPACE'
order by file_id, block_id;
c) table을 생성하는 문장을 실행시킨다. 이 테이블은 처음 extent는 발생을
시킬 수 있으나 두번째 extent 발생시 free space 부족으로 extent 발생에 실패
할 것이다.
e.g: 위에서 select한 결과에서 50Mb의 free space를 가지고 있다고 가정하고
일반적인 free space extent의 크기는 5Mb라고 가정하자.
create table RECLAIM( A number )
tablespace YOUR_TABLESPACE
storage (initial 5M next 100M minextents 2);
주의 : 여기서 next extent를 너무 크게 잡지는 않는 것이 좋다. 현재 실제로
사용되고 있는 temporary 영역까지 포함해서는 안 되기 때문임.
d) 첫번째 extent를 발생시킨 후 두번째 extent를 발생시키려고 하는 위와 같은
작업은 SMON으로 하여금 테이블스페이스를 clean up하게 할 수 있도록 유도하는
역할을 한다.
e) 만약 RECLAIM 테이블이 성공적으로 생성되었다면 SMON이 성공적으로 clean
up 작업을 수행한 것이며 RECLAIM 테이블을 drop시킨 후 기존에 에러가 발생되었
던 작업을 수행한다.
* 상기 작업 이외에 SMON에 의해 temporary segment가 clean up되기를 기다리
는 방법도 있을 수 있으나, SMON이 clean up 작업을 수행하는 frequency는
oracle version마다 다르며 12시간 정도 걸릴 수도 있다.
Reference Documents
<Note:35513.1>

You cannot remove it. Change the default tablespace for sys from Work to Temp. You can optionally bounce the db.

Similar Messages

  • Quick Cleanup of Temporary Segments and also for  Rollback Segment

    Do you know a tip allowe to do a quick
    Cleanup of Temporary Segments and also for Rollback Segment; same time we
    need to wait about 2 hours to cleanup these tablespaces.
    we have to take action immediately to prevent other sessions to fail as well
    and we cannot bounce the Oracle instance. So, how do we get rid of this
    temporary segment as quickly as possible?
    Rq: the shrink commande same time not cleanup Rollback Segment, i don't know why (Ex:Alter rollback segment R01 shrink; )
    Thank you

    According to my knowledge the rollback tablespace can not be cleanup as you want because in the rollback segments are the transactions without commit and because of that you can not do that. The Rollback tablespace cleans up itself when pending transactions make commit.
    [email protected]
    Joel P�rez

  • TEMPORARY SEGMENTS에 대해서 (ORACLE VERSION: 7.X ~ 8.1)

    제품 : ORACLE SERVER
    작성날짜 : 2003-11-07
    TEMPORARY SEGMENTS에 대해서 (Oracle version: 7.X ~ 8.1)
    ===========================================================================
    이 문서에서는 sort작업의 수행과 관련하여, memory상의 할당 및 disk상의
    temporary segment 생성 등에 관하여 살펴보았다.
    특히 temporary segment를 temporary type의 tablespace에 생성하도록 지정한
    경우에 대해서 자세히 살펴보았으며, 그러한 작업시 user가 확인할 수 있는
    dictionary정보 등을 기술하였다.
    이 문서는 아래와 같이 7가지 part로 나누어 설명하였으며, Oracle 7에서
    Oracle 8i에 모두 적용되는 사항이다.
    1. temporary segment가 생성되는 operation
    2. 메모리 할당
    3. user별 지정
    4. tablespace의 space management
    5. permanent tablespace를 사용하는 경우
    6. temporary tablespace를 사용하는 경우
    7. guideline
    8. temporary segments에 대한 정보 확인
    1. temporary segment가 생성되는 operation
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    temporary segment를 생성하게 되는 sort operation은 다음과 같이 정리할 수
    있다.
    - index생성
    - ORDER BY나 GROUP BY
    - SELECT문장에서 DISTINCT function
    - UNION, INTERSECT, MINUS operation
    - Sort-Merge joins
    - analyze command
    이 외에도 unique나 primary key를 생성하거나 enable시키는 문장의 경우
    sorting을 위해 temporary segment를 사용하게 되며,
    CREATE TABLE AS SELECT나 CREATE INDEX의 경우 table이나 index가
    만들어지는 과정중에는 segment type이 temporary 로 나타난다.
    CREATE TABLE이나 CREATE INDEX 문장이 완성되어 table이나 index가 완전히
    생성되면 type이 table과 index로 변경된다. 이러한 CREATE TABLE문장이나
    CREATE INDEX 문장이 도중에 space부족으로 실패하면, user의 temporary
    tablespace가 아닌 table이나 index를 생성하는 tablespace에 temporary
    segment위한 공간이 부족하다는 오류가 발생하는 것이다. 물론, CREATE INDEX시
    이렇나 temporary segment외에도 sort를 위한 temporary segment는 user의
    temporary tablespace에 생성된다.
    2. memory allocation
    ~~~~~~~~~~~~~~~~~~~~
    각 session별로 첫번째 sort가 수행되는 순간 memory가 할당되고 sort가
    진행된다. sort가 수행되기 위해 필요한 영역이 점차 증가하다가, sort가
    완전히 끝나거나 SORT_AREA_SIZE 크기에 도달하면 더 이상 memory를
    할당하지 않는다.
    이렇게 SORT_AREA_SIZE initialization parameter는 하나의 sort에 의해
    사용되어질 real main memory의 최대 크기를 나타낸다. 이 parameter의
    default값은 64K bytes이며, 이 parameter에 의해 만들어지는 sort memory
    영역은 다음과 같이, server configuration에 따라 다른 부분에 위치하게 된다.
    (1) dedicated server configuration
    sort area가 Program Global Area (PGA)에 할당된다. PGA는 이 외에도
    user 권한 등을 포함한 session information, cursor status, stack
    space 등을 포함한다.
    (2) multi threaded server (MTS) configuration
    sort area가 User Global Area(UGA)에 할당된다. 이 UGA는 SGA의 한
    구성 요소인 shared pool 내에 위치한다.
    sort가 완전히 끝이 나면, sort영역은 SORT_AREA_RETAINED_SIZE parameter에
    의해 정해진 memory크기로 줄어든다. 즉, SORT_AREA_RETAINED_SIZE는 다음
    sort를 위해서 미리 확보해 두는 영역이다. 만약 SORT_AREA_RETAINED_SIZE가
    0으로 설정되면 같은 process라도 매번 sort 시마다 새로 memory를
    SORT_AREA_SIZE 만큼 할당하게 되는 것이다.
    SORT_AREA_RETAINED_SIZE의 default 값은 SORT_AREA_SIZE와 같아서, 이전
    sort 시에 사용된 memory 부분이 항상 다음 sort 시에 그대로 이용된다.
    process가 완전히 종료되면 이 영역도 해제되어 MTS라면 shared pool 영역으로
    반환되고, dedicated 방식인 경우 operating system 영역으로 반환된다.
    이 두 initial parameter는 session level에서도 수정이 가능하다, 예를 들어
    두 paramter를 모두 1m로 설정하는 명령은 다음과 같다.
    SQL>alter session set
         sort_area_size = 1024000
         sort_area_retained_size=1024000;
    만약 앞으로 새로 생성되는 모든 session에 대해서 영향을 받도록 하려면
    alter system 명령을 이용하여야 한다. 예를 들면 다음과 같다.
    SQL>alter system set
         sort_area_size=102400 deferred
         sort_area_retained_size=102400 deferred;
    3. user 별 지정
    ~~~~~~~~~~~~~~
    2번에서 설명한 SORT_AREA_SIZE의 memory 외에도 추가적으로 sort 시 공간이
    필요하다면, 이 때는 이미 sort가 된 data들은 disk에 쓰여지고, memory 내의
    sort 영역을 비운 다음 그 영역을 새로운 sort되어져야 할 data들이 사용하도록
    하면서 전체 data를 sort한다. 물론 이렇게 부분적으로 sort가 된 단위들은
    나중에 다시 merge 단계를 거쳐 전에 data가 모두 sort가 되도록 한다. 이와
    같이 일부 정렬된 data들이 disk에 씌여지면 temporary segment가 생성되게
    된다.
    이렇게 정렬된 data들이 임시로 씌여지는 temporary tablespace는 각
    user마다 생성 시 지정되며, 임의로 변경 가능하다.
    예를 들면 다음과 같다.
    SQL> create user scott identified by tiger
         default tablespace users
         temporary tablespace temp;
    SQL> alter user scott temporary tablespace newtemp;
    4. tablespace의 space management
    (dictionary managed vs. locally managed)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    tablespace는 extent 단위로 space를 할당하는데, free space와 used space를
    관리하는 방법은 dictionary managed 방식과 oracle8i에서 새로 소개된
    locally managed, 이렇게 두가지로 구분될 수 있다.
    locally managed tablespace에 관한 자세한 사항은 <Bul:11860>을 참조하도록
    한다.
    (1) dictionary managed tablespace
    이것은 oracle8.0과 그 이전 version에서, tablespace에서 extent를 할당하고
    반환하는 방법으로 사용되는 것이다.
    data dictionary table에 extent를 할당하거나 해제함에 따라 변경되는
    extent정보를 저장한다. user에게는 dba_extents나 dba_free_space와 같은
    view를 통해 조회가능하다.
    이러한 형태의 tablespace내에 저장되는 segment는 storage option인
    initial, next, pctincrease 에 의해 필요한 extent를 free space로 부터
    할당받아가게 되는데 temporary segment를 위한 tablespace라면, 그 tablespace
    (주로 TEMP라고 이름지어짐) 에 생성되는 모든 temporary segment는
    tablespace의 default storage의 값을 segment별로 적용하게 된다.
    (2) locally managed tablespace
    이것은 8i에서만 사용가능한 방법으로, tablespace 자체가 자신의 extent에
    대한 정보를 가지고 관리한다. locally managed tablespace에 속한 각
    datafile들은 각 datafile마다 bitmap을 가지고 있어서, 각 block의
    free와 used상태를 유지한다. bitmap의 각 block은 하나의 block 혹은
    하나의 block의 group을 나타낸다.
    이렇게 extent를 자신이 관리하는 tablespace는, 일정한 크기의 extent
    size를 유지하는 UNIFORM형태나, system에서 자동으로 가변적인 extent
    size를 결정하는 AUTOALLOCATE방식, 두가지로 지정 가능하다.
    이러한 형태의 tablespace는 INITIAL, NEXT, PCTINCREASE, MINEXTENTS
    등의 storage option을 사용할 수 없다.
    locally managed tablespace는 다음과 같은 이점을 가진다.
    - extent를 local형태로 관리하면, recursive space management operation을
    줄일 수 있다. 즉 dictionary table에 대한 조회나 dml을 피할 수 있다.
    - 자동으로 bitmap만을 통해서, free space가 인접해있는지가 확인이 되기
    때문에 extent를 coalescing할 필요가 없어진다.
    tablespace를 생성할 때는 위의 두 형태 중 하나로 tablespace를 생성하여야
    하며, alter 문장을 통해서 형태를 변경할 수는 없다.
    5. permanent tablespace에 temporary segment 생성
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    일반적으로 TEMP라는 이름을 가지는 user가 temporary tablespace로 지정하는
    tablespace는 temporary나 permanent 중 하나로 지정가능하다.
    permanent로 지정하게 되면 sort가 필요할 때마다 temporary segment를
    tablespace에 생성하게 되고 sort가 끝나면 SMON이 이 segment를 해제한다.
    일반적으로는 이렇게 permanent로 지정을 하여도 db user의 temporary로
    지정된 tablespace에는 일반 user의 schema object를 생성하지는 않지만,
    실제적으로는 생성하여도 생성된 object의 사용에 지장은 없다.
    그런데 permanent로 지정하게 되면 다음과 같은 단점이 있다.
    - transaction level로 sort가 필요할 때마다 temporary segment를 생성하게
    되므로 여러개의 temporary segment가 생성되어 진다.
    - temporary segment가 자주 생성되고 다시 없어짐에 따라 fragmentation이
    발생할 가능성이 크다.
    - SMON이 sort가 완료되면 temporary segment를 free시키는 역할을 하는데,
    sort segment가 매우 많이 생성되게 되면, SMON이 그 segemnt를 지우는 데
    많은 시간을 할애하게 된다. 이렇게 되면 전체적인 db performance에
    영향을 주게 된다.
    permanent type으로 temporary segment를 위한 tablespace를 생성하는
    문장의 예를 기술하였다.
    (Oracle 8.1에서는 이렇게 선언하면 default로 dictionary-managed 형태로
    생성된다)
    SQL>create tablespace temp datafile '/oracle/oradata/temp01.dbf'
         default storage(initial 1m next 1m pctincrease 0);
    Oracle 8.1이상에서 temporary segment를 위해 locally-managed permanent
    tablespace를 생성하는 예문은 다음과 같다.
    단, 반드시 UNIFORM extent size만이 가능하다.
    SQL>create tablespace temp datafile '/oracle/oradata/temp01.dbf'
         extent management local uniform size 1m;
    6. temporary tablespace에 temporary segment 생성
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Oracle7.3부터 sort operation을 더욱 효율적으로 사용하기 위해 temp
    tablespace를 명시적으로 temporary로 지정하는 것이 가능하게 되었다.
    이렇게 함으로써, temporary tablespace에 sort space(temporary segment)를
    할당하고 해제하는 작업의 반복을 피할 수 있으며, 특히 OPS 환경에서 성능 향상에
    도움이 될 수 있다.
    이러한 형태의 tablespace에 생성되는 temporary (sort) segment는
    db startup 후 처음 수행되는 sort 작업이 memory 내의 sort를 마치고, disk로
    내려쓸 때 생성된다. 이렇게 일단 temporary segment가 생성되면 이 segment는
    db가 restartup될 때까지 줄어들거나 해제되지 않는다. sort가 필요한
    다른 transaction들은 미리 생성된 temporary segment를 공유하게 되나,
    extent를 공유하지는 않는다.
    sort 작업은 사용 가능한 extent가 존재하지 않으면 새로운 extent를 할당하면서
    temporary segment를 늘려나가며, 이미 설명한 바와 같이 db가 running되어
    있는 동안은 줄어들지 않는다. 그러나 sort가 끝나게 되면 사용한 extent를
    free로 표시하여 다른 transaction이 재사용 가능하도록 한다. 결국 temporary
    segment는 무한정 계속 늘어나기보다는 일정한 size 정도까지 늘어난 후에는
    extent 별로 재사용되어지는 것이다.
    이러한 temporary tablespace 내의 sort segment에 대한 정보는
    Sort Extent Pool (SEP)에 저장하며, 이것은 SGA 내에 위치한다.
    temporary tablespace를 이용하여 sort를 수행하여야 하는 모든 문장은
    SGA 내의 이 SEP를 확인하여 free extent를 찾아낸다. 이렇게 각 operation 후에
    extent가 할당, 해제되는 과정이 필요없기 때문에 기존의 permanent
    tablespace에 temporary segment를 생성하는 것보다 db의 전반적인 속도가
    향상되는 것이다.
    앞에서 이 temporary tablespace 형태가 특히 OPS에서 성능 향상을 가져올
    수 있다고 하였는데, 그 이유는 이 SEP에서 할당되는 extent는 다른
    instance끼리 같은 extent를 사용하는 경우는 없도록 instance id를 이용하여
    할당받도록 하여 항상 같은 instance에만 할당이 된다.
    즉, ping이 발생할 확률이 줄게 되어 속도의 향상을 가져오게 된다.
    temporary tablespace 내의 sort segment의 해제 작업은 db shutdown 시에
    자동으로 이루어지는 것이 아니고 db startup 시에 SMON에 의해서 수행된다.
    database가 open되고 나면, temporary tablespace에서 extent를 해제하여
    coalescing 작업을 수행한다. 이러한 작업으로 인해 db가 startup된 직후
    SMON이 CPU를 많이 사용하는 경우가 발생하는 것이다.
    만약에 temporary tablespace의 NEXT값이 너무 작게 지정되어 매우 많은
    갯수의 extent가 만들어지게 되면, SMON의 이러한 작업으로 인해 사용가능한
    CPU resource가 거의 없어짐으로 인해 db 사용에 문제가 야기될 수 있다.
    tablespace를 temporary로 지정하는 문장의 예는 다음과 같다.
    (Oracle 8.1에서는 이렇게 선언하면 default로 dictionary-managed 형태로
    생성된다.)
    SQL>create tablespace temp datafile '/oracle/oradata/temp01.dbf'
    default storage(initial 1m next 1m pctincrease 0) temporary;
    Oracle 8.1 이상에서 temporary segment를 위해 locally-managed temporary
    tablespace를 생성하는 예문은 다음과 같다.
    단, temporary tablespace에서는 반드시 UNIFORM extent size만이 가능하다.
    SQL>create temporary tablespace temp
    tempfile '/oracle/oradata/temp01.dbf'
    extent management local uniform size 1m;
    이렇게 temporary tablespace로 생성된 tablespace에는 table이나 index와
    같은 permanent한 schema object는 생성될 수 없다.
    dictionary-managed temporary tablespace의 경우는 다음과 같은 문장에
    의해 permanent로 변경이 가능하다.
    SQL> alter tablespace temp permanent;
    7.guidelines
    ~~~~~~~~~~~~
    - temporary segment가 자주할당되고, 해제되는 것을 피하고자 한다면 temporary
    type의 tablespace를 사용한다.
    - 하나 이상의 temporary tablespace를 사용하는 것도 동시에 sort가 발생하는
    경우 도움이 된다. 즉 db user마다 temporary tablespace를 달리 지정하라는
    것인데, 이것은 db user별로 업무 분할이 잘 되어 있는 OPS에서 특히 유용하다.
    그 외에도 각 tablespace를 다른 disk에 위치시키는 경우 속도 향상을 가져올
    수 있고, db user별로 업무가 나뉘는 경우 각 업무에 필요한 sort space를
    따로 관리하는 장점이 있다.
    - temporary tablespace의 default storage를 지정하는 경우, INITIAL은 NEXT와
    같게 하고 pctincrease는 항상 0으로 한다.
    pctincrease가 0이면 temporary tablespace의 모든 extent는 같은 크기의
    조각을 가지게 되고, 이렇게 되면 coalescing이 수행되지 않아도 새로운
    sort작업이 기존에 발생한 extent를 그대로 이용할 수있게 된다.
    8. temporary segments에 대한 정보 확인
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    v$sort_segment view에서 sort segment를 포함하는 temporary tablespace를
    확인할 수 있다.
    extent_size     : extent의 크기, Oracle block갯수
    total_extents     : 빈 것과, 사용 중인 것 모두 합해 segment에 포함된 total
              extent의 갯수
    used_extents     : 현재 사용 중인 extent의 갯수
    free_extents     : 현재 free로 표시되어 있는 extent의 total갯수
    max_used_size     : 하나의 operation, 즉 한 transaction에 의한 한번의 sort와
    같은 작업을 위해 사용된 extent의 갯수 중 최대로 큰 경우
    현재 user에 의해 사용되어지고 있는 temporary segment 내의 공간을
    확인하려면, v$sort_usage와 v$session view를 이용한다.
    단, sort_usage는 sort 시에만 정보가 나타나는 것을 주의해야 한다.
    예를 들어 다음과 같이 조회할 수 있다.
    select s.username, u.tablespace, u.contents, u.extents, u.blocks
    from v$session s, v$sort_usage u
    where s.saddr=u.session_addr;
    USERNAME TABLESPACE CONTENTS EXTENTS BLOCKS
    SCOTT TEMP TEMPORARY 10 10240000

    You need to read Note:131299.1 available on Metalink.
    ALERT: Oracle Installer 8.1.X Hangs on Machines with Pentium 4 Processors.
    There is a patch available.

  • Temporary segments

    Hi,
    Oracle 10g Concepts, Chapter - 2, Page - 17 says....
    Some unindexed joins and correlated subqueries can require use of a temporary
    segment. For example, if a query contains a DISTINCT clause, a GROUP BY, and an
    ORDER BY, Oracle can require as many as two temporary segments.
    Here I do not understand why would Oracle need Two temporary segments. Why cant it use same segment and let it grow as needed?
    Thanks in advance.
    -rohit

    Depending on the size of your sort area (specified by sort_area_size if you manage PGA manually, or derived through pga_aggregate_target if you use automatic PGA management), the amount of data, and the query plan, Oracle may require one temporary segment per sort operation. GROUP BY, DISTINCT and ORDER BY all imply a sort, but there are other operations (e.g. SORT JOIN) that also require a sort, and therefore, possibly a sort segment.
    Having said that, it is also possible that Oracle will choose an access path that eliminates the need for a sort (assuming use of CBO), even for something like ORDER BY. If the sort column(s) are indexed and not null (whether by a constraint or by a predicate in the query), Oracle may choose to use a FULL INDEX SCAN as an access path. This will read the entire index in key order, thus the rows will be sorted without actually sorting.
    John

  • Temporary segment can't be dropped after upgrading from 9.2.0.1 to 9.2.0.8

    After upgrading oracle from 9.2.0.1 to 9.2.0.8 ,alert.log show some corrupted block ,dbv also confirm the errors.
    alert log:
    SMON: enabling tx recovery
    Wed Aug 12 21:47:23 2009
    Database Characterset is ZHS16GBK
    Wed Aug 12 21:47:23 2009
    Hex dump of Absolute File 6, Block 11 in trace file d:\oracle\admin\oracle9i\bdump\oracle9i_smon_1100.trc
    Corrupt block relative dba: 0x0180000b (file 6, block 11)
    Bad header found during buffer read
    Data in bad block -
    type: 35 format: 2 rdba: 0x0040000b
    last change scn: 0x0000.00000000 seq: 0xff flg: 0x04
    consistency value in tail: 0x000023ff
    check value in block header: 0x551d, computed block checksum: 0x0
    spare1: 0x0, spare2: 0x0, spare3: 0x0
    Reread of rdba: 0x0180000b (file 6, block 11) found same corrupted data
    Hex dump of Absolute File 6, Block 19 in trace file d:\oracle\admin\oracle9i\bdump\oracle9i_smon_1100.trc
    Corrupt block relative dba: 0x01800013 (file 6, block 19)
    Bad header found during buffer read
    Data in bad block -
    type: 35 format: 2 rdba: 0x00400013
    last change scn: 0x0000.00000000 seq: 0xff flg: 0x04
    consistency value in tail: 0x000023ff
    check value in block header: 0x21f2, computed block checksum: 0x0
    spare1: 0x0, spare2: 0x0, spare3: 0x0
    Reread of rdba: 0x01800013 (file 6, block 19) found same corrupted data
    Hex dump of Absolute File 6, Block 195 in trace file d:\oracle\admin\oracle9i\bdump\oracle9i_smon_1100.trc
    Corrupt block relative dba: 0x018000c3 (file 6, block 195)
    Bad header found during buffer read
    Data in bad block -
    type: 0 format: 2 rdba: 0x004000c3
    last change scn: 0x0000.00000000 seq: 0xff flg: 0x04
    consistency value in tail: 0x000000ff
    check value in block header: 0x683, computed block checksum: 0x0
    spare1: 0x0, spare2: 0x0, spare3: 0x0
    Reread of rdba: 0x018000c3 (file 6, block 195) found same corrupted data
    Wed Aug 12 21:47:24 2009
    replication_dependency_tracking turned off (no async multimaster replication found)
    Completed: ALTER DATABASE OPEN  
    SYS@oracle9i>col segment_name for a20
    SYS@oracle9i>col segment_type for a20
    SYS@oracle9i>select segment_name,segment_type from dba_segments where header_file=6 and header_block
    =11;
    SEGMENT_NAME         SEGMENT_TYPE
    6.11                 TEMPORARY
    SYS@oracle9i>select segment_name,segment_type from dba_segments where header_file=6 and header_block
    =19;
    SEGMENT_NAME         SEGMENT_TYPE
    6.19                 TEMPORARY
    SYS@oracle9i>select segment_name,segment_type from dba_segments where header_file=6 and header_block
    =195;
    SEGMENT_NAME         SEGMENT_TYPE
    6.195                TEMPORARY
    smon can't clean the temporary segment,so I set event drop_segments ,but it also don't take effect

    You could run dbms_repair to mark those blocks as corrupted.
    You should
    a. take the tablespace offline
    b. run dbv a few times to confirm that it is always the same blocks and only these blocks in temporary segments that appear to be corrupted
    c. use dbms_repair to mark the corrupted blocks
    However, if it is always a segment header block that appears to be corrupted, it is suspicous behavioiur.
    Also, SMON is failing on the corrupted blocks which are segment headers -- had the corrupted blocks not been segment headers then SMON would not have even been reading all the blocks. It only reads the header blocks (segment/extent) to free the extents.
    But you should first go through your alert.log to find out when and, possiby why, those blocks are corrupt.

  • Index rebuild - temporary segment

    Hi,
    I am getting an error while rebuilding the indexes, like unable to allocate extents in temporary segment. Kindly help me to solve this.
    Regards,
    Mathew Collins

    You should never drop an index with the intention of recreating it without first checking the size of the index against the size of the available temp tablespace sort area.
    If you are using an alter index rebuild to reorganize the index then unless you specify a new tablespace in the command the existing tablespace must have enough free space to hold the entire original index and the rebuilt index. An alter index rebuild also uses temporary (sort) tablespace so you still need to ensure that your index has not outgrown your temp tablespace.
    HTH -- Mark D Powell --

  • Temporary segments issue

    hi,
    my database is 8.0.6
    if i give
    SQL>select count(*) from dba_extents where segemnt_type='TEMPORARY';
    38450
    IAM GETTING THE ABOVE VALUE
    SOME TIMES ITS ABOVE 60000 ALSO....
    HERE I NOTICED MY SMON IS NOT CLEANING UP MY TEMP SEGMENTS ...
    1.SO WHAT SHOULD I DO IN THIS SCENARIO?
    2. WHETHER IT WILL AFFECT THE PERFORMANCE OF MY DATABASE?
    please HELP ME.
    THANKS AND REGARDS,
    MOHAMMED MEHRAJ HUSSAIN.

    Hi,
    duplicate post
    doubt
    - Pavan Kumar N

  • SMON cleanup process taking longer time (cleaning temporary extents)

    Os info:     Solaris 5.8
    Oracle info:     9.2.0.8
    Message:     
    We are in the process of testing our upgrade from 9.2.0.8 to 11.2.0.3. As a part of this, we have cloned our production database and started cleaning up of unused objects on the new instance.
    Dropped an Audit Table (27g table size & 11g index size) from SYSTEM tablespace as a part of 11g upgrade tasks. As you know SYSTEM tablespace is under Dictionary managed tablespace and drop table ran for about 2 weeks.
    We are unable to bring this database gracefully, as SMON is still cleaning the temporary extents. This cleanup seems to be very slow and will take about 40+ days.
    Created SR regarding this issue, to speed up the SMON clean up process.. but no luck.
    At this moment we are looking for a solution to
    1#Is there a way to speed up the SMON cleanup process (temporary extents)?
    OR
    2# Is there a way to bypass the cleanup of this temporary segment and bring the database gracefully?
    No Luck from Oracle Support...
    Googled it but no luck.
    Just want to check with the folks over here and see if there is any solution for this issue.
    Thanks in advance for your time and efforts on this forum. Appreciate your assistance!
    Thanks,
    Raghu Yella.

    Just passing by.
    >
    If the data is not needed, drop the index, truncate the table and then drop the table (as rp0428 noted above)
    >
    Srini and rp0428, what do you guys know that I don't? A "drop table" (which is what the OP indicated was run) should drop any data (effectively the same thing as a truncate) and all associated indexes. Does the truncate offer some performance benefit in this case?
    And I'm still trying to wrap my head around a 40 day drop. The statement, "started cleaning up of unused objects" scares me if there is more backup tables in this bloated SYSTEM tablespace. If that is the case (and maybe regardless), I wonder if it would just be better to create a fresh "clean" database and then with transportable tablespaces reattach all the DATA tablespaces to this new database. Fresh start.

  • Tablespace....contents=TEMPORARY.. how long will data reside here??

    Hello all,
    While creating a tablespace we have the option, PERMANENT OR TEMPORARY.
    Well, in the oracle 8.1.6 db that i have; the temporary tablespace is like this... A tablespace was created with TEMPORARY and it is used as the temp tablespace.
    So unlike with the original temp tablespace(create temporary tablespace...), i just cannot drop the datafiles of this tablespace once they become large.
    If i have created a tablespace with TEMPORARY, how long will the data stay there ??
    TIA,
    J J

    For a dictionary managed tablespace defined to be temporary, the sort extents might not be de-allocated while the instance is running, but are marked as free and can be re-used as required which would mean that the sort segment could potentially grow. The Oracle server stores the information about the sort segment in the Sort Extent Pool which is part of the System Global Area (SGA). Every statement that needs to sort in the temporary tablespace checks this part of the SGA for free extents thereby eliminating the need for frequent allocation and de-allocation which in turn reduces the contention due to the ST enqueue.
    The SMON process is responsible for the cleanup up of the temporary segments within dictionary managed temporary tablespaces and is something that usually happens during instance startup. If you want to forcefully wakeup the SMON process to do the cleanup then you can maybe change the storage attributes like the maxextents of the temporary tablespace (change it to some number and then put it back to unlimited and give it a minute) and this might trigger the SMON to do the cleanup.
    Good luck......

  • Unable to extend temp segment by 256 in tablespace PROD_REV_FACT_TS

    I get the following error
    please let me know how to solve this
    ERROR at line 31:
    ORA-01652: unable to extend temp segment by 256 in tablespace PROD_REV_FACT_TS
    Free space
    1 select tablespace_name , sum(bytes)
    2 from dba_free_space
    3 where tablespace_name ='PROD_REV_FACT_TS'
    4 group by tablespace_name
    5* order by 2 asc
    SQL> /
    TABLESPACE_NAME SUM(BYTES)
    PROD_REV_FACT_TS 1547698176
    Tables available
    SQL> select count(1) from all_tables where tablespace_name ='PROD_REV_FACT_TS';
    COUNT(1)
    0

    As William pointed out, the total amount of free space is not very revealing. Also, there are potentially more things in tablespaces than tables. Try these two queries to get a better picture of what space you have, and what is in the tablespace.
    SELECT file_id, MAX(bytes) biggest, SUM(Bytes) total
    FROM dba_free_space
    WHERE tablespace_name = 'PROD_REV_FACT_TS';
    SELECT segment_name, segment_type, owner, bytes
    FROM dba_segments
    WHERE tablespace_name = 'PROD_REV_FACT_TS';For a really detailed view of free_space you could try:
    SELECT file_id, block_id, bytes
    FROM dba_free_space
    WHERE tablespace_name = 'PROD_REV_FACT_TS'
    ORDER BY 1, 2;It sounds like you are trying to create a table or an index in that tablespace, and running out of space. When you do that, Oracle initially builds the segment as a temporary segment. When the segment is fully built, the temporary segments are changed to permanent segments. This makes cleanup easier for Oracle if the database goes down in the middle of the operation.
    HTH
    John

  • Amount of temporary tablespace size used for index rebuild

    Hi All,
    I want to know approximate amount of temporary tablespace size used for index rebuild. I need this information to avoid the insufficient temporary tablespace error during the huge index rebuild.
    Is there a query or procedure to find it out.
    Thank you.

    Hi,
    While creating the index, the temporary segment is created in the permanent tablespace. So permanent tablespace must have sufficient space.
    http://www.oracle-base.com/articles/10g/SpaceObjectTransactionManagement10g.php
    http://aprakash.wordpress.com/2010/01/05/numeric-segment-name/
    Anand

  • How to purge data in a global temporary table from another session

    I've got a problem with vendor-delivered web-based software (jdbc) that periodically "hangs." When that happens, I have to kill the database session before retrying the process. This "workaround" does NOT clean up the temporary tablespace. Is there anyway (outside of bouncing the database) to truncate temporary tables regardless of sessionid? Thanks.

    In 8i the space used by temporary segments is not dropped in a temporary tablespace. The space is available for other queries or temporary tables. This avoids the costs of allocating and releasing space for temporary segments.

  • Unable to extend TEMP segment even after adding fresh temp files

    Hi All,
    I have a huge table with rows nearly 2 million. When this table is moved to another tablespace, the command failed giving the following error:
    ORA-01652: unable to extend temp segment by 128 in tablespace XYZ
    To overcome this error, an additional temp file was added with huge size. Unfortunately, the same error appeared again when the table was tried to move to another tablespace. I wonder if the new temp file was not recognized by database, so tried to see how many files belong to temporary tablespace, but the query listed the newly added temp file also.
    What could be the possible reason for this error? Suggestions or clues are most welcome.
    Thanks,
    ...

    The temp segment is for the table that is being moved.
    Oracle creates a temporary segment when doing a move. If the target tablespace has enough space, the move succeeds and the temp segment gets converted to a Table segment. Else, if the move fails because of lack of space (the temp segment itself unable to grow), then the temp segment is dropped on failure.
    Thus, in a
    alter table ABC move tablespace MY_TBS;or
    the target tablespace MY_TBS should have enough space for ABC. While Oracle is building the copy of ABC in MY_TBS, it is being built as a temporary segment. If the copy succeeds, the temporary segment is renamed as a Table segment 'ABC' and the original table segment 'ABC' is dropped.
    This behaviour also happens when you do an ALTER TABLE .. MOVE ; into the same tablespace that it is existing in. The new copy of the table is a temporary sgement till the copy succeeds.

  • Direct Path Insert into temporary table

    Hi,
    I made the following experiment (temp_idtable is a temp table with a single column id, V_PstSigLink is a complex View):
    14:24:28 SQL> insert into temp_idtable select id from V_PstSigLink;
    17084 Zeilen wurden erstellt. (in english: rows inswerted)
    Statistiken
    24 recursive calls
    52718 db block gets
    38305 consistent gets
    16 physical reads
    4860544 redo size
    629 bytes sent via SQL*Net to client
    553 bytes received via SQL*Net from client
    3 SQL*Net roundtrips to/from client
    4 sorts (memory)
    0 sorts (disk)
    17084 rows processed
    14:24:41 SQL> commit;
    Transaktion mit COMMIT abgeschlossen.
    14:25:29 SQL> insert /*+ APPEND*/into temp_idtable select id from V_PstSigLink;
    17084 Zeilen wurden erstellt. (in english: rows inswerted)
    Statistiken
    1778 recursive calls
    775 db block gets
    38847 consistent gets
    40 physical reads
    427408 redo size
    613 bytes sent via SQL*Net to client
    565 bytes received via SQL*Net from client
    3 SQL*Net roundtrips to/from client
    27 sorts (memory)
    0 sorts (disk)
    17084 rows processed
    As you can see, with /*+ APPEND*/ there will be much less REDO generated.
    How can it be?
    1. /*+ APPEND*/ only doesn't mean that there shouldn't be REDO generated, does it? For that one has to declare the table with NOLOGGING.
    2. In the doc there is a statement that for temp. tables there is no REDO log generated, just UNDO (and REDO only for UNDO).
    Where is the difference coming from?
    If I use Direct Path (APPEND) for a temp table, where will be the table populated - in the Buufer Cache or directly in a temporary segment on the disk?
    Balazs

    Hi John,
    I'm a little confused about your statement " Oracle does not cache data blocks until they are read from a table.". I wanted to make a little experiment with KEEP Buffer Cache to see weather I can 'pin' the content of a temp table. But before getting to pin I realized an interesting behavior. Please see this sqlplus log:
    SQL> create global temporary table temp_ins(id NUMBER);
    Table created.
    SQL> insert into temp_ins values (1);
    1 row created.
    SQL> insert into temp_ins values (2);
    1 row created.
    SQL> insert into temp_ins values (3);
    1 row created.
    SQL> set autotrace on explain statistics;
    SQL> select * from temp_ins;
    ID
    1
    2
    3
    Execution Plan
    0 SELECT STATEMENT Optimizer=CHOOSE
    1 0 TABLE ACCESS (FULL) OF 'TEMP_INS'
    Statistics
    0 recursive calls
    0 db block gets
    4 consistent gets
    0 physical reads
    0 redo size
    416 bytes sent via SQL*Net to client
    503 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    3 rows processed
    SQL>
    I realized exectly the opposit of your statement! Oracle apparently cached the content of the temp table before it read from it!! Could you please explain why? Now I'm going to try it with a normal table...
    Balazs

  • ORA-03212 temporary tablespace

    Hi all,
    we run a single instance database on file system (no ASM).
    The database has benn running fine for several weeks now. 2 days ago however the following error came up:
    "*** MODULE NAME:(DBMS_SCHEDULER) 2012-09-02 06:00:03.470
    *** ACTION NAME:(MGMT_CONFIG_JOB_1) 2012-09-02 06:00:03.470
    ERROR: kfnUseConn - failure to make a connection
    ORA-03212: Temporary Segment cannot be created in locally-managed tablespace".
    I changed the user's (oracle_ocm) temp tablespace to "TEMPORARY LOCAL". which should avoid that error in future.
    My question:
    What is the appropriate temporary tablespace for system users?
    We run quite a lot of databases that were created with version 7.x and migrated up to version 10 or 11. They all used to have PERMANENT tablespaces as temp tbs for the users 'SYS, SYSTEM, DIP, APPQOSSYS, CSMIG' which did not make any problems up to now.
    Should I change default temporary tbs to TBLSPC_TEMP for all users including those mentioned above?
    FJH

    Please post output of below commands :
    1. select tablespace_name from dba_data_files where tablespace_name like '%TEMP%';
    If you gets any name here, it means your temp tablespace is not really a temp one, its a permanent one whose name is temp, because if you have created temp tablespace with the TEMPFILE keyword, then only its a really temp tablespace. DBA_DATA_FILES do not shows the datafiles which have been created with TEMPFILE keyword.
    2.set long 999999;
    SELECT DBMS_METADATA.GET_DDL('TABLESPACE','TEMP') FROM DUAL;
    In above output if you don't see TEMPFILE keyword then ORA-03212 is correct and as documented.
    Now, if you want your TEMPORARY tablespace to be Locally Managed then you should use the TEMPFILE clause and NOT DATAFILE while creating the TEMPORARY TABLESPACE.
    create temporary tablespace temp tempfile
    '/u10/oradata/cprpt/temp01.dbf' size 250M reuse,
    '/u10/oradata/cprpt/temp02.dbf' size 250M reuse,
    '/u10/oradata/cprpt/temp03.dbf' size 250M reuse,
    '/u10/oradata/cprpt/temp04.dbf' size 250M reuse
    extent management local uniform size 3M;
    http://www.dbasupport.com/forums/showthread.php?t=31317
    Regards
    Girish Sharma

Maybe you are looking for

  • Workflow conditional statement not working

    I have 2 level approvals of objects in Documents list. The document first uploaded by user and then first need to get approval from HR Line Manager and then get approval from HR manager. the attach image shows shows workflow , the issue is either I s

  • Filename printing on dustcover - but I don't want it to!

    Hi all, Hoping someone can help as this is driving me crazy. No matter what I do (erase the filename, insert a space instead of the filename, make the text the same colour as the background), the filename keeps coming up in white text underneath all

  • Cisco LMS 4 IEFrame

    Hello, i have added a IEFrame in a LMS Dashboard containing some information about Cisco WCS. I works fine, just there is an issue when i open my Dashboard and I didn't start WCS before the IE Frame not showing the information. I tried to set the cre

  • How to associate an xml from httpservice to datagrid if the xml element name contains periods in it

    Following is the xml from an http service, how to associate this xml to a data grid (employee name, number) since it contains periods(dots) in xml element name. An early help is appreciated..... <?xml version="1.0" encoding="ISO-8859-1"?> <com.compan

  • Character encoding in portlets

    Hi I was developed Java portlets, using JPS and BC4J. We are using portal (9.0.2) in different languages (English, Hungarian). In JPS pages wich character encoding do I use, because the data retreived from the database doesn't appear properly. thanks