Re: ?: Table Restore/Backup :?

In <1993May10.095816.15007@pyra.co.uk> graeme@pyra.co.uk (Graeme Sargent) writes: >In <1993May8.140157.9963@mnemosyne.cs.du.edu> aburt@mnemosyne.cs.du.edu (Andrew Burt) writes: >>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. >Which could quite feasible be spread across all the chunks in your >system. Where's the advantage? I wasn't making myself entirely clear: The restore should then restore only those pages that reside on the dead chunk. So if table A lived on chunks 1, 2, and 3, and chunk 2 went down, it should restore the pages to chunk 2 from table A; and from other tables that lived on 2. >>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). No, this should be no different than restore the whole table, but happening to ignore the pages that lived (and still live) on chunks 1 and 3. Or for that matter, no different than restoring the whole db, but ignoring pages for anything but chunk2. It still reverts back to a question about how sound it is for informix to say "rebuild all your databases" when you lose, say, 1 disk out of 100. I can see where mirroring might not be feasible with a huge DB (e.g., perhaps the system can't support enough disks, say, it's 75% full of disks now). Perhaps it's not cost effective to buy twice the disk space. Yet the software *could* do it, so it seems to me an important feature they're not providing. (And remember, this isn't a $100 program we're talking about here. Database packages seem to be among the absolute most expensive software you can buy, easily running into six figures. My expectations go way up for those kind of bucks.) (And, because of what seems to me to be a bit of an oligopoly, you can't switch to another vendor -- they aren't competing in price, so you can't really get anything cheaper.) But if I have to live with the price, I want them to jump. -- Andrew Burt aburt@du.edu "But if he was dying he wouldn't bother to carve "Aaaaargh", he'd just say it."