| 
DB2/400 nouveautés liées à la version 4.30 : - gestion des ALIAS un ALIAS permet de renommer un fichier (lui donner un nom long) ou préciser un membre pour un fichier multi-membres. CREATE ALIAS MABIB/MBR2_ALIAS FOR MABIB/FIC1P1 (MBR2) mettre à jour MBR2_ALIAS revient à mettre à jour MBR2 dans FIC1P1 ATTENTION : DROP TABLE nom-alias détruit le fichier PHYSIQUE il faut écrire DROP ALIAS pour supprimer l'ALIAS Un alias portant sur un fichier inconnu, peut exister. |
|
Limitations : + n'est pas supporté pas ALTER TABLE, si c'est un ALIAS de membre. + n'est pas supporté par la clause FOREIGN KEY (int. référentielle), si c'est un ALIAS de membre. + CREATE TABLE ne peut pas créer une table ayant le même nom qu'un alias + idem pour CREATE INDEX et CREATE VIEW. + DROP TABLE, GRANT et REVOKE ne sont pas admis pour un alias de membre on entend par ALIAS de membre, un alias indiquant un membre particulier |
|
- Sous sélection admise dans l'ordre UPDATE la notion de sous-sélection permettait de mettre un ordre SELECT dans la clause WHERE d'un ordre SQL. SUPPRIMER les clients sans commande : Delete from client C where not exists ( select * from commande where nocli = C.nocli ) supprimer les commandes quand la clause SELECT ne trouve pas de ligne (NOT EXISTS) ayant le n° de client lu dans le fichier client (C.nocli) Cette synatxe est maintenant acceptée dans la clause SET de UPDATE UPDATE command C set priha = (select pritarif from article WHERE codart = C.codart ) WHERE priha = 0 |
|
mettre à jour le fichier command, mettre dans priha la valeur retournée par la clause select qui dit (je vais chercher le pritarif dans le fichier article, de la ligne ayant le code article lu dans le fichier commande ) UPDATE recap R set SALAIRAN = (select sum(salair + primes) from personp1 where matricule = R.matricule) mettre à jour le fichier recap, mettre dans salairAN la valeur retournée par la clause select qui dit (je vais chercher la somme du calcul (salair * primes) dans le fichier du personnel des lignes ayant le matricule lu dans le fichier RECAP ) |
|
l'assignation de valeurs peut se faire de deux manières: UPDATE fichier set (col1, col2) = (select zone1, zone2 from fichier2 where ... ) ou sous la forme UPDATE fichier set col1 = (select zone1 from fichier2 where .... ) , set col2 = (select zone2 from fichier3 where .... ) |
|
Les nouveaux Index EVI (Encoded Vector Index) à l'origine était l'index b-tree : +-------+ de A à N |AN - OZ| de O à Z +-------+ / \ / \ +-------+ de A à M |AM - N.| (tout ce qui est Nxxx) +-------+ / \ +------+ (tout ce qui est NAxxx) | A. | ____________ +------+ |TES=878787| <-- NANTES / \ / +------+ | N. | +------- ____________ \ |CY =124578| <-- NANCY |
|
Ces index fonctionnent très bien quand il s'agit de retrouver un petit nombre de clés dans un grand nombre d'enregistrements (type CHAIN) mais ils sont assez lents si vous réalisez une requête retournant 80 % des enregistrements, particulièrement lors des tris. En effet les enregistrements doivent être retournés dans l'ordre des clés et ils sont stockés dans physiquement sur le n° de RANG(dans le physique) Vous multipliez alors les E/S disque sauf si vous réorganisez souvent vos fichier par RGZPFM KEYFILE(xxx) ^ en indiquant le nom de l'index le plus fréquement utilisé ici ---! Certains SGBD utilisent la technique des index bitmap |
|
soit la table suivante : l'index bitmap associé sera ##################### rang # client ville # valeur bitmap ##################### ...................... 1 # 1 NANTES # : NANTES : 10000100 : 2 # 6 ANGERS # : ANGERS : 01000000 : 3 # 3 RENNES # : RENNES : 00100010 : 4 # 7 CHOLET # : CHOLET : 00010000 : 5 # 8 BREST # : BREST : 00001000 : 6 # 5 NANTES # : VANNES : 00000001 : 7 # 4 RENNES # :........:...........: 8 # 2 VANNES # 12345678 # # ##################### On place un "1" pour chaque enregistrement ayant cette clé à la position du n° de rang pour NANTES les enregistrements 1 et 6. |
|
Cette technique pose plusieurs problèmes : 1/ la place utilisée peut-être importante pour des clés composées. 2/ la maintenance d'une clé génère DEUX E/S (sur l'ancienne clé et sur la nouvelle) L'AS/400 n'utilise pas les index bitmap, par contre la technologie bitmap est utilisée pour gérer vos requêtes avec des tests depuis la V4R20. Il utilise un index B-tree pour chaque critère et construit un nuage de point (bitmap) sur chaque résultat, et applique une fonction booleènne AND/OR sur les deux. le résultat indique par un "1" la liste des enregistrements ayant vos un (OR) ou deux (AND) critères vrais. NANTES ou ANGERS fournit 10000100 puis 01000000 11000100 ==> les lignes 1,2 et 6. |
|
EVI pour finir, qui est un concept Rochester (il y a un brevet), l'AS/400 étant le premier à l'utiliser. EVI est une utilisation avancèe des index Bitmap Vecteur ##################### +-------------+ rang # client ville # ........................... | code | rang | ##################### : Table des symboles : +------+------+ 1 # 1 NANTES # :.........................: | 1 | 1 | 2 # 6 ANGERS # :Valeur:code:Deb:Fin: nbre: | 2 | 2 | 3 # 3 RENNES # : : : : : : | 3 | 3 | 4 # 7 CHOLET # :NANTES: 1 : 1 : 6 : 2 : | 4 | 4 | 5 # 8 BREST # :ANGERS: 2 : 2 : 2 : 1 : | 5 | 5 | 6 # 5 NANTES # :RENNES: 3 : 3 : 7 : 2 : | 1 | 6 | 7 # 4 RENNES # :CHOLET: 4 : 4 : 4 : 1 : | 3 | 7 | 8 # 2 VANNES # :BREST : 5 : 5 : 5 : 1 : | 6 | 8 | # # :VANNES: 6 : 8 : 8 : 1 : +-------------+ ##################### :......:....:...:...:.....: |
|
Le vecteur contient un poste par enregistrement, la position donnant le n° de rang, MAIS on indique un code et non une valeur de clé. tout cela lève les deux désavantages des index bitmap. On indique en plus une table des symboles qui contient - la correspondance entre chaque valeur de clé et son code associé - des statistiques destinées au "Query Governor" l'optimiseur de requêtes Il faut simplement indiquer le nombre de valeurs différentes lors de la création afin de savoir s'il faut créér un vecteur sur 1,2 ou 4 octets si vous ne connaissez pas ce nombre de valeurs différentes SQL va les rechercher pour vous et la création de l'index sera un peu plus longue CREATE ENCODED VECTOR INDEX on fichier(clé1, clé2, ...) FOR x DICTINCT VALUES |
|
On parle de place occupée divisée par entre 3 et 16 de temps de construction divisé par 1,2/1,5 de temps de réponse divisés (jusqu'à 10 fois) --> tout cela reste à vérifier sur VOTRE BASE ! Mais quand même, les tests du lab sont les suivants : sur un 53S (4 voies) avec une table de 255 GO sans index : 30 minutes b-tree : 18 minutes EVI : 0,58 minutes (il n'y a pas d'erreur de frappe !) ATTENTION : les index EVI sont destinés à SQL (et QUERY, QM, ...) ILS NE SONT PAS UTILISABLES PAR PROGRAMME (CHAIN, READ, etc) il nous faudra donc probablement faire cohabiter les deux ! |
|
Quelques tests concernant les index EVI sur un S10 (70 CPW) avec 350 Mo de mémoire centrale et 14 Go disques chargés à 70 %. les tests portent sur un fichier de 590.552 enregistrements nbr de ! lignes test A/ retrouver un petit nombre de lignes (clé = valeur) ! 1.022 ! test B/ retrouver un grand nombre de ligne (clé <> de valeur)! 589.530 ! test C/ 2 tests (<> de ..) reliés entre eux par AND ! 429.792 ! test D/ 2 tests (= à ..) reliés entre eux par OR ! 160.767 les temps estimés sont donnés par le résultat de la commande STRDBMON. ......................................................................... : Tous ces tests donnent un temps estimé de 61 secondes sans index. : :.......................................................................: |
|
Avec des index B-TREE rappel Avec des index EVI nbr de ...................... lignes ...................... : : : : : : : A : 1 s : 1.022 : A : 11 s : ........:............. ........:............. : : : : : : : B : 30 s : 589.530 : B : 52 s : ........:............. ........:............. : : : : : : : C : 61 s : 429.792 : C : 52 s : :.......:............: :.......:............: : : : : : : : D : 61 s : 160.767 : D : 52 s : :....................: :....................: On voit bien que ces index sont avantageux avec des gros volumes de données (et probablement des clés longues, ici les clés étaient de 8c.) Dernier détail, taille des index : b-tree 12.599 Ko et 8.667 Ko EVI 1.957 Ko et 745 Ko |
|
Ce que dit le laboratoire est le suivant : avec des petits volumes de données, EVI peut être un peu plus lent à l'éxécution (+10, +20 %) par rapport à l'index b-tree "parfait" mais : ° les temps de construction et la place occupée sont plus avantageux. ° avec in index b-tree il faut l'index EXACT. par exemple si vous faites un requête triée par client, dept , type, il faut un index avec ces TROIS CLEFS. avec EVI, si vous avez a/ un index par client b/ un index par dept c/ un index par type les trois seront utilisé en technique bitmap. il est ainsi beaucoup plus facile de préparer des index faisant face à une MAJORITE de cas (requêtes utilisateurs particulièrement). |
