Thanks everybody's input, I have get a lot of replies, the best thing to do is obvious not get volume full. In our scenario, these are test/development databases, all the oracle files are on single NFS volume , database is not Running in archive mode, The argument so far is :

Is corruption a normal behavior after oracle file system is full or it should never? Could this be anything particular related to NFS since we had never observed this on SAN?

Jackie

Thanks -----Original Message----- From: ericgrancher@gmail.com [mailto:ericgrancher@gmail.com] On Behalf Of Eric Grancher Sent: Monday, December 08, 2008 1:13 PM To: Matthew Zito; Glenn Dekhayser; Li, Jackie (Yanhui); toasters@mathworks.com Subject: Re: oracle coruption caused by NFS file system is full

dear all,

(being quite silent on the list, I take the occasion to say that I appreciate very much the contributions and for once that I can contribute...)

From my understanding and experience (we got hit once at CERN when we started using DOT devices/NFS for Oracle databases, then we understood the issue and took the right actions to prevent this from happening again), the issue can typically be linked with snapshots: one (or more) snapshots having been created on the volume, Oracle needs to update a block, which turns to the need of more space as the old copy has to be kept (to preserve the snapshot). If no space is available, the write operation is refused which Oracle sees as a "corruption".

It is quite well described in TR-3633, pages 22-24. http://media.netapp.com/documents/tr-3633.pdf The operations to be performed (after having added space) to recover from this situation depends on the type of the affected file, the cases are listed as well in the mentioned document.

It may actually not be linked with auto-extensibility of Oracle datafiles (which we use extensively without problem). Just updating redo-log files and/or changing blocks in datafiles can generate the issue.

Regarding actions to avoid such an issue happening again, it very much depends on your usage of snapshots:

-1- if the snapshots are not used, removing the snapshots and disabling the automatic creation of new snapshots is enough! -2- using the vol autosize feature and making sure that there is enough space at the aggregate level (and max-autosize not reached) is a possibile solution (DFM is our friend for this!) -3- using vol option try_first http://now.netapp.com/NOW/knowledge/docs/ontap/rel7251/html/ontap/cmdref/man... linked with snap autodelete as decribed in http://now.netapp.com/NOW/knowledge/docs/ontap/rel7251/html/ontap/cmdref/man... could be a solution (which we do not use, be careful with your snapshots if they are a key part of your backup strategy!)

best regards, eric

2008/12/8 Matthew Zito mzito@gridapp.com:

This is also why you don't enable autoextend on tablespaces, and put your archive logs on a separate filesystem. Space management is part of the day to day responsibility of a DBA. Running out of space is a Very Bad Thing for databases. Thanks, Matt