Exportar (0) Imprimir
Expandir Tudo
Este artigo foi traduzido manualmente. Coloque o ponteiro do mouse sobre as frases do artigo para ver o texto original. Mais informações.
Tradução
Original

RESTORE (Transact-SQL)

Restaura backups feitos por meio do comando BACKUP. Esse comando permite executar os seguintes cenários de restauração:

  • Restaurar um banco de dados inteiro de um backup de banco de dados completo (uma restauração completa).

  • Restaurar parte de um banco de dados (uma restauração parcial).

  • Restaurar arquivos ou grupos de arquivos específicos para um banco de dados (uma restauração de arquivo).

  • Restaurar páginas específicas para um banco de dados (uma restauração de página).

  • Restaurar um log de transações em um banco de dados (uma restauração de log de transações).

  • Reverter um banco de dados ao momento determinado capturado por um instantâneo do banco de dados.

Para obter mais informações sobre cenários de restauração do SQL Server, consulte Visão geral da restauração e recuperação (SQL Server). Para obter mais informações sobre descrições dos argumentos, consulte Argumentos de RESTORE (Transact-SQL).

Observação Observação

Para obter mais informações sobre como restaurar do serviço de armazenamento do Blob do Windows Azure, consulte Backup e restauração do SQL Server com o serviço de armazenamento de Blob do Windows Azure.

Aplica-se a: SQL Server (SQL Server 2008 até a versão atual).

Ícone de vínculo de tópico Convenções da sintaxe Transact-SQL

--To Restore an Entire Database from a Full database backup (a Complete Restore):
RESTORE DATABASE { database_name | @database_name_var } 
 [ FROM <backup_device> [ ,...n ] ]
 [ WITH 
   {
    [ RECOVERY | NORECOVERY | STANDBY = 
        {standby_file_name | @standby_file_name_var } 
       ]
   | ,  <general_WITH_options> [ ,...n ]
   | , <replication_WITH_option>
   | , <change_data_capture_WITH_option>
   | , <FILESTREAM_WITH_option>
   | , <service_broker_WITH options> 
   | , <point_in_time_WITH_options—RESTORE_DATABASE> 
   } [ ,...n ]
 ]
[;]

--To perform the first step of the initial restore sequence 
-- of a piecemeal restore:
RESTORE DATABASE { database_name | @database_name_var } 
   <files_or_filegroups> [ ,...n ]
 [ FROM <backup_device> [ ,...n ] ] 
   WITH 
      PARTIAL, NORECOVERY 
      [  , <general_WITH_options> [ ,...n ] 
       | , <point_in_time_WITH_options—RESTORE_DATABASE> 
      ] [ ,...n ] 
[;]

--To Restore Specific Files or Filegroups: 
RESTORE DATABASE { database_name | @database_name_var } 
   <file_or_filegroup> [ ,...n ]
 [ FROM <backup_device> [ ,...n ] ] 
   WITH 
   {
      [ RECOVERY | NORECOVERY ]
      [ , <general_WITH_options> [ ,...n ] ]
   } [ ,...n ] 
[;]

--To Restore Specific Pages: 
RESTORE DATABASE { database_name | @database_name_var } 
   PAGE = 'file:page [ ,...n ]' 
 [ , <file_or_filegroups> ] [ ,...n ]
 [ FROM <backup_device> [ ,...n ] ] 
   WITH 
       NORECOVERY   
      [ , <general_WITH_options> [ ,...n ] ]
[;]

--To Restore a Transaction Log:
RESTORE LOG { database_name | @database_name_var } 
 [ <file_or_filegroup_or_pages> [ ,...n ] ]
 [ FROM <backup_device> [ ,...n ] ] 
 [ WITH 
   {
     [ RECOVERY | NORECOVERY | STANDBY = 
        {standby_file_name | @standby_file_name_var } 
       ]
    | ,  <general_WITH_options> [ ,...n ]
    | , <replication_WITH_option>
    | , <point_in_time_WITH_options—RESTORE_LOG> 
   } [ ,...n ]
 ] 
[;]

--To Revert a Database to a Database Snapshot:   
RESTORE DATABASE { database_name | @database_name_var } 
FROM DATABASE_SNAPSHOT = database_snapshot_name  

<backup_device>::=
{ 
   { logical_backup_device_name |
      @logical_backup_device_name_var }
 | { DISK | TAPE | URL } = { 'physical_backup_device_name' |
      @physical_backup_device_name_var } 
} 
Note: URL is the format used to specify the location and the file name for the Windows Azure Blob. Although Windows Azure storage is a service, the implementation is similar to disk and tape to allow for a consistent and seemless restore experince for all the three devices. 
<files_or_filegroups>::= 
{ 
   FILE = { logical_file_name_in_backup | @logical_file_name_in_backup_var } 
 | FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var } 
 | READ_WRITE_FILEGROUPS
} 

<general_WITH_options> [ ,...n ]::=  
--Restore Operation Options
   MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name' 
          [ ,...n ] 
 | REPLACE 
 | RESTART 
 | RESTRICTED_USER 
 | CREDENTIAL

--Backup Set Options
 | FILE = { backup_set_file_number | @backup_set_file_number } 
 | PASSWORD = { password | @password_variable } 

--Media Set Options
 | MEDIANAME = { media_name | @media_name_variable } 
 | MEDIAPASSWORD = { mediapassword | @mediapassword_variable } 
 | BLOCKSIZE = { blocksize | @blocksize_variable } 

--Data Transfer Options
 | BUFFERCOUNT = { buffercount | @buffercount_variable } 
 | MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

--Error Management Options
 | { CHECKSUM | NO_CHECKSUM } 
 | { STOP_ON_ERROR | CONTINUE_AFTER_ERROR } 

--Monitoring Options
 | STATS [ = percentage ] 

--Tape Options
 | { REWIND | NOREWIND } 
 | { UNLOAD | NOUNLOAD } 
  
<replication_WITH_option>::=
 | KEEP_REPLICATION 

<change_data_capture_WITH_option>::=
 | KEEP_CDC

<FILESTREAM_WITH_option>::=
 | FILESTREAM ( DIRECTORY_NAME = directory_name )


<service_broker_WITH_options>::= 
 | ENABLE_BROKER 
 | ERROR_BROKER_CONVERSATIONS 
 | NEW_BROKER 


<point_in_time_WITH_options—RESTORE_DATABASE>::= 
 | {
   STOPAT = { 'datetime'| @datetime_var } 
 | STOPATMARK = 'lsn:lsn_number'
                 [ AFTER 'datetime'] 
 | STOPBEFOREMARK = 'lsn:lsn_number'
                 [ AFTER 'datetime'] 
   } 

<point_in_time_WITH_options—RESTORE_LOG>::= 
 | {
   STOPAT = { 'datetime'| @datetime_var } 
 | STOPATMARK = { 'mark_name' | 'lsn:lsn_number' }
                 [ AFTER 'datetime'] 
 | STOPBEFOREMARK = { 'mark_name' | 'lsn:lsn_number' }
                 [ AFTER 'datetime'] 
   } 

Para obter descrições dos argumentos, consulte Argumentos de RESTORE (Transact-SQL).

O SQL Server dá suporte a vários cenários de restauração:

Palavras-chave de RESTORE descontinuadas

As palavras-chave a seguir foram descontinuadas no SQL Server 2008:

Palavra-chave descontinuada

Substituída por...

Exemplo de palavra-chave de substituição

LOAD

RESTORE

RESTORE DATABASE

TRANSACTION

LOG

RESTORE LOG

DBO_ONLY

RESTRICTED_USER

RESTORE DATABASE ... WITH RESTRICTED_USER

RESTORE LOG

RESTORE LOG pode incluir uma lista de arquivos para permitir a criação de arquivos durante o roll forward. Isso é usado quando o backup de log contiver registros de log gravados quando um arquivo foi adicionado ao banco de dados.

