SQL Server xp_delete_file не удаляет файлы

Question

Я пытаюсь написать какой-нибудь SQL, который удалит файлы типа '.7z', которые старше 7 дней.

Вот что у меня не работает:

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, Standard, с SP2

Answer 1

Имел подобную проблему, нашел разные ответы. Вот что я нашел.

Вы не можете удалить файлы 7z с помощью xp_delete_file. Это недокументированная расширенная хранимая процедура, оставшаяся от SQL 2000. Она проверяет первую строку удаляемого файла, чтобы убедиться, что это файл резервной копии SQL или файл отчета SQL. Он не проверяет на основе расширения файла. Из того, что я понял, его предполагаемое использование заключается в планах обслуживания для очистки старых резервных копий и планирования отчетов.

Вот пример, основанный на ссылке Томалака на удаление файлов резервных копий старше 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. Многие сайты рекомендуют вместо этого использовать сценарий оболочки.

Answer 2

AFAIK xp_delete_file удалять только файлы, распознаваемые SQL Server 2005 (файлы резервных копий, журналы транзакций и т. Д.). Возможно, вы можете попробовать что-то вроде этого:

xp_cmdshell 'del <filename>'

Answer 3

Этот sp только удалит только собственные файлы резервных копий сервера sql или собственные отчеты об обслуживании (в целях безопасности)

Как предложил Smink, вы можете использовать

xp_cmdshell 'del <filename>'

С соответствующими разрешениями на папку.

Answer 4

Я прочитал много разных подходов и решений, которые преследовали несколько человек при попытке решить проблему с помощью расширенной хранимой процедуры xp_delete. Решения:

1. Не забудьте указать точку (.) В расширении при настройке задачи обслуживания служб SSIS.
2. Обязательно нажмите на подпапки «Включить первый уровень», если они существуют для каждой резервной копии базы данных.
3. Обязательно нажмите на файлы резервной копии вверху. Задача обслуживания действительно проверяет тип файла. Я считаю, что для резервного копирования базы данных проверяется заголовок файла резервной копии.

В моем сценарии все вышеперечисленное было верным. Есть несколько комментариев в Интернете, где некоторые из них сказали, что подпрограмма xp_delete содержит ошибки.

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

Команды базы данных, использованные для проверки базы данных:

RESTORE HEADERONLY FROM DISK = N'<file path\filename>.Bak'
RESTORE VERIFYONLY FROM DISK = N'<file path\filename>.bak'

Обе приведенные выше команды указали, что файл резервной копии был действительным.

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

Сообщение о событии:

* Не найдено описание для события с кодом 17052 из исходного сервера MS SQL. Либо компонент, который вызывает это событие, не установлен на локальном компьютере, либо установка повреждена. Вы можете установить или восстановить компонент на локальном компьютере. Если событие возникло на другом компьютере, отображаемая информация должна была быть сохранена вместе с событием.

Следующая информация была включена в событие:

Уровень серьезности: 16 Ошибка: 18456, ОС: 18456 [Microsoft] [Собственный клиент SQL Server 11.0] [SQL Server] Ошибка входа для пользователя «домен \ имя_сервера $». *

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

Следующим шагом было сравнение безопасности базы данных, где xp_delete работал, с базой данных, где она не работала. В базе данных было 2 пропущенных входа в систему безопасности, где xp_delete не работал. 2 отсутствующих логина были: NT AUTHORITY \ SYSTEM NT Service \ MSSQLSERVER

После добавления службы NT \ MSSQLSERVER успешно сработал xp_delete.

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

Answer 5

Я нашел этот вопрос, но решение не применимо ко мне (поскольку это были файлы .bak, которые сам SQL Server сделал в рамках плана обслуживания).

Проблема в моем случае была безопасность. Сценарий запускался как пользователь, который запускает SQL Server (MSSQL) (в моем случае и, вероятно, в большинстве случаев «сетевой сервис»), не имел доступа к папке, в которой пытался удалить файлы.

Так что добавление «сетевой службы» и предоставление ей «изменить» помогло.

Answer 6

Обычно мы попадаем в такие ситуации, когда база данных перемещается на другой сервер или когда экземпляр SQL переустанавливается на тот же сервер, но резервная копия остается в старом каталоге. Например: Вы перемещаете базу данных с сервера1 на сервер2, но у вас есть сервер с планом обслуживания, который выполняет периодическое резервное копирование, или вы переустанавливаете экземпляр SQL на сервере1 и Вы восстанавливаете базу данных.

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

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

Первый аргумент показывает, что используются таблицы из msdb.

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

Answer 7

Я знаю, что это немного старо, но я хотел поделиться своими разочарованиями со всеми вами. У меня была та же проблема, что и у многих из этих постов, но, похоже, ничего не получалось. Затем я вспомнил, что у нас есть уровень шифрования в базе данных под названием NetLib. Это означает, что резервные копии зашифрованы и, как таковой, xp_delete_file не может прочитать заголовки. Теперь я использую командный файл в ОС и вызываю его из задания агента. Надеюсь, это кому-нибудь поможет.

Answer 8

Попробуйте изменить первый параметр с 0 на 1.

Вот небольшая сводка по xp_delete_file Я только что нашел. Похоже, вам не повезло с этой процедурой.