December 2, 2003 at 10:38 am
I got the following errors........
Error: 823, Severity: 24, State: 11
I/O error 33(The process cannot access the file because another process has locked a portion of the file.) detected during write at offset 0x000002983a0000 in file 'e:\MSSQL\data\tempdb.mdf'..
Error: 15457, Severity: 0, State: 1
Seems like a bad disk. It is a Raid 0 drive.
I have asked a drive check to be performed for this drive. I am not sure if it can be done while the SQL Server is running.
I am thinking of shrinking the tempDB and let it grow again so that it may not expand on the bad sectors.
I could also move the tempDB to another drive temporarily, but would require me to reboot our production server.
Also, my concern is that if the drive is bad, it will affect the other system databases as they are sitting on the same drive. The sytem databases have passed integrity checks over the weekend and seem to be okay.
Anyone has any ideas on what steps I should take or the best way to resolve this problem.
December 2, 2003 at 11:22 am
The file may be damaged or could be a disk problem. You are very lucky if only tempdb is on it, either you can move it to other drive or re start the service. If any user db on it you might want to read more about DBCC CHECKDB. Make sure you have backup of the DB. Error 15457 is not a serious error. You will see this error whenever you check the server config options from the EM.
Shas3
December 2, 2003 at 11:33 am
Sometimes, restart will help u to make a decision
December 8, 2003 at 3:44 pm
Sorry to get back late here, we had some other problems I was working on. Well, our hardware people said that there was nothing wrong with the drive in question. So, it had to be the tempdb problem.
I ran the DBCC CheckDB with All_ErrorMsgs and it returned me no errors. There were no non-system objects in the tempdb and the space used in the 35GB tempdb database was only 4MB. Looking at the time it required to run and the results, it seems to me that the the DBCC command checks only on the space that has been allocated to the tables, etc. So, I ran the DBCC CheckDB with Physical_Only with the hopes that it will scan all the pages even if they are empty, but it came with the same results. No errors.
So, I restarted the server in minimum configuration mode (at the dos prompt with "SQLServr.Exe -c -f" and then using Query Analyzer, I altered the database files (mdf and log) size of the tempdb using the 'alter database' command. And restarted the SQLServer. Fortunately it worked.
If this had not worked, I was going to try to use "DBCC ShrinkFile" and shrink the tempdb database files.
Thanks for your help.
December 9, 2003 at 8:41 am
Have your or those "hardware people" looked at the OS.
If Windows mixed up some files positions it might cause this error. A smaller file might remove the symtoms while the error remained.
Run chkdsk on the command line. It will show the problem but not repair it.
chkdsk /f will repair it. This takes a reboot. The results can be seen in the event log
December 9, 2003 at 8:46 am
823 Error messages usually imply on disk corruption most typically
arising from problems at a level below the operating system (e.g.
Hardware component failure, bad/outdated device driver, or external
failure such as an unfiltered power surge).
Do you see other errors seen in conjunction
with 823 errors in error logs?
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply