La différence entre un Index et un fichier LF ? [Résolu]

[JauB]

Bonjour,
Je me pose toujours cette question, et voilà venu le moment opportun pour vous la poser : C'est quoi la différence entre un Index (créé via du SQL : CREATE INDEX ...) et un fihcier logique (créé à partir d'un DDS ) ?
J'ai plusieurs programmes COBOL qui alimentent une base de données et j'ai des rapports qui utilisent SQL sur cette base de données.
Ma démarche est la suivante :

1. Premièrement je développe mes fichiers PF et LF (via des DDS)
2. je développe mes PGM COBOL qui passent par les LF (en utilisant les bons LF selon la clé de tri que j'ai : Dans mon cas un PF peut avoir plusieurs LF, donc j'attaque un tel ou autre LF sur le même PF selon mon besoin), ces PGM COBOL alimentent ma base de données (un simple entrepôt de données)L
3. Une fois que cet entrepôt alimenté, je crée des index (via des CREATE INDEX ...) sur ses tables
4. J'attaque via des requêtes SQL ces tables (je suppose que mes requêtes utilisent alors ces index créés via SQL.

Est ce que ma démarche vous semble correcte ou faut-il l'ajuster ?
J'ai toujours des ambiguités sur les LF/Index !
Merci pour vos lumières

[K2R400]

Un LF peut-être soit un index, soit une vue, soit les deux.
Je te déconseille vivement d'utiliser des LFs.
Créé tes tables, tes index, tes vues avec SQL, requête que sur les PF (tables) et éventuellement si tu veux lire avec les ordres natifs COBOL au lieu de SQL, tu lis avec les index

[JauB]

Ta réponse fait tout un débat

Envoyé par K2R400

Un LF peut-être soit un index, soit une vue, soit les deux.

Est- ce que cela veut dire que lors de la création du DDS (du LF) on a une option qui peut faire cette différence (entre index, vue ou les deux) ? si oui, comment faire ?

Envoyé par K2R400

Je te déconseille vivement d'utiliser des LFs.

Tu peux nous dire pourquoi ?

Envoyé par K2R400

Créé tes tables, tes index, tes vues avec SQL, requête que sur les PF (tables) et éventuellement si tu veux lire avec les ordres natifs COBOL au lieu de SQL, tu lis avec les index

Comment je lis avec les index à partir de COBOL ? Tu veux dire au lieu de faire par exemple :

Code :

1
2
3
4
5
6
7
SELECT FTST00  ASSIGN       DATABASE-MYLF00
                                        ORGANIZATION INDEXED
                                        ACCESS       DYNAMIC
                                        RECORD KEY   EXTERNALLY-DESCRIBED-KEY
                                        WITH DUPLICATES
                                       STATUS       STATUT OF TEST.

Je fais :

Code :

1
2
3
4
5
6
7
SELECT FTST00  ASSIGN       DATABASE-MYINDEX00
                                        ORGANIZATION INDEXED
                                        ACCESS       DYNAMIC
                                        RECORD KEY   EXTERNALLY-DESCRIBED-KEY
                                        WITH DUPLICATES
                                       STATUS       STATUT OF TEST.

C'est ça ?

[Mercure]

Evite de passer par les DDS pour créer tes fichiers car ça devient de plus en plus obsolète et IBM ne fera d'ailleurs plus rien pour améliorer les choses dans ce domaine. A la place, utilise SQL autant que faire se peut pour créer tables, index, EVI, vues, alias, etc.

Tu pourras utiliser les tables et les index comme tu utilises un PF et un LF dans tes programmes HLL tels que COBOL, RPG, etc. En COBOL, place le nom de tes index sur la SELECT, comme tu l'as illustré.

Ne serait-ce que parce que les page sizes des index sont 8 fois (64ko) plus grands que ceux des LF (8ko), moi aussi je recommanderais les index. Le compilateur s'en accomodera et tu feras transiter ainsi un volume de données beaucoup plus important dans les "buffers" si index.

