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:

• Azure SQL DB Managed Instance – Introdução
• Managed Instance – Criando minha primeira instância
• Managed Instance – Como se conectar direto do SSMS utilizando uma VPN?
• Managed Instance – Como se conectar através do SSMS de uma VM do Azure?
• Managed Instance (#5) – Quanto custa tudo isso?
• Managed Instance (#6) – Consigo fazer um Join entre tabelas de bases diferentes?
• Managed Instance (#7) – A função getdate() já retorna a data da minha localidade?
• Managed Instance (#8) – Suporte Microsoft em Português
• Managed Instance (#9) – Agora consigo mandar E-mail do SQL Server?
• Managed Instance (#10) – Consigo criar Linked Server?
• Managed Instance (#11) – Agora consigo criar Jobs direto no SSMS?
• Managed Instance (#12) – Configuração da Collation da instância

 

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:

• https://www.tiagoneves.net/blog/fazendo-um-backup-database-no-azure/

Criei minha credencial:

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

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:

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:

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:

• https://docs.microsoft.com/en-us/azure/storage/common/storage-dotnet-shared-access-signature-part-1
• https://docs.microsoft.com/en-us/azure/storage/blobs/storage-dotnet-shared-access-signature-part-2

Agora vamos criar a credencial com essa chave gerada:

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:

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:

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.

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