Conception de base pour les Etats

[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]

Envoyé par 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!

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

Envoyé par JauB

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 ?

[JauB]

ok.
voilà, pour chaque région on a plusieurs lieux géographiques (només: REPRESENTATIONS). pour chaque représentation on a un chef, et c'est ce chef qui va faire les éditions ( édition des échéanciers comme à la banque,....)et je réflechis à mettre une table échéance par représentation comme ça chaque chef ne se connectera qu'à sa propre table. sinon s'ils se connectent tous à la même table alors là ça ne marchera pas ( je pense !).
qu'est ce que vous en dites?

[jab]

Envoyé par Mercure

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 ?

Il ne s'agit pas de test mais bien d'une base en prod. si j'ai bien compris, l'idée est de répartir la charge sur deux serveurs. Le serveur avec les données à jour pour l'appli et un serveur avec une copie pour le reporting.

[jab]

Envoyé par JauB

ok.
voilà, pour chaque région on a plusieurs lieux géographiques (només: REPRESENTATIONS). pour chaque représentation on a un chef, et c'est ce chef qui va faire les éditions ( édition des échéanciers comme à la banque,....)et je réflechis à mettre une table échéance par représentation comme ça chaque chef ne se connectera qu'à sa propre table. sinon s'ils se connectent tous à la même table alors là ça ne marchera pas ( je pense !).
qu'est ce que vous en dites?

Si tu index correctement ta table, il n'y aura aucun problème à accéder à l'ensemble. Une table par chef cela me parait une architecture peu banale.

[Mercure]

jab a écrit :
Il ne s'agit pas de test mais bien d'une base en prod. si j'ai bien compris, l'idée est de répartir la charge sur deux serveurs. Le serveur avec les données à jour pour l'appli et un serveur avec une copie pour le reporting.

OK mais il va bien falloir que JauB testes ses programmes d'édition, non ? Et à partir de quelles données fera-t-il ses tests sinon à partir d'une base de test placée dans un bibliothèque de test, qui sera en fait ce qu'il a copié dans le batch de nuit sur le serveur de backup ? Cet environnement de test deviendra en fait également l'environnement de production à terme, quand les tests seront terminés.

JauB travaille sous l'OS i5, c'est à dire un des nouveaux noms de l'OS/400. Ce qui me semble bizarre c'est que des programmes d'édition soient développés en Java sur ce genre de machine alors que c'est a priori en Cobol habituellement que c'est fait.

Je suis toutefois d'accord avec ce que suggère jab en ce qui concerne l'index sur l'ensemble de la table en question sans l'éclater en multiples sous-tables.
Je ne vois pas pourquoi ça ne marcherait pas.

[JauB]

Envoyé par Mercure

JauB travaille sous l'OS i5, c'est à dire un des nouveaux noms de l'OS/400. Ce qui me semble bizarre c'est que des programmes d'édition soient développés en Java sur ce genre de machine alors que c'est a priori en Cobol habituellement que c'est fait.

oui mais pas nécessairement travailler avec COBOL vu que notre équipe ne maitrise pas COBOL comme elle maitrise JAVA. on a téléchargé les drivers pour l'accès à la base DB2 via JDBC. les éditions on les faits avec iReport ( JASPER) si vous le connaissez. En fait le progiciel qu'on a est dévelopé en COBOL mais utilise la technologie WEBFACING pour l'habillage de l'application ( donc en JSP) et c'est pour ça qu'on a pensé à travailler la partie Editique en JAVA. sinon comme le dit JAB je vais juste mettre des index sur mes fichiers physiques sans éclater les tables. mais il me faudra faire les tests au cas où 100 personnes sont connectées en même temps.
si vous avez d'autres idées pour gérer mes états ne manquez pas SVP de me faire part de vos réflexions.
Merci les amis

[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.