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

Aplica-se a: do Banco de Dados SQL do Azure

Migrar de um ambiente autogerenciado para um PaaS como o Banco de Dados SQL do Azure pode ser complexo. Este artigo destaca os principais recursos do Banco de Dados SQL do Azure para bancos de dados únicos 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
Continuidade de negócios e recuperação de desastres (BCDR)
Segurança e conformidade
Monitoramento e manutenção inteligentes de banco de dados
Movimentação de dados

Observação

Microsoft Entra ID era anteriormente conhecido como Azure Ative Directory (Azure AD).

Monitorar bancos de dados usando o portal do Azure

Para 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 camadas de serviço, consulte Visão geral do modelo de compra baseado em DTU e 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 ficar abaixo de um determinado limite.

Por exemplo, se você espera que a carga de trabalho em seu banco de dados cresça, você pode optar por configurar um alerta de e-mail sempre que seu banco de dados atingir 80% em qualquer uma das métricas de desempenho. Você pode usar isso como um aviso antecipado para descobrir quando você pode ter que mudar para o próximo tamanho de computação mais alto.

As métricas de desempenho também podem ajudá-lo a determinar se é possível fazer o downgrade para um tamanho de computação mais baixo. No entanto, esteja ciente das cargas de trabalho que aumentam ou flutuam antes de tomar a decisão de mudar para um tamanho de computação mais baixo.

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

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

Como faço para criar e gerenciar backups no Banco de dados SQL?

O Banco de Dados SQL do Azure faz backup automático dos 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 desastres seja eficiente e a perda de dados seja mínima. O primeiro backup completo acontece assim que você cria um banco de dados. Esses backups ficam 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 em qualquer momento dentro do período de retenção usando Recuperação de Ponto no Tempo (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 os dados desses backups a qualquer momento dentro desse período. Os backups de bancos de dados são mantidos em armazenamento replicado geograficamente para fornecer resiliência contra catástrofes regionais. Você também pode restaurar esses backups em qualquer região do Azure a qualquer momento dentro do período de retenção. Para obter mais informações, consulte Continuidade de negócios no Banco de Dados SQL do Azure.

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

Seus backups de banco de dados são armazenados em armazenamento replicado geograficamente para garantir que, durante 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 cronometragem de restaurações geográficas, consulte Geo-restore for Azure SQL Database.

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

Além da replicação geográfica ativa, os grupos de failover ajudam a gestionar a replicação e o failover de um grupo de bases 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, pode-se 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 a sua aplicação para casos de desastre e inicie um processo de transferência para o sistema secundário. Você pode criar até quatro réplicas geográficas ativas em diferentes regiões do Azure. Fica ainda melhor. Você também pode acessar essas réplicas geográficas ativas secundárias 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 desastres com o Banco de dados SQL?

A configuração e o gerenciamento da recuperação após desastres podem ser realizados em apenas alguns passos no Banco de Dados SQL do Azure quando se utiliza de replicação geográfica ativa ou grupos de failover. Você ainda precisa monitorar o aplicativo e seu banco de dados para 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 Azure SQL Database Disaster Recovery 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 segurança ideal para seu aplicativo da seguinte maneira:

Identidade e autenticação (autenticação SQL e autenticação com ID do Microsoft Entra).
Atividade de monitorização (Auditoria e deteção de ameaças).
Proteção de dados reais (criptografia de dados transparente [TDE] e sempre criptografada).
Controlando o acesso a dados confidenciais e privilegiados (segurança em nível de linha e mascaramento dinâmico de dados).

Microsoft Defender for Cloud oferece gerenciamento de segurança centralizado em cargas de trabalho executadas 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 de dados transparente [TDE], está configurada em todos os recursos e criar 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:

A autenticação do Windows não é suportada. O Microsoft Entra ID é um serviço centralizado de gerenciamento de identidade e acesso. O Microsoft Entra ID fornece acesso de logon único (SSO) para o pessoal em 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 de autenticação multifator, e pode ser facilmente integrado com o Windows Server Active Directory. Isso 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á usa o Ative Directory local, pode federa-lo com o Microsoft Entra ID para estender seu diretório para o Azure.

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

Se você...	Banco de Dados SQL / Azure Synapse Analytics
AD usado no SQL Server local	Federate AD com o Microsoft Entra IDe use a autenticação do Microsoft Entra. A federação permite que você use o logon único.
Necessidade de impor a autenticação multifator	Exija a autenticação multifator como uma política por meio do Acesso Condicional e use a Autenticação Multifator do Microsoft Entra.
Estão conectados ao Windows usando suas credenciais do Microsoft Entra de um domínio federado	Use a autenticação do Microsoft Entra.
Estão conectados ao Windows usando credenciais de um domínio não federado com o Azure	Use autenticação integrada do Microsoft Entra.
Ter serviços de camada intermediária que precisam se conectar ao Banco de Dados SQL ou ao Azure Synapse Analytics	Use autenticação integrada do Microsoft Entra.
Ter um requisito técnico para usar a autenticação SQL	Usar a autenticação SQL

Como posso limitar ou controlar o acesso de conectividade à minha base de dados?

Há várias técnicas à sua disposição que você pode usar para obter a organização de conectividade ideal para seu aplicativo.

Regras de firewall
Pontos finais 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 seu servidor apenas para entidades (por exemplo, uma máquina de desenvolvedor) que você aprovar, permitindo o endereço IP desse computador através do firewall. Ele também permite que você especifique um intervalo de IPs que você gostaria de permitir o acesso ao servidor. Por exemplo, os endereços IP da máquina do desenvolvedor em sua organização podem ser adicionados de uma só vez especificando um intervalo na página Configurações do firewall.

Você pode criar regras de firewall no nível do servidor ou no nível do banco de dados. As regras de firewall 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 IP no Banco de dados SQL.

Pontos finais 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. Estas tentativas ainda têm de ser autenticadas. Se 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, podes configurar extremidades de serviço da rede virtual.

Os pontos de extremidade de serviço permitem que você exponha seus recursos críticos do Azure somente à sua própria rede virtual privada no Azure. Esta opção elimina o acesso público aos seus recursos. O tráfego entre a sua rede virtual para o Azure permanece na rede de backbone do Azure. Sem pontos de extremidade de serviço, obtém-se roteamento de pacotes por tunelamento forçado. Sua rede virtual força o tráfego da Internet para sua organização e o tráfego do Serviço do Azure a percorrer a mesma rota. Com pontos de extremidade de serviço, você pode otimizar isso, uma vez que 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 as suas VMs e adicionar esses endereços IP específicos das VMs nas configurações do firewall do servidor. Ao atribuir IPs reservados, você evita o trabalho de ter que atualizar as regras de firewall com a alteração de endereços IP.

Em que porta me conecto ao Banco de dados SQL?

O Banco de dados SQL se comunica pela porta 1433. Para se conectar de dentro de uma rede corporativa, você precisa adicionar uma regra de saída nas configurações de firewall da sua organização. Como diretriz, evite expor a porta 1433 além dos limites do Azure.

Como posso monitorizar e regular a atividade no meu servidor e base de dados na Base de Dados SQL?

Auditoria de banco de dados SQL

A Auditoria da Base de Dados SQL do Azure regista eventos da base de dados e grava-os num ficheiro de registo de auditoria na 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íticas, manter a conformidade regulamentar, etc. Ele permite que você defina e configure certas 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.

Deteção de ameaças

Com a deteção de ameaças, você tem a capacidade de agir em caso de violações de segurança ou políticas descobertas pela auditoria. Você não precisa ser um especialista em segurança para lidar com possíveis ameaças ou violações em seu sistema. A deteção de ameaças também tem alguns recursos internos, como a deteção de injeção de SQL, que é uma maneira bastante comum de atacar um aplicativo de banco de dados. A deteção de ameaças executa vários conjuntos de algoritmos que detetam vulnerabilidades potenciais e ataques de injeção de SQL, além de padrões anômalos de acesso ao banco de dados (como acesso de um local incomum ou por uma entidade desconhecida).

Os agentes de segurança ou outros administradores designados recebem uma notificação por e-mail se uma ameaça for detetada no banco de dados. Cada notificação fornece detalhes da atividade suspeita e recomendações sobre como investigar e mitigar a ameaça. Para saber como ativar a deteção de ameaças, consulte Habilitar a deteção de ameaças.

Como posso proteger os meus dados em geral na Base de Dados SQL?

A criptografia fornece um mecanismo forte para proteger e proteger seus dados confidenciais contra intrusos. Os seus dados encriptados não têm qualquer utilidade para o intruso sem a chave de desencriptação. Assim, ele adiciona uma camada extra de proteção sobre as camadas existentes de segurança incorporadas no Banco de dados SQL. Há dois aspetos para proteger seus dados no Banco de dados SQL:

Seus dados armazenados nos arquivos de dados e log
Os seus dados durante o voo

No Base de Dados SQL, por padrão, os seus dados em repouso nos arquivos de dados e de log no subsistema de armazenamento são completamente e sempre encriptados por meio da criptografia de dados transparente [TDE]. As suas cópias de segurança também são encriptadas. Com a TDE, não são necessárias alterações no lado do aplicativo que está acessando esses dados. A encriptação e desencriptação acontecem de forma transparente; daí o nome.

Para proteger seus dados confidenciais em voo e em repouso, o Banco de dados SQL fornece um recurso chamado Sempre criptografado. Always Encrypted é uma forma de criptografia do lado do cliente que criptografa colunas confidenciais em seu banco de dados (para que elas estejam em texto cifrado para administradores de banco de dados e usuários não autorizados). O servidor inicialmente recebe os dados encriptados.

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

O Always Encrypted oferece suporte a comparações de igualdade, para que os DBAs possam continuar a consultar 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 do Cofre da Chave do Azure, armazenamento de certificados do Windows e módulos de segurança de hardware locais.

Caraterísticas	Sempre criptografado	Encriptação de dados transparente
Intervalo de criptografia	De ponta a ponta	Dados em repouso
Server pode acessar dados confidenciais	Não	Sim, uma vez que a encriptação é para os dados em repouso
Operações T-SQL permitidas	Comparação da igualdade	Toda a área de superfície do T-SQL está disponível
Alterações no aplicativo necessárias para usar o recurso	Mínimo	Mínimo
Granularidade de criptografia	Nível da coluna	Nível do banco de dados

Como posso limitar o acesso a dados sensíveis na minha base de dados?

Cada aplicativo tem dados confidenciais no banco de dados que precisam ser protegidos de serem visíveis para todos. Certos funcionários dentro da organização precisam visualizar esses dados, no entanto, outros não devem ser capazes de visualizar esses dados. Nesses casos, seus dados confidenciais precisam ser mascarados ou não devem ser expostos. O Banco de dados SQL oferece duas dessas abordagens para impedir que usuários não autorizados possam exibir 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 para usuários sem privilégios na camada de aplicativo. Você define uma regra de mascaramento que pode criar um padrão de mascaramento (por exemplo, para mostrar apenas os últimos quatro dígitos de um SSN de ID nacional: XXX-XX-0000 e mascarar a maior parte dele com o X caractere) e identificar quais usuários devem ser excluídos da regra de mascaramento. O mascaramento acontece em tempo real e existem várias funções de mascaramento disponíveis para várias categorias de dados. O mascaramento dinâmico de dados permite que você detete automaticamente dados confidenciais em seu banco de dados e aplique mascaramento a eles.
A segurança em nível de linha permite controlar o acesso no nível da linha. Ou seja, certas linhas em uma tabela de banco de dados com base no usuário que executa a consulta (associação ao grupo ou contexto de execução) estão ocultas. A restrição de acesso é feita na camada de banco de dados em vez de em uma camada de aplicativo, para simplificar a lógica do aplicativo. Você começa criando um predicado de filtro, filtrando as linhas que não estão expostas e a política de segurança definindo em seguida quem tem acesso a essas linhas. Finalmente, o usuário final executa sua consulta e, dependendo do privilégio do usuário, ele visualiza essas linhas restritas ou não consegue vê-las.

Como faço para gerenciar chaves de criptografia na nuvem?

Há opções de gerenciamento de chaves para criptografia Always Encrypted (criptografia do lado do cliente) e criptografia de dados transparente (criptografia em repouso). É recomendável girar regularmente as chaves de criptografia. A frequência de rotação deve estar alinhada com os regulamentos internos da organização e com os requisitos de conformidade.

Criptografia de dados transparente (TDE)

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

Automaticamente pelo Banco de Dados SQL do Azure
Ou usando Azure Key Vault como armazenamento de chaves

Por padrão, a chave mestra para TDE é gerenciada pelo Banco de Dados SQL do Azure. Se sua organização quiser ter controle sobre a chave mestra, você poderá usar o Cofre de Chaves do Azure como o armazenamento de chaves. Ao usar o Cofre de Chaves do Azure, sua organização assume o controle sobre o provisionamento de chaves, rotação e controles de permissão. A rotação ou a comutação do tipo de chave mestra TDE é rápida, pois apenas re-encripta 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 de chave para a chave mestra TDE no Cofre de Chaves do Azure e fornecer um identificador de chave do Cofre de Chaves do Azure ao administrador do banco de dados para usar para criptografia em repouso em um servidor. O Cofre da Chave foi concebido de forma a que a Microsoft não veja nem extraia quaisquer chaves de encriptação. Você também obtém 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 chave de criptografia AES de 256 colunas (CEK), que por sua vez é criptografada por uma chave mestra de coluna (CMK). Os drivers de cliente fornecidos para Always Encrypted não têm limitações no comprimento das CMKs. O valor criptografado do CEK é armazenado no banco de dados e a CMK é armazenada em um armazenamento de chaves confiável, como o Repositório de Certificados do Windows, o Cofre de Chaves do Azure ou um módulo de segurança de hardware.

Tanto o CEK quanto o CMK podem ser rotacionados.
A rotação de CEK é um tipo de operação de dados e pode ser demorada, dependendo do tamanho das tabelas que contêm as colunas encriptadas. Por isso, é prudente planejar as rotações CEK de acordo.
A rotação CMK, no entanto, 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 de armazenamento de chaves para as chaves mestras de coluna em Always Encrypted:

Como posso otimizar e proteger o tráfego entre a minha organização e a Base 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 Azure por meio de uma conexão privada. Ao fazer isso, você não acessa a Internet pública. Você também obtém maior segurança, confiabilidade e otimização de roteamento, o que se traduz em latências de rede mais baixas e velocidades mais rápidas do que normalmente usaria pela Internet pública. Se você estiver planejando transferir uma parte significativa de dados entre sua organização e o Azure, usar a Rota Expressa pode gerar benefícios de custo. Você pode escolher entre três modelos de conectividade diferentes para a conexão de sua organização com o Azure:

O ExpressRoute também permite que você aumente até 2x o limite de largura de banda que você compra sem nenhum custo extra. Também é possível configurar a conectividade entre regiões usando a Rota Expressa. Para obter uma lista de provedores de conectividade de Rota Expressa, consulte Parceiros de Rota Expressa e locais de emparelhamento. Os seguintes artigos descrevem a Rota Expressa com mais detalhes:

O Banco de Dados SQL é compatível com quaisquer requisitos normativos e como isso ajuda na conformidade da minha própria organização?

O Banco de dados SQL é compatível com uma série de conformidades regulamentares. Para exibir o conjunto mais recente de conformidades atendidas pelo Banco de Dados SQL, visite a Central de Confiabilidade da Microsoft e examine as conformidades importantes para sua organização para ver se o Banco de Dados SQL está incluído nos serviços compatíveis do Azure. Embora o Banco de dados SQL seja certificado como um serviço compatível, ele ajuda na conformidade do serviço da sua organização, mas não o garante automaticamente.

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

Depois de migrar seu banco de dados para o Banco de dados SQL, você deve monitorar seu banco de dados (por exemplo, verificar como é a utilização de recursos ou verificações DBCC) e executar manutenção regular (por exemplo, reconstruir 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 sempre de forma otimizada. Em alguns casos, o Banco de Dados SQL do Azure pode executar automaticamente tarefas de manutenção dependendo da sua configuração de configuração. Há três facetas para monitorar seu banco de dados no Banco de dados SQL:

Monitorização e otimização do desempenho
Otimização da segurança
Otimização de custos

Monitorização e otimização do 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 sendo executados em um nível ideal. Você também pode configurá-lo para que essas recomendações sejam aplicadas automaticamente e você não precise se preocupar em executar tarefas de manutenção. Com o Supervisor do 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 à medida que a carga de trabalho do aplicativo muda para fornecer as sugestões mais relevantes. Você também tem a opção de revisar manualmente essas recomendações e aplicá-las a seu critério.

Otimização da segurança

A Base de Dados SQL fornece recomendações de segurança práticas para ajudá-lo a proteger os seus dados e a detecção de ameaças para identificar e investigar atividades suspeitas da base de dados que podem representar uma ameaça potencial para a base de dados. Avaliação de Vulnerabilidades é um serviço de varrimento e relatório de bases de dados que permite monitorizar o estado de segurança das suas bases de dados em escala e identificar riscos de segurança e desvios de uma linha de base de segurança definida por si. 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 for Cloud, você identifica as recomendações de segurança em todos os aspetos e as aplica rapidamente.

Otimização de custos

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

Você pode receber notificações de banner em seu servidor SQL do Azure de recomendações de custo. Para obter mais informações, consulte Pools elásticos ajudam 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 faço 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 Banco de dados SQL usando os seguintes métodos:

observador de banco de dados

O inspetor de banco de dados coleta dados detalhados de monitoramento da carga de trabalho para fornecer uma visão detalhada do desempenho, da configuração e da integridade do banco de dados. Os dashboards no portal do Azure fornecem uma visão abrangente do seu conjunto de recursos SQL do Azure e uma visão detalhada de cada recurso monitorado. Os dados são coletados em um armazenamento de dados central em sua assinatura do Azure. Você pode consultar, analisar, exportar, visualizar os dados coletados e integrá-los com sistemas downstream.

Para obter mais informações sobre o inspetor de banco de dados, consulte os seguintes artigos:

portal do Azure

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

Neste gráfico, você também pode configurar alertas por recurso. Esses alertas permitem que você responda às condições do recurso com um e-mail, escreva em um ponto de extremidade HTTPS/HTTP 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.

Visualizações de gerenciamento dinâmico

Você pode consultar a exibição de gerenciamento dinâmico sys.dm_db_resource_stats para retornar o histórico de estatísticas de consumo de recursos da última hora e a exibição de catálogo do sistema sys.resource_stats para retornar o histórico dos últimos 14 dias.

Insight de desempenho de consulta

A funcionalidade de análise de desempenho de consultas permite que se veja um histórico das principais consultas que consomem recursos e das 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 rastrear consultas e detetar regressão. Este recurso requer que o Repositório de Consultas esteja ativado e ativo para a base de dados.

Percebo problemas de desempenho: Qual é a diferença entre minha metodologia de solução de problemas do Banco de dados SQL e o SQL Server?

Uma grande parte das técnicas de solução de problemas que você usaria para diagnosticar problemas de desempenho de consultas e bancos 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 e diagnosticar problemas de desempenho com ainda mais facilidade. 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 o Query Performance Insight (QPI) e o Database Advisor em conjunto e, portanto, a diferença na metodologia difere nesse aspeto – você não precisa mais fazer o trabalho manual de triturar os detalhes essenciais que podem ajudá-lo a solucionar o problema em questão. A plataforma faz o trabalho duro para você. Um exemplo disso é o QPI. Com o QPI, você pode detalhar até o nível de consulta e examinar as tendências históricas e descobrir quando exatamente a consulta regrediu. O Supervisor de Banco de Dados fornece recomendações sobre coisas que podem ajudá-lo a melhorar seu desempenho geral em geral, como índices ausentes, queda de índices, parametrização de consultas, etc.

Na resolução de problemas de desempenho, é importante identificar se é apenas a aplicação ou o banco de dados que a suporta, que está a afetar o desempenho da aplicação. Muitas vezes, o problema de desempenho está na camada de aplicação. Pode ser a arquitetura ou o padrão de acesso aos dados. Por exemplo, considere que você tem um aplicativo tagarela que é sensível à latência da rede. Neste caso, seu aplicativo sofre porque haveria muitas solicitações curtas indo e voltando ("tagarelas") 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 seu aplicativo.

Além disso, se você notar uma degradação no desempenho geral do banco de dados, poderá monitorar as exibições de gerenciamento dinâmico sys.dm_db_resource_stats e sys.resource_stats para entender o consumo de CPU, E/S e memória. Seu desempenho pode 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 crescentes e reduzidas demandas de carga de trabalho.

Para obter um conjunto abrangente de recomendações para ajustar problemas de desempenho, consulte Ajustar seu banco de dados.

Como posso garantir que estou a utilizar a camada de serviço e o tamanho de computação adequados?

O Banco de dados SQL oferece dois modelos de compra diferentes: o modelo DTU mais antigo e o modelo de compra 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 sua consulta e o consumo de recursos do banco de dados em qualquer modelo de compra. Para obter mais informações, consulte Monitor e ajuste de desempenho. Se constatar que as suas consultas/bases de dados estão a consumir muitos recursos de forma consistente, pode considerar aumentar o tamanho da instância de computação. Da mesma forma, se você não parece usar tanto os recursos durante o horário de pico, considere reduzir o tamanho de computação atual. Você pode considerar usar a Automação do Azure para escalonar seus bancos de dados SQL de acordo com uma agenda.

Se você tiver um padrão de aplicativo SaaS ou um cenário de consolidação de banco de dados, considere usar um pool elástico para otimização de custos. O pool elástico é uma ótima maneira de obter consolidação de banco de dados e otimização de custos. Para obter mais informações sobre como gerenciar vários bancos de dados usando 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 qualquer perda de dados. Estas técnicas incorporadas são utilizadas pelo serviço quando surge a necessidade. Seus 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 os abordará proativamente.

O reparo automático de páginas é usado para corrigir páginas corrompidas ou com problemas de integridade de dados. As páginas do 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 revisa proativamente a integridade dos dados do seu banco de dados e soluciona 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 faço 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:
Importar: 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 sincronizo dados entre o Banco de dados SQL e o SQL Server?

Você tem várias maneiras de conseguir isso:

Sincronização de dados: esse recurso ajuda 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, você precisa instalar e configurar o agente de sincronização em um computador local ou em uma 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 para 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 enquanto, apenas esta configuração é suportada. Para obter mais informações sobre como migrar seus dados de um banco de dados do SQL Server para o SQL do Azure com o mínimo de tempo de inatividade, consulte Usar replicação de transações

Monitor e ajuste de desempenho no Banco de Dados SQL do Azure e no da Instância Gerenciada SQL do Azure

Comentários

Esta página foi útil?

Last updated on 2025-09-17