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.
# Interrogations planifiées avec l’éditeur de requête v2
Avec Amazon Redshift Query Editor V2, vous pouvez automatiser les requêtes SQL pour qu’elles s’exécutent selon un planning. Les requêtes planifiées sont des instructions SQL qui s’exécutent automatiquement à des moments ou à des intervalles spécifiés, ce qui vous permet de gérer efficacement les opérations de données et les tâches d’analyse récurrentes. Vous souhaiterez peut-être planifier des requêtes si vous souhaitez rationaliser le traitement par lots, générer des rapports réguliers ou gérer des pipelines de données au sein de leur environnement Amazon Redshift.
Les requêtes planifiées facilitent l'automatisation des flux de travail d'extraction, de transformation et de chargement (ETL), l'actualisation des tableaux de bord avec des up-to-date informations et la mise en œuvre de diverses routines de gestion des données. Les pages suivantes décrivent en détail le processus de création, de configuration et de gestion des requêtes planifiées afin d’optimiser vos charges de travail Amazon Redshift.
# Création d’une planification de requête avec l’éditeur de requête v2
Vous pouvez créer une planification en vue d'exécuter une instruction SQL avec l'éditeur de requête Amazon Redshift v2. La création d'une planification vise à exécuter l'instruction SQL aux périodes qui correspondent aux besoins de votre activité. Au moment de l'exécution de la requête planifiée, celle-ci est lancée par Amazon EventBridge et utilise l'API Amazon Redshift Data.
**Pour créer une planification afin d’exécuter une instruction SQL**
1. Dans la vue **Éditeur** ![\[Editor\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/mgmt/images/qev2-align-left.png), choisissez ![\[Schedule\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/mgmt/images/qev2-calendar.png) **Planification** pour créer une planification en vue d'exécuter une instruction SQL.
1. Lorsque vous définissez la planification, vous fournissez les informations suivantes.
+ Le rôle IAM qui prend les autorisations nécessaires pour exécuter la requête. Ce rôle IAM est également attaché à votre cluster ou groupe de travail.
+ Les valeurs d'authentification pour l'une AWS Secrets Manager ou l'autre des informations d'identification temporaires permettant d'autoriser l'accès à votre cluster ou groupe de travail. Ces méthodes d'authentification sont prises en charge par l'API de données. Pour plus d’informations, consultez [Authentification d’une requête planifiée](query-editor-v2-schedule-query-authentication.md).
+ Le cluster ou le groupe de travail dans lequel réside votre base de données.
+ Le nom de la table de base de données qui contient les données à interroger.
+ Nom de la requête planifiée et sa description. L'éditeur de requêtes v2 préfixe le nom de la requête planifiée que vous fournissez par « QS2 - ». L'éditeur de requête v1 ajoute le préfixe « QS- » aux noms de ses requêtes planifiées.
+ L'instruction SQL à exécuter selon la planification.
+ Les options de fréquence et de répétition de la planification ou une valeur au format cron qui définit la planification. Pour plus d'informations, consultez la section [Cron Expressions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/ScheduledEvents.html#CronExpressions) dans le *guide de l'utilisateur Amazon CloudWatch Events*.
+ Si nécessaire, vous pouvez activer des notifications Amazon SNS standard pour surveiller la requête planifiée. Vous serez peut-être amené à confirmer l'adresse e-mail que vous avez fournie à la notification Amazon SNS. Vérifiez dans votre e-mail s'il existe un lien destiné à confirmer l'adresse e-mail pour la notification Amazon SNS. Pour en savoir plus, consultez [Notifications par e-mail](https://docs.aws.amazon.com/sns/latest/dg/sns-email-notifications.html) dans le *Guide du développeur Amazon Simple Notification Service*. Si votre requête est en cours d'exécution mais que vous ne voyez aucun message publié dans votre rubrique SNS, consultez [Ma règle s'exécute, mais je ne vois aucun message publié dans ma rubrique Amazon SNS](https://docs.aws.amazon.com/eventbridge/latest/userguide/eventbridge-troubleshooting.html#eb-no-messages-published-sns) dans le guide de l'utilisateur * EventBridge Amazon*.
1. Choisissez **Planifier une requête** pour enregistrer et activer la planification et ajouter celle-ci à la liste des requêtes dans la vue **Requêtes planifiées**.
La vue **Requêtes planifiées** ![\[Scheduled queries\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/mgmt/images/qev2-calendar.png) liste toutes les requêtes planifiées pour vos clusters et groupes de travail. Cette vue vous permet d'afficher les détails de la requête planifiée, d'activer ou de désactiver la planification, de modifier la planification et de supprimer la requête planifiée. Lorsque vous examinez les détails d'une requête, vous pouvez aussi consulter l'historique de ses exécutions dans le cadre de la planification.
**Note**
Une exécution de requête planifiée ne reste disponible dans la liste **Historique de planification** que 24 heures. Les requêtes qui s'exécutent selon une planification ne figurent pas dans la vue **Historique des requêtes** de l'éditeur de requête v2
## Démonstration de la planification d'une requête
Pour une démonstration de la planification d'une requête, regardez la vidéo suivante.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/gTw0XUpO8sw)
# Configuration des autorisations pour planifier une requête
Pour planifier des requêtes, l'utilisateur Gestion des identités et des accès AWS (IAM) qui définit le calendrier et le rôle IAM associé au calendrier doit être configuré avec les autorisations IAM pour utiliser Amazon et l'API Amazon EventBridge Redshift Data. Pour recevoir des e-mails des requêtes planifiées, la notification Amazon SNS que vous spécifiez éventuellement doit également être configurée.
Ce qui suit décrit les tâches liées à l'utilisation de politiques AWS gérées pour fournir des autorisations, mais en fonction de votre environnement, vous souhaiterez peut-être limiter les autorisations autorisées.
Pour l'utilisateur IAM connecté à l'éditeur de requêtes v2, modifiez l'utilisateur IAM à l'aide de la console IAM (). [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
+ Outre les autorisations nécessaires pour exécuter les opérations Amazon Redshift et Query Editor v2, associez `AmazonEventBridgeFullAccess` les politiques `AmazonRedshiftDataFullAccess` AWS gérées à un utilisateur IAM.
+ Vous pouvez également attribuer les autorisations à un rôle et attribuer le rôle à l'utilisateur.
Attachez une politique qui accorde l'autorisation `sts:AssumeRole` à l'ARN de ressource du rôle IAM que vous spécifiez lors de la définition de la requête planifiée. Pour en savoir plus sur l'endossement de rôles, consultez [Octroi d'autorisations à un utilisateur pour endosser un rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_permissions-to-switch.html) dans le *Guide de l'utilisateur IAM*.
L'exemple suivant illustre une politique d'autorisation qui endosse le rôle IAM `myRedshiftRole` dans le compte `123456789012`. Le rôle IAM `myRedshiftRole` est également le rôle IAM qui est attaché au cluster ou au groupe de travail où s'exécute la requête planifiée.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeIAMRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::123456789012:role/myRedshiftRole"
]
}
]
}
```
------
Mettez à jour la politique d'approbation du rôle IAM utilisé pour planifier la requête afin de permettre à l'utilisateur IAM de l'endosser.
```
{
"Sid": "AssumeRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/myIAMusername"
},
"Action": "sts:AssumeRole"
}
]
}
```
Pour le rôle IAM que vous spécifiez pour autoriser l'exécution de la requête planifiée, modifiez le rôle IAM à l'aide de la console IAM (). [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
+ Associez `AmazonRedshiftDataFullAccess` les politiques `AmazonEventBridgeFullAccess` AWS gérées au rôle IAM. La politique gérée `AmazonRedshiftDataFullAccess` accepte uniquement l'autorisation `redshift-serverless:GetCredentials` pour les groupes de travail Redshift sans serveur balisés avec la clé `RedshiftDataFullAccess`.
# Authentification d’une requête planifiée
Lorsque vous planifiez une requête, vous utilisez l'une des méthodes d'authentification suivantes lors de l'exécution SQL. Les entrées à effectuer dans l'éditeur de requête v2 varient en fonction de la méthode utilisée. Ces méthodes d'authentification sont prises en charge par l'API de données utilisée pour exécuter vos instructions SQL.
L'utilisateur ou le rôle de base de données utilisé pour exécuter la requête doit disposer des privilèges de base de données nécessaires. Par exemple, pour accorder des privilèges `IAMR:MyRedshiftQEv2Scheduler` à la table `mytable`, exécutez la commande SQL suivante.
```
GRANT all ON TABLE mytable TO "IAMR:MyRedshiftQEv2Scheduler";
```
Pour afficher la liste des utilisateurs de base de données de votre cluster ou groupe de travail, interrogez la vue système `PG_USER_INFO`.
**Note**
Tout groupe de travail Redshift sans serveur pour lequel vous planifiez des requêtes doit être balisé avec la clé `RedshiftDataFullAccess`. Pour plus d’informations, consultez [Autorisation de l’accès à l’API de données Amazon Redshift](data-api-access.md).
Au lieu de baliser le groupe de travail, vous pouvez également ajouter une politique en ligne au rôle IAM (spécifié avec la planification) qui autorise `redshift-serverless:GetCredentials`. Par exemple :
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "UseTemporaryCredentialsForAllServerlessWorkgroups",
"Effect": "Allow",
"Action": "redshift-serverless:GetCredentials",
"Resource": [
"arn:aws:redshift-serverless:*:*:workgroup/*"
]
}
]
}
```
**AWS Secrets Manager**
Avec cette méthode, fournissez une valeur secrète pour le paramètre **secret-arn** qui est stocké dans AWS Secrets Manager. Ce secret contient des informations d’identification pour vous connecter à votre base de données. Vous avez peut-être créé un secret avec les informations d’identification appropriées lorsque vous avez créé votre cluster ou votre groupe de travail. Le secret doit être étiqueté avec la clé `RedshiftDataFullAccess`. Si la clé de balise n'est pas déjà présente, utilisez la AWS Secrets Manager console pour l'ajouter. Pour plus d’informations sur la création d’un secret, consultez [Création d’un secret pour les informations d’identification de connexion à une base de données](redshift-secrets-manager-integration-create.md).
Pour plus d’informations sur les autorisations minimales, consultez [Création et gestion des secrets avec AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/managing-secrets.html) dans le *Guide de l’utilisateur AWS Secrets Manager *.
**Informations d’identification temporaires**
Avec cette méthode, indiquez le **Nom de la base de données** et l'**Utilisateur de la base de données** pour vous connecter à une base de données située dans un cluster. Vous devez simplement indiquer le **Nom de la base de données** au moment de vous connecter à une base de données d'un groupe de travail.
Lorsque vous vous connectez à un cluster, la politique `AmazonRedshiftDataFullAccess` accorde à l'utilisateur de base de données nommé `redshift_data_api_user` une autorisation pour `redshift:GetClusterCredentials`. Si vous souhaitez utiliser un autre utilisateur de base de données pour exécuter l'instruction SQL, ajoutez une politique au rôle IAM attaché à votre cluster pour autoriser `redshift:GetClusterCredentials`. L’exemple de stratégie suivant autorise les utilisateurs de base de données `awsuser` et `myuser`.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "UseTemporaryCredentialsForAllDbUsers",
"Effect": "Allow",
"Action": "redshift:GetClusterCredentials",
"Resource": [
"arn:aws:redshift:*:*:dbuser:*/awsuser",
"arn:aws:redshift:*:*:dbuser:*/myuser"
]
}
]
}
```
# Configuration d'autorisations pour consulter l'historique des requêtes planifiées
Pour permettre aux utilisateurs de consulter l'historique des requêtes planifiées, modifiez le rôle IAM (spécifié avec la planification) **Relations d'approbation** pour ajouter les autorisations.
Voici un exemple de politique de confiance dans un rôle IAM qui permet à l'utilisateur IAM de consulter l'historique *myIAMusername* des requêtes de planification. Au lieu d'accorder à un utilisateur IAM l'autorisation `sts:AssumeRole`, vous pouvez choisir d'accorder à un rôle IAM cette autorisation.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"redshift.amazonaws.com",
"redshift-serverless.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
},
{
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Sid": "AssumeRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/myIAMusername"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
# Surveillance de la requête planifiée
Pour la rubrique Amazon SNS que vous spécifiez pour l'envoi de notifications par e-mail, créez la rubrique Amazon SNS à l'aide de l'éditeur de requête v2 en accédant à la section **Notifications SNS**, choisissez **Activer** pour la surveillance, puis créez la rubrique avec **Créer une rubrique SNS**. L'éditeur de requêtes v2 crée la rubrique Amazon SNS et ajoute un principal de service à la politique d'accès d'Amazon. EventBridge Voici un exemple de **Statégie d'accès** qui est créé dans la rubrique Amazon SNS. Dans l'exemple, les Région AWS *us-west-2* rubriques Compte AWS *123456789012*,, et Amazon SNS *select-version-pdx-testunload* sont utilisées.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "Allow_Publish_Events",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sns:Publish",
"Resource": "arn:aws:sns:us-west-2:123456789012:select-version-pdx-testunload"
}
]
}
```
------
Lorsque la requête planifiée est exécutée, Amazon SNS envoie des e-mails de AWS notification. L'exemple suivant montre un e-mail envoyé à *myemail@example.com* pour une requête planifiée *QS2-may25a* qui s'est exécuté Région AWS *eu-north-1* dans le cadre de la Compte AWS *123456789012* rubrique de notification Amazon SNS. *may25a-SNS*
```
{"version":"0","id":"8e4323ec-5258-7138-181b-91290e30ff9b","detail-type":"Scheduled Event","source":"aws.events","account":"123456789012","time":"2023-05-25T15:22:00Z",
"region":"eu-north-1","resources":["arn:aws:events:eu-north-1:123456789012:rule/QS2-may25a"],"detail":{}}
--
If you wish to stop receiving notifications from this topic, please click or visit the link below to unsubscribe:
https://sns.eu-north-1.amazonaws.com/unsubscribe.html?SubscriptionArn=arn:aws:sns:eu-north-1:123456789012:may25a-SNS:0c1a3d05-39c2-4507-bc3d-47250513d7b0&Endpoint=myemail@example.com
Please do not reply directly to this email. If you have any questions or comments regarding this email, please contact us at https://aws.amazon.com/support
```
# Résolution des problèmes liés à la configuration de la planification d'une requête
Si vous rencontrez des problèmes pour planifier une requête, tenez compte des points suivants.
**Les requêtes ne s'exécutent pas**
Vérifiez que le rôle IAM utilisé dans la planification est autorisé à obtenir les informations d'identification temporaires du cluster. L'autorisation pour les clusters provisionnés est `redshift:GetClusterCredentialsWithIAM`. L'autorisation pour les groupes de travail Redshift sans serveur est `redshift-serverless:GetCredentials`.
**L'historique planifié ne s'affiche pas**
L'utilisateur IAM ou le rôle IAM utilisé pour se connecter à la AWS console n'a pas été ajouté à la politique de confiance du rôle IAM utilisé pour planifier la requête.
Lors de l'utilisation AWS Secrets Manager de la requête planifiée pour se connecter, vérifiez que le secret est marqué avec la clé`RedshiftDataFullAccess`.
Si la requête planifiée utilise une AWS Secrets Manager connexion, le rôle IAM utilisé pour planifier la requête doit avoir l'équivalent d'une politique gérée `SecretsManagerReadWrite` attachée au rôle.
**L'état de l'historique des requêtes est `Failed`**
Consultez la vue système SYS\$1QUERY\$1HISTORY pour obtenir des détails sur les raisons de l'échec de la requête. Il est possible que l'utilisateur ou le rôle de base de données ayant servi à exécuter la requête ne disposait pas des privilèges nécessaires pour exécuter la requête SQL. Pour plus d’informations, consultez [Authentification d’une requête planifiée](query-editor-v2-schedule-query-authentication.md).
Les requêtes SQL suivantes interrogent la vue SYS\$1QUERY\$1HISTORY pour renvoyer les requêtes ayant échoué.
```
SELECT user_id, query_id, transaction_id, session_id, database_name, query_type, status, error_message, query_text
FROM sys_query_history
WHERE status = 'failed';
```
Pour rechercher des informations à propos de l'échec d'une requête planifiée spécifique, consultez [Afficher les résultats d'une requête planifiée avec AWS CloudShell](query-editor-v2-schedule-query-troubleshooting-cloudshell.md).
# Afficher les résultats d'une requête planifiée avec AWS CloudShell
Vous pouvez l'utiliser AWS CloudShell pour obtenir des informations sur une requête de planification. Vous devez disposer des autorisations appropriées pour exécuter les AWS CLI commandes indiquées dans la procédure suivante.
**Pour afficher les résultats d'une requête planifiée**
1. Sur la AWS console, ouvrez l'invite de AWS CloudShell commande. Pour plus d'informations AWS CloudShell, voir [Contenu](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html) du *guide AWS CloudShell de l'AWS CloudShell utilisateur*.
1. Endossez le rôle IAM de la requête planifiée. Pour endosser le rôle, recherchez le rôle IAM associé à la requête planifiée dans l'éditeur de requête v2 et utilisez-le dans la commande de l' AWS CLI dans AWS CloudShell. Par exemple, pour le rôle `scheduler`, entrez une commande AWS STS pour endosser le rôle utilisé par la requête planifiée.
```
aws sts assume-role --role-arn "arn:aws:iam::123456789012:role/scheduler" --role-session-name "scheduler-test"
```
Les informations d'identification renvoyées se présentent comme suit.
```
"Credentials": {
"AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"SessionToken": "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY...",
"Expiration": "2023-08-18T18:19:44+00:00"
},
"AssumedRoleUser": {
"AssumedRoleId": "AROA35B2NH6WBTP7ONL4E:scheduler-test",
"Arn": "arn:aws:sts::123456789012:assumed-role/scheduler/scheduler-test"
}
}
```
1. Créez des variables environnementales en AWS CLI utilisant les informations d'identification affichées lorsque vous assumez le rôle IAM. Vous devez utiliser ces jetons avant qu'ils n'arrivent à expiration. Par exemple, vous entrez ce qui suit dans AWS CloudShell.
```
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_SESSION_TOKEN=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY...
```
1. Pour voir l'erreur d'une requête ayant échoué, exécutez la AWS CLI commande pour décrire une instruction. L'ID de l'instruction SQL est tiré du champ **ID** figurant dans l'**Historique de planification** d'une requête planifiée dans l'éditeur de requête v2.
```
aws redshift-data describe-statement --id 130d2620-05d2-439c-b7cf-815d9767f513
```
Dans cet exemple, la requête SQL planifiée `select * from users limit 100` génère une erreur SQL indiquant que la table `users` n'existe pas.
```
{
"CreatedAt": "2023-08-18T17:39:15.563000+00:00",
"Duration": -1,
"Error": "ERROR: relation \"users\" does not exist",
"HasResultSet": false,
"Id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"QueryString": "select * from users limit 100\n—RequestID=a1b2c3d4-5678-90ab-cdef-EXAMPLE22222; TraceID=1-633c5642-4039308d03f3a0ba53dbdf6f",
"RedshiftPid": 1073766651,
"RedshiftQueryId": 0,
"ResultRows": -1,
"ResultSize": -1,
"Status": "FAILED",
"UpdatedAt": "2023-08-18T17:39:16.116000+00:00",
"WorkgroupName": "default"
}
```