Archives par mot-clé : index

SQL cours

Instruction SQL CREATE INDEX

L’instruction CREATE INDEX est utilisée pour créer des index dans les tables.

Les index sont utilisés pour récupérer les données de la base de données plus rapidement qu’autrement. Les utilisateurs ne peuvent pas voir les index, ils sont juste utilisés pour accélérer les recherches/requêtes.

La mise à jour d’une table avec des index prend plus de temps que la mise à jour d’une table sans (car les index ont également besoin d’une mise à jour). Donc, ne créez des index que sur les colonnes qui seront fréquemment recherchées.

CREATE [UNIQUE] INDEX nom-index
        ON nom-table (nom-colonne [ASC | DESC])
        [CLUSTER | NOT CLUSTER]
        [PARTITIONED]
        [PADDED | NOT PADDED]
        [using-specification]
        [free-specification]
        [DEFINE YES | NO]
        [COMPRESS YES | NO]
        [PARTITION BY RANGE partition-element
                      using-specification
                      free-specification]
        [BUFFERPOOL nom-bp]
        [CLOSE YES | NO]
        [DEFER YES | NO]
        [PIECESIZE integer]
        [COPY YES | NO]


using-specification
        USING
              VCAT nom-catalogue |
              STOGROUP nom-stogroup
                  PRIQTY integer
                  SECQTY integer
                  ERASE YES | NO

free-specification
        FREEPAGE integer
        PCTFREE integer

partition-element
        PARTITION integer
        ENDING AT (constant/MAXVALUE/MINVALUE)

UNIQUE:

Cela empêche la table de contenir deux lignes ou plus avec la même valeur de la clé d’index.

ASC :

  • Spécifie que les entrées d’index doivent être conservées dans l’ordre croissant des valeurs de colonne.
  • Ce sont les paramètres par défauts.

DESC :

Spécifie que les entrées d’index doivent être conservées dans l’ordre décroissant des valeurs de colonne.

CLUSTER ou NOT CLUSTER :

Spécifie si l’index est l’index de clustering de la table ou non.

PARTITIONED :

Spécifie que l’index est des données partitionnées

PADDED ou NOT PADDED :

Spécifie comment les colonnes de chaîne de longueur variable doivent être stockées dans l’index.

  • PADDED : spécifie que les colonnes de chaîne de longueur variable dans l’index sont toujours remplies avec le caractère de remplissage par défaut jusqu’à leur longueur maximale.
  • NOT PADDED : spécifie que les colonnes de chaîne de longueur variable ne doivent pas être remplies à leur longueur maximale dans l’index.

Clause USING :

  • Pour les index non partitionnés, la clause USING indique si les ensembles de données de l’index doivent être gérés par l’utilisateur ou gérés par DB2.
  • VCAT : spécifie que le premier ensemble de données pour l’index est géré par l’utilisateur et que les ensembles de données suivants, si nécessaire, sont également gérés par l’utilisateur.
  • STOGROUP : Spécifie que DB2 définira et gérera les ensembles de données d’index. 
  • PRIQTY : spécifie l’allocation d’espace primaire minimum pour l’ensemble de données gérées DB2.
  • SECQTY : spécifie l’allocation d’espace secondaire minimum pour l’ensemble de données gérées DB2.
  • ERASE : Indique si les ensembles de données gérés par DB2 doivent être effacés lors de la suppression de l’index.

FREEPAGE :

Spécifie la fréquence à laquelle laisser une page d’espace libre lors de la création d’entrées d’index.

PCTFREE :

Détermine le pourcentage d’espace libre à laisser dans chaque page non-feuille et page feuille lorsque des entrées sont ajoutées à l’index.

DEFINE :

Spécifie quand les ensembles de données sous-jacents pour l’index sont physiquement créés.

  • OUI : les ensembles de données sont créés lors de la création de l’index. OUI est la valeur par défaut.
  • NON : les ensembles de données ne sont pas créés tant que les données ne sont pas insérées dans l’index.

COMPRESS :

Spécifie si la compression des données d’index sera utilisée.

  • NO : spécifie qu’aucune compression d’index ne sera utilisée. C’est la valeur par défaut.
  • YES : spécifie que la compression d’index sera utilisée.

PARTITION BY RANGE :

Spécifie que l’index est l’index de partitionnement.

  • PARTITION integer : une clause PARTITION spécifie la valeur la plus élevée de la clé d’index dans une partition d’un index de partitionnement.
  • ENDING AT : Spécifie qu’il s’agit de l’index de partitionnement et indique comment les données seront partitionnées.
    CONSTANT : spécifie une valeur constante avec un type de données qui doit être conforme aux règles d’attribution de cette valeur à la colonne.
    MAXVALUE : spécifie une valeur supérieure à la valeur maximale pour la clé de limite d’une limite de partition.
    MINVALUE : spécifie une valeur inférieure à la valeur minimale de la clé de limite d’une limite de partition.

BUFFERPOOL :

Identifie le pool de mémoire tampon à utiliser pour l’index.

CLOSE :

Spécifie si l’ensemble de données peut ou non être fermé lorsque l’index n’est pas utilisé et que la limite du nombre d’ensembles de données ouverts est atteinte.

  • OUI : Admissible à la fermeture. C’est la valeur par défaut
  • NON : Non éligible à la fermeture.

DEFER :

Indique si l’index est créé lors de l’exécution de l’instruction CREATE INDEX.

  • NON : L’index est construit. C’est la valeur par défaut.
  • OUI : L’index n’est pas construit.

PIECESIZE :

Spécifie l’adressabilité maximale de chaque ensemble de données pour un index.

COPY :

Indique si l’utilitaire COPY est autorisé pour l’index.

  • NON : N’autorise pas l’image complète ou les copies simultanées. NON est la valeur par défaut.
  • OUI : Autorise l’image complète ou les copies simultanées.

Exemple 1:

Créez un index sur la colonne TAB1_COL2 d’une table TB_TAB1.

CREATE INDEX IX_TAB1_COL2
       ON TB_TAB1(TAB1_COL2);

Créez un index nommé NOM_IX_PROJET sur la table TB_PROJET. Le but de l’index est de s’assurer qu’il n’y a pas deux entrées dans la table avec la même valeur pour le nom du projet (NOM_PROJET). Les entrées d’index doivent être dans l’ordre croissant.

CREATE UNIQUE INDEX NOM_IX_PROJET
       ON TB_PROJET(NOM_PROJET);

Créez un index nommé IX_EMPLOYE_JOB_DEPT sur la table TB_EMPLOYE. Organisez les entrées d’index dans l’ordre croissant par intitulé de poste (EMPLOYE_JOB) au sein de chaque département (EMPLOYE_DEPT).

CREATE INDEX IX_EMPLOYE_JOB_DEPT
       ON TB_EMPLOYE (EMPLOYE_DEPT, EMPLOYE_JOB);

Exemple 2 :

Créez un index unique, nommé DSN8910.IX_DEPT, sur la table DSN8910.TB_DEPT. Les entrées d’index doivent être dans l’ordre croissant par la colonne unique DEPT_NO. DB2 doit définir les ensembles de données pour l’index, à l’aide du groupe de stockage DSN8G910.

Chaque ensemble de données doit contenir au maximum 1 Mégaoctet de données. Utilisez 512 Ko comme allocation d’espace primaire pour chaque ensemble de données et 64 Ko comme allocation d’espace secondaire. Remplir l’index.

Les ensembles de données peuvent être fermés lorsque personne n’utilise l’index et n’ont pas besoin d’être effacés si l’index est supprimé.

CREATE UNIQUE INDEX DSN8910.IX_DEPT
        ON DSN8910.TB_DEPT
              (DEPT_NO ASC)
        PADDED
        USING STOGROUP DSN8G910
                       PRIQTY 512
                       SECQTY 64
                       ERASE NO
       BUFFERPOOL BP1
       CLOSE YES
       PIECESIZE 1M;

Explication:

Les ensembles de données sous-jacents pour l’index seront créés immédiatement, ce qui est la valeur par défaut (DEFINE YES). En supposant que la table DSN8910.TB_DEPT est vide, si nous voulions différer la création des ensembles de données jusqu’à ce que les données soient insérées pour la première fois dans l’index, nous spécifierions DEFINE NO au lieu d’accepter le comportement par défaut.

La spécification de PADDED garantit que les colonnes de chaînes de caractères de longueur variable dans l’index sont complétées par des blancs.

Exemple 3 :

Créez un index de cluster, nommé IX_EMP, sur la table TB_EMP dans la base de données DSN8910. Mettez les entrées dans l’ordre croissant par la colonne EMP_NO. Laissez DB2 définir les ensembles de données pour chaque partition à l’aide du groupe de stockage DSN8G910. Faites en sorte que l’allocation d’espace principal soit de 36 kilo-octets et autorisez DB2 à utiliser la valeur par défaut pour SECQTY. Si l’index est supprimé, les ensembles de données n’ont pas besoin d’être effacés.

Il doit y avoir 4 partitions, avec des entrées d’index réparties entre elles comme suit :

  • Partition 1 : entrées jusqu’à H99
  • Partition 2 : entrées au-dessus de H99 jusqu’à P99
  • Partition 3 : entrées au-dessus de P99 jusqu’à Z99
  • Partition 4 : entrées au-dessus de Z99

Associez l’index au pool de mémoire tampon BP1 et autorisez la fermeture des ensembles de données lorsque personne n’utilise l’index. Activez l’utilisation de l’utilitaire COPY pour l’image complète ou les copies simultanées.

CREATE INDEX DSN8910.IX_EMP
        ON DSN8910.TB_EMP
            (EMP_NO ASC)
        USING
            STOGROUP DSN8G910
                PRIQTY 36
                ERASE NO
        CLUSTER
        PARTITION BY RANGE
            (PARTITION 1 ENDING AT('H99'),
             PARTITION 2 ENDING AT('P99'),
             PARTITION 3 ENDING AT('Z99'),
             PARTITION 4 ENDING AT('999'))
        BUFFERPOOL BP1
        CLOSE YES
        COPY YES;
SQL cours

Instruction SQL ALTER INDEX

L’instruction SQL ALTER INDEX est utilisée pour modifier la définition d’un index.

Voici la syntaxe de modification d’index :

ALTER INDEX nom-index
      [REGENERATE]
      [ADD COLUMN (nom-colonne ASC/DESC)]
      [CLUSTER | NOT CLUSTER]
      [PADDED | NOT PADDED]
      [using-specification]
      [free-specification]
      [COMPRESS YES | NO]
      [ALTER partition-element
            using-specification
            free-specification]
      [BUFFERPOOL nom-bp]
      [CLOSE YES | NO]
      [PIECESIZE integer]
      [COPY YES | NO]

Explication:

  • REGENERATE : Spécifie que l’index sera régénéré.
  • ADD COLUMN : ajoute nom-colonne à l’index.
  • ALTER PARTITION : identifie la partition de l’index à modifier.

Exemple 1:

Modifiez l’index DSN8910.IX_EMP. Indiquez que DB2 ne doit pas fermer les ensembles de données qui prennent en charge l’index lorsqu’il n’y a aucun utilisateur actuel de l’index.

ALTER INDEX DSN8910.IX_EMP
      CLOSE NO;

Modifier l’index partitionné DSN8910.IX_DEPT. Pour la partition 3, laissez une page d’espace libre pour 13 pages et 13 % d’espace libre par page. Pour la partition 5, laissez une page pour 25 pages et 25 % d’espace libre. Pour toutes les autres partitions, laissez une page d’espace libre pour 6 pages et 11 % d’espace libre.

ALTER INDEX DSN8910.IX_DEPT
USING
    VCAT CATLGG
