SQL Server xp_delete_file no elimina archivos

Question

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

Esto es lo que tengo eso 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' un final a un '0'.

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

estoy usando SQL Server 2005, Standard, w/SP2

Answer 1

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

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

Aquí hay un ejemplo basado en el enlace de Tomalak para eliminar archivos de copia de seguridad anteriores a 7 días. Lo que hace que la gente se despierte es el esquema 'sys', la barra inclinada en la ruta de la carpeta y ningún punto en la extensión del archivo que se debe 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 él en [http://support.microsoft.com/kb/938085]. No lo he probado con SP3.

Dado que no está documentado, xp_delete_file puede desaparecer o cambiar en futuras versiones de SQL Server. Muchos sitios recomiendan un script de shell para realizar las eliminaciones.

Answer 2

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

Aquí está una pequeña summary on xp_delete_file que acabo de encontrar. Suena un poco como si no tuvieras suerte con este procedimiento.

Answer 3

AFAIK xp_delete_file elimine solo los archivos reconocidos por SQL Server 2005 (archivos de copia de seguridad, registros de transacciones, ...). Tal vez usted puede intentar algo como esto:

xp_cmdshell 'del <filename>'

Answer 4

Este SP Sólo se eliminarán los archivos del servidor SQL nativo de copia de seguridad o archivos de informes de mantenimiento nativos (por motivos de seguridad)

Como sugirió Smink puede utilizar

xp_cmdshell 'del <filename>' 

Con los permisos adecuados en la carpeta.

Answer 5

Encontré esta pregunta, pero la solución no se aplicaba a mí (como lo fueron los archivos .bak, SQL Server en sí, como parte de un plan de mantenimiento).

El problema en mi caso era la seguridad. La secuencia de comandos se ejecutaba como 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 los archivos.

Así que agregar "servicio de red" y otorgarle "modificar" ayudó.

Answer 6

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 encriptación 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 SO y lo llamo desde un trabajo de agente. Espero que esto ayude a alguien.

Answer 7

Por lo general, terminamos en tales situaciones cuando se traslada la base de datos a otro servidor o cuando se reinstala una instancia de SQL en la misma, 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 copia de seguridad, los conjuntos que se guardan como información en msdb ya no están allí, por lo tanto, no se eliminarán todas las copias de seguridad anteriores ya que no se verifica información de los errores derivados de las tablas con conjuntos de copia 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.

Answer 8

He leído muchos enfoques y soluciones diferentes que persiguen varias personas al intentar resolver el problema con el procedimiento almacenado extendido xp_delete. Las soluciones son:

1. : asegúrese de no tener un período en la extensión de la configuración de la tarea de mantenimiento de SSIS (.).
2. Asegúrese de hacer clic en las subcarpetas Incluir 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 comprueba el tipo de archivo. Para las copias de seguridad de la base de datos, creo que verifica el encabezado del archivo de respaldo.

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

Cuando los archivos de la copia de seguridad no se borraron, 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 dio como resultado una base de datos operativa.

Los comandos de 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' 

Tanto de los comandos anteriores indicaron el archivo de copia de seguridad válida.

Siguiente 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 Visor de sucesos:

*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.

La siguiente información se incluye con el evento:

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

siguiente que ha iniciado sesión en un equipo en el que xp_delete estaba funcionando correctamente. Después de revisar el directorio activo y no encontrar la cuenta del sistema, procedí al visor de eventos para encontrar mensajes similares. Aquí se hizo evidente que la cuenta de dominio \ server $ está asignada a la seguridad del sistema.

El siguiente paso fue comparar la seguridad de la base de datos donde xp_delete funcionaba en contra de la base de datos donde no funcionaba. Hubo 2 inicios de sesión faltantes en seguridad en la base de datos donde xp_delete no funcionó. Los inicios de sesión 2 desaparecidos fueron: NT AUTHORITY \ SYSTEM NT Service \ MSSQLSERVER

Después de agregar el servicio NT \ MSSQLSERVER, xp_delete trabajado con éxito.

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