Kernel configuration and problem with Oracle

[Rene Mendez]

Hi my system is HPUX 11i i have one problem, the message in syslog is table is full and the message in oracle is:

ORA-01115: IO error reading block from file 1 (block # 28007)
ORA-01110: data file 1: '/ora2/oracle/oradata/AXISCLI/system_01.dbf'
ORA-27041: unable to open file
HP-UX Error: 23: File table overflow

Is problem the kernel configuration?

[A. Clay Stephenson]

Yes, you need to increase nfile.

[Robert-Jan Goossens]

Hi,

take a look at the NFILE parameter in the kernel.

Robert-Jan.

[Anil C. Sedha]

It requires the number of files that can be opened at one time to be increased.

You may ncrease it using sam and reboot your box.

-Anil

[Rene Mendez]

The nfile, is 23089 how match increment ?
This parameter depend the
(16*(NPROC+16+MAXUSERS)/10+32+2*(NPTY+NSTRPTY+
NSTRTEL))

I increment the maxusers.

[James R. Ferguson]

Hi Rene:

The kernel parameter 'nfile' governs the number of files that can be open, simultaneously, system-wide.

You can use 'glance' [toggle the system table with 't' to view] or 'sar -v' to watch the 'nfile' value.

Increase it to exceed your high water mark. There is essentially no penalty for doing so.

Regards!

...JRF...

[Ross Zubritski]

Bump maxusers.

Regards.

RZ

[Michael Tully]

Make sure that if you are utilsing formulas in your kernel parameters that others could be affected.
If your not sure, use 'sam' to help, it will assist with these.

[Robert-Jan Goossens]

Hi,

-quote-

[hp engineer] Jean-Louis Phelix

Hi,

In general it's recommended not to modify kernel parameters directly but rather use indirect modifiers like MAXUSERS. In this case NFILE is a very cheap parameter which can really be put to a very big value (> 50000)without any impact on your system while other indirect modifiers would also increase NINODE for example (inode CACHE not a table size, not used by VxFs, very expensive in size and time and notoriously always too high). I talk about this one because 'sar -v' will probably tell you that it's almost full, although it's normal since it's a cache. The only parameter that you could relate to NFILE could be NFLOCKS which 'should' be around 10% of NFILE.

Regards.

-endquote-

Kind regards,

Robert-Jan.