Session 3: Handling Corruption


Presented by: Robert Davis Running Time: 59 min Corruption can happen no matter how much care we take to prevent it. It’s inevitable, so the best course of action is to be ready for when it does happen. We will learn in the earlier sessions how to detect corruption, and now it’s time to learn what to do once you have identified it. We will explore the different types of corruption and the options for handling each type … without data loss.

Buy This On-Demand Training Now!

This video is part of the Data Integrity and Corruption: A Hard Road to Recovery On Demand training.

Data integrity and corruption can be a complex and scary topic. At some point in your career as a DBA, you will be faced with a potential data loss scenario due to deletion (accidental or not) or corruption. You can’t avoid it. You can only prepare for it and be ready to handle it when it occurs.

Already purchased this? to view your content.

From the Blogs
Sep 29, 2015

Data Breaches and Insider Threats

I’ll sound a bit like Captain Obvious for bringing this up, but it’s important to remember that security encompasses a lot more than protecting sensitive data from the specter of outsider threats like hackers. Properly implemented security policies also account for threat-models that include insiders – or people within your organization....More
Sep 15, 2015

Setting Up Additional Checks to Ensure Regular Transaction Log Backups 1

There’s simply no way to overstate the importance of regular Transaction Log Backups. Not only do they help protect from disaster, but regular execution of T-Log backups on Full (and Bulk-Logged) Recovery databases helps keep thing “fit and trim”. Most of the time, setting up a Notification for when T-Log Backup Jobs fail is enough to let you know when something goes wrong....More
Sep 1, 2015

Stop Using INFORMATION_SCHEMA and SysObjects for Exists Checks 3

Code like this isn’t optimal: IF EXISTS(SELECT * FROM sys.objects WHERE name = N'TableToDrop' AND type = 'U')         DROP TABLE TableToDrop; GO Neither is this: IF EXISTS(SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'TableToDrop')         DROP TABLE TableToDrop; GO Yet, I see both of those used all of the time – over and over again. Even though it’s 2015.  ...More
SQL Server Pro Forums

Get answers to questions, share tips, and engage with the SQL Server community in our Forums.

Sponsored Introduction Continue on to (or wait seconds) ×