Verifica Restore em Tempo Real – SQL Server

Neste artigo irei mostrar uma query que mostra informações de um RESTORE em tempo real.

A query irá retornar os seguintes campos:

  • HostName: nome do servidor (hostname) na qual a sessão está sendo executada.
  • LoginName: nome do logon do SQL Server no qual a sessão está sendo executada.
  • SessionID: id da sessão a que esta solicitação está relacionada.
  • Percent: porcentagem de trabalho concluída até o momento.
  • MinutesRunning: tempo de execução em minutos.
  • StartTime: data/hora do inicio do RESTORE.
  • EstimatedCompletion: data/hora previsto para o fim do RESTORE.
  • DatabaseName: database no qual a solicitação está em execução.
  • ProgramName: nome do programa cliente (ou JOB) que iniciou o RESTORE.
  • Command: identifica qual tipo de comando está sendo realizado no momento.
  • Text: comando SQL utilizado no RESTORE.

Links úteis:
sys.dm_exec_requests
– sys.dm_exec_sessions
– sys.dm_exec_sql_text
dbo.sysjobs

* esta query é compatível com o SQL Server 2008 R2 ou versões superiores.

USE master
GO
SELECT
S.Host_Name AS [HostName]
,S.Login_Name AS [LoginName]
,R.Session_ID AS [SessionID]
,Cast(R.Percent_Complete AS decimal(10,3)) AS [Percent]
,IsNull(DateDiff(minute, S.Last_Request_Start_Time, GetDate()), 0) [MinutesRunning]
,Start_Time AS [StartTime]
,DateAdd(second, Estimated_Completion_Time / 1000, GetDate()) AS [EstimatedCompletion]
,DB_Name(R.Database_ID) AS [DatabaseName]
,(CASE
WHEN S.Program_Name Like 'SQLAgent - TSQL JobStep (Job %' THEN J.Name
ELSE S.Program_Name END) AS [ProgramName]
,R.Command
,B.Text
FROM
sys.dm_exec_requests R WITH (NOLOCK)
JOIN
sys.dm_exec_sessions S WITH (NOLOCK)
ON
R.Session_ID = S.Session_ID
OUTER APPLY
sys.dm_exec_sql_text(R.SQL_Handle) B
LEFT OUTER JOIN
msdb.dbo.sysjobs J WITH (NOLOCK)
ON
(SubString(Left(J.Job_ID, 8), 7, 2) +
SubString(Left(J.Job_ID, 8), 5, 2) +
SubString(Left(J.Job_ID, 8), 3, 2) +
SubString(Left(J.Job_ID, 8), 1, 2)) = SubString(S.Program_Name, 32, 8)
WHERE
R.Session_ID > 50
AND R.Session_ID <> @@SPID
AND S.[Host_Name] Is Not Null
AND R.Command = 'RESTORE DATABASE'
ORDER BY
S.[Host_Name], S.Login_Name

Resultado:

resultado_query

 

Anúncios

Sequência de Collation – SQL Server

As sequências de collation controlam o modo como o SQL Server trata dados alfanuméricos para as opções de armazenamento, recuperação, classificação e comparação. O SQL Server permite especificar uma sequência de collation para suportar qualquer idioma atualmente usado no mundo.

As sequências de collation podem ser especificadas nos níveis de instância, banco de dados, tabela e coluna. A única sequência de collation que é obrigatória é definida em nível de instância, que tem como padrão todos os outros níveis, a não ser que sejam especificamente cancelados.

Uma sequência de collation define o conjunto alfanumérico suportado, incluindo diferenciação de letras maiúsculas e minúsculas, acentos e kana. Por exemplo, se você utilizar a sequência de collation SQL_Latin1_General_CP1_CI_AI, obterá suporte para um conjunto alfanumérico da Europa Ocidental que não diferencia letras maiúsculas e minúsculas e acentos. SQL_Latin1_General_CP1_CI_AI trata e, E, è, é, ê, e ë como se fossem o mesmo caractere para operações de classificação e comparação, enquanto uma sequência de collation francesa, que diferencia letras maiúsculas e minúsculas (CS) e acentos (AS), trata cada uma delas como um caractere diferente.

Para listar quais são as Collations disponíveis no SQL Server, execute o script a seguir:

SELECT * FROM ::fn_helpcollations()

Você terá este resultado:

collation_01

Notem que no final de cada collation existem algumas siglas (_AS, _WS, etc). Essas siglas possuem algumas diferenças que influenciam diretamente no resultado de uma consulta (ou qualquer outra query) e algumas funcionalidades no banco de dados. São 6 siglas:

AI: Accents Insensitive
AS: Accents Sensitive
CI: Case Insensitive
CS: Case Sensitive
KS: Kanatype Sensitive (1)
WS: Width Sensitive (2)

(1) Kana-sensitive: Especifica que o SQL Server deve distinguir entre os dois tipos de caracteres kana japoneses: hiragana e katakana. Se não for selecionada o SQL Server considera caracteres hiragana e katakana iguais.

(2) Width-sensitive: Especifica que o SQL Server deve distinguir entre um caractere de byte único (meia largura) e o mesmo caractere quando representado como um caractere de byte duplo (largura total). Se não for selecionada o SQL Server considera o byte único e byte duplo igualmente.

Ambas as notas ditas acimas são praticamente não utilizadas.

– Para saber a collation configurada a nível de instância (configurada na instalação), execute o script a seguir:

SELECT ServerProperty('Collation') As Collation_Name, ServerProperty('CollationID') As Collation_ID

– Para saber a collation configurada no seu banco de dados (database), execute o script a seguir:

SELECT DatabasePropertyEx('Database','Collation') As Collation_Name_DB

– Para saber a collation configurada em uma tabela, execute o script a seguir:

SELECT 
	Name, Collation 
FROM
	syscolumns 
WHERE 
	[Id] = Object_ID('Tabela')

Caso o retorno em alguma coluna seja NULL, significa que a collation assumida pela mesma é a mesma collation do database.

Links uteis
Como alterar a collation a nível de instância;
Conflitos de Collation em operações de comparação;
Eliminando caracteres especiais de strings no SQL Server.

Script para listar objetos dependentes – SQL Server

Neste artigo irei mostrar um script que mostra todos os objetos e suas respectivas dependências em um database.

Este script é útil para algumas situações, por exemplo: você irá realizar uma manutenção em uma procedure, e para isto você precisa saber quais são os objetos ‘dependetes’ desta mesma procedure a fim de verificar se estes objetos dependentes poderão ser impactados. Outro exemplo: você irá adicionar um novo campo em um tabela X, com este script você pode verificar a quais procedures, views ou functions utilizam esta tabela, entre outros.

O scritpt retorna os seguintes campos:

– DBName: nome do database;
– Object_Schema: o schema do objeto pai;
– Object_Name: o nome do objeto pai;
– Child_Schema: o schema do objeto dependente (filho);
– Child_Name: o nome do objeto dependente (filho);
– Child_Type: o tipo do objeto, por exemplo: USER_TABLE, SQL_STORED_PROCEDURE, etc.

O script analisa as views sys.objects e sysdepends.

Script

Use <Database>
SELECT
	 DB_Name() As DBName 
	,Referencing.DBObject_Schema As Object_Schema
	,Referencing.DBObject As [Object_Name]
	,Referenced.Child_DBBObject_Schema As [Child_Schema]
	,Referenced.Child_DBObject As [Child_Name]
	,Referenced.Child_DBObject_Type As [Child_Type]
FROM
(
	SELECT
		 [Object_ID] As DBObject_Id
		,Schema_Name([Schema_ID]) As DBObject_Schema
		,Name As DBObject
		,Type_Desc As DBObject_Type
	FROM
		sys.objects
	WHERE
		Type Not In('D','IT','PK','SQ','UQ','U','S','TR')
) Referencing
LEFT OUTER JOIN
(
	SELECT
		 Id As Parent_DBObject_Id
		,DepId As Child_DBObject_Id
		,Schema_Name([Schema_ID]) As Child_DBBObject_Schema
		,Name As Child_DBObject
		,Type_Desc As Child_DBObject_Type
	FROM
		sysdepends 
	JOIN	
		sys.objects
	ON
		[Object_ID] = DepId
	GROUP BY
		Id, DepId, [Schema_Id], Name, Type_Desc
) Referenced
ON
	Referencing.DBObject_Id = Referenced.Parent_DBObject_Id

Se você quiser obter as dependências de um objeto especifico, a cláusula WHERE deve ficar desta maneira:

(...)
ON
	Referencing.DBObject_Id = Referenced.Parent_DBObject_Id
WHERE 
	Referencing.DBObject = 'ObjectName'

Ou caso você queria obter os objetos pais de um objeto especifico (são referenciados), a cláusula WHERE deve ficar desta maneira:

(...)
ON
	Referencing.DBObject_Id = Referenced.Parent_DBObject_Id
WHERE 
	Referenced.Child_DBObject = 'ObjectName'

Movendo arquivos dos databases de sistema – SQL Server

Neste artigo irei mostrar um método para mover os arquivos de DATA e LOG dos databases system (master, msdb, tempdb e model).

Caso você queira saber como mover os arquivos de DATA e LOG dos databases users (databases criado por usuário, a grosso modo), veja este post: Movendo Arquivos dos Databases – SQL Server

Antes de mover os arquivos de DATA e LOG dos databases system no SQL Server, é preciso entender melhor a importância de cada um:

• master: este database armazena todas as configurações à nível de sistema. Qualquer coisa que é definida no nível de instância do SQL Server normalmente é armazenada neste mesmo database. Se o database master estiver danificado ou corrompido, a instância do SQL Server não será iniciado (é importante sempre ser feito um backup deste database!).
• msdb: este database contém informações do SQL Server Agent, assim como Jobs, Operadores e alertas. Este database também contém informações sobre backups e restores feitos, assim como o histórico dos planos de execuções de manutenções, etc. Até a versão do SQL Server 2008 R2 os pacotes do SQL Server Integration Services (SSIS) também eram armazenados neste database.
• model: este database possuí um template no qual todos os usuários dos databases são baseados. Qualquer novo database que é criado usa o model como modelo. Todos os objetos criados no database model estarão presentes em todos os databases que forem criados na instância. Pode parecer que este database não é muito importante, porém caso este database esteja danificado ou corrompido, a instância do SQL Server não será iniciado.
• tempdb: este database armazena os dados temporários da instância. Toda vez que o SQL Server for iniciado, este database é truncado, portanto não há necessidade de realizar um backup deste banco de dados, tanto que não há opção para ser executado um backup deste database.

Vamos começar pelo database master. Você verá que o procedimento para alterar o caminho dos arquivos do database master é diferente dos demais, por que? Quando você inicia o serviço da instância, ele executa um executável e passa os parâmetros dos arquivos de DATA e LOG da master, pois lá que as informações pertinentes à instância se encontram. Claro que a ordem de quais databases você irá mudar não influência, porém há de se tomar MUITO cuidado com os passos a serem feitos, pois um problema que ocorrer, não será possível voltar atrás, claro, dependendo do problema.

Para mudar o caminho dos arquivos de DATA e LOG do database master é necessário realizar os seguintes passos principais:
1. Alterar os parâmetros de inicialização do serviço do SQL Server;
2. Parar o serviço (instância);
3. Mover os arquivos de LOG (mastlog.ldf) e DATA (master.mdf);
4. Iniciar o serviço (instância).

Para começar, vamos verificar onde estão os arquivos de DATA e LOG do database master através da query:

Use master 
GO
EXEC sp_helpfile 

Anote o caminho que está na coluna filename, pois iremos copiar os arquivos que estão neste caminho para um outro caminho, no caso o caminho “C:\CaminhosSQLServer\LOG” para o arquivo de LOG, e o caminho: “C:\CaminhosSQLServer\DATA” para o arquivo de DATA.

master_01

Logo em seguida abra o SQL Server Configuration Manager através do comando mmc.exe

master_02

No nó SQL Server Services, dê um duplo clique na instância do SQL Server, logo em seguida clique em Propriedades, e depois vá na aba Avançado:

master_03

Edite o Parâmetros de Inicialização alterando os parâmetros para onde você irá copiar os arquivos de DATA e LOG. Por exemplo, no meu caso está configurado da seguinte maneira:

-dC:\Program Files\Microsoft SQL Server\MSSQL10_50.ALAN\MSSQL\DATA\master.mdf;-ec:\Program Files\Microsoft SQL Server\MSSQL10_50.ALAN\MSSQL\Log\ERRORLOG;-lC:\Program Files\Microsoft SQL Server\MSSQL10_50.ALAN\MSSQL\DATA\mastlog.ldf

Onde há o parâmetro -d significa o caminho e o arquivo de DATA e o -l para LOG.
Como neste caso eu vou alterar os arquivos para os caminhos “C:\CaminhosSQLServer\LOG” e “C:\CaminhosSQLServer\DATA”, como dito anteriormente, ele deve estar configurado da seguinte maneira:

-dC:\CaminhosSQLServer\DATA\master.mdf;-ec:\Program Files\Microsoft SQL Server\MSSQL10_50.ALAN\MSSQL\Log\ERRORLOG;-lC:\CaminhosSQLServer\LOG\mastlog.ldf

