Viewing 15 posts - 241 through 255 (of 994 total)
You've got a damaged PFS allocation page - that's an error that I couldn't write a 100% correct all the time repair for. As Gail says, you must restore from...
February 14, 2010 at 3:01 pm
Well of course they do - no-one was saying SQL Server is infallible - just that it doesn't fail in the way described.
February 11, 2010 at 8:41 am
I heard this anecdotally several times while writing CHECKDB and emergency mode repair for 2005. Spent several days trying to force SQL Server to make a database go suspect because...
February 10, 2010 at 10:46 pm
Glad you enjoyed it.
The 8998s won't go away - the damage has already been done to the database - not sure if the multipath IO could have been the culprit....
February 10, 2010 at 1:31 pm
No - you can usually always attach a suspect database back into SQL Server. See TechEd Demo: Creating, detaching, re-attaching, and fixing a suspect database
February 10, 2010 at 9:05 am
1) No. It just means that the corrupt pages don't have page checksums on them for some reason. Was the database upgraded from 2000?
2) Your storage group are fools. Is...
February 10, 2010 at 8:40 am
The original page in the error message described (1:1022464) is an allocation page that the database cannot function without - this page being corrupt is the cause of the original...
February 10, 2010 at 8:36 am
With all due respect Ted, you dreamed everything you described above 🙂 It doesn't do any of that except the checkpoint at the start, and that's just to flush out...
February 9, 2010 at 9:41 pm
@gdmilner That's not true. It's pretty well known how to attach a detached suspect database back into SQL Server in all versions, using a dummy database. Plenty of sites document...
February 9, 2010 at 5:58 pm
Ah - I'd forgotten all about that one. Luckily not a bug of mine 🙂
Glad you got a solution finally.
February 9, 2010 at 9:21 am
@jadsmith But the question wasn't about log backups - it was about full backups. Full backups do not affect log backups, nor do they take them into account. A full...
February 9, 2010 at 8:23 am
@robert Not true - the action CHECKDB takes depends on the corruption - there are some cases where I delete just the corrupt record rather than the whole page.
IMHO this...
February 8, 2010 at 8:13 am
It's not the data portion of the restore, it's the replay of the transaction log in the restore that's hitting an identity problem. This can happen if a value gets...
February 6, 2010 at 12:30 pm
What's worse is that you've got tables whose allocations are intermixed so you're running the risk of corrupting your actual data by continuiing to run on this database - you...
February 6, 2010 at 11:54 am
Viewing 15 posts - 241 through 255 (of 994 total)