Discussion :

[JauB]

Bonjour,
J'ai un problème bizzard. J'ai une application tournant sous JAVA/TOMCAT et attaquant une base de données DB2/AS400. J'ai des requêtes qui prennent énormément de temps pour s'exécuter. Le problème c'est que lorsqu'un utilisateur soumet une requête via l'application et que juste après j'arrête TOMCAT (vers 18h30 pour quitter le boulot : ) ) pour lancer de nouveaux batchs du soir on trouve que les requêtes qui ont été soumises avant l'arrêt de TOMCAT sont toujours actives :
QZDASOINIT LOGINCO PJ 0,0 RUN
Ce qui nous provoque parfois des probèmes de vérouillage de fichiers (ceux utilisés par la requêtes) dont on aura besoin pour le batch du soir.
Je cherche alors un moyen pour arrêter tous les travaux d'une façon aisée (sans faire l'option 4 sur chaque travail pour l'arrêter) comme ça je serai sûr que tous es fichiers attaqués par ces requêtes ont été dévrouillés pour que le batch se lance sans problème.
Une piste si vous avez compris mon problème

Merci d'avance

[Mercure]

Je pense qu'une la solution "à la hussarde" serait de router ces jobs dans un sous-système particulier créé pour ces jobs et d'arrêter le sous-système par endsbs au même titre que les autres. Mais c'est très dangereux de les arrêter brutalement car une requête non terminée pourrait alors être en train de faire une mise à jour et, si cancel sans contrôle de validation, c'est la cata ! Les données ne sont alors plus synchronisées dans les bases, bonjour pour remettre le tout d'aplomb le lendamain sans compter que tu te ferais salement remonter les bretelles pour avoir cancellé les jobs de cette façon. Cependant, l'idée de sous-système particulier est intéressante et à creuser. Voir à ce sujet ROUTE SPECIFIC ODBC/JDBC USERS TO AN ALTERNATE SUBSYSTEM (page 4 du pdf).

Aussi, avant de toucher à quoique ce soit, j'essaierais de savoir pourquoi les requêtes rament autant. Ce ne sont pas les outils qui manquent et celui qui me vient de suite à l'esprit c'est l'Index Advisor déjà cité qu'on peut consulter à partir d'iSeries Navigator. Cet Advisor t'indique en particulier les tables pour lesquelles il a fallu que SQL crée un chemin d'accés, cause essentielle de la lenteur des requêtes, car aucun déjà existant adapté.
Encore une fois, relis les pages que je t'ai communiquées l'autre jour là-dessus sur mon post ci-dessous.
http://www.developpez.net/forums/d67...n/#post3976611

[JauB]

Je pense qu'une la solution "à la hussarde" serait de router ces jobs dans un sous-système particulier créé pour ces jobs et d'arrêter le sous-système par endsbs au même titre que les autres. Mais c'est très dangereux de les arrêter brutalement car une requête non terminée pourrait alors être en train de faire une mise à jour et, si cancel sans contrôle de validation, c'est la cata ! Les données ne sont alors plus synchronisées dans les bases, bonjour pour remettre le tout d'aplomb le lendamain sans compter que tu te ferais salement remonter les bretelles pour avoir cancellé les jobs de cette façon. Cependant, l'idée de sous-système particulier est intéressante et à creuser. Voir à ce sujet ROUTE SPECIFIC ODBC/JDBC USERS TO AN ALTERNATE SUBSYSTEM (page 4 du pdf).

Aussi, avant de toucher à quoique ce soit, j'essaierais de savoir pourquoi les requêtes rament autant. Ce ne sont pas les outils qui manquent et celui qui me vient de suite à l'esprit c'est l'Index Advisor déjà cité qu'on peut consulter à partir d'iSeries Navigator. Cet Advisor t'indique en particulier les tables pour lesquelles il a fallu que SQL crée un chemin d'accés, cause essentielle de la lenteur des requêtes, car aucun déjà existant adapté.
Encore une fois, relis les pages que je t'ai communiquées l'autre jour là-dessus sur mon post ci-dessous.
http://www.developpez.net/forums/d67...n/#post3976611

Oui je suis entrain de faire une étude sur les index mais en parallèle ce problème d'arrêt me pose problème. Je cite que mes requêtes ne font que des SELECT (donc pas de mises à jour), sinon je n'aurai pas penser à un arrêt brutal de ces jobs.
Je vais réflechir à ta première proposition de router ces jobs dans un sous-système particulier créé pour ces jobs et d'arrêter le sous-système par endsbs au même titre que les autres.
Merci.