13

我正在尝试编写一些 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' a end 更改为'0'。

这将返回“成功”，但文件不会被删除。

我正在使用 SQL Server 2005，标准版，带 SP2

4

8 回答 8

23

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

您不能使用 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-09T20:26:51.827 回答
6

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

xp_cmdshell 'del <文件名>'
于 2008-10-17T16:19:56.223 回答
3

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

正如 Smink 建议的那样，您可以使用

xp_cmdshell 'del <filename>'

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

于 2008-10-17T16:50:27.910 回答
2

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

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

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

于 2012-01-09T14:37:54.430 回答
2

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

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

在我的情况下，以上所有内容都是正确的。网上很少有评论说例程 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 Service\MSSQLSERVER

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

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

于 2016-02-13T19:33:02.687 回答
0

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

这是我刚刚找到的一个小总结。xp_delete_file听起来有点像你对这个程序不走运。

于 2008-10-17T15:58:37.140 回答
0

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

于 2013-02-20T11:29:55.687 回答
0

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

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

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

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

希望这可以帮助某人。

于 2014-10-21T12:32:09.000 回答