Re: anomalous tbtape behavior

In article <3ig914$nhn@mojo.eng.umd.edu> mheinick@eng.umd.edu (Mark Heinicke) writes: >Same setup we've always had, doing Level 0 archives and Logical Logs routinely, >no problem. Except recently we have attempted Level 0 archives--no system changes >we know of--and the archive would only progress partway, stop (for example, >at "24 percent done") and prompt to mount next tape and continue. It does >this despite the fact that it has plenty of tape left to write to. When it >continues, it does another few percent (usually to roughly 27-30% done), >stops, prompts; continues with another few percent (usually to roughly 40% >done), and on the last continuation it completes (that is, does the last >60% or so in one swat). So the archive ends up completed, but has taken >3-4 files instead of the expected 1 (one). First of all, you can't really trust the percentages that tbtape tells you it's done. It doesn't really know. The reason that the last part often seems to go faster and take less tape is probably that you have more chunks toward the end of the chunk list which are not full. Tbtape doesn't back up FREE space, so it can just whip through any empty chunks and not write anything (or very much) to tape. Secondly, tbtape has no idea how much tape is left, it just goes by whatever you specified in your TBCONFIG file as the tapesize. Since you are using a no-rewind device, did you take the tape out and see how much tape it has left, or do you just think 24% shouldn't have taken that much space? Have you checked your config parameter for tapesize to make sure somebody didn't accidentally take a 0 out of the tapesize or something like that? Why do you expect it to take 1 tape? Because you've always just used one, or because you know you have little enough data to fit on one tape? If you have added more data or otherwise increased the space allocated to tables, you could have increased your archive size to above one tape's capacity. >Now, here's the tricky part: Informix technical help brought to my attention >that our device name includes the "no rewind" option--i.e., /dev/nrst8-- >which, according to the OnLine Administrator's Guide, V. 5.0, p. 1-28, is >a no-no: "Tape devices that do not rewind automatically before opening and >on closing are considered incompatible with OnLine operation." > >I don't really want to change the device name, since with our non-Informix >tape routines--e.g., mt, tar--we always use no-rewind followed by mt... status >so we know exactly what/how many files are on the tape. We always used tbtape >followed by mt...status previously with no problem, despite the "incompatibility" >alleged in the documentation. And we can label our tapes with exactly what >files are on them, rather than trusting to the mysterious Informix tape >numbering system. You probably won't have a problem with using a no-rewind device as long as your archive only takes one tape (same for your logical logs, assuming you aren't using continuous backup). The reason you need a no-rewind device is that when you change the tape and hit return to continue, the first thing tbtape does is check to make sure you really replaced the tape. To do this, it reads the tape header, and, if it's a new tape, closes the device and re-opens it to rewind and start again at the beginning, writing a new header. If you are using a no-rewind device, this close does not rewind the device, and your header is now written somewhere a few blocks into the tape, rather than at the beginning. This isn't a problem when archiving, only when restoring. When you restore, and you change the tape and hit return to continue, it reads the header to see if you changed the tape and it's the right tape. Since your header is a few blocks into the tape, tbtape won't find the header it's expecting, and it will say that you put the wrong tape in, and it won't continue. It'll keep prompting you to put the right tape in. Please note that I am not promising you WON'T have problems if you're only using one tape, only that you WILL have problems when you use more. >The last Level-0 archive prior to the recent problematic ones, was back in >October with same tape drive, same OS, same computer, same version of OnLine, >same device name, and it ran fine. Any hints as to what might be going wrong? >Informix tech support said that as long as the archive completed we shouldn't >have to worry about a catastrophe, but I'm not so sure. We are protecting >ourselves with frequent UNLOADS and DBSCHEMAS but they sure tie up a lot of >disk. Well, if the Informix Tech Support person was talking about your old 1-tape archives, he/she was probably right. But if you're thinking about restoring any of the archives that take more than 1 tape, you'd better change your tape device name and do it again. And send the Tech Support person back to class. I hope this helps. June ---- June Tong Informix Software ---- ---- junet@informix.com On-Site Regency Support at SAP ---- ---- Informix: (415)926-6140 SAP: (415)286-6808 ----