Pourquoi le statut de ma requête Amazon Redshift est-il passé de « Terminée » à « Abandonnée » 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 sont pas conservées tant que la transaction n'est pas validée. Cette règle n'est pas applicable aux instructions TRUNCATE, qui exécutent implicitement une commande COMMIT.

Le statut dans la console Amazon Redshift indique que la requête est « Terminée » si l'instruction SQL en question fait toujours partie d'une transaction ouverte. Ce statut passe à « Annulée » si la transaction est annulée. La table système STL_QUERY indique également que l'instruction SQL s'est correctement terminée lorsque la valeur de la colonne abandonnée est 0.

Si la transaction est validée ultérieurement, les modifications apparaîtront à ce moment-là. Toutefois, si la transaction ne peut pas être validée, la console Amazon Redshift indique que la requête est abandonnée. Pour identifier la raison pour laquelle votre transaction ne peut pas être validée, consultez les tables du système STL.

Résolution

Pour confirmer si une transaction a été validée ou annulée, utilisez la sortie de la requête suivante sur la table système SVL_STATEMENTTEXT. Filtrez ensuite ces résultats 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 indique 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 commencent pas par une instruction BEGIN sont généralement validées automatiquement par l'option AUTO COMMIT du client ou du pilote SQL. Si cette option est désactivée, l'utilisateur doit envoyer un COMMIT de manière explicite.

Lorsqu'une transaction est correctement validée, les modifications apportées à la transaction sont durables (persistantes) et peuvent être consultées par les autres XID initiés après l'instruction COMMIT. Pour en savoir plus, veuillez consulter la section Isolement sérialisable.

Si aucun message END, COMMIT ou « Annulation d'une transaction » n'apparaît dans la table système SVL_STATEMENTTEXT, il est possible que le XID soit encore ouvert. Utilisez la vue SVV_TRANSACTIONS pour identifier les transactions ouvertes et les conflits de verrouillage.

Les tables système STL_COMMIT_STATS 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 xid 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 commandes ROLLBACK explicites sont impossibles dans le cas d'une violation d'isolement sérialisable. Elles sont également impossibles lorsqu'un administrateur met fin à une session ou annule une requête. Des délais au niveau de la connexion réseau peuvent également empêcher la conservation des modifications de transactions.

Si une annulation se produit, le client reçoit alors un message d'erreur plus détaillé. Il est recommandé de configurer votre client pour qu'il enregistre les erreurs. Pour en savoir plus, veuillez reportez-vous à la section Configuration de la journalisation (JDBC) ou la section LogLevel (ODBC).

Informations connexes

STL_DDLTEXT