Gallery

Retrospection: PHISSUG S01E02, 99 way your data could die.

PHISSUG S01E02, 99 ways your data could die

It was Valentine’s season back then and my talk provides an antithesis to the theme (Yes, Mejo bitter ako nung mga nakaraang taon kaya ang motto ko ay “Walang Poreber” hanggang sa Valentines special namin dala dala ko yung motto na yun). I talked about how data loss could occur (99 ways is more of an exaggeration since we don’t have time to go through that exhaustive list), how to mitigate them, and how to prevent them. The other speaker talked about Data Replication (Ang motto naman niya eh “Go forth and multiply” which is swak na swak sa season).

Some of the topics that I’ve discussed are the factors to consider when planning for data loss (Hardware and Software). For hardware problems, the usual mitigation is redundancy/high availability and a good material that should be included in my presentation is Brent Ozar’s blog post about the costs of high availability. I can see that it’s a good way to communicate with managers since it roughly translates technical stuff to their [money] language.

On the other hand, software problems largely depend on the people who are managing the server. In my presentation, my assumption is that the server has the sole role of a database server. It would be more problematic if the server has multiple roles since problems that could crash the server may arise from those other moving parts. The focus of the software part is on the destructive TSQL Statements (kinda like that Db Oops thing, you know… that awkward moment when you accidentally executed an update statement without the WHERE Clause).

The mitigations for software problems is a good backup plan. In dire times where the backup is not available, you have to resort to the dark arts of data recovery. My presentation did not talk about resurrecting a dropped database from the dead, but legends say that recovery of the deleted mdf file is possible (using file recovery tools like EaseUS or Recuva) I haven’t heard of a success story about this though (Even my friend who had the exact same problem failed to bring his database back to life. May the lord have mercy on his soul).

I demonstrated recovering deleted data using ApexSQL Recovery, and SSMS Boost‘s capability to stop you from committing Db Oopsies. By the way, Ssms Boost’s beta release is compatible with the newest Ssms version.

With the mitigation and prevention of data loss, we concluded: “Sa Data may Forever”