SQL Server xp_delete_file no elimina archivos

StackOverflow https://stackoverflow.com/questions/212603

  •  03-07-2019
  •  | 
  •  

Pregunta

Estoy tratando de escribir algo de SQL que eliminará los archivos de tipo '.7z' que tienen más de 7 días.

Esto es lo que tengo que no funciona: 

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

También he intentado cambiar el '1' al final por un '0'.

Esto devuelve 'éxito', pero los archivos no se eliminan.

Estoy usando SQL Server 2005, Standard, w / SP2

¿Fue útil?

Solución

Tuve un problema similar, encontré varias respuestas. Esto es lo que encontré.

No puede eliminar archivos 7z con xp_delete_file. Este es un procedimiento almacenado extendido no documentado que se conserva de SQL 2000. Comprueba la primera línea del archivo que se va a eliminar para verificar que sea un archivo de copia de seguridad de SQL o un archivo de informe de SQL. No se verifica en función de la extensión del archivo. Por lo que deduzco, su uso previsto es en planes de mantenimiento para limpiar copias de seguridad antiguas e informes de planes.

Aquí hay una muestra basada en el enlace de Tomalak para eliminar archivos de copia de seguridad de más de 7 días. Lo que hace tropezar a la gente es el esquema 'sys', la barra diagonal final en la ruta de la carpeta y ningún punto en la extensión del archivo que hay que buscar. El usuario que ejecuta SQL Server también necesita tener permisos de eliminación en la carpeta. 

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)

Tenga en cuenta que xp_delete_file está dañado en SP2 y no funcionará en los archivos de informe; hay una revisión para ello en [ http://support.microsoft.com/kb/938085font>. No lo he probado con SP3.

Como no está documentado, xp_delete_file puede desaparecer o cambiar en futuras versiones de SQL Server. Muchos sitios recomiendan un script de shell para hacer las eliminaciones en su lugar.

Otros consejos

AFAIK xp_delete_file solo elimina archivos reconocidos por SQL Server 2005 (archivos de copia de seguridad, registros de transacciones, ...). Quizás puedas probar algo como esto: 

xp_cmdshell 'del <filename>'

Este sp solo eliminará los archivos de copia de seguridad del servidor sql nativo o los archivos de informes de mantenimiento nativos (por razones de seguridad)

Como Smink sugirió que puedes usar 

xp_cmdshell 'del <filename>'

Con los permisos adecuados en la carpeta.

Encontré esta pregunta, pero la solución no se aplicaba a mí (como lo eran los archivos .bak, que el propio SQL Server había creado, como parte de un Plan de mantenimiento).

El problema en mi caso era la seguridad. El script se estaba ejecutando porque el usuario que inicia SQL Server (MSSQL) (en mi caso y probablemente en la mayoría de los casos "servicio de red") no tenía acceso a la carpeta en la que intentaba eliminar archivos.

Por lo tanto, agregar " servicio de red " y concediéndolo " modificar " ayudó.

Había leído muchos enfoques y soluciones diferentes que perseguían varios individuos al intentar resolver el problema con el procedimiento almacenado extendido xp_delete. Las soluciones son:

  1. Asegúrese de NO tener un punto (.) en la extensión al configurar la tarea de mantenimiento de SSIS.
  2. Asegúrese de hacer clic en Incluir subcarpetas de primer nivel si existen para cada copia de seguridad de la base de datos.
  3. Asegúrese de hacer clic en los archivos de copia de seguridad en la parte superior. La tarea de mantenimiento verifica el tipo de archivo. Para las copias de seguridad de la base de datos, creo que comprueba el encabezado del archivo de copia de seguridad.

En mi escenario, todo lo anterior era correcto. Hay pocos comentarios en la web donde algunos de los que dicen que la rutina xp_delete tiene errores.

Cuando los archivos de copia de seguridad no se eliminaron, extraje el SQL para el mantenimiento y lo ejecuté desde SSMS. El mensaje resultante fue que el archivo no era un archivo de copia de seguridad del servidor SQL. Este mensaje fue erróneo ya que la copia de seguridad se pudo restaurar con éxito, lo que resultó en una base de datos operativa.

Los comandos de la base de datos utilizados para verificar la base de datos fueron: 

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

Los dos comandos anteriores indicaron que el archivo de copia de seguridad era válido.

A continuación, abrí el visor de eventos y encontré mensajes que indicaban que había errores de inicio de sesión para el administrador de conexión. Esto fue extraño porque había validado la conexión con el botón de conexión de prueba. Los errores no estaban relacionados con ninguna cuenta que había creado.

Mensaje del Visor de eventos:

  

* No se puede encontrar la descripción para el evento ID 17052 del servidor fuente MS SQL. O el componente que genera este evento no está instalado en su computadora local o la instalación está dañada. Puede instalar o reparar el componente en la computadora local.   Si el evento se originó en otra computadora, la información de la pantalla debía guardarse con el evento.

La siguiente información se incluyó con el evento:

  

Gravedad: 16 Error: 18456, SO: 18456 [Microsoft] [SQL Server Native Client 11.0] [SQL Server] Error de inicio de sesión para el usuario 'dominio \ nombre de servidor $'. *

A continuación, inicié sesión en una máquina donde xp_delete funcionaba correctamente. Después de revisar el directorio activo y no encontrar la cuenta del sistema, pasé al visor de eventos para encontrar mensajes similares. Aquí se hizo evidente que la cuenta para el dominio \ servidor $ se asigna a la seguridad del sistema.

El siguiente paso fue comparar la seguridad de la base de datos donde xp_delete funcionaba con la base de datos donde no funcionaba. Había 2 inicios de sesión faltantes bajo seguridad en la base de datos donde xp_delete no funcionaba. Los 2 inicios de sesión faltantes fueron: NT AUTORIDAD \ SISTEMA Servicio NT \ MSSQLSERVER

Después de agregar el servicio NT \ MSSQLSERVER, xp_delete funcionó correctamente.

Un enfoque de las pruebas es utilizar la tarea de mantenimiento para eliminar un archivo individual.

Intente cambiar el primer parámetro de 0 a 1.

Aquí hay un pequeño resumen en xp_delete_file acabo de encontrar. Parece un poco como si no tuvieras suerte con este procedimiento.

Sé que esto es un poco viejo, pero quería compartir mis frustraciones con todos ustedes. Estaba teniendo el mismo problema que muchas de estas publicaciones, pero nada parecía funcionar. Entonces recordé que tenemos una capa de cifrado en la base de datos llamada NetLib. Esto significa que las copias de seguridad están encriptadas y, como tal, xp_delete_file no puede leer los encabezados. Ahora uso un archivo por lotes en el sistema operativo y lo llamo desde un trabajo de agente. Espero que esto ayude a alguien.

Por lo general, terminamos en tales situaciones cuando la base de datos se mueve a otro servidor o cuando una instancia de SQL se reinstala en el mismo pero la copia de seguridad se deja en el directorio anterior. Por ejemplo: Mueve la base de datos del servidor1 al servidor2, pero tiene un servidor con un plan de mantenimiento que realiza una copia de seguridad periódica o reinstala la instancia de SQL en el servidor1 y restaura la base de datos.

En el caso de la copia de seguridad, los conjuntos que se guardan como información en msdb ya no están allí, por lo tanto, todas las copias de seguridad anteriores que se hayan creado no se eliminarán como información se verifica a partir de los errores derivados de las tablas con conjuntos de copias de seguridad. 

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

El primer argumento muestra que se están utilizando las tablas de msdb.

Espero que esto ayude a alguien.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top