2017-10-10 4 views
0

J'ai une simple transformation composée de 2 étapes. Une étape (Table d'entrée) permet d'interroger les résultats de DB et de 2 étapes (classe Java). 2 pas prend beaucoup de temps (c'est normal dans mon cas) mais après 1 heure j'obtiens l'erreur du jeu fermé de résultatsComment obtenir tous les résultats de résultats définis dans pentaho Étape de la marmite de la bouilloire?

Le serveur a fermé la connexion. Si le jeu de résultats contient une grande quantité de données, le serveur s'attend à ce que le client lise le jeu de résultats relativement rapidement. Dans ce cas, pensez à augmenter la variable de session net_wait_timeout./traitement de votre jeu de résultats plus rapidement (consultez la documentation relative aux jeux de résultats de diffusion pour plus d'informations) 2017/10/02 13:12:06 - Mise à jour des cellules de données .0 -

Je pense qu'il devrait y avoir une étape intermédiaire (ou une certaine autre option) pour obtenir relativement rapidement tout le résultat d'1 étape. Pourriez-vous m'aider avec ça?

+0

J'ai une question (pas si) stupide: est-ce vraiment dû à l'étape de la classe java? Je veux dire, la table d'entrée est souvent verrouillée pour d'autres raisons. Pouvez-vous remplacer l'étape 2 par un pas 'Dumy' et voir si elle se verrouille encore. – AlainD

+0

Une autre question (pas si) stupide: votre classe java peut-elle verrouiller la base de données? Utilise-t-il un 'JDBC'? – AlainD

+0

Oui, il utilise - (java class peut dans certains cas envoyer des requêtes UPDATE à DB). Donc, cela pourrait-il conduire à la connexion (et resultset correspondant) de fermeture pour 1 étape? – palandlom

Répondre

1

je suppose que votre étape 2 est le verrouillage de la même table que celle à l'étape 1.

C'est l'un des inconvénients de l'architecture autrement efficace du PDI. Toutes les étapes de démarrage en même temps, et le plus rapide pour produire des résultats donnent la main aux prochaines étapes. Avec cette stratégie de «faire le plus rapidement en premier», vous pouvez parfois battre l'optimiseur SQL lui-même lorsqu'il y a beaucoup de jointures sur des sommes ou des moyennes (pro rata).

L'écueil principal à cet égard est de lire une table, de faire une transformation et de réécrire le résultat sur la même table avec le truncate table vérifié. Dans ce cas, la troncature est faite quelques millisecondes avant la sélection de la table d'entrée qui déclenche un verrouillage infini. Après une longue période, vous décidez de tuer l'ETL, mais à ce moment-là, les données ont été perdues.

Solutions:

  • Le les meilleures pratiques consiste à réécrire l'étape 2 en utilisant les étapes plutôt que d'IPD utiliser une classe java prêt à l'emploi. C'est la façon que je recommande fortement sur le long terme, mais vous pouvez avoir une raison de ne pas le suivre. Si votre table est petite, vous pouvez mettre blocking step entre l'entrée et la sortie.

  • Si votre table est grande, vous pouvez utiliser une étape sort row au lieu de l'étape de blocage. Vous ne voulez pas vraiment trier, mais le PDI doit regarder la dernière ligne pour être sûr que le tri est terminé, avant de donner des résultats à l'étape suivante. Le tri coupe les données dans des chuncks temporaires sur le disque dur, et vous pouvez avoir un certain contrôle sur où et comment les données tmp sont stockées.

  • Vous pouvez copier votre table dans une table tmp (ou un fichier), la traiter et la supprimer après. Utilisez un travail pour cela, car dans un travail, contrairement à une transformation, le processus est séquentiel.

+0

Merci, pour une explication détaillée!J'espère que j'ai bien compris - j'ai supprimé le code pour l'exécution de la requête UPDATE de java-class et j'ajoute 3 pas (étape INSERT/UPDATE) qui reçoit un champ de 2 pas et fait une requête UPDATE. – palandlom

+0

Félicitations. Cordialement. Les verrous morts ne sont jamais des bogues faciles. – AlainD