Observação Observação

Para um banco de dados que usa o modelo de recuperação completa ou bulk-logged, na maioria dos casos é necessário fazer backup do final do log antes da restauração do banco de dados. Restaurar um banco de dados sem antes fazer backup do final do log resultará em um erro, a não ser que a instrução RESTORE DATABASE contenha a cláusula WITH REPLACE ou WITH STOPAT, que deve especificar um momento ou transação que ocorreu após o final do backup de dados. Para obter mais informações sobre backups da parte final do log, consulte Backups da parte final do log (SQL Server).

Comparação de RECOVERY e NORECOVERY

A reversão é controlada pela instrução RESTORE nas opções [ RECOVERY | NORECOVERY ]:

  • NORECOVERY especifica que a reversão não ocorre. Isso permite que o roll forward continue com a próxima instrução na sequência.

    Nesse caso, a sequência de restauração pode restaurar outros backups e efetuar roll forward neles.

  • RECOVERY (o padrão) indica que a reversão deve ser executada após a conclusão do roll forward no backup atual.

    A recuperação do banco de dados requer que todo o conjunto de dados que está sendo restaurado (o conjunto de roll forward) esteja consistente com o banco de dados. Se o conjunto de roll forward não tiver ido longe o suficiente para ficar consistente com o banco de dados e RECOVERY estiver especificado, o Mecanismo de Banco de Dados emitirá um erro.

Backups do mestre, modelo e msdb que foram criados em uma versão anterior do SQL Server não podem ser restaurados pelo SQL Server 2014.

Observação Observação

Nenhum backup do SQL Server pode ser restaurado para uma versão anterior do SQL Server a não ser na versão na qual o backup foi criado.

Cada versão do SQL Server usa um caminho padrão diferente das versões anteriores. Assim, para restaurar um banco de dados que foi criado no local padrão dos backups de versões anteriores, você deve usar a opção MOVE. Para obter informações sobre o novo caminho padrão, consulte Locais de arquivos para instâncias padrão e nomeadas do SQL Server.

Depois de você restaurar um banco de dados da versão anterior para o SQL Server 2014, o banco de dados será atualizado automaticamente. Normalmente, o banco de dados se torna disponível imediatamente. No entanto, se um banco de dados do SQL Server 2005 tiver índices de texto completo, o processo de atualização importará, redefinirá ou recriará esses índices, dependendo da configuração da propriedade de servidor upgrade_option . Se a opção de atualização for definida para importação (upgrade_option = 2) ou recriação (upgrade_option = 0), os índices de texto completo permanecerão indisponíveis durante a atualização. Dependendo da quantidade de dados a serem indexados, a importação pode levar várias horas, e a recriação pode ser até dez vezes mais demorada. Lembre-se também de que, quando a opção de atualização estiver definida para importar, os índices de texto completo associados serão recriados se um catálogo de texto completo não estiver disponível. Para alterar a configuração da propriedade de servidor upgrade_option, use sp_fulltext_service.

Quando um banco de dados é anexado ou restaurado pela primeira vez a uma nova instância do SQL Server, uma cópia da chave mestra de banco de dados (criptografada pela chave mestra de serviço) ainda não está armazenada no servidor. Você deve usar a instrução OPEN MASTER KEY para descriptografar a chave mestra do banco de dados (DMK). Uma vez que a DMK foi descriptografada, você tem a opção de permitir a descriptografia automática futuramente usando a instrução ALTER MASTER KEY REGENERATE para fornecer ao servidor uma cópia da DMK criptografada com a SMK. Quando um banco de dados for atualizado de uma versão anterior, a DMK deverá ser regenerada para usar o algoritmo AES mais recente. Para obter mais informações sobre a regeneração da DMK, consulte ALTER MASTER KEY (Transact-SQL). O tempo necessário para regenerar a chave DMK para atualizar o AES depende do número de objetos protegidos pela DMK. É necessário regenerar a chave DMK para atualizar o AES somente uma vez, isso não tem impacto sobre regenerações futuras como parte de uma estratégia de rotação de chave.

