May 11, 2009 at 10:00 am
Our SQL ErrTrace file is showing the following message:
[Microsoft][ODBC SQL Server Driver][SQL Server]Warning: Fatal error 7105
Later in the file we see a specific table name. We would like to run DBCC CHECKTABLE over this table. Is it safe to do so with active connections to the database or do we need to kick users out of the application that runs over the database?
Many thanks...
Kay
May 11, 2009 at 10:04 am
Run a full checkDB. It won't kick users out, but it is pretty intensive and may slow the system down.
DBCC CHECKDB (< Database Name > ) WITH NO_INFOMSGS, ALL_ERRORMSGS
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 11, 2009 at 10:34 am
Thanks very much for the response. We are getting authorization to run this command.
Once run, I presume based on the information returned by the command we will have to decide how best to recover. Do you have any advice beforehand, or should we wait and see the outcome?
May 11, 2009 at 2:12 pm
Take a look at this article. http://www.sqlservercentral.com/articles/65804/ The fixes, if any, depends on the results of that command. I prefer not to speculate ahead of time.
It may not be corruption. I don't know what "Fatal error 7105" is. Was there an associated message?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 12, 2009 at 12:42 pm
The DBCC CHECKDB resulted in 0 errors, so apparently the error didn't impact the database or the indicated table. Thanks for the link; I'll bookmark it for future reference.
Just fyi, in the SQL Server Log, the message read:
The Database ID 5, Page(1:631697), slot 39 for LOB data type node does not exist. This is usually caused by transactions that can read uncommitted data on a data page. Run DBCC CHECKTABLE.
I did find out that the DBA who set up this database was having frequent record locks, and he changed a setting that allowed "dirty reads." This may have had some impact in generating this error. We're going to investigate that possibility.
Thanks for your support...yesterday was fairly stressful. I appreciate having someone to turn to.
Kay
May 12, 2009 at 1:00 pm
kwilthew (5/12/2009)
I did find out that the DBA who set up this database was having frequent record locks, and he changed a setting that allowed "dirty reads." This may have had some impact in generating this error. We're going to investigate that possibility.
That would be a good bet, seeing as the error states that it can nbe caused by dirty reads. Maybe point out to that DBA that dirty reads are not the first solution to blocking, that they have downsides and problems, and that optimising the queries is probably a better long-term solution.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply