Variable SQLLOGDIR not found

Version imprimable

08/09/2017, 14h45
janlouk

Variable SQLLOGDIR not found

Bonjour à tous,

J'installe les scripts OLA sur mon instance de management (ce n'est pas la première fois que je le fais), en faisant du multi serveur pour les jobs (ça c'est la première fois). J'ignore si c'est parce que c'est du multi serveur, mais je n'arrive pas à faire tourner les jobs.

Que je mette le job sur du 2008, 2012 cela ne fonctionne pas.

J'ai rien touché sauf le chemin du directory

Code:

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d DBA -Q "EXECUTE [dbo].[DatabaseBackup] @Databases = 'SYSTEM_DATABASES', @Directory = 'C:\Temp', @BackupType = 'FULL', @Verify = 'Y', @CleanupTime = NULL, @CheckSum = 'Y', @LogToTable = 'Y'" -b

Je trouve ici des infos https://docs.microsoft.com/en-us/sql...s-in-job-steps, donc je tente de mettre ceci en plus

Code:

$(ESCAPE_SQUOTE(SQLLOGDIR))

voir même

Code:

$(ESCAPE_SQUOTE("SQLLOGDIR"))

ou encore

Code:

$(ESCAPE_SQUOTE(''SQLLOGDIR''))

ou encore

Code:

$(ESCAPE_SQUOTE('L:\Log'))

juste après (SRVR)) mais rien n'y fait. Là je ne sais pas trop quoi faire.

J'ai également coché l'option Token replace 'Replace tokens for all job responses to alerts' dans Alert system des properties de l'agent, et je l'ai redémarré mais rien n'y fait.

Une idée?
08/09/2017, 15h10
janlouk

Par contre, si je le lance sur du SQL 2016, là je n'ai pas de problème. Pourtant c'est exactement le même job vu que je l'édite sur le Master, et donc il est répliqué pareil sur le Target. Et donc tous mes target.
08/09/2017, 15h42
janlouk

J'ai oublié de mettre le message d'erreur du job : Unable to start execution of step 1 (reason: Variable SQLLOGDIR not found). The step failed.
09/09/2017, 13h49
rudib

Hello,

Courage avec les tokens ! C'est quand même une sacrée m*** ! Quelle est la chaîne finale que tu essaie d'exécuter dans le step, avec ton token ?
09/09/2017, 17h36
janlouk

La chaîne finale? J'ai mis tout le code de la step1 tout en haut dans mon premier message. Moi pas te comprendre Rudi :)
09/09/2017, 19h44
rudib

J'ai peut-être mal compris. Après ta ligne, tu écris "donc je tente de mettre ceci en plus", et tu places le token SQLLOGDIR, que je ne vois pas dans ta première ligne. Je ne comprends pas pourquoi tu as besoin du répertoire des logs, et ce que tu veux en faire.
11/09/2017, 07h37
janlouk

Ok, je comprends. En fait, la première ligne est celle donc d'Ola. Mais comme je ne connais pas du tout cette matière des token, j'ai cherché sur internet et je pensais que je devais ajouter du code. Donc j'ai inséré une des lignes dont je parle après, par exemple:

Donc j'ai par exemple essayé de mettre

Code:

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) $(ESCAPE_SQUOTE(SQLLOGDIR)) -d DBA -Q "EXECUTE [dbo].[DatabaseBackup] @Databases = 'SYSTEM_DATABASES', @Directory = 'C:\Temp', @BackupType = 'FULL', @Verify = 'Y', @CleanupTime = NULL, @CheckSum = 'Y', @LogToTable = 'Y'" -b

Ou encore

Code:

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) $(ESCAPE_SQUOTE('L:\Log')) -d DBA -Q "EXECUTE [dbo].[DatabaseBackup] @Databases = 'SYSTEM_DATABASES', @Directory = 'C:\Temp', @BackupType = 'FULL', @Verify = 'Y', @CleanupTime = NULL, @CheckSum = 'Y', @LogToTable = 'Y'" -b

Enfin, j'ai essayé un peu de tout pour résoudre ce problème que je ne connais pas. Et comme je disais, je n'ai pas ce problème sur une instance 2016. Par contre, je l'ai sur 2008 (pas R2) et 2012.
12/09/2017, 10h37
hmira

Citation:

Envoyé par janlouk

J'ai oublié de mettre le message d'erreur du job : Unable to start execution of step 1 (reason: Variable SQLLOGDIR not found). The step failed.

Bonjour,
Ne cherchez pas plus loin ! Le token (SQLLOGDIR) n'existe qu'à partir de SQL Server 2014.
Le token (SQLLOGDIR) n'est donc pas reconnu par SQL Server Agent dans les versions strictement antérieures à SQL Server Agent 2014, c.à.d. n'est pas reconnu sous 2012, 2008R2, 2008, etc.

A+
12/09/2017, 11h32
janlouk

Bonjour Hamid,

Ok, mais ce que je ne comprends pas c'est que j'ai déjà fait tourner ces jobs ailleurs (mais c'est vrai, en 2008 et 2012).

Mais pas en utilisant L'option Multi-Server (donc MSX et TSX).

Ca veut dire quoi? C'est que quand j'ai installé les scripts OLA sur une instance 2016 SP1 (donc c'est le MSX), et quand je le "partage" (donc sur le TSX), il a d'une manière (que j'ignore) "ajouter" ce fameux SQLLOGDIR ?

Une idée, comment je pourrais l'en empêcher ou le contourner pour les autres versions?
12/09/2017, 14h12
hmira
Bonjour,
Je n'ai pas étudié la question plus en détails, mais il peut y avoir effectivement un lien avec la config. MSX vs TSX
En effet, ce que j'ai compris, d'après la documentation, c'est que dans une config MSX / TSX les travaux , sauf erreur de ma part, sont transférés du MSX vers le TSX et les dits travaux sont exécutés par le TSX (et non pas par le MSX !).
Donc, d'après moi, si la version du serveur cible TSX est strictement antérieure à SQL Serveer 2014, il ne reconnaîtra pas le token SQLLOGDIR et générera fatalement une erreur.
En outre, quand vous regardez les scripts ola (vers la ligne 4787) il y a bien le test suivant :
Code:

1 2 3 4 IF @Version >= 12 BEGIN SET @TokenLogDirectory = '$' + '(ESCAPE_SQUOTE(SQLLOGDIR))' END
Remarque : Le test "@Version >= 12" signifie évidemment que la version majeure de l'instance est supérieure ou égale à SQL Server 2014

Vérifiez à tout hasard que vous utilisesz bien la dernière version des scripts ola.

Si le problème persiste, c.à.d. si vous constatez un bug (?), vous pourrez agir directement et corriger les scripts ola (bloc ci-dessus). Il suffit d'initialiser la variable @TokenLogDirectory par d'autres techniques dans la partie ELSE (partie à rajouter...) pour récupérer le chemin des "errors log" depuis la registry ou par d'autre moyen, par exemple :

Code:

xp_readerrorlog 0, 1, N'Logging SQL Server messages in file', NULL, NULL, NULL, N'asc'

A+
12/09/2017, 17h09
hmira
Citation:

Envoyé par hmira

Si le problème persiste, c.à.d. si vous constatez un bug (?), vous pourrez agir directement et corriger les scripts ola (bloc ci-dessus). Il suffit d'initialiser la variable @TokenLogDirectory par d'autres techniques dans la partie ELSE (partie à rajouter...) pour récupérer le chemin des "errors log" depuis la registry ou par d'autre moyen

Holà, holà, holà ! je parle bien des scripts ola !

Je réponds à moi-même et je m'insurge en faux contre ma propre citation ci-dessus ! Le reste des mes propos restent toutefois valables.
En effet, les travaux (Jobs) sont créés au moment de l'installation des scripts ola.
Au moment de l'installation, nombre de paramètres des travaux (Jobs) sont définis en fonction de la version de l'instance en cours sur laquelle les scripts ola ont été déroulés.
Parmi ces paramètres, il y a le paramètre @OutputFileDirectory qui vient en tant que argument (valeur) pour le paramètre @output_file_name de la procédure système sp_add_jobstep. Schématiquement on a ceci (voir vers ligne 4882)
Code:

1 2 sp_add_jobstep ... @output_file_name = @OutputFileDirectory
Ci-dessous la définition du paramètre output_file_name de la procédure sp_add_jobstep
[ @output_file_name= ] 'file_name'
The name of the file in which the output of this step is saved. file_name is nvarchar(200), with a default of NULL. file_name can include one or more of the tokens listed under command. This parameter is valid only with commands running on the Transact-SQL, CmdExec, PowerShell, Integration Services, or Analysis Services subsystems.

Dans notre scénario, Serveur SQL 2016, la variable @OutputFileDirectory contient, ine fine, une chaine de caractères comme ceci :
@OutputFileDirectory = N'$(ESCAPE_SQUOTE(SQLLOGDIR))\.... \xxxx.txt'

Donc au final, le Job est créé avec une commande ressemblant à ceci :
Code:

1 2 sp_add_jobstep ... @output_file_name = N'$(ESCAPE_SQUOTE(SQLLOGDIR))\.... \xxxx.txt'
Le problème c'est que dans une configuration MSX / TSX, à ce stade, le Job est déjà créé sur le serveur SQL 2016 et sera exécuté ultérieurement sur un autre serveur 2008 ou 2012 qui ne reconnaîtra pas le token (SQLLOGDIR) et générera une erreur.

En conclusion :
- D'après mon analyse, les scripts ola ne sont pas prévus pour être utilisés dans une configuration MSX / TSX où le serveur maitre est dans une version différente des Serveurs cibles.
- Ceci dit, ce problème lié au paramètre @output_file_name de la commande sp_add_jobstep n'est pas spécifique aux scripts ola. C'est un problème général, et c'est vraisemblablement la raison pour la quelle le token (SQLLOGDIR) a été rajouté à partir de SQL Server 2014.
- La seule solution que j'entrevois, pour apporter une solution à ce problème, serait de modifier, après la création des Jobs ola, la valeur du paramètre @output_file_name par la commande sp_update_jobstep Exemple :
Code:

1 2 3 sp_update_jobstep .... , @output_file_name = N'C:\....\zzz.txt'
Et ce, pour chacun des Jobs ola.

A+
13/09/2017, 14h09
janlouk

Merci, je ne pourrai tester ça que la semaine prochaine, donc je donnerai à feedback dans quelques jours.

Bonjour Hamid,

Si j'ai bien compris, je dois lui demander d'utiliser un autre paramètre que cela par "défaut".

J'ai un peu tout essayé, en changeant le contenu du @output_file_name mais je rencontre le même message.
Code:

1 2 sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d DBA -Q "EXECUTE [dbo].[DatabaseBackup] @Databases = 'SYSTEM_DATABASES', @Directory = 'C:\Temp\', @BackupType = 'FULL', @Verify = 'Y', @CleanupTime = NULL, @output_file_name = N'C:\Temp\test.txt' , @CheckSum = 'Y', @LogToTable = 'Y'" -b
Je ne sais pas ce que je fais de mal, car tes explications sont claires....

Citation:

Envoyé par janlouk

Je ne sais pas ce que je fais de mal, car tes explications sont claires....

Non ! il ne faut pas modifier le texte de la commande de l'étape du Job en y ajoutant le texte "@output_file_name = N'C:\Temp\test.txt" !
Au lieu de cela, il te faudra modifier la propriété @output_file_name de l'étape du job (nuance !) comme l'exemple qui suit
Code:

1 2 3 4 EXEC msdb.dbo.sp_update_jobstep @job_id=N'c107df63-d370-44df-882a-bb9014565b1e', -- à remplacer par l'identifiant du Job @step_id=1 , -- à remplacer par l'identifiant de l'étape @output_file_name=N'C:\Temp\test.txt' -- à remplacer par le chemin et nom complet du fichier Output
Remarque : Sous SQL Server 2014 et supérieure, par défaut, la propriété @output_file_name de l'étape du Job contient l'expression, avec des tokens, ci-dessous :

Code:

N'$(ESCAPE_SQUOTE(SQLLOGDIR))\DatabaseBackup_$(ESCAPE_SQUOTE(JOBID))_$(ESCAPE_SQUOTE(STEPID))_$(ESCAPE_SQUOTE(STRTDT))_$(ESCAPE_SQUOTE(STRTTM)).txt'

Cette expression est évaluée en mode "Runtime", c.à.d. au moment de l'exécution du Job.

Tu peux donc finalement tester ceci :
Code:

1 2 3 4 EXEC msdb.dbo.sp_update_jobstep @job_id=N'c107df63-d370-44df-882a-bb9014565b1e', -- à remplacer par l'identifiant du Job @step_id=1 , -- à remplacer par l'identifiant de l'étape @output_file_name=N'C:\Temp\DatabaseBackup_$(ESCAPE_SQUOTE(JOBID))_$(ESCAPE_SQUOTE(STEPID))_$(ESCAPE_SQUOTE(STRTDT))_$(ESCAPE_SQUOTE(STRTTM)).txt' -- remplacer le cas échéant le chemin de la racine "C:\Temp"
Cela revient tout simplement à remplacer le token $(ESCAPE_SQUOTE(SQLLOGDIR)), évalué en mode "Runtime", c.à.d. au moment de l'exécution, mais qui n'est malheureusement pas reconnu par SQL Server 2012 et 2008 R2, par le chemin fixe (du moins la racine qui pose problème) exprimé de manière littérale comme par exemple "C:\Temp".

A+

Complément d'info.

Ci-dessous la signature de la procédure ola [dbo].[DatabaseBackup]

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
CREATE PROCEDURE [dbo].[DatabaseBackup]
@Databases nvarchar(max) = NULL,
@Directory nvarchar(max) = NULL,
@BackupType nvarchar(max),
@Verify nvarchar(max) = 'N',
@CleanupTime int = NULL,
@CleanupMode nvarchar(max) = 'AFTER_BACKUP',
@Compress nvarchar(max) = NULL,
@CopyOnly nvarchar(max) = 'N',
@ChangeBackupType nvarchar(max) = 'N',
@BackupSoftware nvarchar(max) = NULL,
@CheckSum nvarchar(max) = 'N',
@BlockSize int = NULL,
@BufferCount int = NULL,
@MaxTransferSize int = NULL,
@NumberOfFiles int = NULL,
@CompressionLevel int = NULL,
@Description nvarchar(max) = NULL,
@Threads int = NULL,
@Throttle int = NULL,
@Encrypt nvarchar(max) = 'N',
@EncryptionAlgorithm nvarchar(max) = NULL,
@ServerCertificate nvarchar(max) = NULL,
@ServerAsymmetricKey nvarchar(max) = NULL,
@EncryptionKey nvarchar(max) = NULL,
@ReadWriteFileGroups nvarchar(max) = 'N',
@OverrideBackupPreference nvarchar(max) = 'N',
@NoRecovery nvarchar(max) = 'N',
@URL nvarchar(max) = NULL,
@Credential nvarchar(max) = NULL,
@MirrorDirectory nvarchar(max) = NULL,
@MirrorCleanupTime int = NULL,
@MirrorCleanupMode nvarchar(max) = 'AFTER_BACKUP',
@AvailabilityGroups nvarchar(max) = NULL,
@Updateability nvarchar(max) = 'ALL',
@LogToTable nvarchar(max) = 'N',
@Execute nvarchar(max) = 'Y'

Tu constateras qu'aucun paramètre de la procédure ola [dbo].[DatabaseBackup] ne porte le nom @output_file_name

Le paramètre @output_file_name n'est donc pas un paramètre de la procédure ola dbo.DatabaseBackup comme tu l'as, par erreur, supposé !

Le paramètre @output_file_name est un paramètre des procédures systèmes sp_add_jobstep ou sp_update_jobstep, etc. utilisé, en mode runtime, par "SQL Server Agent" voir ci-dessous :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
sp_add_jobstep [ @job_id = ] job_id | [ @job_name = ] 'job_name'   
     [ , [ @step_id = ] step_id ]   
     { , [ @step_name = ] 'step_name' }   
     [ , [ @subsystem = ] 'subsystem' ]   
     [ , [ @command = ] 'command' ]   
     [ , [ @additional_parameters = ] 'parameters' ]   
     [ , [ @cmdexec_success_code = ] code ]   
     [ , [ @on_success_action = ] success_action ]   
     [ , [ @on_success_step_id = ] success_step_id ]   
     [ , [ @on_fail_action = ] fail_action ]   
     [ , [ @on_fail_step_id = ] fail_step_id ]   
     [ , [ @server = ] 'server' ]   
     [ , [ @database_name = ] 'database' ]   
     [ , [ @database_user_name = ] 'user' ]   
     [ , [ @retry_attempts = ] retry_attempts ]   
     [ , [ @retry_interval = ] retry_interval ]   
     [ , [ @os_run_priority = ] run_priority ]   
     [ , [ @output_file_name = ] 'file_name' ]   
     [ , [ @flags = ] flags ]   
     [ , { [ @proxy_id = ] proxy_id   
         | [ @proxy_name = ] 'proxy_name' } ]

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
sp_update_jobstep   
     {   [@job_id =] job_id | [@job_name =] 'job_name' }  , [@step_id =] step_id  
     [ , [@step_name =] 'step_name' ]  
     [ , [@subsystem =] 'subsystem' ]   
     [ , [@command =] 'command' ]  
     [ , [@additional_parameters =] 'parameters' ]  
     [ , [@cmdexec_success_code =] success_code ]  
     [ , [@on_success_action =] success_action ]   
     [ , [@on_success_step_id =] success_step_id ]  
     [ , [@on_fail_action =] fail_action ]   
     [ , [@on_fail_step_id =] fail_step_id ]  
     [ , [@server =] 'server' ]   
     [ , [@database_name =] 'database' ]  
     [ , [@database_user_name =] 'user' ]   
     [ , [@retry_attempts =] retry_attempts ]  
     [ , [@retry_interval =] retry_interval ]   
     [ , [@os_run_priority =] run_priority ]  
     [ , [@output_file_name =] 'file_name' ]   
     [ , [@flags =] flags ]  
     [ ,  {   [ @proxy_id = ] proxy_id   
            | [ @proxy_name = ] 'proxy_name' }

@output_file_name n'est pas non plus un paramètre de la commande sqlcmd ! Pour cela, il y a le commutateur -o

A+

Hamid, 10000000 mercis, tu as résolu un problème très bloquant pour moi. j'ai fait ça et ça fonctionne maintenant.
Code:

1 2 3 4 EXEC msdb.dbo.sp_update_jobstep @job_name=N'MSX-DatabaseBackup - SYSTEM_DATABASES - FULL', @step_id=1 , @output_file_name=N'\\server1\SQL\Backup\BackupTxtResult\DatabaseBackup_$(ESCAPE_SQUOTE(JOBID))_$(ESCAPE_SQUOTE(STEPID))_$(ESCAPE_SQUOTE(STRTDT))_$(ESCAPE_SQUOTE(STRTTM)).txt'
Merci
Merci
Merci
Merci :D