• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 638
  • Last Modified:

Oracle 7.3.4 on Solaris 2.7 - Export File Size Limit

We have several Oracle 7.3.4 databases running on Solaris 2.7.  During my full database exports, I receive error messages EXP-00002, which means that I have hit the physical file limit on the server.  The limit for file size is set to Infinity on the OS side.  Is there a limit on the Oracle side?  What do I need to change?
0
120864
Asked:
120864
1 Solution
 
iamlhbCommented:
It's not oracle limit!
You can change the OS level file size by kernel parameter!
If you have the file size limit, you can use the split command on the UNIX!
More detail usage exist on Metalink!
0
 
balasubramCommented:
Hi,
On your export script please check whether the 'COMPRESS=Y' exists or else add it.
This should be helpful for exports more than 2GB in size.
Bala
0
 
yo_houCommented:
You can specify filesize parameter and enough numbers of file name.
0
 
marek_wiechulaCommented:
The COMPRESS=Y recommended by balasubram makes not difference to the size of the exported dump file.  It is an option which allows you to combine all your extents for each table/index into one extent.  So if you have table ABC with 5 extents and 500K of assigned disk space, then you end up with 1 extent of 500K.  

We use Oracle on Solaris and we had a problem that even if the OS file system allowed files > 2GB the Oracle software had problems with it.  We found that we could pipe our exports and avoid the problem  This is because when Oracle is writing to a named pipe it doesn't really know how big the file is, it just passes the export information along.  Since we were already going to that much trouble we put in another command to compress the export file on the fly and save some space while we were at it.

Basically we do something like this:

{set Oracle sid, locate to correct directory etc. etc.}
mknod export_pipe p
cat export_pipe | compress > export.dmp &
exp user/password file=export_pipe log=export_log <other export parameters>

In fact, in our environment, it is a little more complicated because we have UNIX variables (with embeded ORACLE_SID values) for the file and pipe names and additional code to identify where the cat export_pipe and compress processes are correctly terminated at the end of the export.

It is a little simpler in that we run this from a UNIX user who is also an externally identified DBA user in Oracle so we don't have to supply user or password, just the /.  

Also as a matter of interest we ALWAYS use COMPRESS=N.  We feel that the major reason for taking exports is as quick route to recovering any single table that might be accidentally dropped or corrupted.  To make quick use of that we may want to put the table back into the same space it used to use and we cannot guarantee that we can find a single piece of free space large enough to hold the whole table.  (Well we can guarantee it if we are willing to increase the tablespace size but we often aren't.)
0
 
120864Author Commented:
I incorporated your suggestions into my current script which exports all of our databases.  This works great.  Although it took some time, my import of a table from one of these files worked also.

Thank you.
0

Featured Post

The 14th Annual Expert Award Winners

The results are in! Meet the top members of our 2017 Expert Awards. Congratulations to all who qualified!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now