ORA-1691: unable to extend lobsegment SAPR3.SYS_LOB0000233227C00014$$

Hi gurus,
We had been updated the Oracle Database 10g to Oracle Database 11g on Aix box using SAP Application tools for this.
We got successful on the update process.
Now when we check the alert.log file, we noticed the error:
ORA-1691: unable to extend lobsegment SAPR3.SYS_LOB0000233227C00014$$ by 128 in tablespace PSAPEL700D
At the transaction DB13:
BR0100W Internal error for 'lob_segment: SAPR3.GVD_DATAFILE.SYS_LOB0000274858C00028$$' at location BrSegListGet-25
BR0100W Internal error for 'lob_segment: SAPR3.GVD_DATAFILE.SYS_LOB0000274858C00031$$' at location BrSegListGet-25
We already extended the PSAPEL700D tablespace, but didn't work.
May i use your support?
Thanks,
Denis

Hello Keilor,
Thanks for your reply.
I checked this points about this tablespace:
Size (MB) 31.251,00
Free (MB) 15.631,31
Block size (KB) 8
Initial extent (MB) 0,063
Next extent (MB) 0,000
Min. extents 1
Max. extents 2.147.483.645
DATAFILE                                                              SIZE     AUTOEXTEND     MAXSIZE
/oracle/TSA/sapdata1/el700d_6/el700d.data6     5.000,00     YES     5.500,00
/oracle/TSA/sapdata1/el700d_7/el700d.data7      1.000,00     YES     1.500,00
/oracle/TSA/sapdata1/el700d_8/el700d.data8      1.000,00     YES     1.500,00
/oracle/TSA/sapdata1/el700d_9/el700d.data9     5.000,00     YES     5.500,00
/oracle/TSA/sapdata4/el700d_10/el700d.data10     4.000,00     YES     4.500,00
/oracle/TSA/sapdata4/el700d_11/el700d.data11     7.000,00     YES     7.500,00
/oracle/TSA/sapdata5/el700d_1/el700d.data1      203     YES     500
/oracle/TSA/sapdata5/el700d_2/el700d.data2 1.024,00     YES     1.500,00
/oracle/TSA/sapdata5/el700d_3/el700d.data3     1.024,00     YES     1.500,00
/oracle/TSA/sapdata5/el700d_4/el700d.data4     3.000,00     YES     3.500,00
/oracle/TSA/sapdata5/el700d_5/el700d.data5     3.000,00     YES     3.500,00
Thanks again.
Denis

Similar Messages

  • ORA-1691: unable to extend lobsegment APPLSYS.SYS_LOB0000070652C00004$$ by

    hi gurus,
    i got this error when trying to export large data.
    need help ...
    tqvmch

    Hi,
    Please post the application release, database version and the OS.
    How do you get this error?
    Try the steps in (Note: 378377.1 - Ora-1691: Unable To Extend Lobsegment Applsys.Sys_lob0000033489c00004$$ By 92170) and see if it helps.
    Thanks,
    Hussein

  • DB13 Check and update optimizer stat error: ORA-01652: unable to extend tem

    Hi SAP Gurus,
    When running Check and Update Optimizer Statistics in DB13, an error occurs.
    BR0280I BRCONNECT time stamp: 2011-03-10 06.35.52                    
    BR0301E SQL error -1652 at location stats_tab_collect-16             
    ORA-01652: unable to extend temp segment by 12137 in tablespace SYSTEM
    BR0886E Checking/collecting statistics failed for table SAPR3.ACCTIT 
    BR0280I BRCONNECT time stamp: 2011-03-10 06.36.49                    
    BR0850I 3 of 39479 objects processed - 3.522 of 342.781 units done   
    BR0204I Percentage done: 1.03%, estimated end time: 15:47            
    Looking at tablespace SYSTEM in DB02, the percent used is 58. Auto-extent feature is OFF. Will turning the auto-extent ON, remove the error?

    It seems like Your user (by a mistake) have tablespace SYSTEM as temporary tablespace.
    Connect as sysdba in Your database and check which temp tablespaces awaiable, and size of them:
    select tablespace_name, sum(bytes)/1024/1024 "Size of TEMP TBS in MB" from dba_temp_files  group by tablespace_name;
    Check which users having SYSTEM as tamp-tbs:
    select username, temporary_tablespace from dba_users where temporary_tablespace like 'SYSTEM' order by 1;
    Change those users to have one of your temp-tablespaces:
    alter user &username temporary tablespace &&TempTBS;
    It's also a good idea to have autoextend on on Your temp TBS, but remember to set maxsize so you doesn't fill up your disksystem.
    Hope this solve Your problems.
    Regards
    Audun
    DBA

  • ORA-01652: unable to extend temp segment by 128 in tablespace TEMP2

    Dear all,
    received this error when generate a report.
    check the TEMP1 and TEMP2 they all have lot of spaces.
    check the env $APPLLCSP return empty.
    Please advise how to correct this error.
    Regards,
    Payables: Version : 12.0.0
    APXSSIMP module: Supplier Sites Open Interface Import
    APPLLCSP Environment Variable set to :
    Current NLS_LANG and NLS_NUMERIC_CHARACTERS Environment Variables are :
    American_America.UTF8
    Enter Password:
    REP-0069: Internal error
    REP-57054: In-process job terminated:Terminated with error:
    REP-300: MSG-00001: After SRWINIT
    MSG-00002: After Get_Company_Name
    MSG-00003: After Get_NLS_Strings
    MSG-00004: After Importing Suppliers
    MSG-00005: After Get_Header_Information
    ORA-01652: unable to extend temp segment by 128 in tablespace TEMP2
    ==> SELECT assi.org_id C_Rejected_Org_Id,
    MSG-00020: After SRWEXIT
    Report Builder: Release 10.1.2.0.2 - Production on Mon May 11 09:55:36 2009

    >
    check the TEMP1 and TEMP2 they all have lot of spaces.
    >
    How much is "lot" ? :-) How did you determine this "lot" ?
    Pl see MOS Doc 1025288.6 (How to Diagnose and Resolve UNABLE TO EXTEND Errors)
    HTH
    Srini

  • ORA-1653: unable to extend table - but enough space for datafile

    We encountered this problem in one of our database Oracle Database 10g Release 10.2.0.4.0
    We have all datafiles in all tablespaces specified with MAXSIZE and AUTOEXTEND ON. But last week database could not extend table size
    Wed Dec  8 18:25:04 2013
    ORA-1653: unable to extend table PCS.T0102 by 128 in                 tablespace PCS_DATA
    ORA-1653: unable to extend table PCS.T0102 by 8192 in                tablespace PCS_DATA
    Wed Dec  8 18:25:04 2013
    ORA-1653: unable to extend table PCS.T0102 by 128 in                 tablespace PCS_DATA
    ORA-1653: unable to extend table PCS.T0102 by 8192 in                tablespace PCS_DATA
    Wed Dec  8 18:25:04 2013
    ORA-1653: unable to extend table PCS.T0102 by 128 in                 tablespace PCS_DATA
    ORA-1653: unable to extend table PCS.T0102 by 8192 in                tablespace PCS_DATA
    Datafile was created as ... DATAFILE '/u01/oradata/PCSDB/PCS_DATA01.DBF' AUTOEXTEND ON  NEXT 50M MAXSIZE 31744M
    Datafile PCS_DATA01.DBF had only 1GB size. Maximum size is 31GB but database did not want to extend this datafile.
    We used temporary solution and we added new datafile to same tablespace. After that database and our application started to work correctly.
    There is enough free space for database datafiles.
    Do you have some ideas where could be our problem and what should we check?
    Thanks

    ShivendraNarainNirala wrote:
    Hi ,
    Here i am sharing one example.
    SQL> select owner,table_name,blocks,num_rows,avg_row_len,round(((blocks*8/1024)),2)||'MB' "TOTAL_SIZE",
      2   round((num_rows*avg_row_len/1024/1024),2)||'Mb' "ACTUAL_SIZE",
      3   round(((blocks*8/1024)-(num_rows*avg_row_len/1024/1024)),2) ||'MB' "FRAGMENTED_SPACE"
      4   from dba_tables where owner in('DWH_SCHEMA1','RM_SCHEMA_DDB','RM_SCHEMA') and round(((blocks*8/1024)-(num_rows*avg_row_len/1024/1024)),2) > 10 ORDER BY FRAGMENTED_SPACE;
    OWNER           TABLE_NAME                        BLOCKS   NUM_ROWS AVG_ROW_LEN TOTAL_SIZE           ACTUAL_SIZE          FRAGMENTED_SPACE
    DWH_SCHEMA1     FP_DATA_WLS                        14950     168507          25 116.8MB              4.02Mb               112.78MB
    SQL> select tablespace_name from dba_segments where segment_name='FP_DATA_WLS' and owner='DWH_SCHEMA1';
    TABLESPACE_NAME
    DWH_TX_DWH_DATA
    SELECT /* + RULE */  df.tablespace_name "Tablespace",
           df.bytes / (1024 * 1024) "Size (MB)",
           SUM(fs.bytes) / (1024 * 1024) "Free (MB)",
           Nvl(Round(SUM(fs.bytes) * 100 / df.bytes),1) "% Free",
           Round((df.bytes - SUM(fs.bytes)) * 100 / df.bytes) "% Used"
      FROM dba_free_space fs,
           (SELECT tablespace_name,SUM(bytes) bytes
              FROM dba_data_files
             GROUP BY tablespace_name) df
    WHERE fs.tablespace_name   = df.tablespace_name
    GROUP BY df.tablespace_name,df.bytes
    UNION ALL
    SELECT /* + RULE */ df.tablespace_name tspace,
           fs.bytes / (1024 * 1024),
           SUM(df.bytes_free) / (1024 * 1024),
           Nvl(Round((SUM(fs.bytes) - df.bytes_used) * 100 / fs.bytes), 1),
           Round((SUM(fs.bytes) - df.bytes_free) * 100 / fs.bytes)
      FROM dba_temp_files fs,
           (SELECT tablespace_name,bytes_free,bytes_used
              FROM v$temp_space_header
             GROUP BY tablespace_name,bytes_free,bytes_used) df
    WHERE fs.tablespace_name   = df.tablespace_name
    GROUP BY df.tablespace_name,fs.bytes,df.bytes_free,df.bytes_used
    ORDER BY 4 DESC;
    set lines 1000
    col FILE_NAME format a60
    SELECT SUBSTR (df.NAME, 1, 60) file_name, df.bytes / 1024 / 1024 allocated_mb,
    ((df.bytes / 1024 / 1024) - NVL (SUM (dfs.bytes) / 1024 / 1024, 0))
    used_mb,
    NVL (SUM (dfs.bytes) / 1024 / 1024, 0) free_space_mb
    FROM v$datafile df, dba_free_space dfs
    WHERE df.file# = dfs.file_id(+)
    GROUP BY dfs.file_id, df.NAME, df.file#, df.bytes
    ORDER BY file_name;
    Tablespace                      Size (MB)  Free (MB)     % Free     % Used
    DWH_TX_DWH_DATA                     11456       8298         72         28
    FILE_NAME                                                    ALLOCATED_MB    USED_MB FREE_SPACE_MB
    /data1/FPDIAV1B/dwh_tx_dwh_data1.dbf                                 1216       1216             0
    /data1/FPDIAV1B/dwh_tx_dwh_data2.dbf                                10240       1942          8298
    SQL> alter database datafile '/data1/FPDIAV1B/dwh_tx_dwh_data2.dbf' resize 5G;
    alter database datafile '/data1/FPDIAV1B/dwh_tx_dwh_data2.dbf' resize 5G
    ERROR at line 1:
    ORA-03297: file contains used data beyond requested RESIZE value
    Although , we did moved the tables into another TB , but it doesn't resolve the problem unless we take export and drop the tablespace aand again import it .We also used space adviser but in vain .
    As far as metrics and measurement is concerned , as per my experience its based on blocks which is sparse in nature related to HWM in the tablespace.
    when it comes to partitions , just to remove fragmentation by moving their partitions doesn't help  .
    Apart from that much has been written about it by Oracle Guru like you .
    warm regards
    Shivendra Narain Nirala
    how does free space differ from fragmented space?
    is all free space considered by you to be fragmented?
    "num_rows*avg_row_len" provides useful result only if statistics are current & accurate.

  • Oracle Alert - ORA-1652 Unable to extend the Temp Segment

    Hi Team,
    During our DB Reorg we have received the Oracle Alert - ORA-1652 Unable to extend the Temp Segment by 15485 in tablespace :PSAPBTABI.
    Our DBReorg got cancelled..
    We would like to know how we can resolve the above error so that we can reschedule the DB Reorg activity..
    Regds,
    Satyanarayana N

    Hi,
    If you are using UNIX OS, the temp files are created as sparse file due to the OS functionality.
    Altough you have assigned 49 GB the actual size will be very very less.
    You can check the actula file size with du or df command. To remove these sparse condition you will need to perform certain steps.
    Read this note and execute the steps given and then see the file size difference.
    548221 - Temporary Files are created as sparse files
    Do update the message if the OS is different.
    Regards,
    Nilesh

  • ORA-1653: unable to extend table PERFSTAT.STATS

    Hi there,
    I know it's Friday and by the end of the week we normally are not that alert anymore.
    However now we have a very puzzling problem, one that leaves two DBA's very amazed.
    This morning our alert-log of a 9.2.0.8 database on AIX 5.3 showed:
    ORA-1653: unable to extend table PERFSTAT.STATS in tablespace TOOLSEasy, one would say. Extend the tablespace and you're done.
    However the tablespace is on autoextend, not even mentioned that it has 2.5Gb of free space.
    It is also "Locally Managed", with uniform extent size of 16Kb and manual "segment space management"
    The index of this table is in the same tablespace.
    The storage parameters are set to "unlimited" possibilities.
    A manual
    exec statspack.snapresults in the same error where as a
    create table statstest as select * from stats$sqltext ; works fine. The mentioned source table here is the one which seems unable to extend due to the "tablespace restrictions"
    Some storage parameters:
    CREATE TABLE "PERFSTAT"."STATS$SQLTEXT" (
    "HASH_VALUE" NUMBER NOT NULL ENABLE,
    "TEXT_SUBSET" VARCHAR2 (31) NOT NULL ENABLE,
    "PIECE" NUMBER NOT NULL ENABLE,
    "SQL_TEXT" VARCHAR2 (64),
    "ADDRESS" RAW (8),
    "COMMAND_TYPE" NUMBER,
    "LAST_SNAP_ID" NUMBER,
    CONSTRAINT "STATS$SQLTEXT_PK" PRIMARY KEY
    ("HASH_VALUE", "TEXT_SUBSET", "PIECE
    USING INDEX
    PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE
    INITIAL 1048576
    NEXT 1048576
    MINEXTENTS 1
    MAXEXTENTS 2147483645
    PCTINCREASE 0
    FREELISTS 1
    FREELIST GROUPS 1
    BUFFER_POOL DEFAULT
    ) TABLESPACE "TOOLS"
    ENABLE
    PCTFREE 5
    PCTUSED 40
    INITRANS 1
    MAXTRANS 255
    NOCOMPRESS
    LOGGING
    STORAGE (INITIAL 5242880
    NEXT 5242880
    MINEXTENTS 1
    MAXEXTENTS 2147483645
    PCTINCREASE 0
    FREELISTS 1
    FREELIST GROUPS 1
    BUFFER_POOL DEFAULT)
    TABLESPACE "TOOLS"Can this be some kind of Data Dictionairy corruption ??

    virendra.k wrote:
    The next extent clause in creation script says that it is required to have at least 1G of contiguous memory. But the satement fails which means that a chunk of this size cannot be allocated. The situation may arise due to fragmentation of tablespace. See metalink doc id [1020182.6|https://metalink2.oracle.com/metalink/plsql/f?p=130:14:9000433346754441541::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,1020182.6,1,0,1,helvetica] if the largest free chunk >= 1G. Other wise increase the size of tablespace. It may help you.
    I don't understand the result of 1G you calculated.
    I only see: NEXT 1048576 of the primary key, which is 1M and NEXT 5242880 ( 5M) of the table itself.
    However it the Note lead me to the solution.
    The largest piece of contiguous free space in the tablespace is, according to this Note:
    TABLESPACE NAME CONTIGUOUS BYTES
    TOOLS                                 3,407,872 ==> 3Mb
    TOOLS 3,407,872
    TOOLS 3,407,872
    TOOLS 3,301,376
    TOOLS 3,194,880
    TOOLS 3,194,880
    TOOLS 3,194,880
    TOOLS 3,194,880
    TOOLS 3,088,384
    So I executed the following:
    SQL> alter table stats$sqltext storage (next 1m);And subsequently:
    SQL> exec statspack.snap;Which now succeeds !!
    Conclusion: Tablespace REORG needs to be planned.
    One more strange thing however:
    I altered the NEXT_EXTENT size back to 5M, and again the statspack.snap now works OK.
    It must be the either a background COALESCE that solved the problem, or the (maybe existing) corruption in the dictionary is now fixed/gone
    Thanks for the assistance

  • ORA-1652: unable to extend temp segment by 128 in tablespace

    HI,
    i am getting an error in alert log file.....
    Thread 1 advanced to log sequence 1758
      Current log# 2 seq# 1758 mem# 0: /dev/vx/rdsk/racdg/orcl_raw_log12
    Mon Sep  8 12:34:16 2008
    ARC1: Evaluating archive   log 1 thread 1 sequence 1757
    ARC1: Beginning to archive log 1 thread 1 sequence 1757
    Creating archive destination LOG_ARCHIVE_DEST_1: '/arch/log/1_1757.dbf'
    ARC1: Completed archiving  log 1 thread 1 sequence 1757
    Mon Sep  8 13:04:26 2008
    Completed checkpoint up to RBA [0x6de.2.10], SCN: 0x0000.6c1f757f
    Mon Sep  8 13:49:16 2008
    ORA-1652: unable to extend temp segment by 128 in tablespace                 TEMPI don';t want to add datafile
    SQL> select bytes,maxbytes,increment_by from dba_temp_files;
         BYTES   MAXBYTES INCREMENT_BY
    6134169600          0            0
    SQL> select TABLESPACE_NAME, BYTES_USED, BYTES_FREE from V$TEMP_SPACE_HEADER;
    TABLESPACE_NAME                BYTES_USED BYTES_FREE
    TEMP                           6037700608   96468992i have also referred metalink note: 19047.1
    Is there any way to avoid this problem without adding any datafile........

    how to find out which session is using temp tablespace
    SQL> select * from v$sort_usage;
    USERNAME                       USER                           SESSION_ADDR
    SESSION_NUM SQLADDR             SQLHASH TABLESPACE
    CONTENTS  SEGTYPE     SEGFILE#    SEGBLK#    EXTENTS     BLOCKS   SEGRFNO#
    DATA3                        DATA3                        000000044D84F558
          25860 00                        0 TEMP
    TEMPORARY DATA             201     183561          1        128          1pls correct me if the above query is worng to find out the no. of session s using temp tablespace
    i think we have already allocated good amt of space to pga_aggregate_target
    SQL> show parameter pga
    NAME                                 TYPE        VALUE
    pga_aggregate_target                 big integer 524288000
    SQL>Edited by: user00726 on Sep 8, 2008 2:29 AM

  • The Sky is Falling! ORA-01652: unable to extend temp segment by 128

    So we currently have a production problem and I'm not so in the know as a lowly java developer and not an Oracle expert.
    We keep getting this error(below) when a certain heavy query hits the DB.
    Our DBA claims that the tablespace for 'TABLE_SPACE_NAME_HERE' is 20GB of space and that the problem is the query.
    The query has been running fine for many many months but all of a sudden is presenting a problem and we have to do something quick.
    We tried bouncing the application server but the error came right back when the big select query gets hit.
    Any thoughts? Help! : )
    java.sql.SQLException: ORA-01652: unable to extend temp segment by 128 in tablespace TABLE_SPACE_NAME_HERE
         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:113)
         at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
         at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
         at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:754)
         at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:219)
         at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:972)
         at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1074)
         at oracle.jdbc.driver.T4CPreparedStatement.executeMaybeDescribe(T4CPreparedStatement.java:854)
         at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1156)
         at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3415)
         at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3460)
         at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:296)

    LosLobo wrote:
    So, the next question... what is our lesson learned in this case?It depends on the root cause.
    Our DBA thinks 30GB is an unreasonable size for the tablespace and is fingering the select query that was causing the error to occur. Their solution is move to the query to a view and then reduce the tablespace back to 20GB.
    My thoughts are shouldn't the DB be able to handle a query that has been running fine for the last couple years? Also, if we do what is suggested what would prevent another query from coming along and causing the same issue all over again?Has the DBA identified the source of the issue? Did the query plan change? It's possible that something with statistics (or with some configuration change) causes Oracle to believe that two different query plans are roughly equally efficient. One plan might take substantially more TEMP space than another. It's possible that Oracle had been choosing the plan that involved less TEMP space being used and recently changed to preferring the plan that takes more TEMP space. If that's the issue, you may want to force Oracle to use the plan that involves less TEMP usage.
    Regardless of your TEMP tablespace size, another query may come along that causes TEMP to run out of space. Or data growth may cause TEMP to run out of space. Or an increase in the number of users may cause TEMP to run out of space. Ideally, the DBAs would be identifying how much TEMP space is used over the course of the day so that if things are growing steadily additional space can be added as necessary. If TEMP space increases dramatically because a query plan changes, however, even the best monitoring is unlikely to be able to predict that level of growth.
    Whether 30 GB is unreasonable (or whether 20 GB is unreasonable) will depend heavily on your application. We don't know enough to be able to comment. A TB-sized OLTP database serving millions of customers will have very different TEMP requirements than a multi-TB data warehouse which will have very different TEMP requirements than a small department-level application.
    My surmising is we must have just crossed a watermark threshold and the simplest most reasonable solution is to just leave the larger tablespace size.Why do you believe this is the case? It is entirely possible that you need more TEMP because your TEMP usage has been growing slowly over time. It is entirely possible that the query in question has always been using more TEMP space than it really should and that you finally have enough usage to cause the problem to bubble to the surface. It is entirely possible that the query used a reasonable amount of TEMP for the past couple years and suddenly started using far more because of a query plan change. Once you identify the source of the problem, we can figure out the appropriate solution. Without knowing the source of the problem, we're all just guessing.
    Justin

  • ORA-01652: unable to extend temp segment by 128 in tablespace TEMP

    Hi,
    I am getting the following error while executing an insert query.
    ORA-01652: unable to extend temp segment by 128 in tablespace TEMP.
    I have tried increasing the TEMP tbsp size it got resolved temporarily but occurred again after few days.
    When the problem occured, following query shows all insert queries in TEMP tablespace and one of them consumes about 5GB and others are about 24MB.
    SELECT S.sid || ',' || S.serial# sid_serial, S.username,
    T.blocks * TBS.block_size / 1024 / 1024 mb_used, T.tablespace,
    T.sqladdr address, Q.hash_value, Q.sql_text
    FROM v$sort_usage T, v$session S, v$sqlarea Q, dba_tablespaces TBS
    WHERE T.session_addr = S.saddr
    AND T.sqladdr = Q.address (+)
    AND T.tablespace = TBS.tablespace_name
    ORDER BY S.sid;
    The insert query is :
    INSERT INTO SEOSDATA (ENTRYID,DOMAINNAME,USERNAME,EVENTTYPE,LOGNAME,TIMSTAMP,SOURCE,COMPUTERNAME,EVENTID,EVENTCATEGORY,SEARCHSTRINGS,MSGTEXT) VALUES (ENTRYID_SEQ.NEXTVAL,:1,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11)
    It is not expected that an insert query consumes such a huge memory.
    Can someone help me in figuring out what the problem is.
    What might have gone wrong? Seems like sorting is used, why an insert query uses sorting?
    Regards
    Ishu

    Hi,
    Insert statement should not use TEMP tablespace. Please check with following query which user and session id is using TEMP tablespace.
    SELECT b.tablespace, b.segfile#, b.segblk#, b.blocks, a.sid, a.serial#,
    a.username, a.osuser, a.status
    FROM v$session a,v$sort_usage b
    WHERE a.saddr = b.session_addr
    ORDER BY b.tablespace, b.segfile#, b.segblk#, b.blocks;
    Dilipkumar Patel.

  • ORA-1688: UNABLE TO EXTEND TABLE IN SYSAUX TABLESPACE

    Hi,
    We are running oracle10g R-2 (10.2.0.2.0) on solaris 10.
    In our alert log file we get following message interminantely:-
    ORA-1688: unable to extend table SYS.WRH$_ACTIVE_SESSION_HISTORY partition
    WRH$_
    ACTIVE_455891297_399 by 128 in tablespace SYSAUX
    MMON Flush encountered SYSAUX out of space error(1688).
    MMON (emergency) purge of WR snapshots (243) and older
    The above error reproduce after every 1 hour.
    Thanks & Regards
    Rishikesh

    It seems your tablespace SYSAUX to be little: you need to make it bigger or add another datafile. Using "Oracle Enterprise Manager" is quite easy to do, in section "Storage Manager".

  • ORA-01653: unable to extend table... problem

    Hello.
    I'm using Oracle 8i 8.1.5.0.2 SE on Adelinux 6.2(kinda localized version of RedHat 6.2).
    When I run my Pro*C module, the following error message appeared even though there's enough free space on that tablespace.
    ORA-01653: unable to extend table UALMAS.TBL_OPTIONS_T by 466608 in tablespace TALMAS
    The free space of TALMAS tablespace is as follow:
    --->> cut here <<---
    SQL> SELECT TABLESPACE_NAME,BYTES FROM DBA_FREE_SPACE;
    TABLESPACE_NAME BYTES
    TALMAS 284839936
    TALMAS 204271616
    TALMAS 732184576
    TALMAS 846002176
    TALMAS 547749888
    TALMAS 305330176
    TALMAS 194267136
    TALMAS 50661376
    TALMAS 561453056
    TALMAS 108539904
    10 rows selected.
    --->> cut here <<---
    I use COMMIT at the end of some part of insertion, and the free space listed is not the result of rollback I think.
    Does anyone have such an experience?
    Can anyone tell me how to solve this problem?
    Any comment would be appreciated.
    @Wings... of Icarus
    null

    Hi,
    Maxsize unlimited means the maxsize of 32GB. Check if your tablespace is reaching its maxsize, you may have to add a datafile to the tablespace. Sometime, maxfile is not reached but you do not enough disk in the file system to extend the tablespace. So check the file system utilization as well.
    HTH

  • ORA-1653: unable to extend table

    hi guys!
    its the second time am posting this message! had this error in this alert.log
    ORA-1653: unable to extend table APPLSYS.WF_LOCAL_ROLES_STAGE by 4849950 in tablespace APPLSYSD
    the tablespace is APPLSYSD free_space 59390.4688M used_space 22495.7031M
    initial extent 40960, next_extent 1048576, max_extent 2147483645 and pct_free is set to 0!
    the tablespace contains three datafiles and their percentage used is 36%, 35% and 12%. I dont really understand how this error comes! how come in the error, it wants to extend by 4849950 while the value for next_extent is 1048576? could some one please help me overcome this problem??
    Thanls

    hi.
    here are the output to some queries.
    select initial_extent,next_extent, pct_increase from dba_tablespaces where tablespace_name='APPLSYSD'
    INITIAL_EXTENT NEXT_EXTENT PCT_INCREASE
    40960 40960 0
    select initial_extent, next_extent, pct_free, pct_increase from dba_tables where owner='APPLSYS' and table_name=('WF_LOCAL_ROLES_STAGE')
    INITIAL_EXTENT NEXT_EXTENT PCT_FREE PCT_INCREASE
    40960 1048576 10 0
    select table_name,NEXT_EXTENT,PCT_INCREASE from dba_tables where owner='APPLSYS' and table_name='WF_LOCAL_ROLES_STAGE';
    TABLE_NAME NEXT_EXTENT PCT_INCREASE
    WF_LOCAL_ROLES_STAGE 1048576 0
    select OWNER,SEGMENT_NAME,NEXT_EXTENT,PCT_INCREASE,EXTENTS from dba_segments where owner='APPLSYS' and segment_name='WF_LOCAL_ROLES_STAGE';
    OWNER SEGMENT_NAME NEXT_EXTENT PCT_INCREASE EXTENTS
    APPLSYS WF_LOCAL_ROLES_STAGE 1048576 0 1

  • ORA-1653 (unable to extend table) and ORA-1654  (unable to extend index)

    Hi,
    We recently installed 12c.r1 and have it running now form some three weeks. About 100 assets currently in it.
    When trying to add a new discovery profile a received an error message from the BUI, in the cacao log from the EC i found a lot java exceptions caused (probably by : Internal Exception: java.sql.SQLException: ORA-01653: unable to extend table OC.PERSISTENTALERT by 8 in tablespace OC_DEFAULT_TS)
    When looking at the alert log from the database i found its full with ORA-1653 and ORA-1654 messages; (and still those errors are being put in the alert logfile on a continues basis.)
    ORA-1653: unable to extend table OC.PERSISTENTALERT by 8 in tablespace OC_DEFAULT_TS
    ORA-1653: unable to extend table OC.PERSISTENTALERT by 8 in tablespace OC_DEFAULT_TS
    ORA-1653: unable to extend table OC.VDO_SERVICE_INFO by 128 in tablespace OC_DEFAULT_TS
    ORA-1653: unable to extend table OC.VDO_SERVICE_INFO by 128 in tablespace OC_DEFAULT_TS
    ORA-1653: unable to extend table OC.PERSISTENTALERT by 8 in tablespace OC_DEFAULT_TS
    ORA-1653: unable to extend table OC.PERSISTENTALERT by 8 in tablespace OC_DEFAULT_TS
    And
    ORA-1654: unable to extend index OC.VMB_RESOURC_ASSOCIA_ID_UNQIDX by 8 in tablespace OC_DEFAULT_TS
    ORA-1654: unable to extend index OC.VMB_RESOURC_ASSOCIA_ID_UNQIDX by 8 in tablespace OC_DEFAULT_TS
    ORA-1654: unable to extend index OC.VMB_RESOURC_ASSOCIA_ID_UNQIDX by 8 in tablespace OC_DEFAULT_TS
    ORA-1654: unable to extend index OC.VMB_RESOURCE_CAPABIL1_UNQIDX by 128 in tablespace OC_DEFAULT_TS
    ORA-1654: unable to extend index OC.VMB_RESOURCE_CAPABIL1_UNQIDX by 128 in tablespace OC_DEFAULT_TS
    ORA-1654: unable to extend index OC.VMB_RESOURCE_CAPABIL1_UNQIDX by 128 in tablespace OC_DEFAULT_TS
    Only thing i could think of would be a space issue in the filesystem. But there's still some 15G of free space available for the DB to extend.
    Any clues as to where to find the cause of this?
    Thanks in advance
    Kind regards
    Patrick

    Hi,
    Sorry for the late response (wasn't in the office last week)
    I'v extended the zpool with additional LUN's , now there is 168GB of free space (total DB size now 42GB) so, efficient free space should be available. After a restart of the DB unfortunately again the alert file is flooded with ORA-1653 / 64 messages on a continues basis;
    ORA-1654: unable to extend index OC.VDO_SENSOR_INFO_ID_UNQIDX by 8 in tablespace OC_DEFAULT_TS
    ORA-1654: unable to extend index OC.VDO_SENSOR_INFO_ID_UNQIDX by 8 in tablespace OC_DEFAULT_TS
    ORA-1654: unable to extend index OC.VDO_ALERT_MONITOR_ST1_UNQIDX by 8 in tablespace OC_DEFAULT_TS
    ORA-1654: unable to extend index OC.VDO_ALERT_MONITOR_ST1_UNQIDX by 8 in tablespace OC_DEFAULT_TS
    ORA-1654: unable to extend index OC.VDO_SENSOR_INFO_ID_UNQIDX by 8 in tablespace OC_DEFAULT_TS
    ORA-1654: unable to extend index OC.VDO_SENSOR_INFO_ID_UNQIDX by 8 in tablespace OC_DEFAULT_TS
    ORA-1654: unable to extend index OC.VDO_SENSOR_INFO_ID_UNQIDX by 8 in tablespace OC_DEFAULT_TS
    ORA-1654: unable to extend index OC.VDO_SENSOR_INFO_ID_UNQIDX by 8 in tablespace OC_DEFAULT_TS
    ORA-1653: unable to extend table OC.PERSISTENTALERT by 8 in tablespace OC_DEFAULT_TS
    ORA-1653: unable to extend table OC.PERSISTENTALERT by 8 in tablespace OC_DEFAULT_TS
    Mon Jul 16 13:56:46 2012
    ORA-1653: unable to extend table OC.PERSISTENTALERT by 8 in tablespace OC_DEFAULT_TS
    ORA-1653: unable to extend table OC.PERSISTENTALERT by 8 in tablespace OC_DEFAULT_TS
    ORA-1653: unable to extend table OC.PERSISTENTALERT by 8 in tablespace OC_DEFAULT_TS
    ORA-1653: unable to extend table OC.PERSISTENTALERT by 8 in tablespace OC_DEFAULT_TS
    ORA-1653: unable to extend table OC.PERSISTENTALERT by 8 in tablespace OC_DEFAULT_TS
    ORA-1653: unable to extend table OC.PERSISTENTALERT by 8 in tablespace OC_DEFAULT_TS
    Mon Jul 16 13:56:55 2012
    ORA-1654: unable to extend index OC.VDO_SENSOR_INFO_ID_UNQIDX by 8 in tablespace OC_DEFAULT_TS
    ORA-1654: unable to extend index OC.VDO_SENSOR_INFO_ID_UNQIDX by 8 in tablespace OC_DEFAULT_TS
    Mon Jul 16 13:57:02 2012
    ORA-1653: unable to extend table OC.PERSISTENTALERT by 8 in tablespace OC_DEFAULT_TS
    ORA-1653: unable to extend table OC.PERSISTENTALERT by 8 in tablespace OC_DEFAULT_TS
    ORA-1653: unable to extend table OC.PERSISTENTALERT by 8 in tablespace OC_DEFAULT_TS
    ORA-1653: unable to extend table OC.PERSISTENTALERT by 8 in tablespace OC_DEFAULT_TS
    etc,.....etc,......etc,.....
    Unsure what to do.
    Check the PCT_USED with a script and found;
    NAME MBYTES USED FREE PCT_USED LARGEST MAX_SIZE PCT_MAX_USED EXTENT_MAN SEGMEN
    USERS 5 1.31 3.69 26.25 3.69 32767.98 0 LOCAL AUTO
    OC_INDEX_TS 100 1 99 1 99 32767 0 LOCAL AUTO
    OC_DATA_TS 100 1 99 1 99 32767 0 LOCAL AUTO
    TEMP 174 174 0 100 0 32767.98 .53 LOCAL MANUAL
    SYSTEM 720 711.31 8.69 98.79 8 32767.98 2.17 LOCAL MANUAL
    SYSAUX 1230 1148.44 81.56 93.37 64.44 32767.98 3.5 LOCAL AUTO
    UNDOTBS1 7625 445.75 7179.25 5.85 3656 32767.98 1.36 LOCAL MANUAL
    OC_DEFAULT_TS 32767 32767 0 100 0 32767 100 LOCAL AUTO
    8 rows selected.
    Seems the OC_DEFAULT_TS is 100% full.
    Shouldn't this autoextend?!?
    I'm no DBA, and the OPCenter installation is default 'out-of-the-box' on a new system. Only running for a month now with about 100 assets.
    Any help appreciated
    Thanks
    Patrick
    Edited by: Patrick on Jul 16, 2012 3:13 PM
    Edited by: Patrick on Jul 16, 2012 3:15 PM

  • ORA-01653 unable to extend table.

    Hi All,
    I am Using oracle 9i on Windows XP box
    I got the following error messages .
    ORA-01653: unable to extend table SCOTT.EMP2 by 128 in tablespace ORADATA
    I was inserting 557056 rows from emp table to emp2 table , by issuing
    sql> insert into emp2 select * from emp ;
    My emp2 table is in tablespace oradata which I created by issuing.
    create tablespace oradata
    datafile 'c:\oratemp\data01.dbf' size 20m
    extent management local
    autoallocate
    segment space management auto
    Please help me to explain why I got this error and how to solve this error.
    Thanks.

    Your ORADATA tablespace got filled, ang got no free space to accommodate new insertions.
    So, resize the datafile of ORADATA tablespace using the following statement.
    SQL> CONNECT /AS SYSDBA
    SQL> ALTER DATABASE DATAFILE 'c:\oratemp\data01.dbf' RESIZE 100M;
    Regards,
    Sabdar Syed.

Maybe you are looking for