Guide DB2

UTILISATION DES
BUFFERS POOLS

1
 INTRODUCTION
l’évolution de nos sites de productions tant au niveau :
- des volumes de nos bases de données
- des besoins de nos utilisateurs
- de la puissance des CPU
- de l’évolution du 31-bit vers le 64-bit
nous oblige de plus en plus à revoir l’utilisation des Buffers pools de
DB2 afin de réduire au maximum les accès I/O vers les bases

2
 AGENDA
- Rappel des annonces des diverses versions
- Les Buffers Pools dans DB2
- Combien de Buffers Pools
- Hiperpools
- Dataspaces
- DB2 Version 8

3
 DB2 V5 Enhancements

un petit Rappel sur les annonces de la V5 au niveau des buffers pools:

- Multiple LRU chains
- Deferred Write enhancements
- DISPLAY BPOOL filtering capability
- Allow parallel query to use Hiperpools
- Parallel opens/closes
- > 10 000 DDs
- Deferred close enhancements
- GBP Rebuild and automatic recovery
- GBP Duplexing

4
 DB2 V6 Enhancements
En V6, les diverses annonces au niveau des buffers pools sont:
- Buffer pools in dataspaces
- LRU versus FIFO
- 8K et 16K buffers pools
- New ZPARM to specific default BP
- New GBPCACHE options
- Miscellaneous enhancements

5
 DB2 V7 Enhancements
La version 7 de DB2 apporte le support de z/OS , ce qui permet
- d’augmenter la taille des BP
- D’utiliser les capacités des nouveaux systèmes MVS.
- Un dataspace BP peut être spanné en multiples dataspaces
- DBM1 utilise des buffers lookaside

6
Environnement Société Générale

2084-311 2064-214
38 GB 27 GB

MVS Z/OS 1.4.0 XCF MVS Z/OS 1.4.0

DB2 version 710 data sharing DB2 version 710

7
 LES BUFFERS POOLS
- Les principes
- Les virtual pools
- Les hiper pools
- Les data spaces
- Les valeurs maximales
- Les commandes

8
 LES PRINCIPES
- DB2 n’accède pas directement aux données sur disque mais
généralement par une zone mémoire réelle gérée par l’adresse space
DBM1 appelée “ virtual buffer pool ”.

- Une fois utilisées, ces données peuvent rester en mémoire pour une
réutilisation ultérieure

- Pour augmenter la capacité de stockage de ces données, DB2 peut

utiliser
- Soit des Hiper pools
- Soit des data spaces

9
 LES VIRTUALS POOLS
- 1° les virtuals pools

DBM1 adress space

Disques

Buffers pages

10
 LES HIPERS POOLS
- 2° avec hipers pools

DBM1 adress space Expanded storage

Disques

Buffers pages

Buffers pages

11
 LES DATA SPACES
- 3° avec data spaces

DBM1 adress space

Disques Buffers pages DATA SPACE

Loockaside
128 b/buf
Buffers pages

12
VALEURS MAXIMALES

4k page 8k page 16k page 32k page

Primary 1,6 GB 1,6 GB 1,6 GB 1,6 GB

virtual
buffer pool
hiperpool 8 GB 8 GB 8 GB 8 GB

Dataspace 32 GB 64 GB 128 GB 256 GB

Buffer pool

13
 LES COMMANDES
- ALTER BUFFERPOOL (BPn)
permet de créer un buffer pool non utilisé
permet de changer les diverses valeurs de ce buffer
VPSIZE, HPSIZE, CASTOUT, VPTYPE , DWQT, VDWQT…

- DISPLAY BUFFERPOOL (BPn)

permet d’afficher les infos sur ce buffer
avec les divers paramètres tel:
- DETAIL (INTERVAL) ou DETAIL(*)
- LIST……

14
 Combien de Buffers Pools
- Au début, la question ne se posait pas , il n’y avait que quelques BP
de 4k et le BP32K

- Puis le choix est arrivé, avec les 50 BP de 4k, suivi des 8k, des 16k
et des 10 BP32k

- Juste un petit rappel, pour éviter les problèmes de mémoire , la

somme des virtuals buffers pools ne doit pas dépasser les 700 à
800 M en fonction du nombre de users et de data sets open .

15
 Combien de Buffers Pools
Bénéfice de 3 BP ou moins :
- Le tunning se fait sans trop d’effort
- La faible précision produit moins de flexibilité
- Toutes les applications sont logées à la même enseigne
Bénéfice de 4 BP ou plus:
On peut grouper les tables en fonction de leur relative priorité ou leur
mode d’accès
- Sépare les datas et indexes
- Favorise les datas critiques dans un BP séparé
- Tire avantage des buffers pools thresholds
- Isole des données pour un monitoring plus poussé

16
 Combien de Buffers Pools
On peut répartir les tables en fonction de leurs types d’accès:
- Les tables en READ ONLY
- Les tables avec un fort pourcentage de mise à jour
- Les tables accédées le plus souvent en SEQUENTIEL
- Les tables accédées le plus souvent at RANDOM

On peut séparer aussi en fonction de la priorité des applications.

17
 Recommandations minimales
- 1.Isoler le catalogue et la directory ( qui restent en BP0)
2.Isoler la data base de tri avec un DWQT et un VDWQT à 80%
3. Séparer data et index dans des BP dédiés
4. Essayer de faire un tableau de bord pour suivre les modifications
5. Ne séparer que les projets sensibles ou pour faire un tunning
poussé.

18
 HIPERPOOLS

Dans cette partie de la présentation, nous verrons successivement :

- les principes de fonctionnement des hiperpools
- Un point sur les performances
- l’utilisation des hiperpools

19
 Principes de fonctionnement
Pour augmenter l’efficacité des Buffers Pools, une solution consiste à
utiliser des Hiperpools. C’est une extension des Virtual Buffers Pools
résidant en mémoire auxiliaire. Cela permet d’adresser 8 GB en plus.
Par contre, le fait d’être en mémoire auxiliaire donc non directement
adressable , oblige à déplacer les pages vers la mémoire centrale.
Ceci provoque bien sur, un peu d’overhead CPU et ne peut faire d’I/O.

Les accès en hiperpool sont en read- only, et donc une page updatée ne
pourra être stockée dans un hiperpool qu’après avoir été écrite sur
disque

20
 Principes de fonctionnement
Un hiperpool est toujours couplé avec un virtual pool
Nous avons donc 2 niveaux de cache:
- Level 1: les virtuals Pools
° l’espace est alloué dans l’adresse space DBM1
° doit correspondre à de la mémoire réelle
° utilisé pour garder les données accédées les plus récentes
° peut faire des opérations d’I/O
° peut demandé ou modifié des données
- Level 2: Hiperpool
° l’espace est alloué dans un ou plusieurs ESO hiperspaces
° doit correspondre à de la mémoire auxiliaire
° ne peut stocker des données modifiées ( dirty)

21
 Principes de fonctionnement
Les cas ou les hiperpools ne sont pas utilisés :
- les données séquentielles ne sont pas déplacées de VP vers HP si
HPSEQT=0
- Les dirty pages non écrites sur disque
- Certains utilitaires tel que LOAD, REORG, RECOVER

22
 Caractéristiques
- Ils sont optionnels
- Il y a toujours une relation 1:1 entre VP et HP
- VP est préréquisite avant de créer du HP
- Un HP peut être dans un ou des multiples ESO hiperspaces
- On ne peut partagé un ESO entre plusieurs HPs
- Une page peut résider en VP ou en HP mais pas dans les deux
- Avant un update, une page de HP est toujours ramené en VP
- Le séquentiel est à privilégier pour le HP par rapport au Random

23
 Usages
Considérons le bénéfice versus coût des hiperpools :
- Bénéfice:
le nombre d’I/O diminue quand une page demandée n’est pas en VP
mais en HP.
- Coût :
une page accédée doit être déplacée de HP vers VP
DB2 cherche dans HP que lorsque la page n’a pas été trouvée dans VP

Le bénéfice augmente bien sur avec la taille du HP.

Par contre son coût reste inchangé en fonction de la taille du HP.

24
 Tunning considérations
sur une commande –dis bufferpool(bp10) detail(*) on obtient:
DSNB401I -DB2W BUFFERPOOL NAME BP10, BUFFERPOOL ID 10, USE COUNT
232
DSNB402I -DB2W VIRTUAL BUFFERPOOL SIZE = 12500 BUFFERS
ALLOCATED = 12500 TO BE DELETED = 0
IN-USE/UPDATED = 83
DSNB406I -DB2W VIRTUAL BUFFERPOOL TYPE -
CURRENT = PRIMARY
PENDING = PRIMARY
PAGE STEALING METHOD = LRU
DSNB403I -DB2W HIPERPOOL SIZE = 40000 BUFFERS, CASTOUT = YES
ALLOCATED = 40000 TO BE DELETED = 0
BACKED BY ES = 40000
DSNB404I -DB2W THRESHOLDS -
VP SEQUENTIAL = 80 HP SEQUENTIAL = 80
DEFERRED WRITE = 50 VERTICAL DEFERRED WRT = 30,0
PARALLEL SEQUENTIAL = 50 ASSISTING PARALLEL SEQT= 0
DSNB405I -DB2W HIPERSPACE NAME(S) - à101DB2W

25
 Tunning considérations
DSNB410I -DB2W CUMULATIVE STATISTICS SINCE 08:07:37 JAN 12, 2004
DSNB411I -DB2W RANDOM GETPAGE =211672252 SYNC READ I/O (R) =
3407471
SEQ. GETPAGE = 30563883 SYNC READ I/O (S) = 105295
DMTH HIT = 0
DSNB412I -DB2W SEQUENTIAL PREFETCH -
REQUESTS = 880687 PREFETCH I/O = 864833
PAGES READ = 27702582
DSNB413I -DB2W LIST PREFETCH -
REQUESTS = 1350581 PREFETCH I/O = 6186572
PAGES READ = 32255574
DSNB414I -DB2W DYNAMIC PREFETCH -
REQUESTS = 1275784 PREFETCH I/O = 1101570
PAGES READ = 34213246
DSNB415I -DB2W PREFETCH DISABLED -
NO BUFFER = 0 NO READ ENGINE = 0
DSNB420I -DB2W SYS PAGE UPDATES = 33016649 SYS PAGES WRITTEN =
7822249
ASYNC WRITE I/O = 386286 SYNC WRITE I/O = 840
DSNB421I -DB2W DWT HIT = 15 VERTICAL DWT HIT =
117452
NO WRITE ENGINE = 0

26
 Tunning considérations
DSNB430I -DB2W HIPERPOOL ACTIVITY (NOT USING ASYNCHRONOUS

DATA MOVER FACILITY) -

SYNC HP READS = 888260 SYNC HP WRITES = 2
ASYNC HP READS = 4401768 ASYNC HP WRITES =110412542
READ FAILURES = 0 WRITE FAILURES = 0
DSNB431I -DB2W HIPERPOOL ACTIVITY (USING ASYNCHRONOUS

DATA MOVER FACILITY) -

HP READS = 0 HP WRITES = 0
READ FAILURES = 0 WRITE FAILURES = 0
DSNB440I -DB2W PARALLEL ACTIVITY -
PARALLEL REQUEST = 0 DEGRADED PARALLEL= 0
DSNB441I -DB2W LPL ACTIVITY -
PAGES ADDED = 0
DSN9022I -DB2W DSNB1CMD '-DIS BUFFERPOOL' NORMAL
COMPLETION
27
 DATASPACES

Dans cette partie de la présentation, nous verrons successivement :

- les principes de fonctionnement des dataspaces
- Un point sur les performances
- l’utilisation des dataspaces

28
 Principes de fonctionnement
DB2 offre la possibilité d’allouer les Buffers Pools en Dataspace donc
hors adresse space DBM1.
Pour cela, VPTYPE(DATASPACE) spécifié dans l’ALTER BPOOL
permettra cette utilisation, VPTYPE(PRIMARY) permettant de
revenir en VBP.
Les opérations d’I/O peuvent être effectuées directement entre les disques
et les dataspaces .
128 bytes par BP sont occupés dans DBM1 pour le contrôle de ces
dataspaces.
Dans DBM1, une autre zone de mémoire est utilisée : le Lookaside Pool

29
 Principes de fonctionnement
le Lookaside Pool:
Cette zone est partagée par l’ensemble des Dataspaces Pools ayant la
même taille de page.
- Non managée par LRU
- Sa taille est étendue ou contractée en fonction de son utilisation (de
256 en minimum jusqu’à 4096 par défaut)
- Prévient le Data Manager quand il atteint cette limite, et dans ce cas un
Relpage est fait
- Utilise MVCL pour copier les datas vers le lookaside Pool
pour copier les datas modifiées vers le dataspace

30
 Bénéfices pour DB2
Ceci réduit la mémoire allouée dans DBM1 pour les Buffers Pools
Donc, possibilité d’agrandir les autres pools

Petit Rappel: Dynamic cache de l’EDM pool peut également être défini
dans un dataspace (différent des dataspaces buffer pools).

C’est aussi une ouverture vers les plus grandes mémoires

Les I/O pouvant être faites directement , ceci permettra plus de
parallélisme, que ce soit pour des utilitaires ou des requêtes.
La taille des BP ayant augmentée, les données modifiées peuvent rester
plus longtemps en mémoire, et on réduit le temps d’I/O pour les
données souvent modifiées.

31
 Recommendations
Les dataspaces buffers pools doivent correspondre à de la mémoire réelle
de façon à éviter de paginer en mémoire auxiliaire

Quelques APAR sont les biens venus en version 7:

- PQ45985 minimise le coût CPU
- PQ71766 pour supporter les multiples dataspaces pour le même BP

32
 Tunning considérations
sur une commande –dis bufferpool(bp10) detail(*) on obtient:
DSNB401I -DB2V BUFFERPOOL NAME BP10, BUFFERPOOL ID 10, USE COUNT 10
DSNB402I -DB2V VIRTUAL BUFFERPOOL SIZE = 25000 BUFFERS
ALLOCATED = 25000 TO BE DELETED = 0
IN-USE/UPDATED = 103
DSNB406I -DB2V VIRTUAL BUFFERPOOL TYPE -
CURRENT = DATASPACE
PENDING = DATASPACE
PAGE STEALING METHOD = LRU
DSNB403I -DB2V HIPERPOOL SIZE = 0 BUFFERS, CASTOUT = YES
ALLOCATED = 0 TO BE DELETED = 0
BACKED BY ES = 0
DSNB404I -DB2V THRESHOLDS -
VP SEQUENTIAL = 80 HP SEQUENTIAL = 80
DEFERRED WRITE = 50 VERTICAL DEFERRED WRT = 10,0
PARALLEL SEQUENTIAL = 50 ASSISTING PARALLEL SEQT= 0
DSNB405I -DB2V DATASPACE NAME(S) - DB2VD000

33
 Tunning considérations
