SQL维护清理任务正常运行但不删除数据

Question

我有一个维护计划，应该会扫描BACKUP文件夹并删除所有5天前的.bak文件。 当我运行任务时，它给出了成功的消息，但旧的.bak文件仍然存在。

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

结果为列IsDamaged = 0

我已经查证过了这个问题，但这不是我的问题。

我还尝试删除作业和维护计划，但没有效果。

有任何想法吗？

- Alex

Answer 1

请尝试以下检查：

1. 使用 *.* 作为文件扩展名或者不带点的 bak，如果其他问题也正确，这两种方法都可以实现备份。
2. 确保路径仅是指向备份文件所在的路径，但末尾要加上反斜杠。
3. 在第一次创建备份时，请勾选验证。

- sturb

---

对我而言，使用扩展名为“bak”是有效的。不需要使用点号和星号。 - jao

我们遇到了这个问题--把路径改为以“\”结尾，同时将文件规范改为“*.*”。这样做起作用了。 - Matt Dawdy

有人知道这个问题的解决方案吗？当我将“每日”更改为“每周”时，它开始正常工作了。 - Ahsan

Answer 2

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

您可以按照以下步骤进行验证：

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

- Dan Malcolm

---

在我的情况下，实际上是一个权限问题。感谢您帮助我找出问题所在！ - Bryan Bedard

Answer 3

我有同样的问题。罪魁祸首是 .Bak 后缀。将其更改为 Bak 后，你应该就可以了。

- jordan koskei

---

有人在微软需要被绞死。他们的标准是文件名不区分大小写但保留大小写 - 我花了6个<插入任意数量的形容词>小时追踪此问题。 - pojo-guy

你是个冠军。我的问题也与扩展名有关。.bak不起作用，但是没有句号的bak本身就像一位功夫大师教授他最新的课程。像冠军一样。向你致敬。 - Gawie Schneider

Answer 4

我会提供我的建议，最近也遇到了这个问题，我使用SQL 2012进行新的部署。备份任务正常运行，但是清理旧日志和备份的任务却没有起作用，尽管任务已经成功完成。

在我看来，问题可能出在一些小事情上，例如我将扩展名设置为.bak和.txt，但是当我将它们更改为大写的.BAK和.TXT时，它就开始工作了。

希望能对那些处理类似问题的人有所帮助。

- Rost

Answer 5

请确保在正确的SQL Server中创建维护计划。 更详细地说，如果您有SQL Server 2005并在此SQL Server 2005下创建维护计划，那么您将仅能“清理”（删除）从SQL Server 2005服务器生成/备份的那些备份（bak）和事务日志（trn）。如果您试图清理来自2008、2008 R2、2012或更新版本的bak或trn，则不起作用（由于文件头信息）。也就是说，2005不认识2008或更新版本格式的这些文件！ 但是，您始终可以通过在SQL Server 2008下创建维护计划并“清理”那些来自2005~2012版本的文件来清理这些文件（已经测试过）。 这意味着： 1. 2005只能清理2005格式的bak/trn 2. 2008可以清理2005~2012格式的文件 我没有机会测试2000（太旧）或2014（太新）。但我猜2014应该可以从2008清理。

- Chjquest

---

谢谢。我看到了这篇博客文章，它似乎证实了xp_delete_file在删除文件之前确实会尝试读取文件头，因此会跳过由较新版本的SQL或第三方工具创建的文件。（一个实际的推论是，与只查看路径/扩展名的PowerShell等其他方法相比，xp_delete_file可能要慢得多。） - BradC

好的，xp_delete_file做得很好。因为人们可能有其他*.bak文件，但与SQL服务器完全无关（可能是其他软件文件恰好具有相同的文件扩展名）。通过读取文件头，它仅删除SQL Server / 可识别的文件。 - Chjquest

Answer 6

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

- Thyamine

---

确切地说，我成功备份了.bak文件，但无法清理相同的.bak文件。我尝试删除特定文件而不是文件夹中的文件，但出现了以下错误：执行查询“EXECUTE master.dbo.xp_delete_file 0, N'D:\Program F...”失败，因为出现以下错误：“执行xp_delete_file扩展存储过程时出错：指定的文件不是 SQL Server 备份文件。”可能的故障原因包括：查询存在问题，“ResultSet”属性未正确设置，参数未正确设置或连接未正确建立。我如何验证您提到的路径？ - Alex

在清理任务下，请确保所有内容都正确列出。包括完整的文件夹名称和文件扩展名。过去我曾看到它允许空白字段（假设默认值），但并未正确运行/清理。 - Thyamine

Answer 7

我曾经遇到同样的问题，也试图解决它。我认为我尝试了每种组合方式，但都没有成功。请注意，xp_delete_file未经记录，而且显然非常有缺陷。

但我所做的并能帮助你的是将步骤更改为PowerShell步骤。

您可以使用以下内容删除30天以上的文件：

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

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

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

祝好运

- Anders

Answer 8

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

- Cindy

---

你和我一样，解决了这个问题吗？我想这个工作已经拖了好几天了。 - Ahsan

Answer 9

我也来凑热闹...我的问题出在尝试删除维护文件时失败了。虽然我已经正确设置了扩展名和文件位置，但我忘记将其从备份文件设置为维护计划文件。

- PseudoToad

Answer 10

检查备份文件是否未选中只读选项，如果已选中，则xp_delete_file过程将无法删除它们（它将执行并返回无错误）。 我曾经遇到过这样的情况，即数据库备份应用程序设置了所制作的备份文件的只读属性。

- DarkWhite