SQL Server xp_delete_file não a exclusão de arquivos

https://stackoverflow.com/questions/212603

03-07-2019
|

Pergunta

Eu estou tentando escrever alguns SQL que vai apagar arquivos do tipo '.7z' que são mais velhos do que 7 dias.

Aqui está o que eu tenho que não está funcionando:

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

Eu também tentei mudar o '1' um final a um '0'.

Este retorna 'sucesso', mas os arquivos não são ficando excluído.

Estou usando o SQL Server 2005, Standard, w / SP2

Solução

teve um problema semelhante, encontrou várias respostas. Aqui está o que eu encontrei.

Você não pode excluir 7z arquivos com xp_delete_file. Este é um procedimento armazenado estendido indocumentados que é um resquício de SQL 2000. Ele verifica a primeira linha do arquivo a ser excluído para verificar se ele é um arquivo de backup do SQL ou um arquivo de relatório SQL. Ele não verifica com base na extensão do arquivo. Pelo que pude perceber seu uso pretendido está nos planos de manutenção para backups antigos de limpeza e relatórios do plano.

Aqui está uma amostra com base no link do Tomalak fazer backup de arquivos de exclusão com mais de 7 dias. O que viagens pessoas se é o esquema 'sys', a barra final no caminho da pasta, e nenhum ponto na extensão do arquivo para procurar. O usuário que o SQL Server é executado como também precisa ter permissões de exclusão na pasta.

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)

Note que xp_delete_file é dividido em SP2 e não funcionará em arquivos de relatório; há um hotfix para ele em [ http://support.microsoft.com/kb/938085]. Eu não testei com SP3.

Uma vez que está em situação irregular, xp_delete_file podem desaparecer ou mudar em futuras versões do SQL Server. Muitos sites recomendar um shell script para fazer as exclusões em vez.

Outras dicas

AFAIK xp_delete_file apenas apagar arquivos reconhecidos pelo SQL Server 2005 (arquivos de backup, os logs de transação, ...). Talvez você pode tentar algo como isto:

xp_cmdshell 'del <filename>'

Esta sp só vai só vai apagar arquivos de backup do servidor SQL nativo ou arquivos de relatório de manutenção nativos (para fins de segurança)

Como Smink sugeriu que você pode usar

xp_cmdshell 'del <filename>'

Com as permissões adequadas na pasta.

Eu encontrei esta pergunta, mas a solução não se aplica a mim (como era arquivos .bak, SQL Server próprio tinha feito, como parte de um plano de manutenção).

A questão no meu caso era a segurança. O roteiro foi sendo executado como o usuário que inicia o SQL Server (MSSQL) (no meu caso e, provavelmente, a maioria dos casos "serviço de rede") não tem acesso para a pasta que estava tentando apagar arquivos em.

Assim, acrescentando que "serviço de rede" e concedeu "modificar" ajudou.

Eu tinha lido muitas abordagens e soluções diferentes vários indivíduos perseguidos ao tentar resolver o problema com o procedimento xp_delete armazenado estendido. As soluções são:

Certifique-se de não ter um ponto (.) Na extensão ao configurar a tarefa de manutenção SSIS.
Certifique-se de clicar no sub-pastas de primeiro nível Incluir se elas existem para cada backup do banco de dados.
Certifique-se de clicar nos arquivos de backup no topo. A tarefa de manutenção não verifica o tipo de arquivo. Para backups de banco de dados, eu acredito que ele verifica o cabeçalho do arquivo de backup.

Em meu cenário, todos os itens acima foram corretas. Existem alguns comentários sobre o web, onde alguns dos referidos o xp_delete rotina é buggy.

Quando os arquivos de backup não estavam sendo apagadas, eu extraiu o SQL para a manutenção e correu-lo de SSMS. A mensagem resultante era o arquivo não era um arquivo de backup do servidor SQL. Esta mensagem estava errada como o backup pode ser restaurada com sucesso, resultando em um banco de dados operacional.

Os comandos de banco de dados usados ??para verificar o banco de dados foram:

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

Ambos os comandos acima indicado o arquivo de backup era válido.

Em seguida eu abriu o visualizador de eventos e encontrou mensagens indicando houve erros de login para o gerenciador de conexões. Isso era estranho, porque eu tinha validado a conexão com o botão conexão de teste. Os erros não foram relacionadas a qualquer conta que eu tinha criado.

Visualizador de eventos Mensagem:

* A descrição para Event ID 17052 de fonte MS SQL Server pode não ser encontrada. Ou o componente que gera esse evento não está instalado no seu computador local ou a instalação está danificada. Você pode instalar ou reparar o componente no computador local. Se o evento se originou em outro computador, a informação do mostrador teve que ser salva com o evento.

As informações a seguir foi incluído com o evento:

Gravidade: 16 Erro: 18456, OS:. 18456 [Microsoft] [SQL Server Native Client 11.0] [SQL Server] Falha de logon do usuário 'domain \ servername $' *

Em seguida eu entrei em uma máquina onde xp_delete estava funcionando corretamente. Depois de analisar o diretório ativo e não encontrar a conta do sistema, eu continuei a visualizador de eventos para encontrar mensagens semelhantes. Aqui tornou-se evidente a conta de domínio \ servidor $ é mapeado para a segurança do sistema.

O passo seguinte foi comparar a segurança do banco de dados onde xp_delete trabalhou contra o banco de dados onde não funcionou. Havia 2 logins faltando menos de segurança no banco de dados onde xp_delete não funcionou. Os 2 logins ausentes foram: NT AUTHORITY \ SYSTEM Serviço NT \ MSSQLSERVER

Depois de adicionar o serviço NT \ MSSQLSERVER, xp_delete trabalhado com sucesso.

Uma abordagem para testes é usar a tarefa de manutenção para excluir um arquivo individual.

Tente alterar o primeiro parâmetro de 0 a 1.

Aqui está uma pequena em xp_delete_file Eu só encontrado. Soa um pouco como você estaria fora da sorte com este procedimento.

Eu sei que isto é um pouco velho, mas eu queria compartilhar minhas frustrações com todos vós. Eu estava tendo o mesmo problema que muitos desses lugares, mas nada parecia funcionar. Lembrei-me então de que temos uma camada de criptografia no banco de dados chamado NetLib. Isto significa que os backups são criptografados e, como tal, xp_delete_file não pode ler os cabeçalhos. Eu agora uso um arquivo de lote no sistema operacional e chamá-lo a partir de um trabalho de agente. Espero que isso ajude alguém.

Nós geralmente acabam em tais situações quando você tem o banco de dados movido para outro servidor ou quando uma instância do SQL é reinstalado na mesma, mas o backup é deixado no diretório antigo. Por exemplo: Você mover o banco de dados do server1 para o server2, mas você tem um servidor com um plano de manutenção que realiza um backup periódico ou reinstalar a instância do SQL em server1 e você restaurar o banco de dados.

No caso de backup os conjuntos que são mantidos como informações em msdb não estão mais lá, portanto, todos os backups mais antigos que foram criados não serão eliminados como nenhuma informação é verificada a partir da falha derivada das tabelas com conjuntos de backup.

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

O primeiro mostra argumento de que as tabelas de msdb estão sendo usados.

Espero que isso ajude alguém.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow