August 5, 2011 at 7:41 am
I had Litespeed at my previous employer. About one a month a dev would either do something dumb to the data or want to know "what did this row look like on a day in the past?"
The table restore was great for that, made the devs very happy since I could fix (almost) anything they could damage. Easy to use - since I've been gone from the job one of the devs jumped in & recovered his own damaged data, didn't even have to call me to find out how to do it.
The downside is that to be a *fast* recovery tool, you have to turn on the object-level map for large DBs -- adding extra time to the backup window. At backup time this builds a map of what in the BAK belongs to what table. Without the map Litespeed first has to scrape through the BAK to figure it out at restore time. When it has to be fixed !!!NOW!!!, that's a problem.
August 5, 2011 at 7:41 pm
From what I've heard, Virtual Restore is probably the easiest way to go.
Aside from backups, there's archiving.
I feel obligated to point out that for some situations, particularly where detailed change auditing is required, "full" history can be very useful, particularly if you take the time to develop the queries which can answer "Give me the results of this SQL _as if_ it had been run at <datetime>".
Note that this tends to take enormous amounts of space and some more or less intricate temporal coding, but if you have certain requirements, it's very useful: regulatory compliance auditing, or a business requirement for the "as if it had been run" at multiple arbitrary time increments, and/or very far past increments.
Now, as far as guaranteeing (i.e. WORM media) that your history tables aren't changed by someone else, that's another story.
Alternately, if the requests are usually only for a couple days or a week ago, you could set up log shipping (manually, if need be) to multiple targets, and have the "hour-old" server, the "day-old" server, the "two day-old" server, and the "week-old" server, as well.
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply