Novo DBA na cloud: Gerir o Base de Dados SQL do Azure após 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

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 todas as semanas, backup diferencial a cada poucas horas e um backup de log a cada cinco minutos para garantir que a recuperação em caso de desastre é eficiente e a perda de dados mínima. O primeiro backup completo acontece assim que você cria um banco de dados. Pode aceder a estes backups durante um determinado período chamado período de retenção, que varia consoante o nível de serviço que escolher. Pode restaurar para qualquer ponto no tempo dentro deste período de retenção utilizando Recuperação num Ponto no Tempo (PITR).

Além disso, a funcionalidade de backups de retenção a longo prazo permite-lhe guardar os seus ficheiros de backup por até 10 anos e restaurar dados desses backups em qualquer momento desse período. O Azure mantém cópias de segurança da base de dados em armazenamento geo-replicado para garantir resiliência face a catástrofes regionais. Também pode restaurar estas cópias de segurança em qualquer região do Azure a qualquer momento durante o 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?

Guarde as suas cópias de segurança da base de dados em armazenamento geo-replicado para garantir que, durante um desastre regional, possa restaurar a cópia de segurança noutra região do Azure. Esta funcionalidade chama-se restauração geográfica. Para obter mais informações e cronometragem de restaurações geográficas, consulte Geo-restore for Base de Dados SQL do Azure.

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.

Para além da geo-replicação ativa, os grupos de failover ajudam a gerir a replicação e 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. Também pode aceder a estas geo-réplicas ativas secundárias em modo só de leitura, o que ajuda a reduzir a latência num cenário de aplicação geograficamente distribuída.

Como é a recuperação de desastres com o Banco de dados SQL?

Pode configurar a sua estratégia de recuperação de desastres em apenas alguns passos no Base de Dados SQL do Azure quando utiliza grupos ativos de geo-replicação ou 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 Base de Dados SQL do Azure Disaster Recovery 101.

Segurança e conformidade

Base de Dados SQL do Azure fornece segurança tanto ao nível da base de dados como ao nível da plataforma. Pode controlar e fornecer a segurança ideal para a sua aplicação utilizando as seguintes funcionalidades:

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

Microsoft Defender para a 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.

Que métodos de autenticação de utilizadores oferece o SQL Database?

A base de dados SQL oferece dois métodos de autenticação:

• autenticação do Microsoft Entra
• autenticação 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. Isto significa que as credenciais são partilhadas entre os serviços do Azure para facilitar a autenticação.

O Microsoft Entra ID suporta autenticação multifator e pode ser facilmente integrado com o Microsoft Entra Connect Sync. Esta integração também permite que o Base de Dados SQL do Azure ofereça autenticação multifator e contas de utilizador convidado dentro de um domínio 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.

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

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

• Regras de firewall
• Pontos finais de serviço de rede virtual
• IPs reservados

Firewall

Por defeito, o servidor SQL lógico impede todas as ligações a bases de dados, exceto (opcionalmente) ligações provenientes de outros serviços Azure. Ao usar uma regra de firewall, pode abrir o acesso ao seu servidor apenas a entidades (por exemplo, uma máquina de programação) que aprove, permitindo que o endereço IP desse computador passe pelo firewall. Também pode especificar um intervalo de IPs que pretende permitir o acesso ao servidor. Por exemplo, pode adicionar endereços IP de máquinas programadoras na sua organização de uma só vez, especificando um intervalo na página de definições do Firewall.

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

Pontos finais de serviço

Por defeito, a tua base de dados está configurada para permitir que os serviços e recursos do Azure acedam a este servidor, o que significa que qualquer máquina virtual no Azure pode tentar ligar-se à tua base 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. 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 as suas VMs e adicionar esses endereços IP específicos das VMs nas configurações do firewall do servidor. Ao atribuir IPs reservados, não precisa de atualizar as regras do firewall ao mudar de endereços IP.

Em que porta me conecto ao Banco de dados SQL?

O Banco de Dados SQL do Azure se comunica pela porta 1433. Para se ligar dentro de uma rede corporativa, deve adicionar uma regra de saída nas definições do 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 quiser obter informações sobre potenciais violações de segurança e políticas, manter a conformidade regulatória e muito mais. Fornece relatórios pré-configurados e um painel de controlo para lhe dar uma visão geral dos eventos que ocorrem na sua base de dados. Podes definir e configurar as categorias de eventos que precisam de ser auditados.

Pode aplicar estas políticas de auditoria ao nível da base de dados ou ao nível do servidor. Para mais informações, consulte Ativar a Auditoria de Bases de Dados SQL.

Deteção de ameaças

Ao utilizar a deteção de ameaças, pode agir sobre violações de segurança ou políticas descobertas através de auditorias. 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 algumas capacidades incorporadas, como a deteção de injeção SQL, que é uma forma comum de atacar uma aplicação de base 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.

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

Cada aplicação tem dados sensíveis na base de dados que precisa de proteger para não serem visíveis para todos. Certos membros da organização precisam de ver estes dados, mas outros não. Nesses casos, deve ou mascarar os seus dados sensíveis ou não os expor de todo. O SQL Database oferece duas abordagens para evitar que utilizadores não autorizados vejam dados sensíveis:

• O mascaramento dinâmico de dados é uma funcionalidade de mascaramento que pode usar para limitar a exposição de dados sensíveis, mascarando-os a utilizadores não privilegiados. Defines uma regra de mascaramento que cria um padrão de mascaramento. Por exemplo, pode mostrar apenas os últimos quatro dígitos de um número de identificação nacional XXX-XX-0000 e mascarar o resto com o caráter X. Com o mascaramento dinâmico de dados, identifica quais os utilizadores 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.

• A segurança em nível de linha permite controlar o acesso no nível da linha. Esta funcionalidade esconde certas linhas numa tabela de base de dados com base no utilizador que executa a consulta (pertença ao grupo ou contexto de execução). A restrição de acesso é feita na camada de base de dados em vez de numa camada de aplicação, o que simplifica a lógica da aplicação. Começas por criar um predicado que filtra as linhas que não estão expostas. Depois, cria-se a política de segurança que define quem tem acesso a essas linhas. Finalmente, o utilizador final executa a sua consulta e, dependendo do privilégio do utilizador, ou visualiza essas linhas restritas ou não as consegue ver de todo.

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

Tanto o Always Encrypted (encriptação do lado do cliente) como a encriptação de dados transparentes (encriptação em repouso) oferecem opções de chave gerida pelo cliente . Roda as chaves de encriptação regularmente. Escolha uma frequência de rotação que esteja alinhada com os regulamentos internos da sua organização e os requisitos de conformidade.

Criptografia de dados transparente (TDE)

O TDE utiliza uma hierarquia de duas chaves. Os dados de cada base de dados de utilizador são encriptados por uma chave de encriptação de base de dados (DEK) simétrica AES-256, que é encriptada por uma chave mestra assimétrica RSA 2048 única para cada 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 defeito, o Base de Dados SQL do Azure gere a chave mestra TDE. Se a sua organização quiser controlo sobre a chave mestra, use o Azure Key Vault como 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 gestão de dados, um administrador de segurança pode provisionar o material de chave para a chave mestra TDE no Azure Key Vault e fornecer um identificador de chave Azure Key Vault ao administrador da base de dados para usar para encriptação em repouso num 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

O Always Encrypted também utiliza uma hierarquia de duas chaves. Uma coluna de dados sensíveis é encriptada por uma chave de encriptação AES de 256 colunas (CEK), que é encriptada 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.

• Roda tanto o CEK como o CMK.

• 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. Planeie as rotações do CEK em conformidade com isso.

• A rotação CMK não interfere com o desempenho da base 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 a sua organização e a base de dados SQL geralmente é encaminhado pela rede pública. No entanto, pode otimizar este caminho e torná-lo mais seguro usando o Azure ExpressRoute. O ExpressRoute estende a sua rede corporativa para a plataforma Azure através de uma ligação privada, contornando 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 planeia transferir uma quantidade significativa de dados entre a sua organização e o Azure, usar o ExpressRoute pode trazer benefícios em termos de custo. Você pode escolher entre três modelos de conectividade diferentes para a conexão de sua organização com o Azure:

• Colocação de Exchange na Nuvem
• Qualquer-para-qualquer
• Ponto a Ponto

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 pode configurar a conectividade entre regiões usando o ExpressRoute. Para obter uma lista de provedores de conectividade de Rota Expressa, consulte Parceiros de Rota Expressa e locais de emparelhamento. Os seguintes artigos descrevem o ExpressRoute com mais detalhe:

• Pré-requisitos
• Fluxos de trabalho

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

O Base de Dados SQL do Azure cumpre uma série de exigências regulatórias. Para consultar o conjunto mais recente de conformidades que o SQL Database cumpre, visite o Microsoft Trust Center e reveja as conformidades importantes para a 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 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 a sua base de dados para a Base de Dados SQL, monitorize a sua base de dados (por exemplo, verifique como é 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 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

Ao utilizar o Query Performance Insights, pode obter recomendações personalizadas para a carga de trabalho da sua base de dados, para que as suas aplicações possam continuar a funcionar a um nível ótimo. 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. Ao usar o SQL Database Advisor, pode implementar automaticamente recomendações de índice com base na sua carga de trabalho. Esta funcionalidade chama-se Auto-Tuning. 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

O SQL Database fornece recomendações de segurança acionáveis para o ajudar a proteger os seus dados. Também oferece deteção de ameaças para identificar e investigar atividades suspeitas na base de dados que possam representar uma ameaça potencial para a base de dados. A avaliação de vulnerabilidades é um serviço de análise e elaboração de relatórios de bases de dados que pode utilizar para monitorizar, em larga escala, o estado de segurança das suas bases de dados e identificar riscos de segurança e desvios em relação a uma base de referência de segurança que define. Após cada análise, fornece uma lista personalizada de passos acionáveis e scripts de remediação, juntamente com um relatório de avaliação que pode ajudar a cumprir os requisitos de conformidade.

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

Otimização de custos

A plataforma SQL do Azure analisa o histórico de utilização entre as bases de dados de 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 construir recomendações acionáveis.

Você pode receber notificações de banner em seu servidor SQL do Azure de recomendações de custo. Para mais informações, consulte Elastic pools ajudam-no a gerir e escalar múltiplas bases de dados no Base de Dados SQL do Azure e a Planear e a gerir custos para o Base de Dados SQL do Azure.

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

Pode monitorizar o desempenho e a utilização de recursos na base de dados SQL utilizando 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:

• Monitorar cargas de trabalho SQL do Azure com o monitor de bases de dados (visualização)
• Guia de início rápido: criar um observador para monitorar o SQL do Azure (visualização)
• Criar e configurar um observador (visualização)
• Coleta de dados e conjuntos de dados do monitor de banco de dados (pré-visualização)
• Analisar dados de monitoramento do inspetor de banco de dados (visualização)
• Perguntas frequentes do observador de banco de dados

portal do Azure

O portal Azure mostra a utilização de uma base de dados quando seleciona a base 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 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. Estes alertas permitem-lhe responder a condições de recurso com um email, escrever num endpoint HTTPS/HTTP ou realizar uma ação. Para mais informações, consulte Criar alertas para Base de Dados SQL do Azure usando o portal 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?

A maioria das técnicas de resolução de problemas que usa para diagnosticar problemas de consulta e desempenho de bases de dados são as mesmas que no SQL Server local. O Base de Dados SQL do Azure utiliza o mesmo SQL Database Engine. No entanto, as funcionalidades do Azure ajudam-no a resolver problemas e diagnosticar problemas de desempenho ainda mais facilmente. Também pode realizar algumas destas ações corretivas em seu nome e, em alguns casos, corrigi-las proativamente de forma automática.

A sua abordagem para resolver problemas de desempenho pode beneficiar significativamente da utilização de funcionalidades inteligentes como o Query Performance Insight (QPI) e o Database Advisor. A diferença na metodologia é que já não precisa de efetuar o trabalho manual de apurar os detalhes essenciais que podem ajudar a diagnosticar o problema em causa. A plataforma faz o trabalho duro para você. Um exemplo desse trabalho é o QPI. Ao usar QPI, pode aprofundar até ao nível da consulta e analisar as tendências históricas para perceber quando exatamente a consulta regrediu. O Consultor de Bases de Dados dá-lhe recomendações sobre coisas que podem ajudar a melhorar o seu desempenho geral em geral, como índices em falta, eliminação de índices, parametrização das suas consultas e mais.

Na resolução de problemas de desempenho, é importante identificar se é apenas a aplicação ou a base de dados a afetar o desempenho da sua 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, a sua aplicação é prejudicada porque há muitos pedidos curtos de um lado para o outro ("chatty") entre a aplicação e o servidor. Numa rede congestionada, estas viagens de ida e volta acumulam-se 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 notar uma degradação no desempenho global da sua base de dados, pode monitorizar as vistas de gestão dinâmica sys.dm_db_resource_stats e sys.resource_stats para compreender 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 um conjunto abrangente de recomendações para afinar problemas de desempenho, consulte Tune your database.

Como posso garantir que estou a usar o nível 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 notar que as suas bases de dados estão consistentemente a correr com alta utilização, considere escalar para um tamanho de computação superior. Da mesma forma, se não usares tanto os recursos durante as horas de ponta, considera reduzir a escala a partir do tamanho atual de computação. Pode considerar usar o Automatização do Azure para escalar as suas bases de dados SQL de acordo com um calendário.

Se tiver um padrão de aplicação SaaS ou um cenário de consolidação de bases de dados, considere usar um pool elástico para otimização de custos. Um pool elástico é uma excelente forma de consolidar bases de dados e otimizar custos. Para mais informações sobre a gestão de múltiplas bases de dados utilizando um pool elástico, consulte Gerir pools e bases 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. O serviço utiliza estas técnicas incorporadas quando necessário. Se houver problemas, a base de dados SQL resolve-os proativamente. Como camada extra de proteção, pode optar por testar a restauração de cópias de segurança e realizar verificações de integridade. Para mais informações, consulte Data Integrity in Base de Dados SQL do Azure.

A reparação automática de páginas é usada para corrigir páginas corrompidas ou com problemas de integridade dos dados. A CHECKSUM definição verifica sempre a integridade das páginas da base 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 posso exportar e importar dados como ficheiros BACPAC a partir da base 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: Também pode importar dados como ficheiro BACPAC para a sua base de dados no Base de Dados SQL do Azure usando o portal Azure:

  

Como sincronizo dados entre o Banco de dados SQL e o SQL Server?

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

Conteúdo relacionado

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