Discussion :

[JauB]

Bonjour tout le monde,

on a un progiciel développé en COBOL et utilisant une base DB2 sous I5. le progiciel ne couvre pas la partie "GENERATION d'ETATS"! donc on est amené à développé nos propres états en java et en attaquant la base DB2. Toutefois on ne veut pas toucher à la base de production et donc on pense à dupliquer les tables pour faire nos éditions. Sachant qu'on gére un volume énorme de données. le progiciel va être utilisé par toutes les régions du pays. et dans un but d'améliorer les temps d'éxecution quel est à votre avis le meilleur moyen pour créer nos propres tables et les alimenter par les données de la base du progiciel pour avoir des temps d'éxecution satisfaisants?
la base ne serait utilisée qu'en mode consultation et pas de mise à jour.

[Mercure]

Si je comprends bien ce que tu demandes, tu veux créer un environnement de test pour les éditions ?

Dans ces conditions, puisque tu ne vas faire que des consultations de tables, ce qui va pénaliser les temps de traitement ce sont essentiellement les prédicats WHERE et les ORDER BY, voire les tris internes utilisés dans vos éditions.

Je commencerais par optimiser ma base de production en lançant tous les travaux interactifs et batch sous debug (STRDBG) pour savoir quels index SQL a créé lors des traitements. Je consulterais ensuite la log de chaque travail pour le savoir. C'est indiqué clairement dans la log sous forme de messages. Je créerais alors les index en question avec CREATE INDEX (ou via fichier logique), ce qui éviterait ensuite que SQL les crée à chaque exécution du programme en pénalisant du coup les temps de traitement.

Compte tenu qu'il n'y a pas de mise à jour de tables, je n'irais donc pas créer un environnement de test spécifique aux éditions, d'autant plus qu'il faudra bien que vous mettiez vos éditions en production tôt ou tard.

Si malgré tout vous voulez créer un environnement de test, les index auront donc déjà été créés et vous pourrez les reporter facilement dans vos bibliothèques de test.

[JauB]

mais je préfére passer par des tables temporaires vu que ces tables seront alimentées par BATCH et donc le lendemain je n'aurai que les données dont j'aurai besoin ( + d'autres données) et je n'aurai pas à attaquer toute les tables de production! car ce n'est plus du tout envisageable d'attaquer directment les tables de prod!
Merci

[jab]

Si j'ai bien compris, il s'agit de travailler en production sur une copie de la production. Cette copie est-elle sur un autre serveur ? Sinon je ne vois pas bien l'interêt. Un compte en readonly pour protéger les données sera aussi efficace. Sinon la copie en batch de nuit me semble le plus judicieux si les données à j-1 sont suffisantes. Tu peux en profiter pour adapter la base résultat pour optimiser les requêtes d'édition (au niveau des index).

[JauB]

la copie sera sur un autre serveur BACKUP. pourquoi je ne veux pas attaquer la base production même si c'est juste des consultations? tout simplement parce que je risque d'alourdir le système aux utilisateurs qui sont entrain de faire d'autres opérations sur la base de production!
mais ce qui me pose problème c'est que les tables contiennent des milliers et des milliers d'enregsitrements et donc je chercher une solution pour éclater ces tables. comme ça chaque utilisateur ne se connectera qu'à ses propres tables ( u qu'on gére l'habilitation des connexions des utilisateurs)!
Merci pour vos réponses.

[jab]

la copie sera sur un autre serveur BACKUP. pourquoi je ne veux pas attaquer la base production même si c'est juste des consultations? tout simplement parce que je risque d'alourdir le système aux utilisateurs qui sont entrain de faire d'autres opérations sur la base de production!

Ok d'ou la nécessité de copier en batch la nuit.

mais ce qui me pose problème c'est que les tables contiennent des milliers et des milliers d'enregsitrements et donc je chercher une solution poch le soie en batur éclater ces tables. comme ça chaque utilisateur ne se connectera qu'à ses propres tables ( u qu'on gére l'habilitation des connexions des utilisateurs)!
Merci pour vos réponses.

l

La je ne vois pas comment t'aider. La seul solution est de composer ton batch pour construire tes tables résultats selon tes besoins avec des commandes sql (insert where) mais je crains que le temps de l'opération deviennent très long. Si tu a un timestamp sur tes tables d'origines, tu pourrais te contenter de mettre à jour et non de tout réimporter chaque nuit.

[Mercure]

C'est difficile de donner des conseils en ne connaissant ni la fonctionnelle ni la base de données.

Disons que par exemple tu pourrais ne copier dans ton environnement de test qu'une ou deux régions représentatives de l'ensemble des régions ?

[christophedal]

Pour ma part j'ai développé pour ma société (ADiTi) une propagation de données de DB2 vers MySql, Postgre, ...

Pourquoi pas vers d'autre table de la DB2 I5.

J'utilise la journalisation des tables :
J'ai un programme RPG qui constitue les requêtes à partir du journal et un programme java qui propage les données.

[JauB]

peux tu m'expliquer davantage.