onload and detached indexes

Folks, Production and Development Environment OS: HPUX 11.0 IDS: 7.30 FC7 Help is required. We have recently discovered page corruption in one of our production databases. 14:22:16 bfcheck: bad page: pg_addr 14a4a71 != bp->bf_pagenum d6759d A case has been opened with Informix and the recommendation was oncheck -cI, cD, and cc. The database has 350 tables. A test was carried out in our development area to determine the length of time this analysis would take. We concluded that to complete this analysis this year we had to make other arrangements. The alternative was an onunload of the production database and an onload in another environment. The attempt to restore the database failed at a detached index. The error follows - ISAM error: no such DBspaceError building TBLspace. ERROR: DBspace dbsradidx not found for index fk1_route_address. I have tried the following onload commands; onload -b 64 -s 71303168 -t /dev/rmt/c3t1d0BESTb -d data00 cortran onload -b 64 -s 71303168 -t /dev/rmt/c3t1d0BESTb -fd dbsradidx data00 -ddata00 cortran onload -b 64 -s 71303168 -t /dev/rmt/c3t1d0BESTb -fi fk1_route_addressdbsradidx data00 -d data00 cortran Informix tech support has identified 2 known bugs 77981 and 95776. The details I do not know. One work around is to create dbspaces for the detached indexes. This is not an option, there are several detached indexes. Have any of you come across this before? Is there a practical work around? Perhaps there is way to do this analysis in production without impacting users. Thanks in advance, Scott H.

I've had this problem in v7.24. The bug is that, although you can use onload -d to load tables into a specified database, onload tries to load detached indexed into their original location (which, in an inter-database transfer, may not exist of course). It's just pants, isn't it? In fact, I've never worked with a version of IDS 7 that had a version of onload that DID work reliably! Henderson, Scott wrote in message <80rqoe$2rh$1@news.xmission.com>... > >Folks, > >Production and Development Environment >OS: HPUX 11.0 >IDS: 7.30 FC7 > >Help is required. > >We have recently discovered page corruption in one of our production >databases. > >14:22:16 bfcheck: bad page: pg_addr 14a4a71 != bp->bf_pagenum d6759d> >A case has been opened with Informix and the recommendation was oncheck -cI,>cD, and cc. The database has 350 tables. A test was carried out in our >development area to determine the length of time this analysis would take. >We concluded that to complete this analysis this year we had to make other >arrangements. The alternative was an onunload of the production database >and an onload in another environment. > >The attempt to restore the database failed at a detached index. The error >follows - > >ISAM error: no such DBspace>Error building TBLspace. >ERROR: DBspace dbsradidx not found for index fk1_route_address. > >I have tried the following onload commands; > >onload -b 64 -s 71303168 -t /dev/rmt/c3t1d0BESTb -d data00 cortran >onload -b 64 -s 71303168 -t /dev/rmt/c3t1d0BESTb -fd dbsradidx data00 -d>data00 cortran >onload -b 64 -s 71303168 -t /dev/rmt/c3t1d0BESTb -fi fk1_route_address>dbsradidx data00 -d data00 cortran > >Informix tech support has identified 2 known bugs 77981 and 95776. The >details I do not know. One work around is to create dbspaces for the >detached indexes. This is not an option, there are several detached >indexes. > >Have any of you come across this before? Is there a practical work around? > >Perhaps there is way to do this analysis in production without impacting >users. > > >Thanks in advance, > >Scott H. >