Hi Manu, > Actually, I've got many Collision, Retries into the analyze.shm -s > > I'll probably conclude to increase the GSEMNUM to give more > processing versus give more space by expend TABSZ.
This is a good conclusion. High collision counts can be caused by having a table that is too wide (xxTABSZ) to scan in a single scheduler timeslice. > About GLTABSZ equal RLTABSZ, If I understand correctly, if two > records held in the same groupid, the GLTABSZ use one place and > the RLTASZ use two places to store the locks. Correct. With a large system and random access, it is very likely that most locks are in different groups so having the two values the same is usually a good idea. > My application works with a majority of little records, frequently > updated (accumulators) Accumulator records are often a problem. If you have a control file with several small accumulator records, these are probably all in one group. Although each has a separate record lock, they are all covered by the same group lock. Your innocent looking control file can become the biggest performance bottleneck in the system during updates because everyone is queuing for the WR group lock. The easiest solution to this (assuming that you cannot redesign the application!!) is to oversize the control file so that the records are likely to end up in different groups. > With a RLTAB gt GLTAB, I suppose I'm able to manage more records > locks for one grouplocks ; Is'n it ? True but the above problem with control files may be the cause of your collisions. [ General comment to all list particpants.... This topic is discussed in detail on the UniVerse Internals course. ] Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
