Re: ?: Table Restore/Backup :?

Andrew Burt writes: |> |> Maybe I'm being simplistic, but wouldn't it make some sense to address |> this issue? Regardless of mirroring or raid5 type recovery ability, |> Informix still *ought* to provide a way to rebuild a table or all tables |> on a chunk that goes down. It sounds simple to me: Have informix keep |> track of which chunks a table is on (kept redundantly on different chunks); |> if a chunk is lost, it could report: you need to restore tables A, B, and C. |> Informix should then be able to restore from archives and logs such that |> all tables are brought forward as needed (i.e., ignore restoring tables that |> are already current). What happens when you lack the logical logs for the full rollforwward? This could leave you with some tables "up to date" and others "out of date". If there are referential constraints across two such tables, your database could be quite a mess afterwards. |> Ideally, it would be nice for informix to keep track of what *pages* are |> on what chunk, both in the archive and logs, so that a restore could |> put that chunk back together. Would you be willing to eat the additional time it would take to support all that additional info? Bear in mind that the more "bombproof" you make a piece of software (esp. a complicated piece of software), the longer it will take to accomplish any task. Dave Disclaimer: These opinions are not those of Informix Software, Inc. ************************************************************************** "I look back with some satisfaction on what an idiot I was when I was 25, but when I do that, I'm assuming I'm no longer an idiot." - Andy Rooney