DSNB410I -DB2V CUMULATIVE STATISTICS SINCE 05:04:25 JAN 12, 2004
DSNB411I -DB2V RANDOM GETPAGE =430799763 SYNC READ I/O (R) =
48463624
SEQ. GETPAGE =272409648 SYNC READ I/O (S) = 549462
DMTH HIT = 0
DSNB412I -DB2V SEQUENTIAL PREFETCH -
REQUESTS = 4882507 PREFETCH I/O = 1062473
PAGES READ = 32898824
DSNB413I -DB2V LIST PREFETCH -
REQUESTS = 10589136 PREFETCH I/O = 3653580
PAGES READ = 6064750
DSNB414I -DB2V DYNAMIC PREFETCH -
REQUESTS = 9105607 PREFETCH I/O = 1840680
PAGES READ = 38291500
DSNB415I -DB2V PREFETCH DISABLED -
NO BUFFER = 0 NO READ ENGINE = 0
DSNB420I -DB2V SYS PAGE UPDATES = 32236112 SYS PAGES WRITTEN =
6138940
ASYNC WRITE I/O = 772809 SYNC WRITE I/O = 8943

34
 Tunning considérations
DSNB421I -DB2V DWT HIT = 10503 VERTICAL DWT HIT =
3557585
NO WRITE ENGINE = 18
DSNB430I -DB2V HIPERPOOL ACTIVITY (NOT USING ASYNCHRONOUS
DATA MOVER FACILITY) -
SYNC HP READS = 0 SYNC HP WRITES = 0
ASYNC HP READS = 0 ASYNC HP WRITES = 0
READ FAILURES = 0 WRITE FAILURES = 0
DSNB431I -DB2V HIPERPOOL ACTIVITY (USING ASYNCHRONOUS
DATA MOVER FACILITY) -
HP READS = 0 HP WRITES = 0
READ FAILURES = 0 WRITE FAILURES = 0
DSNB440I -DB2V PARALLEL ACTIVITY -
PARALLEL REQUEST = 0 DEGRADED PARALLEL= 0
DSNB441I -DB2V LPL ACTIVITY -
PAGES ADDED = 0
DSN9022I -DB2V DSNB1CMD '-DIS BUFFERPOOL' NORMAL COMPLETION

35
 RESULTATS
Pool DB2 Hit Rate % Hit Rate % GBP Hit Getpgs Pg Upd Sync I/O
Name Target with P/F w/o P/F Ratio % /Second /Second /Secon
BP0 DB2V 99.91 99.94 37.87 870.85 4.27 0.49
BP2 DB2V 99.34 99.99 0.00 758.29 834.05 0.02
BP4 DB2V 93.51 98.81 0.00 11158.59 5615.00 47.62
BP5 DB2V 99.32 99.80 0.00 6004.00 185.60 130.85
BP10 DB2V 78.15 88.90 27.42 6207.40 25.91 460.17
BP11 DB2V 91.56 95.45 14.51 11599.64 201.79 515.22
BP32K DB2V 0.00 0.00 0.00 0.00 0.00 0.00
BP32K2 DB2V 99.83 99.81 0.00 11.30 8.60 0.01
BP16K0 DB2V 54.99 55.88 63.82 4547.14 10.05 1851.54
BP16K1 DB2V 0.00 0.00 0.00 0.00 0.00 0.00
BP16K2 DB2V 0.00 0.00 0.00 0.00 0.00 0.00

36
 Performances
1-sur un select de 150 000 pages de 4k avec un BP de 600 MB, ( en VBP
ou en DSP) , un overhead de 5 à 6% en temps CPU pour DSP du au
lookaside.
Même elapsed time  I/O bound
2-si la taille de la mémoire ne correspond pas à la taille de DSP ( ex 6 GB
pour une mémoire réelle de 2 GB) un select de 1 500 000 pages peut
entraîner un overhead important (prés de 50%)
3-ce même select entre un VBP de 800 MB et un DSP de 6 GB donne un
elapsed time réduit de 40 fois et un CPU time réduit de 25%
4- des tests sur les transactions donnent un gain de 40 % pour l’elapsed
time et de 20% pour le CPU time.
5- les utilitaires n’ont pas été mesuré

37
 Performances
Comparaison entre Hiperpools et dataspaces:
Performance en lecture:
- A taille égale , a peu près équivalent si 100% BP miss
- Si BP hits, Dataspace est plus efficace
- HP peut avoir besoin de 2 moves
- DSP ne demande qu’un move
- peut se traduire par un gain de plus de 30% CPU
Performance en écriture:
Du fait que l’on ne peut stocker une donnée modifiée en HP, les DSP sont
beaucoup plus efficaces

38
 Mise en œuvre des dataspaces
avec la commande
ALTER BUFFERPOOL (BP10) VPTYPE(DATASPACE)
On obtient:
DSNB535I -DB2T VPTYPE FOR BP10 HAS BEEN SET TO
DATASPACE.
IT WILL TAKE EFFECT ON THE NEXT ALLOCATION.
DSN9022I -DB2T DSNB1CMD '-ALTER BUFFERPOOL' NORMAL
COMPLETION

39
 Mise en œuvre des dataspaces
sur la commande
Dis BUFFERPOOL (BP10)
On obtient:
DSNB401I -DB2T BUFFERPOOL NAME BP10, BUFFERPOOL ID 10,
USE COUNT 1
DSNB402I -DB2T VIRTUAL BUFFERPOOL SIZE = 1400 BUFFERS

ALLOCATED = 1400 TO BE DELETED = 0

IN-USE/UPDATED = 3
DSNB406I -DB2T VIRTUAL BUFFERPOOL TYPE -
CURRENT = PRIMARY
PENDING = DATASPACE
PAGE STEALING METHOD = LRU ……..

40
 Mise en œuvre des dataspaces
pour rendre effectif, le dataspace on peut soit :
1. Stopper et redémarrer le DB2
2. Stopper tous les objets qui utilisent ce buffer pool
3. Faire une commande
ALTER BUFFERPOOL BP(10) vpsize(0)
puis, quand le dataspace a été pris en compte , remettre la valeur de
la vpsize initiale.

Il ne peut pas y avoir de HPSIZE en cas de DATASPACE, mais cela ne

plante pas .

41
 Impact sur le data sharing
En cas de Data Sharing , l’utilisation des dataspaces, permettant d’allouer
des tailles beaucoup plus grandes, doit bien sur aller de pair avec
l’augmentation des Group Buffer Pool correspondant
Chaque membre ayant ces propres buffers pools , pour un BP particulier,
un membre peut utiliser du VBP et un autre du DSP

42
 RECAPITULATIF
HPOOL HPOOL DSPOOL DSPOOL
En 31 bit En 64 bit En 31 bit En 64 bit
DB2 V5 YES N/S N/S N/S

DB2 V6 YES N/S YES N/S

DB2 V7 YES NO YES YES

43
DB2 VERSION 8

44
 DB2 version 8
L’arrivée de la version 8 remet tout en question, car cette version va
supporter le 64-bit adressage .
La nouvelle taille de l’adresse space du DBM1 pourra aller jusqu’à 16
exabytes soit 8 milliards de fois la taille supportée en Version 7.
Par comparaison, la différence est la même qu’entre une clef de 5 cm de
long et la distance de la terre à la lune .

45
 DB2 version 8
Au niveau de nos buffers pools :
La question ne devrait plus se poser entre VBP, HP et DSP , nous aurons
la possibilité de tout remettre en Virtual Buffers Pools avec des
valeurs que nous ne pouvons tester pour le moment.

Ceci, bien sur, sera valable également pour les autres zones mémoires
tel que:
- EDM Pool
- Sort Pool
- RID Pool
- ……

46
 DB2 version 8
Mais ceci sera une autre grande aventure que nous
attendons tous avec une certaine fébrilité .

Merci de m’avoir écouter .

47