FREEPAGE 6
PCTFREE 11
ALTER PARTITION 3
    USING VCAT CATLGG
    FREEPAGE 13
    PCTFREE 13,
ALTER PARTITION 5
    USING VCAT CATLGG
    FREEPAGE 25
    PCTFREE 25;

Exemple 2 :

Modifiez l’index DSN8910.IX_PROJ. Utilisez BP1 comme pool de mémoire tampon à associer à l’index, indiquez que l’image complète ou les copies simultanées sur l’index sont autorisées et modifiez la taille maximale de chaque ensemble de données à 8 mégaoctets.

ALTER INDEX DSN8910.IX_PROJ
        BUFFERPOOL BP1
        COPY YES
        PIECESIZE 8M;

Exemple 3 :

Supposons que l’index IX_X1 contient au moins une colonne de longueur variable et est un index rembourré. Remplacez l’index par un index qui n’est pas rempli.

ALTER INDEX IX_X1 NOT PADDED;
DB2 cours

Détails de la base de données DB2

Une base de données (DB2) est un ensemble de tables de données ou d’entités associées. Par exemple, une base de données typique pour une organisation comprendrait un client, une commande et des tables de détails de commande. Toutes ces tables sont liées les unes aux autres d’une manière ou d’une autre. Dans cet exemple, les clients ont des commandes et les commandes ont des détails de commande. Même si chaque table existe par elle-même, collectivement, les tables constituent une base de données.

La base de données est un groupe d’espaces de table et d’espaces d’index logiquement liés, qui à leur tour contiennent respectivement des tables et des index.

La base de données par défaut, DSNDB04, est prédéfinie dans le processus d’installation de DB2.

Espace table (Table Space)

Les données sont en fait stockées dans une structure appelée espace table (Table Space).

Chaque espace table est corrélé à un ou plusieurs ensembles de données VSAM physiques individuels dans les volumes DASD du groupe de stockage.

Chaque espace table contient une ou plusieurs tables.

Il existe trois types d’espace table différents :

  • Espace de table simple
  • Espace table segmenté
  • Espace table partitionné

Nous parlerons en détail de l’espace de la table tout en traitant des ” verrous ”  (Locks) au chapitre “DB2 – Verrous“.

Espace d’indexation (Index Space)

Un espace d’index est la structure de stockage sous-jacente pour les données d’index.

Chaque espace d’index correspond à un ou plusieurs ensembles de données VSAM physiques individuels dans les volumes DASD du groupe de stockage.

Il est automatiquement créé par DB2 chaque fois qu’un index est créé. Il ne peut y avoir qu’un seul index dans un espace d’index.

Table

Les tables sont des structures logiques gérées par le gestionnaire de base de données.

Lorsque vous stockez des informations dans votre classeur, vous ne les jetez pas simplement dans un tiroir. Au lieu de cela, vous créez des fichiers dans le classeur, puis vous classez les données associées dans des fichiers spécifiques.

Dans le monde des bases de données, ce fichier s’appelle une table. Une table est un fichier structuré qui peut stocker des données d’un type spécifique. Une table peut contenir une liste de clients, un catalogue de produits ou toute autre liste d’informations.

Chaque table a un nom, et dans une table, chaque colonne a un nom. Aucun ordre particulier n’est conservé parmi les lignes d’une table, mais les lignes peuvent être récupérées dans un ordre déterminé par les valeurs de leurs colonnes. Les données d’un tableau sont logiquement liées. Toutes les données de table sont affectées à des espaces table.

Un tableau est constitué de données disposées logiquement en colonnes et en lignes.

Colonne (Column)

  • Les tableaux sont constitués de colonnes. Une colonne contient une information particulière dans un tableau.
  • La colonne est un champ unique dans une table. Tous les tableaux sont constitués d’une ou plusieurs colonnes.
  • La meilleure façon de comprendre cela est d’envisager les tables de base de données comme des grilles, un peu comme des feuilles de calcul. Chaque colonne de la grille contient une information particulière. Par exemple : dans une table “client“, une colonne contient le numéro de client, une autre contient le nom du client, et l’adresse, la ville, l’état et le code postal sont tous stockés dans leurs propres colonnes.

Ligne (Row)

  • Les données d’une table sont stockées dans des lignes.
  • La ligne est un enregistrement dans une table.
  • Encore une fois, en envisageant un tableau comme une grille de style feuille de calcul, les colonnes verticales de la grille sont les colonnes du tableau et les lignes horizontales sont les lignes du tableau.

Par exemple, une table client peut stocker un client par ligne. Le nombre de lignes dans la table est le nombre d’enregistrements qu’elle contient.

Exemple de table

Types de tableaux

Table de base : une table de base est créée avec l’instruction CREATE TABLE et est utilisée pour contenir des données utilisateur persistantes.

Table de résultats : une table de résultats est un ensemble de lignes que le gestionnaire de base de données sélectionne ou génère à partir d’une ou plusieurs tables de base pour répondre à une requête.

Table récapitulative : une table récapitulative est une table définie par une requête qui est également utilisée pour déterminer les données de la table. Les tables récapitulatives peuvent être utilisées pour améliorer les performances des requêtes. Si le gestionnaire de base de données détermine qu’une partie d’une requête peut être résolue à l’aide d’une table récapitulative, le gestionnaire de base de données peut réécrire la requête pour utiliser la table récapitulative.

Table temporaire : une table temporaire déclarée est créée avec une instruction DECLARE GLOBAL TEMPORARY TABLE et est utilisée pour contenir des données temporaires au nom d’une seule application. Cette table est supprimée implicitement lorsque l’application se déconnecte de la base de données.

Index

Un index est une aide à l’accès aux données qui peut être créée sur une table. C’est un ensemble ordonné de pointeurs vers les lignes d’une table.

Chaque index est basé sur les valeurs des données dans une ou plusieurs colonnes d’une table. Un index est un objet distinct des données de la table. Lorsque vous créez un index, le gestionnaire de base de données construit la structure et la maintient automatiquement.

Un index peut servir les objectifs suivants :

  • Améliorer les performances. Dans la plupart des cas, l’accès aux données est plus rapide avec un index. Fournit un moyen rapide de rechercher des lignes dans une table en fonction de leurs valeurs dans les colonnes clés.
  • Applique les règles d’unicité en définissant une colonne ou un groupe de colonnes en tant qu’index unique ou clé primaire.
  • Fournit un ordre logique des lignes d’une table en fonction des valeurs des colonnes clés.
  • Regroupe les lignes d’une table dans le stockage physique selon l’ordre de l’index défini.

Vue (View)

Une vue offre une manière différente d’examiner les données dans une ou plusieurs tables. La vue est une table virtuelle constituée d’une instruction SQL SELECT qui accède aux données d’une ou plusieurs tables ou vues.

Une vue ne stocke jamais de données. Lorsque vous accédez à une vue, l’instruction SQL qui la définit est exécutée pour dériver les données demandées.

Une vue comporte des colonnes et des lignes, tout comme une table de base. Toutes les vues peuvent être utilisées comme des tables de base pour la récupération de données.

Vous pouvez utiliser des vues pour contrôler l’accès aux données sensibles, car les vues permettent à plusieurs utilisateurs de voir différentes présentations des mêmes données. Par exemple, plusieurs utilisateurs peuvent accéder à une table de données sur les employés. Un responsable voit des données sur ses employés, mais pas sur les employés d’un autre service. Un chargé de recrutement voit les dates d’embauche de tous les employés, mais pas leurs salaires ; un agent financier voit les salaires, mais pas les dates d’embauche. Chacun de ces utilisateurs travaille avec une vue dérivée de la table de base. Chaque vue apparaît comme une table et a son propre nom.

