Oracle hitting 1gb file size limit - OUCH!

[Wayne Schmidt]

Anyone,

We are seeing the same issue on HPUX 11.00 and Oracle 8.1.7.4. When files are going beyond 1gb (I stress one gig), the database is reporting:

*** SESSION ID:(2.1) 2003-12-01 00:57:14.611
KCF: write/open error block=0x10469 online=1
file=16 /ora/laxap01u.plaxsbo.u1000/oradata/plaxsbo/users_indexes_01.dbf
error=27072 txt: 'HP-UX Error: 27: File too large
Additional information: 66665'
Automatic datafile offline due to write error on

This is the second time this error has occured. 1st time on datafile, 2nd on index file.

.proto has ulimit set to unlimited. Oracle environment ulimit set to unlimited. Fstab is mounting the filesystem with largefiles option. mkfs reports largefiles. fstyp f_flag=16.

Help!

Thank you,

Wayne

[Dave Hutton]

Are large files option turned on that filesystem?

alcatraz:root /root # fsadm -F vxfs /usr/openv
nolargefiles

You can turn it on with:
alcatraz:root /root # fsadm -F vxfs -o largefiles /usr/openv
alcatraz:root /root # fsadm -F vxfs /usr/openv
largefiles
alcatraz:root /root #

Dave

[Jean-Luc Oudart]

which shell do you use for oracle, the user ?

JL

[Dave Hutton]

Gah sorry Wayne I reread it. You do have large files on...

[A. Clay Stephenson]

I would first do both a ulimit -Sa and a ulimit -Ha to display both the soft and hard ulimits. A 1GB largefiles would not come into play. If ulimit is okay then that leaves just one thing - quotas. You need to check if quotas are in play on this filesystem.

[Mark Grant]

I actually don't understand this but I would have thought a 32bit OS with a mirrored filesystem would actually struggle to get beyond a 1GB file regardless of the largefiles option. I could be completely wrong but are you using 32bit oracle on a 32bit machine with a mirrored filesystem?

Someone else could confirm if I am just imagining things.

[A. Clay Stephenson]

No, 32-bit programs can address 2GB files easily. Note that 32-bits allows a range of 4GB (unsigned) and 2GB (signed). In fact, 32-bit programs can use 64-bit file offsets. There is a set of 64-bit system calls (e.g. lseek64, creat64, fstat64, ...) to allow 32-bit programs to handle largefiles.

Mirroring has no impact on this and is, in fact, completely invisible to the application.

[Mark Grant]

Thanks A.Clay. I seem to be learning a lot today :)

[Wayne Schmidt]

$ ulimit -Sa
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 1048576
stack(kbytes) 40960
memory(kbytes) unlimited
coredump(blocks) 4194303
$ ulimit -Ha
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 1048576
stack(kbytes) 40960
memory(kbytes) unlimited
coredump(blocks) unlimited

Oracle and HPUX are both running 64bit. Shell is ksh.

Thank you everyone! I'm looking for the straw that's breaking the camel's back. A huge mystery that is stumping both Oracle and HP.

[Jean-Luc Oudart]

Wayne,

it seems there was an issue with ksh at some stage cf. Metalink docid 360746.999

I would suggest try with POSIX sh .

Regards,
Jean-Luc

[A. Clay Stephenson]

I would certainly check to see if quotas are on. Next, it's rather difficult to know what ulimit is actually set to under a running process because the process itself might set ulimit and simply checking it from the shell of the same user is not a definitive test.

By any chance, is the database actually started by a process launched under cron or at?

I know that 2GB files work on 11.0 and 8.1.7.4 because I have instances like that running. I am guessing that you have autoextend on for your tablesspaces and the problem occurs when the tablespace needs to grow. In our case, the tablespaces are not allowed to autoextend but they do exceed 1GB with no problems. To help isolate the problem, I would do something like isuue a create tablespace dumbo specifying a size of , perhaps 2047M, with autoextend off. If that tablespace is created then ulimits and quotas shouldn't be the problem (again, unless the process itself is resetting ulimit). You can then drop tablespace dumbo.
If good so far then repeat the test with autoextend on and add a table and do some inserts to reproduce the problem.

[James A. Donovan]

A link to the Metalink note matching this issue....

http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=1067314.6

Doc ID: Note:1067314.6
Subject: KCF: WRITE/OPEN ERROR, ORA-27072, HP-UX ERROR: 27 FILE TOO LARGE
Type: PROBLEM
Status: PUBLISHED
Content Type: TEXT/PLAIN
Creation Date: 15-MAR-1999
Last Revision Date: 19-JUN-2000


Problem Description: ==================== The database starts and is running normally. After a period of activity, an error appears in the alert.log: Mon Feb 8 16:33:02 1999 KCF: write/open error block=0x21ed2 online=1 file=30 /u09/oradata/midas/xsiteaud02.dbf error=27072 txt: 'HP-UX Error: 27: File too large

[Tim Sanko]

We are running 8.1.7 ourselves. We expect a 2GB for filesystems without largefiles turned on. Our export compressed is ~3.7 GB. uncompressed it pushes 16 GB.

I suspect oracle configuration.

Check your tablespace sizes...

Tim