Re: ?: Table Restore/Backup :?

> 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). > > 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. > > So, where's the hole in this dike? > -- > > Andrew Burt aburt@du.edu I would like to object. Even if I could restore a file, I normally would NOT. Why not? Because no file is an island, entire of itself [pardon for the Donne misquote]. Most of the data in my files is related to other files. I CANNOT afford to have inconsistent data. [Data loss is not nice either, but a consistent db is critical]. Sure, there are exceptions to this point, but overall, I believe that most applications would have this limitation as well. Think about it. Standard disclaimers apply, Ihor Kinal att!cbnewsh!ijk