November 24, 2010 at 12:48 pm
YSLGuru (11/24/2010)
I have to make a decision about what to do by tomorrow and since its the Holidays I didn’t; know if you would be reading the threads again till after the holiday.
What holiday? No holidays here til mid Dec.
If the bits that contain the corrupt pages have not changed since DPM last backed them up then any corruption of those would not be pulled into the backup and therefore not included in restores. Does that make sense?
Yes. Take a backup (a proper backup, not this DPM mess) and restore and test that. If DPM is using the diff map to tell what changed, corruption would not indicate as changed because the file changes outside of SQL. If DPM works the way you describe, then restoring from it is like restoring a full backup from before the corruption and a diff backup from after. The database is corrupt, but the diff backup doesn't contain it
3rd party tools use SQL's VDI interface to do backups. Essentially they ask SQL to do a backup as it would for BACKUP DATABASE but instead of writing the data to disk, to give it to them to do something with (compress, encrypt, store differently, etc).
Don't reboot. If the DB is corrupt there's always a chance it could come up suspect. I'd suggest fix the corruption (repair/restore) then reboot.
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
December 1, 2010 at 1:50 pm
GilaMonster (11/24/2010)
YSLGuru (11/24/2010)
I have to make a decision about what to do by tomorrow and since its the Holidays I didn’t; know if you would be reading the threads again till after the holiday.What holiday? No holidays here til mid Dec.
If the bits that contain the corrupt pages have not changed since DPM last backed them up then any corruption of those would not be pulled into the backup and therefore not included in restores. Does that make sense?
Yes. Take a backup (a proper backup, not this DPM mess) and restore and test that. If DPM is using the diff map to tell what changed, corruption would not indicate as changed because the file changes outside of SQL. If DPM works the way you describe, then restoring from it is like restoring a full backup from before the corruption and a diff backup from after. The database is corrupt, but the diff backup doesn't contain it
3rd party tools use SQL's VDI interface to do backups. Essentially they ask SQL to do a backup as it would for BACKUP DATABASE but instead of writing the data to disk, to give it to them to do something with (compress, encrypt, store differently, etc).
Don't reboot. If the DB is corrupt there's always a chance it could come up suspect. I'd suggest fix the corruption (repair/restore) then reboot.
Gail,
Sunday I dropped our Database and created it anew from the most recent backup done by DPM. When I ran CHECKDB afterwards it reported no problems.
When I ran CHECKDB on Monday &Tuesday moring it again reported no problems.
This morning I got an email from my boss (I am outsick) that the problem is back and sure enough when I hust ran CHECKTABLE for the same table that had the errors last time itis again reporting problems.
I have the ITGuys looking at the hardware. Any thoughts? If this were a true data issue I don;t ssee how it could come back in a new copy of the data, a copy that CHECKDB verified had no problems and yet here we rare. This still sound like a hardware issue to you?
Kindest Regards,
Just say No to Facebook!December 1, 2010 at 2:04 pm
Once more with feeling...
ALL corruption is either a faulty IO subsystem or a SQL bug. 99% - IO subsystem problems. Repeated corruption is a good indication that something is wrong somewhere in the IO stack.
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 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply