Loading…

Managed Instance (#13) – Como migrar uma base para o MI via Backup e Restore?

Fala Pessoal,

Esse é mais um post da série sobre o Azure SQL Database Managed Instance. Caso ainda não tenha visto, seguem os posts anteriores:

 

No Azure SQL Database não tínhamos a opção de migrar os dados para o Azure via backup e restore da nossa base On Premise.

Agora no Managed Instanced isso já é possível!!!

Para testar vou fazer um backup de uma base em um SQL Server no meu notebook.

O processo de fazer um backup para o Azure via URL está descrito em detalhes nesse post abaixo do Tiago Neves:

Criei minha credencial:

CREATE CREDENTIAL [Backup_Azure] 
WITH IDENTITY = 'bkpsqlserver'
, SECRET = 'jshdfkasjhfkasjdfhaskljdhflUD/8FbXgHiqR1/zfC4NIShny63RfFKhhhaK3q2HdY38c2Q9LDBUZ8TQ==' 

Em seguida fiz o Backup da base com o comando abaixo:

backup database TesteMigracaoMI
to url = 'https://bkpsqlserver.blob.core.windows.net/bkpsqlmibc/TesteMigracao_MI.bak'
with compression,credential = 'Backup_Azure'

Validei o backup e está tudo certo:

O processo de restore no MI que é um pouco diferente.

Primeiro. Mesmo com uma vpn, se você fizer um backup da base em um disco local e tentar restaurar direto no MI, não vai funcionar:

restore database TesteMigracaoMI
from disk = 'C:\Temp\TesteMigracaoMI.bak'

Erro retornado:

Msg 41902, Level 16, State 1, Line 1
Unsupported device type. SQL Database Managed Instance supports database restore from URI backup device only.

O restore só funciona via URL.

Se eu fizer o mesmo processo de restore descrito no post do Tiago, não vai funcionar.

A credencial até cria normalmente:

CREATE CREDENTIAL [Backup_Azure] 
WITH IDENTITY = 'bkpsqlserver'
, SECRET = 'jshdfkasjhfkasjdfhaskljdhflUD/8FbXgHiqR1/zfC4NIShny63RfFKhhhaK3q2HdY38c2Q9LDBUZ8TQ=='

Mas quando tentamos restaurar temos o erro abaixo:

Se tentar restaurar sem a opção WITH CREDENTIAL gera o erro abaixo:

Eita… E agora Fabrício?

Temos que usar uma chave Shared Access Signature (SAS) para ler o backup da Storage account:

1 – Procure a Storage Account onde está armazenando seu Backup

2 – Clique em Shared Acess Signature

3 – Você pode definir quais acessos dar para essa chave que vai compartilhar.

4 – Defina uma data limite para essa data ficar válida. Fiz um teste aqui e ao tentar restaurar após passar a data, é retornado um erro.

5 – Pode limitar qual IP vai poder ser usado para fazer o restore (olha o nível de segurança).

6 – Gere a SAS.

Ao gerar a SAS, vai ser gerado as informações abaixo:

Vamos precisar da SAS Token, mas quando for usar temos que tirar o “?” que aparece na primeira letra.

Mais informações sobre SAS:

Agora vamos criar a credencial com essa chave gerada:

CREATE CREDENTIAL [Backup_Azure_SAS]
WITH IDENTITY = 'Shared access signature'
, SECRET = 'sv=2017-11-09&ss=bfqt&srt=sco&sp=rwdlacup&se=2018-11-30T18:22:21Z&st=2018-11-30T10:22:21Z&spr=https&sig=W3GB9ZR5Uc5U1EyrRkWDGlCCfOxn0oJLbdIOHym98sE%3D'

Se tentar restaurar vai gerar o erro abaixo:

Para funcionar temos que criar a credencial com nome do nosso caminho do blob storage + container que conseguimos pegar na tela abaixo:

Criada a credencial correta:

CREATE CREDENTIAL [https://bkpsqlserver.blob.core.windows.net/bkpsqlmibc]
WITH IDENTITY = 'Shared access signature'
, SECRET = 'sv=2017-11-09&ss=bfqt&srt=sco&sp=rwdlacup&se=2018-11-30T18:22:21Z&st=2018-11-30T10:22:21Z&spr=https&sig=W3GB9ZR5Uc5U1EyrRkWDGlCCfOxn0oJLbdIOHym98sE%3D'

Finalmente conseguimos chegar no Restore:

Agora conseguimos executar o restore com sucesso:

 

Realizando um select em uma tabela da base restaurada:

Fabricio, eu consigo usar a estratégia de backup FULL+DIFF para migrar para o MI com um tempo menor de parada do meu ambiente?

R: Isso ainda não é possível.

Se tentar restaurar um backup com NORECOVERY vai tomar o erro abaixo:

Para fazer uma migração de uma base grande com um tempo mínimo de Downtime temos que usar outra estratégia que mostrarei em posts futuros.

Aproveitando a brincadeira de restore…. =)

Ligando um profile consigo ver que o MI transforma meu comando simples de restore no comando abaixo:

RESTORE DATABASE [2d16a9d2-e77f-4317-9f7d-56e18fdd09ba] 
FROM URL = N'https://bkpsqlserver.blob.core.windows.net/bkpsqlmibc/TesteMigracao_MI.bak' 
WITH STATS=10, BUFFERCOUNT=8, MAXTRANSFERSIZE=3145728, NORECOVERY, REPLACE, 
MOVE N'TesteMigracaoMI' TO N'C:\WFRoot\DB.4\Fabric\work\Applications\Worker.CL_App14\work\data\2d16a9d2-e77f-4317-9f7d-56e18fdd09ba.mdf' , 
MOVE N'TesteMigracaoMI_log' TO N'C:\WFRoot\DB.4\Fabric\work\Applications\Worker.CL_App14\work\data\2d16a9d2-e77f-4317-9f7d-56e18fdd09ba.ldf' , 
MOVE N'xtp' TO N'C:\WFRoot\DB.4\Fabric\work\Applications\Worker.CL_App14\work\data\2d16a9d2-e77f-4317-9f7d-56e18fdd09ba.xtp'

Repara no caminho do disco local que o MI está armazenando nossa base: C:\WFRoot\DB.4\Fabric\work\Applications\Worker.CL_App14\work\data

Isso acontece na contratação do Business Critical. Contratando o General Purpose é diferente, mas vamos ver as diferenças entre Business Critical e General Purpose em um post futuro.

Também é interessante ver que o nome da nossa base se transforma em um ID e que ele usa a opção NORECOVERY por debaixo dos panos.

Ainda analisando os comandos que o MI executa após o nosso restore, olha que interessante o que ele faz:

  • Ele não nos deixa restaurar com NORECOVERY, mas ele restaura assim. Em seguida deixa a base online com o RECOVERY.
  • Colocou em MULTI_USER e READ_WIRTE
  • Ligou o QUERY_STORE que é o padrão do MI e Azure SQL Database.
  • Colocou o Recovery da base como FULL, caso ela ela tenha vindo no backup como SIMPLE.
  • Habilitou o CHECKSUM e setou o AUTO_CLOSE OFF caso essas opções viessem com as configurações erradas no Backup.
RESTORE DATABASE [2d16a9d2-e77f-4317-9f7d-56e18fdd09ba] WITH RECOVERY, CHECKSUM, KEEP_CDC, KEEP_CDC, NEW_BROKER

ALTER DATABASE [2d16a9d2-e77f-4317-9f7d-56e18fdd09ba] SET MULTI_USER

ALTER DATABASE [2d16a9d2-e77f-4317-9f7d-56e18fdd09ba] SET READ_WRITE WITH NO_WAIT

ALTER DATABASE [2d16a9d2-e77f-4317-9f7d-56e18fdd09ba] SET QUERY_STORE = ON

ALTER DATABASE [2d16a9d2-e77f-4317-9f7d-56e18fdd09ba] SET RECOVERY FULL

ALTER DATABASE [2d16a9d2-e77f-4317-9f7d-56e18fdd09ba] SET PAGE_VERIFY CHECKSUM WITH NO_WAIT

ALTER DATABASE [2d16a9d2-e77f-4317-9f7d-56e18fdd09ba] SET AUTO_CLOSE OFF

ALTER AUTHORIZATION ON DATABASE::[2d16a9d2-e77f-4317-9f7d-56e18fdd09ba] TO [dba_admin]

Cool!!!

Nesse post começamos a entrar em mais detalhes de como o MI funciona internamente.

A brincadeira está ficando mais legal. =)

Gostou dessa Dica?

Curta, comente, compartilhe…

Assine meu canal no Youtube , curta minha página no Facebook  ou siga nossa página no Instagram para receber Dicas de Leituras, Vídeos e Eventos sobre SQL Server.

Até o próximo post.

Abraços,

Fabrício Lima

Microsoft Data Platform MVP

Consultor e Instrutor SQL Server

Trabalha com SQL Server desde 2006

One thought on “Managed Instance (#13) – Como migrar uma base para o MI via Backup e Restore?

Deixe uma resposta

%d blogueiros gostam disto: