2008-10-17 1 views
12

Я пытаюсь написать некоторый SQL, который удалит файлы типа «.7z», которые старше 7 дней.SQL Server xp_delete_file не удаляет файлы

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

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

ответ

19

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

Вы не можете удалить файлы 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_lash не работает в пакете обновления 2 и не будет работать с файлами отчетов; есть исправление для него в [http://support.microsoft.com/kb/938085]. Я не тестировал его с SP3.

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

0

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

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

+0

Tomalak: это не сработало. – GernBlandston 2008-10-17 16:02:45

+0

Я понял, после того, как прочитал резюме, которое я только что написал. Заблуждающийся форум, где-то указывал в сторону моего первого ответа. – Tomalak 2008-10-17 16:04:58

6

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

xp_cmdshell 'del <filename>'
3

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

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

xp_cmdshell 'del <filename>' 

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

1

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

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

Так что добавление «сетевого обслуживания» и предоставление его «модификации» помогло.

0

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

0

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

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

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

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

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

0

Я прочитал много разных подходов и решений для нескольких лиц, преследуемых при попытке решить проблему с расширенной хранимой процедурой 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' 

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

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

Просмотр событий Сообщения:

*The description for Event ID 17052 from source MS SQL SERVER cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. If the event originated on another computer, the display information had to be saved with the event.

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

Severity: 16 Error:18456, OS: 18456 [Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed for user 'domain\servername$'.*

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

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

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

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