ORA-1654 を防ぐには?

Windows Server 2003 R2 で Oracle9i R2を運用している時にORA-1654が発生しました。
発生時のDBの使用状況
   表領域情報: 使用している領域 サイズ:32,768M 増分:1,000M 最大:Unlimited 使用済:32,767M 状態:ONLINE
             TEMP:8,388M
UNDO:5,114M
   サーバーHDD:空き容量300G以上
   で発生しました。
   その後、再度同じ処理を実行したところORA-1654は発生せずに終了しました。
こちらの 他の質問で
-- 引用開始 --
自動拡張の最大サイズに達しているケースが
まず考えられますね。もう一つはデータファイル自体が最大サイズ
(DB_BLOCK_SIZE×4M)に達している場合でしょうか?
http://otn.oracle.co.jp/forum/message.jspa?messageID=2014707
-- 引用終了 --
とあるのですが表領域の最大をUnLimitedにしていたら自動で最大サイズは設定した増分ずつ
増えてORA-1654が発生することは無いと思うのですが間違っているのでしょうか?
アドバイス等ご教示お願いします。
-- アラートログファイルより抜粋 --
Sat Feb 16 04:36:42 2013
ORA-1654: unable to extend index IPS_USER.SN1F_MKEY by 128 in tablespace      IPS_USER
不足情報等ございましたらご指摘のほうも頂ければ幸いですので宜しくお願いします。

IPS_USER表領域に属するデータファイルの情報を提示できますでしょうか。
具体的には以下の出力をタグで表示して頂ければと。
[code]
SQL> SELECT * FROM DBA_DATA_FILES where tablespace_name='IPS_USER';
[/code]
# linesizeやpagesizeは適切に設定をお願いします
※※以下追記
使用している領域 サイズ:32,768M 増分:1,000M 最大:Unlimited 使用済:32,767M 状態:ONLINE
すみません、9iと言う事は、SMALLFILEですね。
SMALLFILEの最大サイズは32GBになります(8KBブロックの場合)。
データファイルを該当の表領域に追加すれば解消すると思います。
こちらのマニュアルの「4.データベースの制限事項」の「物理データベースの制限」にそれっぽい事が書いてあります。
<<http://otndnld.oracle.co.jp/document/oracle9i/920/generic/server/J06256-02.pdf>>
Edited by: asahideO on 2013/02/16 11:37                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

Similar Messages

  • 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

  • Can not connect to DB after this message: ORA-1654: unable to extend index

    Hi Experts;
    Right now I got this problem in my DB, ORA-1654: unable to extend index RADIT.RADITDATA_USERNAME_IDX by 8192 in tablespace RADIT_DATA_IDX.
    But, I was trying to connect to the DB, but it's not accepting connections.
    This DB is oracle 9i , running in Red Hat Enterprise Linux ES release 3.
    I was looking thru google, but all the options is to alter the tablesplace/datafile, but I can not do that, because I cann't connect.
    Have an idea, what can I do?
    Please, any idea is welcome.
    Thanks for your help.
    Regards
    Al

    Here are the lines requested:
    hu Jun 14 22:00:21 2012
    Thread 1 advanced to log sequence 52031
    Current log# 3 seq# 52031 mem# 0: /home/oracle/oracle/product/10.2.0/redo/redo_g3_01.log
    Current log# 3 seq# 52031 mem# 1: /home/oracle/oracle/product/10.2.0/redo/redo_g3_02.log
    Fri Jun 15 05:00:36 2012
    ORA-1654: unable to extend index RADIT.RADITDATA_USERNAME_IDX by 8192 in tablespace RADIT_DATA_IDX
    Fri Jun 15 21:00:46 2012
    Thread 1 advanced to log sequence 52032
    Current log# 2 seq# 52032 mem# 0: /home/oracle/oracle/product/10.2.0/redo/redo_g2_01.log
    Current log# 2 seq# 52032 mem# 1: /home/oracle/oracle/product/10.2.0/redo/redo_g2_02.log
    Sat Jun 16 05:00:48 2012
    ORA-1654: unable to extend index RADIT.RADITDATA_USERNAME_IDX by 8192 in tablespace RADIT_DATA_IDX
    Sat Jun 16 19:07:19 2012
    Thread 1 advanced to log sequence 52033
    Current log# 1 seq# 52033 mem# 0: /home/oracle/oracle/product/10.2.0/redo/redo_g1_01.log
    Current log# 1 seq# 52033 mem# 1: /home/oracle/oracle/product/10.2.0/redo/redo_g1_02.log
    Sun Jun 17 05:00:20 2012
    ORA-1654: unable to extend index RADIT.RADITDATA_USERNAME_IDX by 8192 in tablespace RADIT_DATA_IDX
    Sun Jun 17 22:00:48 2012
    Thread 1 advanced to log sequence 52034
    Current log# 3 seq# 52034 mem# 0: /home/oracle/oracle/product/10.2.0/redo/redo_g3_01.log
    Current log# 3 seq# 52034 mem# 1: /home/oracle/oracle/product/10.2.0/redo/redo_g3_02.log
    Mon Jun 18 05:00:19 2012
    ORA-1654: unable to extend index RADIT.RADITDATA_USERNAME_IDX by 8192 in tablespace RADIT_DATA_IDX
    Mon Jun 18 22:00:47 2012
    Thread 1 advanced to log sequence 52035
    Current log# 2 seq# 52035 mem# 0: /home/oracle/oracle/product/10.2.0/redo/redo_g2_01.log
    Current log# 2 seq# 52035 mem# 1: /home/oracle/oracle/product/10.2.0/redo/redo_g2_02.log
    Tue Jun 19 05:03:21 2012
    ORA-1654: unable to extend index RADIT.RADITDATA_USERNAME_IDX by 8192 in tablespace RADIT_DATA_IDX
    Tue Jun 19 19:09:42 2012
    Thread 1 advanced to log sequence 52036
    Current log# 1 seq# 52036 mem# 0: /home/oracle/oracle/product/10.2.0/redo/redo_g1_01.log
    Current log# 1 seq# 52036 mem# 1: /home/oracle/oracle/product/10.2.0/redo/redo_g1_02.log
    Wed Jun 20 05:00:34 2012
    ORA-1654: unable to extend index RADIT.RADITDATA_USERNAME_IDX by 8192 in tablespace RADIT_DATA_IDX
    Wed Jun 20 21:22:40 2012
    Thread 1 advanced to log sequence 52037
    Current log# 3 seq# 52037 mem# 0: /home/oracle/oracle/product/10.2.0/redo/redo_g3_01.log
    Current log# 3 seq# 52037 mem# 1: /home/oracle/oracle/product/10.2.0/redo/redo_g3_02.log
    Thu Jun 21 05:00:54 2012
    ORA-1654: unable to extend index RADIT.RADITDATA_USERNAME_IDX by 8192 in tablespace RADIT_DATA_IDX
    Thu Jun 21 21:00:12 2012
    Thread 1 advanced to log sequence 52038
    Current log# 2 seq# 52038 mem# 0: /home/oracle/oracle/product/10.2.0/redo/redo_g2_01.log
    Current log# 2 seq# 52038 mem# 1: /home/oracle/oracle/product/10.2.0/redo/redo_g2_02.log
    Hope you can get a better idea of this problem.

  • Newbie: ORA-1654,ORA-1688,ORA-1653 "unable to extend index/table"

    Hi!
    I have gotten a lot of these three ORA-erros in my alertlog:
    ORA-1654: unable to extend index SYS.SYS_IOT_TOP_8835 by 128 in tablespace SYSAUX
    ORA-1653: unable to extend table SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY by 128 in tablespace SYSAUX
    ORA-1688: unable to extend table SYS.WRH$_LATCH partition WRH$_LATCH_1494888728_1416 by 128 in tablespace SYSAUX
    Info about SYSAUX:
    Allocation Type Automatic
    Segment Space Management Automatic
    Enable logging Yes
    Block Size (B) 8192
    Datafile:
    Name +ORA_1/db07/sysaux.dbf
    Tablespace SYSAUX
    Status Online
    File Size (KB) 1239040
    Auto Extend Yes
    Increment 10240KB
    Maximum File Size 1500MB
    So, how do I solve this? And please, Im quite new to this, so be nice :-)

    If you have access to metalink you may read this:
    Usage and Storage Management of SYSAUX tablespace occupants SM/AWR, SM/ADVISOR, SM/OPTSTAT and SM/OTHER
    Doc ID: Note:329984.1
    Werner

  • ORA-1654 - Unable to extend index

    We have an oracle apps server and we started experiencing ORA-1654 errors. After digging through log files we found an error: ORA-1654: unable to extend index JTF.JTF_IH_ACTIVITIES_N6 by 16 in tablespace APPS_TS_TX_IDX.
    From what I can figure we need to add a datafile to our system. We currently have 4 datafiles that are 4Gb each. Is this the correct solution? If so what is the safest way to do this. Can I copy the 4 DB files to an alternate location and restore that way if the adding file doesn't work or what is the best practice for this type of action? Thanks

    There are currently 4 entries for that tablespace, pointing to all 4 db files. The entry for db file #4 is auto extensible, if you subtract user_bytes from max_bytes you get 1310672 which is about 1024kb. so I assume this means it is full? The other three table references are auto extensible = N and max_bytes, max_blocks, increment_by are all 0.
    Since this file seems to be full, and assuming that the 4Gb per file limit was set up for a particular reason. If I wanted to create another file for this tablespace I just 'alter tablespace APPS_TS_TX_IDX add datafile '/path to datafile' size XXXM;' and that is it despite the 4 entries for this tablespace?
    Do I need to backup data in order to perform this? It is a production system and data loss is not an option.
    Do I need to shut down all services (Apps, portal, etc) before I add the datafile?
    Thanks for your help!

  • ORA-1654: unable to extend index DMDB.PK24_MEMBER_RELATIONSHIP by 128 in ta

    Hi
    I got following error.Please advise me what action i should go for.
    ORA-1654: unable to extend index DMDB.PK24_MEMBER_RELATIONSHIP by 128 in tablespace
    Regards,
    RJ

    You maybe need to increase the size of a datafile (or add a datafile) to the tablespace where the index is.
    And retry your last action.
    Nicolas.

  • ORA-1654:unable to extend index SYSTEM.X2EC_ERROR_LOG by 122880 in tablesp

    Hi All,
    Please Help me in this....!
    We got the following error in our DB....
    Thu Jul 9 05:50:40 2009
    ORA-1654: unable to extend index SYSTEM.X2EC_ERROR_LOG by 122880 in tablespace SYSTEM
    ORA-1654: unable to extend index SYSTEM.X2EC_ERROR_LOG by 122880 in tablespace SYSTEM
    Now(3 hrs after this error) if we monitor our tablespaces through EM, every thing is fine and 12G freespace on SYSTEM tablespace.
    Please UPDATE ASAP
    Thanx
    Rama Krishna N K J

    01654, 00000, "unable to extend index %s.%s by %s in tablespace %s"
    // *Cause:  Failed to allocate an extent of the required number of blocks for
    //          an index segment in the tablespace indicated.
    // *Action: Use ALTER TABLESPACE ADD DATAFILE statement to add one or more
    //          files to the tablespace indicated.

  • ORA-1654:unable to extend index CDTRANS_DET by 1068 in tablespace INDEXES

    Hi All,
    I am getting below error
    ORA-1654:unable to extend index CDTRANS_DET by 1068 in tablespace INDEXES.
    I have checked space of INDEXES tablespace and it having 2 GB free space.
    Oracle version--7
    Os-------unix
    Kindly help me out.
    Thanks

    hi,
    your block size?
    Check How often do they extend? how big are they? the NEXT EXTENT size
    may
    not be appropriate.
    try this too
    alter index/table name deallocate unused
    alter tablespace name coalescs; 3. run querys to check dba_free_space and dba_data_files
    regards,
    Deepak

  • How to be notified for all ORA- Errors recorded in the alert.log file

    based on Note:405396.1, I Changed the Matches Warning from the default value ORA-0*(600?|7445|4[0-9][0-9][0-9])[^0-9] to ORA-* in order to receive an warning alert for all ORA- errors.
    but I just recieved the alert like the following:
    Metric=Generic Alert Log Error
    Time/Line Number=Mon Feb 25 23:52:21 2008/21234
    Timestamp=Feb 26, 2008 12:06:03 AM EST
    Severity=Warning
    Message=ORA-error stack (1654, 1654, 1654) logged in /opt/oracle/admin/PRD/bdump/alert_PRD.log.
    Notification Rule Name=Alert Log Error
    Notification Rule Owner=SYSMAN
    as you can see, the message only indicate the ORA-1654, nothing else.
    How to set in 10g grid control to get the details alert that in the alert log like:
    "ORA-1654: unable to extend index ADM.RC_BP_STATUS by 1024 in tablespace PSINDEX"
    I can't believe Oracle 10g Grid control only provide the ORA- number without details

    Go to your database target.
    On the home tab, on the left hand side under Diagnostic Summary, you'll see a clickable date link next to where it says 'Alert Log'. Click on that.
    next click on Generic Alert Log Error Monitoring Configuration (its at the bottom)
    In the alert thresholds put:
    ORA-0*(600?|7445|4[0-9][0-9][0-9])[^0-9]
    I believe that will pick anything up but experiment, its only perl.
    If you want to test this use the DBMS_System.ksdwrt package but I would advise you only do so on a test database. If you've never heard of it, google it. Its a way of writing to your alert log.
    Make sure you have your emails sent to long format as well.

  • Error: ORA-01654: unable to extend index APPLSYS.SYS_IOT_TOP_34179 by 16 in

    Hi,
    I am using Oracle API (HzLocationV2Pub.LocationRec) to update record and getting the following error message in JDeveloper log and couldn't able to update.
    x_return_status : U
    x_msg_data : Unexpected SQL error encountered during synchronization:
    Procedure: sync_party_site
    Error: ORA-01654: unable to extend index APPLSYS.SYS_IOT_TOP_34179 by 16 in tablespace APPS_TS_QUEUES
    Please contact the system administrator.
    x_msg_count : 1
    What is the reason behind this error?
    How to resolve this?
    Thanks & Regards,
    Sagarika

    Hi,
    You need to add more space to your datafile/tablespace, or extend the index.
    SQL> alter index APPLSYS.SYS_IOT_TOP_34179 storage (maxextents unlimited);
    SQL> ALTER TABLESPACE <tablespace name> ADD DATAFILE '<full path and file name>' SIZE <integer> <K|M>; Note: 1025288.6 - How to Diagnose and Resolve UNABLE TO EXTEND Errors
    https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=1025288.6
    Note: 19049.1 - OERR: ORA 1654 unable to extend index by for tablespace
    https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=19049.1
    Note: 762273.1 - ORA-1654: unable to extend index
    https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=762273.1
    Regards,
    Hussein

  • Oracle error 1654

    Hi
    I have checked my alert log and found the error ORA-1654: unable to extend index PK_STUDENTS by 512 in tablespace TS. I have checked that the current extent is only 3 from dba_segments. The max extent allocated is 200. So why is there such a error? What can I do? Thanks!

    Make sure that the HASH_MULTIBLOCK_IO_COUNT value is less than the next_extent. You can either increase the next extent to greater than the HASH_MULTIBLOCK_IO_COUNT value or reduce the HASH_MULTIBLOCK_IO_COUNT to be lesser than the next_extent. If HASH_MULTIBLOCK_IO_COUNT is found to be 0 in v$parameter table, then it the init.ora, give HASH_MULTIBLOCK_IO_COUNT = 1 and restart database. this should solve the problem.
    regs,
    Kris

  • Confuse between temp file error and perment file error

    during the weekend, i usually maintain our database and this weekend i end up with strange situation,
    i lunched my scripts to reorginize datafiles, however the scripts is crash all the time due to weird message which is in my opinion is misleading ora message.
    this is the situaion:
    i am using this scripts to tell me if my datafiles are full or not
    1 L_INDEX 24 107.12109375 103.74609375 3.375 0 96.8493600262553 3.15063997374467
    2 L_TABLES 30 108.2939453125 97.1689453125 11.125 0 89.7270341680719 10.2729658319281
    as you can see, the free space on the l_index tablespace is now 3G and need to reogrinze to free space, however when we run our scripts to free spaces by moving objects to tools tablespace and then return them back,
    I recieve this message:
    ORA-01652: unable to extend temp segment by .......
    to solve this error is adding new temp files, however we have 5 temps file and there were pantly of space there and also i add 2 new files with size 1g and maxsize is 32G, still i am receving this error and my scripts crash when i try to rebuild the index,
    the workaround was is adding new datafile to l_index and try again to rebuild the index and it works,
    so i am wondering if the problem was on the datafiles, why i recieved error about temp, i waste some time thinking that my problem was with temp, however the real problem came from l_index tablespace.
    oracle verison is 10.1.0.4 and os is windows
    Thanks

    ORA-01652: unable to extend temp segment by Temporary tablespace is also used when re-creating or creating indexes in database.
    A temp segment is created the moment create or re-build indexes command is issued and will be held until the index is being created completely. If either of the tablespace have insufficient space, you might get the error ORA-1652 or ORA 1654.
    You should be looking at the tablespace name for adding space instead of looking temp segment.
    ORA-1652: unable to extend temp segment by in tablespace

  • Unable to extend index name of the index by 8 in tablespace

    Hello,
    I am not a DBA and do not have much experience in Oracle. When I was trying to restore the backup of my application, I received the following error. I could not able to proceed further in my tasks.
    ORA-01654: unable to extend index <name of the index> by 8 in tablespace <name of the Index tablespace>The following query was used to create the table space. Oracle version is 10g.
    CREATE TABLESPACE TS_JIRA
    DATAFILE 'D:\oracle\product\10.2.0\oradata\jiraadmi\TS_JIRA.dbf' SIZE 100M REUSE
    AUTOEXTEND ON NEXT 10M MAXSIZE 200M
    MINIMUM EXTENT 64K
    DEFAULT STORAGE ( INITIAL 64K NEXT 64K MINEXTENTS 1 MAXEXTENTS UNLIMITED PCTINCREASE 0);I do not know how to extend the size of the tablespace. Can anyone help to sort out this issue?
    Thanks in advance
    Ram

    Hi Ram;
    I suggest also review below doc for your future issue
    TROUBLESHOOTING GUIDE (TSG) - UNABLE TO CREATE / EXTEND Errors [ID 1025288.6]
    Overview Of ORA-01654: Unable To Extend Index %s.%s By %s In Tablespace %s [ID 146595.1]
    OERR: ORA 1654 unable to extend index <name.name> by <num> for tablespace <nam [ID 19049.1]
    I belive they will answer all your question ;)
    PS:Please dont forget to change thread status to answered if it possible when u belive your thread has been answered, it pretend to lose time of other forums user while they are searching open question which is not answered,thanks for understanding
    Regard
    Helios

  • Undo tablespace problem

    Hello, I was processing a batch job that commits every 5,000 records. I have the UNDO_RETENTION set to 10,800. UNDO_MANAGEMENT is set to AUTO. at some point the database shut down
    with the following errors in the alert log:
    ORA-1654: unable to extend index CRM.XIF35CUSTOMER by 16 in tablespace      RCRMCUSTIX01
    ORA-1654: unable to extend index CRM.XIF35CUSTOMER by 16 in tablespace      RCRMCUSTIX01
    ORA-1654: unable to extend index CRM.XIF35CUSTOMER by 16 in tablespace      RCRMCUSTIX01
    ORA-1654: unable to extend index CRM.XIF35CUSTOMER by 16 in tablespace      RCRMCUSTIX01
    Fri Jun 09 02:19:48 2006
    KCF: write/open error block=0x1faa4f online=1
    file=2 C:\ORACLE\ORADATA\CRMMGG\UNDOTBS01.DBF
    error=27069 txt: 'OSD-04026: Invalid parameter passed. (OS 2075215)'
    Fri Jun 09 02:19:48 2006
    Errors in file c:\oracle\admin\crmmgg\bdump\crmmgg_dbw0_20680.trc:
    ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode
    ORA-01114: IO error writing block to file 2 (block # 2075215)
    ORA-01110: data file 2: 'C:\ORACLE\ORADATA\CRMMGG\UNDOTBS01.DBF'
    ORA-27069: skgfdisp: attempt to do I/O beyond the range of the file
    OSD-04026: Invalid parameter passed. (OS 2075215)
    I noticed the the undo datafile is over 16GB. I reset the UNDO_RETENTION to 5 seconds. The undo tablespace data file is staying at 16GB. Is there any way to shring this file. It is a test DB so I can rebuild if necessary. What is the best way to recover from this? Thak you,
    David

    You are facing a generic problem on Windows platforms, when datafiles configured as AUTOEXTEND ON reach a 4GB boundary (4GB,8GB,...). The best way to avoid the problem is switch AUTOEXTEND to OFF and define the appropriate number of single datafiles for the tablespace. From metalink:
    ALERT: Problems with Datafile AUTOEXTEND/RESIZE on NT/2000 Platforms
    Doc ID:148894.1
    Werner

  • Tablespace fragmentation problem

    All,
    I am working in Oracle 9i. Developers are facing some problem. Oracle is throwing ORA-1654 error. There is enough space in the tablespaces. To me it seems to be fragmentation problem. I found one query on some site and executed in my environment.
    SQL> select substr(ts.name, 1,10) TableSpace,to_char(f.file#,990) "file #",tf.blocks blocks,sum(f.length) free,to_char(count(*),9990) frags,max(f.length) bigst, to_char(min(f.length),999990) smllst,round(avg(f.length)) avg,to_char(sum(decode(sign(f.length-5), -1, f.length,0)),99990) dead from sys.fet$ f, sys.file$ tf, sys.ts$ ts where ts.ts# = f.ts# and ts.ts# = tf.ts# group by ts.name, f.file#, tf.blocks;
    TABLESPACE file BLOCKS FREE FRAGS BIGST SMLLST AVG DEAD
    GAP_ARC 7 15360 8239 108 6099 20 76 0
    GAP_BILD 8 256000 223804 3655 77909 5 61 0
    GAP_DATA 9 230400 48267 211 3937 5 229 0
    GAP_GEN 10 192000 86156 902 52178 1 96 3
    GAP_IMP 11 38400 37669 14 37399 10 2691 0
    GAP_INDEX 12 230400 96408 3557 506 1 27 5335
    GAP_INDEX 12 409600 96408 3557 506 1 27 5335
    GAP_INDEX 13 230400 56120 1611 495 2 35 2627
    GAP_INDEX 13 409600 56120 1611 495 2 35 2627
    GAP_ZNZL 14 1920 1919 50 515 10 38 0
    RBS 3 51200 30479 871 35 29 35 0
    RBS_BIG 4 76800 63929 157 43649 130 407 0
    SYSTEM 1 25600 25952 2 12976 12976 12976 0
    SYSTEM 2 25600 22728 20 11321 2 1136 12
    TEMP 5 64000 58279 252 25649 130 231 0
    TOOLS 6 6400 6384 1 6384 6384 6384 0
    16 Zeilen ausgewählt.
    From the output it seems GAP_INDEX has some fragmentation problem. Can somebody suggest, what the output means particularly the "DEAD" one.
    And also, how to do the fragmentation ??
    Thanks for help.
    Regards,
    Rajeev

    I haven't taken the time to study the query in depth but I think 'dead' is an attempt to identify free exents that are too small to be used.
    The original post leaves out some very important information such as the type of tablespace space allocation in use: dictionary vs local with auto-allocate or uniform extents.
    As one poster noted if you use locally managed tablespaces wtih uniform extents then free space fragmentation by definition cannot exist.
    With auto-allocate and dictionary mangement it can. Auto-allocate generally extents the time till a tablespace's free space becomes fragemented such that the space is not usuable and contains logic to reclaim via reuse but with the right combination of very small and very large objects the problem can still exist.
    Dictionary management is almost bound to lead to free space fragmentation conditions for an active system though the adoption of a proper extent sizing policy can help: initial = next with pctincrease = 0 for all objects in a tablespace and the extent sizes for the larger objects being an even multiple of the small object extent size.
    For auto-allocate and especially dictionary management when free space gets low the options are re-create the objects to consolidate all free space into a few large contiguous chunks or add another file. Sometimes you can relocate an object whose extents can then be reused by other objects. With uniform extents moving an object to another tablespace always creates fully reusable free space. Since objects should be where you want them the only real option then is to add free space is to add a file. Managing free space in a uniform extent environment then is genarally very straight forward.
    HTH -- Mark D Powell --

Maybe you are looking for

  • ANY hope for "moisture damage"??

    A couple months ago - my phone got wet - and I took it in-guy cleaned it up and I was good to go.  Then last week, it started acting up - husband took it in and she said she had to do a "hard reset" before she could order me a new phone.  I hadn't sy

  • Does Nokia even employ an R&D department anymore?

    Last time I owned a Nokia was over two years ago and recently I decided to go back to the make of mobile that I had been used to most of my mobile-life. I just bought a Nokia 5300 (slidy, music phone) and I am appalled that Nokia have not change or i

  • Safari 6.0 flash problem (blocked plug in)

    getting this message since update to safari 6.0 any help would be great thank you

  • Our computer crashed, we replaced hard drive, and now we can't get Photoshop to open.

    One of our computers crashed and we had to replace the hard drive. Now we can't get Photoshop to open. Since the computer didn't give us any warning we didn't get to deactivate Photoshop before the crash. I've been on the Adobe site for over an hour

  • Launch coded UI test from other application

    Hi I need to launch Coded UI test i.e. coded UI test builder from another application developed in .Net. basic requirement is I will hit one button which will open the coded UI test builder, I will click on record button available on it. Will perform