Pourquoi DB2 propose-t-il une table par tablespace?

Question

La documentation DB2 pour DB2 / z v10 contient l'extrait de code suivant dans le section des tablespaces :

En règle générale, vous ne devriez avoir qu'une seule table dans chaque espace table.

Mais cela ne fournit aucune justification à cela.

Nous avons quelques tableaux stockant des informations historiques basées sur le temps selon les lignes suivantes (considérablement réduites en complexité mais devraient suffire à illustrer):

Table HOURLY_CPU_USAGE:
    RecDate        date
    RecTime        time
    Node           char(32)
    MaxCpuUsage    float
    primary key    (RecDate, RecTime, Node)
Table DAILY_CPU_USAGE:
    RecDate        date
    Node           char(32)
    MaxCpuUsage    float
    primary key    (RecDate, Node)
Table MONTHLY_CPU_USAGE:
    RecDate        date
    Node           char(32)
    MaxCpuUsage    float
    primary key    (RecDate, Node)

(le tableau quotidien a tous les enregistrements horaires regroupés en une seule journée, et le tableau mensuel fait de même avec les données quotidiennes, en les regroupant dans la ligne avec la date YYYY-MM-01).

Maintenant, il me semble que ces tables ont toutes un but très similaire et je ne suis pas certain pourquoi nous voudrions les conserver dans des tablespaces séparés.

Remise pour l'instant de la possibilité de les combiner en une seule table, c'est une suggestion que j'ai faite mais il y a des complications qui l'empêchent.

Quelle est la justification de la directive "une table par tablespace"? Quelles sont les exceptions, le cas échéant? Je suppose qu'ils peuvent être des exceptions car cela semble plutôt une ligne directrice qu'une règle absolue.

Answer 1

Juste une supposition sauvage ... mais peut-être qu'IBM recommande pas plus d'une table par espace table car de nombreux utilitaires db / 2 fonctionnent au niveau de l'espace table.Si vous placez plusieurs tables dans un espace table, les utilitaires opèrent sur toutes les tables comme une unité.

Par exemple, la sauvegarde et la restauration fonctionnent au niveau de l'espace table.Vous ne pouvez pas sauvegarder / restaurer des tables individuelles dans le même espace table.Ils sont tous sauvegardés ou restaurés en tant qu'unité.Je pense que le même genre de chose s'applique à d'autres utilitaires et probablement à de nombreux paramètres de réglage également.

Answer 2

De nos jours, la principale raison de conserver une table par espace table est d'ordre administratif. La plupart des utilitaires DB2 fonctionnent au niveau de l'espace table. Par exemple, si vous effectuez un LOAD REPLACE sur un espace table pour une table spécifique, toutes les autres tables seront vides car la première chose que fait LOAD REPLACE est de supprimer toutes les lignes.

Alors "pourquoi ne garderiez-vous pas une table par espace table?". Je pense qu'il est raisonnable et même souhaitable d'inclure plusieurs tables dans un seul espace table lorsque les tables sont liées dans la mesure où l'une est inutile sans l'autre. Par exemple. CustomerTable + NextCustomerIDTable.

Une autre considération est le type d'espace table. Selon le type d'espace table que vous avez créé, la création de plusieurs tables dans un seul espace table peut avoir des implications sur les performances. Si vous n'utilisez pas d'espaces table segmentés, une analyse de l'espace table lira toutes les pages de l'espace table, y compris les pages d'autres tables. Consultez la rubrique "Analyse de l'espace table" ici: http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=%2Fcom.ibm.db2.doc.ve%2Fdvnhlpcn_tablescan.htm

Answer 3

Il semble qu'ils ont changé le texte de leur documentation.

Le lien fourni à la question contient désormais les informations suivantes:

Le nombre de tables que vous devez définir dans un espace table dépend sur les caractéristiques des tableaux:

Si une table peut devenir volumineuse, il est préférable de la placer dans son propre espace table. Cette conception simplifie les performances le réglage, et en particulier, le réglage du pool de tampons. Pour les tables plus petites, les espaces table segmentés à plusieurs tables sont meilleurs. Cette conception permet de réduire le nombre d'ensembles de données qui nécessitent à gérer pour la sauvegarde et la restauration, et le nombre d'ensembles de données que le système de base de données doit s'ouvrir et se fermer pendant DB2 opérations.

Il est préférable de minimiser le nombre d'espaces table dans chaque base de données pour les raisons suivantes:

Pendant l'exécution des instructions de définition de données, le système de base de données maintient un verrou exclusif sur toute la base de données jusqu'à une validation l'opération est exécutée. Le verrou exclusif effectue les opérations suivantes les fonctions: Le verrou exclusif empêche les exécutions simultanées d'instructions de définition de données pour les tables et les index de la même base de données. Si le cache d'instructions dynamiques est désactivé (paramètre de sous-système CACHEDYN= NO), le système de base de données utilise le verrou de base de données pour sérialiser l'exécution des instructions de définition de données et du SQL dynamique instructions qui accèdent aux tables et aux index de la base de données.

S'il y a moins d'espaces table dans la base de données, moins d'espaces table sont verrouillés simultanément. Lors de l'exécution de la phase SWITCH des opérations de l'utilitaire REORG en ligne, le système de base de données obtient un verrou exclusif sur le base de données complète pour sérialiser l'exécution des opérations REORG en ligne et instructions de définition de données sur les tables et les index de la base de données.

S'il y a moins de tables dans la base de données, moins de tables sont verrouillées simultanément. Le volume de journalisation des instructions de définition de données est plus petit lorsqu'il y a moins d'espaces table dans la base de données.

Answer 4

En général, c'est parce que les options de performances ont tendance à être meilleures pour les configurations «une table par tablespace».Par exemple, la possibilité de faire une analyse de partition limitée pour certaines requêtes si la table est partitionnée (ce qui REQUIERT 1 To par TS).

(Mais en tant que personne de performance mainframe, je dirais cela, n'est-ce pas?) :-)