SQL Server xp_delete_file non elimina i file

https://stackoverflow.com/questions/212603

03-07-2019
|

Domanda

Sto cercando di scrivere alcuni SQL che elimineranno i file di tipo '.7z' che sono più vecchi di 7 giorni.

Ecco cosa ho che non funziona:

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

Ho anche provato a cambiare '1' alla fine in '0'.

Questo restituisce 'successo', ma i file non vengono cancellati.

Sto usando SQL Server 2005, Standard, w / SP2

Soluzione

Ha avuto un problema simile, ho trovato varie risposte. Ecco cosa ho trovato.

Non puoi eliminare i file 7z con xp_delete_file. Questa è una procedura memorizzata estesa non documentata che è un holdover da SQL 2000. Controlla la prima riga del file da eliminare per verificare che si tratti di un file di backup SQL o di un file di report SQL. Non controlla in base all'estensione del file. Da quello che raccolgo l'uso previsto è nei piani di manutenzione per ripulire vecchi backup e pianificare i report.

Ecco un esempio basato sul link di Tomalak per eliminare i file di backup più vecchi di 7 giorni. Ciò che incanta le persone è lo schema 'sys', la barra finale nel percorso della cartella e nessun punto nell'estensione del file da cercare. L'utente con cui viene eseguito SQL Server deve inoltre disporre delle autorizzazioni di eliminazione per la cartella.

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)

Nota che xp_delete_file è rotto in SP2 e non funzionerà sui file di report; c'è una correzione per questo a [ http://support.microsoft.com/kb/938085×. Non l'ho provato con SP3.

Poiché non è documentato, xp_delete_file potrebbe scomparire o cambiare nelle versioni future di SQL Server. Molti siti raccomandano invece uno script di shell per eseguire le eliminazioni.

Altri suggerimenti

AFAIK xp_delete_file elimina solo i file riconosciuti da SQL Server 2005 (file di backup, registri delle transazioni, ...). Forse puoi provare qualcosa del genere:

xp_cmdshell 'del <filename>'

Questo SP eliminerà solo i file di backup del server sql nativo o i file dei report di manutenzione nativi (per motivi di sicurezza)

Come Smink ha suggerito, puoi usare

xp_cmdshell 'del <filename>'

Con le autorizzazioni appropriate per la cartella.

Ho trovato questa domanda, ma la soluzione non si applicava a me (dato che erano i file .bak, SQL Server stesso aveva creato, come parte di un piano di manutenzione).

Il problema nel mio caso era la sicurezza. Lo script veniva eseguito come l'utente che avvia SQL Server (MSSQL) (nel mio caso e probabilmente nella maggior parte dei casi "servizio di rete") non aveva accesso alla cartella in cui stava tentando di eliminare i file.

Quindi aggiungendo " servizio di rete " e concederlo " modifica " aiutato.

Avevo letto molti approcci e soluzioni diversi perseguiti da più persone nel tentativo di risolvere il problema con la stored procedure estesa xp_delete. Le soluzioni sono:

Assicurarsi di NON avere un punto (.) nell'estensione durante la configurazione dell'attività di manutenzione SSIS.
Assicurarsi di fare clic sulle sottocartelle Includi di primo livello se esistono per ciascun backup del database.
Assicurati di fare clic sui file di backup in alto. L'attività di manutenzione controlla il tipo di file. Per i backup del database, credo che controlla l'intestazione del file di backup.

Nel mio scenario, tutto quanto sopra era corretto. Ci sono alcuni commenti sul web in cui alcuni hanno detto che la routine xp_delete è buggy.

Quando i file di backup non venivano eliminati, ho estratto l'SQL per la manutenzione ed eseguito da SSMS. Il messaggio risultante era che il file non era un file di backup del server sql. Questo messaggio era errato poiché il backup poteva essere ripristinato correttamente, risultando in un database operativo.

I comandi del database utilizzati per verificare il database erano:

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

Entrambi i comandi sopra indicati indicavano che il file di backup era valido.

Successivamente ho aperto il Visualizzatore eventi e ho trovato messaggi che indicavano errori di accesso per la gestione connessione. Questo era strano perché avevo convalidato la connessione con il pulsante di connessione di prova. Gli errori non erano correlati a nessun account che avevo creato.

Messaggio Visualizzatore eventi:

* Impossibile trovare la descrizione per ID evento 17052 dall'origine MS SQL SERVER. Il componente che genera questo evento non è installato sul computer locale o l'installazione è danneggiata. È possibile installare o riparare il componente sul computer locale. Se l'evento ha avuto origine su un altro computer, le informazioni sul display dovevano essere salvate con l'evento.

Le seguenti informazioni sono state incluse con l'evento:

Gravità: 16 Errore: 18456, OS: 18456 [Microsoft] [SQL Server Native Client 11.0] [SQL Server] Accesso non riuscito per l'utente 'domain \ servername $'. *

Successivamente ho effettuato l'accesso a una macchina in cui xp_delete funzionava correttamente. Dopo aver esaminato la directory attiva e non aver trovato l'account di sistema, sono passato al visualizzatore di eventi per trovare messaggi simili. Qui è diventato evidente che l'account per domain \ server $ è mappato sulla sicurezza del sistema.

Il passo successivo è stato quello di confrontare la sicurezza del database in cui xp_delete ha funzionato con il database in cui non funzionava. Nel database mancavano 2 accessi di sicurezza in cui xp_delete non funzionava. I 2 accessi mancanti erano: NT AUTHORITY \ SYSTEM Servizio NT \ MSSQLSERVER

Dopo aver aggiunto il servizio NT \ MSSQLSERVER, xp_delete ha funzionato correttamente.

Un approccio al test consiste nell'utilizzare l'attività di manutenzione per eliminare un singolo file.

Prova a cambiare il primo parametro da 0 a 1.

Ecco un piccolo riepilogo su xp_delete_file Ho appena trovato. Sembra un po 'sfortunato con questa procedura.

So che è un po 'vecchio ma volevo condividere le mie frustrazioni con tutti voi. Avevo lo stesso problema di molti di questi post, ma nulla sembrava funzionare. Ho poi ricordato che abbiamo un livello di crittografia nel database chiamato NetLib. Ciò significa che i backup sono crittografati e, pertanto, xp_delete_file non è in grado di leggere le intestazioni. Ora uso un file batch nel sistema operativo e lo chiamo da un lavoro agente. Spero che questo aiuti qualcuno.

Di solito finiamo in tali situazioni quando il database viene spostato su un altro server o quando un'istanza SQL viene reinstallata sullo stesso ma il backup viene lasciato nella vecchia directory. Per esempio: Si sposta il database da server1 a server2, ma si dispone di un server con un piano di manutenzione che esegue un backup periodico o si reinstalla l'istanza SQL su server1 e ripristini il database.

Nel caso del backup i set che sono conservati come informazioni in msdb non sono più presenti, quindi tutti i backup più vecchi che sono stati creati non verranno eliminati in quanto nessuna informazione viene controllato dagli errori derivati ??dalle tabelle con set di backup.

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

Il primo argomento mostra che vengono utilizzate le tabelle di msdb.

Spero che questo aiuti qualcuno.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow