Re: stale dbspace info

Christoph Liebig wrote: > > Hi ! > > Recently we had a power loss which caused a hard disk damage in turn. > The disk contained several primary chunks as cooked file space for > dbspaces. And now you know why Informix recommends not using cooked files... > > Although the dbspaces are lost, informix still carries the > configuration infos about the now physically lost dbspaces (e.g. > onstat -d lists them).> > On my way to reestablish this dbspaces I tried first to drop them. > This was not possible, onspaces would report an "internal ISAM error". > I went on recreating the dbspace files with exactly the same path as > before (of course, the i-nodes will be different). > This did not help much, onspaces gives me the same error as above. > > My question: how can I delete the stale info on dbspaces that no more > exists, e.g. is there some system table to edit ? Chris, howzabout the following: Suppose the dbspace you lost has 2 chunks in the following files chunk 4: /usr/dopey1 Offset 100000K, Size 24000K chunk 6: /usr/mopey3 Offset 0K, size 50000K Create a bogus instance - each dbspace about a megabyte. Except chunks 4 and 6 of the new instance. Set *these* to the same device, offset, size as the dbspace on your live instance. When the bogus OnLine initializes these, they will be identical to the way the looked when they were created on the live system. I'm not sure if they need to be part of the same dbspace as they were in on the production system. To be safe, configure the dbspace names and chunk assignments identically to those of the production system. Now, after you have created all these chunks on the bogus system, knock it off-line and bring back up the production system. The dbspace containing those chunks should come up looking clean & empty. And accessible. As well as droppable, the whole point of this exercise. If you find this tedious - like they are chunks 98 and 153 of your online system, you might have Advanced Support log into your system and use some undocumented (and unusable by customer) options to oncheck that allow them to modify flags on the dbspace descriptor in the dbspace page. They can change flags so that the dbspace is not flagged as a BLOBspace, bypassing many checks that would be performed (like looking at the chunk free lists in each chunk) and allowing the bogus BLOBspace to be dropped. If your database isn't too complex, the fake instance should do just fine. Good luck, and GET the *^^%%$@ OFF THOSE &^%$#! COOKED FILES! -- -- Jake (A pompous purveyor of patently pointless prestidigitation) +------------------------------------------------------------+ | The expedient performance of a task with excessive concern | | regarding its duration-to-completion engenders a virtual | | certainty of diminished benefit therefrom. | | -- Benjamin Franklin (but he said it in 3 words) | +------------------------------------------------------------+