One of my clients contacted me and informed that they have a node production clustered server and they recently noticed that the nightly error log had stopped cycling ERRORLOGs. When we attempted to run sp_cycle_errorlog we get the following:
Msg 17049, Level 16, State 1, Procedure sp_cycle_errorlog, Line 9
Unable to cycle error log file from ‘G:\SQL_DATAMNT\MSSQL13.MSSQLSERVER\MSSQL\Log\ERRORLOG.10’ to ‘G:\SQL_DATAMNT\MSSQL13.MSSQLSERVER\MSSQL\Log\ERRORLOG.11’ due to OS error ‘1392(failed to retrieve text for this error. Reason: 15105)’. A process outside of SQL Server may be preventing SQL Server from reading the files. As a result, errorlog entries may be lost and it may not be possible to view some SQL Server errorlogs. Make sure no other processes have locked the file with write-only access.”
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Above error has one meaningful information which is not very clearly visible. OS Error 1392. What does it mean?
As shown above, the error means – The file or directory is corrupted and unreadable.
When we try opening ERRORLOG.10 we got exactly the same error. What is the solution now?
When SQL Server recycles the ERRORLOG, it will rename all the previous ERRORLOG.n to ERRORLOG.(n+1), and then create a new ERRORLOG as the most current one. If the rename process fails, the recycle of ERRORLOG cannot complete.
Since we can’t use that file and in this case even deletion of the file was also not happening. We changed -e parameter in configuration manager to use the new path.
Then we failed over the SQL cluster instance to another node. We verified that the SQL server can come online and ERRORLOG generated at the new location. Then we can recycle command again and it worked!
Note that this is a serious error. I told my client that he was lucky that it happened with ERRORLOG file. Imagine if it happens with database related MDF or LDF file. They immediately engaged a hardware vendor for the disk sanity check.
Reference: Pinal Dave (http://blog.SQLAuthority.com)