Lorsque la colonne d’une vue est directement dérivée de la colonne d’une table de base, cette colonne de vue hérite de toutes les contraintes qui s’appliquent à la colonne de la table de base. Par exemple, si une vue inclut une clé étrangère de sa table de base, les opérations d’insertion et de mise à jour utilisant cette vue sont soumises aux mêmes contraintes référentielles que la table de base. De plus, si la table de base d’une vue est une table parent, les opérations de suppression et de mise à jour utilisant cette vue sont soumises aux mêmes règles que les opérations de suppression et de mise à jour sur la table de base.

Une vue peut devenir inopérante (par exemple, si la table de base est supprimée) ; si cela se produit, la vue n’est plus disponible pour les opérations SQL.

La meilleure façon de reconnaître les vues est de regarder un exemple. (Vous étudierez plus en détail les SQL. Cet exemple est juste pour vous faire comprendre le concept de vues).

Vous avez les trois tables suivantes :

  • Clients
  • Commandes
  • Détails de la commande

Vous devez récupérer les clients qui ont commandé un produit spécifique.

Les détails de la colonne sont les suivants :

3 Tables avec leurs colonnes respectives

La requête est la suivante :

SELECT NOM_CLIENT, PRENOM_CLIENT
    FROM  CLIENTS, COMMANDES, DETAILS 
    WHERE CLIENTS.ID_CLIENT = COMMANDES.ID_CLIENT
      AND DETAILS.NUM_COMMANDE = COMMANDES.NUM_COMMANDE 
      AND ID_PRODUIT = 'BANANE' ;

Toute personne ayant besoin de ces données devrait comprendre la structure de la table, ainsi que la façon de créer la requête et de joindre les tables. Pour récupérer les mêmes données pour un autre produit (ou pour plusieurs produits), la dernière clause WHERE devrait être modifiée.

Imaginez maintenant que vous puissiez encapsuler toute cette requête dans une table virtuelle appelée “PRODUITS”. Vous pourriez alors simplement faire ce qui suit pour récupérer les mêmes données :

SELECT NOM_CLIENT, PRENOM_CLIENT
    FROM  PRODUITS
    WHERE ID_PRODUIT = 'BANANE' ;

C’est là que les vues entrent en jeu. “PRODUITS” est une vue et, en tant que vue, elle ne contient aucune colonne ni donnée. Au lieu de cela, il contient une requête, la même requête utilisée ci-dessus pour joindre correctement les tables.

Pourquoi utiliser les vues ?

Voici quelques utilisations courantes des vues :

  • Pour extraire des données de plusieurs tables.
  • Pour réutiliser les instructions SQL.
  • Pour simplifier les opérations SQL complexes. Une fois la requête écrite, elle peut être réutilisée facilement, sans avoir à connaître les détails de la requête sous-jacente elle-même.
  • Pour exposer des parties d’un tableau au lieu de tableaux complets.
  • Pour sécuriser les données. Les utilisateurs peuvent avoir accès à des sous-ensembles spécifiques de tables au lieu de tables entières.
  • Pour modifier le formatage et la représentation des données. Les vues peuvent renvoyer des données formatées et présentées différemment de leurs tables sous-jacentes.

Pour la plupart, une fois les vues créées, elles peuvent être utilisées de la même manière que les tables. Vous pouvez effectuer des opérations SELECT, filtrer et trier des données, joindre des vues à d’autres vues ou tables, et éventuellement même ajouter et mettre à jour des données. Certaines restrictions s’appliquent à ce dernier élément. La chose importante à retenir est que les vues ne sont que cela, des vues sur des données stockées ailleurs. Les vues ne contiennent pas de données elles-mêmes, de sorte que les données qu’elles renvoient sont extraites d’autres tables. Lorsque des données sont ajoutées ou modifiées dans ces tables, les vues renverront ces données modifiées.

Il existe des problèmes de performances avec les vues car les vues ne contiennent aucune donnée, toute récupération nécessaire pour exécuter une requête et qui doit être traitée chaque fois que la vue est utilisée. Si vous créez des vues complexes avec plusieurs jointures et filtres, ou si vous imbriquez des vues, vous constaterez peut-être que les performances sont considérablement dégradées. Assurez-vous de tester l’exécution avant de déployer des applications qui utilisent beaucoup les vues.

Synonyme

  • Autre nom privé pour une table ou une vue.
  • Un synonyme ne peut être utilisé que par la personne qui l’a créé.

Lorsqu’une table ou une vue est supprimée, tous les synonymes qui y sont définis sont également supprimés.

Alias

  • Nom défini localement pour une table ou une vue dans le même sous-système DB2 local ou dans un sous-système DB2 distant. Les alias confèrent à DB2 une indépendance d’emplacement car un alias peut être créé pour une table sur un site distant, évitant ainsi à l’utilisateur de spécifier le site qui contient les données. Les alias peuvent également être utilisés comme un type de synonyme global car ils peuvent être consultés par n’importe qui, pas seulement par leur créateur.
  • Lorsqu’une table/vue est supprimée, tous les alias définis dessus ne sont PAS supprimés.
  • Utilisez des synonymes pour le développement de programmes, utilisez des alias pour les applications distribuées et utilisez des vues pour la sécurité et l’adhésion.

Le tableau suivant donne la différence entre “Synonyme” et “Alias” :

SynonymeAlias
Un autre nom pour une table ou une vue qui doit résider dans le sous-système DB2 localUn autre nom pour une table ou une vue qui peut résider dans le sous-système DB2 local ou distant
Ne peut être utilisé que par son créateurPeut être utilisé par n’importe qui, y compris son créateur
Est supprimé lorsque la table/vue correspondante est suppriméePas supprimé même lorsque la table/vue correspondante est supprimée
Différences entre Synonyme et Alias

Stockage physique des données 

La figure suivante représente la façon dont les données sont stockées physiquement dans le système DB2 :

Stockage physique des données 
Exemple de stockage de données physique

Pools de mémoire tampon (Buffer Pool)

Les pools de mémoire tampon sont des zones de stockage virtuel dans lesquelles DB2 stocke temporairement des pages d’espaces table ou d’index.

Les pools de mémoire tampon améliorent les performances de la base de données. Si une page de données nécessaire se trouve déjà dans le pool de mémoire tampon, cette page est accessible plus rapidement que si cette page devait être lue directement à partir du disque. Le gestionnaire de base de données a des agents dont les tâches consistent à récupérer les pages de données du disque et à les placer dans le pool de mémoire tampon (prefetchers), et à réécrire les pages de données modifiées du pool de mémoire tampon sur le disque (nettoyeurs de page).

La lecture et l’écriture de pages de données vers et depuis le disque sont appelées entrée/sortie disque (E/S). Éviter l’attente associée aux E/S disque est le principal moyen d’améliorer les performances de la base de données. La manière dont vous créez le pool de mémoire tampon et configurez le gestionnaire de base de données et les agents associés au pool de mémoire tampon contrôle les performances de la base de données.

Dans DB2, vous avez la possibilité d’allouer 80 pools de mémoire tampon :

  • 50 pools de mémoire tampon 4K et
  • 10 pools de mémoire tampon 8K, 16K et 32K.

Le pool de mémoire tampon par défaut est BP0.

Relation entre les espaces de table et les pools de mémoire tampon

Chaque espace table est associé à un pool de mémoire tampon spécifique dans une base de données. Un tablespace est associé à un bufferpool. La taille du pool de mémoire tampon et de l’espace de table doit être identique. Plusieurs pools de mémoire tampon vous permettent de configurer la mémoire utilisée par la base de données pour augmenter ses performances globales.

Tailles des pools de mémoire tampon

La taille de la page du pool de mémoire tampon est définie lorsque vous utilisez la commande “CREATE DATABASE“. Si vous ne spécifiez pas la taille de la page, elle prendra la taille de page par défaut, qui est de 4 Ko. Une fois le bufferpool créé, il n’est plus possible de modifier la taille de la page ultérieurement