Lecture des rapports de STATPACK 2 Verrous mémoire et Cie Cours PERFSTAT Lecture des rapports de STATPACK 2 Verrous mémoire et Cie Page 1

Sommaire Analyse des verrous mémoire Analyse lectures logiques et physiques Analyse du cache dictionnaire Activité du cache librairie Page 2

Analyse des Verrous (Latch) Qu ’est-ce qu ’un verrou mémoire ? : Elles permettent de protéger un cache mémoire PARTAGE en verrouillant cette zone dès qu ’un process y accède. Elle est libérée lorsqu ’elle n’est plus utilisée. Une file d ’attente est gérée pour chaque buffer. Les processes en attente sont appellées les ‘ WILLING-TO-WAIT ’, ils réitereront leur demande plus tard. A contrario de les processes appelées ‘ IMMEDIATE ’ ne réitereront pas leur demande s’ils n ’ont pas de verrou immédiatement. Ce temps d ’attente est couteux en temps CPU car si un verrou n ’est pas attribué alors le CPU en refait la demande. Certaines demandes peuvent ne pas être renouvellées, dans ce cas l ’exécution de celle se fera en zone NON partagée. Page 3

Pour plus de détails dans les mesures, il faut aller voir dans la table V$LATCH L ’audit des verrous dans le rapports STATPACK se basent sur les WILLING-TO-WAIT et concerne: Les attentes d ’un process pour obtenir un ‘ VERROU ’ Elle sont mesurées en nombre de demandes de verrous satisfaites et en non satisfaites (abandonnées). Si un grand nombre de process obtiennenent rapidement un ‘ verrou ’ cela signifie 2 choses : Ou que les verrous sont rapidements libérés. Ou qu’il y a peu d ’accès concurrents à un buffer. Page 4

Intérêt des verrous Inconvénients Garantit l ’intégrité des données dans un contexte de partage de données. Garantit un accès aux données demandées à plus ou moins longue échéance Inconvénients Gestion lourde et consommatrice en temps CPU, gestion de files d ’attente supplémentaires. Augmentation des temps d ’attente Difficiles à ‘ tuner ’ Page 5

L ’audit se porte sur les valeurs suivantes Get Requests : Nombre totale de demandes de verrous satisfaites. Pct get misses : Taux de demande non satisfaites de verrous et qui n ’ont pas été réitérées. Avg Slps/Misses : Taux de demandes en attentes qui n ’ont pas été réitérés. Wait time (s) : Temps moyen d ’attente d ’un process avant obtention d ’un verrou. No Wait requests : Nombre de demande satisfaites immédiatement. Pct NoWait misses : Taux de demandes non satisfaites immédiatement et NON réitérées. Page 6

Les plus 3 buffers les plus importants de la SHARED POOL latch Cache buffer chain Cache buffer lru chain Cache buffer (Partie données partagées) LRU Chain Hash chain Library cache Row cache buffer Library cache Dictionnary cache Page 7 Jules Mak-Po-Pan

Les plus importants verrous auditées : Cache buffer chains : Ce verrou protège l ’accès au hash chain du buffer cache. Si le temps t ’attente est élevé c ’est que les recherches dans le cache sont longues. Pct Avg Wait Pct Get Get Slps Time NoWait NoWait Latch Requests Miss /Miss (s) Requests Miss ------------------------ -------------- ------ ------ ------ ------------ ------ cache buffers chains 12,066,792 0.2 0.0 2 27,445 0.0 Il a y eu 12,066,792 demandes satisfaites pour un taux de demandes non-satisfaites est de 0,2%, le temps d ’attente moyen avant d ’être satisfait est de 2s. Il y a donc eu beaucoup d ’attentes. En revanche il n ’y a eu que 27445 demandes satisfaites immédiatement pour 0% d ’échecs. On en conclu qu’ il y eu beaucoup d ’accès aux buffer cache :  Une entrée du hash-code pointe sur beaucoup de blocs de données : délai de recherche longues.  Une entrée du hash-code pointe sur trop peu de blocs de données : peu de donnés partagées ou groupement de données trop forte. Consulter la vue x$bh pour analyser les hash chains Page 8

- Cache buffer LRU chain : Ce verrou est mis lorsqu ’un process cherche à accèder à la liste des objets les plus récemments utilisées (Last Recently Used) dans le cache buffer, ce paramètre permet aux processes d ’accèder directement au buffer SANS recherches: Pct Avg Wait Pct Get Get Slps Time NoWait NoWait Latch Requests Miss /Miss (s) Requests Miss ------------------------ -------------- ------ ------ ------ ------------ ------ cache buffers lru chain 574 0.0 0 27,299 0.2 Il n ’y a eu que 574 demandes satisfaites par le LRU, le taux de demandes non-satisfaites est de 0,0%, le temps d’attente moyen avant d ’être satisfait est de 0s. Le LRU est donc très efficace et peu sollicitée => trop petite. Ceci est symptomatique que : Les données dans la SHARED POOL ont été réutilisées peut de fois dans un cycle LRU. Augmenter le nombre de verrous : Paramètre db_block_lru_latches trop petite Réduire le nombre d ’accès au buffer cache : une shared pool mal taillée. Page 9

- Rows Cache objects : Verrou du dictionnaire de données - Rows Cache objects : Verrou du dictionnaire de données. Ce verrou est très utilisée pendant le parsing. Pct Avg Wait Pct Get Get Slps Time NoWait NoWait Latch Requests Miss /Miss (s) Requests Miss ------------------------ -------------- ------ ------ ------ ------------ ------ row cache objects 4,049,353 3.5 0.0 1 1,044 0.0 Il y eu 4,049,353 demandes satisfaites pour un taux de demandes non-satisfaites est de 3,5%, le temps d ’attente moyen avant d ’être satisfait est de 1s. Il y a donc eu beaucoup d ’attentes et 3,5% d ’entre-eux n ’ont pas réitérés leurs demande. Par contre il y a eu PEU de demandes satisfaites directement (1044). Ceci est symptomatique d ’ une mauvaise réutilisation du code, en effet en 25mn il y a eu près de 5000 demandes de parsing Page 10

- ROWS Cache enqueue latch : C’est un verrou qui est mis sur la file d ’attente du cache de données partagées. Elle traduit les locks qu ’il y a eu sur le cache dictionnaire. Pct Avg Wait Pct Get Get Slps Time NoWait NoWait Latch Requests Miss /Miss (s) Requests Miss ------------------------ -------------- ------ ------ ------ ------------ ------ row cache enqueue latch 4,049,016 0.7 0.0 0 0 Il y a eu 4,049,353 demandes satisfaites pour un taux de demandes non-satisfaites est de 0,7%. Il y a donc eu beaucoup de monde dans la file d ’attente du buffer de données partagées. De fait il y a eu beaucoup de résultats partagées avec des process antérieurs et peu (0,7) de renouvellements. Page 11

Activité des verrous Pct Avg Wait Pct Get Get Slps Time NoWait NoWait Latch Requests Miss /Miss (s) Requests Miss ------------------------ -------------- ------ ------ ------ ------------ ------ row cache enqueue latch 4,049,016 0.7 0.0 0 0 row cache objects 4,049,353 3.5 0.0 1 1,044 0.0 shared pool 96,091 0.8 0.1 0 0 Le % de demandes non réitérées (Pct Misses) les plus importantes concernent le ROW Cache Objects, la Row cache enqueue latch et la share pool. Cela signifie que : - 3,5% des demandes d ’accès au ROW Cache Objects ont fini par être faites ‘ailleurs’ et que l ’attente pour obtenir un verrous sur ce cache a été en moyenne de 1s - En 25mn il y a eu peu de transfer de données en shared pool. Ou la shared pool se suffit à elle-même ou les même transactions ont été passées plusieurs fois, ou elle est trop petite. Page 12

Conclusion de l ’analyse des verrous : Beaucoup demandes de verrous Files d ’attente trop longue Recherches longues dans la Shared Pool SHARED POOL AREA trop grande donc temps de recherche longue Mécanisme LRU peu sollicitée : faible taux de réutilisation des données récentes. Beaucoup de changements de données dans le cache Peu de demandes de transfert dans la Shared Pool Peu de données dans le DATA BUFFER CACHE sont éligibles pour le partage. SHARED POOL AREA trop petite car peu de transfers inter-caches. Page 13

SHARED POOL AREA TROP GRANDE : Confirmée par la SHARED POOL ADIVISORY Estd Shared Pool SP Estd Estd Estd Lib LC Time Size for Size Lib Cache Lib Cache Cache Time Saved Estd Lib Cache Estim (M) Factr Size (M) Mem Obj Saved (s) Factr Mem Obj Hits ----------- ----- ---------- ------------ ------------ ------- --------------- 48 .6 89 4,027 12,593 1.0 1,964,280 64 .8 104 6,601 12,593 1.0 1,964,280 80 1.0 110 7,219 12,593 1.0 1,964,280 96 1.2 110 7,219 12,593 1.0 1,964,280 112 1.4 110 7,219 12,593 1.0 1,964,280 128 1.6 110 7,219 12,593 1.0 1,964,280 144 1.8 110 7,219 12,593 1.0 1,964,280 160 2.0 110 7,219 12,593 1.0 1,964,280 Page 14

Sommaire Analyse des verrous mémoire Analyse lectures logiques et physiques Analyse du cache dictionnaire Activité du cache librairie Page 15

Top 5 : Lectures en cache par segments Subobject Obj. Logical Owner Tablespace Object Name Name Type Reads %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- ADELIE SILODECL_I IX_DONNEE_TVA_03 PT_2003T4 INDEX 383,120 5.44 ADELIE SILODECL_I IX_DONNEE_TVA_03 PT_2004T1 INDEX 329,520 4.68 ADELIE SILODECL_I IX_DONNEE_TVA_03 PT_2002T2 INDEX 325,760 4.63 ADELIE SILODECL_I IX_DONNEE_TVA_03 PT_2002T4 INDEX 324,784 4.62 ADELIE SILODECL_I IX_DONNEE_TVA_03 PT_2003T2 INDEX 322,448 4.58 Environ 25% des lectures en cache se sont fait sur un seul index : DONNEE_TVA. Intérêt du partitionnement 25% sur le même tablespace Page 16

Lectures physiques par segments Owner Tablespace Object Name Name Type Reads %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- ADELIE SILODECL_I IX_DONNEE_TVA_03 PT_2003T4 INDEX 1,514 6.73 ADELIE SILODECL_D DEPOT_TVA PT_2003T4 TABLE 1,451 6.45 ADELIE SILODECL_D DONNEE_TVA PT_2003T4 TABLE 1,411 6.27 ADELIE SILODECL_D DONNEE_TVA PT_2004T1 TABLE 1,206 5.36 ADELIE SILODECL_I IX_IMPRIME_TVA_03 PT_2003T4 INDEX 1,197 5.32 ------------------------------------------------------------- 11,5% des lectures physiques sur DONNEE_TVA 6,7% de lecture physiques sur l ’index IX_DONNE_TVA (P4) !!! Alors qu ’une partie est déjà dans le cache. 12,8% des lectures physiques sur la partition des données PT_2003T4 12,5% des lectures physiques sur partition d ’index PT_2003T4 Page 17

Top 5 : Attentes dans le cache par segments Owner Tablespace Object Name Name Type Reads %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- ADELIE SILODECL_I IX_DONNEE_TVA_03 PT_2003T4 INDEX 1,514 6.73 ADELIE SILODECL_D DEPOT_TVA PT_2003T4 TABLE 1,451 6.45 ADELIE SILODECL_D DONNEE_TVA PT_2003T4 TABLE 1,411 6.27 ADELIE SILODECL_D DONNEE_TVA PT_2004T1 TABLE 1,206 5.36 ADELIE SILODECL_I IX_IMPRIME_TVA_03 PT_2003T4 INDEX 1,197 5.32 ------------------------------------------------------------- 11,5% concernent DONNEE_TVA = Lectures physiques Dont 6,7% sur un de ses indexes Page 18

Conclusions Attentes dues aux lectures physiques 12,8% des lectures physiques concernent la même partition d ’un tablespace Indexes pas totalement chargées en cache entraine des lectures physiques. Etude du poids des I/Os nécessaire pour rééquilibrage des partitions de DONNEE_TVA Utiliser le paramètre BUFFER_POOL_KEEP pour garder un max de temps une table en mémoire (Attention mécanisme LRU) Précéder les requêtes par un ALTER TABLE DONNEE_TVA CACHE. Page 19

Sommaire Analyse des verrous mémoire Analyse lectures logiques et physiques Analyse du cache dictionnaire Activité du cache librairie Page 20

Analyse du cache dictionnaire Contient les objets système Contient les objets des schémas Ce sont les objets les plus sollicités Page 21

Statistiques du le cache dictionnaire Get Pct Scan Pct Mod Final Cache Requests Miss Reqs Miss Reqs Usage ------------------------- ------------ ------ ------- ----- -------- ---------- dc_free_extents 4 0.0 0 0 1 dc_histogram_defs 52,550 0.0 0 0 294 dc_object_ids 58,825 0.0 0 0 270 dc_objects 5,412 0.0 0 0 613 dc_profiles 40 0.0 0 0 1 dc_rollback_segments 56 0.0 0 0 12 dc_segments 5,206 0.0 0 0 282 dc_sequences 2 0.0 0 2 3 dc_tablespaces 939,944 0.0 0 0 49 dc_user_grants 244 0.0 0 0 17 dc_usernames 80 0.0 0 0 8 dc_users 962,453 0.0 0 0 23 ------------------------------------------------------------- Forte sollicitation en ‘select ’ (DC_ROLLBACK_SEGMENTS). Beaucoup d ’utilisateurs connectés (DC_USERS) Base peu sollicitée en mise à jour (dc_rollback_segments) Page 22

Conclusion Base utilisée en select Beaucoup de connexions à gérer : Gestion des accès Gestion des droits Gestion des définitions d ’objets Page 23

Sommaire Analyse des verrous mémoire Analyse lectures logiques et physiques Analyse du cache dictionnaire Activité du cache librairie Page 24

Activité du cache librairie Library Cache Activity for DB: SILODECL Instance: SILODECL Snaps: 5 -9 ->"Pct Misses" should be very low Get Pct Pin Pct Invali- Namespace Requests Miss Requests Miss Reloads dations --------------- ------------ ------ -------------- ------ ---------- -------- BODY 28 0.0 28 0.0 0 0 INDEX 19,204 0.0 6,370 0.0 0 0 SQL AREA 1,558 39.9 5,929 21.3 16 0 TABLE/PROCEDURE 12,287 0.0 16,131 0.0 3 0 TRIGGER 68 0.0 68 0.0 0 0 ------------------------------------------------------------- Beaucoup de pertes dans la SQL aréa : 1558 demandes d ’accès : 39,9% de demandes non résolues 5929 demandes de chargement de code dans la SQL aréa mais 21% non faits. Page 25

Conclusion 39,9% des recherches de codes SQL n ’ont pas aboutit 21% de chargement de code qui n ’ont pu être faits Page 26