Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# STL\$1VACUUM
Affiche les statistiques de ligne et de bloc pour les tables qui ont été l’objet d’une opération VACUUM.
La vue affiche les informations propres à chaque moment où l’opération VACUUM a commencé et fini, et démontre les avantages de l’exécution de l’opération. Pour plus d’informations sur la configuration requise pour exécuter cette commande, consultez la description de la commande [VACUUM](r_VACUUM_command.md).
STL\$1VACUUM n’est visible que par les super-utilisateurs. Pour plus d’informations, consultez [Visibilité des données dans les tables et vues système](cm_chap_system-tables.md#c_visibility-of-data).
Tout ou partie des données de cette table sont également disponibles dans la vue de surveillance SYS [SYS\$1VACUUM\$1HISTORY](SYS_VACUUM_HISTORY.md). Les données de la vue de surveillance SYS sont formatées pour être plus faciles à utiliser et à comprendre. Nous vous recommandons d’utiliser la vue de surveillance SYS pour vos requêtes.
## Colonnes de la table
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/r_STL_VACUUM.html)
## Exemples de requêtes
La requête suivante rapporte les statistiques de l’opération VACUUM pour la table 108313. La table a été l’objet d’une opération VACUUM après une série d’insertions et de suppressions.
```
select xid, table_id, status, rows, sortedrows, blocks, eventtime,
reclaimable_rows, reclaimable_space_mb
from stl_vacuum where table_id=108313 order by eventtime;
xid | table_id | status | rows | sortedrows | blocks | eventtime | reclaimable_rows | reclaimable_space_mb
-------+----------+-------------------------+------+------------+--------+----------------------+------------------+----------------------
14294 | 108313 | Started | 1950 | 408 | 28 | 2016-05-19 17:36:01 | 984 | 17
14294 | 108313 | Finished | 966 | 966 | 11 | 2016-05-19 18:26:13 | 0 | 0
15126 | 108313 | Skipped(sorted>=95%) | 966 | 966 | 11 | 2016-05-19 18:26:38 | 0 | 0
```
Au début de l’opération VACUUM, la table contenait 1 950 lignes stockées dans 28 blocs de 1 Mo. Amazon Redshift a estimé pouvoir en récupérer 984, soit 17 blocs d’espace disque, avec une opération VACUUM.
Dans la ligne correspondant à l’état Finished (Terminé), la colonne ROWS présente une valeur de 966, et la valeur de la colonne BLOCKS est égale à 11, au lieu de 28. L’opération VACUUM a récupéré la quantité d’espace disque estimée, sans qu’il ne reste de lignes ou d’espace récupérables à l’issue de l’opération VACUUM.
Dans la phase de tri (transaction 15126), l’opération VACUUM a été en mesure d’ignorer la table, car les lignes ont été ajoutées dans l’ordre des clés de tri.
L’exemple suivant montre les statistiques d’une opération d’aspiration SORT ONLY sur la table SALES (110116 dans cet exemple) après une importante opération INSERT :
```
vacuum sort only sales;
select xid, table_id, status, rows, sortedrows, blocks, eventtime
from stl_vacuum order by xid, table_id, eventtime;
xid |table_id| status | rows |sortedrows|blocks| eventtime
----+--------+-----------------+-------+----------+------+--------------------
...
2925| 110116 |Started Sort Only|1379648| 172456 | 132 | 2011-02-24 16:25:21...
2925| 110116 |Finished |1379648| 1379648 | 132 | 2011-02-24 16:26:28...
```