SQL 维护清理任务工作但不删除答案

【问题标题】：SQL Maintenance Cleanup Task Working but Not DeletingSQL 维护清理任务工作但不删除
【发布时间】：2011-03-16 15:07:50
【问题描述】：

我有一个维护计划，假设要通过 BACKUP 文件夹并删除所有超过 5 天的 .bak。当我运行该作业时，它会给我一条成功消息，但旧的 .bak 文件仍然存在。

我已尝试以下问题的步骤：https://serverfault.com/questions/245493/sql-maintenance-cleanup-task-success-but-not-deleting-files

Result is column IsDamaged = 0

我已经验证了以下问题，这不是我的问题：https://serverfault.com/questions/94094/maintenance-cleanup-tasks-running-successfully-but-not-deleting-back-up-files

我也尝试删除作业和维护计划并重新创建，但无济于事。

有什么想法吗？

【问题讨论】：

标签： sql-server sql-server-2008 maintenance-plan

【解决方案1】：

试试这些检查：

使用 *.* 作为文件扩展名或不带点的 bak，如果其他问题也正确，我发现这两种方法都有效。
确保该路径只是备份所在的路径，但末尾带有反斜杠。
首先在创建备份时检查是否勾选了验证。

【讨论】：

使用扩展 bak 对我有用。没有点和星号
我们遇到了这个问题 - 将路径更改为以“\”结尾，并将文件规范更改为“.”。那行得通。
对我来说，当我每天改为每周时，它开始工作了。有谁知道解决办法吗？

【解决方案2】：

这通常是由权限问题引起的。当权限阻止运行该步骤的帐户删除文件时，清理任务似乎没有记录任何有用的信息。

您可以如下验证：

在 SQL Server Management Studio 中，右键单击您的维护计划并选择“修改”
找到用于删除 bak 文件的维护清理任务并单击“查看 T-SQL”按钮。将脚本复制到剪贴板 - 类似于“EXECUTE master.dbo.xp_delete_file ...”
使用对包含备份的文件夹具有所需权限的 Windows 帐户连接到服务器并运行 SQL
如果确实清理了 bak 文件，则表明维护计划任务配置正确并且您有权限问题。
在 Management Studio 中，打开作业的属性窗口（SQL Server 代理 > 作业），单击第一步中的编辑按钮。 “运行身份”部分将指示哪个帐户正在运行该作业。

【讨论】：

就我而言，这实际上是一个权限问题。感谢您帮助我解决问题！

【解决方案3】：

有同样的问题。罪魁祸首是 .Bak 扩展名。将其更改为 Bak，您应该会很好。

【讨论】：

微软的某个人需要被处以私刑。他们的标准是文件名不区分大小写但会保留大小写 - 我花了 6 小时来追踪它。
你是冠军。我的问题也与扩展有关。 .bak 不起作用，但是如果没有句号，bak 本身的功能就像一位功夫大师教授他的最新课程。像个冠军。向你致敬

【解决方案4】：

确保在正确的 SQL Server 中创建维护计划。更详细的，

如果你有 SQL Server 2005 并且你创建了 maint.此 SQL Server 2005 下的计划，您将只能“清理”（删除）从 SQL Server 2005 服务器生成/备份的那些备份 (bak) 和事务日志 (trn)。如果您尝试从 2008、2008 R2、2012 或更新版本中清理那些 bak 或 trn，它将无法正常工作。（由于文件头信息）。也就是说，2005 无法识别 2008 或更新格式的文件！

但是，您始终可以通过创建 maint.xml 来清理这些文件。 SQL Server 2008 下的计划并从 2005 年到 2012 年（已测试）“清理”这些文件。

这意味着， 1、2005只能清理2005格式的bak/trn 2. 2008可以清理2005~2012格式

我没有机会测试 2000（太旧）或 2014（太新）。但我想 2014 年应该从 2008 年开始。

【讨论】：

谢谢。遇到this blog post，这似乎证实xp_delete_file 确实尝试在删除之前读取文件头，因此将跳过更高版本的SQL 或第3 方实用程序生成的文件。（一个实际的推论是xp_delete_file 可能比仅查看路径/扩展名的 PowerShell 等其他方法慢得多。）
好吧，xp_delete_file 很好地完成了这项工作。因为人们可能有其他 *.bak 文件但与 SQL server 完全无关（可能是其他软件文件恰好是相同的文件扩展名）。通过读取文件头，它只删除 SQL Server/识别的文件。

【解决方案5】：

我会给我 2 美分，刚刚也解决了这个问题，使用 SQL 2012 进行了新的部署。备份作业正常工作，但日志和旧备份的清理任务虽然已成功完成，但没有做任何事情。

在我看来，在这些愚蠢的事情中，我将扩展名设置为.bak 和.txt，但是一旦我将它们更改为.BAK 和.TXT（大写），它就开始工作了.

希望它能帮助解决类似问题的人。

【讨论】：

【解决方案6】：

我以前也遇到过类似的工作问题。我遇到它没有删除的情况是因为当我通过 GUI 时没有明确设置位置。即使我没有更改任何内容，当路径位置没有具体列出时，它就像不知道在哪里查找处理删除，因此没有发生删除。它备份得很好，一切都很好，但它不会按照向导/表单中的说明进行清理。

【讨论】：

没错，我成功地 .bak 文件，但无法清理相同的 .bak 文件。我尝试删除特定文件而不是文件夹中的文件并收到此错误：执行查询“EXECUTE master.dbo.xp_delete_file 0,N'D:\\Program F...”失败并出现以下错误： “执行 xp_delete_file 扩展存储过程时出错：指定的文件不是 SQL Server 备份文件。”。可能的失败原因：查询有问题，“ResultSet”属性设置不正确，参数设置不正确，或者连接没有正确建立。我该如何去验证你提到的路径？
在清理任务下确保所有内容都正确列出。完整的文件夹名称和文件扩展名。在过去，我看到它允许空白字段（假设默认值）并且没有正确运行/清理。

【解决方案7】：

我遇到了同样的问题，我也尝试解决它。我想我尝试了每一种组合，但没有奏效。请注意，xp_delete_file 未记录在案，而且显然有很多错误。

但我所做的并且可以帮助您的是将步骤更改为 PowerShell 步骤。

您可以使用以下方法删除超过 30 天的文件

get-childitem c:\sqlbackup -recurse |其中 {$.lastwritetime -lt (get-date).adddays(-30) -and -not $.psiscontainer} |% {remove-item $_.fullname -force -whatif}

注意添加的 -whatif 以便您进行测试。

但就我而言，这还不够。 PowerShell 方法存在权利问题。运行 SQL 代理的帐户没有删除文件的权限。正确设置权限时，一切都像魅力一样。

祝你好运

【讨论】：

【解决方案8】：

我发现我必须将频率从 1 周更改为天，然后它会删除旧的备份。为什么，我不知道，但这确实解决了问题。

【讨论】：

对我来说完全一样，你解决了这个问题吗？我想要它工作几天

【解决方案9】：

把我的 2 美分投入...当我试图删除维护文件时，我的失败了。尽管我正确设置了扩展名和文件位置，但我忘记将其从备份文件设置为维护计划文件。

【讨论】：

【解决方案10】：

问题把我逼疯了。我有一个解决方法，尽管其他服务器使用没有问题的维护计划。我复制了T-SQL 脚本并制作了一个sp，将dbo 更改为sys。这个对我有用。读取脚本

Create Procedure bk_removeTLogBackupFiles
as
Declare @DeleteDate varchar(50)
Declare @DeleteExecuteSQL varchar(1000)
Set @DeleteDate = cast(DATEADD(day,-7,GetDate()) as varchar(50))
Set   @DeleteExecuteSQL =
'EXECUTE master.sys.xp_delete_file 0,N''\\Backupserver\BackupFolder\' + @@servername + '\User'',N''trn'',N' + quotename(@DeleteDate,'''') +  ',1'


Execute (@DeleteExecuteSQL)

这是一个通用脚本，我用于所有备份到某个服务器，服务器\文件夹级别的安全性被分类到用户系统等的文件夹中。不多，但它对我有用。

【讨论】：