Discussion :

[Sankasssss]

Bonjour,

j'ai cherché à faire une requête update avec sous sélection pour remplir une colonne mais cette requête met à mal notre AS400.
Voici la requête concerné :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
update rembtest.amuaide as ds0 set datefin = (
     select
     max(ds1.dsas0dfde)
     from clilandta.dsas000 as ds1
     where
     ds0.ni = ds1.dsas0n010
     and ds1.dsas0dec like ('1%') and ds1.dsas0eta = '3  '
     and ds1.dsas0sera = 'SAN' and ds1.dsas0aide like '%AMU%'
     and ds1.dsas0ddde < 20110700 and ds1.dsas0dfde > 20110000
)
;

Quand je dis qu'elle met à mal l'AS400, c'est qu'elle utilise 60% de l'AS400 pendant très longtemps.
La table à mettre à jour ne contient que +- 2500 enregistrements, elle est composée de 6 colonnes et personne ne l'utilise à part moi.

Après plus d'une minute d’exécution, j'ai fait un select sur la table d'update pour voir le nombre de ligne déjà mise à jour :

Code :

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

SELECT COUNT(*) FROM rembtest.amuaide WHERE datefin > 0

J'en étais à un peu moins de 100 lignes affectées.
J'ai pu me rendre compte en actualisant plusieurs fois le résultat que la requête update affectait environs une ligne par seconde

Donc j'aimerais savoir ce que j'ai fais de mal dans ma requête qui ne me semble pas compliquée pour avoir un tel résultat

[bernard59139]

Bonjour

A priori, et avec les info que tu donnes, je dirais que c'est le sous-select qui consomme les ressources.

Sur la table clilandta.dsas000 AS ds1, je vérifierai qu'un index existe sur

• dsas0eta
• dsas0sera
• dsas0ddde
• dsas0dfde
• et sur dsas0dec

toutes les colonnes n'ont pas besoin d'être dans un index, mais cela dépend des données.

a+

[pdz74]

Bonsoir,

Le plus important c'est le prédicat de corrélation. Vérifie la présence d'un index sur ds1.dsas0n010. Sans cela, oups... Sachant que le meilleur index possible serait un index multi-colonnes avec ds1.dsas0n010 en première colonne et les autres colonnes citées par bernard59139 ensuite. Si possible, les colonnes avec prédicat d'égalité d'abord, ensuite les colonnes avec like, > ou <. Evidemment, c'est la théorie, ensuite tout dépend de la grosseur des colonnes, de leur pouvoir discriminant, ..., bref des différentes statistiques.

A contrario, si tu as plusieurs index mono-colonne sur les différentes colonnes de la requête, le risque est que DB2 fasse du multiple-index, ce qui, dans le cas présent, s'avèrerait certainement désastreux.

Je ne suis pas spécialiste as400 (perso, c'est zos), mais j'imagine que tu peux faire un explain de ta requête, cela devrait te mener vers la bonne piste.

Tiens nous au courant.

Bon week.

[bernard59139]

scromeleu, j'avais laissé de coté la colonne ds1.dsas0n010
merci pour la précision

[Sankasssss]

Tout d'abord un très grand merci pour votre intervention à tout les deux .

Voici le suivi, en effet il n'y a pas d'index sur ces colonnes.
Malheureusement il ne s'agit pas de table provenant de notre société et je ne peux y toucher.
Pour faire ce que vous me suggériez, j'ai copié la table dans une bibliothèque qui nous appartient. De la j'ai réessayer sans mettre d'index pour test et là miracle, plus aucun problème. La requête est effectuée quasi immédiatement.

Y aurait-il un problème pour faire des liaisons entre des bibliothèques différentes?

[K2R400]

Y aurait-il un problème pour faire des liaisons entre des bibliothèques différentes?

Que veux-tu dire par là ?

Si tu ne peux pas ajouter d'index (d'ailleurs je ne vois pas pourquoi, même si cette table comme tu dis ne t'appartiens pas) vérifie que ta table ne possède pas trop d'enregistrements supprimés, ils sont quand même lus lors d'une requête. Ensuite, duplique la table QSYS/QAQQINI dans QUSRSYS et mets la valeur à *YES au lieu de *DEFAULT pour la ligne IGNORE_DERIVED_INDEX et tout va rentrer dans l'ordre.

[Sankasssss]

Ce que je veux dire c'est que lorsque j'essaye de faire un update d'une table se trouvant dans la biblio rembtest avec une sélection d'une table qui se trouve dans la biblio CLILANDTA, cela prend énormément de temps alors que quand c'est au sein de la même biblio il n'y a plus de problème...

Si tu ne peux pas ajouter d'index (d'ailleurs je ne vois pas pourquoi, même si cette table comme tu dis ne t'appartiens pas)

C'est parce que le contrat de maintenance du logiciel stipule que nous ne touchons pas à leur environnement.

vérifie que ta table ne possède pas trop d'enregistrements supprimés, ils sont quand même lus lors d'une requête.

L'application ne supprime jamais d'enregistrement dans cette table.
Par contre il est vrais qu'il y a énormément d'enregistrement.
Mais je ne comprend pas qu'en copiant la table dans l'autre biblio, et avec l'intégralité de ces lignes avec un CPYF, cela améliore grandement les performance. C'est pour cela que je me posais la question précédente :

Y aurait-il un problème pour faire des liaisons entre des bibliothèques différentes?

Je testerai dès demain le changement de IGNORE_DERIVED_INDEX dans QUSRSYS, j'espère que tu vises juste
Merci pour ton intervention

[pdz74]

Je ne connais pas AS400, donc je ne me prononcerai pas sur des soucis de bib.

Par contre, concernant le fait que tu ne doives pas toucher à du DDL livré par un presta extérieur. Toutes les sociétés achètent des logiciels à l'extérieur. Les seuls objets intouchables, ce sont les vues et les tables, cad ce qui est accédé dans les programmes. Par contre, tout le reste, tu es libre d'en faire ce que tu veux, par exemple changer le nom des databases, des tablespaces, des stogroups, des paramètres techniques, ... Et surtout, si tu te rends compte qu'il manque des index, il est super important de les créer et d'en prévenir le fournisseur : loin de mettre en doute une quelconque clause juridique d'un contrat, tu leur rendras un fier service car il y a de fortes chances pour que cet index puisse servir à d'autres clients du même fournisseur : tu le verras donc apparaitre dans la version suivante livrée par le presta. Donc, surtout n'hésite pas à intervenir sur du DDL livré de l'extérieur. Par expérience, je peux te dire que de nombreux logiciels développés sous DB2 par certaines sociétés, le sont sans l'apport de DBA et des fois, ça craint...

Faut faire vite et pas cher, la qualité, basta !!! Tu me diras, c'est également la nouvelle devise de ma société, mais ceci est un autre problème...