2010-03-24 27 views
9

Estoy tratando de escribir una copia de seguridad automatizada y restaurar scripts de T-SQL. He hecho la parte BACKUP pero estoy luchando en RESTORE.SQL Server "RESTORE FILELISTONLY" Resultados

Cuando ejecuto la siguiente declaración en SS Management Studio;

EXEC('RESTORE FILELISTONLY FROM DISK = ''C:\backup.bak''') 

puedo obtener un conjunto de resultados en una cuadrícula y también se puede utilizar

INSERT INTO <temp_table> 
EXEC('RESTORE FILELISTONLY FROM DISK = ''C:\backup.bak''') 

para poblar una tabla temporal. Sin embargo, recibo un error de sintaxis cuando trato de seleccionar de ese conjunto de resultados. por ejemplo,

SELECT * FROM 
EXEC('RESTORE FILELISTONLY FROM DISK = ''C:\backup.bak''') 

Los metadatos del conjunto de resultados deben almacenarse en algún lugar del Diccionario de SQL Server. Encontré otra fórmula de curita para que funcione mi restauración automatizada, pero si pudiera llegar al resultado, crearía una solución más elegante. También tenga en cuenta que es diferente de resultados en 2008 que en 2005.

Gracias de antemano ...

Respuesta

7

No se puede seleccionar a partir EXEC. Solo puede INSERTAR en una tabla (o tabla variable) el conjunto de resultados de un EXEC.

En cuanto a la restauración automatizada, la respuesta en Fully automated SQL Server Restore ya le ofrece todo lo que necesita para crear una solución. Si se debe intentar restaurar automáticamente las bases de datos con una lista de archivos desconocida, ese es un tema diferente.

+0

Gracias por la respuesta. Pero me sorprendió que el comentario de EXEC encuentre campos del comando RESTORE de algún lado (diccionario, metadatos, etc.). Por qué select no puede acceder al mismo recurso para extraer los campos del conjunto de resultados. – mevdiven

+1

EXEC obtiene los campos del conjunto de resultados. No hay diccionario ni metadatos involucrados. –

31

callejón sin salida: SELECT INTO es agradable, ya que no tiene que definir las columnas de las tablas, pero no es compatible con EXEC.

Solución: INSERT INTO admite EXEC, pero requiere que se defina la tabla. Usando el SQL 2008 definition provided by MSDN escribí el siguiente script:

DECLARE @fileListTable TABLE (
    [LogicalName]   NVARCHAR(128), 
    [PhysicalName]   NVARCHAR(260), 
    [Type]     CHAR(1), 
    [FileGroupName]   NVARCHAR(128), 
    [Size]     NUMERIC(20,0), 
    [MaxSize]    NUMERIC(20,0), 
    [FileID]    BIGINT, 
    [CreateLSN]    NUMERIC(25,0), 
    [DropLSN]    NUMERIC(25,0), 
    [UniqueID]    UNIQUEIDENTIFIER, 
    [ReadOnlyLSN]   NUMERIC(25,0), 
    [ReadWriteLSN]   NUMERIC(25,0), 
    [BackupSizeInBytes]  BIGINT, 
    [SourceBlockSize]  INT, 
    [FileGroupID]   INT, 
    [LogGroupGUID]   UNIQUEIDENTIFIER, 
    [DifferentialBaseLSN] NUMERIC(25,0), 
    [DifferentialBaseGUID] UNIQUEIDENTIFIER, 
    [IsReadOnly]   BIT, 
    [IsPresent]    BIT, 
    [TDEThumbprint]   VARBINARY(32) -- remove this column if using SQL 2005 
) 
INSERT INTO @fileListTable EXEC('RESTORE FILELISTONLY FROM DISK = ''YourBackupFile.bak''') 
SELECT * FROM @fileListTable 
+2

Para SQL Server 2005, use la misma definición de tabla con una diferencia: suelte la última columna (TDEThumbprint varbinary (32)). –

+5

Después de que SQL Server 2012 va a necesitar agregar una nueva columna, 'SnapshotURL nvarchar (360)', p. según https://msdn.microsoft.com/en-us/library/ms173778.aspx, pero no estoy seguro si eso es para SQL Server 2014 o 2016 (I _think_ se inicia en 2016 ...) – JonBrave