Viewing 15 posts - 16 through 30 (of 993 total)
You might be able to try the hack-copy described at https://www.sqlskills.com/blogs/paul/disaster-recovery-101-fixing-a-broken-boot-page/ but for page 1:58 instead of 1:9. No idea if it will work as I've never tried it, but...
November 1, 2017 at 1:39 am
October 31, 2017 at 11:59 am
The 824 is a read failure of a page in a critical system table. That's not repairable and not fixable manually either. You'll need to script out as much as...
October 31, 2017 at 9:52 am
The full will start at 12.00. It will not be blocked by the log backup. When the log backup completes, the log clearing will be deferred until the full backup...
May 1, 2016 at 11:06 am
Almost impossible to say. Could be the I/O subsystem at the source, at the destination, something during the network copy, and so on.
April 28, 2016 at 8:34 pm
Looks like something trashed a contiguous block of your data file, filling it with zeroes, so a bunch of pages at the leaf-level of the table's clustered index have been...
April 28, 2016 at 3:58 pm
kosha5 (12/1/2015)
December 1, 2015 at 9:50 am
It's not possible for there to be corruption in a database that doesn't get included in a backup - so I wouldn't have said that.
If you're offloading DBCC CHECKDB to...
May 13, 2015 at 3:44 pm
Nice script!
March 10, 2015 at 4:12 pm
CHECKDB is orthogonal to restore speed. Likely you happened to end the data-reading portion of the backup at a point where there are long-running transactions to roll back, or lots...
October 27, 2014 at 6:56 am
Could be the problem from the fix mentioned above. If not, likely a transient corruption problem from the I/O subsystem where it returns bogus data once in a blue moon...
October 9, 2014 at 10:07 am
No - don't run it in parallel - you'll overload your server and I/O subsystem.
June 18, 2014 at 11:50 am
Viewing 15 posts - 16 through 30 (of 993 total)