Подтвердить что ты не робот

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

Я пытаюсь написать некоторый 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' a конец на '0'.

Это возвращает "успех", но файлы не удаляются.

Я использую SQL Server 2005, Standard, w/SP2

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

xp_cmdshell 'del <filename>'

Ответ 3

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

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

xp_cmdshell 'del <filename>'

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

Ответ 4

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

В моем случае проблема была в безопасности. script запускался как пользователь, который запускает SQL Server (MSSQL) (в моем случае и, возможно, в большинстве случаев "сетевой сервис" ) не имел доступа к папке, в которой он пытался удалить файлы.

Поэтому добавление "сетевого сервиса" и предоставление его "модификации" помогло.

Ответ 5

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

  • Обязательно НЕ иметь период (.) в расширении при настройке задачи обслуживания SSIS.
  • Обязательно зайдите в подпапки Include First-Level, если они существуют для каждой резервной копии базы данных.
  • Обязательно нажмите на резервные файлы вверху. Задача обслуживания проверяет тип файла. Для резервного копирования базы данных я считаю, что он проверяет заголовок файла резервной копии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

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

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

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