Re: Informix Backup ...

Thalavoipuram, Kalyan wrote: > > We are doing a level 0 archive using ontape. It was working quite fine > for a long time. > Recently we are getting an error after 90 % of it is done ... The error > that we get is > > Archive failed - function write to tape failed code -1 errno 2. > > Does anybody know as to what to look for in this case. There are actually two possibilities. Others have mentioned that your TAPESIZE parameter may be too small. If you are using a compressed tape device your data may no longer compress as well as it used to. The compression algorithm the tape drives use is pretty simple and while it compresses text to about 50% it does not do nearly as well for binary data. The second possibility is that one of your DBSPACETEMP dbspaces is filling up during the archive. You can prove this by doing a backup with no users active. If that succeeds but online archives fail then this is the problem. Certainly if you reduce TAPESIZE and the problem remains suspect this one. The problem happens in 7.[12]x because of how the engine deals with pages that are being changed during the archive. The ontape thread creates a temp table for each dbspace, round robining the creation across the dbspaces listed in DBSPACETEMP with each table entirely in one dbspace (no fragmentation). When a page is modified during the archive its preimage is insertedinto the corresponding dbspace's temp table. When each dbspace is completely backed up its temp table records are written out to the tape also but the temp table, though it is no longer used, is not dropped until the entire archive is complete. It two or more of your most active dbspaces have their temp tables in the same tempdbspace that dbspace may fill up and the archive fails. There are three possible solutions: 1) increase the size of each tempdbspace 2) add additional tempdbspaces 3) reduce the number of tempdbspaces and make each one larger Option 3 is the best for archives but will slow down sorting which can parallelize better with more tempdbspaces. Option 2 sounds good but one dbspace may still fill up. Option 1 is the best compromise but you need more disks than 2) so this can get expensive for dbspace that you only need for archiving. The problem, BTW, affects all archive utilities since they all use the ontape and arcbackup threads. Version 7.3 solved the problem by fragmenting all of the temp tables across all tempdbspaces so the problem on one filling while the others have space left goes away. I had once suggested, when 7.3 was being planned, that they drop the temp tables as they were no longer needed rather than waiting until the end of the archive but I do not know if they took the recommendation. Art S. Kagel