* Não é permitido espaços depois dos parâmetros -d e -l e seus respectivos caminhos.

Em seguida pare o serviço da instância. Com o serviço parado (ele TÊM que estar parado), mova os arquivos de DATA e LOG atuais do database master

Neste exemplo os arquivos estão caminho “C:\Program Files\Microsoft SQL Server\MSSQL10_50.ALAN\MSSQL\DATA\”. Mova os arquivos de LOG e DATA para os respectivos caminhos configurados.

E em seguida inicie o serviço da instância. Se o serviço da instância subir, significa que a mudança do caminho dos arquivos foram feitos com sucesso!

Verifique o novo caminho dos arquivos de LOG e DATA utilizando a mesma query no início do passo-a-passo:

Use master 
GO
EXEC sp_helpfile 

Resultado:

master_04

Feito a mudança dos arquivos de LOG e DATA do database master, vamos executar o passo-a-passo dos demais databases system, no caso as databases: msdb, model e a tempdb.

Neste caso, os passos a serem realizados são mais simples, porém o cuidado deve ser o mesmo! Neste caso farei a mudança de apenas um database, no caso a msdb. Os passos a serem realizados no database msdb são os mesmos para os demais. Você pode fazer a mudança para os três de uma vez só, caso você queira. Não há problema nisso, desde que, claro, seja feito com muita cuidado e atenção.

Neste caso serão realizados 4 passos:
1. Para cada database que terão os arquivos movidos, executar o comando “ALTER DATABASE…MODIFY FILE”;
2. Parar o serviço da instância do SQL Server;
3. Mover os arquivos para os novos caminhos;
4. Iniciar a instância do SQL Server.

Vamos ao exemplo:

Assim como no primeiro passo do database master, obtenha o caminho atual dos arquivos de LOG e DATA do database msdb.

Use msdb
GO
EXEC sp_helpfile 

Guarde o caminho e o nome dos arquivos de LOG e DATA.

master_05

Agora execute o comando a seguir para mover os arquivos de LOG e DATA do database msdb.

USE master
GO
ALTER DATABASE msdb 
	MODIFY FILE 
		(NAME = MSDBData, FILENAME = 'C:\CaminhosSQLServer\DATA\MSDBData.mdf');
GO
ALTER DATABASE msdb 
	MODIFY FILE 
		(NAME = MSDBLog, FILENAME = 'C:\CaminhosSQLServer\LOG\MSDBLog.ldf');
GO

Após executar esta query, você deverá receber esta mensagem:

The file “MSDBData” has been modified in the system catalog. The new path will be used the next time the database is started.
The file “MSDBLog” has been modified in the system catalog. The new path will be used the next time the database is started.

Mova os arquivos de LOG e DATA para os respectivos caminhos conforme o comando feito acima. Agora dê um STOP-START no serviço da instância do SQL Server. Se o serviço da instância subir, significa que a mudança do caminho dos arquivos foram feitos com sucesso!

Verifique novamente o caminho dos arquivos de LOG e DATA utilizando a mesma query no início do passo-a-passo:

Use msdb 
GO
EXEC sp_helpfile 

Resultado:

master_06

É algo simples de ser feito, porém é preciso ser feito com calma e ter cuidado. Todos os passos são importantes. Caso aconteça algo de errado, você não poderá conseguir novamente a instância do SQL Server.

Em caso de erros ao realizar este passo-a-passo, deixe um comentário que eu poderei ajudá-lo da melhor maneira. Em casos de duvidas, também pode deixar um comentário que tentarei respondê-lo o quanto antes.

É isso aí!

Backup Differential não pode ser restaurado porque não há arquivos prontos para reversão – SQL Server

Esta mensagem ocorre quando você tenta restaurar um backup diferencial utilizando o SQL Server 2005 – 2012.

“System.Data.SqlClient.SqlError: The log or differential backup cannot be restored because no files are ready to rollforward. (Microsoft.SqlServer.Smo)”.

Este erro está dizendo que não há nenhuma base de dados no modo no-operational (não-operacional), e, portanto, não foi feita de tal forma que as transações não comitadas (confirmadas) não fossem revertidas. Quando você restaura um backup no modo RESTORE WITH RECOVERY (padrão), indica que o roll forward deve ser realizado somente enquanto o backup FULL for restaurado, ou seja, quando o restore for finalizado nenhum arquivo de LOG ou Differential poderá ser restaurado, pois o arquivo de LOG estará truncado. Ao realizar o restore no modo RESTORE WITH NORECOVERY, após o final do restore do backup FULL o roll forward não será finalizado, assim deixando os arquivos de LOG “abertos” para que mais arquivos de LOG sejam restaurados.

A maneira mais fácil de reproduzir este erro é realizando um backup FULL da sua base de dados, e em seguida restaura-lá com a opção RESTORE WITH RECOVERY. Logo em seguida faça um backup Differential da mesma base de dados e tente restaurar o backup no modo RESTORE WITH RECOVERY. Ao realizar o backup ele irá retornar esta mensagem de erro:

msg_error

Para realizar o restore do Backup Differential da maneira correta, antes você precisa restaurar o backup FULL com a opção WITH NORECOVERY (este é o passo mais importante!):

step02

Após o restore verifique se o database está com o status “RESTORING”:

Use Master
GO
SELECT
	Name, State_Desc
FROM
	sys.databases
WHERE
	Name = N'DBTeste1'

step04

Se ele estiver com o status RESTORING, faça o restore do backup Differential com a opção WITH RECOVERY:

step01

E assim o Backup Differential será restaurado.

É importante e primordial lembrar-se que antes de restaurar um backup Differential ou de Log é preciso restaurar o backup Full da maneira correta para evitar esta mensagem de erro e refazer todo o processo do restore.

É isso aí!

Monitoramento de Serviços do SQL Server – VBScript

Neste artigo mostrarei um script (vbscript) que gera um arquivo no Excel com algumas informações sobre os serviços do SQL Server de um ou mais servidores.

O script irá retornar os seguintes campos:

• System Name: hostname do servidor;
• Display Name: nome do serviço que é mostrado no services.msc;
• Name: nome do serviço;
• Started: se o serviço está ou não iniciado;
• Start Mode: se o serviço está desabilitado, se é iniciado manualmente ou automaticamente;
• Logon Name: qual conta sobe o serviço;
• State: o status do serviço: running (rodando) ou stopped (parado).

Caso o serviço esteja parado, a linha estará com a fonte com cor vermelha.

Este script efetua um SELECT em uma classe (ou tabelas) do Windows – para mais informações destas classes, veja este post. Nesta classe ele coleta as informações referentes aos serviços que possuem o “SQL” no nome. Lembrando que ele não olha nada no banco de dados, ou efetua alguma conexão com o banco de dados, etc. Ele olha diretamente estas informações no SO!

Importante: Este script necessita de um driver, no caso o “Microsoft Excel Driver”. Verifique se você possuí o driver instalado: para isso, vá em Control Panel->Administrative Tools->Data Sources (ODBC), dê um duplo clique. Ele irá mostrar uma série de abas, na aba User DSN (a primeria aba), clique em Add. Veja se está listado o “Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)” ou “Microsoft Excel Driver (*.xls)”:

driverexcel

Caso você não possua o driver, você pode baixar neste link do MSDN.

Obs.: O usuário que executa o script precisa ter permissão para ler estas classes nos servidores onde serão feitas as verificações.

Para executar o script, é preciso criar um arquivo.txt com a lista dos servidores a serem verificados. No script o arquivo é este : C:\Maquinas.txt. Você pode mudar o caminho e o nome do arquivo no seguinte trecho código:

Set InputFile = fso.OpenTextFile(“C:\Maquinas.txt“)

Exemplo: C:\Maquinas.txt

localhost

O script do arquivo verifica_servicos.vbs é este:

Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = True
objExcel.Workbooks.Add
intRow = 2

objExcel.Cells(1, 1).Value = "System Name"
objExcel.Cells(1, 2).Value = "Display Name"
objExcel.Cells(1, 3).Value = "Name"
objExcel.Cells(1, 4).Value = "Started"
objExcel.Cells(1, 5).Value = "Start Mode"
objExcel.Cells(1, 6).Value = "Logon Name"
objExcel.Cells(1, 7).Value = "State"

Set Fso = CreateObject("Scripting.FileSystemObject")
Set InputFile = fso.OpenTextFile("C:\Maquinas.txt")
Do While Not (InputFile.atEndOfStream)
	strComputer = InputFile.ReadLine

	Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
	Set colItems = objWMIService.ExecQuery("Select * From Win32_Service Where Name Like '%SQL%'")

	For Each objItem in colItems
		objExcel.Cells(intRow, 1).Value = objItem.SystemName
		objExcel.Cells(intRow, 2).Value = objItem.DisplayName
		objExcel.Cells(intRow, 3).Value = objItem.Name
		objExcel.Cells(intRow, 4).Value = objItem.Started
		objExcel.Cells(intRow, 5).Value = objItem.StartMode
		objExcel.Cells(intRow, 6).Value = objItem.StartName
		objExcel.Cells(intRow, 7).Value = objItem.State

		If objExcel.Cells(intRow, 7).Value = "Stopped" Then
			objExcel.Cells(intRow, 7).EntireRow.Font.ColorIndex = 3
		End If

		intRow = intRow + 1
	Next
Loop

objExcel.Range("A1:G1").Select
objExcel.Selection.Interior.ColorIndex = 19
objExcel.Selection.Font.ColorIndex = 11
objExcel.Selection.Font.Bold = True
objExcel.Cells.EntireColumn.AutoFit

Set objSheet = objExcel.ActiveWorkbook.Worksheets(1)
Set objRange = objExcel.Range("B2")
objRange.Sort objRange,1,,,,,,1

Execute o verifica_servicos.vbs, o resultado será:

result

Caso você queria saber mais sobre como utilizar o objeto Excel.Application, veja este link.

É isso aí!

Lendo Informações do Backup – SQL Server

Neste artigo irei mostrar alguns comandos T-SQL, que estão disponíveis do SQL Server 2005, que retornam informações úteis dos backups realizado, tais como: arquivos de data e log que estão no backup, horário de inicio e término do backup, integridade do backup realizado, etc.

Os comandos T-SQL são:

RESTORE FILELISTONLY
RESTORE LABELONLY
RESTORE HEADERONLY
RESTORE VERIFYONLY

Obs.: estes comandos apenas extraem as informações que estão no backup, isso sem a necessidade de restaura-lós.

Para saber mais detalhes de cada informação retornada nestes comandos, clique no título do comando.

RESTORE FILELISTONLY

Este comando retorna informações sobre os arquivos de dados (mdf e ndf) e log (ldf) armazenados em um dispositivo.

-- FROM DISK = Caminho\NomeDoArquivo.BAK
RESTORE FILELISTONLY FROM DISK = 'C:\Backups\ALAN_TESTE\ALAN_TESTE_FULL.bak'

Por exemplo, neste comando ele retorna algumas informações importantes como:
– LogicalName: nome lógico do arquivo no SQL Server;
– PhysicalName: caminho e nome do arquivo;
– Type: o tipo do arquivo, ex: se o Type for “D”, trata-se de um arquivo de dados.

bkp01

RESTORE LABELONLY

Este comando retorna um conjunto de resultados que contém informações sobre as mídias de backup identificadas pelo dispositivo de backup designado. É um modo mais rápido de descobrir que a mídia de backup contém. A instrução lê somente o cabeçalho da mídia, essa instrução terminará rapidamente mesmo quando estiverem sendo usados a mídia como a fita.

-- FROM DISK = Caminho\NomeDoArquivo.BAK
RESTORE LABELONLY FROM DISK = 'C:\Backups\ALAN_TESTE\ALAN_TESTE_FULL.bak'

RESTORE HEADERONLY

Este comando retorna informações sobre os backups (Backup Set) armazenados em um dispositivo. É um dos comandos mais utilizados, pois retorna todos os backups armazenados no dispositivo, seus tipos e quais databases eles pertecem, o usuário que realizou o backup, a data de inicío e fim dos backups, collation, modo de recovery, etc.

-- FROM DISK = Caminho\NomeDoArquivo.BAK
RESTORE HEADERONLY FROM DISK = 'C:\Backups\ALAN_TESTE\ALAN_TESTE_FULL.bak'

bkp02

RESTORE VERIFYONLY

Este comando verifica se o conjunto de backup está completo e se todo o backup pode ser lido. Porém, RESTORE VERIFYONLY não tenta verificar a estrutura dos dados contida nos volumes de backup. Se o backup for válido, o retorno será de sucesso.

-- FROM DISK = Caminho\NomeDoArquivo.BAK
RESTORE VERIFYONLY FROM DISK = 'C:\Backups\ALAN_TESTE\ALAN_TESTE_FULL.bak'

Caso o backup seja válido, o retorno deverá ser:

The backup set on file 1 is valid.

Essas informações são importantes para verificar o status do backup para evitar erros ao restaurar o backup, entre outras informações.
É isso aí!