August 4, 2011 at 4:56 am
Hey guys,
I've recently had to start supporting a SQL Server 2000 box, which was virtualised, and we have experienced a number of errors on it since day 1....
The error messages always relate to the same database (which may be a red-herring, as it is the only db on the server with any significant amount of activity, and certainly any large number of reads or writes).
The following error occurs fairly regularly throughout the day;
"Error: 605 Severity: 21 Date: 20110804 Time: 83416 Database: MY_DB Message: Error: 605, Severity: 21, State: 1 Attempt to fetch logical page (1:21636) in database tempdb belongs to object 0 , not to object #2F4698F5 ."
Thinking there may just be a problem with the cache, the server has been rebooted, but the problem remains.
Since the reboot, I have also encountered the follownig error;
"Error: 5180 Severity: 22 Date: 20110804 Time: 83157 Database: MY_DB Message: Error: 5180, Severity: 22, State: 1 Could not open FCB for invalid file ID 0 in database tempdb ."
CHECKDB returns no problems, and I suspect that this is a hardware issue with memory.
I have read in a few threads that MAXDOP settings may also have an effect such as this however...
One obvious issue is that the server was only allocated a single logical CPU core.
By no means anywhere near enough, so I have looked to have this addressed regardless.
"Minimum query plan threshold for considering queries for parallel execution (cost estimate):" is set to 5.
Does this setting really matter right now, as there is only a single CPU at present and obviously parallelism will be impossible (or restricted to a single CPU at least).
Any suggestions?
Has anyone else encountered this problem?
There are obviously issues to address with the environment anyway, but there would appear to be an underlying problem other than this.
My plan of action so far is;
Clear cache: done
Allocate more CPU cores (arranged for tonight)
Perform Memory Diagnostics (arranged for tonight)
Move tempdb to dedicated drives (currently it's sharing the data drive)
*Thoughts are that if there are maybe disk corruptions, then moving the file should overcome these, as well as the obvious performance benefits. Can perform I/O diagnostics to verify either way.
Thanks in advance for any other suggestions or tips 🙂
August 4, 2011 at 5:14 am
Incidentally, environment is SQL Server 2000 (Service Pack 4) on Windows Server 2003 R2 (SP2).
I've seen a few solutions where SQL Server has been patched up to SP3 or below, but they don't seem to apply to SP4.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply