It wasn’t much data, but it was a record of millions of dollars’ worth of transactions. This one time (no, not at band camp), I had to sort out a problem that was caused by a person with far too much access to production who was able to get in to the server and delete a few rows from a few key tables. But when the call was about volatile data sets of data that are constantly changing with lots of dependencies across tables, then, everything changed. If it was non-volatile data, for example, look-up information, that would be available in a full backup, I could use SQL Data Compare and compare the production database against the last backup file directly to retrieve the information. I’d go to the source control system, retrieve the appropriate piece of code, and reapply it usually after I’d revoked that person’s access to the production system. When that call came through and it was code or an index or something that I had in source control and could easily retrieve, it really wasn’t a big deal. You know, yesterday, I accidently dropped/edited/deleted/updated a row/table and now I need you to restore the database… What?… No, I don’t want to lose the last 17 hours of data… Yes, I know the CEO thinks we should make a profit what does that have to do with it… Oh that sale was recorded yesterday wasn’t it? But I just want one row/table/index.
I used to dread the phone call that went something like this:
Object Level Recovery with SQL Virtual Restore - Simple Talk
0 kommentar(er)
