Re: ?: Table Restore/Backup :?

In <1993May10.141515.1374@mnemosyne.cs.du.edu> aburt@mnemosyne.cs.du.edu (Andrew Burt) writes: >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. But *WHEN* do you restore it to??? How long was the gap between the disk failure and the time that you next tried to access it? 1 clock cycle? 10 clock cycles? 1 second? 10 minutes? Depending on your configuration it could be any of those! So you restore chunk 2. What do you about the data that you wrote to all the other chunks during that gap? Leave it (at least potentially) inconsistent? Bear in mind that the recovery mechanism relies on the before-image from the Physical Log being there when it tries to re-update it. >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. But I can't afford to have them ignored, I need all the uncommitted data to be rolled back for me. >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. This is a different discussion. I wholeheartedly agree that there should be a restorable object of smaller granularity than an entire system. I strongly disagree that a table (or a chunk) is a viable candidate to be such a restorable object, unless you totally re-design OnLine from the ground up. It is difficult to defend the incapacity to restore an individual database other than as lack of designer foresight. However this is a direct result of the way OnLine's logging works, which is almost certainly one of the main reasons that OnLine outperforms it competition. There is a direct performance trade-off here, and I believe that the design goals for OnLine were performance with resilience, not resilience with performance. The planned enhancement to make a dbspace a restorable object gives the DBA the ability to make that object an individual table, an individual database or anything in between. That is the way it *SHOULD* be implemented. >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. But I think in practice you will find that you will prefer where they intend to jump, over where you are asking them to jump. 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@pyra.co.uk --------------------------------------------------------------------------- We have the technology. The tricky bit is learning how to use it.