Don't know about EMC specifics, but Netapp has a snapshot feature where you are using up additional disk-space each time you do a DML. The original block is "frozen" (contains the snapshot point-in-time), and the copy of the block with the modified data is written out. So now you have 2 blocks instead of one. As you make more changes, you will take up more space.
Fact that you got the no-space-left error when writing to the online redo log sounds suspiciously like the same sort of problem, ie a redo write is actually requiring more space. If this is a snapshot issue, keeping to 10% free will of course avoid this problem. Better still, switch off snapshotting.
Also it appears you have put the redologs on the same volume as the archivelogs. I would prefer to keep them separate, like internal/DAS disks, for these and other reasons vendors don't tell you about. And for performance reasons, also look at increasing rsize/wsize - and EMC should have recommendations on that.
-- -- Original Message -- -- From: "Allen, Brandon" <Brandon.Allen@(protected)> To: "Riyaj Shamsudeen" <rshamsud@(protected)> Cc: <oracle-l@(protected)> Sent: Wednesday, April 19, 2006 10:25 AM Subject: RE: Recovery with logs, then incremental, then more logs?
> Yep, it's an EMC. My Unix admin just told me earlier today that EMC told him that they recommend keeping the filesystems below 90% full to avoid any problems. I had never heard anything like that before - anyone else? This is a 500GB filesystem, so to keep it below 90% we're talking about wasting 50GB. Not the end of the world, I know, but certainly not ideal and I can't believe that this would actually be a requirement for stability. > > > -- --Original Message-- -- > From: Riyaj Shamsudeen [mailto:rshamsud@(protected)] > > > I don't know much about NFS3 protocol, but is your vendor / file system > in this list ? > > http://www.oracle.com/technology/deploy/availability/htdocs/vendors_nfs.html
