Очистка после обслуживания sql не удаляет файлы

Обновлено: 03.07.2024

Result is column IsDamaged = 0

Я также попытался удалить План работы и обслуживания и воссоздать, но безрезультатно.

спросил(а) 2011-03-16T18:07:00+03:00 10 лет, 8 месяцев назад

Попробуйте выполнить следующие проверки:

ответил(а) 2011-07-25T10:40:00+04:00 10 лет, 4 месяца назад

Это часто вызвано проблемами разрешения. Задача очистки, похоже, не делает ничего полезного в том случае, если разрешения запрещают учетную запись, под которой этот шаг выполняется при удалении файлов.

Вы можете проверить это следующим образом:

ответил(а) 2014-03-25T20:08:00+04:00 7 лет, 8 месяцев назад

Я поставлю мне 2 цента, просто по этой проблеме, новое развертывание с SQL 2012.
Резервные задания работают правильно, однако задачи очистки для журналов и старых резервных копий ничего не сделали, хотя были успешно завершены.

Проблема, на мой взгляд, среди этих глупых вещей, я установил расширение как .bak и .txt , однако, как только я изменил их на .bak и .txt (в столицах), он начал работать.

Надеюсь, что это поможет кому-то, кто устраняет аналогичную проблему.

Была такая же проблема. Culprit - расширение .Bak. Измените это на Bak, и вы должны быть хорошими.

ответил(а) 2013-06-25T18:49:00+04:00 8 лет, 5 месяцев назад

Убедитесь, что вы создали планы обслуживания в правильном SQL Server.
Чтобы быть более подробно,

Если у вас есть SQL Server 2005 и вы создаете maint. планы в рамках этого SQL Server 2005,
вы ТОЛЬКО сможете "очистить" (удалить) резервную копию (bak) и журнал транзакций (trn), сгенерированный/резервный с сервера SQL Server 2005.
Если вы попытаетесь очистить эти бак или trn от 2008, 2008 R2, 2012 или новее, это не сработает. (Из-за информации заголовка файла). То есть 2005 не распознает эти файлы в 2008 году или более новый формат!

Однако вы всегда можете очистить эти файлы, создав maint. планы под SQL Server 2008 и "очистка" этих файлов с 2005 по 2012 год (проверено).

Это означает,
1. 2005 год может только очистить bak/trn в формате 2005 года
2. 2008 год может очистить формат 2005

У меня не было шанса испытать 2000 (слишком старый) или 2014 (слишком новый).
Но я думаю, 2014 год должен работать с 2008 года.

Result is column IsDamaged = 0

Я также пытался удалить план работы и обслуживания и воссоздать его, но безуспешно.

задан 16 марта '11, 15:03

10 ответы

Попробуйте эти проверки:

Используйте *. * Для расширения файла или bak без точки, оба из которых я нашел работоспособными, если другие проблемы тоже верны.
Убедитесь, что путь - это просто путь к тому месту, где находятся ваши резервные копии, но с обратной косой чертой в конце.
Убедитесь, что проверка отмечена галочкой, когда вы создаете резервную копию в первую очередь.

использование расширения bak - это то, что сработало для меня. Без точек и звездочек - Джао

У нас была эта проблема - изменили путь на "\", а также изменили спецификацию файла на ".". Это сработало. - Мэтт Доуди

для меня, когда я сменил ежедневный на еженедельный, он начал работать. Кто-нибудь знает решение этого? - Ahsan

Часто это вызвано проблемами с разрешением. Задача очистки, похоже, не регистрирует ничего полезного, если разрешения не позволяют учетной записи, под которой выполняется шаг, удалять файлы.

Вы можете проверить это следующим образом:

В SQL Server Management Studio щелкните правой кнопкой мыши план обслуживания и выберите «Изменить».
Найдите задачу «Очистка при обслуживании», используемую для удаления ваших файлов BAK, и нажмите кнопку «Просмотреть T-SQL». Скопируйте скрипт в буфер обмена - это будет что-то вроде «EXECUTE master.dbo.xp_delete_file . »
Подключитесь к серверу, используя учетную запись Windows, у которой есть необходимые разрешения для папки, содержащей резервные копии, и запустите SQL
Если файлы BAK очищаются, это означает, что задача плана обслуживания настроена правильно и у вас есть проблема с разрешениями.
В Management Studio откройте окно свойств задания («Агент SQL Server»> «Задания»), нажмите кнопку «Изменить» на первом шаге. В разделе «Запуск от имени» будет указано, какая учетная запись выполняет задание.

ответ дан 25 мар '14, в 21:03

В моем случае это была проблема с разрешением. Спасибо, что помогли мне разобраться! - Брайан Бедард

Была такая же проблема. Виновником является расширение .Bak. Измените его на Bak, и все будет хорошо.

Кого-то в Microsoft нужно линчевать. Их стандарт заключается в том, что имена файлов не чувствительны к регистру, но с сохранением регистра - я потратил 6 часов гонится за этим. - поджо-гай

Ты чемпион. Моя проблема была в расширении. .bak не работает, однако без полной остановки bak сам по себе функционирует как мастер кунг-фу, преподающий свой новейший класс. КАК ЧЕМПИОН. Престижность тебе - Гави Греф

Убедитесь, что вы создали планы обслуживания на правильном сервере SQL. Чтобы быть более подробным,

Если у вас есть SQL Server 2005 и вы создаете файл maint. согласно планам этого SQL Server 2005, вы сможете ТОЛЬКО «очищать» (удалять) те резервные копии (bak) и журнал транзакций (trn), созданные / скопированные с сервера SQL Server 2005. Если вы попытались очистить эти bak или trn из 2008, 2008 R2, 2012 или новее, это не сработает. (Из-за информации заголовка файла). То есть 2005 не распознает эти файлы в формате 2008 или новее!

Однако вы всегда можете очистить эти файлы, создав файл maint. планы под SQL Server 2008 и "очистить" эти файлы с 2005

Это означает, что 1. 2005 может очищать только bak / trn в формате 2005 2. 2008 может очищать формат 2005

У меня не было возможности протестировать 2000 (слишком старый) или 2014 (слишком новый). Но я думаю, что 2014 год должен работать с 2008 года.

Создан 17 июля '14, 20:07

Что ж, хорошо, что xp_delete_file справляется со своей задачей. Потому что у людей может быть другой файл * .bak, но он не имеет ничего общего с SQL-сервером (может быть, другой файл программного обеспечения имеет такое же расширение). Читая заголовок файла, он удаляет только SQL Server / распознанный файл. - Chjquest

Я положил мне 2 цента, я только что решил эту проблему, у меня новое развертывание с SQL 2012. Задания резервного копирования работают правильно, однако задачи очистки как для журналов, так и для старых резервных копий ничего не сделали, хотя были успешно завершены.

Проблема, на мой взгляд, среди этих глупостей, я установил расширение как .bak и .txt , однако, как только я изменил их на .BAK и .TXT (в столицах) заработало.

Надеюсь, это поможет кому-то, кто устраняет аналогичную проблему.

Создан 28 июля '14, 13:07

У меня раньше были подобные проблемы с работой. Случаи, с которыми я столкнулся, когда он не удалялся, были связаны с тем, что местоположение не было явно установлено, когда я проходил через графический интерфейс. Даже если я ничего не менял, когда местоположение пути не было конкретно указано, казалось, что он не знал, где искать, чтобы обработать удаление, поэтому никаких удалений никогда не происходило. Резервное копирование выполнялось нормально, и все было хорошо, но не выполнялась очистка, как указано в мастере / форме.

ответ дан 16 мар '11, в 18:03

Точно, я успешно файлы .bak, но не могу ОЧИСТИТЬ те же файлы .bak. Я попытался УДАЛИТЬ КОНКРЕТНЫЙ ФАЙЛ вместо файлов в папке и получил эту ошибку: Выполнение запроса «EXECUTE master.dbo.xp_delete_file 0, N'D: \\ Program F . » завершилось ошибкой со следующей ошибкой: «Ошибка при выполнении расширенной хранимой процедуры xp_delete_file: указанный файл не является файлом резервной копии SQL Server.». Возможные причины сбоя: проблемы с запросом, свойство «ResultSet» настроено неправильно, параметры установлены неправильно или соединение не установлено правильно. Как мне проверить путь, о котором вы упомянули? - Alex

Убедитесь, что в разделе «Задачи очистки» все указано правильно. Полное имя папки и расширение файла. Раньше я видел, что он разрешает пустые поля (предполагая значения по умолчанию) и не запускает / не очищает должным образом. - Тиамин

У меня была такая же проблема, и я тоже пытался ее решить. Думаю, я пробовал каждую комбинацию, но это не сработало. Обратите внимание, что xp_delete_file недокументирован и явно содержит много ошибок.

Но что я сделал и могу вам помочь, так это изменить шаг на шаг PowerShell.

Вы можете использовать следующее для удаления файлов старше 30 дней

get-childitem c: \ sqlbackup -recurse | где .lastwritetime -lt (дата получения) .adddays (-30) -and -not $.psiscontainer> |%

Обратите внимание на -whatif, который добавлен, чтобы вы могли протестировать.

Но в моем случае этого было недостаточно. При подходе PowerShell возникла проблема с правами. Учетная запись, на которой запущен агент SQL, не имела прав на удаление файлов. При правильной настройке прав все работало как шарм.

Result is column IsDamaged = 0

Я также пытался удалить план работы и обслуживания и воссоздать, но безрезультатно.

Попробуйте эти проверки:

Используйте *. * Для расширения файла или бак без точки, оба из которых я нашел работу, если другие проблемы тоже правильные.
Убедитесь, что путь - это просто путь к вашим резервным копиям, но с обратной косой чертой в конце.
Убедитесь, что флажок проверки отмечен при создании резервной копии в первую очередь.

Это часто вызывается проблемами с разрешениями. Задача очистки, по-видимому, не регистрирует ничего полезного, когда разрешения не позволяют учетной записи, под которой выполняется шаг, удалять файлы.

Вы можете проверить это следующим образом:

В SQL Server Management Studio щелкните правой кнопкой мыши план обслуживания и выберите «Изменить».
Найдите задачу «Очистка при обслуживании», используемую для удаления ваших bak-файлов, и нажмите кнопку «Просмотр T-SQL». Скопируйте скрипт в буфер обмена - это будет что-то вроде «EXECUTE master.dbo.xp_delete_file . »
Подключитесь к серверу, используя учетную запись Windows, которая имеет необходимые разрешения для папки, содержащей резервные копии, и запустите SQL
Если bak-файлы действительно очищены, это означает, что задача «План обслуживания» настроена правильно и что у вас есть проблема с разрешениями.
В Management Studio откройте окно свойств для задания (агент SQL Server> Задания), нажмите кнопку Изменить на первом шаге. В разделе «Запуск от имени» будет указано, какая учетная запись выполняет задание.

Была такая же проблема. Culprit - это расширение .Bak. Измените это на Bak, и вы должны быть хорошими.

Я положу 2 цента, только что был уже над этой проблемой, новое развертывание с SQL 2012 . Задания резервного копирования работают правильно, однако очистить задачи для журналов и старых резервных копий ничего не сделали, хотя были успешно завершено.

Проблема, по моему мнению, среди этих глупостей, я установил расширение как .bak и .txt , однако, как только я изменил их на .BAK и .TXT (в заглавных буквах), оно начало работать.

Надеюсь, это поможет кому-то, кто устраняет подобные проблемы.

Убедитесь, что вы создаете планы обслуживания на правильном сервере SQL. Чтобы быть более подробным,

Если у вас есть SQL Server 2005, и вы создаете maint. В соответствии с планами SQL Server 2005, вы ТОЛЬКО сможете «очистить» (удалить) те резервные копии (bak) и журнал транзакций (trn), которые были созданы/скопированы с сервера SQL Server 2005. Если вы попытались очистить эти баки или трн из 2008, 2008 R2, 2012 или новее, это не сработает. (Из-за информации заголовка файла). То есть, 2005 не распознает эти файлы в 2008 или более новом формате!

Однако вы всегда можете очистить эти файлы, создав maint. планы под SQL Server 2008 и «очистить» эти файлы с 2005 по 2012 годы (проверено).

Что означает, 1. 2005 может очистить только bak/trn в формате 2005 2. 2008 может очистить формат 2005

Я обнаружил, что мне нужно изменить частоту с 1 недели на дни, а затем удалить старые резервные копии. Почему, я не знаю, но это решило проблему.

У меня были похожие проблемы с работой раньше. Случаи, когда я сталкивался с этим, не удаляя, были, потому что местоположение не было явно установлено, когда я шел через GUI. Даже если я ничего не изменил, когда местоположение пути не было конкретно указано, это было похоже на то, что он не знал, где искать обработку для удаления, поэтому удаление никогда не происходило. Он хорошо зарезервировал и все было хорошо, но он не очистился, как указано в мастере/форме.

У меня была такая же проблема, и я тоже пытался ее решить. Я думаю, что попробовал каждую комбинацию, но она не сработала. Обратите внимание, что xp_delete_file недокументирован и, очевидно, очень глючит.

Но то, что я сделал и могу вам помочь, это изменить шаг на шаг PowerShell.

Вы можете использовать следующее, чтобы удалить файлы старше 30 дней

get-childitem c:\sqlbackup -recurse | где .lastwritetime -lt (get-date) .adddays (-30) -and -not $ . psiscontainer> |%

Обратите внимание на -whatif, который добавлен, чтобы вы могли проверить.

Но в моем случае этого было недостаточно. При использовании подхода PowerShell возникла проблема с правами. У учетной записи, на которой запущен агент SQL, не было прав на удаление файлов. При правильной настройке прав все работало как шарм.

Бросить мои 2 цента в . мой не удавалось, когда я пытался удалить файлы обслуживания. Хотя у меня были правильно установлены расширение и местоположение файла, я забыл установить его из резервных копий файлов в файлы плана обслуживания.

