Une validation est-elle nécessaire pour une requête de sélection dans DB2?

Question

J'ai un produit de reporting fournisseur exécutant des requêtes pour extraire des données de rapport, pas d'insertions, pas de mises à jour simplement en lisant des données.

Nous avons double notre taille de tas 3 fois et sommes maintenant à 1024 pages 4k, L'application fonctionnera bien pendant une semaine, puis nous commencerons à voir l'erreur DB2 SQL: SQLCODE: -954, SQLSTATE: 57011 indiquant le journal des transactions n'est pas en mesure d'accueillir la demande.

Ce n'est pas la taille des rapports car ils fonctionnent correctement après un recyclage. J'ai parlé avec un autre DBA à ce sujet. Il croit que le problème était dans une différence entre ORACLE et DB2 en ce que le code du fournisseur est merdique et ne pas émettre des validations sur les sélections. Cela provoque le nettoyage des références et s'accumule lentement comme une poubelle dans le tas.

Je voulais savoir si c'est exact car je pensais que seuls les insertions et les mises à jour nécessaires pour inclure des commits. Existe-t-il une documentation IBM sur ce sujet?

Nous recyclons actuellement sur une base hebdomadaire pour atténuer le problème, mais je voudrais avoir une bonne idée sur le problème avant de retourner au fournisseur leur demandant de modifier leur code.

Answer 1

Toute transaction doit être terminée correctement - pourquoi pensez-vous que cela s'applique uniquement aux insertions et aux mises à jour? Envisagez d'exécuter par transaction un "select a de b où c> 12" puis "select a de b où c < = 12"; Dans une transaction, la base de données doit garantir que chaque a est renvoyé exactement une fois soit par le premier ou le deuxième choix, et non par les deux (en supposant que c n'est jamais nul ;-). Sans transactionnalité, certains A pourraient tomber entre les mailles du filet ou être retourné deux fois si leur c correspondant a été modifié par une autre transaction, et c'est tout simplement pas ACID -)

Alors, quand vous ne pas besoin des requêtes SELECT séparées pour être transactionnel entre eux, dites à la DB! Et la façon dont vous le dites, est en terminant la transaction après chaque sélection (normalement commettre est ce que vous utilisez pour le but, mais je suppose que vous pourriez, indifféremment, choisir d'utiliser rollback ici ;-).

Answer 2

Pour la réponse d'Alex, la première activité SQL après tout CONNECT, COMMIT ou ROLLBACK initie une transaction. Pour gérer votre problème de ressources (journaux de transactions complets), vous devez examiner votre application qui émet les rapports. Assurez-vous que les transactions sont fermées explicitement dans le code. J'ai vu des cas où les développeurs d'applications comptent sur Garbage Collector pour nettoyer les objets de base de données - tandis que ces objets sont en attente de nettoyage, les ressources de la base de données (transactions) restent ouvertes.

Il est toujours recommandé de COMMITER ou de ROLLBACK explicitement vos transactions dès que vous avez terminé avec les données - indépendamment de la méthodologie de programmation que vous utilisez.