Re: ?: Table Restore/Backup :?

In <1993May8.140157.9963@mnemosyne.cs.du.edu> aburt@mnemosyne.cs.du.edu (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, It depends on how you define the issue. Hence the development of dbspace level recovery. >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 There is always tbunload/tbload if you want to insist on doing things for yourself and don't care about relational integrity. >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. Which could quite feasible be spread across all the chunks in your system. Where's the advantage? >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). It would probably take just as long (probably longer) to work out which bits to ignore and how to regain consistency with the bits that are not being restored, than to restore the whole thing. Where's the advantage? >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. It *does* keep track of this. A restore puts *all* your chunks back together. That's what provides the *GUARANTEE* that your chunks are consistent with each other, even if you need/desire to choose not to rollforward the latest log(s). You appear to forget that your failed table(s) RELATES to other tables, these relationships need to be maintained and/or rolled back, not just the data in the failed table(s). >So, where's the hole in this dike? >-- I'm getting wet! graeme -- Disclaimer: The author's opinions are his own, and not necessarily those of Pyramid Technology Ltd. or Pyramid Technology Inc. --------------------------------------------------------------------------- -m------- Graeme Sargent Voice: +44 (0)252 373035 ---mmm----- Senior Database Consultant Fax : +44 (0)252 373135 -----mmmmm--- Pyramid Technology Ltd. Telex: Tell who??? -------mmmmmmm- Farnborough, Hants GU14 7PL Email: graeme@uk.pyramid.com --------------------------------------------------------------------------- We have the technology. The tricky bit is learning how to use it.