## Collision rate

<region_name>: collision rate (<percentage>%), <number_of> collisions, <number_of> accesses on region <region_ID>

### Erläuterung

Die Rate der Sperrkollisionen ist hoch.

In unterschiedlichen Threads laufende Tasks versuchen parallel auf einen globalen Speicherbereich zuzugreifen. Bei der dafür notwendigen Synchronisation treten gehäuft Kollisionen auf.

Eine Ausnahme hiervon sind bei liveCache-Instanzen hohe Kollisionsraten in den Bereichen (<region_id>) OMSVDIR und CNSTVIEW. Diese sind bei bestimmten Aktionen, z.B. gleichzeitigem CIF-Queue-Transfer, normal.

### Benutzerreaktion

Handlungsbedarf besteht bei Kollisionsraten von mehr als 10 Prozent. Generell steigt die Kollisionswahrscheinlichkeit mit wachsender Anzahl genutzter Prozessoren (allgemeiner Datenbankparameter MAXCPU). Sie sollten daher prüfen, ob bei Multiprozessorsystemen das Datenbanksystem die Anwendungsanforderungen auch mit weniger CPUs erfüllen kann.

Treten in Multiprozessor-Zentralsystemen (Datenbanksystem und Anwendung laufen auf dem gleichen Rechner) hohe Kollisionsraten auf, sollten Sie überprüfen, ob der Rechner CPU-seitig überlastet ist und die Datenbank-Threads durch andere Anwendungen blockiert werden. In diesem Fall sollten diejenigen Datenbank-Threads, die User-Tasks enthalten, vom Betriebssystem REAL TIME PRIORITY erhalten. Dabei muss jedoch der Wert von MAXCPU um mindestens eins kleiner sein als die Anzahl realer CPU, um Betriebssystemblockaden zu vermeiden.

##### Zusätzliche Maßnahmen

· Wenn die hohen Kollisionsraten in den Bereichen DATAn, SPLITn oder TREEn auftreten, dann erhöhen Sie die Werte des allgemeinen Datenbankparameters CACHE_SIZE sowie der speziellen Datenbankparameter _DATA_CACHE_RGNS und _TREE_RGNS.

· Wenn die hohen Kollisionsraten in den Bereichen TRACE oder BUFWRTR auftreten, dann schalten Sie den Datenbank-Trace immer nur vorübergehend zur Problemlokalisierung ein.