SQL Server xp_delete_file не удаляет файлы
https://stackoverflow.com/questions/212603
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я пытаюсь написать 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, w / SP2
Решение
Была похожая проблема, найдены разные ответы. Вот что я нашел.
Вы не можете удалить файлы 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 и не будет работать с файлами отчетов; для этого есть исправление по адресу >. Я не проверял это с SP3.
Поскольку документ xp_delete_file недокументирован, он может исчезнуть или измениться в будущих версиях SQL Server. Многие сайты рекомендуют вместо этого использовать сценарий оболочки.
Другие советы
AFAIK xp_delete_file удаляет только файлы, распознаваемые SQL Server 2005 (резервные файлы, журналы транзакций, ...). Возможно, вы можете попробовать что-то вроде этого:
xp_cmdshell 'del <filename>'
Этот sp только удалит только собственные файлы резервных копий сервера SQL или файлы отчетов о техническом обслуживании (в целях безопасности)
Как сказал Smink, вы можете использовать
xp_cmdshell 'del <filename>'
С соответствующими разрешениями на папку.
Я нашел этот вопрос, но решение не применимо ко мне (так как это были файлы .bak, которые сам SQL Server создал в рамках плана обслуживания).
В моем случае проблема заключалась в безопасности. Сценарий запускался как пользователь, который запускает SQL Server (MSSQL) (в моем случае и, вероятно, в большинстве случаев «сетевая служба») не имел доступа к папке, в которой он пытался удалить файлы.
Итак, добавление " сетевой службы " и предоставление ему "изменить" помог.
Я прочитал много разных подходов и решений, которые преследовали несколько человек, пытаясь решить проблему с помощью расширенной хранимой процедуры xp_delete. Решения:
<Ол>В моем сценарии все вышеперечисленное было правильным. Есть несколько комментариев в Интернете, где некоторые из них сказали, что подпрограмма 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 успешно работал.
Один из подходов к тестированию - использовать задачу обслуживания для удаления отдельного файла.
Попробуйте изменить первый параметр с 0 на 1.
Вот небольшая сводка по xp_delete_file Я только что нашел. Похоже, вам не повезет с этой процедурой.
Я знаю, что это немного старо, но я хотел поделиться своими разочарованиями со всеми вами. У меня была та же проблема, что и у многих из этих постов, но, похоже, ничего не получалось. Затем я вспомнил, что у нас есть уровень шифрования в базе данных под названием NetLib. Это означает, что резервные копии зашифрованы и, как таковой, xp_delete_file не может прочитать заголовки. Теперь я использую командный файл в ОС и вызываю его из задания агента. Надеюсь, это кому-нибудь поможет.
Обычно мы попадаем в такие ситуации, когда база данных перемещается на другой сервер или когда экземпляр SQL переустанавливается на тот же сервер, но резервная копия остается в старом каталоге. Например: Вы перемещаете базу данных с сервера1 на сервер2, но у вас есть сервер с планом обслуживания, который выполняет периодическое резервное копирование, или вы переустанавливаете экземпляр SQL на сервере1 и вы восстанавливаете базу данных.
В случае резервного копирования наборы, которые хранятся в виде информации в базе данных msdb, больше не существуют, поэтому все старые резервные копии, которые были созданы, не будут удалены из-за отсутствия информации. проверяется на наличие ошибок, полученных из таблиц с резервными наборами.
EXECUTE master.sys.xp_delete_file 0, -- FileTypeSelected (0 = FileBackup, 1 = FileReport)
Первый аргумент показывает, что таблицы из msdb используются.
Надеюсь, это кому-нибудь поможет.