Проблема сводила меня с ума. У меня есть обходной путь, хотя другие серверы используют план обслуживания без проблемы. Я скопировал скрипт T-SQL и сделал sp, изменив dbo на sys . Меня устраивает. Скрипт для чтения

Это общий сценарий, который я использую для всех своих резервных копий, идущих на определенный сервер с безопасностью в рычаге server\folder, отсортированном по папкам для пользовательской системы и т.д Не много, но у меня это сработало.

Резервное копирование начинается через план обслуживания.
С настройкой службой оповещения вы сможете ознакомиться по ссылке

Далее из панели элементов добавляем нужную задачу и помещаем в свой план обслуживания.

В качестве обработки ошибки рекомендую добавить блок "Уведомление оператора". Блок простой и при правильной настройке Database Mail SQL прост в настройке.

У вас должна получиться конструкция:

По окончании выполнение блока задание продолжает выполнение вне зависимости от результата. Т.е. условие выполнения блока "Завершение".

Инструкция SQL проверяет, сколько дней прошло, после того, как выполнялось полное резервное копирование, соответствие размера полной и разностной резервной копии, наличие полной резервной копии в каталоге.
В зависимости от настроек проверяется:
- было ли выполнено резервное копирование в нужную папку;
- существует ли файл полного резервирования в нужной папке;
- соотношение размера файла полного копии к разностной.
Данный блок выполняет роль семафора. При ошибке будет выполнен блок плана по полному резервному копированию. При успешном выполнении инструкции, последует выполнение блока по разностному резервному копированию.

Данная инструкция функционал семафора выполняет по вызову исключения:

Скрипт:
Должно получиться, что-то вроде:

По окончанию выполнения задания в блоке, просто продолжаем выполнение следующего блока. Т.е. выставляем свойство "Завершение"

По окончанию выполнения задания в блоке, просто продолжаем выполнение следующего блока. Т.е. выставляем свойство "Завершение". Нам не надо останавливать выполнения плана обслуживания, если что-то пойдет не так, то продолжаем.

По команде "DBCC FLUSHPROCINDB(8)", значение "8" у вас будет другое.
нужно выполнить запрос SQL:

Скрипт:
По окончанию выполнения задания в блоке, просто продолжаем выполнение следующего блока. Т.е. выставляем свойство "Завершение".

В данном блоке выполняем полное резервное копирование.
Указать:
- тип резервной копии "Полное"
- Выбрать базу данных

В целевом объекте указать:
- каталог, куда делать резервные копии
- расширение должно оканчиваться на ".bak", иначе при восстановлении из архива вам придется его переименовывать, другие расширения SQL не видит.

В параметрах указываем:
- Сжимать резервные копии
- Срок действия резервной копии нужен только если вы воспользуетесь блоком "Удаление старых архивов"
- Проверка целостности резервной копии не помешает, мало-ли что могло пойти не так.

В качестве обработки ошибки рекомендую добавить блок "Уведомление оператора".

"Очистка после обслуживания" - удаляет старые файлы, которые предположительно потеряли свою актуальность.
Указываем путь к резервным копиям и указываем имя расширения файлов.
Пунктом "Возраст файлов" мы ограничиваем период, за который будут удалены файлы.
В моем случае это год, т.к. в дальнейшем полные резервные копии должны будут формироваться два раза в месяц. У вас возможно другой взгляд и возможность хранения резервных копий.

Скрипт по отрезанию журнала транзакций:

Добавляем блок "Выполнение инструкции T-SQL".

Инструкция SQL проверяет, через сколько дней выполнить обновление статистики базы данных.
Данный блок выполняет роль семафора. При ошибке будет выполнен блок обновления статистики. При успешном выполнении инструкции, последует выполнение блока по разностного резервного копирования без обновления статистики.

Данная инструкция функционал семафора выполняет по вызову исключения:

Скрипт:
В итоге у вас получится следующая конструкция.
В названии фигурирует переиндексация, но в виду того что у меня при этом происходил катастрофический рост журнала транзакции, блок по обновлению индексов был исключен. (но вы всегда можете пойти другим путем)

Общая настройка:

Целевой объект:
Как вы можете заметить, расширение файла содержит те самые буквы с точкой ".bak"

В качестве обработки ошибки рекомендую добавить блок "Уведомление оператора".

"Очистка после обслуживания" - удаляет старые файлы, которые предположительно потеряли свою актуальность.

Как вы могли заметить я установил для промежуточных резервных копий всего 3 месяца в виду того, что они как правило занимают не так много места на носителях.

В оригинале у вас получится вот такая конструкция промежуточного копирования:

Читайте также: