Viewing 15 posts - 316 through 330 (of 994 total)
Krasavita - we're not trying to be obtuse when we're explaining things, but these really are very simple concepts that an administrator should understand. It may be that you're an...
October 12, 2009 at 3:53 pm
I'm not sure what you don't understand. You got I/O errors. They disappeared. The page with the I/O error was still allocated to the table in the error message. This...
October 12, 2009 at 5:53 am
The explanation is: in all the cases where I've seen your error occur, and then disappeared again, it was the I/O subsystem. I've seen hundreds of such cases.
I can't give...
October 10, 2009 at 10:59 am
It's kind of self-explanataory - the sysusers table has 31 rows that are stored in one page.
October 9, 2009 at 8:12 am
You don't *have* to turn it off because it's going to do anything bad to your system, but you can if you want to. It's easier to have output come...
October 9, 2009 at 7:45 am
No, you didn't need to turn that TF off - all it does is put DBCC undocumented command output to the console instead of the errorlog.
Ok - your I/O subsystem...
October 9, 2009 at 7:06 am
Go into that database and run DBCC CHECKTABLE (sysusers) and post the results.
Also run the following
DBCC IND (yourdbname, sysusers, -1)
and post the results. That will list all the pages allocated...
October 8, 2009 at 2:48 pm
Yes, you're wrong. The output from CHECKDB tells you that you need to use REPAIR_ALLOW_DATA_LOSS.
CHECKDB found 0 allocation errors and 16 consistency errors in database 'docbase'.
repair_allow_data_loss is the minimum...
September 17, 2009 at 12:31 pm
No - you need to use the REPAIR_ALLOW_DATA_LOSS option, as the output clearly states, and if you do this you're going to lose data from the subcontent table.
The corruption looks...
September 17, 2009 at 11:39 am
Thought that might be the case.
One other thing to try - can you backup the database and restore it on a different server and see if the same behavior is...
September 16, 2009 at 12:13 pm
This is very odd.
Can you do an experiment?
1) Run CHECKDB 3 times in a row and report the results.
2) Run CHECKDB 3 times in a row, but run DBCC DROPCLEANBUFFERS...
September 16, 2009 at 11:50 am
Please start a new thread rather than continuing an unrelated one.
In this case you were lucky - the pages were linked into the table (probably by the corruption) and didn't...
September 16, 2009 at 11:20 am
This says to me that there's an issue with the I/O subsystem randomly returning corrupt data, or maybe a weird stale-read issue from a disk or RAID controller. After the...
September 15, 2009 at 2:58 pm
The 2005/2008 SSMS difference must be an SSMS thing - but that would be a bug that you get no errors. Do you get any results when running from 2008...
September 15, 2009 at 2:15 pm
Ok - that bug is tempdb only it seems.
Can you run DBCC CHECKDB (yourdb) WITH ALL_ERRORMSGS, NO_INFOMSGS and post any results?
[Edit: Hmm - see that you don't get DBCC errors...
September 15, 2009 at 2:06 pm
Viewing 15 posts - 316 through 330 (of 994 total)