Re: ?: Table Restore/Backup :?

->From: ijk@cbnewsh.cb.att.com (ihor.j.kinal) ->Subject: Re: ?: Table Restore/Backup :? ->Date: Mon, 10 May 1993 14:13:01 GMT ->Reply-To: ijk@cbnewsh.cb.att.com (ihor.j.kinal) ->Organization: AT&T -> ->> 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 -> This is almost as much fun as our discussion of leap years a while back! While I have problems with some of the DETAILS of what Andrew Burt is asking for, I believe I am closer to his general postion than I am to Ihor Kinal's position. An awful lot depends on the structure of your database. I use the non- standard concept of "sub-database" in most of my database designs. A "sub-database" is merely a group of tables that are closely related, i.e., share a lot of keys, whereas different sub-databases are more distantly related, i.e., have comparatively few shared keys. Note that here the number of shared keys is the number of (sets of) columns that are common among tables, not necessarily dependent on the number of rows in the tables. I have also observed that tables within a sub-database also tend to have similar activity: either they are all rather static or all rather actively changing. If a DBA were to place a sub-database into a distinct (set of) dbspace(s), then such dbspaces would be good candidates for individual backup and restore. Ihor's legitimate concerns about consistency between a restored portion of a DB and the remainder of the DB are reduced and may even be eliminated by this kind of data partitioning. By the very nature of sub-databases, the critical consistency is all within a single sub-database. Consistency between sub-databases is certainly important, but is normally much easier to re-establish manually. For example, 'orders' and 'order_items' belong in one sub-database, while 'customers' probably belongs in a separate sub-database, assuming a company with a lot of repeat business from customers. Similarly, inventory activity belongs in a separate sub-database from product-line and supplier informa- tion. A relatively new customer might need to be manually reinserted into a restored dbspace containing the 'customers' table. However, that is minor, compared to trying to rebuild all the links between 'orders' and 'order_items' if one table, but not the other, is restored. Regards, Alan +------------------------------+---------------------------------------+ | R. Alan Popiel | Internet: alan@den.mmc.com | | Martin Marietta, LSC | ( Please note: My opinions do not ) | | P.O. Box 179, M/S 5422 | ( represent official Martin policy. ) | | Denver, Colorado 80201-0179 | Voice: 303-977-9998 | +------------------------------+---------------------------------------+