Comment puis-je résoudre les problèmes liés à VACUUM dans Amazon Redshift ?

Brève description

VACUUM est une opération gourmande en ressources qui peut être ralentie par les facteurs suivants :

• Un pourcentage élevé de données non triées
• Une table volumineuse contenant un nombre excessif de colonnes
• L'utilisation d'une clé de tri entrelacée
• Une utilisation irrégulière ou peu fréquente de VACUUM
• Des tables simultanées, des requêtes de cluster, des instructions DDL ou des tâches ETL

Utilisez la requête svv_vacuum_progress pour vérifier le statut et les détails de votre opération VACUUM. Puis, suivez les bonnes pratiques relatives à VACUUM pour résoudre les problèmes et éviter tout problème futur.

Résolution

Résoudre les problèmes liés aux performances de VACUUM

Remarque : La section suivante s'applique aux clusters Amazon Redshift provisionnés. Les tables et requêtes système suivantes ne fonctionnent pas sur Amazon Redshift sans serveur.

Pour vérifier si l'opération VACUUM est en cours, exécutez la requête svv_vacuum_progress :

dev=# SELECT * FROM svv_vacuum_progress;
table_name |          status                 | time_remaining_estimate
-----------+---------------------------------+-------------------------
 data8     |  Vacuum: initialize merge data8 | 4m 55s
(1 row)

La requête svv_vacuum_progress inclut également le nom de la table, le statut de l’opération vacuum et le temps restant estimé avant la fin de cette dernière. Si aucune opération VACUUM n'est en cours, la requête svv_vacuum_progress query indique le statut de la dernière exécution de VACUUM.

Remarque : La requête svv_vacuum_progress ne renvoie qu'une seule ligne de résultats.

Vérifiez les détails de la table soumise à une opération vacuum. Spécifiez les noms des tables et des schémas dans la clause WHERE :

SELECT schema, table_id, "table", diststyle, sortkey1, sortkey_num, unsorted, tbl_rows, estimated_visible_rows, stats_off
FROM svv_table_info
WHERE "table" IN ('data8');

Exemple de sortie :

Schema     | table_id | table | diststyle | sortkey1 | sortkey_num | unsorted | tbl_rows  | est_visible_rows | stats_off
------------+----------+-------+-----------+----------+-------------+----------+-----------+------------------+-----------
testschema | 977719   | data8 | EVEN      | order_id |  2          |    25.00 | 755171520 | 566378624        | 100.00

À partir de la sortie précédente, la colonne sortkey1 affiche la clé de tri principale.

Si la table comporte une clé de tri entrelacée, cette colonne indique l'état INTERLEAVED.

• La colonne sortkey_num indique le nombre de colonnes dans la clé de tri.
• La colonne non triée indique le pourcentage de lignes qui doivent être triées.
• La colonne tbl_rows indique le nombre total de lignes, y compris les lignes supprimées et mises à jour.
• La colonne estimated_visible_rows indique le nombre de lignes qui exclut les lignes supprimées.
• Après une opération vacuum complète (suppression et tri), les valeurs de tbl_rows et estimated_visible_rows se ressemblent, et la valeur non triée atteint 0. Remarque : Les données de la table sont mises à jour en temps réel. Pour vérifier la progression de VACUUM, continuez à exécuter la requête. Notez que les lignes non triées diminuent progressivement à mesure que VACUUM progresse. Pour vérifier si vous disposez d'un pourcentage élevé de données non triées, consultez les informations VACUUM d'une table spécifique.

Exécutez la requête suivante pour vérifier les informations VACUUM d'une table. Spécifiez l'ID de table de la requête précédente :

SELECT table_id, status, rows, sortedrows, blocks, eventtime
FROM stl_vacuum
WHERE table_id=977719
ORDER BY eventtime DESC LIMIT 20;

Exemple de sortie :

table_id |             status             |    rows    | sortedrows | blocks |         eventtime
         ----------+--------------------------------+------------+------------+--------+----------------------------
  977719 | [VacuumBG] Finished            |  566378640 |          0 |  23618 | 2020-05-27 06:55:33.232536
  977719 | [VacuumBG] Started Delete Only | 1132757280 |  566378640 |  47164 | 2020-05-27 06:55:18.906008
  977719 | Finished                       |  566378640 |  566378640 |  23654 | 2020-05-27 06:46:04.086842
  977719 | Started                        | 1132757280 |  566378640 |  45642 | 2020-05-27 06:28:17.128345
(4 rows)

Dans l'exemple précédent, la sortie répertorie d'abord les événements les plus récents, puis les événements les plus anciens, dans un ordre trié :

• La dernière opération VACUUM était une opération VACUUM DELETE automatique qui a commencé le 27/05/2020 à 06:55:18.906008 UTC et s'est terminée en quelques secondes.
• Cette opération VACUUM a libéré l'espace occupé par les lignes supprimées. Cet état est confirmé par le nombre de lignes et de blocs qui apparaissent lorsque l'opération VACUUM a commencé et s'est terminée.

Notez l'évolution du nombre de blocs occupés par la table entre le début et la fin de VACUUM.

Remarque : Amazon Redshift effectue automatiquement les opérations VACUUM SORT et VACUUM DELETE sur les tables en arrière-plan. Ces opérations VACUUM en arrière-plan sont exécutées pendant les périodes de charge réduite et sont suspendues pendant les périodes de charge élevée. Cette opération VACUUM automatique réduit la nécessité d'exécuter la commande VACUUM.

La colonne sortedrows indique le nombre de lignes triées dans la table. Lors de la dernière opération VACUUM, aucun tri n'a été effectué car il s'agissait d'une opération VACUUM DELETE automatique. Étant donné que les lignes actives n'ont pas été triées, la ligne marquée pour suppression affiche le même nombre de lignes triées qu'au démarrage de VACUUM. Une fois l’opération VACUUM DELETE terminée, aucune ligne triée ne s'affiche.

L’opération VACUUM initiale qui a démarré le 27/05/2020 06:28:17.128345 UTC indique un VACUUM complet. Le processus a libéré l'espace des lignes supprimées et les lignes triées après environ 18 minutes. Lorsque l'opération VACUUM est terminée, la sortie affiche les mêmes valeurs pour les lignes et les lignes triées car VACUUM a trié les lignes avec succès.

Pour une opération VACUUM déjà en cours, continuez à surveiller ses performances et à intégrer les bonnes pratiques.

Résoudre un échec de VACUUM

Remarque : Si des erreurs surviennent lorsque vous exécutez des commandes de l'interface de la ligne de commande AWS (AWS CLI), consultez la section Résoudre des erreurs liées à l’AWS CLI. Vérifiez également que vous utilisez bien la version la plus récente de l'interface.

Pour savoir pourquoi une requête VACUUM a échoué, utilisez SYS_QUERY_HISTORY ou STL_QUERY pour vérifier les messages d'erreur.

Si vous utilisez STL_QUERY, vous devez obtenir les détails de l'erreur auprès de STL_ERROR. Dans la mesure où STL_ERROR n’inclut pas de colonne d'ID de requête, recherchez le champ PID dans STL_QUERY. Puis, utilisez ce champ dans la requête STL_ERROR.

Exemple :

SELECT user_id, query_id, transaction_id, session_id,  status, start_time, end_time, execution_time, error_message FROM sys_query_history WHERE query_id IN (<failed queries>)


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

| user_id | query_id   | transaction_id |  session_id | status | start_time              |     end_time                  |  execution_time |   error_message |  
| 100        | 915082632 | 35599398     | 1096641177 | failed  | 2024-10-06 21:09:30.209587 | 2024-10

Si vous utilisez l'instruction execute pour exécuter la requête VACUUM, utilisez describe-statement pour identifier d’éventuels messages d'erreur.

Exemple :

aws redshift-data describe-statement --id 7c823348d-be8b-437a-9a0-db8c0ca44f0f
{
    "ClusterIdentifier": "redshift-cluster-1",
    "CreatedAt": "2024-10-07T16:25:27.566000+00:00",
    "Duration": -1,
    "Error": "ERROR: VACUUM cannot run inside a multiple commands statement",
    "HasResultSet": false,
    "Id": "7c823348d-be8b-437a-9a0-db8c0ca44f0f",
    "QueryString": "vacuum full toptem;\nvacuum full tsupport;\nvacuum full supplierxbox;\nvacuum full party;",
    "RedshiftPid": 10723479554,
    "RedshiftQueryId": 42304,
    "ResultRows": -1,
    "ResultSize": -1,
    "Status": "FAILED",
    "UpdatedAt": "2024-10-07T16:25:33.566000+00:00"
}

Bonnes pratiques relatives à VACUUM

Vous pouvez améliorer les performances de VACUUM grâce aux bonnes pratiques suivantes :

• VACUUM étant une opération gourmande en ressources, exécutez-la pendant les heures creuses.
• Pendant les heures creuses, utilisez wlm_query_slot_count pour modifier temporairement le niveau de simultanéité dans une file d'attente pour une opération VACUUM.
• Effectuez l'opération VACUUM avec un paramètre de seuil allant jusqu'à 99 % pour les tables volumineuses.
• Déterminez le seuil et la fréquence appropriés pour l’exécution de VACUUM. Par exemple, vous souhaiterez peut-être exécuter VACUUM à un seuil de 100 % ou faire en sorte que vos données soient toujours triées. Utilisez l'approche qui optimise les performances des requêtes de votre cluster Amazon Redshift.
• Exécutez une opération VACUUM FULL ou VACUUM SORT ONLY assez souvent pour qu'une région non triée ne s'accumule pas dans les grandes tables.
• Si une table volumineuse contient une grande quantité de données non triées, effectuez une copie complète. Une copie complète peut vous aider à charger les données dans une nouvelle table au lieu d'exécuter VACUUM SORT sur la table existante.
• Exécutez la commande VACUUM avec l'option BOOST. L'option BOOST alloue des ressources supplémentaires à VACUUM, telles que la mémoire disponible et l'espace disque. Avec l'option BOOST, VACUUM fonctionne dans une seule fenêtre et bloque les suppressions et mises à jour simultanées pendant la durée de l'opération VACUUM.
  Remarque : L'exécution de VACUUM avec l'option BOOST peut affecter les performances des requêtes. Il est recommandé d'exécuter l'opération VACUUM BOOST uniquement pendant les opérations de maintenance ou pendant les heures creuses.
• Divisez toutes les tables volumineuses en tables de séries chronologiques pour améliorer les performances de VACUUM. Dans certains cas, lorsque vous utilisez une table de séries chronologiques, vous pouvez répondre à la nécessité d'exécuter VACUUM.
• Choisissez un type de compression de colonne pour les grandes tables. Les lignes compressées consomment moins d'espace disque lorsque vous triez des données.
• Utilisez la commande ANALYZE après l'opération VACUUM pour mettre à jour les statistiques. Le planificateur de requête utilise ces valeurs pour choisir les meilleurs plans.
• Si le cluster est complètement inactif, exécutez une opération MANUAL VACUUM en cas d'échec des tentatives VACCUM. Pour plus d'informations, consultez la section Exécution d’opérations vacuum et analyse manuelle de tables.

Informations connexes

STL_ERROR

Pourquoi ma requête a-t-elle été annulée dans Amazon Redshift ?

Pourquoi ma requête Amazon Redshift sans serveur est-elle annulée ou arrêtée ?