Augmenter la taille limite d'une vue DB2

Bonjour,

J'ai fait une requête SQL très longue et très complexe. Je dois ABSOLUMENT la mettre dans une vue. Mais je reçois ce message d'erreur qui dit que je ne peux pas faire de vue plus grande que 10 000 octets. C'est trop sévère pour ma requete :(

Je ne veux pas envisager l'idée de faire des vues intermédiaires. Ce serait trop de travail corriger la requete....

Est-ce possible d'augmenter la taille de SYSVIEW ? Comment ?

Avez-vous une autre astuce pour contourner mon problème ?

Un grand merci d'avance...

Citation:

---

Message : [SQL0178] Le texte d'expression de requête pour la vue de est trop long. Cause . . . . . : Le texte d'expression de requête associé à la vue de a une longueur supérieure à 10000 octets et n'entre pas dans la vue catalogue SYSVIEWS. Le texte de l'instruction ne peut donc être enregistré dans les vues catalogue système. La colonne VIEW_DEFINITION de la vue catalogue SYSVIEWS contiendra une valeur indéfinie pour cette vue. Que faire . . . : Aucune action de reprise n'est nécessaire. Si les vues catalogue système doivent contenir la totalité du texte, recréez la vue en faisant en sorte que la longueur de l'expression de requête soit inférieure ou égale à 10000 octets.

---

d'après le message d'erreur la vue est bien créée mais t'auras pas accès au ddl
c'est tout

Bonjour,

Pourrais-tu nous préciser la version de DB2 utilisée ?

Parce que pour la longueur du statement, sur DB2V10 sur Z, j'ai trouvé un CLOB de 2M multilignes (donc pas de réelle limite) et pour la V9 j'ai un Varchar de 1500 là aussi multilignes. En LUW dès la V9r7 il y a le CLOB...

Ensuite, c'est un avis personnel par expérience, même en data mining, quand il y a des reqûetes aussi longue pour des vues il y a en général un problème de conception (j'ai vu des exceptions, mais rare), donc es-tu sûr du besoin ?

De plus, il est peut-être possible de raccourcir la requête en utilisant des alias.

Bonjour,

Pour commencer, je vous remercie pour vos réponses.

Je n'arrive pas à consulter la vue créée. je reçois le message d'erreur suivant lors d'un SELECT :

Code:

---

1 2 3 4 5 6 7 8

> SELECT * FROM LPT.LSTART   Etat SQL : 58004 Code fournisseur : -901 Message : [SQL0901] Erreur système SQL. Cause . . . . . : Une erreur système SQL est intervenue. L'instruction SQL en cours ne peut s'exécuter avec succès. Cette erreur n'empêchera pas cependant l'exécution des instructions suivantes. Il se peut que des messages précédents aient signalé un incident lié à cette instruction SQL et que SQL n'ait pas correctement diagnostiqué l'erreur. Les messages précédents indiquent peut-être qu'un incident s'est produit sur cette instruction SQL, mais que le diagnostic n'a pas été correctement effectué par SQL. L'ID message précédent est CPF4204. Une erreur interne de type 3002 s'est produite. S'il s'agit d'une précompilation, le traitement s'interrompra sur cette instruction. Que faire . . . : Consultez les messages précédents pour déterminer si un incident s'est produit sur cette instruction SQL. Pour consulter les messages, utilisez la commande DSPJOBLOG en mode interactif, ou la commande WRKJOB pour visualiser la sortie d'une précompilation. Un programme d'application recevant ce code retour peut tenter de lancer de nouvelles instructions SQL. Corrigez les erreurs éventuelles et renouvelez votre demande.   L'instruction mise en évidence a échoué, entraînant l'interruption du traitement

---

Ensuite, je suis sur AS400 en version V6R1, (il y a peut être moyen d'encore préciser exactement la version du service qui fait tourner la BD, mais je ne sais pas comment en fait pour le savoir). J'ai vraiment beaucoup d'espoir sur votre remarque...


Enfin, je comprends bien votre remarque sur la pertinence d'une aussi grosse requête et je m'y attendais. Pour essayer de vous expliquer, j'ai une BD avec 200.000 articles existants et des dizaines de paramètres se rapportant aux articles. Le modèle est relativement bien pensé avec de petites tables contenant uniquement ce à quoi on s'attend en les voyant. De plus, entre toutes les tables concernant les articles j'ai parfois des relations 1-N...

exemple concret : un article peut avoir plusieurs fournisseurs, avec un tarif achat spécifique par fournisseur, un tarif achat quantitatif spécifique par fournisseur, un tarif de vente unique, mais un historique des Tarifs de vente, ]historique des Tarifs achat (pour le calcul du prix de revient moyen pondéré etc),... Ca fait un gros paquet de jointures, c'est chaud. Et ça, ce n'est que l'ERP. Je dois absolument faire une vue sur ces tables, car après, j'y accède depuis SQL serveur avec la technique des serveurs liés, pour pouvoir faire encore d'autres jointures avec d'autres BD sur d'autres systèmes (bd documentation produit, bd vente en ligne) où là aussi, j'ai faits des vues.

C'est effectivement très lourd mais absolument nécessaire car le service produit veut absolument exporter les articles en temps réel dans un unique excel contenant toutes les infos d'un articles sur une seule et unique ligne, et dans un seul fichier. Pas possible de travailler sur une BD copie à J-1 puisque ce qu'ils veulent c'est les données de prod, s'il y a une erreur détectée à l'export ils doivent la voir le plus possible et la corriger.

Sans çà, ce serait eux qui devrait consolider les données des différents export (et faire l'équivalent des jointures avec des fichiers excel et des RECHERHEV), le truc qu'ils veulent éviter quoi :)

Voilà toute ma misère. Je transforme donc des relations 1-N en relation 1-1 en faisant plusieurs sous requêtes dans mon FROM. je remonte dans mon SELECT (pour ne faire qu'une seule ligne) plusieurs fois les données d'une même tables (Tarif par exemple) en les renommant d'un préfixe différent : FOURNISSEUR_1_PRIX_ACHAT_BRUT_QUANTITE_0, FOURNISSEUR_1_PRIX_ACHAT_BRUT_QUANTITE_1,
FOURNISSEUR_2_PRIX_ACHAT_BRUT_QUANTITE_0,
Forcément, ça fait un paquet de colonnes...

Je vous passe le chapitre ou les gars me fournissent le fichier exporté et modifié et où il faut alors l'importer :cry:

Pour ma requete SQL d'export, j'ai donc un vue dans la BD de chaque système, plus une requete qui refait les jointures entre toutes ces vues. Si je dois encore faire des sous-vues dans les vues à cause des limites du SGBD, :aie: :aie: :aie: no comment ...

désolé pour la tartine,

nico

Bon, j'avais trouvé la restriction des 10000 octets dans la doc de DB2 V6R1, mais je m'étais dit "nan, spapossible !", et si...

Alors déjà, pour des question de maintenabilité et évolutivité, je pense qu'il faut faire la sérialisation ("transforme donc des relations 1-N en relation 1-1") le plus tard possible. En effet d'après ton exemple et la structure des views, tu as dû fixé une limite au "N". concrètement, je suppose que ton exemple explicite les tranche de prix des fournisseurs en fonction des quantités (le principe des tarifs de gros dégressifs), or si tu considères qu'il y a maximum 5 tranches (pour l'exemple) et que tu prévois 5 colonnes dans la vue finale, le jour où un des fournisseurs te pond une sixième tranche, ben... ça marche plus... (et il doit y a voir le même problème avec la liste de fournisseurs par article)

Donc dans l'idéal, je conseillerais, malgré tes remarques, de faire la dernière action de sérialisation dans excel : d'une part, cela peut être -presque- invisible pour l'utilisateur final (en vba à l'ouverture et on surpprime toutes les données de travail juste avant l'affichage, ça fait juste ramer le poste :D ). D'autre part, le vba a déjà des fonctions toutes prêtes (comme le RECHERCHEV) qui simplifient grandement les traitements. De plus, cela déportera une partie de la charge sur le poste client (et soulagera les sgbds). Pour finir, les limites de l'algo seront intrinsèquement les limites d'excel, donc si elles sont atteintes un jour alors le soucis ne proviendra pas des traitements mais de la solution finale choisie (donc c'est à cause des choix utilisateurs -MOA- et non développeurs -MOE-).

Si tu ne veux pas faire ça dans excel, il faut quand même essayer de faire cette sérialisation le "plus tard possible", donc si possible dans sqlserver.

Et si tu veux quand même garder ton architecture telle qu'elle est, j'ai bien peur que "des sous-vues dans les vues à cause des limites du SGBD" soit la seule solution... no comment, action !


Petit détail, je ne trouve pas la limite de taille des noms de colonnes en V6R1, mais en V7 c'est 18 caractères, donc je suppose que c'est au max 18 en V6 voire moins. Alors j'espère que le "FOURNISSEUR_1_PRIX_ACHAT_BRUT_QUANTITE_0" est un exemple et qu'en fait il y a un nom le plus court possible (pour éco de la place) du genre F1PABQ0 ;)

Bonsoir,

Merci pour ta réponse.

Je ne savais pas qu'on appelait "sérialisation" cette technique pour aplatir les lignes en 1-1. Je connaissais ce terme dans un contexte hors-sgbd pour écrire des objets en fichier. Tu viens de m'apprendre qqc, merci pour cette info.

Ta réflexion sur les limites que j'ai du imposer à ma vue quant au nombre de fois que je sortais un jeu de tuple d'une table liée 1-n est très intéressante. J'ai effectivement été contraint de décider d'une limite bloquante. J'ai choisi de sortir le même nombre que notre ERP est capable de supporter (au cas par cas, table par table). comme c'est un programme AS400, il a beaucoup de limite sur les quantités. Elles clopent +/- bien avec la réalité métier donc pas trop gênant. Comme l'ERP est un peu le système directeur, s'il permet par exemple uniquement 5 prix quantitatifs de vente, et bien j'ai reporté 5 fois toutes ces colonnes dans ma vues. On injecte toujours les données d'abord dans l'ERP. les systèmes liés héritent de ces données de bases, et n'ajoutent rien au données de bases (jamais un 6ème prix), par contre ils ajoutent des tas d'autres données complémentaires non dispo dans l'ERP : chemin vers fichiers photos, documentation,....

Bien vu aussi pour les noms des colonnes :ccool: Effectivement c'était pour l'exemple, dans la réalité ce sont des noms très abrégés et difficiles à interpréter et deviner :?

il y avait encore une contrainte dont je n'avais pas parlé. le programme AS400 ne stocke pas toutes les données de la fiche article... il en calcule beaucoup. héhéhé !!! En refaisant les calcules sur le côté pour essayer de les intégrer dans mes requêtes SQL, j'ai découvert que le système faisaient des arrondis à 2 décimales à tous les niveaux. Au secours quoi!!! J'ai passé des heures pour faire les requetes qui recalculent avec les mêmes erreurs d'arrondi... Je me suis vraiment battu avec la machine.

Bon enfin j'ai lu ton info sur les limites. C'est vraiment malheureux.
Je suis foutu alors... Je trouve que ce genre de limite datent d'une autre époque. C'est plus possible de travailler comme ça. Je perds trop de temps.

Pour ta suggestion avec excel c'est ce que je faisais au début... des fichiers avec un onglet par table et des recherches internes entre onglets cachés, avec un super onglet (visible) reprenant la totale. Mais pour les utilisateurs, c'était pas très pratique. Ils me modifiaient statiquement des données provenant d'autres onglets. Ça complexifiait les choses et lorsqu'ils rajoutaient eux-même leurs petites formules et pour un tarif supérieur à 10.000 les performances devenaient difficiles à supporter.

En voyant le temps que je passais à faire du support avec excel en supportant avec eux les performances, je me suis vite dirigé vers l'idée un d'une super vue globale. D'abord j'avais tout fait en SQL server. Mais là, au niveau des perfs... j'étais vraiment honteux.... il fallait 3h pour 1 export 8O

Après en avoir parlé à des gens plus malins que moi, il s'agirait du driver Oledb (utilisé par les serveurs liés) de ibm qui ne pourrait pas faire mieux?!? J'ai beaucoup chipoté avec des paramètres de type "prise de tête" pour changer le niveau d'isolation etc... mais pas moyen d'améliorer vraiment les choses. (PS: en JDBC par contre, ca allait hyper vite, mais j'ai jamais réussi à faire un serveur lié MSSQL qui exploitait le driver JDBC donc j'ai abandonné).

La conclusion semblait évidente : pousser dans chaque système sa propre vue pour que chaque système traite lui-même sa partie avant d'envoyer un résultat prémaché à sql server. Mais c'était sans compter mon problème du jour :cry::cry::cry:

Action me dis-tu... :D la seule action à laquelle je pense en ce moment c'est :massacre: tuer :massacre: tuer :massacre: tuer :massacre:...

Non sérieusement, le coup des sous-vues ça va être ingérable à entretenir en terme de code. en cas de modif et tout ça... J'ai déjà plusieurs codes sur plusieurs systèmes. ca devient trop mal foutu.

Ton idée d'exporter tout sans rien filtrer semble intéressante, c'est un peu ma seule alternative entre le tout mssql et le tout db2. Maintenant, je perds quand même toutes les optimisations que le système DB2 fait en interne sur l'AS400 sans rien dire (une compilation ou précompilation je crois avec une vue non?). Et je vais m'exposer au risque du problème de perf déjà rencontré avec sql server. Mais pour tester ça, je dois encore porter un code monstrueux de DB2 vers TSQL... Cette option va me couter trop cher.


Et si je tapais le code dans un procédure, une fonction ou un truc comme ça ? Il n'y a pas moyen de détourner un autre mécanisme ?

Sinon en dernier, je peux encore simplement tenter ré-exécuter la méga requete avec un INTO dans un table DB2 déclenché par un artifice. Mais bonjour la cochonnerie lorsqu'il faudra l'appeler depuis mssql... En plus en test, si ma requete passait à merveille dans cwbundbs.exe, via le driver OLEDB dans un VBS il me fait une erreur de curseur. J'avais déjà rencontré ce cas, c'était le type d'une colonne qui était foireux pour le datarowset de microsoft... je devrai retester toute mes colonnes une par une.

Je trouve ça horrible d'être coincé par ce genre de détail de bas niveau alors qu'il y a tant à faire côté haut niveau, avec la partie métier. De plus, les non-initiés n'y comprennent absolument rien, et voient d'un très mauvais œil les temps de développement que se multiplient par 2, 3,... ça coute.

Bon j'arrête... râler dans ce poste ne me fait pas gagner du temps non plus :?

Merci pour tes infos et cet échange, c'était intéressant de pouvoir en parler. Je garde ta remarque sur le concept de reporter la "sérialisation" le plus tard possible sous le coude. Je vais continuer de gamberger en espérant trouver une alternative à la fois rapide, la plus performante possible et compacte (avec le moins possible de sources de codes différentes).

Je reste preneur pour toutes idées constructives.

a+

Bon déjà, on parle de DB2 V6R1 sur AS/400 : les limites techniques sont clairement d'un autre temps...

Ensuite pour "sérialisation", j'ai un peu conceptualisé ton problème : la sérialisation étant à la base la "mise en série" donc en ligne des données d'un objet pour faciliter son échange par flux fichier ou réseau.

Quelques remarques en vrac :

Je ne connais pas vraiment la V6R1, donc je ne sais pas ce qui est possible dans tout ce qui est trigger et procédure stockées, mais je pense que c'est à creuser.

Pour le driver Oledb, il n'y a pas un driver ODBC ? (les premiers résultats google me font penser que si, donc je te laisse chercher), ça devrait ('fin j'espère, avec AS400 et V6R1 je ne suis sûr de rien) être plus efficace.

Ensuite, je suppose que le besoin est ponctuel, mais est-il "sur demande" ? je m'explique : quand les utilisateurs ont besoin de l'export, t'appellent-ils ou ont-il un bouton sur leur poste qui le génère ?
Dans le cas où c'est sur demande : il n'y a pas moyen de faire un traitement batch d'extraction des données côté as400 qui génère un fichier ou charge les données voulues dans une table temporaire ?
Si possible, découper les traitements en plusieurs actions indépendantes pourrait simplifier les choses, et ces actions peuvent s'enchainer soit manuellement soit par trigger ou script.