Discussion :

[ujoodha]

Bonjour,

Je travaille actuellement avec db2 v8 sous un AIX 5, nous avons créer une table qui contient maintenant plus de 8 millions de lignes. Ce que l'on voudrait mettre en place c'est un système qui permettrait de requêter pour extraire des données de l'année 2007,2008, etc ... pour éviter de locker la table A (en gros pour les comptas).

D'après ce que j'ai pu lire ce qui pourrait correspondre à mes besoins c'est la création de vue. Mais je dois avouer que j'ai un peu de mal à comprendre le système de vue.

D'après ce que j'ai pu lire, c'est que une vue est une représentation virtuel de la table donc pas de possibilité de création d'index, de tablespaces spécifiques, de contraintes.
Mais la question que je me pose c'est que :
Est ce que ce système m'empêcherait de locker ma table A, est ce que ce système virtuel utilise les indexes physiques (en gros est ce que je gagne en perf et en gestion de transaction )?

Est ce qu'il y aurait quelqu'un pourrait m'éclairer dessus ?

Je vous remercie d'avance.

[pdz74]

Bonjour,

Une vue, c'est purement logique, pas physique. Une vue est en fait le résultat d'une requête exécutée sur une ou plusieurs tables. L'ordre de création d'une vue, c'est d'ailleurs :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
CREATE VIEW TOTO (COL1, COL2, ...) AS
SELECT COL1, COL2, ...
FROM...
WHERE éventuel...
...

Ensuite, dans un programme, tu te sers de la vue en écrivant directement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT COL1, COL2, ...
FROM TOTO
WHERE éventuel
...

Chaque fois que tu te sers d'une vue, DB2 superpose la requête de création de la vue plus ta propre requête. Donc, la table concernée est lue à chaque utilisation, les verrous sur la table sont donc bien posés lors de toute utilisation.

En conclusion, la vue n'est pas la solution que tu recherches.

Les autres solutions possibles en sachant que je connais bien DB2 sous ZOS. Pour AIX, je ne sais pas si ces solutions sont d'actualité.
- Partitionner la table sur l'année. Ensuite, si tu écris WHERE ANNEE = 2007, seule la partition contenant l'année 2007 sera verrouillée.
- Dupliquer tes données en créant par exemple autant de Materialized Query Table (MQT) que d'années. Une MQT, pour résumer, c'est l'équivalent d'une vue, mais le résultat est stockée physiquement sur une autre table, donc dans un espace physique indépendant, contrairement à la vue qui est, je le répète, purement logique. Les verrous seront donc posés sur la MQT et non sur la table de base. Reste à rafraichir les MQT au moment opportun. Si tu veux plus d'infos sur ces MQT, n'hésite pas.
- Jouer éventuellement sur les index, mais un index positionné sur l'année sera très peu discriminant et risque de te poser plus de problèmes qu'autres choses.

A ta disposition.

[J_Edem]

Bonjour,

Je relance ce topic pour savoir si éventuellement on peut créer des MQT à partir d'autres vues matérialisées.

Merci d'avance.

[pdz74]

Si la question est : dans le SELECT de la création de la MQT, peut-on référencer une autre MQT, la réponse est non : ni MQT, ni TTG. Par contre, on peut référencer une table ou une vue standard sans souci.