Viewing 15 posts - 331 through 345 (of 994 total)
There's a known bug with this on tempdb (see http://www.sqlservercentral.com/Forums/Topic770808-149-1.aspx). Could be the same thing. I'll ping Product Support.
September 15, 2009 at 12:23 pm
Is this a user database or tempdb?
September 15, 2009 at 10:55 am
Can you post the actual errors that it found too please?
Btw, you're running SQL 2000 (as I removed the repair_fast statements from the output in 2005). Please be aware that...
September 12, 2009 at 9:47 am
This looks like a bug - and it seems like you have a repro too. You should call Product Support to help figure out the problem. I haven't seen any...
September 9, 2009 at 12:41 pm
You're most likely in the FULL recovery model and you're not taking log backups - in which case it will grow forever. Either start taking log backups or switch to...
September 8, 2009 at 3:31 pm
Hi Alex - one of the Principal Escalation Engineers will be contacting you directly. Thanks
September 8, 2009 at 10:42 am
The databases that are failing have corruption that's preventing the upgrade steps from working. On 2000 there are plenty of metadata corruptions that DBCC CHECKCATALOG won't find - it was...
August 29, 2009 at 11:46 am
If you have an older backup - you *might* be able to restore it and check to see if that page has some of the deleted rows on - but...
August 28, 2009 at 9:38 am
Yes, I recommend you stress test your I/O subsystem. You'll have to poke around to find some SQLIOSim templates - I have some links on my blog but I...
August 28, 2009 at 8:36 am
Yeah, on 2000 you may need to run repair a couple of times to get everything fixed up - on 2005 the indexes would have been fixed in a single...
August 28, 2009 at 8:14 am
Yup - that's what it did. The output from repair is very simple to read, just the output from the consistency checks that's complicated 🙂
August 28, 2009 at 8:09 am
I already have error message explanations for 2000 and 2005 - 250+ page docs each.
In this case, there are no allocated pages so the extent is marked alloacte back to...
August 27, 2009 at 6:42 am
You need to get this onto a new I/O subsystem as its clear that's what is causing the corruptions.
Repair is the easiest way to fix this if you're not a...
August 27, 2009 at 5:59 am
Ah - that seems to be the smoking gun - hope that proves to be the issue.
August 25, 2009 at 8:28 am
Anything with kernel-mode access to the server's memory can corrupt memory wherever it wants.
Yup - there are a lot to it. Maybe I'll get around to it someday 🙂
Thanks
August 25, 2009 at 6:42 am
Viewing 15 posts - 331 through 345 (of 994 total)