Pourquoi l'opération Amazon Redshift VACUUM ne permet-elle pas de récupérer de l'espace disque ?

Brève description

Lorsque vous supprimez des lignes de table, une colonne d'identité de métadonnées masquée (DELETE_XID) est marquée avec l'ID de transaction qui a supprimé la ligne.

Si une transaction active et de longue durée a débuté avant la suppression, VACUUM ne peut pas nettoyer les lignes et l'espace disque ne peut pas être récupéré.

Pour plus d'informations sur la colonne DELETE_XID, consultez la section Optimisation du stockage pour les tables étroites.

Résolution

Pour vérifier les transactions de longue durée sur le cluster Amazon Redshift, exécutez la requête suivante :

rsdb=# select *,datediff(s,txn_start,getdate())/86400||' days '||datediff(s,txn_start,getdate())%86400/3600||' hrs '||datediff(s,txn_start,getdate())%3600/60||' mins '||datediff(s,txn_start,getdate())%60||' secs' duration from svv_transactions where lockable_object_type='transactionid' and  pid<>pg_backend_pid() order by 3;

La sortie suivante indique que xid 50341 est actif depuis 19 minutes et 37 secondes :

txn_owner  | txn_db |  xid  |  pid  |         txn_start          |   lock_mode   | lockable_object_type | relation | granted |           duration
-----------+--------+-------+-------+----------------------------+---------------+----------------------+----------+---------+------------------------------
 superuser | rsdb   | 50341 | 21612 | 2019-08-19 20:20:33.147622 | ExclusiveLock | transactionid        |          | t       | 0 days 0 hrs 19 mins 37 secs
(1 row)

Pour confirmer que vous avez supprimé des lignes de la table Amazon Redshift, exécutez la requête suivante :

select a.query, a.xid, trim(c.name) tablename, b.deleted_rows, a.starttime, a.endtime
from stl_query a
join (select query, tbl, sum(rows) deleted_rows from stl_delete group by 1,2) b
on a.query = b.query
join (select id, name from stv_tbl_perm group by 1,2) c
on c.id = b.tbl
where a.xid in (select distinct xid from stl_commit_stats)
and trim(c.name) = 'tablename'
order by a.starttime;

La sortie suivante montre que la transaction marquée pour suppression de ligne (xid 50350) a commencé après la transaction de longue durée (xid 50341) :

query  |  xid  | tablename | deleted_rows |         starttime          |          endtime
-------+-------+-----------+--------------+----------------------------+----------------------------
 18026 | 50350 | test      |            5 | 2019-08-19 20:20:48.137594 | 2019-08-19 20:20:50.125609
(1 rows)

Pour permettre à VACUUM DELETE de récupérer ces lignes supprimées, choisissez l'une des options suivantes :

• Attendez que la transaction de longue date soit terminée.
• Utilisez l'instruction PG_TERMINATE_BACKEND pour mettre fin à la session qui contient la transaction de longue durée.

Après avoir effectué l'action précédente, réexécutez l'opération VACUUM.

Enquêter sur les transactions de longue durée

Pour vérifier l'activité d'une transaction de longue durée, interrogez la vue SVL_STATEMENTTEXT :

rsdb=# select pid, xid, trim(label), starttime, endtime, trim(text) from svl_statementtext where xid = 50341 order by starttime , sequence;

Exemple de sortie :

pid  |  xid  |  btrim  |         starttime          |          endtime           |          btrim
-------+-------+---------+----------------------------+----------------------------+--------------------------
 21612 | 50341 | default | 2019-08-19 20:20:31.733843 | 2019-08-19 20:20:31.733844 | begin;
 21612 | 50341 | default | 2019-08-19 20:20:33.146937 | 2019-08-19 20:20:35.020556 | select * from sometable;
(2 rows)

Pour vérifier que les requêtes sont exécutées dans la transaction, interrogez la vue STV_INFLIGHT :

rsdb=# select query, xid, pid, starttime, trim(text) from stv_inflight where xid = 50341;

Exemple de sortie :

query | xid | pid | starttime | btrim
-------+-----+-----+-----------+-------
(0 rows)

Causes courantes des transactions de longue durée

Le comportement suivant peut entraîner des transactions de longue durée :

• Un utilisateur lance une transaction implicite à partir d'un client où la validation automatique est désactivée. La transaction demeure active jusqu'à ce que l'utilisateur la ferme à l'aide de la commande COMMIT ou ROLLBACK, ou jusqu'à ce que la session soit terminée.
• Un utilisateur démarre une transaction et utilise BEGIN, mais ne ferme jamais la transaction à l'aide de la commande COMMIT ou ROLLBACK.

Informations connexes

Exécuter des opérations vacuum sur des tables

Minimiser les délais d’exécution des opérations vacuum