Backups terminated by client

Hi All, Curious to know what causes this error. In the online log files they say that the archives where aborted by client. Is there something that happens on the database end that would cause an archive to abort from the client. I know that if someone kills the ontape process which only user informix or root can do then I know that it will abort the archive obviously. Is there something that I am missing from this? Any thoughts would be greatly appreciated. Thanks, Lloyd AJ Wilson.

The fact is that when you run ontape -s all changes in the database are recorded in the current temporary dbspace; ontape uses the temporary dbspace, too. If that dbspace fills out, ontape aborts. If you do not have a DBSPACETEMP defined area, all this matter is done in rootdbs. As far as I know, the only secure solution is to open a dbspace used only during the time you run ontape -s. You have to set this second dbspace using environment variable DBSPACETENP. In this way ontape uses its own temporary dbspace not involving the normal operation one. I know this is a real waste of space, but this bug is on from 7.2x version of IDS and has *NOT* been corrected. Peter -- Peter Komanns Lloyd AJ Wilson <lwilson@harriscomputer.com> wrote in message news:86sE3.16977$m4.69969323@news.magma.ca... > Hi All, > > Curious to know what causes this error. In the online log files they say > that the archives where aborted by client. Is there something that happens > on the database end that would cause an archive to abort from the client. I > know that if someone kills the ontape process which only user informix or > root can do then I know that it will abort the archive obviously. > > Is there something that I am missing from this? > > Any thoughts would be greatly appreciated. > > Thanks, > > Lloyd AJ Wilson. > >

In article <7rupae$eau1@www.informix.com>, "Peter Komanns" <p.komanns@sindata.it> wrote: >The fact is that when you run ontape -s all changes in the database are >recorded in the current temporary dbspace; ontape uses the temporary >dbspace, too. If that dbspace fills out, ontape aborts. If you do not have a >DBSPACETEMP defined area, all this matter is done in rootdbs. >As far as I know, the only secure solution is to open a dbspace used only >during the time you run ontape -s. You have to set this second dbspace using >environment variable DBSPACETENP. In this way ontape uses its own temporary >dbspace not involving the normal operation one. >I know this is a real waste of space, but this bug is on from 7.2x version >of IDS and has *NOT* been corrected. > > >Peter Peter I don't understand where the bug is. It my understanding that the before images from the physicial log are copied to temporary tables in the DBSPACETEMP. If your DBSPACETEMP is not big enough to handle all of the before images that are being copied to the DBSPACETEMP the backup should fail. That is why you want DBSPACETEMP defined. Otherwise is defaults to ROOTDBS. -Peter

Peter Komanns wrote: > > The fact is that when you run ontape -s all changes in the database are > recorded in the current temporary dbspace; ontape uses the temporary > dbspace, too. If that dbspace fills out, ontape aborts. If you do not have a > DBSPACETEMP defined area, all this matter is done in rootdbs. > As far as I know, the only secure solution is to open a dbspace used only > during the time you run ontape -s. You have to set this second dbspace using > environment variable DBSPACETENP. In this way ontape uses its own temporary > dbspace not involving the normal operation one. > I know this is a real waste of space, but this bug is on from 7.2x version > of IDS and has *NOT* been corrected. No so much a BUG but a design flaw which WAS corrected in 7.30+ by a) fragmenting the temp tables and b) dropping each temp table after it has been dumped to tape and is no longer needed. The former is a natural result of a design change in 7.30 that fragments ALL temp tables without an explicit IN <dbspace> clause across all DBSPACETEMP spaces. The latter, I must admit, was my contribution to the new design (at least I suggested it more than a year before 7.30 features were announced, but it's an obvious fix so I'll allow for a Libnitz/Newton deal at work ;-)). Art S. Kagel > Peter > -- > Peter Komanns > > Lloyd AJ Wilson <lwilson@harriscomputer.com> wrote in message > news:86sE3.16977$m4.69969323@news.magma.ca... > > Hi All, > > > > Curious to know what causes this error. In the online log files they say > > that the archives where aborted by client. Is there something that > happens > > on the database end that would cause an archive to abort from the client. > I > > know that if someone kills the ontape process which only user informix or > > root can do then I know that it will abort the archive obviously. > > > > Is there something that I am missing from this? > > > > Any thoughts would be greatly appreciated. > > > > Thanks, > > > > Lloyd AJ Wilson. > > > >