Durante uma restauração offline, se o banco de dados especificado estiver em uso, RESTORE forçará a saída do usuário depois de um pequeno atraso. Para restauração online de um grupo de arquivos não primário, o banco de dados pode permanecer em uso, exceto quando o grupo de arquivos que está sendo restaurado for colocado offline. Todos os dados no banco de dados especificado são substituídos pelos dados restaurados.

Para obter mais informações sobre a recuperação de banco de dados, consulte Visão geral da restauração e recuperação (SQL Server).

As operações de restauração entre plataformas, mesmo entre tipos diferentes de processadores, podem ser executadas desde que o agrupamento do banco de dados tenha suporte no sistema operacional.

RESTORE pode ser reiniciado depois de um erro. Além disso, você pode instruir RESTORE a prosseguir, apesar dos erros, e ele restaura o máximo possível de dados (consulte a opção CONTINUE_AFTER_ERROR).

RESTORE não é permitido em uma transação explícita ou implícita.

A restauração de um banco de dados mestre danificado é executada por meio de um procedimento especial. Para obter mais informações, consulte Fazer backup e restaurar bancos de dados do sistema (SQL Server).

A restauração de um banco de dados limpa o cache de planos da instância do SQL Server. A limpeza do cache de planos gera uma recompilação de todos os planos de execução subsequentes e pode causar uma queda repentina e temporária no desempenho de consultas. Para cada armazenamento em cache limpo no cache de planos, o log de erros do SQL Server contém a seguinte mensagem informativa: "O SQL Server encontrou %d ocorrência(s) de liberação de armazenamento em cache '% s' (parte do cache de planos) devido à manutenção do banco de dados ou operações de reconfiguração". Essa mensagem é registrada a cada cinco minutos, contanto que o cache seja liberado dentro desse intervalo de tempo.

Para restaurar um banco de dados de disponibilidade, primeiro restaure o banco de dados à instância de SQL Server, em seguida, adicione o banco de dados ao grupo de disponibilidade.

Restauração e configuração do banco de dados

Durante uma restauração, a maioria das opções do banco de dados que são configuráveis com ALTER DATABASE é redefinida com os valores em vigor no momento do término do backup.

Porém, o uso da opção WITH RESTRICTED_USER substitui esse comportamento pela configuração da opção de acesso do usuário. Essa configuração sempre é definida seguindo uma instrução RESTORE que inclui a opção WITH RESTRICTED_USER.

Restaurando um banco de dados criptografado

Para restaurar um banco de dados criptografado, é necessário ter acesso ao certificado ou à chave assimétrica usada para criptografar o banco de dados. Sem o certificado ou a chave assimétrica, o banco de dados não pode ser restaurado. Como resultado, o certificado usado para criptografar a chave de criptografia do banco de dados deve ser retido enquanto o backup for necessário. Para obter mais informações, consulte Certificados e chaves assimétricas do SQL Server.

Restaurando um bancos de dados habilitado para armazenamento vardecimal

O backup e a restauração funcionam corretamente com o formato de armazenamento vardecimal. Para obter mais informações sobre o formato de armazenamento vardecimal, consulte sp_db_vardecimal_storage_format (Transact-SQL).

Restaurar dados de texto completo

Dados de texto completo são restaurados com outros dados do banco de dados durante uma restauração completa. Usando a sintaxe RESTORE DATABASE database_name FROM backup_device comum, os arquivos de texto completo são restaurados como parte da restauração de arquivo de banco de dados.

A instrução RESTORE também pode ser usada para executar restaurações em locais alternados, restaurações diferenciais, restaurações de arquivos e grupos de arquivos e restaurações de arquivos e grupos de arquivos diferenciais de dados de texto completo. Além disso, RESTORE pode restaurar apenas arquivos de texto completo, assim como dados de banco de dados.

Observação Observação

Catálogos de texto completo importados do SQL Server 2005 ainda são tratados como arquivos de banco de dados. Nesse caso, o procedimento usado pelo SQL Server 2005 para fazer backup de catálogos de texto completo ainda se aplica, exceto pelo fato de que não é mais necessário pausar e retomar a operação de backup. Para obter mais informações, consulte Backup e restauração de catálogos de texto completo.

O SQL Server inclui tabelas de histórico de backup e restauração que controlam a atividade de backup e restauração de cada instância de servidor. Quando uma restauração é executada, as tabelas de histórico de backup também são modificadas. Para obter mais informações sobre essas tabelas, consulte Informações de histórico e cabeçalho de backup (SQL Server).

REPLACE raramente deve ser usado e só depois de cuidadosa consideração. Normalmente a restauração evita a substituição acidental de um banco de dados por um banco de dados diferente. Se o banco de dados especificado em uma instrução RESTORE já existir no servidor atual e a GUID de família do banco de dados especificado for diferente da GUID de família do banco de dados registrado no conjunto de backup, o banco de dados não será restaurado. Essa é uma proteção importante.

A opção REPLACE substitui várias verificações de segurança importantes que a restauração geralmente executa. As verificações substituídas são as seguintes:

  • Restauração de um banco de dados existente com um backup tirado de outro banco de dados.

    Com a opção REPLACE, a restauração permite que você substitua um banco de dados existente por qualquer banco de dados do conjunto de backup, mesmo que o nome do banco de dados especificado seja diferente do nome de banco de dados registrado no conjunto de backup. Isso pode resultar na substituição acidental de um banco de dados por um banco de dados diferente.

  • Restauração de um banco de dados que usa o modelo de recuperação bulk-logged onde um backup do final do log não foi feito e a opção STOPAT não é usada.

    Com a opção REPLACE, você pode perder trabalho confirmado porque não foi feito backup do log gravado mais recentemente.

  • Substituição de arquivos existentes.

    Por exemplo, um engano poderia permitir a substituição de arquivos do tipo errado, como arquivos .xls, ou que estivessem sendo usados por outro banco de dados que não estivesse online. A perda de dados arbitrária é possível se arquivos existentes forem substituídos, embora o banco de dados restaurado esteja completo.

Não é possível desfazer os efeitos de uma restauração; no entanto, você pode recusar os efeitos de roll forward e de cópia dos dados reiniciando em uma base de um arquivo por vez. Para recomeçar, restaure o arquivo desejado e execute o roll forward novamente. Por exemplo, se você restaurou muitos backups de log acidentalmente e excedeu o ponto de parada pretendido, reinicie a sequência.

Uma sequência de restauração pode ser anulada e reiniciada com a restauração de todo o conteúdo dos arquivos afetados.

Uma operação de reversão de banco de dados (especificada com a opção DATABASE_SNAPSHOT) reverte um banco de dados de origem completo, revertendo-o para o momento de um instantâneo do banco de dados, ou seja, com a substituição do banco de dados de origem pelos dados do momento determinado mantidos no instantâneo do banco de dados especificado. Só o instantâneo para o qual você está revertendo pode existir atualmente. A operação de reversão, então, reconstrói o log (portanto, você não poderá efetuar roll forward em um banco de dados revertido até o ponto do erro do usuário).

A perda de dados é limitada às atualizações no banco de dados desde a criação do snapshot. Os metadados de um banco de dados revertido são iguais aos metadados no momento da criação do instantâneo. No entanto, a reversão para um instantâneo descarta todos os catálogos de texto completo.

A reversão a partir de um instantâneo do banco de dados não é destinada à recuperação de mídia. Ao contrário de um conjunto de backup regular, o instantâneo de banco de dados é uma cópia incompleta dos arquivos do banco de dados. Se o banco de dados ou o instantâneo do banco de dados está corrompido, é provável que a reversão a partir de um instantâneo seja impossível. Além disso, mesmo quando possível, é improvável que a reversão corrija o problema no caso de corrupção.

Restrições na reversão

