DB2 et les DISQUES Définitions Paramètres utiles

Présentation au sujet: "DB2 et les DISQUES Définitions Paramètres utiles"— Transcription de la présentation:

1 DB2 et les DISQUES Définitions Paramètres utiles
Exemples de « LAYOUT »: mes expériences bonnes et mauvaise Mes leçons

2 Définitions DMS: tablespace géré par la database: fichier ou raw
SMS: tablespace géré par le system: répertoire PAGESIZE: taille des pages dans un tablespace EXTENTSIZE: taille allocation dans un tablespace STRIP SIZE: taille d’un bloc sur les disque RAID ARRAY: un RAID (groupe de disque sécurisé) LUN: Unité logique fourni par une baie CONTAINERS: nom des fichiers, disques ou répertoires ou sont stockés les tablespaces Multipathing: mécanisme OS pour accéder un disque(LUN) par plusieurs chemins

3 Baie de disque : DSxxxx 1 2 … 8 1 2 … 8 1 2 … 8 1 2 … 8 ….. 1 2 … 8
LUN1 1 2 … 8 LUN2 1 2 … 8 1 2 … 8 LUN3 1 2 … 8 ….. 1 2 … 8 LUN n

4 Allocation sur les containers
Tablespace X Cn C1 C2 En E1 E2 En+1 ……….

5 Multipathing Tape x DSxxxx LUN1 1 2 … 8 LUN2 System x SAN

6 Paramètres utiles PARALLEL_IO NUM_IOSERVERS PAGESIZE EXTENTSIZE
PREFETCHSIZE queue_depth(Disk parameter) DB2 V9:FILE SYSTEM CACHING: tablespace option AIX: utiliser JFS2 (limites, no fs caching, …)

7 Principes à respecter Connaissez votre configuration disque SIMPLICITE
SMS: petit volume DMS: gros volume EXTENTSIZE=STRIPSIZE ou STRIPSIZExNumber of disque of RAID Utiliser le plus de disque possible (au moins 2) Séparer les logs du reste (pour des raisons de sécurité) Ne pas désactiver le FS caching sur les log, fichiers de la DB, binaires DB2 Tous les containers d’un même tablespace ont la même taille Petite table=petit extentsize GROS NUM_IOSERVERS QUEUE-DEPTH:General rule of thumb is to configure queue depth of 8 per each physical disk in the LUN (default is 10)

8 Exemples 1 « GROS »FS strippés, 1 container sur le FS par tablespace
Facile à administrer L’accroissement est une horreur Utilisation de Raw device Difficile à Administrer (nécessite des connaissances OS et DB) Plus trop d’intérêt avec « no file system caching » options 1 FS par ARRAY,1 container de chaque tablespace sur chaque FS Accroissement maitrisé si on procède par ajout d’array Plusieurs FS strippés, 1 container de chaque tablespace sur chaque FS

9 Mes leçons Faire un beau « layout » en début de projet ne présage pas d’un beau « layout » à la fin: il faut envisager l’accroissement des « grosses » DB des leur création Attention au gâchis d’espace disque (FREE space)

10 La solution que j’utilise
1 FS par array Chaque FS sur un array différent 1 container par FS Chaque tablespace à 1 container par FS Si suffisamment de FS,ARRAY: séparation de data et index Séparation des logs DB2, des binaires et des fichiers de la DB du reste(tablespaces) L’agrandissement se fait par ajout de array, FS, container  Attention rebalancing