Em agosto de 2015, escrevi um artigo apresentando o novo recurso Stretch Database no SQL Server 2016. Nesse artigo, discuti como começar a usar o Stretch Database no SQL Server 2016 Community Technology Preview 2 (CTP2). O SQL Server 2016 foi lançado em 1º de junho de 2016 e houve várias atualizações no produto. O método de configuração do Stretch Database mudou um pouco, assim como alguns dos recursos.
A partir do SQL Server 2016, ganhamos a capacidade de armazenar partes de um banco de dados em um Banco de Dados SQL do Azure. Nas visualizações anteriores, quando você habilitava o Stretch para um banco de dados, era necessário migrar a tabela inteira, com a versão RTM do SQL Server 2016, agora você pode escolher uma parte de uma tabela. Depois de habilitar o alongamento para uma tabela, ele migrará seus dados silenciosamente. Se você não estiver familiarizado com o Stretch Database, ele aproveita o poder de processamento no Azure para executar consultas nos dados remotos reescrevendo a consulta. Você não precisa reescrever nenhuma consulta do seu lado. Você verá isso como um operador de “consulta remota” no plano de consulta.
Uma maneira fácil de identificar bancos de dados e tabelas qualificados para serem habilitados para Stretch é baixar e executar o SQL Server 2016 Upgrade Advisor e executar o Stretch Database Advisor. Aaron Bertrand (@AaronBertrand) escreveu sobre isso há algum tempo. O Upgrade Advisor mudou um pouco desde a postagem de Aaron, mas o processo é basicamente o mesmo:
- Identificar tabelas candidatas para bancos de dados Stretch do SQL Server 2016
Limitações do Stretch Database
Nem todas as mesas serão elegíveis para serem habilitadas para Stretch. Certas propriedades de tabela, tipos de dados e colunas, restrições e índices não são suportados, como:
- Tabelas otimizadas para memória e replicadas
- Tabelas que contêm dados FILESTREAM usam o Controle de alterações ou o Change Data Capture
- Tipos de dados como timestamp, sql_variant, XML ou geografia
- Restrições de verificação ou padrão
- Restrições de chave estrangeira que fazem referência à tabela
- Índices XML, de texto completo, espaciais ou de armazenamento de colunas em cluster
- Visualizações indexadas que fazem referência à tabela
- Você não pode executar instruções UPDATE ou DELETE ou executar operações CREATE INDEX ou ALTER INDEX em uma tabela habilitada para Stretch
Para obter uma lista completa de limitações, você pode visitar:Requisitos e limitações do Stretch Database.
Configurando o banco de dados do Stretch
Começar com a versão RTM é um pouco diferente das visualizações anteriores. Você precisará de uma conta do Azure e, em seguida, deverá habilitar o Stretch Database na instância local.
Para habilitar o Stretch Database em uma instância, execute:
EXEC sys.sp_configure N'remote data archive', '1'; RECONFIGURE; GO
Para esta demonstração, usarei um banco de dados de exemplo que criei chamado STRETCH. Comecei clicando com o botão direito do mouse no banco de dados, escolhendo Tarefas, Alongar e, em seguida, Ativar. Isso estava usando o SQL Server 2016 Management Studio.
A próxima tela oferece quais tabelas você gostaria de habilitar para o Stretch:
Eu escolhi a tabela SALES2. O padrão do assistente é "Tabela inteira", mas você também pode alterar essa opção para migrar um subconjunto de linhas.
Se você escolher por linhas, deverá selecionar um nome para seus critérios e, em seguida, poderá escolher qual coluna usar em sua instrução where, bem como a condição e o valor. Nesta captura de tela, escolhi linhas anteriores a 2016. Ser capaz de escolher uma parte de uma tabela é uma grande melhoria em relação às visualizações anteriores, que só permitiam esticar a tabela inteira. Para simplificar, nesta demonstração, vou migrar a tabela inteira, então cliquei em Cancelar e depois em Avançar.
Depois de selecionar suas tabelas e condições, você deve escolher qual assinatura do Azure você usará, sua região do Azure e suas informações de servidor.
Depois de inserir as informações necessárias, clique em Avançar.
Um novo aprimoramento está usando a chave mestra do banco de dados para proteger as credenciais do Azure para se conectar ao Azure. Se você ainda não tiver uma chave mestra, será solicitado a criar uma, se já tiver uma, será necessário fornecer a senha. Clique em Avançar.
Você precisará criar uma regra de firewall para seu servidor ou poderá inserir um intervalo de IP de sub-rede. Faça sua seleção e clique em Avançar.
É aqui que as coisas realmente mudaram e me farão reconsiderar o uso desse recurso. A Microsoft criou uma Database Stretch Unit (DSU) para que você possa aumentar ou diminuir o nível de desempenho necessário para dados Stretch. A partir de junho de 2016, o preço atual é cobrado para computação e armazenamento, que você vê representado na imagem acima. Para minha tabela de 15 MB que foi migrada, seria cobrado US$ 61 por mês pelo armazenamento, bem como o nível mínimo de DSU (100) em US$ 912,50 por mês. Os níveis de DSU variam de:
| Nível de DSU | Custo por hora | Custo mensal máximo (meses com 31 dias) |
|---|---|---|
| 100 | US$ 1,25 | $930 |
| 200 | US$ 2,50 | US$ 1.860 |
| 300 | US$ 3,75 | US$ 2.790 |
| 400 | US$ 5,00 | US$ 3.720 |
| 500 | US$ 6,25 | US$ 4.650 |
| 600 | US$ 7,50 | US$ 5.580 |
| 1000 | US$ 12,50 | US$ 9.300 |
| 1200 | US$ 15,00 | US$ 11.160 |
| 1500 | US$ 18,75 | US$ 13.950 |
| 2000 | US$ 25,00 | US$ 18.600 |
Por que o assistente me disse apenas $ 912,50, quando a tabela de preços indica que deveria ser $ 900 para junho (ou proporcional com base em quantos dias restam em junho)? Seu palpite é tão bom quanto o meu; Eu tentei várias coisas de matemática e veio em branco. Você pode saber mais sobre os modelos de preços aqui:
- Preços do banco de dados Stretch do SQL Server
Antes de aprender sobre esse novo método de cobrança para DSU, eu poderia argumentar que usar o Stretch Database seria um método muito econômico para armazenar dados frios (dados não usados) na nuvem. Ao estender esses dados para o Azure, você pode migrar uma grande parte dos dados mais antigos, o que diminuiria o tamanho (e, portanto, o custo) de seus backups locais. No caso de você precisar restaurar um banco de dados, bastaria estabelecer a conexão com o Azure para os dados estendidos, eliminando assim a necessidade de restaurá-lo. No entanto, com o custo mínimo de quase US$ 1.000 por mês para a escala DSU de baixo custo, muitas organizações descobrirão que é muito mais barato reter os dados em uma camada de armazenamento mais barata em seu data center e encontrar outros métodos para HA, como espelhamento, envio de logs ou grupos de disponibilidade.
Clique em Concluir para iniciar a migração.
Parabéns, agora migrei a tabela SALES2 para um Banco de Dados SQL do Azure
Desabilitar uma tabela Stretch
Nas primeiras visualizações do Stretch Database, se você quisesse desabilitar uma tabela Stretch, teria que criar uma nova tabela e inserir os dados de extensão nela. Depois que todos os dados forem copiados, você terá que alternar manualmente as tabelas renomeando-as ou mesclando manualmente os dados estendidos de volta à tabela de produção. Com a versão RTM, você ainda pode manipular manualmente a migração, optar por deixar os dados no Azure ou escolher uma opção para trazer os dados de volta do Azure.
Independentemente de qual método você usa para trazer os dados de volta, você incorre em cobranças de transferência de dados.
Backup e restauração de um banco de dados Stretch
Depois de migrar dados para um banco de dados do Stretch, o Azure lida com o backup dos dados do Stretch. Os backups ocorrem com um instantâneo tirado a cada 8 horas e os instantâneos são mantidos por 7 dias. Isso lhe dá até 21 pontos no tempo nos 7 dias anteriores para restaurar.
Você não precisa fazer nenhuma alteração em suas rotinas de backup locais atuais. Quaisquer backups locais feitos conterão todos os dados locais e dados elegíveis que ainda não foram migrados. Isso é chamado de backup superficial e não contém dados já migrados para o Azure.
DBCC CHECKDB
Você também não pode executar CHECKDB em dados que foram migrados para o Azure.
Quando executei o DBCC CHECKDB no meu banco de dados STRETCH antes da migração, obtive os seguintes resultados para a tabela SALES2:
Resultados DBCC para 'SALES2'.
Existem 45860 linhas em 1901 páginas para o objeto "SALES2".
Após a migração, recebi a seguinte saída para a tabela SALES2 (ênfase minha):
Resultados DBCC para 'SALES2'.
Há 0 linhas em 1901 páginas para o objeto "SALES2".
Você pode executar o DBCC CHECKDB no Banco de Dados SQL do Azure, no entanto, devido a não poder se conectar diretamente ao Banco de Dados SQL do Azure estendido, atualmente não é possível executar manualmente o DBCC CHECKDB especificamente nos dados estendidos. Não consigo encontrar nenhuma documentação informando que o Azure está realizando verificações de consistência nesses bancos de dados.
Isso traz um risco significativo na minha opinião.
Resumo
O Stretch Database é uma maneira fácil de migrar dados de arquivo para o Microsoft Azure, se o seu banco de dados oferecer suporte. Atualmente, no SQL Server 2016 RTM, há muitas limitações com propriedades de tabela, dados e colunas, tipos de dados e colunas, restrições e índices. Se você não estiver restrito por essas limitações, o Stretch Database é uma maneira simples de migrar dados históricos para o Banco de Dados SQL do Azure para liberar armazenamento local e diminuir os tempos de restauração desses bancos de dados se a despesa valer a pena. Você também precisa se sentir confortável, pelo menos por enquanto, em não poder executar o DBCC CHECKDB em relação a nenhum dado migrado. Gerenciar restaurações também será um pouco mais complicado com a necessidade de restaurar a conexão entre o banco de dados do SQL Server e o banco de dados remoto do Azure.
