Did I: have space when it stopped archiving? My bet would be that you ran out of space on I:. When somebody realized this or the backup kicked in, they started deleting files. When space freed up, the archiver kicked in again.
If you ran out of disk space you would have seen the message "O/S-Error: (OS 112) There is not enough free space on the disk" in your [sid]ARCH.TRC file as I recently had this happen. Your whole database would have stopped as well until free space was allocated.
Originally posted by marist89 Did I: have space when it stopped archiving? My bet would be that you ran out of space on I:. When somebody realized this or the backup kicked in, they started deleting files. When space freed up, the archiver kicked in again.
right.. i think its not the space issue.. .but rather the IO error... could be the disk.. but i am not sure..
cos when its the space issue i will get the below
If you ran out of disk space you would have seen the message "O/S-Error: (OS 112) There is not enough free space on the disk" in your [sid]ARCH.TRC file as I recently had this happen. Your whole database would have stopped as well until free space was allocated.
The same problem faced by me few days back. It is because of less space on Archive disk. When u free the space then archiveing will start again autometically.
I question may arise why the Database not hanged ? when archive process fails.
The answar is
Suppose u have 3 Log groups.
when log swtich occurs and LGWR starts writing next online Redo log file, and the archive process do the archive of privios log file. On next log swtich LGWR starts writing next on line group. and Arch. process keep on tring archive log files and found no space and starts issuing archive related errors. The database will hang when all the 3 Log groups are full and archive is not done and no log group is available for Redo entries.
I think I can only add to the problem! anyway, here is my evidence:
This is EE 8.1.7.4.10 under Windows NT4.0 Server SP6a
I had the same this Monday morning at 04:50, the previous log switch was on the Saturday.
1) What caused the log switch at 04:50? - no users, no batch process - can checkpointing do this?
2) The OS/Hardware/RAID logs show no errors - this is a RAID-1 pair.
3) I'm running 8.1.7 - so it shouldn't be the Oracle bug.
3) I expect that 10 minutes later an independant OS process then moved the archlog file to another directory (same disk) and thus allowed ARCH to write a second version of the archlog.
4) The first version of the archlog that was written fails when applied to the Standby with "ORA-00317: file type 0 in header is not log file", the second works fine.
5) There was 1.3Gb free on the destination disk when I got in at 08:30. As ARCH could write a second version 10 minutes after the first, it could not be a space problem.
6) I can't imagine it was due to hitting an OS limit at that time of day.
This leaves me with the conclusion of data corruption caused by an Act of God, undetected at the OS/Hardware level.
Reply With Quote
Bookmarks