Não há suporte para a reversão nas seguintes condições:

  • O banco de dados de origem contém algum grupo de arquivos somente leitura ou compactado.

  • Há algum arquivo offline que estava online quando o instantâneo foi criado.

  • Existe mais de um instantâneo do banco de dados atualmente.

Para obter mais informações, consulte Reverter um banco de dados a um instantâneo do banco de dados.

Uma operação de backup pode, opcionalmente, especificar senhas para um conjunto de mídias, um conjunto de backup ou ambos. Quando uma senha tiver sido definida em um conjunto de backup ou de mídias, será preciso especificar a senha ou as senhas corretas na instrução RESTORE. Essas senhas impedem operações de restauração não autorizadas e anexações não autorizadas de conjuntos de backup para mídia usando ferramentas do SQL Server. Porém, mídia protegida por senha pode ser substituída pela opção FORMAT da instrução BACKUP.

Observação sobre segurança Observação sobre segurança

A proteção fornecida por esta senha é fraca. Destina-se a evitar uma restauração incorreta com o uso de ferramentas de SQL Server por usuários autorizados ou não autorizados. Não impede a leitura dos dados de backup por outros meios ou a substituição da senha. Esse recurso será removido em uma versão futura do Microsoft SQL Server. Evite usar esse recurso em desenvolvimentos novos e planeje modificar os aplicativos que atualmente o utilizam. A prática recomendada para proteger backups é armazenar as fitas de backup em um local seguro ou fazer backup em arquivos de disco protegidos por ACLs (listas de controle de acesso) adequadas. As ACLs devem ser definidas no diretório raiz em que os backups são criados.

Para obter informações específicas sobre o backup e a restauração do SQL Server com o armazenamento do Blob do Windows Azure, consulte Backup e restauração do SQL Server com o serviço de armazenamento de Blob do Windows Azure.

Permissões

Se o banco de dados que está sendo restaurado não existir, o usuário deverá ter permissões CREATE DATABASE para poder executar o comando RESTORE. Se o banco de dados existir, permissões RESTORE assumirão como padrão os membros das funções de servidor fixas sysadmin e dbcreator e o proprietário (dbo) do banco de dados (para a opção FROM DATABASE_SNAPSHOT, o banco de dados sempre existe).

As permissões RESTORE são concedidas a funções nas quais as informações de associação estão sempre disponíveis para o servidor. Como a associação da função de banco de dados fixa pode ser verificada apenas quando o banco de dados está acessível e não danificado, o que nem sempre é o caso quando RESTORE é executado, os membros da função de banco de dados fixa db_owner não têm permissões RESTORE.

Todos os exemplos presumem que um backup de banco de dados completo foi executado.

Os exemplos de RESTORE incluem o seguinte:

Observação Observação

Para obter exemplos adicionais, consulte os tópicos de instruções de restauração listados em Visão geral da restauração e recuperação (SQL Server).

A.Restaurando um banco de dados completo

O exemplo a seguir restaura um backup de banco de dados completo do dispositivo de backup lógico AdventureWorksBackups. Para obter um exemplo de como criar esse dispositivo, consulte Dispositivos de backup.

RESTORE DATABASE AdventureWorks2012 
   FROM AdventureWorks2012Backups;
ObservaçãoObservação

Para um banco de dados que usa o modelo de recuperação completa ou bulk-logged, o SQL Server requer que se faça backup do final do log antes da restauração do banco de dados. Para obter mais informações, consulte Backups da parte final do log (SQL Server).

[Início dos exemplos]

B.Restaurando backups de banco de dados diferenciais e completos

O exemplo a seguir restaura um backup de banco de dados completo seguido por um backup diferencial do dispositivo de backup Z:\SQLServerBackups\AdventureWorks2012.bak, que contém os dois backups. O backup de banco de dados completo a ser restaurado é o sexto conjunto de backup no dispositivo (FILE = 6), e o backup de banco de dados diferencial é o nono no dispositivo (FILE = 9). Assim que o backup diferencial é recuperado, o banco de dados é recuperado.

RESTORE DATABASE AdventureWorks2012
   FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2012.bak'
   WITH FILE = 6
      NORECOVERY;
RESTORE DATABASE AdventureWorks2012
   FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2012.bak'
   WITH FILE = 9
      RECOVERY;

[Início dos exemplos]

C.Restaurando um banco de dados usando a sintaxe RESTART

O exemplo a seguir usa a opção RESTART para reiniciar uma operação RESTORE interrompida por uma deficiência de força no servidor.

-- This database RESTORE halted prematurely due to power failure.
RESTORE DATABASE AdventureWorks2012
   FROM AdventureWorksBackups;
-- Here is the RESTORE RESTART operation.
RESTORE DATABASE AdventureWorks2012 
   FROM AdventureWorksBackups WITH RESTART;

[Início dos exemplos]

D.Restaurando um banco de dados e movendo arquivos

O exemplo a seguir restaura um banco de dados completo e log de transações e move o banco de dados restaurado para o diretório C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Data.

RESTORE DATABASE AdventureWorks2012
   FROM AdventureWorksBackups
   WITH NORECOVERY, 
      MOVE 'AdventureWorks2012_Data' TO 
'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Data\NewAdvWorks.mdf', 
      MOVE 'AdventureWorks2012_Log' 
TO 'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Data\NewAdvWorks.ldf';
RESTORE LOG AdventureWorks2012
   FROM AdventureWorksBackups
   WITH RECOVERY;

[Início dos exemplos]

E.Copiando um banco de dados usando BACKUP e RESTORE

O exemplo a seguir usa as instruções BACKUP e RESTORE para fazer uma cópia do banco de dados AdventureWorks2012 . A instrução MOVE causa a restauração dos dados e do arquivo de log nos locais especificados. A instrução RESTORE FILELISTONLY é usada para determinar o número e os nomes dos arquivos no banco de dados que está sendo restaurado. A nova cópia do banco de dados é nomeada TestDB. Para obter mais informações, consulte RESTORE FILELISTONLY (Transact-SQL).

BACKUP DATABASE AdventureWorks2012 
   TO AdventureWorksBackups ;

RESTORE FILELISTONLY 
   FROM AdventureWorksBackups ;

RESTORE DATABASE TestDB 
   FROM AdventureWorksBackups 
   WITH MOVE 'AdventureWorks2012_Data' TO 'C:\MySQLServer\testdb.mdf',
   MOVE 'AdventureWorks2012_Log' TO 'C:\MySQLServer\testdb.ldf';
GO

[Início dos exemplos]

F.Restauração pontual usando STOPAT

O exemplo a seguir restaura um banco de dados para seu estado de 12:00 AM em April 15, 2020 e mostra uma operação de restauração que envolve vários backups de log. No dispositivo de backup, AdventureWorksBackups, o backup de banco de dados completo a ser restaurado é o terceiro conjunto de backup no dispositivo (FILE = 3), o primeiro backup de log é o quarto conjunto de backup (FILE = 4), e o segundo backup de log é o quinto conjunto de backup (FILE = 5).

RESTORE DATABASE AdventureWorks2012
   FROM AdventureWorksBackups
   WITH FILE=3, NORECOVERY;

RESTORE LOG AdventureWorks2012
   FROM AdventureWorksBackups
   WITH FILE=4, NORECOVERY, STOPAT = 'Apr 15, 2020 12:00 AM';

RESTORE LOG AdventureWorks2012
   FROM AdventureWorksBackups
   WITH FILE=5, NORECOVERY, STOPAT = 'Apr 15, 2020 12:00 AM';
RESTORE DATABASE AdventureWorks2012 WITH RECOVERY; 

[Início dos exemplos]

G.Restaurando o log de transações até uma marca

O exemplo a seguir restaura o log de transações até a marca na transação marcada denominada ListPriceUpdate.

USE AdventureWorks2012
GO
BEGIN TRANSACTION ListPriceUpdate
   WITH MARK 'UPDATE Product list prices';
GO

UPDATE Production.Product
   SET ListPrice = ListPrice * 1.10
   WHERE ProductNumber LIKE 'BK-%';
GO

COMMIT TRANSACTION ListPriceUpdate;
GO

-- Time passes. Regular database 
-- and log backups are taken.
-- An error occurs in the database.
USE master;
GO

RESTORE DATABASE AdventureWorks2012
FROM AdventureWorksBackups
WITH FILE = 3, NORECOVERY;
GO

RESTORE LOG AdventureWorks2012
   FROM AdventureWorksBackups 
   WITH FILE = 4,
   RECOVERY, 
   STOPATMARK = 'UPDATE Product list prices';

[Início dos exemplos]

H.Restaurando com o uso da sintaxe de TAPE

O exemplo a seguir restaura um backup de banco de dados completo de um dispositivo de backup TAPE.

RESTORE DATABASE AdventureWorks2012 
   FROM TAPE = '\\.\tape0';

[Início dos exemplos]

I.Restaurando usando a sintaxe FILE e FILEGROUP

O exemplo a seguir restaura um banco de dados nomeado MyDatabase que tem dois arquivos, um grupo de arquivos secundário e um log de transações. O banco de dados usa o modelo de recuperação completa.

O backup do banco de dados é o nono conjunto de backup no conjunto de mídias em um dispositivo de backup lógico nomeado MyDatabaseBackups. Depois, três backups de log, que estão nos próximos três conjuntos de backup (10, 11 e 12) no dispositivo MyDatabaseBackups, são restaurados usando WITH NORECOVERY. Depois de restaurar o último backup de log, o banco de dados é recuperado.

Observação Observação

A recuperação é executada como uma etapa separada para reduzir a possibilidade de recuperação antecipada, antes que todos os backups de log tenham sido restaurados.

No RESTORE DATABASE, observe que há dois tipos de opções de FILE. As opções FILE que precedem o nome do dispositivo de backup especificam os nomes de arquivos lógicos dos arquivos de banco de dados restaurados do conjunto de backup; por exemplo, FILE = 'MyDatabase_data_1'. Esse conjunto de backups não é o primeiro backup de banco de dados no conjunto de mídias; portanto, sua posição no conjunto de mídias é indicada com a opção FILE na cláusula WITH, FILE=9.

RESTORE DATABASE MyDatabase
   FILE = 'MyDatabase_data_1',
   FILE = 'MyDatabase_data_2',
   FILEGROUP = 'new_customers'
   FROM MyDatabaseBackups
   WITH 
      FILE = 9,
      NORECOVERY;
GO
-- Restore the log backups.
RESTORE LOG MyDatabase
   FROM MyDatabaseBackups
   WITH FILE = 10, 
      NORECOVERY;
GO
RESTORE LOG MyDatabase
   FROM MyDatabaseBackups
   WITH FILE = 11, 
      NORECOVERY;
GO
RESTORE LOG MyDatabase
   FROM MyDatabaseBackups
   WITH FILE = 12, 
      NORECOVERY;
GO
--Recover the database:
RESTORE DATABASE MyDatabase WITH RECOVERY;
GO

[Início dos exemplos]

K.Revertendo de um instantâneo do banco de dados

O exemplo a seguir reverte um banco de dados para um instantâneo do banco de dados. O exemplo presume que existe apenas um instantâneo atualmente no banco de dados. Para obter um exemplo de como criar esse instantâneo de banco de dados, consulte Criar um instantâneo do banco de dados (Transact-SQL).

Observação Observação

A reversão para um instantâneo descarta todos os catálogos de texto completo.

USE master;  
RESTORE DATABASE AdventureWorks2012 FROM DATABASE_SNAPSHOT = 'AdventureWorks_dbss1800';
GO

Para obter mais informações, consulte Reverter um banco de dados a um instantâneo do banco de dados.

[Início dos exemplos]

Contribuições da comunidade

ADICIONAR
Mostrar:
© 2014 Microsoft