May 03, 2016, updated at May 04, 2016 (UTC)

3181

Transact-SQL-Skript wird in Aufgabenplanung nicht ausgeführt, im SQL Management Studio aber schon

Hallo zusammen,

ich habe ein Skript, das ein vollständiges Backup aller Datenbanken auf dem MSSQL-Server durchführt. Nun möchte ich, dass das Skrip in einer Aufgabe täglich ausgeführt wird. Das funktioniert aber nicht (die Ausführung per Aufgabenplanung wird gewünscht, damit man sie noch mit anderen Skripten, z.B. PowerShell, verbinden kann).
Dasselbe Skript wird auf einem anderen Server auf dieselbe Weise ausgeführt, da funktioniert es einwandfrei. Ich weiß nicht, warum es diesmal nicht funktioniert.
Die Aufgabe wird mit dem Admin-Konto ausgeführt. Ich habe es auch mit den höchsten Privilegien versucht.
Führe ich die Aufgabe manuell aus, startet sie und wird nach 10 Sekunden angeblich erfolgreich beendet.
Führe ich das Skript als Abfrage im SQL Management Studio aus, funktioniert es einwandfrei.
Beim Datenbankserver wird mit Windows-Anmeldung (derselbe Admin) gearbeitet. Der Admin hat Vollzugriff auf das Zielverzeichnis.
Woran kann das liegen?

Das OS ist Windows Server 2012 R2 mit SQL Server 2014 SP1.
Das Skript wird in der Aufgabenplanung folgendermaßen aufgerufen:
Programmaufruf: sqlcmd
Argumente: -i "C:\Users\Administrator\Skripte\SQLBackup.sql"

Hier ist das Skript:

DECLARE @name VARCHAR(50) -- database name  
DECLARE @path VARCHAR(256) -- path for backup files  
DECLARE @fileName VARCHAR(256) -- filename for backup  
DECLARE @fileDate VARCHAR(20) -- used for file name

 
-- specify database backup directory  
SET @path = 'D:\SQL-Backup\MAIN\'  

 
-- specify filename format
-- SELECT @fileDate = CONVERT(VARCHAR(20),GETDATE(),112) 
SELECT @fileDate = CONVERT(VARCHAR(20),GETDATE(),112) + REPLACE(CONVERT(VARCHAR(20),GETDATE(),108),':','') -- mit Datum im Namen  

 
DECLARE db_cursor CURSOR FOR  
SELECT name 
FROM master.dbo.sysdatabases 
-- WHERE name NOT IN ('master','model','msdb','tempdb')  -- exclude these databases  
WHERE name NOT IN ('tempdb')  
 
OPEN db_cursor   
FETCH NEXT FROM db_cursor INTO @name   

 
WHILE @@FETCH_STATUS = 0   
BEGIN   
       SET @fileName = @path + @name + '_' + @fileDate + '.BAK'    
       BACKUP DATABASE @name TO DISK = @fileName

       FETCH NEXT FROM db_cursor INTO @name   
END   

 
CLOSE db_cursor   
DEALLOCATE db_cursor

Please also mark the comments that contributed to the solution of the article

Content-Key: 303528

Url: https://administrator.de/contentid/303528

Printed on: April 18, 2024 at 10:04 o'clock

6 Comments

Latest comment

Moin, Moin,

Das funktioniert aber nicht (die Ausführung per Aufgabenplanung wird gewünscht, damit man sie noch mit anderen Skripten, z.B. PowerShell, verbinden kann).

Willst du uns auch das Betriebssystem, SQL-Server samt Service Packversion verraten oder sollen wir raten?
Wie rufst du das Skript über die Aufgabenplanung überhaupt auf?

Gruß,
Dani

Hallo,

Zitat von @Irolan:
Aufgabe täglich ausgeführt wird. Das funktioniert aber nicht

Hat der ebtreffende denn auch Rechte im SQL Server?

Der Admin hat Vollzugriff auf das Zielverzeichnis.

Juckt den SQL vermutlich überhaupt nicht.

Woran kann das liegen?

Falsche Anwendung der Skripte, Rechte....

Dasselbe Skript wird auf einem anderen Server auf dieselbe Weise ausgeführt, da funktioniert es einwandfrei

Dann schau dort doch genau nach warum es dort aber da nicht....

Gruß,
Peter

Das OS ist Windows Server 2012 R2 mit SQL Server 2014 SP1.
Das Skript wird folgendermaßen aufgerufen:
Programmaufruf: sqlcmd
Argumente: -i "C:\Users\Administrator\Skripte\SQLBackup.sql"

Falsche Anwendung der Skripte, Rechte....

Ich glaube nicht, dass es am Skript liegt, da es auf dem anderen Server funktioniert und vom SQL Management Studio aus ja klappt.
Ich habe die Rechte der Administratoren beider Server im SQL verglichen und sehe keinen Unterschied.

Dann schau dort doch genau nach warum es dort aber da nicht....

Jetzt rate mal, was ich gemacht habe, bevor ich mich entschlossen habe, hier zu posten.
Der einzige Unterschied, den ich gefunden habe, der auf dem es geht ist ein 2012er, der auf dem es nicht geht ein 2012 R2. Aber daran wirds kaum liegen.

Dann schau Dir mal die Fehlermeldungen an.
Ach, die werden ja gar nicht gespeichert ...

Also mal Grundlegendes:
Pack den Aufruf in eine Batch und leite die Ausgabe in eine Textdatei um.
Batch:

sqlcmd -i "C:\Users\Administrator\Skripte\SQLBackup.sql" > c:\temp\Fehlerprotokoll.txt 2>&1  

Und die dann in der Aufgabenplanung aufrufen.
SQLCMD sagt sicherlich irgendwas dazu, man müsste es nur lesen.

Wow, ganz ehrlich Leute. Ihr habt vielleicht mehr Ahnung als ich (deshalb frage ich ja auch nach), aber der Umgangston, der einem hier entgegengebracht wird, ist echt verbesserungswürdig. Vielleicht könnte man es ja mal mit etwas weniger Sarkasmus und weniger von oben herab versuchen. Es gibt vielleicht Leute, die noch nicht alles wissen, auch wenn es für euch Grundlagen sind.

Jedenfalls, ich konnte das Problem lösen, indem ich an den Befehl ein
-S "<Servername>\<Instanzname>"
angehängt habe. Seltsam, dass der zweite Server das braucht, beim ersten gings ohne.

Moin Irolan,

hr habt vielleicht mehr Ahnung als ich (deshalb frage ich ja auch nach), aber der Umgangston, der einem hier entgegengebracht wird, ist echt verbesserungswürdig

Welchen Kommentar meinst du?

Seltsam, dass der zweite Server das braucht, beim ersten gings ohne.

Eine Möglichkeit wäre, dass es bei Server A eine Standardinstanz und auf Server B diese bei der Installation umbenannt wurde.

Gruß,
Dani

German solved Question Windows Server Microsoft

Hotly discussed

How to set up and configure a Linux GRE tunnelAlexWisha - 3 Comments

End of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment