Re: 8.1.7 cache buffer chains contention

comments below

>>Another area of suspicion is in the read-consistency
>>cycle - the average transactions applies 895 rollback
>>changes - that's quite a lot, whilst making 274 forward
>>block changes to 151 blocks. Your transactions seem
>>to be colliding rolling back each others changes to
>>get a consistent view of the data.
>>
>
>I mentioned that we have about 500 sessions, there are a handful
>of appservers(7-10) that are used to provide the connection.
>Each of those appservers connects to a specific user. I am not sure
>if this is a self imposed limitation (one database user per app server
>or not).
>
>The tril_joins_wrk you mentioned below is basically a temporary
>work table each of the database users above owns their own
>copy of that table that is later joined to another table to return
>the rows needed, then those rows are deleted from the tril_joins_wrk.
>
>
>So there are say 50 users sharing that table at one time all inserting
>/deleting from that table. (this is one point where we thought temp
>tables/tablespaces could really help).
>

I just went back through some other stats packs from this week and prior to the upgrade, and I think the one I posted was a _lot_ worse than the average situation, possibly brought on by the latch free contention? More sessions staying active longer due to waiting on that latch?

The typical number for consistant gets that I saw in the other statspacks was in the area of ~30-60

Scott Received on Fri Aug 24 2001 - 14:21:00 CDT