Ajustar aplicativos e bancos de dados para desempenho no Banco de Dados SQL do Azure

Aplica-se a:Banco de Dados SQL do AzureBanco de Dados SQL no Fabric

• Base de Dados SQL do Azure
• Instância Gerida do SQL do Azure

Depois de identificar um problema de desempenho que você está enfrentando com o Banco de Dados SQL do Azure ou o Banco de Dados SQL de Malha, este artigo foi criado para ajudá-lo a:

• Ajuste seu aplicativo e aplique algumas práticas recomendadas que podem melhorar o desempenho.
• Ajuste o banco de dados alterando índices e consultas para trabalhar com dados de forma mais eficiente.

Este artigo pressupõe que você já tenha trabalhado com as recomendações do assessor de banco de dados e as recomendações de ajuste automático , se aplicável. Ele também pressupõe que tenha revisado a visão geral sobre monitorização e ajuste, monitorizar o desempenho usando o Repositório de Consultase artigos relacionados à solução de problemas de desempenho. Além disso, este artigo pressupõe que você não tenha um problema de desempenho relacionado à utilização de recursos da CPU que pode ser resolvido aumentando o tamanho da computação ou a camada de serviço para fornecer mais recursos ao banco de dados.

Observação

Para obter orientações semelhantes na Instância Gerida SQL do Azure, consulte Ajustar aplicações e bases de dados para desempenho na Instância Gerida SQL do Azure.

Ajuste seu aplicativo

No SQL Server local tradicional, o processo de planejamento de capacidade inicial geralmente é separado do processo de execução de um aplicativo em produção. As licenças de hardware e produto são compradas primeiro, e o ajuste de desempenho é feito depois. Quando você usa o Azure SQL, é uma boa ideia entrelaçar o processo de execução de um aplicativo e ajustá-lo. Com o modelo de pagamento por capacidade sob demanda, você pode ajustar seu aplicativo para usar os recursos mínimos necessários agora, em vez de provisionar demais em hardware com base em suposições de planos de crescimento futuros para um aplicativo, que muitas vezes são incorretos.

Alguns clientes podem optar por não ajustar um aplicativo e, em vez disso, optar por provisionar recursos de hardware em excesso. Essa abordagem pode ser uma boa ideia se você não quiser alterar um aplicativo chave durante um período ocupado. Mas, ajustar um aplicativo pode minimizar os requisitos de recursos e reduzir as contas mensais.

Práticas recomendadas e antipadrões no design de aplicativos para o Banco de Dados SQL do Azure

Embora as camadas de serviço do Banco de Dados SQL do Azure sejam projetadas para melhorar a estabilidade e a previsibilidade do desempenho de um aplicativo, algumas práticas recomendadas podem ajudá-lo a ajustar seu aplicativo para aproveitar melhor os recursos em um tamanho de computação. Embora muitos aplicativos tenham ganhos significativos de desempenho simplesmente mudando para um tamanho de computação ou camada de serviço mais alto, alguns aplicativos precisam de ajuste adicional para se beneficiar de um nível mais alto de serviço. Para aumentar o desempenho, considere o ajuste adicional de aplicativos para aplicativos que tenham estas características:

• Aplicações que têm desempenho lento devido ao comportamento "comunicativo"

  As aplicações faladoras realizam operações excessivas de acesso a dados que são sensíveis à latência da rede. Talvez seja necessário modificar esses tipos de aplicativos para reduzir o número de operações de acesso a dados ao banco de dados. Por exemplo, você pode melhorar o desempenho do aplicativo usando técnicas como envio em lote de consultas ad hoc ou mover as consultas para procedimentos armazenados. Para mais informações, consulte 'Consultas em Lote'.

• Bancos de dados com uma carga de trabalho intensiva que não pode ser suportada por uma única máquina inteira

  Os bancos de dados que excedem os recursos do tamanho de computação Premium mais alto podem se beneficiar da expansão da carga de trabalho. Para obter mais informações, consulte de fragmentação entre bancos de dados e de particionamento funcional.

• Aplicativos que têm consultas subótimas

  Os aplicativos que têm consultas mal ajustadas podem não se beneficiar de um tamanho de computação mais alto. Isso inclui consultas que não têm uma cláusula WHERE, têm índices ausentes ou têm estatísticas desatualizadas. Esses aplicativos se beneficiam de técnicas padrão de ajuste de desempenho de consulta. Para obter mais informações, consulte Índices ausentes e Ajuste e sugestão de consulta.

• Aplicativos com design de acesso a dados abaixo do ideal

  Aplicações que têm problemas inerentes de simultaneidade de acesso a dados, como interbloqueios, podem não se beneficiar de uma maior capacidade computacional. Considere reduzir as viagens de ida e volta em relação ao banco de dados armazenando em cache dados no lado do cliente com o serviço de Cache do Azure ou outra tecnologia de cache. Consulte a cache da camada de aplicação .

  Para evitar que os impasses voltem a ocorrer no Banco de Dados SQL do Azure, consulte Analisar e evitar impasses no Banco de Dados SQL do Azure e no Banco de Dados SQL de Malha.

Ajuste seu banco de dados

Nesta seção, examinamos algumas técnicas que você pode usar para ajustar o banco de dados para obter o melhor desempenho para seu aplicativo e executá-lo no menor tamanho de computação possível. Algumas dessas técnicas correspondem às práticas recomendadas de ajuste tradicionais do SQL Server, mas outras são específicas do Banco de Dados SQL do Azure. Em alguns casos, você pode examinar os recursos consumidos de um banco de dados para localizar áreas para ajustar e estender ainda mais as técnicas tradicionais do SQL Server para trabalhar no Banco de Dados SQL do Azure.

Identificar e adicionar índices ausentes

Um problema comum no desempenho do banco de dados OLTP está relacionado ao design do banco de dados físico. Muitas vezes, os esquemas de banco de dados são projetados e enviados sem testes em escala (seja em carga ou em volume de dados). Infelizmente, o desempenho de um plano de consulta pode ser aceitável em pequena escala, mas degradar substancialmente quando aplicado a volumes de dados em nível de produção. A fonte mais comum desse problema é a falta de índices apropriados para satisfazer filtros ou outras restrições em uma consulta. Muitas vezes, os índices ausentes manifestam-se como uma varredura de tabela quando uma busca de índice seria suficiente.

Neste exemplo, o plano de consulta selecionado usa uma verificação quando uma busca é suficiente:

DROP TABLE dbo.missingindex;
CREATE TABLE dbo.missingindex (col1 INT IDENTITY PRIMARY KEY, col2 INT);
DECLARE @a int = 0;
SET NOCOUNT ON;
BEGIN TRANSACTION
    WHILE @a < 20000
    BEGIN
        INSERT INTO dbo.missingindex(col2) VALUES (@a);
        SET @a += 1;
    END
    COMMIT TRANSACTION;
    GO
SELECT m1.col1
    FROM dbo.missingindex m1 INNER JOIN dbo.missingindex m2 ON(m1.col1=m2.col1)
    WHERE m1.col2 = 4;

O Banco de Dados SQL do Azure pode ajudá-lo a localizar e corrigir condições comuns de índice ausentes. Os DMVs incorporados ao Banco de Dados SQL do Azure examinam compilações de consulta nas quais um índice reduziria significativamente o custo estimado para executar uma consulta. Durante a execução da consulta, o mecanismo de banco de dados controla a frequência com que cada plano de consulta é executado e rastreia a lacuna estimada entre o plano de consulta em execução e o plano imaginado onde esse índice existia. Você pode usar esses DMVs para adivinhar rapidamente quais alterações no design do banco de dados físico podem melhorar o custo geral da carga de trabalho de um banco de dados e sua carga de trabalho real.

Você pode usar essa consulta para avaliar possíveis índices ausentes:

