SQL Server xp_delete_file沒有刪除文件

我想寫一些SQL將刪除7天以前的文件類型'.7z'。SQL Server xp_delete_file沒有刪除文件

這裏是我有什麼不工作：

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

我也試圖改變「1」一結束，以「0」。

這將返回'成功'，但文件不會被刪除。

我使用的是SQL Server 2005中，標準，W/SP2

來源

2008-10-17 GernBlandston

有類似問題，找到各種答案。這是我發現的。

您不能使用xp_delete_file刪除7z文件。這是一個未記錄的擴展存儲過程，它是SQL 2000的延緩。它檢查要刪除的文件的第一行，以驗證它是SQL備份文件還是SQL報告文件。它不會根據文件擴展名進行檢查。從我收集它的預期用途是維護計劃清理舊備份和計劃報告。

下面是一個基於Tomalak的鏈接來刪除超過7天的備份文件的示例。人們往往會想到的是'sys'模式，文件夾路徑中的尾部斜槓以及文件擴展名中沒有找到的點。 SQL Server運行的用戶還需要具有該文件夾的刪除權限。

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)

請注意，xp_delete_file在SP2中被破壞，不能在報告文件上工作;在[http://support.microsoft.com/kb/938085]有一個修補程序。我沒有用SP3測試過它。

由於它沒有記錄，因此xp_delete_file可能會在未來版本的SQL Server中消失或更改。許多網站推薦使用shell腳本來完成刪除操作。

來源

2009-02-09 20:26:51

嘗試更改爲0的第一個參數爲1

這裏是一個小summary on xp_delete_file我剛發現。聽起來有點像你在這個程序中運氣不好。

來源

2008-10-17 15:58:37 Tomalak

Tomalak：那沒用。 – GernBlandston 2008-10-17 16:02:45

我讀過我剛剛發佈的摘要後，我想到了。一個錯誤的論壇帖子指出了我的第一個答案的方向。 – Tomalak 2008-10-17 16:04:58

AFAIK xp_delete_file只刪除SQL Server 2005識別的文件（備份文件，事務日誌，...）。或許你可以嘗試這樣的事：

xp_cmdshell 'del <filename>'

來源

2008-10-17 16:19:56

此SP將只將只刪除本機SQL Server備份文件或本機維護報告文件（出於安全目的）

由於Smink建議您可以使用

xp_cmdshell 'del <filename>'

具有該文件夾的適當權限。

來源

2008-10-17 16:50:27

我發現了這個問題，但解決方案並不適用於我（因爲它是.bak文件，SQL Server本身作爲維護計劃的一部分）。

我的情況是安全問題。該腳本正在運行，因爲啓動SQL Server（MSSQL）的用戶（在我的情況下，可能大多數情況下是「網絡服務」）無法訪問它試圖刪除文件的文件夾。

因此，添加「網絡服務」並授予它「修改」幫助。

來源

2012-01-09 14:37:54 Holger

我知道這有點舊，但我想與大家分享我的挫折感。我遇到了與很多這些帖子相同的問題，但似乎沒有任何工作。然後我記得我們在數據庫上有一個名爲NetLib的加密層。這意味着備份是加密的，因此xp_delete_file無法讀取標題。我現在在操作系統中使用批處理文件，並從代理作業調用它。希望這可以幫助某人。

來源

2013-02-20 11:29:55 dwjv

當您將數據庫移動到另一臺服務器或者SQL實例重新安裝在同一臺服務器上但備份保留在舊目錄中時，我們通常會遇到這種情況。例如：您將數據庫從server1移動到server2，但您的服務器具有執行定期備份的維護計劃，或者您在服務器1上重新安裝SQL實例，在還原數據庫時重新安裝SQL實例。

在備份案例中，作爲msdb中信息保存的集合不再存在，因此所有已創建的較舊備份將不會被刪除，因爲沒有從具有備份集的表導出的故障中檢查信息。

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

第一個參數顯示正在使用從msdb中的表。

希望這可以幫助別人。

來源

2014-10-21 12:32:09

我已經閱讀了許多不同的方法和解決方案，試圖用擴展存儲過程xp_delete解決問題時追求多個人。解決方案如下：

配置SSIS維護任務時，務必在擴展名中沒有句點（。）。
如果每個數據庫備份都存在，請務必單擊包含第一級子文件夾。
一定要點擊頂部的備份文件。維護任務確實檢查文件類型。對於數據庫備份，我相信它會檢查備份文件頭。

在我的情況中，以上所有都是正確的。在網上幾乎沒有評論，其中一些人說例行xp_delete是越野車。

當備份文件沒有被刪除時，我提取了用於維護的SQL並從SSMS運行它。由此產生的消息是該文件不是一個SQL Server備份文件。此消息是錯誤的，因爲備份可以成功恢復，從而產生可操作的數據庫。

用於驗證數據庫中的數據庫的命令爲：

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

兩個上述命令所指示的備份文件是有效的。

接下來，我打開事件查看器，發現指示連接管理器存在登錄錯誤的消息。這很奇怪，因爲我已經驗證了與測試連接按鈕的連接。這些錯誤與我創建的任何帳戶無關。

事件查看消息：

*The description for Event ID 17052 from source MS SQL SERVER cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. If the event originated on another computer, the display information had to be saved with the event.

下面的信息包括與所述事件：

Severity: 16 Error:18456, OS: 18456 [Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed for user 'domain\servername$'.*

接着我登錄到其中xp_delete是正常的機器。在查看活動目錄並未找到系統帳戶之後，我繼續前往事件查看器以查找類似的消息。在這裏，很明顯domain \ server $的帳戶被映射到系統安全性。

下一步是比較數據庫安全性，其中xp_delete對數據庫不起作用。在xp_delete不起作用的數據庫中有2個安全漏洞登錄。的2名失蹤登錄爲： NT AUTHORITY \ SYSTEM NT服務\ MSSQLSERVER

加入NT服務\ MSSQLSERVER後，xp_delete成功合作。

測試的一種方法是使用維護任務刪除單個文件。

來源

2016-02-13 19:33:02 user5923365

SQL Server xp_delete_file沒有刪除文件

回答

相關問題