💾 DB2 for z/OS – Le Guide Ultime

DB2 (comme tout sous z/OS) ne tourne pas comme un seul "processus". Il s'exécute en tant que plusieurs **Address Spaces (AS)** (espaces d'adressage mémoire) qui collaborent.

Diagramme (Simplifié)

(Client: CICS, Batch/JCL, TSO)
         |
         | (Connexion)
         ▼
+-----------------+
|   DIST (as)     | (Distributed Data Facility)
| (Réseau / TCP/IP) |
+-----------------+
         |
         ▼
+-----------------+
|   MSTR (as)     | (Master / System Services)
| (Coordinateur)  |
+-----------------+
         |
         +----------------------------------+
         |                                  |
         ▼                                  ▼
+-----------------+                  +-----------------+
|   DBM1 (as)     | (Database Manager) |   IRLM (as)     | (Lock Manager)
| (Le "Cerveau" SQL)|                  | (Gestionnaire de |
| (EDM Pool)      |                  |  Verrous)       |
| (Bufferpools)   |                  +-----------------+
+-----------------+

DB2 ne stocke pas ses données dans un "gros fichier .db". Il utilise une structure complexe de fichiers (datasets) gérés par z/OS.

1. Fichiers Physiques (VSAM LDS)

Au plus bas niveau, les données sont stockées dans des VSAM Linear Data Sets (LDS). C'est le "fichier plat" (dataset) sur le disque (DASD). L'OS (z/OS) voit un LDS, mais DB2 (DBM1) voit un Tablespace.

2. Hiérarchie (Catalog & Directory)

DB2 utilise un "meta-stockage" pour se gérer lui-même :

• Catalog (DSNDB06) : La "meta-base". Contient les définitions (SYSTABLES, SYSCOLUMNS...). C'est ici que le CREATE TABLE est stocké.
• Directory (DSNDB01) : Le "cache interne" (DBD, Plans...). (Invisible pour l'utilisateur).

3. Le Tablespace (UTS) (Le "Conteneur" de Table)

On ne stocke pas une TABLE. On stocke un TABLESPACE, qui contient une (ou plusieurs) TABLE(s).

UTS (Universal Table Space) est le standard moderne (recommandé). Il ne contient qu'une seule table.

• PBG (Partition-By-Growth) : (Le plus simple). Un UTS qui grossit "par morceaux" (partitions) automatiquement (ex: ajoute un nouveau fichier VSAM de 4Go quand il est plein).
• PBR (Partition-By-Range) : (Le plus performant/complexe). L'Admin partitionne la table (ex: par ANNEE, CODE_CLIENT). Permet le "Partition Pruning" (l'Optimizer ne lit que la partition 2024) et l'exploitation (REORG d'une seule partition).

Le "Logging" (Journalisation) est la fonction la plus critique de DB2 (garantit ACID).

Diagramme (Flux de Log)

(UPDATE/INSERT/DELETE)
      |
      ▼
+-----------------+
| Log Buffer (RAM)| (Rapide)
+-----------------+
      | (Full / Checkpoint / Commit)
      ▼
+-----------------+
| Active Log (Disque)| (Circulaire)
+-----------------+
      | ("Offload" quand plein)
      ▼
+-----------------+
| Archive Log (Bande/Disque)
| (Historique/Backup)
+-----------------+

• RBA/LRSN (L'Horloge) : DB2 n'utilise pas de "timestamp". Il utilise un RBA (Relative Byte Address) (ou LRSN en Sysplex). C'est le "compteur kilométrique" (offset) du log. (Ex: "Le Checkpoint est à RBA=5000", "Ce COMMIT est à RBA=5120").
• Checkpoint (Point de contrôle) : Moment où DB2 "force" l'écriture des pages modifiées (sales) (des Bufferpools) sur disque (VSAM). Permet un redémarrage (Restart) rapide.
• Group Commit : (Performance OLTP) DB2 attend (quelques ms) pour "grouper" plusieurs COMMIT (ex: 50 COMMITS) en une seule I/O physique sur l'Active Log.
• Restart (Recovery) :
  • Restart Light : (Après un crash) DB2 lit l'Active Log depuis le dernier Checkpoint -> ROLLBACK (UNDO) les COMMITS non validés, ROLLFORWARD (REDO) les COMMITS validés mais non écrits.
  • Cold Start / Recovery : (Après une perte disque) Restaure le COPY (Backup), puis applique les Archive Logs.

Le **Locking** (Verrouillage) est le cœur de la performance **OLTP (Transactionnel)**. C'est géré par l'IRLM (1.1).

DB2 utilise un verrouillage "multi-granularité" (Tablespace, Table, Page, Ligne).

Types de Verrous (Locks)

Deadlock (Étreinte fatale)

Un "Deadlock" se produit quand :
1. Transaction A prend un Lock (X) sur la Ligne 1.
2. Transaction B prend un Lock (X) sur la Ligne 2.
3. Transaction A demande un Lock (X) sur la Ligne 2 (Bloquée par B).
4. Transaction B demande un Lock (X) sur la Ligne 1 (Bloquée par A).

L'IRLM détecte ce cycle (via son "Deadlock Detector") et choisit une "victime" (généralement celle qui a fait le moins de COMMITS) et lui envoie un SQLCODE -911 (Rollback). C'est au programme (COBOL/CICS) de gérer ce -911 (ex: retenter l'opération).

Le Bufferpool (Pool de Tampons) est le "Cache" (RAM) principal de DB2 (dans l'Address Space DBM1). C'est là que DB2 stocke les pages de données (lues depuis le disque VSAM) pour éviter les I/O (l'opération la plus lente).

On définit plusieurs pools, (BP0, BP1... BP3K, BP8K...) de tailles différentes (4K, 8K, 16K) pour les différents Tablespaces (Index vs Données).

Diagramme (I/O & Bufferpool)

(SQL: SELECT * FROM ... WHERE ID=1)
      |
      ▼
+-------------------------+
| DBM1 (Cerveau)          |
| (1. "Ai-je la page X ?")|
+-------------------------+
      |
      ▼
+-------------------------+
| Bufferpool (RAM)        |
| (2. OUI: Hit !)         | (2. NON: Miss...)
+-------------------------+
      | (Hit: Rapide)         | (Miss: Lent)
      ▼                     ▼
(Retour)              (I/O -> VSAM (Disque))

Concepts de Tuning

• Page Fix : (PGFIX=YES) "Verrouille" le Bufferpool en mémoire réelle (pas de "paging" z/OS). (Critique pour la performance OLTP).
• PGSTEAL (Steal Algorithm) : L'algorithme (LRU - Least Recently Used) qui décide quelle "vieille" page (non utilisée) doit être "volée" (steal) (retirée du cache) pour faire de la place.
• Deferred Write (Écriture Différée) : DB2 n'écrit **pas** un UPDATE sur disque au COMMIT (c'est le Log qui garantit l'ACID). Il écrit "plus tard" (différé), quand le Bufferpool est plein ou au Checkpoint.

L'"Optimizer" (Optimiseur) DB2 est le composant qui choisit le "Access Path" (Chemin d'accès) (ex: "Utiliser l'Index A" ou "Faire un full TableScan ?").

RUNSTATS : L'utilitaire (JCL, voir 9.1) **critique** qui collecte les statistiques (CARDINALITY, HIGH2KEY...) sur les tables/index. Sans RUNSTATS, l'Optimizer est "aveugle" et choisit des chemins d'accès désastreux.

Problème : J'ai 1 Mainframe (LPAR) qui exécute DB2. S'il tombe (panne matérielle), la banque s'arrête.

Solution : Sysplex (Data Sharing). C'est l'architecture "Cluster" (Actif-Actif) de DB2.

Plusieurs instances DB2 (sur des LPARs/machines différentes) accèdent aux **mêmes** fichiers VSAM (disques partagés), mais chaque instance a ses propres Bufferpools (cache RAM).

Diagramme (Sysplex Data Sharing)

(Clients -> DDF -> Routeur)
       |                            |
       ▼                            ▼
+-----------------+            +-----------------+
| LPAR 1 (OS 1)   |            | LPAR 2 (OS 2)   |
| +-------------+ | (Communique)| +-------------+ |
| | DB2 (MSTR1) | |<-- (CF) -->| | DB2 (MSTR2) | |
| | (BP 1)      | |            | | (BP 2)      | |
| +-------------+ |            +-------------+ |
+-----------------+            +-----------------+
       | (I/O)                      | (I/O)
       +------------+---------------+
                    |
                    ▼
            +----------------+
            | Disques (VSAM) | (Partagés)
            +----------------+

Coupling Facility (CF) (Le "Coordinateur")

Le CF (matériel ou logiciel) est le "cerveau" partagé qui gère le "Data Sharing" :

• Lock Structure : Gère les verrous (Locks) (P-LOCKS) *entre* les LPARs.
• Group Buffer Pools (GBP) : Gère la "cohérence du cache" (s'assure que le BP 1 et le BP 2 ont la même version d'une page).

Comment "dépanner" DB2 ? On utilise des outils (ex: DataDog, Omegamon) qui lisent les "traces" (IFCIDs) générées par DB2 (envoyées via SMF).

IFCIDs Critiques (pour l'analyse de "Wait Events")

Pour savoir "Pourquoi ma requête est lente ?", on analyse les "Wait Events" (temps d'attente) de la requête :

• IFCID 199 (Bufferpool) : Temps d'attente I/O (Synchrone) (ex: sync_read_io_time). (Problème de Bufferpool (5.1)).
• IFCID 400/401 (Locks) : Temps d'attente sur un Verrou (Lock). (Problème de Concurrence (4.4)).
• IFCID 003 (SQL) : Temps CPU total vs Temps d'attente total.

La maintenance de DB2 se fait via des "Utilitaires" (Utilities), qui sont des programmes (ex: DSNUTILB) lancés via JCL (voir 4.1).

DB2 for z/OS (et le Mainframe) excelle dans les environnements **OLTP (Online Transaction Processing)** à très haute volumétrie et très haute fiabilité (où 0% de perte de données est la norme).

Diagrammes conceptuels (voir les modales précédentes pour le contexte) :