SELECT
   CONVERT (varchar, getdate(), 126) AS runtime
   , mig.index_group_handle
   , mid.index_handle
   , CONVERT (decimal (28,1), migs.avg_total_user_cost * migs.avg_user_impact *
        (migs.user_seeks + migs.user_scans)) AS improvement_measure
   , 'CREATE INDEX missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' +
        CONVERT (varchar, mid.index_handle) + ' ON ' + mid.statement + '
        (' + ISNULL (mid.equality_columns,'')
        + CASE WHEN mid.equality_columns IS NOT NULL
        AND mid.inequality_columns IS NOT NULL
        THEN ',' ELSE '' END + ISNULL (mid.inequality_columns, '') + ')'
        + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement
   , migs.*
   , mid.database_id
   , mid.[object_id]
FROM sys.dm_db_missing_index_groups AS mig
   INNER JOIN sys.dm_db_missing_index_group_stats AS migs
      ON migs.group_handle = mig.index_group_handle
   INNER JOIN sys.dm_db_missing_index_details AS mid
      ON mig.index_handle = mid.index_handle
 ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC

Neste exemplo, a consulta resultou nesta sugestão:

CREATE INDEX missing_index_5006_5005 ON [dbo].[missingindex] ([col2])  

Depois de criada, essa mesma instrução SELECT seleciona um plano diferente, que usa uma busca em vez de uma verificação e, em seguida, executa o plano com mais eficiência:

A principal perceção é que a capacidade de E/S de um sistema de commodities compartilhado é mais limitada do que a de uma máquina de servidor dedicada. Há uma prioridade em minimizar E/S desnecessárias para tirar o máximo partido do sistema nos recursos de cada dimensão de computação nos diferentes níveis de serviço. As opções apropriadas de design de banco de dados físico podem melhorar significativamente a latência de consultas individuais, melhorar a taxa de transferência de solicitações simultâneas tratadas por unidade de escala e minimizar os custos necessários para satisfazer a consulta.

Para obter mais informações sobre como ajustar índices usando solicitações de índice ausentes, consulte Ajustar índices não clusterizados com sugestões de índice ausentes.

Ajuste e otimização de consultas

O otimizador de consulta no Banco de Dados SQL do Azure é semelhante ao otimizador de consulta tradicional do SQL Server. A maioria das práticas recomendadas para ajustar consultas e entender as limitações do modelo de raciocínio para o otimizador de consulta também se aplica ao Banco de Dados SQL do Azure. Se você ajustar consultas no Banco de Dados SQL do Azure, poderá obter o benefício adicional de reduzir as demandas agregadas de recursos. Seu aplicativo pode ser executado a um custo mais baixo do que um equivalente não ajustado porque pode ser executado em um tamanho de computação menor.

Um exemplo que é comum no SQL Server e que também se aplica ao Banco de Dados SQL do Azure é como o otimizador de consulta "deteta" parâmetros. Durante a compilação, o otimizador de consulta avalia o valor atual de um parâmetro para determinar se ele pode gerar um plano de consulta mais ideal. Embora essa estratégia muitas vezes possa levar a um plano de consulta que é significativamente mais rápido do que um plano compilado sem valores de parâmetros conhecidos, atualmente ela funciona de forma imperfeita no Banco de Dados SQL do Azure. (Um novo recurso de Desempenho de Consulta Inteligente introduzido com o SQL Server 2022 chamado Otimização do Plano de Sensibilidade a Parâmetros aborda o cenário em que um único plano armazenado em cache para uma consulta parametrizada não é ideal para todos os possíveis valores de parâmetros de entrada. Atualmente, a Otimização do Plano de Sensibilidade a Parâmetros não está disponível no Banco de Dados SQL do Azure.)

O mecanismo de banco de dados oferece suporte a dicas de consulta (diretivas) para que você possa especificar a intenção de forma mais deliberada e substituir o comportamento padrão da deteção de parâmetros. Você pode optar por usar dicas quando o comportamento padrão for imperfeito para uma carga de trabalho específica.

O próximo exemplo demonstra como o processador de consultas pode gerar um plano que não é ideal tanto para os requisitos de desempenho quanto de recursos. Este exemplo também mostra que, se você usar uma dica de consulta, poderá reduzir o tempo de execução da consulta e os requisitos de recursos para seu banco de dados:

DROP TABLE psptest1;
CREATE TABLE psptest1(col1 int primary key identity, col2 int, col3 binary(200));
DECLARE @a int = 0;
SET NOCOUNT ON;
BEGIN TRANSACTION
   WHILE @a < 20000
   BEGIN
     INSERT INTO psptest1(col2) values (1);
     INSERT INTO psptest1(col2) values (@a);
     SET @a += 1;
   END
   COMMIT TRANSACTION
   CREATE INDEX i1 on psptest1(col2);
GO

CREATE PROCEDURE psp1 (@param1 int)
   AS
   BEGIN
      INSERT INTO t1 SELECT * FROM psptest1
      WHERE col2 = @param1
      ORDER BY col2;
    END
    GO

CREATE PROCEDURE psp2 (@param2 int)
   AS
   BEGIN
      INSERT INTO t1 SELECT * FROM psptest1 WHERE col2 = @param2
      ORDER BY col2
      OPTION (OPTIMIZE FOR (@param2 UNKNOWN))
   END
   GO

CREATE TABLE t1 (col1 int primary key, col2 int, col3 binary(200));
GO

O código de instalação cria dados distorcidos (ou distribuídos irregularmente) na tabela t1. O plano de consulta ideal difere com base no parâmetro selecionado. Infelizmente, o comportamento de armazenamento em cache do plano nem sempre recompila a consulta com base no valor mais comum do parâmetro. Assim, é possível que um plano abaixo do ideal seja armazenado em cache e usado para muitos valores, mesmo quando um plano diferente pode ser uma escolha de plano melhor em média. Em seguida, o plano de consulta cria dois procedimentos armazenados que são idênticos, exceto que um tem uma dica de consulta especial.

-- Prime Procedure Cache with scan plan
EXEC psp1 @param1=1;
TRUNCATE TABLE t1;

-- Iterate multiple times to show the performance difference
DECLARE @i int = 0;
WHILE @i < 1000
   BEGIN
      EXEC psp1 @param1=2;
      TRUNCATE TABLE t1;
      SET @i += 1;
    END

Recomendamos que você aguarde pelo menos 10 minutos antes de começar a parte 2 do exemplo, para que os resultados sejam distintos nos dados de telemetria resultantes.

EXEC psp2 @param2=1;
TRUNCATE TABLE t1;

DECLARE @i int = 0;
    WHILE @i < 1000
    BEGIN
        EXEC psp2 @param2=2;
        TRUNCATE TABLE t1;
        SET @i += 1;
    END

Cada parte deste exemplo tenta executar uma instrução insert parametrizada 1.000 vezes (para gerar uma carga suficiente para usar como um conjunto de dados de teste). Quando executa procedimentos armazenados, o processador de consultas examina o valor do parâmetro que é passado para o procedimento durante sua primeira compilação (parâmetro "sniffing"). O processador armazena em cache o plano resultante e o usa para invocações posteriores, mesmo que o valor do parâmetro seja diferente. O plano ideal pode não ser usado em todos os casos. Às vezes, você precisa orientar o otimizador para escolher um plano que seja melhor para o caso médio em vez do caso específico de quando a consulta foi compilada pela primeira vez. Neste exemplo, o plano inicial gera um plano de "verificação" que lê todas as linhas para localizar cada valor que corresponde ao parâmetro:

Como executamos o procedimento usando o valor 1, o plano resultante foi ótimo para o valor 1 mas foi subótimo para todos os outros valores na tabela. O resultado provavelmente não é o que você gostaria se escolhesse cada plano aleatoriamente, porque o plano tem um desempenho mais lento e usa mais recursos.

Se você executar o teste com SET STATISTICS IO definido como ON, o trabalho de verificação lógica neste exemplo será feito nos bastidores. Você pode ver que há 1.148 leituras feitas pelo plano (o que é ineficiente, se o caso médio é retornar apenas uma linha):

A segunda parte do exemplo usa uma dica de consulta para dizer ao otimizador para usar um valor específico durante o processo de compilação. Nesse caso, ele força o processador de consultas a ignorar o valor que é passado como o parâmetro e, em vez disso, assumir UNKNOWN. Isto refere-se a um valor que tem a frequência média na tabela (ignorando a inclinação). O plano resultante é um plano baseado em busca que é mais rápido e usa menos recursos, em média, do que o plano na parte 1 deste exemplo:

Você pode ver o efeito na visão do sistema sys.resource_stats, que é específica do Banco de Dados SQL do Azure. Há um atraso desde o momento em que você executa o teste e quando os dados preenchem a tabela. Neste exemplo, a parte 1 foi executada durante a janela de tempo 22:25:00 e a parte 2 executada às 22:35:00. A janela de tempo anterior usou mais recursos nessa janela de tempo do que a posterior (devido a melhorias na eficiência do plano).

SELECT TOP 1000 *
FROM sys.resource_stats
WHERE database_name = 'resource1'
ORDER BY start_time DESC

Observação

Embora o volume neste exemplo seja intencionalmente pequeno, o efeito de parâmetros subótimos pode ser substancial, especialmente em bancos de dados maiores. A diferença, em casos extremos, pode ser entre segundos para casos rápidos e horas para casos lentos.

Você pode examinar sys.resource_stats para determinar se o recurso para um teste usa mais ou menos recursos do que outro teste. Ao comparar dados, separe o tempo dos testes para que eles não estejam na mesma janela de 5 minutos na visualização sys.resource_stats. O objetivo do exercício é minimizar a quantidade total de recursos utilizados, e não minimizar os recursos de pico. Geralmente, a otimização de um pedaço de código para latência também reduz o consumo de recursos. Certifique-se de que as alterações feitas em um aplicativo são necessárias e que as alterações não afetam negativamente a experiência do cliente para alguém que possa estar usando dicas de consulta no aplicativo.

Se uma carga de trabalho tiver um conjunto de consultas repetidas, geralmente faz sentido capturar e validar a otimização de suas opções de plano, pois ela direciona a unidade de tamanho mínimo de recurso necessária para hospedar o banco de dados. Depois de validá-los, volte a examinar ocasionalmente os planos para garantir que não se tenham degradado. Pode aprender mais sobre dicas de consulta (Transact-SQL).

Otimize a conectividade e o pool de conexões

Para reduzir a sobrecarga de criar conexões frequentes de aplicativos no Banco de Dados SQL do Azure, o pool de conexões está disponível em provedores de dados. O pool de conexões é habilitado em ADO.NET por padrão, por exemplo. O pool de conexões permite que um aplicativo reutilize conexões e minimize a sobrecarga de estabelecer novas.

O pool de conexões pode melhorar a taxa de transferência, reduzir a latência e melhorar o desempenho geral das cargas de trabalho do banco de dados. Tenha em mente estas práticas recomendadas:

• Configure as configurações do pool de conexões, como conexões máximas, tempos limite de conexão ou tempo de vida da conexão, com base nos requisitos de simultaneidade e latência da sua carga de trabalho. Para obter mais informações, consulte a documentação do provedor de dados.

  • ADO.NET gestão de conexões
  • agregação de conexões ODBC
  • Pool de conexões JDBC
  • agrupamento de conexões PHP

• As aplicações em nuvem devem implementar lógica de repetição para lidar de forma eficaz com falhas de conectividade transitórias. Saiba mais sobre como conceber lógica de repetição para erros transitórios.

• Monitore o desempenho da conexão do Banco de Dados SQL do Azure e o uso dos recursos para detetar gargalos, como excessivas conexões inativas ou limites de pool insuficientes, e ajustar as configurações em conformidade. Considere usar o observador de bases de dados ou o Azure Monitor .

Práticas recomendadas para arquiteturas de banco de dados muito grandes no Banco de Dados SQL do Azure

Antes do lançamento da camada de serviço Hyperscale para bancos de dados únicos no Banco de Dados SQL do Azure, os clientes podiam encontrar limites de capacidade para bancos de dados individuais. Embora pools elásticos Hyperscale ofereçam limites de armazenamento significativamente mais altos, pools elásticos e bases de dados em pool em outras camadas de serviço podem ainda estar sujeitas a essas limitações de capacidade de armazenamento nas camadas de serviço que não são de hiperescala.

As duas seções a seguir discutem duas opções para resolver problemas com bancos de dados muito grandes no Banco de Dados SQL do Azure quando você não pode usar a camada de serviço Hyperscale.

Observação

Os pools elásticos não estão disponíveis para a Instância Gerenciada do SQL do Azure, instâncias do SQL Server no local, SQL Server em VMs do Azure ou Azure Synapse Analytics.

Fragmentação entre bancos de dados

Como o Banco de Dados SQL do Azure é executado em hardware de mercadoria, os limites de capacidade para um banco de dados individual são menores do que para uma instalação tradicional do SQL Server local. Alguns clientes usam técnicas de fragmentação para distribuir operações de banco de dados por vários bancos de dados quando as operações não se encaixam dentro dos limites de um banco de dados individual no Banco de Dados SQL do Azure. A maioria dos clientes que usam técnicas de fragmentação no Banco de Dados SQL do Azure divide seus dados em uma única dimensão em vários bancos de dados. Para essa abordagem, você precisa entender que os aplicativos OLTP geralmente executam transações que se aplicam a apenas uma linha ou a um pequeno grupo de linhas no esquema.

Observação

O Banco de Dados SQL do Azure agora fornece uma biblioteca para ajudar com a fragmentação. Para obter mais informações, consulte Visão geral biblioteca cliente do Elastic Database.

Por exemplo, se um banco de dados tiver o nome do cliente, o pedido e os detalhes do pedido (como no banco de dados AdventureWorks), você poderá dividir esses dados em vários bancos de dados agrupando um cliente com as informações relacionadas ao pedido e aos detalhes do pedido. Pode garantir que os dados do cliente permanecem numa base de dados individual. O aplicativo dividiria diferentes clientes entre bancos de dados, distribuindo efetivamente a carga por vários bancos de dados. Com a fragmentação, os clientes não só podem evitar o limite máximo de tamanho do banco de dados, mas o Banco de Dados SQL do Azure também pode processar cargas de trabalho significativamente maiores do que os limites dos diferentes tamanhos de computação, desde que cada banco de dados individual se encaixe em seus limites de camada de serviço.

Embora a fragmentação de banco de dados não reduza a capacidade de recursos agregados de uma solução, ela é altamente eficaz no suporte a soluções muito grandes que estão espalhadas por vários bancos de dados. Cada banco de dados pode ser executado em um tamanho de computação diferente para suportar bancos de dados muito grandes e "eficazes" com altos requisitos de recursos.

Particionamento funcional

Os usuários geralmente combinam muitas funções em um banco de dados individual. Por exemplo, se um aplicativo tiver lógica para gerenciar o estoque de uma loja, esse banco de dados poderá ter lógica associada ao inventário, ao controle de ordens de compra, aos procedimentos armazenados e às exibições indexadas ou materializadas que gerenciam os relatórios de fim de mês. Essa técnica facilita a administração do banco de dados para operações como backup, mas também exige que você dimensione o hardware para lidar com o pico de carga em todas as funções de um aplicativo.

Se você usar uma arquitetura de expansão no Banco de Dados SQL do Azure, é uma boa ideia dividir diferentes funções de um aplicativo em bancos de dados diferentes. Se você usar essa técnica, cada aplicativo será dimensionado independentemente. À medida que um aplicativo se torna mais ocupado (e a carga no banco de dados aumenta), o administrador pode escolher tamanhos de computação independentes para cada função no aplicativo. No limite, com essa arquitetura, um aplicativo pode ser maior do que uma única máquina de mercadoria pode suportar, porque a carga é distribuída por várias máquinas.

Consultas em lote

Para aplicativos que acessam dados usando consultas ad hoc frequentes e de alto volume, uma quantidade substancial de tempo de resposta é gasta na comunicação de rede entre a camada de aplicativo e a camada de banco de dados. Mesmo quando o aplicativo e o banco de dados estão no mesmo data center, a latência de rede entre os dois pode ser ampliada por um grande número de operações de acesso a dados. Para reduzir as viagens de ida e volta da rede para as operações de acesso a dados, considere usar a opção de agrupar as consultas ad hoc em lote ou compilá-las como procedimentos armazenados. Se você agrupar as consultas ad hoc, poderá enviar várias consultas como um lote grande em uma única viagem ao banco de dados. Se você compilar consultas ad hoc em um procedimento armazenado, poderá obter o mesmo resultado como se as colocasse em lote. O uso de um procedimento armazenado também oferece o benefício de aumentar as chances de armazenar em cache os planos de consulta no banco de dados para que você possa usar o procedimento armazenado novamente.

Alguns aplicativos são intensivos em gravação. Às vezes, pode-se reduzir a carga total de E/S em um banco de dados considerando como agrupar as escritas. Muitas vezes, isso é tão simples quanto usar transações explícitas em vez de transações de confirmação automática em procedimentos armazenados e lotes ad hoc. Para obter uma avaliação de diferentes técnicas que você pode usar, consulte Técnicas de envio em lote para aplicativos de banco de dados no Azure. Experimente sua própria carga de trabalho para encontrar o modelo certo para processamento em lote. Certifique-se de entender que um modelo pode ter garantias de consistência transacional ligeiramente diferentes. Encontrar a carga de trabalho certa que minimiza o uso de recursos requer encontrar a combinação certa de consistência e compensações de desempenho.

Cache da camada de aplicação

Alguns aplicativos de banco de dados têm cargas de trabalho de leitura pesada. As camadas de cache podem reduzir a carga no banco de dados e podem potencialmente reduzir o tamanho de computação necessário para dar suporte a um banco de dados usando o Banco de Dados SQL do Azure. Com o Cache do Azure para Redis, se tiver uma intensa carga de leitura, pode ler os dados uma vez (ou talvez uma vez por máquina da camada de aplicação, dependendo da configuração) e, em seguida, armazenar esses dados fora do seu banco de dados. Essa é uma maneira de reduzir a carga do banco de dados (CPU e E/S de leitura), mas há um efeito na consistência transacional porque os dados que estão sendo lidos do cache podem estar fora de sincronia com os dados no banco de dados. Embora em muitos aplicativos algum nível de inconsistência seja aceitável, isso não é verdade para todas as cargas de trabalho. Você deve entender completamente todos os requisitos do aplicativo antes de implementar uma estratégia de cache da camada de aplicativo.

Obtenha dicas de configuração e design

Se você usar o Banco de Dados SQL do Azure, poderá executar um script de T-SQL de código aberto para melhorar a configuração e o design do banco de dados no Banco de Dados SQL do Azure. O script analisa seu banco de dados sob demanda e fornece dicas para melhorar o desempenho e a integridade do banco de dados. Algumas dicas sugerem alterações operacionais e de configuração com base nas práticas recomendadas, enquanto outras recomendam alterações de design adequadas à sua carga de trabalho, como habilitar recursos avançados do mecanismo de banco de dados.

Para saber mais sobre o script e começar, visite a página wiki Dicas do Azure SQL .

Para manter-se atualizado com os recursos e atualizações mais recentes do Banco de Dados SQL do Azure, consulte O que há de novo no Banco de Dados SQL do Azure?

Conteúdo relacionado

• Monitor do Banco de Dados SQL do Azure
• Query Performance Insight para o Banco de Dados SQL do Azure
• Monitoramento de desempenho usando exibições de gerenciamento dinâmico
• Observador de banco de dados
• Diagnosticar e solucionar problemas de alta CPU no Banco de Dados SQL do Azure
• Ajuste índices não agrupados com sugestões de índice ausentes
• Vídeo: Boas práticas de carregamento de dados na Base de Dados SQL do Azure