Re: Problem with Cold Recovery

In article <5fsjta$jvs@cssun.mathcs.emory.edu>, John Wells <ontop@worldnet.att.net> writes >We are attempting to recover some data we lost from a week old ontape >archive by doing a full informix cold recovery. There are two dbspaces >with two chunks in each space. When we do the ontape -r the first dspace >recovers just fine, but when informix gets to the second one it chokes. We >get a message that says "unable to open device dbspace2". This is not a >direct quote. > >We searched the log and found this message. rsphr.c, line 396, thread 32, >proc id 3017, Aborting physical restore of ROOT dbspace, Aborted by CLIENT. > > >Needless to say we still need the data and can't seem to recover all of our >dbspaces. Since oninit can still access dbspace2, we tried a warm recovery >of dbspace2. That resulted in message which said Memory Fault. From my >experience that means ontape core dumped. Not very useful. > >Has anyone encountered a similar problem? Do you have a solution? Is >there a repository of problems I can search? I have tried tech notes and >found nothing. > >John Wells, First Pacific Corporation, 503-315-7233 From the reference to ontape I assume you are using Online 7.x - which exact version? When ontape starts a restore you get a list of chunks that will be restored. Does all these chunks exist? Are they all owner informix, group informix, mode 660? Note if the are links then both the link and whatever it links to should be owner informix, group informix, mode 660? On Solaris I had to follow several layers of links... .../chunks/chunk1 (My chunks) link to /dev/rdsk/c1t1d0s0 (raw device) links to /dev/devices/sbus......@1ef/....2,b (or somethingl like that) I set them all as informix wants (use chown -h, chgrp -h, chmod -h to change the permissions on the link itself rather then what it points to).....the option may have been -H, better check the man page... -- David Williams