Cleanup log running transactions ..rollback segments

Is there any metric in OEM which does the following...
Am trying to read the document and find the metric which does the following ..not having much luck...
#* Description : Process to monitor and notify DBA about any in-doubt
#* transaction which is holding ROLLBACK Segment and
#* troubling system resources for longer time.
Thank you

Below are more details on what it does...trying to find if any metric in OEM does this...thank you
$sql_text  = "select c.USN  ";
   $sql_text .= ",d.name       ";
   $sql_text .= ",c.EXTENTS , ";
   $sql_text .= "a.username , a.osuser , a.sid , a.process, a.status  ";
   $sql_text .= ",b.start_time ";
   $sql_text .= ",b.status trans_stat, b.used_ublk*value as Bytes_Used ";
   $sql_text .= ",b.used_urec  as Records_used          ";
   $sql_text .= ",start_uext   as First_Extent          ";
   $sql_text .= ",a.MACHINE           ";
   $sql_text .= ",a.TERMINAL        ";
   $sql_text .= ",a.PROGRAM     ";
   $sql_text .= "from v\$session     a,                        ";
   $sql_text .= "     v\$transaction b,                        ";
   $sql_text .= "     v\$rollname    d,                        ";
   $sql_text .= "     (select value from v\$parameter          ";
   $sql_text .= "          where name = 'db_block_size' )  e , ";
   $sql_text .= "     v\$rollstat    c ,                       ";
   $sql_text .= "     dba_rollback_segs f                      ";
   $sql_text .= "where b.ses_addr = a.saddr (+)                ";
   $sql_text .= " and c.usn      = b.xidusn (+)                ";
   $sql_text .= " and d.usn      = c.usn                       ";
   $sql_text .= " and f.segment_id = c.usn                     ";
   $sql_text .= " and a.status     = 'INACTIVE'                ";
   $sql_text .= " and b.used_urec <=${rec_used}                ";
   $sql_text .= " and (round((sysdate - to_date(start_time,'mm/dd/yy HH24:mi:ss'))*1440)) >= ${time_interval} ";
   $sql_text .= " and a.username  <>  'DMIRROR'  

