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

Mover do ambiente autogerenciado autocontrolado tradicional para um ambiente PaaS pode parecer um pouco difícil primeiro. Como desenvolvedor de aplicativos ou um DBA, você deseja saber os principais recursos da plataforma que ajudam a manter seu aplicativo disponível, com bom desempenho, seguro e flexível – sempre. Este artigo visa fazer exatamente isso. O artigo organiza sucintamente os recursos e conta com algumas diretrizes sobre como usar melhor os principais recursos do Banco de Dados SQL do Azure com bancos de dados individuais e em pool para gerenciar e fazer a manutenção de seu aplicativo em execução com eficiência e obter os melhores resultados na nuvem. O público-alvo típico para este artigo seria aqueles que:

• Esteja avaliando a migração de seu(s) aplicativo(s) para o Banco de Dados SQL do Azure – Modernizando seu(s) aplicativo(s).
• Estão no processo de migração de seus aplicativos – cenário de migração em andamento.
• Recentemente concluíram a migração para o Banco de Dados SQL do Azure – DBA novo na nuvem.

Este artigo discute algumas das principais características do Banco de Dados SQL do Azure como uma plataforma da qual você pode se beneficiar prontamente ao trabalhar com bancos de dados individuais e em pools elásticos. são eles:

• Monitorar bancos de dados usando 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

Observação

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

Monitorar bancos de dados usando o Portal do Azure

No portal do Azure, é possível monitorar o uso de um banco de dados individual selecionando-o e clicando no gráfico Monitoramento. Isso abre uma janela Métrica que pode ser alterada clicando no botão Editar gráfico. Adicione as seguintes métricas:

• Percentual de CPU
• Porcentagem de DTU
• Porcentagem de E/S de dados
• Percentual de tamanho do banco de dados

Depois de adicionar essas métricas, você pode continuar a visualizá-las no gráfico Monitoramento com mais informações na janela Métrica. Todas as quatro métricas mostram o percentual médio de utilização relativo à DTU do seu banco de dados. Consulte os artigos Modelo de compra baseado em DTU e Modelo de compra baseado em vCore para obter mais informações sobre as camadas de serviço.

Você também 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ê tem a opção de alerta se a métrica exceder um limite determinado ou se ficar abaixo de um limite determinado.

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. Suponha que você está usando um banco de dados Standard S2 e todas as métricas de desempenho mostram que o banco de dados em média não usa mais de 10% a qualquer momento. É provável que o banco de dados funcione bem em Standard S1. 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)

Capacidades de continuidade de negócios e recuperação de desastres permitem continuar seu negócio, como de costume, em caso de 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 fazer para criar e gerenciar backups no Banco de Dados SQL?

Você não cria backups no Banco de Dados SQL do Azure porque não precisa. O Banco de Dados SQL faz backup de bancos de dados automaticamente, para que você não tenha que se preocupar com agendamento, realização e gerenciamento de backups. A plataforma faz um backup completo toda semana, um backup diferencial que backup em intervalos de algumas horas e um backup de log a cada 5 minutos para garantir que a recuperação de desastres seja eficiente e a mínimo de perda de dados. O primeiro backup completo acontece assim que você criar um banco de dados. Esses backups ficam disponíveis por determinado período chamado "período de retenção" e varia de acordo com a camada de serviço escolhida. O Banco de Dados SQL fornece a capacidade de restaurar em qualquer ponto no tempo nessa retenção usando Recuperação de ponto no tempo (PITR).

Camada de serviço	Período de retenção em dias
Basic	7
Standard	35
Premium	35

Além disso, o recurso Retenção de Longo Prazo (LTR) permite que você mantenha seus arquivos de backup por um período mais longo especificamente, por até 10 anos, e faça a restauração desses backups em qualquer ponto nesse período. Além disso, os backups de banco de dados são mantidos em um armazenamento replicado geograficamente para garantir a resiliência de uma catástrofe regional. Você também pode restaurar esses backups em qualquer região do Azure em qualquer momento dentro do período de retenção. Confira Visão geral da continuidade dos negócios.

Como fazer para garantir a continuidade no caso de um desastre no nível do 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. O RPO (Objetivo de Ponto de Recuperação) para a restauração geográfica geralmente é de < 1 hora e o ERT (Tempo Estimado de Recuperação) é de alguns minutos a horas.

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 fornecem uma maneira conveniente de 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, confira Grupos de failover.

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 é muito útil para reduzir a latência para 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 de desastres podem ser feitos com apenas alguns cliques 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 saber mais, confira: Introdução à recuperação de desastre no Banco de Dados SQL do Azure 101.

Segurança e conformidade

O Banco de Dados SQL leva a segurança e a privacidade muito a sério. A segurança no Banco de Dados SQL do Microsoft Azure está disponível no nível do banco de dados e no nível da plataforma e é melhor compreendida quando categorizada em várias camadas. Em cada camada, você tem que controlar e fornecer segurança ideal para seu aplicativo. As camadas são:

• Identidade e autenticação (autenticação do SQL e autenticação com o Microsoft Entra ID (anteriormente Azure Active Directory).
• Atividade de monitoramento (Auditoria e detecção de ameaças).
• Proteção de dados reais (Transparent Data Encryption [TDE] e Always Encrypted [AE]).
• Controlando o acesso a dados confidenciais e privilegiados (Segurança em nível de linha e Máscara de Dados Dinâmicos do Banco de Dados SQL).

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 para o Banco de Dados SQL, como a Auditoria e a Transparent Data Encryption [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ários 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. Com ele, é possível fornecer um acesso de SSO (logon único) de forma bastante conveniente para toda a equipe de sua organização. Isso significa que as credenciais são compartilhadas entre todos 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.

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

Como fazer para 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 VNet
• IPs Reservados

Firewall

Um firewall impede o acesso de uma entidade externa ao seu servidor, permitindo somente entidades específicas. Por padrão, todas as conexões e bancos de dados dentro do servidor são rejeitadas, exceto (opcionalmente) as conexões de outros Serviços do Azure. Com uma regra de firewall, você pode abrir o acesso ao seu servidor somente para entidades (por exemplo, um computador de desenvolvedor) que você aprovar, concedendo permissão ao endereço IP do 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 saber mais sobre como configurar uma regra de firewall no nível do servidor e do banco de dados, confira: 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 este servidor", o que significa que todas as Máquinas Virtuais do Azure podem tentar se conectar ao banco de dados. Essas tentativas ainda precisam ser autenticadas. Se não quiser que seu banco de dados esteja acessível para nenhum IP do Azure, desabilite a opção "Permitir que os serviços e recursos do Azure acessem este servidor". Além disso, você pode configurar Pontos de Extremidade de Serviço VNET.

Pontos de extremidade de serviço (SE) permitem que você exponha seus recursos essenciais do Azure apenas para a sua própria rede virtual privada no Azure. Fazendo isso, você essencialmente 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 SE você, obtém um roteamento de pacotes com tunelamento 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 pontos de extremidade de serviço, você pode otimizar isso desde o fluxo de pacotes diretamente de sua rede virtual para o serviço de 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 eu me conecto ao Banco de Dados SQL

Porta 1433. O Banco de Dados SQL se comunica por essa porta. 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 eu monitoro e controlo a atividade no meu servidor e banco de dados no Banco de Dados SQL

Auditoria do Banco de Dados SQL

Com o Banco de Dados SQL, você pode ativar ON Auditing para controlar eventos de banco de dados. A Auditoria do Banco de Dados SQL registra eventos de banco de dados e grava-os em um arquivo de log de auditoria em sua Conta de Armazenamento do Microsoft Azure. A auditoria é especialmente útil se você pretende obter insights sobre possíveis violações de segurança e política, manter a conformidade regulatória etc. Com ela, é possível definir e configurar determinadas categorias de eventos que você imagina que precisam de auditoria e, com base nisso, você pode obter relatórios pré-configurados e um painel para ter uma visão geral dos eventos que ocorrem no banco de dados. Você pode aplicar essas políticas de auditoria no nível do banco de dados ou no nível do servidor. Um guia sobre como ativar a auditoria para o servidor/banco de dados, consulte: Habilitar a auditoria de Banco de Dados SQL do Microsoft Azure.

Detecção de ameaças

Com a detecção de ameaças, você tem a capacidade de agir facilmente sobre violações de segurança ou política descobertas por 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 detecção de SQL Injection. SQL Injection é uma tentativa de alterar ou comprometer os dados e uma maneira muito comum de ataque a um aplicativo de banco de dados em geral. A detecção de ameaças é executada em vários conjuntos de algoritmos que detectam possíveis vulnerabilidades e ataques de injeção de SQL, bem como padrões de acesso anormais do banco de dados (como o acesso de um local fora do comum ou por uma entidade desconhecida). 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, confira: Habilitar a detecção de ameaças.

Como fazer para 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:

• Os dados que estão em repouso nos arquivos de dados e log
• Os dados que estão em andamento

No Banco de Dados SQL, por padrão, os dados em repouso nos arquivos de dados e de log no subsistema de armazenamento são completamente e sempre criptografados por meio de Transparent Data Encryption [TDE]. Seus backups também são criptografados. Com TDE, não é necessária nenhuma alteração no lado do aplicativo que está acessando esses dados. A criptografia e descriptografia ocorrem de modo transparente; por isso o nome. Para proteger dados confidenciais em trânsito e em repouso, o Banco de Dados SQL fornece um recurso chamado Always Encrypted (AE). O AE é uma forma de criptografia no lado do cliente que criptografa as colunas confidenciais no banco de dados (para que fiquem em texto cifrado 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 AE criptografa colunas confidenciais na tabela de ponta a ponta, de clientes não autorizados para o disco físico. O AE dá suporte a comparações de igualdade atualmente, para que os DBAs possam continuar a consultar colunas criptografadas como parte dos 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.

Características	Always Encrypted	Transparent Data Encryption
Expansão de criptografia	Ponta a ponta	Dados em repouso
O servidor pode acessar dados confidenciais	Não	Sim, desde que a criptografia seja para os dados em repouso
Operações de T-SQL permitidas	Comparação de igualdade	Toda a área de superfície do T-SQL está disponível
Alterações de aplicativo necessárias para usar o recurso	Minimal	Muito Mínimo
Granularidade de criptografia	Nível de coluna	Nível de banco de dados

Como posso limitar o acesso a dados confidenciais em meu banco de dados

Cada aplicativo tem uma determinado quantidade de dados confidenciais no banco de dados que precisam ser protegidos de ficarem visíveis para todos. Uma certa equipe na organização precisa ver esses dados, porém outras não devem conseguir vê-los. Um exemplo é os salários de funcionários. Um gerente precisará ter acesso às informações de salário dos subordinados diretos dele. No entanto, os membros individuais da equipe não devem ter acesso às informações de salário dos colegas. Outro cenário é os desenvolvedores de dados que podem interagir com dados confidenciais durante as fases de desenvolvimento ou teste, por exemplo, CPFs de clientes. Novamente, essas informações não precisam ser expostas ao desenvolvedor. Nesses casos, dados confidenciais precisam ser mascarados ou não serem expostos de forma alguma. O Banco de Dados SQL oferece duas abordagens para impedir que usuários não autorizados possam visualizar dados confidenciais:

A Máscara de Dados Dinâmicos é um recurso de mascaramento de dados que permite que você limite a exposição de dados confidenciais mascarando-os para usuários sem privilégios na camada de aplicativo. Defina uma regra de mascaramento que pode criar um padrão de mascaramento (por exemplo, mostrar apenas os últimos quatro dígitos de uma identificação nacional, CPF: XXX-XXX-000-0, e marcar a maior parte dele como X) 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 que você controle o acesso no nível de 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 fazer para gerenciar chaves de criptografia na nuvem?

Há opções de gerenciamento de chaves para Always Encrypted (criptografia no 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.

Transparent Data Encryption (TDE)

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 pela plataforma – Banco de Dados SQL.
• Ou por você usando o Azure Key Vault como o repositório de chaves.

Por padrão, a chave mestra para Transparent Data Encryption é gerenciada pelo serviço Banco de Dados SQL para sua conveniência. Se sua organização deseja ter controle sobre a chave mestra, há uma opção para usar o Azure Key Vault como o 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.

Always Encrypted

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 de armazenamento de chaves para as chaves mestras de coluna no Always Encrypted

Como otimizar e proteger o tráfego entre a 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 seria é roteado pela rede pública. No entanto, se optar por otimizar esse caminho e torná-lo mais seguro, você poderá analisar o Azure ExpressRoute. O ExpressRoute essencialmente permite estender sua rede corporativa na plataforma 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 resulta em menores latências de rede e muito mais rapidez do que normalmente conseguiria 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:

• Co-posicionamento do Exchange de Nuvem
• De qualquer ponto a qualquer ponto
• Ponto a ponto

O ExpressRoute permite aumentar em até duas vezes o limite da largura de banda adquirida sem custos adicionais. Também é possível configurar conectividade entre regiões usando o ExpressRoute. Para ver uma lista de provedores de conectividade do ExpressRoute, confira: Locais de parceiros e emparelhamento do ExpressRoute. 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 os requisitos regulatórios? Como isso ajuda na conformidade da minha organização?

O Banco de Dados SQL cumpre várias regras de conformidade regulatória. Para ver o último conjunto de conformidades atendido pelo Banco de Dados SQL, visite o Microsoft Trust Center e faça uma busca detalhada das conformidades que são importantes para sua organização, a fim de saber se o Banco de Dados SQL está incluído nos serviços do Azure em conformidade. É importante observar que, embora o Banco de Dados SQL possa ser certificado como um serviço em conformidade, ele ajuda na conformidade do serviço da sua organização, mas não garante essa conformidade automaticamente.

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

Depois que você migrar seu banco de dados para o Banco de Dados SQL, o ideal será monitorá-lo (por exemplo, verificar como a utilização de recursos está ou fazer verificações de DBCC) e executar uma manutenção regular (por exemplo, recriar ou reorganizar índices, estatísticas etc.). Felizmente, o Banco de Dados SQL é inteligente no sentido de que ele usa as tendências históricas e métricas e estatísticas registradas de forma proativa ajudá-lo a monitorar e fazer a manutenção do banco de dados, para que seu aplicativo seja executado de forma 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 gerenciamento de otimização.
• Otimização de segurança.
• Custo da otimização.

Monitoramento e otimização de desempenho

Com a Análise de Desempenho de Consultas, é possível obter recomendações personalizadas para a carga de trabalho de banco de dados para que os aplicativos possam continuar em execução no nível ideal - sempre. 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 do Banco de Dados SQL, é possível implementar automaticamente as recomendações de índice com base na 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 scripts de correção e etapas acionáveis são fornecidos, bem como um relatório de avaliação que pode ser usado para ajudar a alcançar os 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 normalmente leva duas semanas para analisar e criar recomendações viáveis. O pool elástico é uma dessas opções. A recomendação é exibida no portal como um banner:

Você também pode ver essa análise na seção "Assistente":

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

No Banco de Dados SQL, você pode aproveitar as informações inteligentes da plataforma para monitorar o desempenho e ajustar adequadamente. 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:

Portal do Azure

O portal do Azure exibe a utilização de um banco de dados selecionando o banco de dados e clicando no 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.

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 rapidamente as PRINCIPAIS 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.

Análise de SQL do Azure (versão prévia) nos logs do Azure Monitor

Os logs do Azure Monitor permitem coletar e visualizar as principais métricas de desempenho do Banco de Dados SQL do Azure e são compatíveis com até 150 mil bancos de dados e 5 mil pools elásticos do SQL por workspace. Você pode usá-lo para monitorar e receber notificações. Você pode monitorar métricas do Banco de Dados SQL e de pool elástico em várias assinaturas do Azure e pools elásticos, e isso pode ser usado para identificar problemas em cada camada da pilha de um aplicativo.

Estou observando problemas de desempenho: como minha metodologia de solução de problemas do Banco de Dados SQL difere da do SQL Server?

Uma parte importante das técnicas de solução de problemas que você deseja usar para diagnosticar a consulta e problemas de desempenho do banco de dados permanecem as mesmas. Afinal, o mesmo mecanismo de banco de dados aciona a nuvem. No entanto, a plataforma Banco de Dados SQL do Azure tem uma 'inteligência' interna. Ela pode ajudá-lo a solucionar e diagnosticar problemas de desempenho ainda mais facilmente. Ela pode também executar algumas dessas ações corretivas em seu nome e, em alguns casos, proativamente corrigi-los – automaticamente.

Sua abordagem para solucionar problemas de desempenho pode se beneficiar bastante usando recursos inteligentes como Análise de Desempenho de Consultas (QPI) e Assistente do Banco de Dados em conjunto, portanto a diferença na metodologia difere nesse aspecto: você não precisa mais fazer o trabalho manual de replicar 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 Assistente do Banco de Dados fornece recomendações sobre coisas que podem ajudá-lo a melhorar o desempenho geral em geral, como: índices ausentes, índices descartados, 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 de conversação que é sensível a latência de rede. Nesse caso, o aplicativo é prejudicado porque deve haver muitas solicitações curtas indo e vindo ("tagarelas") entre o aplicativo e o servidor e em uma rede congestionada, essas idas e voltas se acumulam rapidamente. Para melhorar o desempenho nesse caso, você pode usar Consultas em lote. Usar lotes ajuda muito porque agora as suas solicitações são processadas em um lote; ajudando, assim, a reduzir a latência de ida e volta e a melhorar o desempenho do seu 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 pode estar sendo afetado porque o banco de dados está sem recursos. Talvez seja necessário alterar o tamanho da computação e/ou a camada de serviço com base nas demandas de carga de trabalho crescentes e decrescentes.

Para um conjunto abrangente de recomendações de ajuste dos problemas de desempenho, confira: Ajustar seu desempenho.

Como fazer para garantir que estou usando o tamanho da computação e a camada de serviço apropriados?

O Banco de Dados SQL oferece várias camadas de serviço: Básica, Standard e Premium. Cada camada de serviço garante um desempenho previsível associado a essa camada de serviço. Dependendo de sua carga de trabalho, você pode ter intermitência de atividade em que a utilização de recursos pode atingir o limite do tamanho da computação em que você está. Nesses casos, é útil primeiro iniciar avaliando se qualquer ajuste pode ajudá-lo (por exemplo, adicionar ou alterar um índice etc.). Se ainda tiver problemas com o limite, considere a possibilidade de passar para um tamanho da computação ou nível de serviço superior.

Camada de serviço	Cenários de caso de uso comuns
Basic	Aplicativos com muitos usuários e um banco de dados que não tem requisitos de alta simultaneidade, escala e desempenho.
Standard	Aplicativos com requisitos de simultaneidade considerável, escala e desempenho juntamente com baixas a médias demandas de E/S.
Premium	Aplicativos com muitos usuários simultâneos, alto consumo de CPU/memória e altas demandas de E/S. Aplicativos confidenciais de alta simultaneidade, alta taxa de transferência e latência podem aproveitar o nível Premium.

Para garantir que você esteja usando o tamanho de computação certo, monitore o consumo de recursos de consulta e de banco de dados usando uma das maneiras mencionadas acima em "Como fazer para monitorar o desempenho e a utilização de recursos no Banco de Dados SQL". Se perceber que suas consultas/bancos de dados frequentemente têm escassez de CPU/memória etc., considere passar para um tamanho da computação maior. Da mesma forma, se você observar que, mesmo durante os horários de pico, não parece que está usando tanto os recursos, considere a possibilidade de reduzir o tamanho da computação atual.

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 ler mais sobre o gerenciamento de vários bancos de dados usando o pool elástico, confira: Gerenciar pools e bancos de dados.

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

O Banco de Dados SQL usa algumas técnicas inteligentes que permitem manipular determinadas classes de corrupção de dados automaticamente e sem qualquer perda de dados. Essas técnicas são incorporadas ao serviço e são usadas por ele quando necessário. Regularmente, seus backups de banco de dados no serviço são testados restaurando-os e executando DBCC CHECKDB nele. Se houver problemas, o Banco de Dados SQL trata deles proativamente. O reparo automático de página é realizado para corrigir páginas que estejam corrompidas ou que tenham problemas de integridade dos dados. As páginas de banco de dados sempre são verificadas com a configuração CHECKSUM padrão, que verifica a integridade da página. O Banco de Dados SQL monitora e revisa proativamente a integridade de dados do banco de dados e, se ocorrerem problemas, trata deles com a mais alta prioridade. Além disso, você pode opcionalmente executar suas próprias verificações de integridade à vontade. Para saber mais, consulte Integridade dos dados no Banco de Dados SQL

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

Como 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 SQL do Azure como um arquivo BACPAC no portal do Azure.

  

• Importar: você também pode importar dados como um arquivo BACPAC para o 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 a sincronizar dados bidirecionalmente entre vários bancos de dados locais do SQL Server e do 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ção – Com replicação de transação, você pode sincronizar os dados de um banco de dados do SQL Server com o Banco de Dados SQL do Azure com a instância do SQL Server como editor e o Banco de Dados SQL do Azure como assinante. Por ora, apenas há suporte apenas para esta configuração. Para saber mais sobre como migrar os dados de um banco de dados do SQL Server para o SQL do Azure com um tempo de inatividade mínimo, confira: Usar a replicação de transação.

Próximas etapas

Conheça o Banco de Dados SQL.