Re: Error 179 - any ideas??

Neil Truby wrote: > > I set up a test instance on a server, with a copy of our production > database, for testing. I kept BUFFERS very small - 500 I think. The > server application failed with 179 errors (no more sort space). This > suggests a problem with DBSPACETEMP. It's certainly true that my > setting for this area would have been unusable, since there's a bug in > our release of OnLine (7.13) whereby all temporary dbspaces in a > restored instance will be marked down. > > I bounced the database server with BUFFERS set to 5000, but no other > parameter changes. The temporary dbspaces remain down, but the > application worked fine from then on. Why should this be? R7.xx tends to put sort-work files into temp filesystem space. If the variable PSORT_DBTEMP is not set it will use TEMP (or TMP?) which is usually set to /tmp and is rarely made large enough. Just export PSORT_DBTEMP set to a list of filesystems with approximately the same a mount of free space (the sort will fail when any one of the tempdirs becomes full). The more filesystems in the list the better because during the BTW: Other relevant parameters to help sorts and index builds in 7.xx: PSORT_MAXALLOC=10240 # Amount of memory to assign to each sort # thread, 10240 is the maximum effective value. PSORT_NPROCS=40 # The documentation is unclear on the usage and # effect of this on 7.xx sorts and indeed the # behavior has changed over the versions, but # currently Online 7.13+ will use PSORT_NPROCS # sort threads and sort-memory blocks as long # as PDQPRIORITY > 2 PDQPRIORITY=20 # The more the merrier, but values between 20 # and 40 seem to maximize sort/index build # performance without sucking up TOO much # resources. Adjust according to other load. # Obviously for general production high values # should be avoided except on dedicated DSS # servers, but PDQPRIORITY=40 can make a # TREMENDOUS difference during index builds.