Similar Messages

  • TRANSACTION을 ROLLBACK SEGMENT에 할당하는 방법(SET TRANSACTION USE)

    제품 : ORACLE SERVER
    작성날짜 : 2003-04-04
    TRANSACTION을 ROLLBACK SEGMENT에 할당하는 방법
    ==============================================
    (SET TRANSACTION USE ROLLBACK SEGMENT)
    Purpose
    Batch job 등을 사용할 때 특별히 크게 만든 rollback segment를 사용하도록
    할 수가 있다. transaction에 특정한 rbs를 지정하는 방법을 알아보자.
    Explanation
    Oracle은 다음과 같은 규칙에 의해 각 Transaction이 사용하는 Rollback
    segment를 결정한다.
    1. Active Transaction의 수가 가장 작은 Rollback Segment에 할당한다.
    2. 만약 1의 조건에 만족하는 Rollback segment가 하나 이상이면, 가장
    마지막에 할당된 rbs 다음의 rbs를 할당한다. 이것은 undo 기능을 더
    오래 지속시키도록 해 준다.
    그러나, Application이 큰 rollback segment가 필요하다면 위와 같이
    자동적인 rollback segment의 할당이 아닌 Manual하게 특정 rollback
    segment를 할당 가능하다.
    다음의 방법을 사용한다.
    1) 큰 rollback segment를 만든다. 큰 rollback segment 를 만들기
    위해서는 rbs tablespace에 영역이 충분히 커야 하므로 필요할 경우
    tablespace를 확장하는 작업을 한다.
    <tablespace 확장>
    $ sqlplus system/manager
    sql> alter tablespace rbs add datafile '?/rbs1SID.dbf' size 100m;
    <rollback segment 생성>
    sql> create rollback segment big_rbs storage(initial 10m next 10m)
    tablespace rbs;
    sql> alter rollback segment big_rbs online;
    2) Transaction 를 assign 한다.
    <sqlplus>
    SQL> set transaction use rollback segment big_rbs;
    <pro*c>
    exec sql commit work;
    exec sql set transaction use rollback segment big_rbs;
    <forms>
    dbms_transaction.use_rollback_segment('big_rbs');
    이와 같이 지정하면 이후에 commit 또는 rollback이 일어날 때까지
    한 transaction에만 해당된다.

  • The OPTIMAL storage parameter in the rollback segment

    Hi,
    in metalink note Subject: ORA-01555 "Snapshot too old" in Very Large Databases (if using Rollback Segments)
    Doc ID: 45895.1
    I see :
    Solution 1d:
        Don't use the OPTIMAL storage parameter in the rollback segment. but how not to use the OPTIMAL storage parameter in the rollback segment ?
    Thank you.

    If you are using undo_management=AUTO (in 9i or higher) then there is no "OPTIMAL" setting.
    "OPTIMAL" is when using Manual Undo Management with Rollback Segments created by the DBA.
    If you are using Manual Undo Management, check your Rollback Segments. The Optimal size would be visible in V$ROLLSTAT.
    select a.segment_name a,  b.xacts b, b.waits c, b.shrinks e, b.wraps f,
          b.extends g, b.rssize/1024/1024 h, b.optsize/1024/1024 i,
          b.hwmsize/1024/1024 j, b.aveactive/1024/1024 k , b.status l
    -- from v$rollname a, v$rollstat b
    from dba_rollback_segs a, v$rollstat b
    where a.segment_id = b.usn(+)
    and b.status  in ('ONLINE', 'PENDING OFFLINE','FULL')
    order by a.segment_name
    /To unset the Optimal setting you can run
    alter rollback segment SEGMENT_NAME storage (optimal NULL);Note that if you unset OPTIMAL, then your Rollback Segments will remain at very large sizes if and when they grow running large transactions ("OPTIMAL" is the pre-9i method for Oracle to automatically shrink Rollback Segments). You can manually SHRINK or DROP and CREATE Rollback Segments then.

  • ROLLBACK SEGMENT의 MINEXTENTS를 20 이상으로 하면 좋은 이유

    제품 : ORACLE SERVER
    작성날짜 : 2003-06-19
    ROLLBACK SEGMENT의 MINEXTENTS를 20 이상으로 하면 좋은 이유
    =========================================================
    PURPOSE
    이 자료는 다음과 같은 주제에 대하여 소개하는 자료이다.
    이 문서는 database application의 요구 사항을 충족시키기 위해 고려되어
    져야 할 rollback segment tablespace 구성에 관한 내용을 담고 있다.
    Creating, Optimizing, and Understanding Rollback Segments
    -Rollback Segment 구성과 기록 방식
    -Transaction에 Rollback Segment를 할당하는 Oracle 내부 메커니즘
    -Rollback Segment 크기와 갯수
    -Rollback Segment의 크기와 갯수 결정을 위한 테스트
    -Rollback Segment extent의 크기와 갯수
    -Rollback Segment의 minextents를 20 이상으로 하면 좋은 이유?
    -Rollback Segment의 Optimal storage parameter와 Shrink
    Explanation
    Rollback Segment 구성과 기록 방식
    Rollback segment는 extent라 불리는 연속적인 여러 개의 block으로 구성된다.
    Rollback segment는 ordered circular 방식으로 extent를 쓰게 되는데,
    current extent가 full이 되면 next extent로 옮겨 가며 사용하게 된다.
    Transaction은 rollback segment 내의 current location에 record를 쓴 다음,
    record의 size 만큼 current pointer를 옮겨 간다.
    Rollback segment에 현재 record가 쓰여지고 있는 위치를 "Head"라고 한다.
    또한, "Tail"이란 용어는 rollback segment에서 가장 오래된 active
    transaction record의 시작 위치가 되는 부분을 말한다.
    Transaction에 Rollback Segment를 할당하는 Oracle 내부 메커니즘
    새로운 transaction이 rollback segment 를 요청하면, 각 rollback segment
    를 이용하고 있는 active transaction 갯수를 확인하여 가장 적은 갯수의
    active transaction 을 가진 rollback segment를 할당하게 된다.
    Rollback segment는 transaction load를 처리하기에 충분한 크기를 가져야
    하고, 필요한 만큼의 rollback segment를 사용할 수 있도록 적당한 갯수의
    rollback segment를 가져야 한다.
    1. 한 transaction은 단 하나의 rollback segment만을 사용할 수 있다.
    2. 같은 extent에 여러 transaction이 기록할 수 있다.
    3. Rollback segment의 Head는 Tail에 의해 현재 사용 중인 extent를
    침범하지 않는다.
    4. 링 형태로 구성되어 있는 rollback segment의 extent들은 다음 extent를
    찾을 때 절대 건너 뛰는 일이 없으며, 순서를 뒤바꾸어 사용하지도 않는다.
    5. Head가 next extent를 찾지 못하면, 새로운 extent를 추가로 할당하고,
    그 extent를 링 안에 포함시킨다.
    위와 같은 원리를 감안할 때, transaction size 뿐만 아니라 transaction
    time도 상당히 중요한 고려 사항이라는 것을 알 수 있다.
    Rollback Segment 크기와 갯수
    Rollback segment size가 충분한지 판단하는 기준은 transaction activity에
    직접적으로 영향을 받는다. 주로 일어나는 transaction activity에 근거하여
    rollback segment size를 결정하여야 하고, 잘 일어나지 않는 특수한 경우의
    큰 transaction이 문제라면 별도의 rollback segment로 관리되어야 한다.
    Transaction 발생 중 Head가 너무 빨리 wrap around 시켜서 tail을 catch하
    지 않도록 하여야 하며, 자주 변경되는 data에 대해 long-running query가
    수행되었을 경우 read-consistency가 유지될 수 있도록 rollback segment
    가 wrap around되지 않아야 한다.
    Rollback segment 갯수를 적당히 잡아야 하는 이유는 process들 간에
    contention을 방지하기 위함이고, V$WAITSTAT, V$ROLLSTAT, V$ROLLNAME
    view를 통해서 contention을 확인할 수 있으며, 조회문은 다음과 같다.
    sqlplus system/manager
    select rn.name, (rs.waits/rs.gets) rbs_header_wait_ratio
    from v$rollstat rs, v$rollname rn
    where rs.usn = rn.usn
    order by 1;
    위의 query에 의해 조회된 rbs_header_wait_ratio 가 0.01 보다 크면,
    rollback segment 갯수를 추가한다.
    Rollback Segment의 크기와 갯수 결정을 위한 테스트
    1. Rollback segment tablespace 생성
    2. 테스트하기 위해 생성할 Rollback segment 갯수 결정
    3. 같은 크기의 extent로 rollback segment 생성
    extent 갯수는 최대 확장 시 10 - 30 개 정도가 되도록 extent 크기를 결정
    4. Rollback segment의 minextents는 2이다.
    5. 테스트할 rollback segment와 system rollback segment만 online 상태로 한다.
    6. Transaction을 수행하고, 필요하면 application을 load한다.
    7. Rollback segment contention을 확인한다.
    8. Rollback segment가 최대 얼마까지 확장하는지 모니터링한다.
    Rollback Segment extent의 크기와 갯수
    Rollback segment가 자라나는 최대 사이즈를 알 수 있는데, 이 수치를
    "minimum coverage size"라 한다. 만약, contention이 발생한다면 rollback
    segment 갯수를 늘려 가면 테스트를 반복한다. 또한, extent 갯수가 10개
    미만이나 30개 이상이 될 필요가 있다면 extent 크기를 늘리거나 줄이면서
    테스트를 반복해 나가면 된다.
    Rollback segment의 extent 크기를 정할 때, 각 extent는 모두 같은 크기로
    생성할 것을 recommend한다.
    Rollback tablespace의 크기는 extent size의 배수로 지정한다.
    최적의 성능을 위한 rollback segment의 minextents는 20 이상이어야 한다.
    Rollback Segment의 minextents를 20 이상으로 하면 좋은 이유?
    Rollback segment는 dynamic하게 allocate되고, 더 이상 필요 없게 되었을 때
    (만약, Optimal parameter가 셋팅되어 있으면) 모두 commit된 extent에
    대해서는 optimal size 만큼만 남기고 release(deallocate)된다.
    Rollback segment가 적은 수의 extent를 가질 수록, space 할당/해제 시
    extent 수가 많을 때보다 큰 사이즈의 space가 할당되고, 해제된다.
    다음과 같은 예를 들어 보자.
    200M 정도의 rollback segment가 있는데, 100M 짜리 2개의 extent로 이루어져
    있다고 가정해보자. 이 rollback segment에 추가로 space를 할당해야 할 일이
    생겼을 때, 모든 rollback segment extent는 같은 크기를 가져야 한다는 점을
    감안할 때, 100M 짜리 extent를 하나 더 할당해야 할 것이다.
    이 결과 직전의 rollback segment 크기에 비하여 50% 만큼의 크기 증가분이
    생겨나게 된 것인데, 실제 필요로 하는 space보다 더 많은 space가 할당되었을
    것이다.
    이와 반대로, 10M 짜리 extent 20개로 구성된 200M 짜리 rollback segment를
    생각해보자.
    여기에 추가로 space를 할당해야 할 일이 생겼을 때, 10M 짜리 extent 하나만
    추가되면 되는 것이다.
    Rollback segment가 20개 또는 그 이상의 extent로 구성되어 있다면 extent가
    하나 더 증가할 경우가 생겼을 때, rollback segment의 전체 크기가 5% 이상은
    늘어나지 않는다는 것이다.
    즉, space의 할당과 해제 작업이 보다 유연하고 쉽게 일어날 수 있다.
    요약하면, rollback segment의 extent 갯수를 20 이상으로 잡으면 space
    할당과 해제가 "보다" 수월해진다.
    실제로 extent 갯수를 20 이상으로 잡았을 때, 처리 속도가 훨씬 빨라진다는
    사실이 많은 테스트 결과 밝혀졌다.
    한가지 확실한 사실은, space를 할당하고 해제하는 작업은 cost가 적게 드는
    작업이 아니라는 사실이다.
    실제로 extent가 할당/해제되는 작업이 일어날 때, performance가 저하되는
    일이 발생한다는 것이다.
    Extent 하나에 대한 cost는 별 문제가 안 된다고 할지라도, rollback segment
    는 끊임없이 space를 할당하고 해제하는 작업을 반복하기 때문에 작은 크기의
    extent를 갖는 것이 cost 측면에서 훨씬 효율적이라는 결론이다.
    Rollback Segment의 Optimal storage parameter와 Shrink
    Optimal은 deallocate 시에 rollback segment 내에 optimal size 만큼의
    extents를 유지하기 위해 사용하는 rollback segment storage parameter이다.
    다음과 같은 명령으로 사용한다.
    alter rollback segment r01 storage (optimal 1m);Optimal size는 storage 절 안에서 기술되어야 한다.
    Optimal size 이상이 되면, 모두 commit된 extent에 대해서는 optimal size
    만큼만 남기고 release된다.
    즉, optimal에서 지정한 크기 만큼만 rollback segment를 유지하겠다는
    뜻이며, 일정한 크기로 늘어났다가 다음번 tx이 해당 rbs를 취할 경우
    optimal size만큼 resize하는 option이다.
    rbs의 가장 최근에 사용된 extent가 다 차서 다른 extent를 요구할 때
    이 optimal size와 rbs size를 비교하게 되며, 만약 rbs size가 더 크다면
    active tx에 관여하지 않는 tail extent에 대하여 deallocation이 이루어진다.
    특정 rollback segment가 너무 큰 space를 차지해서 다른 rollback segment가
    extent를 발생할 수 있는 여유 공간을 부족하게 만들기 때문에 이를 극복하기
    위해서 optimal size를 지정할 필요가 있다.
    즉, optimal parameter를 지정하면 space availability 측면에서 효율적이다.
    다음과 같이 shrink 명령을 수행하는데, size를 지정하지 않으면 optimal
    size 만큼 shrink된다.
    alter rollback segment [rbs_name] shrink to [size];Shrink 명령 수행 후, 바로 줄어들지 않는 경우가 있는데,
    transaction이 있는 경우는 줄어들지 않고, transaction이 종료되면 줄어든다.
    Optimal이 적용되는 시간은 session이 빠져 나가고 약 5~10 분 정도 걸린다.
    적당한 OPTIMAL SIZE?
    => 20 ~ 30 extents 정도가 적당한데, batch job의 성격에 따라 size는 달라
    지며 각 optimal의 합이 datafile의 size를 넘어도 전혀 상관없다.
    Optimal size를 initial, next와 같게 주면 extent가 발생하는 매번 shrink가
    일어나므로 좋지 않다.
    RBS들의 평균 크기를 구하여 이것을 optimal 크기로 지정하여 사용하는 것을
    권한다.
    다음의 query를 이용하여 peak time에 rollback segment들의 평균 크기를 구한다.
    select initial_extent + next_extent * (extents-1) "Rollback_size", extents
    from dba_segments
    where segment_type ='ROLLBACK';
    이 크기의 평균값(bytes)을 rollback segment들의 optimal size로 사용할 수
    있다.
    주의할 사항은 너무 자주 shrink된다거나 optimal 값을 너무 작게 주면
    ora-1555 : snapshot too old error가 발생할 확률이 높아지므로,
    사용하지 않는 것이 좋을 수도 있고, 되도록 큰 값으로 셋팅해야 한다.
    Rollback segment의 optimal size를 확인할 수 있는 view는 V$ROLLSTAT
    이라는 dynamic view로서 OPTSIZE column에서 확인이 가능하다.
    Example
    none
    Reference Documents
    <Note:69464.1>

  • Missing cleanup() after second (local) transaction rollback

              I wrote a simple dummy ressource adapter with local and XA transaction support and
              discovered some problems when using this adapter within an stateless session bean
              that calls setRollbackOnly().
              If I configure the resource adapter for XATransaction support, everything runs fine:
              WebLogic (or its ConnectionManager) detects the transaction rollback calls my cleanup()
              method and delists the connection from the list of busy connections (so I can do
              my rollback test with this connection a often as I want).
              If I configure my resource adapter for LocalTransaction support, the connection also
              is delisted from the list of busy connections (my cleanup method also is called)
              but after a second rollback test the connection remains in the busy connection list
              (and the cleanup call is missing). So calling the rollback test a third time brings
              a ResourceAllocationException.
              I am wondering whether the "mysterious" java.lang.IllegalStateException: Cannot delist
              resource, transaction has been rolled back
              that comes within my server log has something to do with my problem.
              Attched is my server log that reflects the situation.
              Thanks for any hint,
              juergen
              [connectorlog.txt]
              

    Hi Neelam,
    I am sure what exactly your application needs for single-threaded process.
    If you have some thread context in a given thread that you need for correctly handle all message, then you may try to set max-free-pool-size to 1 on the MDB to force single threaded.
    You can find more information in MDB tuning doc at http://download.oracle.com/docs/cd/E17904_01/web.1111/e13814/mdbtuning.htm#PERFM271
    If all you need is to sequentially handle all messages and it does not matter if the processing is done in a particular thread, you could use a JMS feature called Unit-of-order (UOO) together with MDBs. JMS UOO gives you the capability of making sure all messages in one UOO group are processed sequentially and in the order that them are produced, even when there are multiple consumers or redelivery of messages due to fialures. Messages in different UOO groups can be processed in parallel.
    For more information about UOO can be found at http://download.oracle.com/docs/cd/E17904_01/web.1111/e13727/uoo.htm#JMSPG389
    The following link discusses how to process messages in order with MDBs. Re: Transaction-Rollback on foreign jms queue usin Singletonservice in weblogic
    Hope these links help you find the right solution for your application.
    Dongbo

  • Rollback segments - database logging

    Got a problem...
    We are trying to move data from one database to another using: INSERT INTO table1 (SELECT a,b,c FROM table2@db2). The problem we are having is that the amount of data being moved with this in sert command is too great - we are getting an error indicating that our rollback segment is not large enough - ORA-01562: failed to extend rollback segment number 4.
    Unfortunately, we are not going to be able to increase the size of the rollback segment any further than we already have. Is there a way to disable the database logging that occurs?
    I tried using INSERT INTO table1 dbms_disable_logging (SELECT a,b,c FROM table2@db2), but noticed no difference - same error.
    Any ideas?
    Thank you,
    Dan

    We use select..into all the time in an unlogged mode for speed and rollback space reasons.
    We replicate fifty million row tables with a minimal amount of rollback segment (<50MB).
    In unlogged mode we can replicate 50 million rows in under forty minutes - that's smokin!
    Oracle version 8 or greater introduced this concept. I am running 8.1.6.
    You need to alter the table to disable logging and then perform the select into.
    The table alter only takes seconds.
    ALTER TABLE IDMDBO.DIM_PLANS NOLOGGING
    Then do the select into and then turn logging back on (if so desired).
    You can also disable logging at the table space level.
    Keep in mind there are only a few database operations that can be performed unlogged and select..into is one of them.
    There is currently no way to carte blanche disable transaction logging - hopefully this will be coming soon!
    Cheers.
    - Brendan Sullivan
    null

  • Is "SET TRANSACTION USE ROLLBACK SEGMENT" only a hint

    I have two users, one makes some inserts in a table.
    The other makes a select which visits many rows.
    I have a big rollback-segment.
    To ensure, both users use this rollback-segment I created a logon-trigger:
    CREATE OR REPLACE TRIGGER a_logon AFTER LOGON
    ON DATABASE
    WHEN ( USER IN ( 'SCOTT', 'BOB' ) )
    BEGIN
    SET TRANSACTION USE ROLLBACK SEGMENT rbs_big;
    END;
    But I still get "snapshot to old" messages from the select, which contains the name off an other rollback-segment in the message.
    The trigger really fires, i tested it by adding an insert-statement to a log-table.
    What`s wrong ?

    The set transaction use rollback segment lasts only until you commit or rollback first time and all other transactions in that session will not be forced to that rbs anymore. Other possible solution could be that other users are accessing same tables / updating them so those sessions can't keep the read consistent image available anymore for your sessions.

  • How to online datafile of rollback segment of NO archive log available

    I set offline datafile of rool back segement and rename it
    but when I try to online , get error to recover
    I try to recover but unfortunately all archive log was deleted ( kind of cron job in unix aotu delete these file)
    Pls advice how can I set this data file online without the archive log ( while databse still up and running) Oracle version is 8i not possible to drop datafile by sql.
    in roll back segment I have 3 data files as below and the rb04.dbf is offline
    usr/Systems/1354RM_1_7.1_Master/databases/dbsnml/data/rbs01.dbf
    /usr/Systems/1354RM_1_7.1_Master/databases/dbsnml/data/rbs03.dbf
    /usr/Systems/1354RM_1_7.1_Master/databases/dbsnml/data/rbs04.dbf
    sequence of what I did is below:
    SQL> alter database datafile '/usr/Systems/1354RM_1/databases/dbsnml/data/rbs04.dbf' offline;
    Database altered.
    SQL> alter tablespace RBS rename datafile '/usr/Systems/1354RM_1/databases/dbsnml/data/rbs04.dbf' to '/usr/Systems/1354RM_1_7.1_Master/databases/dbsnml/data/rbs04.dbf';
    Tablespace altered.
    SQL> alter database datafile '/usr/Systems/1354RM_1_7.1_Master/databases/dbsnml/data/rbs04.dbf' online;
    alter database datafile '/usr/Systems/1354RM_1_7.1_Master/databases/dbsnml/data/rbs04.dbf' online
    ERROR at line 1:
    ORA-01113: file 13 needs media recovery
    ORA-01110: data file 13:
    '/usr/Systems/1354RM_1_7.1_Master/databases/dbsnml/data/rbs04.dbf'
    SQL> recover datafile '/usr/Systems/1354RM_1_7.1_Master/databases/dbsnml/data/rbs04.dbf';
    ORA-00279: change 71449081 generated at 12/23/2008 20:18:05 needed for thread 1
    ORA-00289: suggestion :
    /usr/Systems/1354RM_1_7.1_Master/OSRES/data/warm_repl/WarmArchive/arch_1_455922.
    arc
    ORA-00280: change 71449081 for thread 1 is in sequence #455922
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    ORA-00308: cannot open archived log
    '/usr/Systems/1354RM_1_7.1_Master/OSRES/data/warm_repl/WarmArchive/arch_1_455922
    .arc'
    ORA-27037: unable to obtain file status
    HP-UX Error: 2: No such file or directory
    Additional information: 3

    SQL> alter tablespace RBS rename datafile '/usr/Systems/1354RM_1/databases/dbsnml/data/rbs04.dbf' to '/usr/Systems/1354RM_1_7.1_Master/databases/dbsnml/data/rbs04.dbf';Did you rename the file at OS level after you issued above command? Oracle will not rename the file at OS level.
    Other than that, if you plan to change rollback segment tablespace, better create a new one and create new rollback segment in new tablespace and drop the old one.

  • Transaction taking default rollback segment

    Dear al,
    10.2.0.4. on solaris 10
    transaction taking default rollback segment
    set transaction use rollback segment rbs2;
    structure of rbs2:
    Create rollback segment rbs2 tablespace tempt storage (initial 1M next 1M minextents 2 maxextents 1024);
    alter ROLLBACK SEGMENT RBS2 STORAGE
    (MINEXTENTS 20
    MAXEXTENTS UNLIMITED );
    set transaction use rollback segment rbs2;
    when am running the query , am getting the below error :
    ERROR at line 3:
    ORA-01555: snapshot too old: rollback segment number 8 with name "_SYSSMU8$"
    too small
    why still the transaction is referring to system rollback segment "_SYSSMU8$" where I've explicitly set the rollback segment for the transactiom ?
    ANy idea ?
    KAI

    Thanks robert and
    Now, after setting
    undo_retention integer
    2700
    It failed with the below and now it took 20 minutes..
    ERROR at line 4:
    ORA-01555: snapshot too old: rollback segment number 9 with name "_SYSSMU9$"
    too small
    ORA-02063: preceding line from TABS2CALLS
    Elapsed: 00:20:11.40
    Please advise
    Kai

  • Transaction table in rollback segments

    hi guys,
    I have read the following, but am still having a little difficulty conceptualising. Would someone be kind enough to give me a very brief example?
    thanks
    For each rollback segment, Oracle maintains a transaction table--a list of all transactions that use the associated rollback segment and the rollback entries for each change performed by these transactions.

    First of all, the statement is talking about old manual undo management using rollback segment.
    If you check the preceding two paragraph of the statement then it's easier to understand,
    It basically says, Rollback segment hold rollback entries of transaction. To make it easier to track transactions and undo entries, Oracle maintain a table to save such info.
    Rollback segment , transaction and undo entries are one to many relationships.
    Rollback Segment --< Transactions --< Undo Entries
    http://download.oracle.com/docs/cd/B10501_01/server.920/a96524/b_deprec.htm
    Contents of a Rollback Segment
    Information in a rollback segment consists of several rollback entries. Among other information, a rollback entry includes block information (the file number and block ID corresponding to the data that was changed) and the data as it existed before an operation in a transaction. Oracle links rollback entries for the same transaction, so the entries can be found easily if necessary for transaction rollback.
    Neither database users nor administrators can access or read rollback segments. Only Oracle can write to or read them. (They are owned by the user SYS, no matter which user creates them.)
    How Rollback Entries Are Logged
    Rollback entries change data blocks in the rollback segment, and Oracle records all changes to data blocks, including rollback entries, in the redo log. This second recording of the rollback information is very important for active transactions (not yet committed or rolled back) at the time of a system crash. If a system crash occurs, then Oracle automatically restores the rollback segment information, including the rollback entries for active transactions, as part of instance or media recovery. When recovery is complete, Oracle performs the actual rollbacks of transactions that had been neither committed nor rolled back at the time of the system crash.
    When Rollback Information Is Required
    For each rollback segment, Oracle maintains a transaction table--a list of all transactions that use the associated rollback segment and the rollback entries for each change performed by these transactions. Oracle uses the rollback entries in a rollback segment to perform a transaction rollback and to create read-consistent results for queries.

  • 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

  • Forcing a specific rollback segment on a transaction does not seem to work

    Hi!
    We're using Oracle 9.2.0.5.0 on Sun Solaris and we're still configured to use Rollback Segments.
    We have an issue with Snapshot too old due to RBS too small on a long query I attach below for reference:
    set heading off
    set pagesize 0
    set feedback off
    set linesize 200
    <<<<< SET TRANSACTION USE ROLLBACK SEGMENT UMF_RBS_LARGE_TRAN; <<<<<
    SELECT ucms_cards.msisdn
    || ';;' || to_char(to_date(substr(ucms_cards.notes,14+length(ucms_cards.msisdn),19),'MM-DD-YYYY.HH24-MI-SS'),'DD/MM/YYYY HH24:MI:SS')
    || ';;' || to_char(ucms_batches.expiry_date,'dd/mm/yyyy')
    || ';;' || ucms_cards.serial_no
    || ';;' || ucms_cards.serial_no
    || ';;' || ucms_cards.batch_serial_no
    || ';;' || ' '
    || ';;' || CASE ucms_cards.card_status
    WHEN 'used' THEN '1'
    ELSE '0'
    END
    || ';;' || CASE WHEN date_booked_in is null THEN '01/01/1970 00:00:00' ELSE to_char(date_booked_in,'DD/MM/YYYY') || ' 00:00:00' END
    || ';;' || ' '
    from ucms_batches,ucms_cards, UCMS_EVENT_LOG
    WHERE ucms_cards.batch_serial_no = ucms_batches.serial_no
    AND ucms_cards.serial_no = substr(UCMS_EVENT_LOG.ENTITY_ID,11,length(UCMS_EVENT_LOG.ENTITY_ID)-9)
    AND UCMS_EVENT_LOG.PARTY_NO in (0)
    AND UCMS_EVENT_LOG.TIMESTAMP>=TO_TIMESTAMP(TO_CHAR(SYSDATE-1, 'DD-MM-YYYY') || ' 00:00:01', 'DD-MM-YYYY HH24:MI:SS')
    AND UCMS_EVENT_LOG.TIMESTAMP<=TO_TIMESTAMP(TO_CHAR(SYSDATE-1, 'DD-MM-YYYY') || ' 23:59:59', 'DD-MM-YYYY HH24:MI:SS')
    AND UCMS_EVENT_LOG.USER_ID LIKE 'SCP-AGENT1%'
    AND UCMS_EVENT_LOG.EVENT_TYPE_ID IN (1,2)
    AND UCMS_EVENT_LOG.ENTITY_TYPE_ID LIKE 'ucms_cards%'
    UNION
    SELECT ucms_imported_cards.msisdn
    || ';;' || to_char(to_date(substr(ucms_imported_cards.notes,14+length(ucms_imported_cards.msisdn),19),'MM-DD-YYYY.HH24-MI-SS'),'DD/MM/YYYY H24:MI:SS')
    || ';;' || to_char(ucms_imported_cards.expiry_date,'dd/mm/yyyy')
    || ';;' || ucms_imported_cards.serial_no
    || ';;' || ucms_imported_cards.serial_no
    || ';;' || DBMS_UTILITY.GET_HASH_VALUE(ucms_imported_cards.card_type,1,65536)
    || ';;' || ' '
    || ';;' || CASE ucms_imported_cards.card_status
    WHEN 'used' THEN '1'
    ELSE '0'
    END
    || ';;' || '01/01/1970 00:00:00'
    || ';;' || ' '
    from ucms_imported_cards, UCMS_EVENT_LOG
    where ucms_imported_cards.serial_no = substr(UCMS_EVENT_LOG.ENTITY_ID,11,length(UCMS_EVENT_LOG.ENTITY_ID)-9)
    AND UCMS_EVENT_LOG.PARTY_NO in (0)
    AND UCMS_EVENT_LOG.TIMESTAMP>=TO_TIMESTAMP(TO_CHAR(SYSDATE-1, 'DD-MM-YYYY') || ' 00:00:01', 'DD-MM-YYYY HH24:MI:SS')
    AND UCMS_EVENT_LOG.TIMESTAMP<=TO_TIMESTAMP(TO_CHAR(SYSDATE-1, 'DD-MM-YYYY') || ' 23:59:59', 'DD-MM-YYYY HH24:MI:SS')
    AND UCMS_EVENT_LOG.USER_ID LIKE 'SCP-AGENT1%'
    AND UCMS_EVENT_LOG.EVENT_TYPE_ID LIKE '2%'
    AND UCMS_EVENT_LOG.ENTITY_TYPE_ID LIKE 'ucms_imported_cards%';
    As you see we forced the session to use a huge RBS created for the purpose, but strangely after a long while the query fails with a RBS too small failure due to another RBS, not the one specified.
    Is there any chance the UNION or any other component of the query is implicitly opening a new transaction with a different RBS associated?
    Any chance to force the same RBS specified explicitly?
    Thanks!
    Mike

    albertone wrote:
    but strangely after a long while the query fails with a RBS too small failure due to another RBS, not the one specified.You misunderstand snapshot too old. It can be caused by other sessions same as by your session. Assume AFTER your session issued select some other session modified one (or more) tables ucms_batches, ucms_cards, UCMS_EVENT_LOG and committed changes. By the time your select reaches to fetch rows modified by that other session rollback extents in rollback segment used by that other session were reused. You will get snapshot too old. Bottom line - all sessions modifying table(s) used by your select must use rollback segments large enough so they are not overwritten before corresponding rows are needed by your select.
    SY.

  • Does a single transaction, spreeds accross multiple rollback segments?

    Hi,
    Does a single transaction, spreeds accross multiple rollback segments?
    What if , there is not enough space in the allocated rollback segment?
    Thanks
    Naveen.

    With the additional note/ caveat that, assuming you're using a moderately recent version of Oracle and using automatic UNDO management, which you really, really ought to be doing, Oracle is constantly adding, removing, and expanding the rollback segments, making it all but impossible for a rollback segment to be too small unless it (along with all the other active redo segments) exceed the size of your UNDO tablespace.
    Justin

  • Rollback segment for set transaction

    there is way that i can setup a rollback segment for a spacific user or specific transction.
    ALTER ROLLBACK SEGMENT big_rbs ONLINE;
    SET TRANSACTION USE ROLLBACK SEGMENT big_rbs;
    sql .....
    commit;
    ALTER ROLLBACK SEGMENT big_rbs OFFLINE;
    the sql is going for about hour, i was woundering during that time can some else use this rollback segment. i just want this rbs to this user, how i can do that.
    thanks

    I guess i didn't clearify well. let say i created a rbs for specific tranction. before this transaction is start it will turn on this rbs and once this transaction is completed, it issue the command commit, and bring it back to this rbs offline. the question is durning this transaction does any other transaction can come and use this rbs instead of we have lot of other rbs.
    I hope that you get my point.

  • Will rollback failure cause long-running transaction?

    We are getting the following error for one transaction
    [TimesTen][TimesTen 5.1.35 CLIENT]Communication link failure. System call select() failed with OS error 110. This operation has Timed Out. Try increasing your ODBC timeout attribute or check to make sure the target TimesTen Server is running
    After that application tries to do a rollback, but rollback failed.
    Will this transaction become a long-running transaction in server?

    Have you filed a metalink SR to get help on this issue?
    -scheung

Maybe you are looking for