Denis était très proche. Mais la solution réelle a été un peu échangée. Comme PowerShell ne peut pas vérifier le processeur sur une durée, seule l'utilisation actuelle, la vérification SQL Server devait être utilisée.
Alors ma première étape du travail a été d'exécuter un script PowerShell qui vérifie si l'heure système actuelle se situe entre les deux contraintes de temps. Si c'est le cas, le script PowerShell ne fait rien. Le travail SQL Server interprète cela comme un succès.
Le Job passe ensuite à la dernière étape et exécute la requête de mise à jour.
Si toutefois l'heure actuelle est en dehors de la plage, j'effectue une Start-Time -s 600
pause du script PowerShell pendant 10 minutes (en simulant l'exigence "une fois tous les 5 à 10 minutes). Ceci permet d'empêcher l'agent SQL Server d'essayer constamment d'exécuter ce travail. .
Après 10 minutes, le script PowerShell génère une erreur personnalisée. Depuis que j'ai $ErrorActionPreference = "Stop"
au début du script, le script PowerShell cesse de s'exécuter après l'erreur. Cette étape est très importante.
Étant donné que powershell s'est arrêté et n'est pas revenu, l'Agent SQL Server interprète cela comme un échec et ne passera pas à l'étape qui exécute la requête de mise à jour.
PS Vous m'avez conduit dans la bonne direction. Si j'avais assez de réputation, je voterais pour vous.
Edit: Ajout du script Powershell
$ErrorActionPreference = "Stop"
$StartTime = Get-Date "12:00 AM"
$EndDate = Get-Date "05:00 AM"
$CurrentDate = Get-Date
$ExecuteJob = $StartTime -lt $CurrentDate -and $EndDate -gt $CurrentDate
if(!$ExecuteJob){
Start-Sleep -s 600
throw "Current Time not within Server downtime"
}