March 25, 2011 at 5:43 am
vamshikrishnaeee (3/25/2011)
I have moved the data from the corrupted database to the new database. Will the new database get corrupted because of importing data from the corrupted database because might be some of data which I have been imported,is from the corrupted page?
No. If SQL encounters a corrupt page during any read, it will throw an error and terminate the session.
Your corruption was in a system table, not in the user data (though there could have been other corruptions that we don't know about.)
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
March 25, 2011 at 5:56 am
Ray Mond (3/25/2011)
Having said that, you might want to check the contents of that page just to find out what exactly it contains e.g.
It's a page in one of the system tables. If it was a user table, checkDB would not itself have failed with an invalid checksum page. Plus, that early in the file is right in the system table area.
Sysobjvalues, to be specific.
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
March 30, 2011 at 4:50 am
Hi,
I have gone throught several blogs on Page restores. But the process of page restore looks like this:
Restore the corrupted page from the latest full backup
Take the current tail log backup
Restore the all the log backup after full backup and restore tail backup at last
My question is:
1.Can't we use differential backup in between instead of restoring all the logbackups?
2.While restoring full backup do we need to put the database in norecovery mode as usual for next backups to restore?(as many of the blogs are shown this with recovery)
Thanks,
Vamsy
March 30, 2011 at 5:02 am
vamshikrishnaeee (3/30/2011)
1.Can't we use differential backup in between instead of restoring all the logbackups?
You can use a diff, providing that it doesn't contain the corrupted pages. If it was taken after the corruption, it should be tested (restored and checkDB) before being used for a page restore.
You will still need to restore log backups since the diff and end with a 'tail' log backup
2.While restoring full backup do we need to put the database in norecovery mode as usual for next backups to restore?(as many of the blogs are shown this with recovery)
The restore is done with norecovery, but if the edition is Enterprise, the DB remains online (in most cases)
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
March 30, 2011 at 5:16 am
Hi Gail,
Can you please elaborate this if you don't mind.
"The restore is done with norecovery, but if the edition is Enterprise, the DB remains online (in most cases) "
As in normal cases restore strategies in any edition is
restore full backup with norecovery
restore diff bakcup with norecovery
restore last log backup with recovery
As far I know if we restore fullbackup with recovery we cannot restore other backups on the database.If not please suggest me on this.
Thanks,
Vamsy
October 4, 2011 at 9:29 am
Run CHKDSK (no repair function) on the Disk that contains the corrupt file....
If you receive these errors:
/* WARNING! F parameter not specified.
Running CHKDSK in read-only mode.
CHKDSK is verifying files (stage 1 of 3)...
6176 file records processed.
File verification completed.
133 large file records processed.
0 bad file records processed.
0 EA records processed.
0 reparse records processed.
CHKDSK is verifying indexes (stage 2 of 3)...
13853 index entries processed.
Index verification completed.
Errors found. CHKDSK cannot continue in read-only mode. */
Then you have an NTFS problem (these errors can be found on a local or SAN storage). You can try and fix the error by shutting down SQL and running chkdsk with automatic fix or allocate new Disks and restore your databases.
Hope this helps,
David
October 4, 2011 at 9:32 am
Run CHKDSK (no repair function) on the Disk that contains the corrupt file....
If you receive these errors:
/* WARNING! F parameter not specified.
Running CHKDSK in read-only mode.
CHKDSK is verifying files (stage 1 of 3)...
6176 file records processed.
File verification completed.
133 large file records processed.
0 bad file records processed.
0 EA records processed.
0 reparse records processed.
CHKDSK is verifying indexes (stage 2 of 3)...
13853 index entries processed.
Index verification completed.
Errors found. CHKDSK cannot continue in read-only mode. */
Then you have an NTFS problem (these errors can be found on a local or SAN storage). You can try and fix the error by shutting down SQL and running chkdsk with automatic fix or allocate new Disks and restore your databases.
Hope this helps,
David
October 4, 2011 at 9:32 am
Run CHKDSK (no repair function) on the Disk that contains the corrupt file....
If you receive these errors:
/* WARNING! F parameter not specified.
Running CHKDSK in read-only mode.
CHKDSK is verifying files (stage 1 of 3)...
6176 file records processed.
File verification completed.
133 large file records processed.
0 bad file records processed.
0 EA records processed.
0 reparse records processed.
CHKDSK is verifying indexes (stage 2 of 3)...
13853 index entries processed.
Index verification completed.
Errors found. CHKDSK cannot continue in read-only mode. */
Then you have an NTFS problem (these errors can be found on a local or SAN storage). You can try and fix the error by shutting down SQL and running chkdsk with automatic fix or allocate new Disks and restore your databases.
Hope this helps,
David
October 4, 2011 at 11:16 am
Sorry for the Dups, looks like SQLServerCentral had issues...
Viewing 9 posts - 16 through 23 (of 23 total)
You must be logged in to reply to this topic. Login to reply