Ontape error

HI all, IDS 7.31.UC5 Sun Solaris 2.6 I'm using ontape to backup my database since day one. All the while the backup was running successfully until last few week ago. The backup was failed and the error message we have was saying that ISAM error: no more extents. When I re-run the backup again on the same tape, it was running successfully. We are having this problem on and off. When we encounter this problem, what we need to do is just re-run the backup again on the same tape. Any idea on this? Is it because of BUG? Below is the error message : Please mount tape 1 on /dev/rmt/0h and press Return to continue ... 10 percent done. 20 percent done. 100 percent done. Archive failed - ISAM error: no more extents Program over. Archive Finished on Thu Oct 19 23:36:56 SGT 2000 Thanks in advance. Best Regards, Jason

You need to add tempdb space to the server. It is best in 7.3x to have at least three temp dbspaces (don't forget the -T flag to onspaces). You are running out of temp space to store modified page preimages until the dbspace has been backed up. You likely have only a few very large and very active dbspaces and the most active are the last in the dbspace list. Art S. Kagel JasonYLPang@pg.SLR.com wrote: > > HI all, > > IDS 7.31.UC5 > Sun Solaris 2.6 > > I'm using ontape to backup my database since day one. All the while the > backup was running successfully until last few week ago. The backup was > failed and the error message we have was saying that ISAM error: no more > extents. When I re-run the backup again on the same tape, it was running > successfully. We are having this problem on and off. When we encounter this > problem, what we need to do is just re-run the backup again on the same > tape. Any idea on this? Is it because of BUG? Below is the error message : > > Please mount tape 1 on /dev/rmt/0h and press Return to continue ... > 10 percent done. > 20 percent done. > 100 percent done. > Archive failed - ISAM error: no more extents > > > Program over. > Archive Finished on Thu Oct 19 23:36:56 SGT 2000 > > Thanks in advance. > > Best Regards, > Jason

On Wed, 25 Oct 2000 20:53:15 -0400, "Art S. Kagel" <kagel@bloomberg.net> wrote: >You need to add tempdb space to the server. It is best in 7.3x to have >at least three temp dbspaces (don't forget the -T flag to onspaces). You >are running out of temp space to store modified page preimages until the >dbspace has been backed up. You likely have only a few very large and >very active dbspaces and the most active are the last in the dbspace list. > >Art S. Kagel > Rookie question. Is it better to have one large temp or several smaller temp spaces? Gary Quiring

Gary Quiring wrote: > > On Wed, 25 Oct 2000 20:53:15 -0400, "Art S. Kagel" > <kagel@bloomberg.net> wrote: > > >You need to add tempdb space to the server. It is best in 7.3x to have > >at least three temp dbspaces (don't forget the -T flag to onspaces). You > >are running out of temp space to store modified page preimages until the > >dbspace has been backed up. You likely have only a few very large and > >very active dbspaces and the most active are the last in the dbspace list. > > > >Art S. Kagel > > > Rookie question. Is it better to have one large temp or several > smaller temp spaces? In general, and certainly for 7.3x, it is better to have three or more tempdbspaces using as many different spindles and controllers as possible. EVEN if each chunk is part of a RAID10 array with 20 drive pairs because if there are multiple tempdbspaces the engine will write to them in parallel more efficiently. In 7.2x, because the temp tables that the archive produces were not fragmented across dbspaces as they are in 7.3x, you could run out of temp space in one tempdbspace while the others still had space left so you although for sorting and index building you want three or more tempspaces even in 7.2x because you do not want your archives to fail after 23 hours you need to make one big one instead and use PSORT_DBTEMP filesystems for index building (which is faster even in 7.3x anyway). Art S. Kagel

Is there a direct correlation between # of temp dbspaces and cpu vp's on 7.31? I've heard that you don't need more temp dbspaces than number of cpu vp's because the engine won't use them. Bob "Art S. Kagel" wrote: --snip-- > > In general, and certainly for 7.3x, it is better to have three or more > tempdbspaces using as many different spindles and controllers as possible. > EVEN if each chunk is part of a RAID10 array with 20 drive pairs because if > there are multiple tempdbspaces the engine will write to them in parallel > more efficiently. > > In 7.2x, because the temp tables that the archive produces were not > fragmented across dbspaces as they are in 7.3x, you could run out of temp > space in one tempdbspace while the others still had space left so you > although for sorting and index building you want three or more tempspaces > even in 7.2x because you do not want your archives to fail after 23 hours > you need to make one big one instead and use PSORT_DBTEMP filesystems for > index building (which is faster even in 7.3x anyway). > > Art S. Kagel

Robert Bothwell wrote: > > Is there a direct correlation between # of temp dbspaces and cpu vp's > on 7.31? No. > I've heard that you don't need more temp dbspaces than number of cpu > vp's because the engine won't use them. I never heard that one. On 7.3x the engine fragments most temp tables (I believe sort-work files are an exception) across ALL appropriate temp dbspaces (appropriate as in if a logged temp table use normal dbspaces listed, if a non-logged temp table use TEMP dbspaces listed in DBSPACETEMP). For sorting purposes it is best to have AT LEAST three TEMP dbspaces listed because of the way the engine writes/rereads/merges sort-work files as it gathers the sort-work files together to output the result set. Art S. Kagel > Bob > > "Art S. Kagel" wrote: > --snip-- > > > > In general, and certainly for 7.3x, it is better to have three or more > > tempdbspaces using as many different spindles and controllers as possible. > > EVEN if each chunk is part of a RAID10 array with 20 drive pairs because if > > there are multiple tempdbspaces the engine will write to them in parallel > > more efficiently. > > > > In 7.2x, because the temp tables that the archive produces were not > > fragmented across dbspaces as they are in 7.3x, you could run out of temp > > space in one tempdbspace while the others still had space left so you > > although for sorting and index building you want three or more tempspaces > > even in 7.2x because you do not want your archives to fail after 23 hours > > you need to make one big one instead and use PSORT_DBTEMP filesystems for > > index building (which is faster even in 7.3x anyway). > > > > Art S. Kagel