Fala, pessoal!

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 backup para o Azure via URL está descrito em detalhes no artigo do Tiago Neves, disponível no link a seguir:

• Fazendo um backup database On-Premises no Azure

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 é 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 artigo 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:

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 (olhe 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:

• Using shared access signatures (SAS)
• Usando SAS (Assinaturas de Acesso Compartilhado)

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:

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:

• “Fabrício, eu consigo usar a estratégia de backup FULL+DIFF para migrar para o MI com um tempo menor de parada do meu ambiente?”

Não. Isso ainda não é possível.

Se tentar restaurar um backup com NORECOVERY, encontrará 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 artigos 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'

Repare 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 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]

Bacana!

Neste artigo começamos a entrar em mais detalhes sobre como o MI funciona internamente.

Gostou dessa dica? Curta, comente e compartilhe!

Assine meu canal no YouTube , curta minha página no Facebook ou siga minha página no Instagram para receber dicas de leituras, vídeos e eventos sobre SQL Server.

Até o próximo artigo!

Abraços.