DBA novo na nuvem – Gerenciar o Banco de Dados SQL do Azure após a 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 o 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 aviso antecipado para decidir quando precisará alternar para o próximo tamanho da computação mais elevado.

As métricas de desempenho podem ajudá-lo a determinar se você pode fazer downgrade para um tamanho da computação inferior. 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 a cada semana, backup diferencial a cada poucas horas e um backup de log a cada 5 minutos para garantir que a recuperação de desastre seja eficiente e a perda de dados seja mínima. O primeiro backup completo acontece assim que você criar um banco de dados. Esses backups estão disponíveis para você por um determinado período chamado período de retenção, que varia de acordo com a camada de serviço escolhida. Você pode restaurar para qualquer ponto no tempo dentro desse período de retenção usando PITR (Recuperação Pontual).

Além disso, o recurso de backups de retenção de longo prazo permite manter seus arquivos de backup por até 10 anos e restaurar dados desses backups a qualquer momento dentro desse período. Os backups de banco de dados são mantidos no armazenamento replicado geograficamente para fornecer resiliência contra catástrofes regionais. Você também pode restaurar esses backups em qualquer região do Azure em qualquer momento dentro do 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?

Seus backups de banco de dados são armazenados em um armazenamento replicado geograficamente para garantir que, no caso de um desastre regional, você possa restaurar o backup para outra região do Azure. Isso é chamado de restauração geográfica. Para obter mais informações e o tempo das restaurações geográficas, confira Restauração geográfica para o 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 seu banco de dados está inicialmente hospedado na região Oeste dos EUA do Azure e você deseja resiliência a desastre regional, crie uma réplica de replicação geográfica do banco de dados no Oeste dos EUA para o Leste dos EUA. 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 seu aplicativo em busca de um desastre e inicie um failover para o 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 réplicas geográficas secundárias ativas para acesso somente leitura. Isso ajuda a reduzir a latência de um cenário de aplicativo distribuído geograficamente.

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

A configuração e o gerenciamento da recuperação de desastres podem ser feitos com apenas algumas etapas no Banco de Dados SQL do Azure quando você usa replicação geográfica ativa ou grupos de 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

A segurança no Banco de Dados SQL está disponível no nível do banco de dados e no nível da plataforma. Você pode controlar e fornecer a segurança ideal para seu aplicativo da seguinte maneira:

• 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).
• Controlando o Acesso a dados confidenciais e privilegiados (segurança em nível de linha e mascaramento de dados dinâmicos).

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ário são oferecidos no Banco de Dados SQL?

Há dois métodos de autenticação oferecidos no Banco de Dados SQL:

• 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. O que isso significa é que as credenciais são compartilhadas entre os serviços do Azure para facilitar a autenticação.

O Microsoft Entra ID dá suporte a autenticação multifator e pode ser facilmente integrado ao Windows Server Active Directory. Isto também permite que o Banco de dados SQL e o Azure Synapse Analytics ofereçam autenticação multifator e contas de usuário convidado em um domínio do 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?

Há várias técnicas à sua disposição que podem ser usadas para obter a organização de conectividade ideal para seu aplicativo.

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

Firewall

Por padrão, todas as conexões com bancos de dados dentro do servidor não são permitidas, exceto (opcionalmente) conexões provenientes de outros Serviços do Azure. Com uma regra de firewall, você pode abrir o acesso ao servidor apenas para entidades (por exemplo, um computador de desenvolvedor) que você aprova, permitindo o endereço IP desse computador por meio do firewall. Ele também permite especificar um intervalo de IPs para os quais você deseja permitir o acesso ao servidor. Por exemplo, endereços IP de computador de desenvolvedor na sua organização podem ser adicionados de uma só vez especificando-se um intervalo na página de configurações Firewall.

Você pode criar regras de firewall no nível de servidor ou no nível de banco de dados. Regras de firewall de IP no nível do servidor podem ser criadas usando o portal do Azure ou com o 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 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 roteamento de pacotes por "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. Com os endpoints de serviço, você pode otimizar isso, pois os pacotes fluem diretamente da sua rede virtual para o serviço na rede de 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ê evita a necessidade de ter que atualizar as regras de firewall com a alteração dos endereços IP.

Em qual porta me conecto ao Banco de Dados SQL?

O Banco de Dados SQL se comunica pela porta 1433. Para se conectar de uma rede corporativa, você precisa 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ê pretende obter informações sobre possíveis violações de segurança e política, manter a conformidade regulatória etc. Ele permite que você defina e configure determinadas categorias de eventos que você acha que precisam de auditoria e, com base nisso, você pode obter relatórios pré-configurados e um painel para obter uma visão geral dos eventos que ocorrem em seu banco de dados.

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

Detecção de ameaças

Com a detecção de ameaças, você obtém a capacidade de agir sobre violações de segurança ou política descobertas pela auditoria. 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 tem alguns recursos internos, como a detecção de injeção de SQL, que é uma maneira bastante 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 têm nenhuma utilidade 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:

• Seus dados armazenados nos arquivos de dados e log
• Seus dados em transmissão

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 aplicativo tem dados confidenciais no banco de dados que precisam ser protegidos contra serem visíveis para todos. Uma certa equipe na organização precisa ver esses dados, porém outras não devem conseguir vê-los. Nesses casos, seus dados confidenciais precisam ser mascarados ou não expostos. O Banco de Dados SQL oferece duas abordagens para impedir que usuários não autorizados possam visualizar dados confidenciais:

• O mascaramento dinâmico de dados é um recurso de mascaramento de dados que permite limitar a exposição de dados confidenciais mascarando-os a usuários não privilegiados na camada do aplicativo. Você define uma regra de mascaramento que pode criar um padrão de máscara (por exemplo, para mostrar apenas os últimos quatro dígitos de um SSN de ID nacional: XXX-XX-0000 e mascarar a maior parte com o X caractere) e identificar quais usuários devem ser excluídos da regra de mascaramento. O mascaramento ocorre durante a execução e várias funções de mascaramento estão disponíveis para várias categorias de dados. O mascaramento de dados dinâmicos permite automaticamente detectar dados confidenciais no banco de dados e aplicar mascaramento a eles.

• A segurança em nível de linha permite controlar o acesso no nível da linha. Ou seja, determinadas linhas em uma tabela de banco de dados com base no usuário que executa a consulta (uma associação de grupo ou um contexto de execução) são ocultadas. A restrição de acesso é feita no nível do banco de dados em vez de em uma camada de aplicativo, para simplificar a lógica do aplicativo. Comece criando um predicado de filtro, filtrando linhas que não devem ser expostas e a política de segurança e, em seguida, definindo quem tem acesso a essas linhas. Por fim, o usuário final executa a consulta e, dependendo do privilégio de usuário, ele visualiza essas linhas restritas ou não pode vê-las de maneira alguma.

Como gerenciar chaves de criptografia na nuvem?

Há opções de gerenciamento de chave para Always Encrypted (criptografia do lado do cliente) e transparent data encryption (criptografia em repouso). Recomendamos que você regularmente gire as chaves de criptografia. A frequência de rotação deve ser alinhada com os regulamentos internos da organização e requisitos de conformidade.

TDE (Transparent Data Encryption)

Há uma hierarquia de duas chaves na TDE – os dados em cada banco de dados do usuário são criptografados por uma DEK (chave de criptografia de banco de dados) exclusiva do banco de dados AES-256 simétrica que, por sua vez, é criptografada por uma chave mestra assimétrica RSA 2048 exclusiva do servidor. A chave mestra pode ser gerenciada:

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

Por padrão, a chave mestra do TDE é gerenciada pelo Banco de Dados SQL do Azure. Se sua organização quiser controlar a chave mestra, você poderá usar o Azure Key Vault como repositório 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 para a chave mestra de TDE no Azure Key Vault e fornecer um identificador de chave do Azure Key Vault para o administrador de banco de dados para uso na 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

Há também uma hierarquia de duas chaves em Always Encrypted - uma coluna de dados confidenciais é criptografada por uma CEK (chave de criptografia de coluna) AES 256 que, por sua vez, é criptografada por uma CMK (chave mestra da coluna). 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.

• Tanto a CEK quanto a CMK podem ser giradas.

• A rotação da CEK é um tamanho de operação de dados e pode ser demorada, dependendo do tamanho das tabelas contendo colunas criptografadas. Portanto, é recomendável planejar rotações de CEK adequadamente.

• No entanto, a rotação da 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 Banco de Dados SQL geralmente é roteado pela rede pública. No entanto, você pode otimizar esse caminho e torná-lo mais seguro com o Azure ExpressRoute. O ExpressRoute estende sua rede corporativa para a plataforma do Azure por meio de uma conexão privada. Fazendo isso, você não passa pela 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 está planejando transferir uma parte significativa dos dados entre sua organização e o Azure, usar o ExpressRoute pode gerar 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. Também é possível 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 abaixo descrevem a Rota Expressa em mais detalhes:

• Introdução à Rota Expressa
• 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?

O Banco de Dados SQL cumpre várias regras de conformidade regulatória. Para exibir o conjunto mais recente de conformidades que foram cumpridas pelo Banco de Dados SQL, visite a Central de Confiabilidade da Microsoft e examine as conformidades que são importantes para sua organização para ver se o Banco de Dados SQL está incluído nos serviços em conformidade com o 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 Banco de Dados SQL, você deverá monitorar seu banco de dados (por exemplo, verificar como é a utilização do recurso ou verificações de DBCC) e executar a manutenção regular (por exemplo, recompilar ou reorganizar índices, estatísticas etc.). 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

Com o Query Performance Insights, você pode obter recomendações personalizadas para sua carga de trabalho de banco de dados para que seus aplicativos possam continuar em execução 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. Com o Assistente de Banco de Dados SQL, você pode implementar automaticamente recomendações de índice com base em sua carga de trabalho. Isso é chamado de Ajuste Automático. 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 Banco de Dados SQL fornece recomendações viáveis de segurança para ajudá-lo a proteger os dados e detectar ameaças para identificar e investigar atividades suspeitas do banco de dados que podem representar uma potencial ameaça para o banco de dados. A avaliação de vulnerabilidade é um serviço de exame e relatório de banco de dados que permite monitorar o estado de segurança de seus bancos de dados em grande escala e identificar os riscos de segurança e o desvio de uma linha de base de segurança definida por você. Após cada verificação, uma lista personalizada de etapas acionáveis e scripts de correção é fornecida e um relatório de avaliação que pode ser usado para ajudar a atender aos requisitos de conformidade.

Com o Microsoft Defender para Nuvem, você identifica as recomendações de segurança de modo geral e as aplica rapidamente.

Otimização de custo

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

É possível receber notificações de faixa em seu servidor SQL do Azure de recomendações de custo. Para obter mais informações, consulte pools elásticos que ajudam você a gerenciar e dimensionar vários bancos de dados no Banco de Dados SQL do Azure e planejar e gerenciar custos para o Banco de Dados SQL do Azure.

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

Também é possível monitorar o desempenho e a utilização de recursos em um Banco de Dados SQL usando os métodos a seguir:

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 fornecem uma visão de painel único do seu patrimônio 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:

• Monitorar cargas de trabalho de SQL do Azure com o observador de banco de dados (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)
• Conjuntos e coleção de dados do observador de bancos de dados (preview)
• Analisar dados de monitoramento do observador de banco de dados (preview)
• Perguntas frequentes sobre o observador de banco de dados

portal do Azure

O portal do Azure exibe a utilização de um banco de dados selecionando o banco de dados e selecionando o gráfico do painel 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 email, grave em um ponto de extremidade HTTP/HTTPS ou execute uma ação. Para obter mais informações, consulte Criar alertas para o Banco de Dados SQL do Azure e o Azure Synapse Analytics usando o portal do 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 de regressão. 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?

Uma parte importante das técnicas de solução de problemas que você usaria para diagnosticar problemas de desempenho de consulta e de banco de dados permanece a mesma: o mesmo mecanismo de banco de dados alimenta a nuvem. O Banco de Dados SQL do Azure pode ajudá-lo a solucionar problemas e diagnosticar problemas de desempenho ainda mais facilmente. Ele também pode executar 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 usando recursos inteligentes, como QPI ( Análise de Desempenho de Consultas ) e Orientador de Banco de Dados em conjunto e, portanto, a diferença na metodologia difere nesse aspecto– você não precisa mais fazer o trabalho manual de moer os detalhes essenciais que podem ajudá-lo a solucionar o problema em questão. A plataforma faz o trabalho pesado por você. Um exemplo disso é a QPI. Com a QPI, você pode detalhar tudo até o nível da consulta e observar as tendências históricas e descobrir quando exatamente a consulta foi retornada. O Orientador de Banco de Dados fornece recomendações sobre itens que podem ajudá-lo a melhorar seu desempenho geral em geral, como índices ausentes, índices de remoção, parametrização de suas consultas etc.

Com a solução de problemas do desempenho, é importante identificar se é apenas o aplicativo ou o banco de dados de backup que está afetando o desempenho do aplicativo. 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, seu aplicativo sofre porque haveria muitas solicitações curtas indo e voltando ("tagarela") entre o aplicativo e o servidor e em uma rede congestionada, e essas viagens de ida e volta se somam 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 observar uma degradação no desempenho geral de seu banco de dados, você pode monitorar as exibições de gerenciamento dinâmico sys.dm_db_resource_stats e sys.resource_stats para compreender 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 obter um conjunto abrangente de recomendações para ajustar problemas de desempenho, consulte Ajustar seu banco de dados.

Como fazer para garantir que estou usando a camada 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 suas consultas/bancos de dados estão sendo executados de forma consistente, considere a possibilidade de aumentar a escala para um tamanho de computação maior. Da mesma forma, se você não parece usar os recursos tanto durante o horário de pico, considere reduzir o tamanho da computação atual. É possível considerar o uso da Automação do Azure para dimensionar seus bancos de dados SQL em um agendamento.

Se tiver um cenário de padrão de aplicativo SaaS ou de consolidação de banco de dados, considere o uso de um Pool elástico para otimizar os custos. O pool elástico é uma ótima maneira de obter a consolidação de banco de dados e a otimização de custoa. Para obter mais informações sobre como gerenciar vários bancos de dados usando o pool elástico, consulte 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. Essas técnicas internas são usadas pelo serviço quando a necessidade surge. Os backups de banco de dados em todo o serviço são testados regularmente restaurando-os e executando DBCC CHECKDB neles. Se houver problemas, o Banco de Dados SQL trata deles proativamente.

O reparo automático de página é usado para corrigir páginas corrompidas ou que têm problemas de integridade de dados. As páginas de banco de dados são sempre verificadas com a configuração padrão CHECKSUM que verifica a integridade da página. O Banco de Dados SQL monitora e analisa proativamente a integridade dos dados do banco de dados e resolve os problemas à medida que eles surgem. Opcionalmente, você pode executar suas próprias verificações de integridade conforme necessário. Para obter mais informações, consulte Integridade de Dados no Banco de Dados SQL.

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

Como fazer para exportar e importar dados como arquivos BACPAC do Banco de Dados SQL 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:

  

• Importação: você também pode importar dados como um arquivo BACPAC para seu banco de dados no Banco de Dados SQL do Azure usando o portal do Azure:

  

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

Há várias maneiras fazer isso:

• Sincronização de Dados: esse recurso ajuda você a sincronizar dados bidirecionalmente entre vários bancos de dados do SQL Server e o Banco de Dados SQL. Para sincronizar com bancos de dados do SQL Server local, você precisa instalar e configurar o agente de sincronização em um computador local ou máquina virtual e abrir a porta TCP de saída 1433.

• Replicação de transações: com a replicação de transações, você pode sincronizar seus dados de um banco de dados do SQL Server com o Banco de Dados SQL do Azure com a instância do SQL Server sendo o editor e o Banco de Dados SQL do Azure sendo o assinante. Por ora, apenas há suporte apenas para esta configuração. Para obter mais informações sobre como migrar seus dados de um banco de dados do SQL Server para o SQL do Azure com tempo de inatividade mínimo, consulte Usar Replicação de Transações

Conteúdo relacionado

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