En outre, lors de l'utilisation de requêtes SQL directes ou dans les programmes, SQL utilisera plutôt un index qu'un LF si le choix se présente. Un LF, notamment si Select/Omit, sera traité par l'ancien moteur SQL moins performant (CQE) au lieu du relativement nouveau moteur SQE bien plus performant.

Envoyé par jaub

# Une fois que cet entrepôt alimenté, je crée des index (via des CREATE INDEX ...) sur ses tables
# J'attaque via des requêtes SQL ces tables (je suppose que mes requêtes utilisent alors ces index créés via SQL.

Ne crée surtout pas les index d'avance. Alimente d'abord tes bases, puis lances un STRDBG sec. Ensuite, fais tes requêtes sur la table (ex PF). Quand tu as fini, regardes dans la log du job les messages que SQL t'a renvoyé ( call qcmd puis <F10> ). Tu y trouveras des messages qui te diront quels index SQL a jugé bon de créer temporairement pour exécuter tes requêtes. Si les requêtes en question sont vraiment récurrentes dans le temps, crées alors le ou les index pour de bon avec CREATE INDEX.

Ceci n'est qu'un bref aperçu de ce que SQL peut apporter.

[JauB]

Envoyé par Mercure

Evite de passer par les DDS pour créer tes fichiers car ça devient de plus en plus obsolète et IBM ne fera d'ailleurs plus rien pour améliorer les choses dans ce domaine. A la place, utilise SQL autant que faire se peut pour créer tables, index, EVI, vues, alias, etc.

Tu pourras utiliser les tables et les index comme tu utilises un PF et un LF dans tes programmes HLL tels que COBOL, RPG, etc. En COBOL, place le nom de tes index sur la SELECT, comme tu l'as illustré.

Ne serait-ce que parce que les page sizes des index sont 8 fois (64ko) plus grands que ceux des LF (8ko), moi aussi je recommanderais les index. Le compilateur s'en accomodera et tu feras transiter ainsi un volume de données beaucoup plus important dans les "buffers" si index.

En outre, lors de l'utilisation de requêtes SQL directes ou dans les programmes, SQL utilisera plutôt un index qu'un LF si le choix se présente. Un LF, notamment si Select/Omit, sera traité par l'ancien moteur SQL moins performant (CQE) au lieu du relativement nouveau moteur SQE bien plus performant.



Ne crée surtout pas les index d'avance. Alimente d'abord tes bases, puis lances un STRDBG sec. Ensuite, fais tes requêtes sur la table (ex PF). Quand tu as fini, regardes dans la log du job les messages que SQL t'a renvoyé ( call qcmd puis <F10> ). Tu y trouveras des messages qui te diront quels index SQL a jugé bon de créer temporairement pour exécuter tes requêtes. Si les requêtes en question sont vraiment récurrentes dans le temps, crées alors le ou les index pour de bon avec CREATE INDEX.

Ceci n'est qu'un bref aperçu de ce que SQL peut apporter.

Re,
Alors je viens de tester le STRDBG, CALL QCMD ...

Ma requête ressemble à :

Code :

1
2
3
SELECT FICHIER1.CHAMP1
FROM   FICHIER 1 JOIN FICHIER2 ON .....

Voici le résultat :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Connexion en cours : base de données relationnelle S65F67EC.
Connexion en cours : base de données relationnelle S65F67EC.
Impossible d'extraire le fichier d'options de requête.      
Ouverture du membre QAPZPTF impossible avec UPDPROD(*NO).          
Ouverture du membre QAPZREQ impossible avec UPDPROD(*NO).          
Ouverture du membre QAPZPTF impossible avec UPDPROD(*NO).          
Ouverture du membre QAPZREQ impossible avec UPDPROD(*NO).          
Ouverture du membre QAPZPTF impossible avec UPDPROD(*NO).          
Ouverture du membre QAPZREQ impossible avec UPDPROD(*NO).          
Le plan d'accès du processeur de requêtes a été reconstruit.       
Impossible d'extraire le fichier d'options de requête.             
Message de débogage de début **** de l'optimiseur pour la requête .
Ouverture du membre QAPZPTF impossible avec UPDPROD(*NO).          
Ouverture du membre QAPZREQ impossible avec UPDPROD(*NO).          
Ouverture du membre QAPZPTF impossible avec UPDPROD(*NO).          
Tous les chemins d'accès ont été considérés pour le fichier FICHIER1.   
Tous les chemins d'accès ont été considérés pour le fichier FICHIER2. 
FICHIER1 Fichier traité en position de jointure 1.                      
FICHIER2 Fichier traité en position de jointure 2.                    
Le plan d'accès du processeur de requêtes a été reconstruit.    
Message de débogage de fin **** pour la requête .               
ODP créé.                                                       
Groupage utilisé pour la requête.                               
Connexion à la base de données relationnelle S65F67EC terminée. 
Les curseurs SQL ont été fermés.

Qu'est ce que je peux déduire de ce résultat !? mes index ont étaient les bons ? ...

[BelieveInNothing]

Envoyé par JauB

Re,
Alors je viens de tester le STRDBG, CALL QCMD ...

Ma requête ressemble à :

Code :

Voici le résultat :

Code :

Qu'est ce que je peux déduire de ce résultat !? mes index ont étaient les bons ? ...

Bonjour,
C'est normal qu'il affiche ces messages car le programme débogué (STRSQL) tente d'accéder à des fichiers existants dans une bibliothèque de type PROD.
Et donc pour éviter ces messages, il faut :

• Soit appliquer les requêtes sur des fichiers dans une bibliothèque de type *TEST.
• Soit lancer la commande : STRDBG UPDPROD(*YES).

La seconde option est déconseillée car elle va permettre de déboguer en accédant et éventuellement mettre à jour un fichier de production.

Bonne journée.

[JauB]

Envoyé par BelieveInNothing

Bonjour,
C'est normal qu'il affiche ces messages car le programme débogué (STRSQL) tente d'accéder à des fichiers existants dans une bibliothèque de type PROD.

Et donc pour éviter ces messages, il faut :

• Soit appliquer les requêtes sur des fichiers dans une bibliothèque de type *TEST.
• Soit lancer la commande : STRDBG UPDPROD(*YES).

La seconde option est déconseillée car elle va permettre de déboguer en accédant et éventuellement mettre à jour un fichier de production.

Bonne journée.

Désolé mais je ne te crois pas M. BelieveInNothing
Je rigole et je comprends maintenant le UPDPROD
Je viens de refaire des tests et en fouillant avec le F1 sur les différents messages il s'avère que mes requêtes passent par les INDEX, COOOOOOOOOL
Mais toute autre explication est la bienvenue, car ce qui me reste ambigue c'est lorsque je changerai de jointure (éventuellement sur d'autres ID) alors que faut-il faire pour les Index ? créer d'autres Index sur ces nouveaux champs de jointure ? faut-il spécifier quelque chose dans le script de création de l'Index (car je pense qu'on ne peut avoir qu'un seul Index principal sur un fichier ou quelque chose comme ça !) Sinon pour les types d'Index (on parle parfois d'Index binaire ...) que choisir et comment ?
Merci les amis

[Mercure]

@ jaub,

Ce que te dit BelieveInNothing est tout à fait sensé. Si tes tables (fichiers) sont des données de TEST, change le type de la biblio qui les contient en *TEST en passant la commande

Code :

CHGLIB LIB(MaBibDeTest) TYPE(*TEST)

Si ce sont des données de production, ne change pas le type de biblio mais lance les STRDBG avec UPDPROD(*YES). Comme BelieveInNothing, je ne recommanderais certainement pas cette dernière option et préconiserais la première pour les mêmes raisons que lui.

Envoyé par jaub

Mais toute autre explication est la bienvenue, car ce qui me reste ambigue c'est lorsque je changerai de jointure (éventuellement sur d'autres ID) alors que faut-il faire pour les Index ? créer d'autres Index sur ces nouveaux champs de jointure ? faut-il spécifier quelque chose dans le script de création de l'Index (car je pense qu'on ne peut avoir qu'un seul Index principal sur un fichier ou quelque chose comme ça !) Sinon pour les types d'Index (on parle parfois d'Index binaire ...) que choisir et comment ?

D'après ce que tu écris-là, je crois que tu n'as pas bien compris ce que j'ai expliqué dans mon post précédent. En effet, je t'ai dit de ne pas créer d'avance les index et de faire tourner d'abord tes requêtes sous debug pour savoir s'il y a lieu de créer de nouveaux chemins d'accés (index). Si un index avait été créé par SQL lors du passage de tes requêtes, tu aurais vu dans la log du passage des messages du genre CPI432C - Chemin d'accès créé pour le fichier xxx ou encore CPI432F - Suggestion de chemin d'accés pour le fichier xxx. Cela na pas avoir été le cas en voyant la log que tu as publiée parce que tu as dû créer toi-même au préalable un index qui a par hasard convenu à SQL pour effectuer tes requêtes. Ce ne sera pas toujours le cas, loin s'en faut. Fais donc toujours tourner les requêtes select avant de créer un index en supposant que tel ou tel chemin d'accés améliorera les performances de tes requêtes. Analyse la log en retour de requête et crée les index que SQL te signale s'il y a lieu. Si tu continues de créer des index à tour de bras à tâtons, tu vas vite te retrouver avec une tonne de chemin d'accés qu'il te faudra gérer d'une biblio à l'autre et qui seront pénalisants (maintenance des chemins d'accés en *IMMED) et très probablement en grande partie inutiles pour la machine.

NB Les index que tu es appelé à créer sont des index de type binaire (Binary Radix). Tu seras appelé à créer peut-être des index de type EVI plus tard, mais c'est relativement des index secondaires.

Je te recommande vivement la lecture (in us-english) de cette page sur le site de Big Blue et souviens-toi que Google est ton ami

[JauB]

Envoyé par Mercure

Ce que te dit BelieveInNothing est tout à fait sensé

Je lui ai dit que je ne le crois pas juste pour rigoler vu que son pseudo est BelieveInNothing (ne rien croire en français je suppose), donc à mon tour de ne pas le croire

Envoyé par Mercure

D'après ce que tu écris-là, je crois que tu n'as pas bien compris ce que j'ai expliqué dans mon post précédent.

Sii si je t'ai bien compris, mais ma question était : si j'ai plusieurs requêtes sur les même fichiers et que ces requêtes n'utilisent pas toujours les mêmes champs pour les jointures alors que faut-il faire pour créer les index ?

Exemple (vaut mieux qu'écrire 10000 mille lignes )

Requête 1:

Code :

1
2
3
SELECT *
FROM    FICHIER1 F1 JOIN FICHIER F2 ON F1.CHAMP1 = F2.CHAMP2

La moteur SQL m'indiquera certainement qu'il faut créer des index sur les deux fichiers FICHIER1 et FICHIER2 et ce sur les champs CHAMP1 et CHAMP2 n'est ce pas ?

Supposons que j'ai une autre requête de type :
Requête 2:

Code :

1
2
3
SELECT *
FROM    FICHIER1 F1 JOIN FICHIER F2 ON F1.CHAMP111 = F2.CHAMP222

La moteur SQL m'indiquera certainement qu'il faut créer des index sur les deux fichiers FICHIER1 et FICHIER2 et ce sur les champs CHAMP111 et CHAMP222 n'est ce pas ?
Alors dans ce cas quels sont les index à créer ?
J'éspère avoir bien expliqué ma demande

[K2R400]

En fait, chaque fois que le moteur a besoin d'un index et qu'il n'existe pas, il te crée un enregistrement dans la table QSYS2/SYSIXADV

Efface le contenu de ce fichier, et à partir de maintenant tu pourras voir dedans les index qu'il a besoin.

Mais le mieux c'est iSeries Navigator pour ce faire, il a une option pour interroger SYSIXADV. Dans Base de données, clic droit sur le nom de ta base, puis assistant de gestion des Index.
Il y a 4 options :

- Elagage des index recommandés.
Imagine, il te dit de créer un index et que tu le crées (possible directement avec iSeries Navigator aussi). Ainsi, les enregistrements dans SYSIXADV sont obsolètes, cette option permet de supprimer les entrées qui n'ont plus lieu d'être puisque l'index est créé

- Regroupement des index (Condensed advised index)
Imagine, il te dit dit de créer un index sur NUMCLI pour une requête particulière, puis sur (NUMCLI, DATCDE) pour une autre requête.
Le regroupement va permettre de garder qu'une seule entrée en te disant qu'il faudrait créer un index sur NUMCLI, DATCDE (NUMCLI seul n'a plus d'intérêt dû au partage des chemins d'accès).

- Mise à blanc :
CLRPFM QSYS2/SYSIXADV ou DELETE * FROM QSYS2/SYSIXADV comme tu préfères.

- Assistant
--> Il te dit les index à créer (mieux vaut utiliser le regroupement)

Perso, je commence par faire un élagage, puis un regroupement (qui appelle ensuite l'assistant), sinon à la mimine :
SELECT * FROM QSYS2/SYSIXADV

[BelieveInNothing]

Envoyé par K2R400

En fait, chaque fois que le moteur a besoin d'un index et qu'il n'existe pas, il te crée un enregistrement dans la table QSYS2/SYSIXADV

Bonjour,
Il me semble que la table QSYS2/SYSIXADV n'existe qu'à partir de la version V5R4.

Pour plus de lecture, tu peux voir ici

Merci.

[JauB]

Envoyé par K2R400

En fait, chaque fois que le moteur a besoin d'un index et qu'il n'existe pas, il te crée un enregistrement dans la table QSYS2/SYSIXADV

Efface le contenu de ce fichier, et à partir de maintenant tu pourras voir dedans les index qu'il a besoin.

Mais le mieux c'est iSeries Navigator pour ce faire, il a une option pour interroger SYSIXADV. Dans Base de données, clic droit sur le nom de ta base, puis assistant de gestion des Index.
Il y a 4 options :

- Elagage des index recommandés.
Imagine, il te dit de créer un index et que tu le crées (possible directement avec iSeries Navigator aussi). Ainsi, les enregistrements dans SYSIXADV sont obsolètes, cette option permet de supprimer les entrées qui n'ont plus lieu d'être puisque l'index est créé

- Regroupement des index (Condensed advised index)
Imagine, il te dit dit de créer un index sur NUMCLI pour une requête particulière, puis sur (NUMCLI, DATCDE) pour une autre requête.
Le regroupement va permettre de garder qu'une seule entrée en te disant qu'il faudrait créer un index sur NUMCLI, DATCDE (NUMCLI seul n'a plus d'intérêt dû au partage des chemins d'accès).

- Mise à blanc :
CLRPFM QSYS2/SYSIXADV ou DELETE * FROM QSYS2/SYSIXADV comme tu préfères.

- Assistant
--> Il te dit les index à créer (mieux vaut utiliser le regroupement)

Perso, je commence par faire un élagage, puis un regroupement (qui appelle ensuite l'assistant), sinon à la mimine :
SELECT * FROM QSYS2/SYSIXADV

J'ai fait comme tu as dit : je suis allé sur iSeries Navigator, sur mon schéma je fait clique droit ==> Assistant de gestion des Index ==> Elagage des index recommandés, mais là rien ne se passe !

Est ce que cette option Elagage des index recommandés crée les index recquis ou quoi ? sachant que lorsque je fais Assistant de gestion des Index cela m'affiche beaucoup d'index à créer !
P.S : je n'ai pas l'option Regroupement des index que tu as cité. On est sur la V5R4.

[punkoff]

Bonjour,

Non l'élagage ne crée pas d'index.

Concernant l'écran de suggestion des indexs, il faut vraiment prendre le temps de l'analyser et ne surtout pas créer tout ce qu'il te recommande (sinon je me retrouverai a devoir créé plusieurs milier d'index ..)

Bref il faut recouper les suggestions avec les MTI et les requêtes sql.