Question

我正在尝试编写一些SQL，它将删除超过7天的“.7z”类型的文件。

这就是我所得到的不起作用：

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，Standard，w / SP2

Answer 1

有类似的问题，找到了各种答案。这是我找到的。

您无法使用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脚本来进行删除。

Answer 2

AFAIK xp_delete_file仅删除SQL Server 2005识别的文件（备份文件，事务日志，...）。也许你可以尝试这样的事情：

xp_cmdshell 'del <filename>'

Answer 3

此sp只会删除本机sql server备份文件或本机维护报告文件（出于安全目的）

正如Smink建议你可以使用

xp_cmdshell 'del <filename>'

拥有该文件夹的适当权限。

Answer 4

我发现了这个问题，但解决方案并不适用于我（因为它是.bak文件，SQL Server本身已经作为维护计划的一部分）。

我的问题是安全问题。该脚本正在运行，因为启动SQL Server（MSSQL）的用户（在我的情况下，可能大多数情况下是“网络服务”）无法访问它试图删除文件的文件夹。

所以添加“网络服务”并授予它“修改”有帮助。

Answer 5

在尝试使用扩展存储过程xp_delete解决问题时，我已阅读了多个不同的方法和解决方案。解决方案是：

配置SSIS维护任务时，请确保扩展名中没有句点（。）。
如果每个数据库备份都存在，请务必单击Include First-Level子文件夹。
请务必点击顶部的备份文件。维护任务会检查文件类型。对于数据库备份，我相信它会检查备份文件头。

在我的场景中，以上所有都是正确的。网上有一些评论，其中一些说例程xp_delete是错误的。

当没有删除备份文件时，我提取了SQL进行维护并从SSMS运行它。生成的消息是文件不是sql server备份文件。此消息是错误的，因为备份可以成功恢复，从而产生可操作的数据库。

用于验证数据库的数据库命令是：

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

以上两条命令都表明备份文件有效。

接下来，我打开了事件查看器，找到了表明连接管理器存在登录错误的消息。这很奇怪，因为我已经验证了与测试连接按钮的连接。这些错误与我创建的任何帐户无关。

事件查看器消息：

*找不到源MS SQL SERVER中事件ID 17052的描述。引发此事件的组件未安装在本地计算机上，或者安装已损坏。您可以在本地计算机上安装或修复该组件。如果事件源自另一台计算机，则必须随事件一起保存显示信息。

活动中包含以下信息：

严重性：16错误：18456，操作系统：18456 [Microsoft] [SQL Server Native Client 11.0] [SQL Server]用户'domain \ servername $'登录失败。*

接下来，我登录了xp_delete正常运行的机器。在查看活动目录但未找到系统帐户后，我继续查看事件查看器以查找类似的消息。在这里，很明显domain \ server $的帐户被映射到系统安全性。

下一步是将xp_delete工作的数据库安全性与不起作用的数据库进行比较。数据库中安全性下有2个缺少登录，其中xp_delete不起作用。丢失的2个登录名是： NT AUTHORITY \ SYSTEM NT服务\ MSSQLSERVER

添加NT服务\ MSSQLSERVER后，xp_delete成功运行。

一种测试方法是使用维护任务删除单个文件。

Answer 6

尝试将第一个参数从0更改为1.

这是我刚发现的一个小summary on xp_delete_file。听起来有点像你这个程序运气不好。

Answer 7

我知道这有点旧，但我想与大家分享我的挫败感。我和很多这些帖子都有同样的问题，但似乎没什么用。然后我记得我们在数据库上有一个名为NetLib的加密层。这意味着备份已加密，因此，xp_delete_file无法读取标头。我现在在操作系统中使用批处理文件并从代理作业调用它。希望这有助于某人。

Answer 8

当您将数据库移动到另一台服务器或在同一台服务器上重新安装SQL实例但备份保留在旧目录中时，我们通常会遇到这种情况。例如：您将数据库从server1移动到server2，但您有一个服务器具有执行定期备份的维护计划，或者您在server1上重新安装SQL实例你恢复数据库。

在备份情况下，作为msdb中的信息保存的集不再存在，因此所有已创建的旧备份都不会被删除，因为没有信息从具有备份集的表派生的失败中检查。

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

第一个参数显示正在使用msdb中的表。

希望这有助于某人。

SQL Server xp_delete_file不删除文件

8 个答案: