Novo DBA na nuvem: Gerenciando o Banco de Dados SQL do Azure após migração

Aplica-se a:Banco de Dados SQL do Azure

A migração de um ambiente autogerenciado para um PaaS como o Banco de Dados SQL do Azure pode ser complexa. Este artigo destaca os principais recursos do Banco de Dados SQL do Azure para bancos de dados individuais e em pool, ajudando você a manter os aplicativos disponíveis, com desempenho, seguros e resilientes.

As principais características do Banco de Dados SQL do Azure incluem:

• Monitoramento de banco de dados com o portal do Azure
• BCDR (continuidade de negócios e recuperação de desastres)
• Segurança e conformidade
• Monitoramento e manutenção de banco de dados inteligente
• Movimentação de dados

Monitorar bancos de dados usando o Portal do Azure

Para obter métricas e alertas do Azure Monitor, incluindo regras de alerta recomendadas, consulte Monitorar o Banco de Dados SQL do Azure com métricas e alertas. Para obter mais informações sobre as camadas de serviço, consulte a visão geral do modelo de compra baseado em DTU e o modelo de compra baseado em vCore.

Você pode configurar alertas nas métricas de desempenho. Selecione o botão Adicionar alerta na janela Métrica. Siga o assistente para configurar seu alerta. Você pode alertar se as métricas excederem um determinado limite ou se a métrica estiver abaixo de um determinado limite.

Por exemplo, se você espera que a carga de trabalho em seu banco de dados cresça, você poderá configurar um alerta por email sempre que seu banco de dados atinge 80% em qualquer uma das métricas de desempenho. Você pode usar isso como um alerta antecipado para identificar quando talvez seja necessário migrar para a próxima capacidade computacional superior.

As métricas de desempenho também podem ajudá-lo a determinar se é possível reduzir para um tamanho de computação menor. No entanto, tome cuidado com cargas de trabalho que apresentam picos ou oscilam antes de tomar a decisão de migrar para um tamanho da computação inferior.

BCDR (continuidade de negócios e recuperação de desastres)

As habilidades de continuidade de negócios e recuperação de desastre permitem que você continue seus negócios se ocorrer um desastre. O desastre pode ser um evento de nível de banco de dados (por exemplo, alguém por engano descarta uma tabela crucial) ou um evento de nível no centro de dados (catástrofe regional, por exemplo, um tsunami).

Como criar e gerenciar backups no Banco de Dados SQL?

O Banco de Dados SQL do Azure faz backup automático de bancos de dados para você. A plataforma faz um backup completo toda semana, backup diferencial a cada poucas horas e um backup de log a cada cinco minutos para garantir que a recuperação de desastres seja eficiente e a perda de dados mínima. O primeiro backup completo acontece assim que você criar um banco de dados. Você pode acessar esses backups por um determinado período chamado período de retenção, que varia conforme o nível de serviço que você escolher. Você pode restaurar para qualquer ponto no tempo dentro desse período de retenção usando a Recuperação Pontual (PITR).

Além disso, o recurso de backups de retenção de longo prazo permite que você mantenha seus arquivos de backup por até 10 anos e restaure dados desses backups a qualquer momento desse período. O Azure mantém backups de banco de dados em armazenamento geo-replicado para fornecer resiliência contra catástrofes regionais. Você também pode restaurar esses backups em qualquer região do Azure a qualquer momento durante o período de retenção. Para obter mais informações, consulte Continuidade dos negócios no Banco de Dados SQL do Azure.

Como garantir a continuidade dos negócios em caso de desastre no nível de datacenter ou catástrofe regional?

Armazene seus backups de banco de dados em armazenamento geo-replicado para garantir que, durante um desastre regional, você possa restaurar o backup em outra região do Azure. Esse recurso chama-se geo-restore. Para obter mais informações e tempo das restaurações geográficas, consulte Restauração geográfica do Banco de Dados SQL do Azure.

Para bancos de dados de missão crítica, o Banco de Dados SQL do Azure oferece replicação geográfica ativa, que cria uma cópia secundária replicada geograficamente do banco de dados original em outra região. Por exemplo, se o seu banco de dados estiver inicialmente hospedado na região West US do Azure e você quiser resiliência regional a desastres, crie uma georréplica ativa do banco de dados de West US para East US. Quando uma calamidade atingir o Oeste dos EUA, você pode realizar failover na região Leste dos EUA.

Além da replicação geográfica ativa, os grupos de failover ajudam você a gerenciar a replicação e o failover de um grupo de bancos de dados. Você pode criar um grupo de failover que contenha vários bancos de dados na mesma região ou em regiões diferentes. Em seguida, você pode iniciar um failover de todos os bancos de dados no grupo de failover para a região secundária. Para obter mais informações, consulte Visão geral de grupos de failover e práticas recomendadas (Banco de Dados SQL do Azure).

Para obter resiliência para falhas de datacenter ou zona de disponibilidade, verifique se a redundância de zona está habilitada para o banco de dados ou pool elástico.

Monitore ativamente sua aplicação para detectar um desastre e inicie o failover para o ambiente secundário. Você pode criar até quatro dessas réplicas geográficas ativas em diferentes regiões do Azure. E fica ainda melhor. Você também pode acessar essas replicações geográficas ativas secundárias de acesso somente leitura, o que ajuda a reduzir a latência em um cenário de aplicativo distribuído geograficamente.

Como é a recuperação de desastre com o Banco de Dados SQL?

Você pode configurar sua estratégia de recuperação de desastres em apenas algumas etapas no Banco de Dados SQL do Azure ao usar grupos ativos de geo-replicação ou failover. Você ainda precisa monitorar o aplicativo e seu banco de dados em busca de qualquer desastre regional e fazer failover para a região secundária para restaurar a continuidade dos negócios.

Para obter mais informações, consulte a Recuperação de Desastre do Banco de Dados SQL do Azure 101.

Segurança e conformidade

Banco de Dados SQL do Azure oferece segurança tanto no nível do banco de dados quanto no nível da plataforma. Você pode controlar e oferecer segurança ideal para sua aplicação utilizando os seguintes recursos:

• Identidade e autenticação (autenticação SQL e autenticação com Microsoft Entra ID).
• Atividade de monitoramento (Auditoria e detecção de ameaças).
• Proteção de dados reais (criptografia de dados transparente [TDE] e Always Encrypted).
• Controle do acesso a dados sensíveis e privilegiados (segurança em nível de linha e mascaramento dinâmico de dados).

O Microsoft Defender para Nuvem oferece gerenciamento de segurança centralizado em cargas de trabalho em execução no Azure, no local e em outras nuvens. Você pode ver se a proteção essencial do Banco de Dados SQL, como Auditoria e Criptografia transparente de dados [TDE] , está configurada em todos os recursos e cria políticas com base em seus próprios requisitos.

Quais métodos de autenticação de usuários o SQL Database oferece?

O SQL Database oferece dois métodos de autenticação:

• autenticação do Microsoft Entra
• Autenticação do SQL

A autenticação do Windows não tem suporte. O Microsoft Entra ID é um serviço centralizado de gerenciamento de identidade e acesso. A ID do Microsoft Entra fornece acesso de SSO (logon único) ao pessoal da sua organização. Isso significa que as credenciais são compartilhadas entre os serviços do Azure para facilitar a autenticação.

O Microsoft Entra ID suporta autenticação multifator, podendo ser facilmente integrado ao Microsoft Entra Connect Sync. Essa integração também permite que o Banco de Dados SQL do Azure ofereça autenticação multifatorial e contas de usuário convidado dentro de um domínio Microsoft Entra. Se você já usar um Active Directory local, poderá federá-lo com o Microsoft Entra ID para estender seu diretório do Azure.

A autenticação do SQL dá suporte apenas a nome de usuário e senha para autenticar usuários em qualquer banco de dados em determinado servidor.

Como limitar ou controlar o acesso de conectividade ao meu banco de dados?

Para organizar a conectividade da sua aplicação, utilize as seguintes técnicas:

• Regras de firewall
• Pontos de extremidade de serviço de rede virtual
• IPs Reservados

Firewall

Por padrão, o servidor SQL lógico impede todas as conexões com bancos de dados, exceto (opcionalmente) conexões vindas de outros serviços do Azure. Usando uma regra de firewall, você pode abrir o acesso ao seu servidor apenas para entidades (por exemplo, uma máquina desenvolvedora) que você aprova, permitindo que o endereço IP desse computador passe pelo firewall. Você também pode especificar uma faixa de IPs que deseja permitir o acesso ao servidor. Por exemplo, você pode adicionar endereços IP de máquinas desenvolvedoras na sua organização de uma vez especificando um intervalo na página de configurações do Firewall.

Você pode criar regras de firewall no nível de servidor ou no nível de banco de dados. Você pode criar regras de firewall IP em nível de servidor usando o portal do Azure ou usando SSMS. Para obter mais informações sobre como definir uma regra de firewall no nível do servidor e no nível do banco de dados, consulte Criar regras de firewall de IP no Banco de Dados SQL.

Pontos de extremidade de serviço

Por padrão, seu banco de dados está configurado para permitir que os serviços e recursos do Azure acessem esse servidor, o que significa que qualquer máquina virtual no Azure pode tentar se conectar ao seu banco de dados. Essas tentativas ainda precisam ser autenticadas. Se você não quiser que seu banco de dados seja acessível por nenhum IP do Azure, você pode desabilitar Permitir que os serviços e recursos do Azure acessem esse servidor. Além disso, você pode configurar endpoints de serviço de rede virtual.

Os pontos de extremidade de serviço permitem que você exponha seus recursos críticos do Azure apenas para sua própria rede virtual privada no Azure. Essa opção elimina o acesso público aos seus recursos. O tráfego entre sua rede virtual para o Azure permanece na rede de backbone do Azure. Sem pontos de extremidade de serviço, você tem roteiros de pacotes de túnel forçado. Sua rede virtual força o tráfego de Internet para sua organização e o tráfego do serviço do Azure a passarem pela mesma rota. Ao usar endpoints de serviço, os pacotes fluem diretamente da sua rede virtual para o serviço na rede backbone do Azure.

IPs Reservados

Outra opção é provisionar IPs reservados para suas VMs e adicionar os endereços IP dessas VMs nas configurações de firewall do servidor. Ao atribuir IPs reservados, você não precisa atualizar as regras do firewall ao mudar endereços de IP.

Em qual porta me conecto ao Banco de Dados SQL?

O Banco de Dados SQL do Azure se comunica pela porta 1433. Para se conectar dentro de uma rede corporativa, você deve adicionar uma regra de saída nas configurações do firewall da sua organização. Como uma orientação, evite a exposição da porta 1433 fora do limite do Azure.

Como posso monitorar e regular a atividade em meu servidor e banco de dados no Banco de Dados SQL?

Auditoria do Banco de Dados SQL

A Auditoria do Banco de Dados SQL do Azure registra eventos de banco de dados e os grava em um arquivo de log de auditoria em sua Conta de Armazenamento do Azure. A auditoria é especialmente útil se você deseja obter insights sobre possíveis violações de segurança e políticas, manter a conformidade regulatória e muito mais. Ele fornece relatórios pré-configurados e um painel para fornecer uma visão geral dos eventos que ocorrem no seu banco de datos. Você pode definir e configurar as categorias de eventos que precisam ser auditadas.

Você pode aplicar essas políticas de auditoria no nível do banco de dados ou no nível do servidor. Para mais informações, veja Habilitar a Auditoria de Banco de Dados SQL.

Detecção de ameaças

Ao usar a detecção de ameaças, você pode agir sobre violações de segurança ou políticas descobertas por meio de auditorias. Não é preciso ser um especialista em segurança para tratar potenciais ameaças ou violações no seu sistema. A detecção de ameaças também possui algumas funcionalidades integradas, como a detecção de injeção SQL, que é uma forma comum de atacar um aplicativo de banco de dados. A detecção de ameaças executa vários conjuntos de algoritmos que detectam possíveis vulnerabilidades, ataques de injeção de SQL e padrões anômalos de acesso ao banco de dados (como o acesso a partir de um local incomum ou por um usuário desconhecido).

Os agentes de segurança ou outros administradores designados recebem uma notificação por email se uma ameaça é detectada no banco de dados. Cada notificação fornece detalhes da atividade suspeita e recomendações sobre como investigar e minimizar a ameaça. Para saber como ativar a detecção de ameaças, consulte Habilitar detecção de ameaças.

Como proteger meus dados em geral no Banco de Dados SQL?

A criptografia fornece um forte mecanismo de proteção e segurança de dados confidenciais contra intrusos. Seus dados criptografados não servem para nada para o invasor sem a chave de descriptografia. Portanto, ele adiciona uma camada extra de proteção sobre as camadas de segurança existentes criadas no Banco de Dados SQL. Há dois aspectos para proteger seus dados no Banco de Dados SQL:

• Os dados em repouso nos arquivos de dados e log
• Os dados em versão piloto

No Banco de Dados SQL, por padrão, seus dados em repouso nos arquivos de dados e de log no subsistema de armazenamento são completamente criptografados por meio da criptografia de dados transparente [TDE]. Seus backups também são criptografados. Com o TDE, não há nenhuma alteração necessária no lado do aplicativo que esteja acessando esses dados. A criptografia e descriptografia ocorrem de modo transparente; por isso o nome.

Para proteger seus dados confidenciais em trânsito e em repouso, o Banco de Dados SQL fornece um recurso chamado Always Encrypted. O Always Encrypted é uma forma de criptografia do lado do cliente que criptografa colunas confidenciais em seu banco de dados (portanto, elas estão em texto criptografado para administradores de banco de dados e usuários não autorizados). O servidor recebe os dados criptografados em primeiro lugar.

A chave para o Always Encrypted também é armazenada no lado do cliente, para que somente clientes autorizados possam descriptografar as colunas confidenciais. O servidor e os administradores de dados não podem ver os dados confidenciais, já que as chaves de criptografia ficam armazenadas no cliente. O Always Encrypted criptografa colunas confidenciais na tabela de ponta a ponta, de clientes não autorizados ao disco físico.

O Always Encrypted dá suporte a comparações de igualdade, portanto, os DBAs podem continuar consultando colunas criptografadas como parte de seus comandos SQL. O Always Encrypted pode ser usado com uma variedade de opções de armazenamento de chaves, como o Azure Key Vault, o repositório de certificados do Windows e os módulos de segurança de hardware locais.

Como posso limitar o acesso a dados confidenciais no meu banco de dados?

Cada aplicação tem dados sensíveis no banco de dados que você precisa proteger para que não sejam visíveis para todos. Certos funcionários da organização precisam visualizar esses dados, mas outros não. Nesses casos, você precisa ou mascarar seus dados sensíveis ou não expô-los de forma alguma. O SQL Database oferece duas abordagens para evitar que usuários não autorizados visualizem dados sensíveis:

• A máscara dinâmica de dados é uma funcionalidade de mascaramento de dados que você pode usar para limitar a exposição de dados sensíveis, mascarando-a para usuários não privilegiados. Você define uma regra de mascaramento que cria um padrão de mascaramento. Por exemplo, você só pode mostrar os últimos quatro dígitos de um número XXX-XX-0000 de identificação nacional e mascarar o restante com o X caractere. Com o mascaramento dinâmico de dados, você identifica quais usuários estão excluídos da regra de mascaramento e pode ver dados não mascarados. O mascaramento ocorre em tempo real e várias funções de mascaramento estão disponíveis para diferentes categorias de dados.

• Segurança no nível de linha permite que você controle o acesso no nível de linha. Esse recurso oculta certas linhas em uma tabela de banco de dados com base no usuário que executa a consulta (pertença ao grupo ou contexto de execução). A restrição de acesso é feita na camada de banco de dados, em vez de em uma camada de aplicação, o que simplifica a lógica do seu app. Você começa criando um predicado que filtra as linhas que não estão expostas. Depois, você cria a política de segurança que define quem tem acesso a essas linhas. Por fim, o usuário final executa sua consulta e, dependendo do privilégio do usuário, ele ou visualiza essas linhas restritas ou não consegue vê-las de forma alguma.

Como gerenciar chaves de criptografia na nuvem?

Tanto a criptografia Always Encrypted (criptografia do lado do cliente) quanto a criptografia de dados transparentes (criptografia em repouso) oferecem opções de chave gerenciada pelo cliente . Gire as chaves de criptografia regularmente. Escolha uma frequência de rotação que esteja alinhada com as regulamentações internas e os requisitos de conformidade da sua organização.

Criptografia de Dados Transparente (TDE)

O TDE utiliza uma hierarquia de duas chaves. Os dados de cada banco de dados de usuário são criptografados por uma chave de criptografia de banco de dados (DEK) AES-256 exclusiva de cada banco de dados, que é criptografada por uma chave mestra assimétrica RSA-2048 exclusiva do servidor. A chave mestra pode ser gerenciada de uma destas formas:

• Automaticamente pelo Banco de Dados SQL do Azure
• Ou usando o Azure Key Vault como repositório de chaves

Por padrão, o Banco de Dados SQL do Azure gerencia a chave mestra TDE. Se sua organização quiser controle sobre a chave mestra, use o Azure Key Vault como o armazenamento de chaves. Usando o Azure Key Vault, sua organização assume o controle sobre o provisionamento, a rotação e a permissão das chaves. Girar ou alternar o tipo de uma chave mestra de TDE é rápido, pois isso só criptografa novamente a DEK. Para organizações com separação de funções entre segurança e gerenciamento de dados, um administrador de segurança pode provisionar o material da chave mestra TDE no Azure Key Vault e fornecer um identificador de chave do Azure Key Vault ao administrador do banco de dados para uso para criptografia em repouso em um servidor. O Cofre de Chaves foi projetado para que a Microsoft não veja nem extraia nenhuma chave de criptografia. Você também pode obter um gerenciamento centralizado de chaves para sua organização.

Sempre Criptografado

O Always Encrypted também utiliza uma hierarquia de duas chaves. Uma coluna de dados sensíveis é criptografada por uma chave de criptografia AES de 256 colunas (CEK), que é criptografada por uma chave mestra de coluna (CMK). Os drivers de cliente fornecidos para Always Encrypted não têm nenhuma limitação de tamanho das CMKs. O valor criptografado da CEK é armazenado no banco de dados, e a CMK é armazenada em um repositório de chaves confiável, como o repositório de certificados do Windows, o Azure Key Vault ou um módulo de segurança de hardware.

• Faça o rodízio de CEK e CMK.

• A rotação da CEK é um tamanho de operação de dados e pode ser demorada, dependendo do tamanho das tabelas contendo colunas criptografadas. Planeje as rotações do CEK de acordo com isso.

• A rotação de CMK não interfere no desempenho do banco de dados e pode ser feita com funções separadas.

O diagrama a seguir mostra as opções do repositório de chaves para as chaves mestras de coluna no Always Encrypted:

Como posso otimizar e proteger o tráfego entre minha organização e o Banco de Dados SQL?

O tráfego de rede entre sua organização e o SQL Database geralmente passa pela rede pública. No entanto, você pode otimizar esse caminho e torná-lo mais seguro usando o Azure ExpressRoute. O ExpressRoute estende sua rede corporativa para a plataforma Azure por meio de uma conexão privada, contornando a Internet pública. Você também obtém maior segurança, confiabilidade e otimização de roteamento que se traduz em latências de rede mais baixas e velocidades mais rápidas do que você normalmente experimentaria passando pela Internet pública. Se você planeja transferir uma parte significativa dos dados entre sua organização e o Azure, usar o ExpressRoute pode trazer benefícios de custo. Você pode escolher entre três modelos diferentes de conectividade para a conexão de sua organização com o Azure:

• Colocação do Cloud Exchange
• De qualquer ponto a qualquer ponto
• Ponto a Ponto

O ExpressRoute também permite que você expanda até 2 vezes o limite de largura de banda que você adquiriu, sem custo adicional. Você também pode configurar conectividade entre regiões usando o ExpressRoute. Para obter uma lista de provedores de conectividade do ExpressRoute, consulte Parceiros do ExpressRoute e Locais de Emparelhamento. Os artigos a seguir descrevem o ExpressRoute com mais detalhes:

• Pré-requisitos
• Fluxos de trabalho

O Banco de Dados SQL está em conformidade com quaisquer requisitos regulatórios e como isso ajuda na conformidade da minha própria organização?

Banco de Dados SQL do Azure está em conformidade com uma variedade de exigências regulatórias. Para ver o conjunto mais recente de conformidades que o SQL Database atende, visite o Microsoft Trust Center e revise as conformidades importantes para sua organização para verificar se o SQL Database está incluído nos serviços compatíveis do Azure. Embora o Banco de Dados SQL seja certificado como um serviço em conformidade, ele ajuda na conformidade do serviço da sua organização, mas não o garante automaticamente.

Monitoramento e manutenção de banco de dados inteligente após a migração

Depois de migrar seu banco de dados para o SQL Database, monitore seu banco de dados (por exemplo, verifique como está a utilização de recursos ou verificações DBCC) e realize manutenção regular (por exemplo, reconstruir ou reorganizar índices, estatísticas e mais). O Banco de Dados SQL usa as tendências históricas e as métricas e estatísticas registradas para ajudá-lo proativamente a monitorar e manter seu banco de dados, para que seu aplicativo seja executado de maneira ideal sempre. Em alguns casos, o Banco de Dados SQL do Azure pode executar automaticamente tarefas de manutenção, dependendo de sua configuração. Há três facetas para monitoramento de banco de dados no Banco de Dados SQL:

• Monitoramento e otimização de desempenho
• Otimização de segurança
• Otimização de custo

Monitoramento e otimização de desempenho

Ao usar o Query Performance Insights, você pode obter recomendações personalizadas para a carga de trabalho do seu banco de dados, para que suas aplicações continuem rodando em um nível ideal. Também é possível defini-lo para que essas recomendações sejam aplicadas automaticamente e você não precise se preocupar em executar tarefas de manutenção. Ao usar o SQL Database Advisor, você pode implementar automaticamente recomendações de índice com base na sua carga de trabalho. Esse recurso é chamado de Auto-Tuning. As recomendações evoluem conforme a carga de trabalho do aplicativo muda para fornecer sugestões mais relevantes. Você também pode obter a opção de revisar manualmente essas recomendações e aplicá-las a seu critério.

Otimização de segurança

O SQL Database oferece recomendações de segurança acionáveis para ajudar você a proteger seus dados. Também oferece detecção de ameaças para identificar e investigar atividades suspeitas no banco de dados que possam representar uma ameaça potencial ao banco de informações. Avaliação de vulnerabilidades é um serviço de varredura e relatórios de bancos de dados que você pode usar para monitorar o estado de segurança dos seus bancos de dados em larga escala e identificar riscos e desvios de uma linha de base de segurança que você definiu. Após cada varredura, ele fornece uma lista personalizada de passos acionáveis e scripts de remediação, junto com um relatório de avaliação que pode ajudar você a cumprir os requisitos de conformidade.

Ao usar o Microsoft Defender para Nuvem, você pode identificar recomendações de segurança em todos os aspectos e aplicá-las rapidamente.

Otimização de custo

A plataforma SQL do Azure analisa o histórico de utilização entre os bancos de dados em um servidor para avaliar e recomendar opções de otimização de custos. Essa análise geralmente leva algumas semanas de atividade para analisar e criar recomendações acionáveis.

Você pode receber notificações em banner sobre recomendações de custo no seu servidor SQL do Azure. Para mais informações, consulte Os pools elásticos ajudam você a gerenciar e escalar vários bancos de dados no Banco de Dados SQL do Azure e Planeje e gerencie os custos do Banco de Dados SQL do Azure.

Como fazer para monitorar o desempenho e a utilização de recursos no Banco de Dados SQL?

Você pode monitorar o desempenho e a utilização de recursos no SQL Database usando os seguintes métodos:

inspetor de banco de dados

O observador de banco de dados coleta dados detalhados de monitoramento de carga de trabalho para fornecer uma exibição detalhada do desempenho, da configuração e da integridade do banco de dados. Os painéis no portal do Azure oferecem uma visão unificada do seu ambiente do SQL do Azure e uma visão detalhada de cada recurso monitorado. Os dados são coletados em um armazenamento de dados central na sua assinatura do Azure. Você pode consultar, analisar, exportar, visualizar os dados coletados e integrá-los a sistemas downstream.

Para obter mais informações sobre o observador de banco de dados, consulte os artigos a seguir:

• Monitore cargas de trabalho do SQL do Azure com o Database Watcher (preview)
• Início Rápido: Criar um observador para monitorar o SQL do Azure (versão prévia)
• Criar e configurar um observador (versão prévia)
• Coleta de dados e conjuntos de dados do Monitor de Banco de Dados (versão prévia)
• Analisar dados de monitoramento do monitor de banco de dados (versão prévia)
• Perguntas frequentes sobre o observador de banco de dados

portal do Azure

O portal do Azure mostra a utilização de um banco de dados quando você seleciona o banco de dados e seleciona o gráfico no painel de Visão Geral. Você pode modificar o gráfico para mostrar várias métricas, incluindo a porcentagem de CPU, a porcentagem de DTU, a porcentagem de E/S de dados, a porcentagem de sessões e a porcentagem do tamanho do banco de dados.

Nesse gráfico, você também pode configurar alertas por recurso. Esses alertas permitem que você responda às condições dos recursos com um e-mail, escreva em um endpoint HTTPS/HTTP ou execute uma ação. Para mais informações, veja Criar alertas para Banco de Dados SQL do Azure usando o portal Azure.

Exibições de gerenciamento dinâmico

É possível consultar o modo de exibição de gerenciamento dinâmico sys.DM db_resource_stats para retornar o histórico de estatísticas de consumo de recursos na última hora e o modo de exibição de catálogo do sistema sys.resource_stats para retornar o histórico dos últimos 14 dias.

Análise de desempenho de consultas

A Análise de Desempenho de Consultas permite visualizar um histórico das principais consultas de consumo de recursos e consultas de longa execução para um banco de dados específico. Você pode identificar TOP rapidamente consultas por utilização de recursos, duração e frequência de execução. Você pode acompanhar as consultas e detectar regressões. Este recurso requer que o Repositório de Consultas esteja habilitado e ativo para o banco de dados.

Percebo problemas de desempenho: como minha metodologia de solução de problemas para um banco de dados SQL difere da do SQL Server?

A maioria das técnicas de solução de problemas que você usa para diagnosticar problemas de consulta e desempenho de banco de dados são as mesmas do SQL Server on-premiss. Banco de Dados SQL do Azure usa o mesmo SQL Mecanismo de Banco de Dados. No entanto, recursos do Azure ajudam você a solucionar problemas e diagnosticar problemas de desempenho ainda mais facilmente. Ele também pode realizar algumas dessas ações corretivas em seu nome e, em alguns casos, corrigi-las proativamente automaticamente.

Sua abordagem para solucionar problemas de desempenho pode se beneficiar significativamente do uso de recursos inteligentes como Query Performance Insight (QPI) e Database Advisor. A diferença na metodologia é que você não precisa mais fazer manualmente o trabalho de levantar os detalhes essenciais que podem ajudar a diagnosticar e solucionar o problema em questão. A plataforma faz o trabalho pesado por você. Um exemplo desse trabalho é o QPI. Usando QPI, você pode aprofundar até o nível da consulta e analisar as tendências históricas para descobrir exatamente quando a consulta regrediu. O Consultor de Banco de Dados oferece recomendações sobre coisas que podem ajudar a melhorar seu desempenho geral em geral, como índices ausentes, eliminação de índices, parametrização de suas consultas e mais.

Na solução de problemas de desempenho, é importante identificar se é apenas a aplicação ou o banco de dados afetando o desempenho da sua aplicação. Geralmente, o problema de desempenho está na camada de aplicativo. Ele pode estar na arquitetura ou no padrão de acesso a dados. Por exemplo, considere que você tem um aplicativo que realiza muitas comunicações e é sensível à latência de rede. Nesse caso, o aplicativo sofre porque existem muitas solicitações curtas indo e voltando ("conversantes") entre o aplicativo e o servidor. Em uma rede congestionada, essas viagens de ida e volta se acumulam rapidamente. Para melhorar o desempenho nesse caso, você pode usar consultas em lote, que ajudam a reduzir a latência de ida e volta e melhorar o desempenho do aplicativo.

Além disso, se você notar uma degradação no desempenho geral do seu banco de dados, pode monitorar as visões de gerenciamento sys.dm_db_resource_stats e sys.resource_stats dinâmicas para entender o consumo de CPU, E/S e memória. Seu desempenho poderá ser afetado se o banco de dados estiver sem recursos. Talvez seja necessário alterar o tamanho da computação e/ou a camada de serviço com base nas demandas crescentes e reduzidas da carga de trabalho.

Para um conjunto abrangente de recomendações sobre ajustes de problemas de desempenho, veja Ajuste seu banco de dados.

Como posso garantir que estou usando o nível de serviço e o tamanho de computação apropriados?

O Banco de Dados SQL oferece dois modelos de compra diferentes: o modelo de DTU mais antigo e o modelo de compra de vCore mais adaptável. Para obter mais informações, consulte Comparar modelos de compra baseados em vCore e DTU do Banco de Dados SQL do Azure.

Você pode monitorar o consumo de recursos de consulta e banco de dados em qualquer modelo de compra. Para obter mais informações, confira Monitoramento e ajuste de desempenho. Se você perceber que seus bancos de dados estão rodando consistentemente com alta utilização, considere escalar para um tamanho de computação maior. Da mesma forma, se você não usar tanto os recursos durante os horários de pico, considere reduzir o tamanho atual do computo. Você pode considerar usar o Automação do Azure para escalar seus bancos de dados SQL em um cronograma.

Se você tem um padrão de app SaaS ou um cenário de consolidação de banco de dados, considere usar um pool elástico para otimização de custos. Um pool elástico é uma ótima maneira de consolidar bancos de dados e otimizar custos. Para mais informações sobre como gerenciar múltiplos bancos de dados usando um pool elástico, veja Gerenciar pools e bancos de dados.

Com que frequência preciso executar verificações de integridade do banco de dados para meu banco de dados?

O Banco de Dados SQL pode lidar com determinadas classes de corrupção de dados automaticamente e sem nenhuma perda de dados. O serviço utiliza essas técnicas integradas quando a necessidade surge. Se houver problemas, o SQL Database resolve-os de forma proativa. Como uma camada extra de proteção, você pode optar por testar a restauração de backup e realizar verificações de integridade. Para mais informações, veja Integridade de dados no Banco de Dados SQL do Azure.

O reparo automático de páginas é usado para corrigir páginas que estejam corrompidas ou com problemas de integridade de dados. A CHECKSUM configuração sempre verifica a integridade das páginas do banco de dados. Para obter mais informações, consulte Integridade de Dados no Banco de Dados SQL.

Movimentação de dados após a migração

Como faço para exportar e importar dados como arquivos BACPAC a partir do SQL Database usando o portal do Azure?

• Exportar: você pode exportar seu banco de dados no Banco de Dados SQL do Azure como um arquivo BACPAC do portal do Azure:

  

• Importar: Você também pode importar dados como arquivo BACPAC para seu banco de dados no Banco de Dados SQL do Azure usando o portal Azure:

  

Como fazer para sincronizar dados entre o Banco de Dados SQL e o SQL Server?

Para mais informações sobre alternativas de sincronização de dados, veja Migrar para soluções alternativas.

Conteúdo relacionado

• Monitoramento e ajuste de desempenho no Banco de Dados SQL do Azure e na Instância Gerenciada de SQL do Azure