Atualizar um banco de dados usando desanexação e anexação (Transact-SQL)
Aplica-se a: SQL Server
Este tópico descreve como usar operações de desanexação e anexação para atualizar um banco de dados do SQL Server. Depois de ser anexado ao SQL Server, o banco de dados estará disponível imediatamente e, em seguida, será atualizado automaticamente. Isso impede que o banco de dados seja usado com uma versão anterior do mecanismo de banco de dados. No entanto, a atualização de metadados não afeta a configuração de nível de compatibilidade do banco de dados de um banco de dados. Veja mais informações em Nível de compatibilidade do banco de dados após a atualização mais adiante neste tópico.
Neste tópico
Antes de começar:
Para atualizar um banco de dados do SQL Server:
Acompanhamento:
Antes de começar
Limitações e Restrições
Os bancos de dados de sistema não podem ser anexados.
Anexe e desanexe a desabilitação do encadeamento de propriedades de bancos de dados ao definir sua opção encadeamento de propriedades de bancos de dados como 0. Para obter informações sobre como habilitar o encadeamento, veja Opção cross db ownership chaining de configuração de servidor.
Quando anexar um banco de dados replicado que foi copiado em vez de desanexado:
Se você anexar o banco de dados a uma versão atualizada da mesma instância do servidor, será necessário executar sp_vupgrade_replication para atualizar a replicação após a conclusão da operação de anexação. Para obter mais informações, veja sp_vupgrade_replication (Transact-SQL).
Se você anexar o banco de dados a uma instância de servidor diferente (independentemente da versão), deverá executar sp_removedbreplication para remover a replicação após a conclusão da operação de anexação. Para obter mais informações, veja sp_removedbreplication (Transact-SQL).
Recomendações
Não é recomendável anexar ou restaurar bancos de dados de origem desconhecida ou não confiável. Esses bancos de dados podem conter um código mal-intencionado que pode executar um código Transact-SQL inesperado ou provocar erros modificando o esquema ou a estrutura física do banco de dados. Antes de usar um banco de dados de origem desconhecida ou não confiável, execute DBCC CHECKDB no banco de dados, em um servidor que não seja de produção. Além disso, examine o código, como procedimentos armazenados ou outro código definido pelo usuário, no banco de dados.
Para atualizar um banco de dados usando desanexar e anexar
Desanexe o banco de dados. Para obter mais informações, veja Desanexar um banco de dados.
Opcionalmente, mova o arquivo ou arquivos de banco de dados desanexados e o arquivo ou arquivos de log.
Você deverá mover os arquivos de log junto com os arquivos de dados, mesmo se pretender criar novos arquivos de log. Em alguns casos, reanexar um banco de dados exige seus arquivos de log existentes. Portanto, mantenha todos os arquivos de log desanexados até que o banco de dados seja anexado com êxito sem eles.
Observação
Se você tentar anexar o banco de dados sem especificar o arquivo de log, a operação de anexação procurará o arquivo de log em seu local original. Se ainda existir uma cópia original do log nesse local, essa cópia será anexada. Para evitar a utilização do arquivo de log original, especifique o caminho do novo arquivo de log ou remova a cópia original do arquivo de log (depois de copiá-la para o novo local).
Anexe os arquivos copiados à instância do SQL Server. Para obter mais informações, consulte Attach a Database.
Exemplo
O exemplo a seguir atualiza uma cópia de um banco de dados de uma versão anterior do SQL Server. As instruções do Transact-SQL são executadas em uma janela do Editor de Consultas conectada à instância do servidor à qual está anexado.
Desanexe o banco de dados executando as seguintes instruções Transact-SQL:
USE master; GO EXEC sp_detach_db @dbname = N'MyDatabase'; GO
Usando o método de sua escolha, copie os arquivos de dados e log no novo local.
Importante
Para um banco de dados de produção, preferencialmente coloque o banco de dados e o log de transações em discos separados. Isso leva a diferentes requisitos de crescimento de arquivo e E/S e é considerado uma melhor prática mantê-los separados.
Para copiar arquivos pela rede para um disco ou um computador remoto, utilize o nome UNC (Convenção Universal de Nomenclatura) do local remoto. Um nome UNC assume a forma
\\Servername\Sharename\Path\Filename
. Assim como ocorre com a gravação de arquivos no disco rígido local, deverão ser concedidas à conta do usuário utilizada pela instância do SQL Server, as permissões apropriadas exigidas para ler ou gravar em um arquivo no disco remoto.Anexe o banco de dados movido e, opcionalmente, seu log executando a seguinte instrução Transact-SQL:
USE master; GO CREATE DATABASE MyDatabase ON (FILENAME = 'C:\MySQLServer\MyDatabase.mdf'), (FILENAME = 'C:\MySQLServer\Database.ldf') FOR ATTACH; GO
No SQL Server Management Studio, um banco de dados anexado recentemente não fica imediatamente visível no Pesquisador de Objetos. Para exibir o banco de dados, no Pesquisador de Objetos, clique em Exibir e depois em Atualizar. Quando o nó Bancos de Dados for expandido no Pesquisador de Objetos, o banco de dados recentemente anexado será exibido na lista de bancos de dados.
Acompanhamento: depois de atualizar um banco de dados do SQL Server
Se o banco de dados 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 como importar (upgrade_option = 2) ou recriar (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.
Nível de compatibilidade do banco de dados após a atualização
Após a atualização, o nível de compatibilidade do banco de dados permanece no nível de compatibilidade antes da atualização, a menos que ele não seja compatível com a nova versão. Nesse caso, o nível de compatibilidade do banco de dados atualizado é definido para o nível de compatibilidade mais baixo com suporte.
Por exemplo, se você anexar um banco de dados com nível de compatibilidade 90 antes de anexá-lo a uma instância de SQL Server 2019 (15.x), após a atualização, o nível de compatibilidade será definido como 100, que é o nível de compatibilidade mais baixo com suporte no SQL Server 2019 (15.x). Para obter mais informações, veja Nível de compatibilidade de ALTER DATABASE (Transact-SQL).
Gerenciando metadados na instância do servidor atualizado
Quando você anexa um banco de dados à outra instância do servidor, para oferecer uma utilização consistente aos usuários e aplicativos, pode ser necessário recriar alguns, ou todos os metadados, para o banco de dados, como logons, trabalhos e permissões, na outra instância do servidor. Para obter mais informações, confira Gerenciar metadados ao disponibilizar um banco de dados em outra instância do servidor (SQL Server).
A Chave mestra de serviço e a Criptografia de Chave Mestra de Banco de dados é alterada de 3DES para AES
SQL Server 2012 (11.x) e versões superiores usam o algoritmo de criptografia AES para proteger a chave mestra de serviço (SMK) e a chave mestra de banco de dados (DMK). O AES é um algoritmo de criptografia mais novo que o 3DES usado em versões anteriores. 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 como regenerar a DMK, veja 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.