Home/ Questions/Q 8702547
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T02:40:43+00:00

Oracle 11G, Linux with 200GB space. About 25GB were already occupied by some files.

  • 0

Oracle 11G, Linux with 200GB space. About 25GB were already occupied by some files.

I received a “.dmp” file of 50GB and, in order to perform the import, I created a bigtablespace with bigdatafile of 100GB (cause I thought it would be enough).

The import command:

imp user/pwd full=Y log=/home/oracle/log.txt file=/usr/oracle/public/dump.dmp

But after importing lot of tables and inserting lot of data into them, I received the following error message:

IMP-00017: following statement failed with ORACLE error 603:
 "CREATE UNIQUE INDEX "PR_TABLE1" ON "TABLE1" ("TABLE1_ID" , "ROW_NUM" , "COL_NUM" ) "
 " PCTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE(INITIAL 4294967294 FREELISTS 1 "
 "FREELIST GROUPS 1 BUFFER_POOL DEFAULT)                      NOLOGGING"
IMP-00003: ORACLE error 603 encountered
ORA-00603: ORACLE server session terminated by fatal error
ORA-01114: IO error writing block to file 201 (block # 1719438)
ORA-27072: File I/O error
Linux-x86_64 Error: 25: Inappropriate ioctl for device Additional information: 4 Additional information: 1719438 Additional information:
114688
ORA-01114: IO error writing block to file 201 (block # 1719438)
ORA-27072: File I/O error
Linux-x86_64 Error: 25: Inappropriate ioctl for device Additional information: 4 Additional information: 1719438 Additional info
IMP-00017: following statement failed with ORACLE error 3114:
 "BEGIN  SYS.DBMS_EXPORT_EXTENSION.SET_IMP_SKIP_INDEXES_OFF; END;"
IMP-00003: ORACLE error 3114 encountered
ORA-03114: not connected to ORACLE
IMP-00000: Import terminated unsuccessfully

About 15GB were consumed by the “temp” datafile.

It seems it run out of space, according to what I’ve read online about datafiles trying to extend themselves. Linux shows around 8GB free, but it might have them reserved for something else.

The question is: is there a way for me to know how much space should I give to my hard drive to successfully realize the import???

The reason to ask this is because it takes so long to upload the “.dmp” file to the server and many more to create the “.dbf” files and realize the import.

The client doesn’t know this info. I’m not an Oracle DBA, but I once successfully connected a .Net application to an Oracle database, so now I’m supposed to be the expert here.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’m assuming your datafiles and tempfiles are on filesystem?

    So, for temp files, Oracle creates them as sparse files. So, if you have a filesystem that has, say, 100MB of free space. You could create a temp tablespace in that filesystem, of size 2GB, even though there’s only 100MB of free space. So, it’s easy to over allocate space. So, as soon as you started using this temp space, when your usage exceeded 100MB, you’d get the error above, “inappropriate ioctl for device”.

    So, please sanity check the size of your data file and temp files, and the amount of free space you actually have. Note that, once you start using the space in the temp file, the size of the file (as reported by the O/S) probably won’t change, but the free space as reported by the O/S will decrease till it hits zero and the filesystem is full.

    Note also, that index creation, on a large table, could create significant temp space usage, particularly if you’re using WORKAREA_SIZE_POLICY=AUTO and PGA_AGGREGATE_TARGET. (I know, if you’re new to Oracle, and not a DBA, that may not make any sense, don’t worry about it.)

    What you may want to do, is run the import with ‘INDEXES=N’, to just import the data, then create the indexes after the fact, running from a script. This way, you can set WORKAREA_SIZE_POLICY=MANUAL, and set very large sort_area_size and sort_area_retained_size. this may (or may not, depending on the size of the indexes being created) reduce the space usage of temp tablespace.

    So, in summary, first check the sizes of your temp files, and space left in your filesystem. If you have a problem w/ initially sparse files that have now overcommitted you on space, then you need to resolve that. Best bet may be to drop the temp tablespace, check the amount of free space then in the filesystem, and then create a new temp tablespace, appropriate to your situation.

    Then, secondly, see if you can tune the TEMP space consumption during index builds, using manual workarea size policy and explicitly set sort_area_size/sort_area_retained_size.

    Hope that helps.

    • 0