Otimizar aplicações e bases de dados para desempenho na Base de Dados SQL do Azure
Aplica-se a:
Banco de Dados SQL do Azure
Depois de identificar um problema de desempenho que você está enfrentando com o Banco de Dados SQL do Azure, 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 consultor de banco de dados do Banco de Dados SQL do Azure e as recomendações de ajuste automático, se aplicável. Ele também pressupõe que você tenha revisado a visão geral de monitoramento e ajuste, Monitorar o desempenho usando o Repositório de Consultas e 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.
Nota
Para obter orientações semelhantes na Instância Gerenciada SQL do Azure, consulte Ajustar aplicativos e bancos de dados para desempenho na Instância Gerenciada 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:
Aplicativos com desempenho lento devido ao comportamento "tagarela"
Os aplicativos tagarelas fazem 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 obter 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 Fragmentação entre bancos de dados e Particionamento funcional.
Aplicativos com consultas abaixo do ideal
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
Aplicativos que têm problemas inerentes de simultaneidade de acesso a dados, por exemplo, deadlocking, podem não se beneficiar de um tamanho de computação mais alto. 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 Cache da camada de aplicativo.
Para evitar que os deadlocks voltem a ocorrer no Banco de Dados SQL do Azure, consulte Analisar e evitar deadlocks no Banco de Dados SQL do Azure.
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 em falta
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-se substancialmente em volumes de dados no 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 se manifestam como uma varredura de tabela quando uma busca de índice pode ser 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á um prêmio em minimizar E/S desnecessárias para aproveitar ao máximo o sistema nos recursos de cada tamanho de computação das camadas 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 sugestã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 A 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 configuração cria dados distorcidos t1 (ou distribuídos irregularmente) na tabela. O plano de consulta ideal difere com base no parâmetro selecionado. Infelizmente, o comportamento de cache de plano nem sempre recompila a consulta com base no valor de parâmetro mais comum. 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, o plano resultante foi ótimo para o valor11, 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 exibiçã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
Nota
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 fiquem na mesma janela de 5 minutos na sys.resource_stats exibição. 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á-lo, ocasionalmente reexamine os planos para ajudá-lo a garantir que eles não se degradaram. Você pode saber mais sobre dicas de consulta (Transact-SQL).
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 ter limites de capacidade para bancos de dados individuais. Embora os pools elásticos de hiperescala (visualização) ofereçam limites de armazenamento significativamente mais altos, os pools elásticos e os bancos de dados em pool em outras camadas de serviço ainda podem ser restringidos por esses limites 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.
Nota
Os pools elásticos de hiperescala estão em pré-visualização para a Base de Dados SQL do Azure. 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.
Nota
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 da biblioteca de 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), 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 AdventureWorks 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.
Criação de partições funcionais
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 de 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, você pode reduzir a carga total de E/S em um banco de dados considerando como gravar em lote juntos. 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 aplicativo
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 você tiver uma carga de trabalho de leitura pesada, poderá ler os dados uma vez (ou talvez uma vez por máquina de camada de aplicativo, dependendo de como está configurado) 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 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 SQL do Azure.
Conteúdos relacionados
- Saiba mais sobre o modelo de compra baseado em DTU
- Saiba mais sobre o modelo de compra baseado em vCore
- Leia O que é um pool elástico do Azure?
- Descubra quando considerar uma piscina elástica
- Leia sobre Monitoramento de desempenho usando exibições de gerenciamento dinâmico
- Aprenda a diagnosticar e solucionar problemas de alta CPU no Banco de Dados SQL do Azure
- Ajuste os índices não em cluster com sugestões de índices em falta
- Vídeo: Práticas recomendadas de carregamento de dados no Banco de Dados SQL do Azure
- Monitorizar a Base de Dados SQL do Azure com o Azure Monitor