Pourquoi le statut de ma requête Amazon Redshift est-il passé de « Terminé » à « Abandonné » alors qu'aucune modification n'a été apportée ?

Date de la dernière mise à jour : 05/10/2020

La console Amazon Redshift montre que le statut de la requête est « Terminé », mais celui-ci passe ensuite à « Abandonné ». Cependant, aucune mise à jour n'a été apportée au tableau lorsque j'ai interrogé les résultats d'une session ou d'une transaction précédente. Pourquoi ?

Brève description

Les instructions SQL qui manipulent des données ou créent des objets de base de données ne perdurent pas jusqu'à la validation de la transaction. Cela ne s'applique pas aux instructions TRONQUER, qui exécutent implicitement une commande VALIDER.

La console Amazon Redshift montre que le statut de la requête est « Terminé » pour une instruction SQL si elle est encore dans une transaction ouverte. Le statut passe à « Abandonné » si la transaction est restaurée. La table de système STL_QUERY montre également que l'instruction SQL est terminée avec succès lorsque la valeur de la colonne « Abandonné » est de 0.

Si la transaction est validée ultérieurement, les modifications s'affichent. Toutefois, si la transaction ne peut pas être validée, la console Amazon Redshift montre que la requête est abandonnée. Afin d'identifier la raison pour laquelle votre transaction ne peut pas être validée, vérifiez les tables de système STL.

Solution

Exécutez la requête suivante pour vérifier la table de système SVL_STATEMENTTEXT et filtrer par l'ID de transaction (xid) de l'instruction SQL :

SELECT * FROM SVL_STATEMENTTEXT WHERE xid IN (SELECT xid FROM STL_QUERY WHERE query = [QUERY ID]) ORDER BY starttime, sequence;

Si le résultat est une instruction COMMENCER sans instruction FIN ou VALIDER correspondante, le client SQL ou le paramètre AUTO-VALIDATION du pilote est désactivé. Selon le client ou le pilote SQL, vous pouvez activer le paramètre AUTO-VALIDATION. Vous pouvez également émettre manuellement une instruction VALIDER ou FIN explicite lorsque la transaction est terminée.

Lorsqu'une instruction SQL valide ses modifications, une entrée correspondante est ajoutée à la table de système STL_COMMIT_STATS. Exécutez la requête suivante pour confirmer que les modifications ont bien été validées :

SELECT q.query, q.xid, NVL2(cs.endtime, cs.endtime::text, 'NO COMMIT') AS commit_endtime
FROM STL_QUERY q LEFT JOIN STL_COMMIT_STATS cs ON q.xid = cs.xid AND cs.node = -1
WHERE q.query = [QUERY ID];

Si une instruction SQL ne peut pas valider les modifications et que la transaction se termine, une entrée apparaît dans la table de système STL_UNDONE pour la restauration. Exécutez la requête suivante pour savoir si les modifications ont été restaurées :

SELECT *
FROM STL_UNDONE
WHERE xact_id_undone IN (SELECT xid from STL_QUERY where query = [QUERY ID]);

Cette requête renvoie les informations sur les transactions qui sont restaurées, ce qui signifie que la transaction n'a pas été exécutée jusqu'à la fin et que les modifications n'ont pas été appliquées. Les restaurations se produisent lorsqu'il y a une violation d'isolement sérialisable, ou lorsqu'un administrateur MET FIN à une session ou ANNULE une requête. Les annulations peuvent également être causées par des délais d'expiration dans la connexion réseau. Si une restauration se produit, le client reçoit un message d'erreur avec plus de détails. Par conséquent, assurez-vous que votre client est configuré pour la journalisation des erreurs.


Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?