APRENDER. PRATICAR. EVOLUIR.1. Escolher a fronteira de gestão necessária
A migração começa pelo inventário de dependências da aplicação, não pela preferência por um nome de serviço. Azure SQL Database, SQL Managed Instance e SQL Server numa VM partilham tecnologia, mas oferecem fronteiras de gestão diferentes. Uma necessidade confirmada de instalar software no sistema operativo do servidor SQL aponta para uma opção com esse controlo e respetiva responsabilidade operacional. Uma aplicação com funcionalidades de instância pode justificar avaliar Managed Instance, sem assumir compatibilidade absoluta antes de testar. Regista jobs, autenticação, ligações entre bases, drivers e integrações. No projeto fictício, o fornecedor apresenta como requisito um agente no host, mas não demonstra a sua finalidade. O arquiteto pede evidência e alternativas suportadas antes de aceitar o custo permanente de operar VMs.
2. Dimensionar elastic pools com procura simultânea
Elastic pools permitem que bases partilhem recursos dentro de um orçamento definido. O benefício depende de como os picos se sobrepõem. Somar a média diária de cada base pode esconder o fecho em que todas precisam de capacidade ao mesmo tempo; somar todos os máximos históricos pode exagerar necessidades se nunca coincidem. Observa janelas representativas e preserva folga para variação e tarefas operacionais. Define limites por base quando adequados e mede impacto dos consumidores mais exigentes. O modelo local soma três séries fictícias por instante e acrescenta reserva. Não prevê vCores, DTUs, latência ou preço Azure. Serve para mostrar porque o maior valor da soma temporal é uma pergunta diferente da soma dos maiores valores individuais. Depois, a equipa tem de testar o serviço real com métricas apropriadas.
3. Não confundir pooling de bases e de instâncias
Um elastic pool de SQL Database e um instance pool de Managed Instance agrupam unidades diferentes. O primeiro organiza bases; o segundo permite alojar várias instâncias com recursos atribuídos num conjunto de infraestrutura partilhado. Se cada aplicação precisa de configurações ao nível da instância, essa distinção entra na análise de compatibilidade e isolamento. Não assumes que mover bases para um pool lhes dá todas as funcionalidades de uma instância SQL Server. Também não assumes que qualquer partilha equivale a uma VM dedicada por workload. No caso fictício, três aplicações pequenas têm requisitos de instância separados e picos moderados. A comparação deve incluir recursos atribuídos, isolamento necessário, janela de manutenção e capacidade de crescimento, em vez de escolher apenas a opção com o menor número de recursos no portal.
4. Modelar inatividade e retoma em serverless
Serverless ajusta compute dentro dos limites configurados, mas poupança e experiência dependem do padrão de uso. Uma base com longos intervalos inativos pode beneficiar, desde que o primeiro pedido tolere retoma e a aplicação trate erros transitórios. Sessões mantidas abertas por monitorização ou funcionalidades incompatíveis podem impedir pausa; verifica os requisitos atuais em vez de assumir que ausência de pedidos de negócio significa ausência de atividade. A documentação consultada distingue pausa disponível em General Purpose de pausa em preview no Hyperscale. Não transportes uma garantia entre tiers sem confirmar suporte e estado. Durante uma prova de conceito, mede duração de inatividade, eventos de pausa, retoma, utilização mínima e resposta do primeiro pedido. O custo deve incluir armazenamento e compute quando a base permanece ativa, mesmo com pouca carga.
5. Separar relatórios tolerantes a atraso de confirmação de escrita
Read scale-out pode aliviar a réplica gravável ao servir consultas numa réplica de leitura. A decisão exige identificar que fluxos toleram atraso. Um relatório periódico pode aceitar alguns dados ainda não visíveis; a confirmação imediata de uma alteração feita pelo próprio utilizador pode ter outro contrato. ApplicationIntent=ReadOnly é uma intenção de ligação, não uma autorização para escrever numa réplica nem uma garantia de frescura global. No Hyperscale, named replicas permitem objetivos de compute e acesso independentes para workloads de leitura; não devem ser confundidas com uma cópia noutra região para desastre regional. Antes do handover, regista endpoints, connection strings, permissões e testes de frescura por fluxo. Um teste que executa apenas SELECT com sucesso não demonstra que a leitura satisfaz a expectativa temporal do negócio.
6. Tratar restauro como uma nova entrega de dados
Restaurar uma base a partir de backup não deve ser confundido com desfazer apenas a última instrução errada na base em serviço. No percurso de recuperação SQL Database, o restauro cria uma base que precisa de ser validada e integrada no plano de recuperação. A equipa identifica o instante correto, o destino, a configuração necessária e as alterações legítimas posteriores que exigem reconciliação. Uma aplicação pode continuar a apontar para o endpoint antigo enquanto a base restaurada existe sem consumidores. O PM deve acompanhar validação, decisão de cutover, acesso, dependências e custo temporário das duas cópias. No exercício, o responsável pelo negócio confirma posições e totais antes de a equipa declarar sucesso. Um job de restauro concluído é evidência técnica parcial, não o fecho automático do incidente.
def required_capacity(series, reserve):
if reserve < 0 or not series or not series[0]:
raise ValueError("invalid fictional capacity input")
if any(len(row) != len(series[0]) or any(v < 0 for v in row) for row in series):
raise ValueError("unaligned or negative demand")
totals = [sum(values) for values in zip(*series)]
return max(totals) + reserve
loads = [[20, 70, 30], [60, 20, 50], [10, 5, 10]]
assert required_capacity(loads, 10) == 105
assert sum(max(row) for row in loads) + 10 == 150
assert required_capacity([[70], [60], [10]], 10) == 150
assert required_capacity([[0, 0], [0, 0]], 10) == 10
assert required_capacity(loads, 0) == 95
print("five fictional capacity checks passed; no Azure sizing or pricing prediction")
Caso fictício: três bases têm picos em instantes diferentes. O modelo calcula a procura simultânea e reserva, mas o projeto só aceita o pool depois de ensaiar também o fecho em que dois picos coincidem.
Armadilhas comuns
Escolher por nome de produto; ignorar picos simultâneos; confundir instance pool com elastic pool; prometer pausa em qualquer configuração; validar leitura sem medir frescura.
Tópicos relacionados: FinOps e dimensionamento · RPO e validação de dados · Migração e dependências
A escolha SQL deve combinar compatibilidade, procura, resposta inicial, frescura e capacidade de recuperar dados aceites pelo negócio.
Referência: Azure SQL deployment options · AZ-305 objectives 2026-04-17