Re: Help, tbtape is trashing my rootdbs!

Michael Faurot writes: >Here's the problem . . . > > After initializing rootdbs and shared memory without any > difficulties I use ISQL to create a couple of databases, fill > one of them up with records and the other is simply empty. > > Now I wish to back-up this entire configuration to tape. So I > use the Archive option from within tbmonitor. I then choose > the option to Create, mount the tape in the drive, select "0" > for a level 0 archive and then receive the following error > message: > > Error reading from the disk, Error No. = 5. > > If I don't shutdown OnLine, I can still access the databases > but if I do shutdown OnLine, I get the following error messages > when I attempt to bring it back up: > > Bad Primary Chunk '/dev/rootdbs' > tbinit: fatal error in shared memory initialization > > I'm fairly certain there's nothing wrong with the tape > perameters I'm using because, oddly enough, if I only create > the first database, I can back-up the system without it > corrupting the rootdbs. It's only after I add the second > database and attempt to back it up that it trashes rootdbs. > > If I make no attempts to back-up the OnLine partitions, OnLine > goes up and down just fine. > >Now when I went to school, I was always of the impression that >back-up utilties are for the preservation of your data. Maybe I'm >missing something but this tbtape program just doesn't seem to be >fitting the mold here too well. An interesting case of drawing the wrong conclusion from the evidence presented. Tbtape does nothing but read the data in your OnLine system. The error message you receive is one that tbtape is getting when doing a read of the data. Whenever such an error is encountered, the chunk is marked as down and OnLine will not come up after the next shutdown without a restore from archive (more on this in a bit). Btw, error 5 is an o/s error and means "I/O error." I will speculate that the reason the second database seems to "cause" the problem is that the space allocated for the tables in that database contain the problem area. Since tbtape will only try to read allocated space, it does not encounter the problem until the second database is created. I am not sure why the bad block was not encountered at the create time - it must be that the space allocated is not all read at the create time. What you should do is run a low-level disk surface check on the devices you are using for your chunks. Typically, this problem is caused by bad blocks present on the device. As per bringing your system back up after a "bad block experience": if you edit your tbconfig file and set MIRROR to 1, you will be able to restart your system even though the chunk is marked as down. Dave -- Disclaimer: These opinions are not those of Informix Software, Inc. ************************************************************************** "I look back with some satisfaction on what an idiot I was when I was 25, but when I do that, I'm assuming I'm no longer an idiot." - Andy Rooney