SQL Server xp_delete_file 不删除文件

Posted 2023-04-15

【中文标题】SQL Server xp_delete_file 不删除文件

【英文标题】：SQL Server xp_delete_file not deleting files

【发布时间】：2008-10-17 15:15:55

【问题描述】：

我正在尝试编写一些 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，标准版，带 SP2

【参考方案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 脚本来执行删除操作。

【讨论】：

文件扩展名上的“（无点）”帮助了我。谢谢！

【参考方案2】：

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

xp_cmdshell 'del '

【讨论】：

smink：我尝试将文件扩展名更改为 .bak，但没有成功。它是否会查看文件以查看我是否在弄乱它而不只是查看扩展名？

是的，它检查文件的二进制签名。

我尝试使用 .bak sql 备份文件，但没有删除它。

【参考方案3】：

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

Smink 建议你可以使用

xp_cmdshell 'del <filename>'

对文件夹具有适当的权限。

【参考方案4】：

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

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

因此添加“网络服务”并授予它“修改”权限。

【参考方案5】：

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

在配置 SSIS 维护任务时，确保扩展名中没有句点 (.)。 如果每个数据库备份都存在第一级子文件夹，请务必单击它们。 一定要点击顶部的备份文件。维护任务会检查文件类型。对于数据库备份，我相信它会检查备份文件头。

在我的情况下，以上所有内容都是正确的。网络上很少有 cmets 有人说例程 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 起作用的数据库安全性与不起作用的数据库进行比较。在 xp_delete 不起作用的数据库中有 2 个在安全性下丢失的登录。 缺少的 2 个登录名是： NT AUTHORITY\SYSTEM NT 服务\MSSQLSERVER

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

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

【讨论】：

好的，所以一些顾问在我们公司进行了配置，显然他们确实将 '.bak' 用于扩展。将句点删除为“bak”后，它工作正常。谢谢。

【参考方案6】：

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

这是我刚刚找到的一个小summary on xp_delete_file。听起来你在这个过程中会不走运。

【讨论】：

我想，在我阅读了我刚刚发布的摘要之后。某处被误导的论坛帖子指向了我的第一个答案的方向。

【参考方案7】：

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

【参考方案8】：

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

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

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

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

希望这对某人有所帮助。