UNDO tablespace getting full

My undo tablespace is getting full because of uncommited deletes performed by jdbc thin client sessions.
How can I solve this problem permanently?
Size of undo tablespace is 5.5GB
I am facing an undo tablespace full issue
Below are the sessions which maybe causing the problem.
select s.sid,
s.serial#,
s.sql_id,
s.prev_sql_id,
s.SCHEMANAME ,
s.OSUSER ,
s.program,
USED_UBLK,USED_UREC from v$session s, v$transaction t where s.taddr=t.addr order by USED_UREC;
3909 30842 fgcp0qn1bqzx9 XLTDB5 xltwrk5 JDBC Thin Client 504 45257
5133 53593 fgcp0qn1bqzx9 XLTDB5 xltwrk5 JDBC Thin Client 07 54482
4525 35108 fgcp0qn1bqzx9 XLTDB10 xltwrk10 JDBC Thin Client 2381 192853
4428 38484 fgcp0qn1bqzx9 XLTDB1 xltwrk1 JDBC Thin Client 8682 634540
For this sql id :fgcp0qn1bqzx9 there are more than 14k executions per hour.
Below is the query for this sql id:
/* TJAPI_SubTrxTransient_deleteTrb1SubTrxTransient_0 */ DELETE FROM TRB1_SUB_TRX_TRANSIENT
Some other details
++++++++++++
Oravle version:11.1.0.7
OS:SunOS
++++++++++++

Perhaps an interesting link:
http://oracledisect.blogspot.com/2008/05/who-is-using-your-undo-space.html
Perhaps you can use Oracle Resource Manager, create a resource plan and switch sessions to a different consumer group once they reach a certain treshold.
http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/dbrm004.htm
Btw are these distributed transactions?
DBA commit other session's transaction?
Edited by: Markus Waldorf on Sep 9, 2010 7:57 PM

Similar Messages

  • TEMP tablespace getting full while inserting a CLOB in Trigger

    We have a Oracle 10g (10.2.0.4.0) DB on a Solaris 9 box which also runs our J2EE web-service application on Weblogic 8sp6 server.
    We get around 220K web-service requests from upstream callers daily to insert data in the main table, say TABLE1, which has daily partitions on a date column. This table has around 21 columns out of which 1 is a CLOB column.
    Now this table has an AFTER INSERT trigger which calls a package procedure to insert the same record into another table, say TABLE2.
    From Java application insert statement in executed in below format using a weblogic jdbc connection pool :
    INSERT INTO TABLE1(COLUMN1, COLUMN2, ........., CLOB_COLUMN,........, COLUMN21) VALUES (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :14, :15, :16, :17, :18, :19, :20);
    Clob object is prepared in application using ojdbc14.jar.
    We are observing a strange issue here. The TEMP tablespace utilization keeps on growing as more and more inserts are executed by application and after ~125K inserts the TEMP tablespace gets full and we start getting ORA-01652 error.
    On further analysis we could see that there are only 7-10 session being maintained but as more and more inserts happen TEMP tablespace utilization goes on increasing for each of these sessions.
    When we tried with inserting just few records and then watching the session details in v$session_wait then we could see that it is in INACTIVE state and waiting for the event ‘SQL*Net message from client’. This does not seem correct as the session has successfully inserted the data and committed the transaction and we can see the data in the tables as well.
    The confusing thing here is when we modify the trigger to pass blank string('' ) instead of the CLOB column to TABLE2 then this issue does not occur. All 200K records are inserted properly and TEMP tablespace utilization also keep always below 1%.
    Can you please help us in solving this issue. Is this related to any oracle issue?
    Inside the package we have tried using DBMS_COPY statement to copy the CLOB column after insert but still same result.
    Code for reference:
    Trigger:
    =====================================
    CREATE OR REPLACE TRIGGER trg
    AFTER INSERT OR UPDATE
    ON TABLE1
    REFERENCING NEW AS NEW OLD AS OLD
    FOR EACH ROW
    BEGIN
    IF (:NEW.date_col > SYSDATE - 2)
    THEN
    IF (:NEW.cat IN (1001, 1002))
    THEN
    pkg.process_change
         (:NEW.COLUMN1,
              :NEW.COLUMN2,
              :NEW.CLOB_COLUMN,
    FLAG
    END IF;
    END IF;
    END;
    =====================================
    Package:
    =====================================
    procedure PKG.Process_change(
    p_COLUMN1 number,
    p_COLUMN2 varchar2,
    p_CLOB_COLUMN clob,
    flag boolean
    ) is
    v_watermark pls_integer;
    v_type varchar2(1);
    begin
    if (flag) then
    v_type := 'U';
    else
    v_type := 'I';
    end if;
    select t_seq.nextval into v_watermark from dual;
    insert into TABLE2(
    COLUMN1 number,
    COLUMN2 varchar2,
    CLOB_COLUMN clob,
    watermark,
    dml_type
    )values (
    p_COLUMN1 number,
    p_COLUMN2 varchar2,
    p_CLOB_COLUMN clob,
    v_watermark,
    v_dml_type
    end;
    =====================================

    My first thought on reading your post is that not only are you using a database version that is now so old it is in extended support and even then not even the most recent patchset for it.
    The first thing I would do is move to 11gR2 and if you can't do that at least get to 10.2.0.5 and apply CLOB relevant patches as well.
    Same goes for your operating system. Solaris 9 is ancient: So move to 10 which has vastly improved memory management.
    To help you further it would be really valuable to know the table layout. For example is this a heap table or an IOT? Is it partitioned? Is this RAC? What size are the CLOBs? Are they stored in-line? Chunk size? etc.
    This page should start you down the right road:
    http://docs.oracle.com/cd/B19306_01/appdev.102/b14249/adlob_tables.htm#sthref204
    But I am also wondering why you would use a trigger to, as you say, "insert the same record into another table." This description is a poster child for "bad design."

  • Tablespace getting full quite often [cannot extend tbs], need a script to add data files on reaching the threshold!!

    Good morning Techies,
    I have a OBIEE environment where developers work on continuous data loads and the tablespaces are filled up quite often throwing cannot extend.
    I have a request from the customer to generate some script or automatic adding up of datafiles.
    Can someone here help with the ways of automizing or easing this situation through some script where it ask the users for the path and DB file size etc and creates a datafile with the inputs.
    Or advise any other ways to handle the situation.
    Regards,
    RanG

    Oracle does not but you can write your own job to execute when you reach certain threshold. You can also do this in a GRID so whenever the metric threshold reached, it executes your procedure. Make sure you check your file system space before adding a datafile.
    With BIGFILE tablespace, you might need to change your backup policies.
    Check these link as well:
    tablespace - Can oracle tablesspaces automatically add smallfile datafiles? - Stack Overflow
    Can Oracle Create New Datafile Automatically?

  • SGEN and tablespaces getting full

    Hello gurus
    I'm running SGEN in a system that I've just installed, and I've noticed that the process of SGEN affects two tablespaces PSAPES620I and PSAPEL620D and I've to increase their sizes in 4Gb total (3gb to PSAPEL620D and 1gb PSAPES620I, is that a normal behavior of SGEN?
    Regards

    Hello,
    Yes. It is quite normal. Don't worry
    Thanks,
    Siva Kumar

  • Set alert for tablespace in grid control when tablespace get 85% full.

    Hi,
    I want to set a tablespace alert in grid control when the tablespace in database get 85% full.
    We should get a alert through a grid control.
    Could you please let me know how to set a alert in grid control for tablsepace usage?
    Thanks,

    HI
    Thanks for the reply.
    I have set the alert the way you asked me do.
    However i am not getting an alert when the tablespace get full by 85%.
    I am not getting alert to our mail.
    Could you please let me know do we need to do anything else.
    I tried using through user defined sql metrics.
    The query which i am using is
    DECLARE
    Type v_filenames is table of dba_data_files.FILE_NAME%type
    index by pls_integer;
    filename v_filenames;
    type v_currsize is table of dba_data_files.BYTES%type
    index by pls_integer;
    currsize v_currsize;
    type v_maxsize is table of dba_data_files.MAXBYTES%type
    index by pls_integer;
    maxsize v_maxsize;
    mark75 number;
    mark500 number;
    n_maxsize number;
    i pls_integer default 1;
    total_files sys.dba_data_files.BYTES%type;
    SUM_BYTES sys.dba_data_files.BYTES%type;
    SUM_MAXBYTES sys.dba_data_files.MAXBYTES%type;
    BEGIN
    SELECT SUM(BYTES)/(1024*1024),SUM(MAXBYTES)/(1024*1024) INTO sum_bytes,SUM_MAXBYTES FROM DBA_DATA_FILES WHERE TABLESPACE_NAME='&&1';
    select SUM(bytes*4/3-maxbytes)/(1024*1024),500-SUM(MAXBYTES)/(1024*1024) into mark75,mark500 FROM DBA_DATA_FILES WHERE TABLESPACE_NAME='&&1';
    if mark75>=mark500 then
    n_maxsize:=mark75;
    else
    n_maxsize:=mark500;
    END IF;
    will the above query will work.
    I dont what condition to put in my case.
    I want to put this condition
    if mark75>=mark500 then
    n_maxsize:=mark75;
    however i am not using it in where clause.
    Thanks.

  • (10gR2)Full UNDO tablespace

    (10gR2)Full UNDO tablespace
    ============================
    PURPOSE
    10gR2 에서 UNDO tablespace 을 NO AUTOEXTEND로 생성한 경우 ,
    transaction 이 실행중인 database 에서는 UNDO tablespace 가
    FULL인 현상을 보게 됩니다.
    이는 10gR2 에서 max retention 을 보장하는 undo retention 의
    메카니즘이 소개되어 autoextend off 인 경우의 UNDO tablespace
    에서 나타나는 현상입니다.
    dba_undo_extents 에서 많은 UNEXPIRED undo segment 가 보이는 것이
    확인되고 UNDO tablespace 가 100% full 인것처럼 나타나는 현상을 볼 수
    있으며 그럼에도 불구하고 ORA-1555 나 ORA-30036 에러는 발생하지 않습니다.
    Explanation
    다음과 같이 많은 UNEXPIRED undo segment 가 조회됩니다.
    SQL> select count(status) from dba_undo_extents where status = 'UNEXPIRED';
    COUNT(STATUS)
    463
    SQL> select count(status) from dba_undo_extents where status = 'EXPIRED';
    COUNT(STATUS)
    20
    SQL> select count(status) from dba_undo_extents where status = 'ACTIVE';
    COUNT(STATUS)
    21
    dba_free_space 을 조회 결과 UNDO tablespace 의 free space 가 존재합니다.
    SUM(BYTES)/(1024*1024) TABLESPACE_NAME
    3 UNDOTBS1
    58.4375 SYSAUX
    3 USERS3
    4.3125 SYSTEM
    103.9375 USERS04
    Transaction 이 실행되면 UNDO tablespace 에 free space 가 조회되지 않는
    FULL 인것처럼 보입니다.
    SUM(BYTES)/(1024*1024) TABLESPACE_NAME
    58.25 SYSAUX
    98 USERS3
    4.3125 SYSTEM
    87.9375 USERS04
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    다음은 AUM 에서의 Undo Block 할당 알고리즘은 다음과 같습니다.
    1. current extent 에 free block 이 있으면 다음 free block 이
    할당됩니다.
    2. 그러나, free block 이 없으면, next extent 가 expired 되었다면 next extent 을
    warp 한후 그 next extent 의 처음 block 을 return 합니다.
    3. 만약 next extent 가 expired 되지 않았다면 UNDO tablespace 로부터 먼저
    space 을 찾습니다. 이때 free extent 가 존재한다면 이를 transaction table 에
    할당하고 해당 next extent 의 첫번째 block 을 return 합니다.
    4. 만약 UNDO tablespace 에 free extent 가 없다면 offline 된 transaction table
    에서 steal 합니다.
    offline 된 transaction table 에서 extent 을 deallocate 한후 이를
    current transaction table 에 add한후 그 add 한 extent 의 첫번째 free block 을
    return 합니다.
    5. offline 된 transaction table 에서 찾을수 없으면 , online 되어 있는
    transaction table 에서 steal 합니다. offline 된 transaction table 에서 extent 을
    deallocate 한후 이를 current transaction table 에 add한후 , 그 add 한 extent 의
    첫번째 free block 을 return 합니다.
    6. 1번~5번 까지 하여도 free block 을 얻지 못하면 이제 UNDO tablespace 의 file 을
    extend 합니다.
    file 이 extend 된다면 이후 current transaction table 에 extent 을 add 한후 ,
    그 extent 의 첫번째 free block 을 return 합니다.
    7. 6번 에서 UNDO tablespace 의 file 을 extend 하지 못했다면 , 자기의 transaction table
    에서 unexpired 된 extent 을 재사용합니다. 그런데 이때 모든 extent 가 busy 하다면
    즉 모두 uncommitted 된 정보라면 8번으로 갑니다. 아니라면 wrap 하여 unexpired 된
    extent 을 사용합니다.
    8. offline 된 transaction table 에서 unexpired 된 extent 을 steal 합니다. 이것이
    실패한다면 online 된 transaction table 에서 unexpired 된 extent 을 steal 합니다.
    9. 8 번까지 수행하고도 free block 을 얻지 못하면 이때서야 오라클에서는
    "ORA-30036 unable to extend segment by %s in undo tablespace '%s' " 에러를
    뿌리며 실패합니다.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    fixed size UNDO tablespace 라 함은 autoextend 가 off 라 datafile 을 자동으로
    더 이상 확장할 수 없음을 말합니다.
    autoextend 가 off 인 경우 10.2 부터는 max retention 이 36 시간 입니다.
    undo_retention 을 900 초(15 분) 으로 설정을 한다고 해도 10gR2 에서는
    max retention 이 36 시간이라 이에 해당하는 undo extent 을 UNEXPIRED 으로 만듭니다.
    그러나 이것이 가용한 undo extent 가 없다는 것이 아니고 , transaction 이 실행되게 되면
    UNEXPIRED undo segment 을 재사용하게 됩니다.
    References
    < Note 413732.1 - Full UNDO Tablespace In 10gR2 >

    A undo tablespace almost full is not necessarily a problem with Oracle 10g ... unless you have some ORA-XXXX errors in the database instance alert.log or in client programs connected to the instance. Is this the case ?
    You should also have a look to V$UNDOSTAT which stores undo statistics for the last 7 days.
    This view has also 2 interesting columns about possible errors related to undo space:
    SOLDERRCNT      NUMBER      Identifies the number of times the error ORA-01555 occurred. You can use this statistic to decide whether or not the UNDO_RETENTION initialization parameter is set properly given the size of the undo tablespace. Increasing the value of UNDO_RETENTION can reduce the occurrence of this error.
    NOSPACEERRCNT      NUMBER      Identifies the number of times space was requested in the undo tablespace and there was no free space available. That is, all of the space in the undo tablespace was in use by active transactions. The corrective action is to add more space to the undo tablespace.

  • Undo tablespace corruption will terminate DB operation

    Hi All,
    Just for the concept, if undotablespace datafile got corrupted due to any reasion, will it force to terminate the DB operation.
    O know this will happen with control file and SYTEM datafile only.
    Please confirm.
    Regards,
    SS

    Hmm what to check? It says the same, it is not mandatory that instance would surely get shut down with the loss of undo tablespace. But you MUST do the recovery of it when the database is closed. I guess that's what that doc is also saying.
    Update:
    See below where I would show the same thing happening. We would start from the undo tablespace getting deleted and would check the alert log for any message. Also we would check the status of teh database after the drop,
    Session 1
    SQL*Plus: Release 10.2.0.1.0 - Production on Thu Aug 6 10:43:35 2009
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    Connected to an idle instance.
    SQL> startup
    ORACLE instance started.
    Total System Global Area  167772160 bytes
    Fixed Size                  1218316 bytes
    Variable Size              79694068 bytes
    Database Buffers           83886080 bytes
    Redo Buffers                2973696 bytes
    Database mounted.
    Database opened.
    SQL> shut immediate
    Database closed.
    Database dismounted.
    ORACLE instance shut down.
    SQL> startup mount
    ORACLE instance started.
    Total System Global Area  167772160 bytes
    Fixed Size                  1218316 bytes
    Variable Size              79694068 bytes
    Database Buffers           83886080 bytes
    Redo Buffers                2973696 bytes
    Database mounted.
    SQL> alter database archivelog;
    Database altered.
    SQL> alter database open;
    Database altered.
    SQL> select name from V$datafile;
    NAME
    --------------------------------------------------------------------------------/u01/app/oracle/oradata/orcl/system01.dbf
    /u01/app/oracle/oradata/orcl/undotbs01.dbf
    /u01/app/oracle/oradata/orcl/sysaux01.dbf
    /u01/app/oracle/oradata/orcl/users01.dbf
    SQL> !rm /u01/app/oracle/oradata/orcl/undotbs01.dbf
    SQL> select status from V$instance;
    STATUS
    ------------  <-- The database is open
    OPEN
    #At this time, in the alert log there was no message.
    #Let's try some ddl/dmls.
    SQL> create table t( a number);
    Table created.
    SQL> insert into t values(1);
    1 row created.
    SQL> commit;
    Commit complete.
    SQL> delete t;
    1 row deleted.
    #No problem so far. Let's issue a checkpoint, this would force oracle to check the file and its status.
    SQL> alter system checkpoint;
    System altered.
    SQL>
    Session-2(Alert log's tail)
    Output snipped
    ORA-01110: data file 2: '/u01/app/oracle/oradata/orcl/undotbs01.dbf'
    Thu Aug  6 11:11:19 2009
    Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_pmon_4402.trc:
    ORA-00376: file 2 cannot be read at this time
    ORA-01110: data file 2: '/u01/app/oracle/oradata/orcl/undotbs01.dbf'
    Thu Aug  6 11:11:19 2009
    Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_pmon_4402.trc:
    ORA-00376: file 2 cannot be read at this time
    ORA-01110: data file 2: '/u01/app/oracle/oradata/orcl/undotbs01.dbf'
    Thu Aug  6 11:11:19 2009
    Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_pmon_4402.trc:
    ORA-00376: file 2 cannot be read at this time
    ORA-01110: data file 2: '/u01/app/oracle/oradata/orcl/undotbs01.dbf'
    #Let's check the status again,
    SQL> select stauts from V$isntance;
    select stauts from V$isntance
    ERROR at line 1:
    ORA-00603: ORACLE server session terminated by fatal error
    Its crashed now as db couldn't find the undo tablespace.
    HTH
    Aman....
    Edited by: Aman.... on Aug 6, 2009 11:28 AM added demo.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

  • While dropping the old undo tablespace we get an error

    Hello friends ,
    i Cannot drop old undo tablespace. While dropping the old undo tablespace we get an error
    ERROR at line 1:
    ORA-01548: active rollback segment '_SYSSMU77$' found, terminate dropping
    tablespace
    SQL> select tablespace_name, status, segment_name from dba_rollback_segs where status != 'OFFLINE';
    TABLESPACE_NAME STATUS SEGMENT_NAME
    SYSTEM ONLINE SYSTEM
    APPS_UNDO NEEDS RECOVERY _SYSSMU77$
    Please help
    Thanks
    Edited by: Vicky C on Dec 23, 2012 9:23 AM

    Hi peter
    We not using rman backup only cold backup.. i tried using cold backup in ramn block media recovery but that recovery needs archive log
    RMAN> BLOCKRECOVER DATAFILE 158 BLOCK 48829;
    Starting blockrecover at 18-DEC-12
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: sid=437 devtype=DISK
    channel ORA_DISK_1: restoring block(s) from datafile copy /var/undo/undo02.dbf
    starting media recovery
    media recovery failed
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of blockrecover command at 12/18/2012 16:45:11
    ORA-00604: error occurred at recursive SQL level 1
    ORA-01422: exact fetch returns more than requested number of rows
    ORA-00279: change 5975281035000 generated at 12/08/2012 06:00:58 needed for thread 1
    ORA-00289: suggestion : /prod/archlogs/1_465484_683651989.dbf
    ORA-00280: change 5975281035000 for thread 1 is in sequence #465484
    ORA-00278: log file '/prod/archlogs/1_465484_683651989.dbf' no longer needed for this re covery
    we did not have block media recovery needed archivelog
    Regards
    Vignesh C

  • Sysaux tablespace is getting full

    Hi,
    can anyone help me find out why my sysaux tablespace is getting full?
    Regards

    Hi,
    The datafiles of System ,and Sysaux tablespaces are in AUTIEXTEND ON mode by default.
    To findout what object is occupying the space
    SELECT OCCUPANT_NAME,OCCUPANT_DESC,SCHEMA_NAME,MOVE_PROCEDURE,SPACE_USAGE_KBYTES from V$SYSAUX_OCCUPANTS;

  • Undo tablespace full even with no active transaction and undo_retention 10s

    The 9.2.0.4 instance is AUM (auto undo management). The undo table space is 50G and is almost full.
    I have set the undo_retention to 10, previously it was 10800 (3hours). I restart the database. Wait quite long time.
    And search on the dba_undo_extents.
    select sum(bytes/(1024*1024*1024)),status from dba_undo_extents d where d.tablespace_name='UNDOTBS2' group by status;
    SUM(BYTES/(1024*1024*1024)) STATUS
    .574447632 EXPIRED
    45.5358887 UNEXPIRED
    It is hard to explain. 10 seconds already passed, at least all the extents should be expired.
    Why so many 45G is still unexpried.
    Is there a bug for undo tablespace? how to fix it.
    It is a rac instance, I am trouble shooting the undo tablespace issues.
    The UNDOTBS2 is for node2 to use.

    If you start the database in exclusive (one instance) mode then the database instance can have only one undo tablespace so I would not expect Oracle to do anything with the undo tablespace for the non-running instance.
    Run you database as normal and generate undo. See if the status changes. If if does that would imply that Oracle does not expire undo unless the undo segments (rbs segments) are accessed. Please post back with results of what you see.
    Between having batch production running on all my databases that use undo tablespaces and the fact we use uniform extent undo tabllespaces I am not in a position to try to duplicate what you are seeing.
    HTH -- Mark D Powell --

  • Tablespace PSAPSR3DB getting full again and agin

    Dears,
    In our PI 7.1 system,Installed on AIX tablespace PSAPSR3DB is getting full very rapidly.
    10 GB space is getting full in 2 days.
    As per our PI developer they are not saving any such huge data in PI, data transfer through PI is going on but I am not sure in that case does PI is storing any data.
    Please suggest how can I stop this rapid increment in data of this tablespace.
    Can I clean some of its data by any way or if possible how not to save data getting transfer through PI.
    Regards,
    Shivam Mittal

    Hi Shivam,
      This table references to standard tablespace for JAVA stack of SAP objects. It's possible that the clean job of Java Stack have been executed with errors. Check this job in Netweaver Administrator application ( http://servername:port/nwa ).
      Have you storing synchronous messages? Maybe you have to tunning the ABAP and Java Stack.
      Have you configured the archive and delete jobs in SXMB_ADM?
    Best regards
    Ivá

  • Cannot drop undo tablespace

    Hello:
    I've created a new undo tablespace undotbs2. I've set it to the default undo tablespace. When I've tried to drop the old one, I get the following error:
    SQL> conn / as sysdba
    Connected.
    SQL> DROP TABLESPACE undotbs1 INCLUDING CONTENTS AND DATAFILES;
    DROP TABLESPACE undotbs1 INCLUDING CONTENTS AND DATAFILES
    ERROR at line 1: ORA-01548: active rollback segment '_SYSSMU7$' found, terminate dropping tablespace
    This is a production database. The service is down because the partition with the Oracle tablespaces: system, undo, temp, etc is full.
    After shutting down the database the problem persist: I cannot drop the old undo tablespace because of the same error.
    I've followed the note 1321093.1. Here the query results:
    Select segment_name, status, tablespace_name, rs.segment_id
    from dba_rollback_segs rs
    where status not in ('ONLINE','OFFLINE');
    _SYSSMU7$ PARTLY AVAILABLE UNDOTBS1 7
    SELECT KTUXEUSN, KTUXESLT, KTUXESQN, /* Transaction ID */ KTUXESTA Status, KTUXECFL Flags
    FROM x$ktuxe
    WHERE ktuxesta !='INACTIVE' AND ktuxeusn =7;
    7 47 382687 ACTIVE DEAD
    SELECT LOCAL_TRAN_ID,GLOBAL_TRAN_ID,STATE,MIXED,COMMIT# FROM DBA_2PC_PENDING;
    No rows
    SELECT LOCAL_TRAN_ID,IN_OUT,DATABASE,INTERFACE FROM dba_2pc_neighbors;
    No rows
    As you can see, there is no pending transactions. No application is connected to the database (service is down), however the database is appling rollbacks since 2 days.
    A lot of archivelogs are being created at rolling back (30 GB archivelogs per hour). Here a tail of the alertlog file:
    Wed Apr 17 06:19:53 2013
    Thread 1 advanced to log sequence 7382
    Current log# 5 seq# 7382 mem# 0: /ora2/origlogs/webfrbr/redo05_m1.log
    Current log# 5 seq# 7382 mem# 1: /ora3/mirrorlogs/webfrbr/redo05_m2.log
    Wed Apr 17 06:21:16 2013
    Thread 1 advanced to log sequence 7383
    Current log# 6 seq# 7383 mem# 0: /ora2/origlogs/webfrbr/redo06_m1.log
    Current log# 6 seq# 7383 mem# 1: /ora3/mirrorlogs/webfrbr/redo06_m2.log
    Wed Apr 17 06:22:41 2013
    Thread 1 advanced to log sequence 7384
    Current log# 4 seq# 7384 mem# 0: /ora2/origlogs/webfrbr/redo04_m1.log
    Current log# 4 seq# 7384 mem# 1: /ora3/mirrorlogs/webfrbr/redo04_m2.log
    Wed Apr 17 06:24:02 2013
    Thread 1 advanced to log sequence 7385
    Current log# 5 seq# 7385 mem# 0: /ora2/origlogs/webfrbr/redo05_m1.log
    Current log# 5 seq# 7385 mem# 1: /ora3/mirrorlogs/webfrbr/redo05_m2.log
    Wed Apr 17 06:25:24 2013
    Thread 1 advanced to log sequence 7386
    Current log# 6 seq# 7386 mem# 0: /ora2/origlogs/webfrbr/redo06_m1.log
    Current log# 6 seq# 7386 mem# 1: /ora3/mirrorlogs/webfrbr/redo06_m2.log
    Wed Apr 17 06:26:46 2013
    Thread 1 advanced to log sequence 7387
    Current log# 4 seq# 7387 mem# 0: /ora2/origlogs/webfrbr/redo04_m1.log
    Current log# 4 seq# 7387 mem# 1: /ora3/mirrorlogs/webfrbr/redo04_m2.log
    Oracle Database - Enterprise Edition 10.2.0.3
    Linux x86-64 Oracle Linux 5
    Please, consider the output of the following queries too:
    select * from V$FAST_START_TRANSACTIONS
    USN 7 -- Undo segment number of the transaction
    SLT 47 -- Slot within the rollback segment
    SEQ 382687 -- Incarnation number of the slot
    STATE RECOVERING --
    UNDOBLOCKSDONE 0 -- Number of undo blocks completed on the transaction
    UNDOBLOCKSTOTAL 2079151 -- Total number of undo blocks that need recovery
    PID 15 -- ID of the current server it has been assigned to
    CPUTIME 1153 -- Time for which recovery has progressed (in seconds)
    PARENTUSN 0 -- Undo segment number of the parent transaction in PDML
    PARENTSLT 0 -- Slot of the parent transaction in PDML
    PARENTSEQ 0 -- Sequence number of the parent transaction in PDML
    XID 07002F00DFD60500 -- Transaction ID
    PXID 0000000000000000 -- Parent transaction ID
    RCVSERVERS 1 -- Number of servers used in the last recovery
    select * from x$ktuxe where ktuxecfl = 'DEAD';
    ADDR 00002B3E808B9BD8
    INDX 145
    INST_ID 1
    KTUXEUSN 7
    KTUXESLT 47
    KTUXESQN 382687
    KTUXERDBF 2
    KTUXERDBB 2080076
    KTUXESCNB 424110769
    KTUXESCNW 0
    KTUXESTA ACTIVE
    KTUXECFL DEAD
    KTUXEUEL 3739
    KTUXEDDBF 0
    KTUXEDDBB 0
    KTUXEPUSN 0
    KTUXEPSLT 0
    KTUXEPSQN 0
    KTUXESIZ 2079151
    select * from v$fast_start_servers;
    RECOVERING 0 15 07002F00DFD60500
    IDLE 0 16 0000000000000000
    IDLE 0 17 0000000000000000
    IDLE 0 18 0000000000000000
    IDLE 0 19 0000000000000000
    IDLE 0 20 0000000000000000
    IDLE 0 21 0000000000000000
    IDLE 0 22 0000000000000000
    IDLE 0 25 0000000000000000
    IDLE 0 26 0000000000000000
    IDLE 0 27 0000000000000000
    IDLE 0 28 0000000000000000
    IDLE 0 29 0000000000000000
    IDLE 0 30 0000000000000000
    IDLE 0 31 0000000000000000
    IDLE 0 32 0000000000000000
    Any ideas to solve this issue?
    Thank you in advance
    Edited by: albrotar on Apr 17, 2013 1:48 AM
    Edited by: albrotar on Apr 17, 2013 1:49 AM
    Edited by: albrotar on Apr 17, 2013 1:51 AM
    Edited by: albrotar on Apr 17, 2013 1:52 AM
    Edited by: albrotar on Apr 17, 2013 1:54 AM

    I've found some errors in alert log file occurred at shutting down the database:
    +...+
    Control autobackup written to DISK device
    handle '/orabck/rman/webfrbr/ora_cfc-3587726327-20130414-00'
    Completed: CREATE UNDO TABLESPACE undotbs2 DATAFILE '/orabck/undo/undotbs02.dbf'
    SIZE 500M reuse autoextend ON NEXT 5M maxsize 32767M
    Sun Apr 14 15:46:43 2013
    Successfully onlined Undo Tablespace 5.
    Undo Tablespace 1 moved to Pending Switch-Out state.
    *** active transactions found in undo tablespace 1 during switch-out.
    Sun Apr 14 15:46:44 2013
    ALTER SYSTEM SET undo_tablespace='UNDOTBS2' SCOPE=BOTH;
    Sun Apr 14 16:11:42 2013
    ALTER ROLLBACK SEGMENT "_SYSSMU7$" offLINE
    Sun Apr 14 16:11:42 2013
    Completed: ALTER ROLLBACK SEGMENT "_SYSSMU7$" offLINE
    Sun Apr 14 16:12:36 2013
    DROP TABLESPACE undotbs1 INCLUDING CONTENTS AND DATAFILES
    Sun Apr 14 16:12:36 2013
    +...+
    Thread 1 advanced to log sequence 5107
    Current log# 4 seq# 5107 mem# 0: /ora2/origlogs/webfrbr/redo04_m1.log
    Current log# 4 seq# 5107 mem# 1: /ora3/mirrorlogs/webfrbr/redo04_m2.log
    Sun Apr 14 19:00:28 2013
    Stopping background process CJQ0
    Sun Apr 14 19:00:29 2013
    Stopping background process QMNC
    Sun Apr 14 19:00:31 2013
    Stopping background process MMNL
    Sun Apr 14 19:00:32 2013
    Stopping background process MMON
    Sun Apr 14 19:00:34 2013
    Shutting down instance (immediate)
    License high water mark = 31
    Sun Apr 14 19:00:34 2013
    Stopping Job queue slave processes
    Sun Apr 14 19:00:34 2013
    Job queue slave processes stopped
    All dispatchers and shared servers shutdown
    Sun Apr 14 19:00:42 2013
    ALTER DATABASE CLOSE NORMAL
    Sun Apr 14 19:04:28 2013
    +...+
    Thread 1 advanced to log sequence 5118
    Current log# 6 seq# 5118 mem# 0: /ora2/origlogs/webfrbr/redo06_m1.log
    Current log# 6 seq# 5118 mem# 1: /ora3/mirrorlogs/webfrbr/redo06_m2.log
    Sun Apr 14 20:11:21 2013
    Errors in file /ora1/admin/webfrbr/bdump/webfrbr_smon_4629.trc:
    +ORA-07445: exception encountered: core dump [_intel_fast_memcpy.A()+10] [SIGSEGV] [Invalid permissions for mapped object] [0x2B6B66003000] [] []+*
    Sun Apr 14 20:11:21 2013
    Errors in file /ora1/admin/webfrbr/bdump/webfrbr_smon_4629.trc:
    ORA-00600: internal error code, arguments: [999], [0x107C14015], [], [], [], [], [], []*
    +ORA-07445: exception encountered: core dump [_intel_fast_memcpy.A()+10] [SIGSEGV] [Invalid permissions for mapped object] [0x2B6B66003000] [] []+*
    Sun Apr 14 20:11:22 2013
    +...+
    Sun Apr 14 20:11:48 2013
    Errors in file /ora1/admin/webfrbr/bdump/webfrbr_pmon_4617.trc:
    ORA-00474: SMON process terminated with error
    Sun Apr 14 20:11:48 2013
    +...+
    The instance could start up, but after this, it is recovering undo and generating redo since 2 days

  • Unable to shrink undo tablespace... Help!

    Hi,
    I have problems to shrink the system undo tablespace, which has grown up to 14 GB.
    I use 9.2. Table space owner is 'SYSTEM', undo_management = AUTO.
    I tried to shrink the greatest rollback segments by the commands
    ALTER SESSION SET UNDO_SUPPRESS_ERRORS = TRUE;
    ALTER ROLLBACK SEGMENT "_SYSSMU6$" SHRINK TO 20 M;
    Oracle confirmed these commands, but nothing happened.
    What am I doing wrong?
    Hermann Mueller

    You have seen the discussion about the undo segments, on the temporary tablespaces, you should be aware that the sort segment of a given temporary tablespace is created at the time the first sort operation takes place. The sort segment continues to grow by means of extent allocation until the segment size has reached the total storage demands of all of the active sorts running on the instance. Oracle will keep on allocating temporary space on demand unless the physical limit states otherwise.
    Temporary segments are produced each time a sort operation (explicit -order by- or implicit -aggregation, reindexing-) requires to sort a set that cannot fit into memory. So if you detect excesive sort usage you should aim your monitors towards the sort operations (reports, reindexing, max, min, aggregations, order by ...). If your system has a DDS behaviour, this kind of operations are frequent as a massive sorting has to be peformed against millions of rows.
    A Temporary tablespace will almost always appear to be near 100% full, that's because once oracle has allocated temporary space it doesn't release it back to the free space, it keeps it allocated even when the sort operation has finished. Criteria behind this fact is similar to the one oracle used to have when the rollback segments were in use, Oracle only allocated space and the dba should perform manual actions to release space, and the criteria is performance. Once it has allocated space this big, there are possibilities that the same circumstances that raised the temporary usage high water mark to this level are repeated, so if oracle keeps the mamimum allocated space, it won't have to allocate the same storage once more.
    Main concern with temporary tablespace growth is not free space itself, but the reasons why this amount of space was allocated, so I suggest you to track the sql statements with sort operations. If you are certain the circumstances that motivated this amount of temporary resources to be allocated won't be repeated again, then you could think of resizing down your temporary tablespace. I suggest you to create a new temporary tablespace with the desired size, and alter the default tempoary tablespace to point to this newly crated temporary tablespace, and finally get rid of the original temporary TS.
    ~ Madrid

  • Undo Tablespace Reuse

    Hi,
    I am using 10.2.0.3.0 on Oracle Solaris 5.10.
    I have an undo tablespace 'UNDOTBS1' which has 5 data files of sizes 60GB. Here are my undo parameters:
    SQL> show parameter undo
    NAME                                 TYPE        VALUE
    undo_management                      string      AUTO
    undo_retention                       integer     900
    undo_tablespace                      string      UNDOTBS1I have a long running batch process, which is inserting billions of records in the table and generating lots of undo. The batch is running for the last two days, and generating lots of undo and developer says that he is committing after 3 million records, though he was told to commit after 10000 records. Now all the data files of undo tablespace have become full except one, which is also getting filled up.
    I see from dba_rollback_segs that there are some 25 segments which are showing status offline.
    does it mean that the oracle will reuse those segments and I dont need to add another data file to the undo tablespace?
    How would I know during this running process, that oracle would reuse space in undo tablespace, or will just throw an error, after exhausting all the data files.
    Thanks and regards

    Hi,
    As the undo segments are used in a curcular fashion, dba_free_space may not give correct picture. use following sql.
    col PCT_USED head '% Used'
    select a.used, b.allocated, round((a.used/b.allocated)*100,2) PCT_USED, c.unexpired, d.active from
    (select sum(BYTES/1024/1024) used from dba_undo_extents where status in ('UNEXPIRED','ACTIVE')) a,
    (select bytes/1024/1024 allocated from dba_data_files where tablespace_name = 'UNDOTBS1') b ,
    (select sum(bytes/1024/1024) unexpired from dba_undo_extents where status = 'UNEXPIRED') c,
    (select sum(bytes/1024/1024) active from dba_undo_extents where status = 'ACTIVE') d
    Here ACTIVE - they are being used
    UNEXPIRED - they will not be released until the undo_retention time. But if all other extents are used, then oracle may reallocate unexpired blocks and any session which is trying to read from unexpired block may received "snapshot too old error".
    EXPIRED - here these blocks will be reused, you can consider them as free.
    Thanks,
    Siva

  • Undo tablespace query

    How to flush the undo tablespace..
    my undo is around 2000mb
    but almost full and for triggering the job for 4millons records
    how to free up the size? or I will hv to add the another datafile?

    You can not really "flush" the undo tablespace. How do you know, that it is almost full? Undo is allocated and re-used. As long as you don't get any database error regarding the undo tablespace, then everything is fine; no need to worry. You are "freeing" the undo-space whenever you say "commit".

Maybe you are looking for