SQL Server xp_delete_file nicht das Löschen von Dateien

https://stackoverflow.com/questions/212603

03-07-2019
|

Frage

Ich versuche, einige SQL zu schreiben, die Dateien vom Typ ‚.7z‘ löschen wird, die als 7 Tage älter sind.

Hier ist, was ich habe, dass nicht funktioniert:

DECLARE @DateString CHAR(8)
SET @DateString = CONVERT(CHAR(8), DATEADD(d, -7, GETDATE()), 1)
EXECUTE master.dbo.xp_delete_file 0, 
                  N'e:\Database Backups',N'7z', @DateString, 1

ich auch habe versucht, die Änderung das ‚1‘ ein, das Ende zu einem ‚0‘.

Das gibt ‚Erfolg‘, aber die Dateien werden nicht gelöscht zu werden.

Ich bin mit SQL Server 2005, Standard, w / SP2

Lösung

ein ähnliches Problem hatte, fand verschiedene Antworten. Hier ist, was ich gefunden habe.

Sie können nicht 7z-Dateien mit xp_delete_file löschen. Dies ist eine nicht dokumentieren erweiterte gespeicherte Prozedur, die ein Überbleibsel aus SQL ist 2000. Es überprüft die erste Zeile der Datei gelöscht werden, um sicherzustellen, dass es entweder eine SQL-Sicherungsdatei oder eine SQL-Berichtsdatei. Es ist nicht von der Dateierweiterung basiert überprüfen. Von dem, was ich die beabsichtigte Verwendung zu sammeln ist in Wartungspläne zu bereinigen alte Backups und Plan-Berichte.

Hier ist eine Probe auf Tomalak den Link basierte Backup-Dateien zu löschen, die älter als 7 Tage. Was stellt Personen ist das Schema ‚sys‘, der Schrägstrich in dem Ordnerpfad, und kein Punkt in der Dateierweiterung zu suchen. Der Benutzer, der SQL Server ausgeführt wird, wie benötigt auch löschen Berechtigungen für den Ordner haben.

DECLARE @DeleteDate datetime
SET @DeleteDate = DateAdd(day, -7, GetDate())

EXECUTE master.sys.xp_delete_file
0, -- FileTypeSelected (0 = FileBackup, 1 = FileReport)
N'D:\SQLbackups\', -- folder path (trailing slash)
N'bak', -- file extension which needs to be deleted (no dot)
@DeleteDate, -- date prior which to delete
1 -- subfolder flag (1 = include files in first subfolder level, 0 = not)

