Stephan Stresing wrote:
>
> Hi,
> we have IDS 7.30.UC8 running here on a Sun Solaris 2.6 box. We've
> encountered a problem with DBSPACETEMP: we've set this parameter to
> dbs1:dbs2 (and we tried also dbs1,dbs2) in the onconfig file. After
> starting a big print job IDS claims temporary space to collect the data.
> But after dbs1 runs full it doesn't switch over to dbs2 but fails with
> an error message (I think it was -264); the essential result was that no
> more space was left on dbs1. The only solution (or better: workaround)
> we found out was to remove dbs1 from DBSPACETEMP definition and to use
> only dbs2 where is a lot more space available for temporary actions.
> Is there sth with this parameter or are we missing sth?
> Any help/comment is appreciated!
There is nth wrong with the parameter, you are missing sth. Vowels
mostly. :-)
The temp dbspaces are not used one after the other, but all together.
You temp tables are fragmented across all temp dbspaces. So the smallest
one will dictate how large your temp table can grow.
A little trick you can use, if dbs2 is a lot larger than dbs1, is to add
it to your DBSPACETEMP variable several times. However, this sort of
defeats the purpose, which is to fragment your tables across multiple
spindles for performance.
You should also look at sizing all your temp dbspaces the same.
_ hp th hps.
Cheers,
--
Mark.
+----------------------------------------------------------+-----------+
| Mark D. Stock http://www.informix.com |//////// /|
| mailto:mdstock@mydas.freeserve.co.uk |///// / //|
| http://www.iiug.org +-----------------------------------+//// / ///|
| |What year 2000 bug? year 2000 bug? |/// / ////|
| |year 2000 bug? year 2000 bug? year |// / /////|
| |2000 bug? year 2000 bug? year 1900 |/ ////////|
+----------------------+-----------------------------------+-----------+