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

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 TRUNCATE, qui exécutent implicitement une commande COMMIT.

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

Pour vérifier si une transaction a été validée ou annulée, utilisez le résultat de la requête suivante dans la table système SVL_STATEMENTTEXT. Ensuite, filtrez en fonction de 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;

La sortie de la requête affiche une instruction « Annulation d'une transaction » pour la transaction annulée.

Si une transaction commence par une instruction BEGIN, celle-ci a été explicitement ouverte par l'utilisateur ou l'application. La déclaration doit également être explicitement validée. Les transactions qui ne sont pas initiées à l'aide d'une instruction BEGIN sont généralement validées automatiquement par l'option AUTO COMMIT du client SQL ou du pilote. Si l'option est désactivée, l'utilisateur doit envoyer un COMMIT de manière explicite.

Lorsqu'une transaction est correctement validée, les modifications de la transaction sont durables (persistantes) et peuvent être vues par d'autres XID initiés après l'instruction COMMIT. Pour plus d'informations, consultez la section Isolement sérialisable.

Si aucun message END, COMMIT ou « Annulation d'une transaction » ne s'affiche dans la table système SVL_STATEMENTTEXT, le XID peut toujours être ouvert. Utilisez la vue SVV_TRANSACTIONS pour identifier les transactions ouvertes et les conflits LOCK.

Les tables système STL_COMMIT_STRATS et STL_UNDONE peuvent également être utilisées pour confirmer si une transaction s'est terminée par un COMMIT ou un ROLLBACK.

Exécutez la requête suivante pour savoir si les modifications ont é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];

Exécutez la requête suivante pour savoir si les modifications ont été annulées:

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

Les modifications de transaction ne sont pas conservées en raison d'une commande ROLLBACK explicite ou si elle ne s'exécute pas avant la fin. Les ROLLBACKS explicites ne peuvent pas se produire en cas de violation d'isolation sérialisable. Ils ne peuvent pas non plus se produire lorsqu'un administrateur MET FIN à une session ou ANNULE une requête. Les délais d'expiration d'une connexion réseau peuvent également empêcher la persistance des modifications des transactions.

Si une restauration se produit, le client reçoit un message d'erreur avec plus de détails. Il est recommandé de configurer votre client pour qu'il enregistre les erreurs. Pour plus d'informations, voir Configurer la journalisation (JDBC) ou LogLevel (ODBC).

Informations connexes

STL_DDLTEXT