Beachten Sie, dass xp_delete_file in SP2 gebrochen und wird auf Report-Dateien nicht funktionieren; es gibt einen Hotfix für sie auf [ http://support.microsoft.com/kb/938085]. Ich habe es nicht mit SP3 getestet.

Da es nicht dokumentiert ist, kann xp_delete_file weggehen oder Änderung in zukünftigen Versionen von SQL Server. Viele Websites empfehlen einen Shell-Skript stattdessen die Deletionen zu tun.

Andere Tipps

AFAIK xp_delete_file nur Dateien, die von SQL Server 2005 (Backup-Dateien, Transaktionsprotokolle, ...) erkannt löschen. Vielleicht können Sie so etwas wie dies versuchen:

xp_cmdshell 'del <filename>'

Diese sp wird nur nur native SQL-Server-Backup-Dateien oder native Wartungsbericht Dateien löschen (aus Sicherheitsgründen)

Wie Smink vorgeschlagen, dass Sie verwenden können,

xp_cmdshell 'del <filename>'

Mit den richtigen Berechtigungen für den Ordner.

Ich fand diese Frage, aber die Lösung galt nicht für mich (wie es BAK-Dateien waren, SQL Server selbst gemacht hatte, im Rahmen eines Wartungsplanes).

Das Problem in meinem Fall war die Sicherheit. Das Skript wurde als der Benutzer ausführen, die SQL Server gestartet wird (MSSQL) (in meinem Fall und wahrscheinlich die meisten Fälle „Netzwerkdienst“) haben keinen Zugriff auf den Ordner wurde versucht, das Löschen von Dateien in.

So fügt hinzu: "Netzwerkdienst" und Gewährung "ändern" geholfen.

ich viele verschiedenen Ansätze und Lösungen mehr Personen verfolgten gelesen hatte bei dem Versuch, das Problem mit der erweiterten gespeicherten Prozedur xp_delete zu lösen. Die Lösungen sind:

Seien Sie sicher, dass eine Periode nicht hat (.) In der Verlängerung, wenn die SSIS-Wartungsaufgabe zu konfigurieren.
Achten Sie darauf, auf der ersten Ebene Unterordner einbeziehen klicken, wenn sie für jede Datenbanksicherung vorhanden sein.
Achten Sie darauf, auf die Backup-Dateien an der Spitze klicken. Die Wartungsaufgabe überprüft den Dateityp. Für Datenbank-Backups, ich glaube, es die Backup-Datei-Header überprüft.

In meinem Szenario, alle der oben genannten korrekt waren. Es gibt nur wenige Kommentare im Internet, wo einige der die Routine xp_delete Buggy ist.

Wenn die Backup-Dateien wurden nicht gelöscht werden, extrahiert ich die SQL für die Wartung und lief es von SSMS. Die resultierende Nachricht war die Datei nicht eine SQL-Server-Backup-Datei war. Diese Meldung war falsch, da die Sicherung erfolgreich gestellt werden kann, was zu einer operativen Datenbank.

Die Datenbankbefehle verwendet, um die Datenbank zu überprüfen waren:

RESTORE HEADERONLY FROM DISK = N'<file path\filename>.Bak'
RESTORE VERIFYONLY FROM DISK = N'<file path\filename>.bak'

Die beiden oben genannten Befehle angezeigt die Sicherungsdatei gültig war.

Als nächstes öffnete ich die Ereignisanzeige und fand Meldungen anzeigt, dass es Login-Fehler für die Verbindungsmanager waren. Das war seltsam, weil ich die Verbindung mit dem Testverbindungstaste bestätigt hatte. Die Fehler wurden nicht im Zusammenhang mit einem Konto, das ich geschaffen hatte.

Ereignisanzeige Nachricht:

* Die Beschreibung für Ereignis-ID 17052 von der Quelle MS SQL Server kann nicht gefunden werden. Entweder ist die Komponente, die dieses Ereignis auslöst wird nicht auf dem lokalen Computer installiert oder die Installation beschädigt ist. Sie können die Komponente auf dem lokalen Computer installieren oder reparieren. Wenn das Ereignis auf einem anderen Computer erstellt wurde, hatten die Anzeigeinformationen mit dem Ereignisse gespeichert werden.

Die folgenden Informationen wurden mit dem Ereignis enthalten:

Schweregrad: 16 Fehler: 18456, O:. 18456 [Microsoft] [SQL Server Native Client 11.0] [SQL Server] Anmeldung für den Benutzer 'Domäne \ server $' ist fehlgeschlagen *

Als nächstes angemeldet ich auf eine Maschine, auf xp_delete richtig funktioniert. Nach dem Active Directory-Überprüfung und das Systemkonto nicht zu finden, ging ich in die Ereignisanzeige ähnliche Meldungen zu finden. Hier zeigte sich, das Konto für Domain \ server $ auf die Sicherheit des Systems abgebildet wird.

Der nächste Schritt war die Datenbank-Sicherheit zu vergleichen, wo xp_delete gegen die Datenbank gearbeitet, wo es nicht funktioniert hat. Es gab 2 fehlende Anmeldungen unter Sicherheit in der Datenbank, in xp_delete nicht funktioniert hat. Die 2 fehlenden Anmeldungen waren: NT AUTHORITY \ SYSTEM NT Service \ MSSQLSERVER

NT-Dienst \ MSSQLSERVER Nach dem Hinzufügen xp_delete arbeitete erfolgreich.

Ein Ansatz zur Prüfung ist es, die Wartungsaufgabe zu verwenden, um eine einzelne Datei zu löschen.

Versuchen Sie, den ersten Parameter von 0 auf 1 geändert wird.

Hier ist eine kleine Zusammenfassung auf xp_delete_file rel="nofollow ich nur gefunden. Klänge, die mit diesem Verfahren ein bisschen wie Sie würde kein Glück.

Ich weiß, dass dies ein wenig alt, aber ich wollte meine Frustrationen mit euch allen teilen. Ich hatte das gleiche Problem wie viele dieser Beiträge, aber nichts schien zu funktionieren. Ich erinnerte mich dann, dass wir eine Verschlüsselungsschicht auf der Datenbank mit dem Namen NetLib haben. Dies bedeutet, dass die Sicherungen sind verschlüsselt und können als solche xp_delete_file die Header nicht lesen. Ich verwende jetzt eine Batch-Datei im Betriebssystem und nenne es von einem Agenten Job. Hoffe, das hilft jemand.

Wir in der Regel in solchen Situationen am Ende, wenn Sie die Datenbank auf einem anderen Server verschoben oder wenn eine SQL-Instanz auf demselben einem neu installiert, aber die Sicherung im alten Verzeichnis links. Zum Beispiel: Sie verschieben die Datenbank von server1 zu server2, aber Sie haben einen Server mit einem Wartungsplan, der eine regelmäßige Sicherung durchführt, oder Sie installieren Sie die SQL-Instanz auf server1 und Sie stellen Sie die Datenbank.

In der Backup-Fall die Sätze, die als Informationen in msdb gehalten werden, sind nicht mehr da, also alle älteren Sicherungen, die erstellt wurden, werden nicht als keine Informationen gelöscht werden geprüft wird, von der aus den Tabellen mit Sicherungssätzen abgeleitet ausfällt.

EXECUTE master.sys.xp_delete_file  0, -- FileTypeSelected (0 = FileBackup, 1 = FileReport)

Das erste Argument zeigt, dass die Tabellen von msdb verwendet werden.

Hoffe, das hilft jemand.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow