Exportar (0) Imprimir
Expandir Tudo

Orientação sobre o desempenho do Banco de Dados SQL do Azure

Atualizado: fevereiro de 2015

Autores: Conor Cunningham, Kun Cheng, Jan Engelsberg

Revisores técnicos: Morgan Oslake, Joanne Marone, Keith Elmore, José Batista-Neto, Rohit Nayak

O Banco de dados SQL do Microsoft Azure tem três camadas de serviço, Basic, Standard e Premium. Ao controlar estritamente a quantidade de recursos de seu Banco de dados SQL do Azure e suas réplicas secundárias, a camada de serviço Premium oferece um desempenho mais previsível para aplicativos em nuvem. O Banco de dados SQL do Azure expande esse conceito para a camada de serviço Standard para oferecer uma alta previsibilidade de desempenho para os bancos de dados com requisitos de desempenho menores do que o oferecido pela camada de serviço Premium. A camada de serviço Basic foi projetada para atender aos requisitos de desempenho de bancos de dados mais baratos.

noteObservação
As camadas de serviço Business e Web serão desativadas em setembro de 2015. Para saber mais, veja Perguntas frequentes sobre a descontinuação das edições Web e Business. Para obter informações detalhadas sobre como atualizar bancos de dados Web e o Business existentes para novas camadas de serviço, consulte Atualizar banco de dados Web/Business SQL para novas camadas de serviço.

Este documento traz orientação para ajudá-lo a determinar qual camada de serviço é adequada para seu aplicativo e fornece recomendações para ajustar seu aplicativo para tirar o máximo proveito do Banco de dados SQL do Azure. As seguintes seções estão incluídas:

Histórico do Banco de dados SQL do Azure

Qual é a diferença nas camadas de serviço?

Motivos para usar as camadas de serviço

Compreendendo o uso de recursos

Ajustando seu aplicativo

Conclusão

Para compreender como as camadas de serviço Basic, Standard e Premium aprimoram o serviço do Banco de dados SQL do Azure, convém ter um bom entendimento geral do Banco de dados SQL do Azure. Você pode escolher o Banco de dados SQL do Azure por vários motivos. Uma razão é evitar o ciclo demorado de compra e instalação do hardware. O Banco de dados SQL do Azure permite criar e remover os bancos de dados rapidamente sem esperar a aprovação de um pedido de compra, a chegada dos computadores, a atualização da energia e do resfriamento ou a realização da instalação. A Microsoft trata esses desafios e reduz significativamente o tempo necessário da ideia até a solução por meio do provisionamento prévio de hardware com base na demanda agregada em cada um de nossos datacenters. Isso pode economizar semanas ou meses para a empresa em relação à compra e à implantação manual do hardware.

A Microsoft também inclui muitos recursos de gerenciamento automático no Banco de dados SQL do Azure, como HA automática, balanceamento de carga e gerenciamento interno.

  • Alta disponibilidade (HA) automática

    O Banco de dados SQL do Azure mantém pelo menos três réplicas para cada banco de dados de usuário e tem lógica para confirmar automaticamente cada alteração em um quorum de réplicas. Isso garante que uma única falha do computador não cause perda de dados. Além disso, cada réplica é colocada em racks de hardwares diferentes, de modo que a falta de energia ou as trocas de rede não afetem o banco de dados. Finalmente, há uma lógica para recriar automaticamente réplicas se um computador for perdido, para que o sistema preserve as propriedades desejadas de integridade, mesmo que um computador deixe de ser íntegro. Esses mecanismos impedem o processo demorado necessário atualmente de instalar e configurar as soluções de alta disponibilidade. Ter uma solução previamente configurada de HA para seus dados elimina outro problema da criação de uma solução de banco de dados de missão crítica usando técnicas tradicionais.

  • Balanceamento de carga

    Diferentemente das máquinas virtuais tradicionais, o Banco de dados SQL do Azure também contém um mecanismo para balancear a carga automaticamente entre vários computadores. O Balanceador de Carga examina dinamicamente a utilização de recursos para um cluster e move as réplicas de banco de dados para computadores no cluster para compartilhar a carga em muitos usuários de modo razoável. Isso amplia a capacidade sob demanda do banco de dados e permite que um usuário considere os requisitos de capacidade de cada banco de dados de modo independente, pois o balanceador de carga poderá migrar bancos de dados ocupados para longe uns dos outros. Ao criar soluções que abrangem vários bancos de dados, essa lógica fornece uma camada de abstração que permite focar nas necessidades de capacidade de cada banco de dados, em vez das limitações específicas do tamanho de uma máquina virtual.

  • Gerenciamento interno

    O Banco de dados SQL do Azure é executado como um serviço. Isso significa que há destinos definidos de atividade para cada banco de dados, evitando o janelas de tempo de inatividade de manutenção demoradas. A Microsoft fornece uma solução de fornecedor único para o serviço, o que significa que há apenas uma empresa a ser chamada se ocorrer algum problema. A Microsoft também atualiza continuamente o serviço, adicionando recursos e capacidade, além de buscar formas de otimizar a experiência do usuário a cada nova atualização realizada. As atualizações ocorrem de forma transparente e sem períodos de tempo de inatividade, sendo integradas ao nosso mecanismo normal de failover de HA. Isso permite aproveitar imediatamente os novos recursos sempre que anunciamos sua disponibilidade, em vez de esperar um servidor ser atualizado durante uma futura janela de tempo de inatividade.

Todos esses recursos são disponibilizados em todas as camadas de serviço, começando a partir de uma faixa de preço acessível de apenas alguns dólares por mês. Isso é muito menos do que custaria comprar e executar seu próprio servidor, o que significa que até mesmo o menor projeto pode se beneficiar do Azure sem gastar muito dinheiro.

A Microsoft trabalhou junto com alguns clientes durante sua migração inicial para o Banco de dados SQL do Azure para saber como eles usavam o serviço e repassar esse aprendizado à nossa equipe de engenharia para o planejamento futuro de recursos. Durante as conversas, descobrimos que alguns tipos de clientes acharam o conjunto de recursos adequado às suas necessidades. Por exemplo, inicializações de desenvolvimento de novos serviços de nuvem com frequência descobriram que a combinação de capacidade sob demanda e sobrecarga administrativa reduzida simplificou suas vidas e permitiu que concentrassem seu tempo em seu negócio principal. Outros clientes tinham desafios em algumas áreas relacionadas a requisitos rigorosos de desempenho, talvez para atender uma API central em uma solução de grande porte de banco de dados de várias camadas, que não eram atendidos no momento pelo serviço de Banco de dados SQL do Azure. Os comentários indicaram que alguns clientes estavam muito dispostos a aceitar a variação de desempenho mais alta para obter um preço muito baixo. Outros clientes estavam mais interessados em garantias de desempenho específicas para que pudessem extrair mais facilmente um valor superior desses bancos de dados.

Para atender todas as suas necessidades, a Microsoft tem três camadas de serviço: Basic, Standard e Premium. Cada camada de serviço tem um ou mais níveis de desempenho que oferecem capacidade de executar o banco de dados de forma previsível. A capacidade é descrita em DTUs (unidades de taxa de transferência de banco de dados).

A camada de serviço Basic foi projetada para oferecer uma previsibilidade de desempenho satisfatória para cada banco de dados hora a hora. A DTU de um banco de dados Basic foi projetada para oferecer recursos suficientes para permitir o desempenho adequado de bancos de dados pequenos sem várias solicitações simultâneas.

A camada de serviço Standard oferece um desempenho melhor e mais previsível, e otimiza os bancos de dados com várias solicitações simultâneas, como de aplicativos Web e de grupos de trabalho. Usar um banco de dados da camada de serviço Standard permite dimensionar seu aplicativo de banco de dados com base em um desempenho previsível minuto a minuto.

O recurso de letreiro relacionado ao desempenho da camada de serviço Premium é o desempenho previsível segundo a segundo de cada banco de dados Premium. Usar a camada de serviço Premium permite dimensionar seu aplicativo de banco de dados com base na carga de pico desse banco de dados e remove os casos em que a variação de desempenho pode fazer com que consultas pequenas levem mais tempo do que o esperado nas operações sensíveis à latência. Esse modelo pode simplificar muito os ciclos de desenvolvimento e validação do produto necessários para aplicativos que precisam criar instruções fortes sobre necessidades de recursos de pico, variação de desempenho ou latência da consulta. Ele também pode permitir a migração de alguns aplicativos locais sem alterações significativas, pois oferece uma experiência mais próxima à experiência tradicional isolada presumida nesses aplicativos quando foram criados originalmente.

Semelhante à Standard, a camada de serviço Premium oferece a opção de diversos níveis de desempenho com base no isolamento desejado pelo cliente.

As configurações do nível de desempenho nas camadas Standard e Premium permitem pagar apenas pela capacidade necessária e ajustar essa capacidade à medida que a carga de trabalho muda. Por exemplo, se a carga de trabalho do banco de dados for intensa durante a temporada de compras de volta às aulas, você poderá aumentar o nível de desempenho para o banco de dados durante esse período e reduzi-lo após o fim dessa janela de pico. Isso permite minimizar o que você paga otimizando seu ambiente de nuvem de acordo com a sazonalidade de seus negócios. Esse modelo também funciona bem para ciclos da versão de produto de software. Uma equipe de teste pode alocar a capacidade ao executar testes e liberar essa capacidade quando os testes forem concluídos. Essas solicitações de capacidade se ajustam bem ao modelo em que você pagaria pela capacidade conforme precisasse e evitaria gastos em recursos dedicados que são usados com pouca frequência. Isso proporciona uma experiência de desempenho muito mais próxima do modelo de hardware tradicional dedicado que muitos clientes da Microsoft usaram com o SQL Server. Isso deve permitir a execução de um conjunto maior de aplicativos com mais facilidade no Banco de dados SQL do Azure.

Para obter mais informações sobre as camadas de serviço, níveis de desempenho e DTUs, consulte Camadas de serviço e níveis de desempenho do Banco de Dados SQL do Azure.

Embora cada carga de trabalho seja diferente, a finalidade das camadas de serviço é oferecer uma alta previsibilidade de desempenho para diversos níveis de desempenho. Elas permitem que clientes com uma grande escala de requisitos de recursos para seus bancos de dados trabalhem em um ambiente computacional mais dedicado.

Casos comuns em que o recurso da camada de serviço Basic seria aplicável:

  • Início do uso do Banco de dados SQL do Azure: aplicativos em desenvolvimento geralmente não precisam de altos níveis de desempenho. Os bancos de dados Basic oferecem um ambiente ideal de desenvolvimento de banco de dados a um baixo preço.

  • Banco de dados com um único usuário: aplicativos que associam um único usuário a um banco de dados geralmente não apresentam altos requisitos de simultaneidade e desempenho. Aplicativos com esses requisitos são candidatos à camada de serviço Basic.

Casos comuns em que o recurso da camada de serviço Standard seria aplicável:

Banco de dados com várias solicitações simultâneas: aplicativos que atendem a um ou mais usuários ao mesmo tempo, como sites com tráfego moderado ou aplicativos departamentais que exigem uma quantidade maior de recursos, são bons candidatos para a camada de serviço Standard.

Casos comuns em que o recurso da camada de serviço Premium seria aplicável:

  • Carga de pico alta: um aplicativo que exige muita CPU, memória ou E/S para concluir suas operações. Por exemplo, se uma operação de banco de dados sabidamente consumir vários núcleos de CPU por um longo período, essa é uma candidata para ao uso de bancos de dados Premium.

  • Muitas solicitações simultâneas: alguns aplicativos de banco de dados atendem a muitas solicitações simultâneas (por exemplo, atender a um site com alto volume de tráfego). As camadas de serviço Basic e Standard apresentam limites quanto à quantidade de solicitações simultâneas. Os aplicativos que requerem mais conexões precisariam escolher um tamanho apropriado de reserva para controlar o número máximo de solicitações necessárias.

  • Baixa latência: alguns aplicativos precisam garantir uma resposta do banco de dados no mínimo de tempo. Se um procedimento armazenado específico for chamado como parte de uma operação mais ampla do cliente, talvez haja um requisito de retorno dessa chamada em não mais que 20 milissegundos 99% do tempo. Esse tipo de aplicativo se beneficiará com os bancos de dados Premium ao assegurar que a capacidade de computação esteja disponível.

Para obter mais detalhes sobre os cenários comuns que podem resultar em problemas de desempenho ao usar o Banco de dados SQL do Azure, consulte Banco de Dados SQL do Azure e SQL Server -- Comparação e Contraste do Desempenho e da Escalabilidade.

O nível exato necessário dependerá dos requisitos de carga de pico para cada dimensão de recurso. Alguns aplicativos podem usar quantidades comuns de um recurso, mas ter requisitos significativos em outro.

Para obter mais informações sobre as camadas de serviço, consulte Camadas de serviço e níveis de desempenho do Banco de Dados SQL do Azure.

O gráfico a seguir mostra a utilização de recursos de CPU de um banco de dados Premium com o nível de desempeno P2 para cada hora do dia em uma semana. Este gráfico em particular é iniciado em uma segunda-feira, mostrando 5 dias úteis e um fim de semana em que ocorrem menos atividades no aplicativo.

SQL_DB

Com base nos dados, esse banco de dados atualmente tem uma carga de pico de CPU de pouco mais de 50% de utilização da CPU, equivalente ao nível de desempenho P2 (meio-dia de terça-feira). Se a CPU fosse o fator dominante no perfil de recursos do aplicativo, você poderia decidir que P2 é o nível de desempenho adequado para garantir que a carga de trabalho sempre seja atendida. Se um aplicativo for crescer com o passar do tempo, faz sentido deixar algum buffer adicional do recurso para que o aplicativo nunca atinja o limite. Isso ajudará a evitar erros visíveis pelo cliente causados porque o banco de dados não tem capacidade suficiente para processar as solicitações de modo eficaz, especialmente em ambientes sensíveis à latência (como um banco de dados que oferece suporte a um aplicativo que pinta páginas da Web com base nos resultados de chamadas de banco de dados).

Vale observar que outros tipos de aplicativo podem interpretar o mesmo gráfico de forma diferente. Por exemplo, se um aplicativo tentar processar dados de folha de pagamento todos os dias e incluir o mesmo gráfico, esse tipo de modelo de "tarefa em lotes" poderá funcionar satisfatoriamente no nível de desempenho P1. O nível de desempenho P1 tem 100 DTUs em relação a 200 DTUs do nível de desempenho P2. Isso significa que o nível de desempenho P1 oferece metade do desempenho do nível P2. Portanto, 50% da utilização de CPU em P2 equivale a 100% da utilização de CPU em P1. Desde que o aplicativo não tenha tempos limite, talvez não importe se um trabalho grande demorar 2 horas ou 2,5 horas para ser concluído, desde que seja feito hoje. Um aplicativo nessa categoria provavelmente pode usar apenas o nível de desempenho P1. Você pode tirar proveito do fato de que há períodos durante o dia em que o uso do recurso é menor, significando que um "pico maior" poderá extrapolar para um dos ciclos posteriores do dia. O nível de desempenho P1 talvez seja ótimo para esse aplicativo (e para economizar dinheiro), desde que os trabalhos possam ser concluídos no horário todos os dias.

O Banco de dados SQL do Azure expõe informações sobre os recursos consumidos referentes a cada banco de dados ativo na exibição sys.resource_stats do banco de dados mestre em cada servidor. Os dados na tabela são agregados por intervalos de 5 minutos. Com as camadas de serviço Basic, Standard e Premium, os dados podem demorar mais de cinco minutos para aparecerem na tabela, o que significa que esses dados são melhores para a análise histórica do que para a análise em tempo real. A consulta da exibição sys.resource_stats mostra o histórico recente de um banco de dados para validar se a reserva selecionada forneceu o desempenho esperado quando necessário. O exemplo a seguir demonstra como os dados nessa exibição são expostos:

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

SQL_DB

Observação: Algumas colunas da tabela foram truncadas por questão de espaço. Consulte o tópico sys.resource_stats para obter uma descrição completa da saída.

Esta seção descreve maneiras de monitorar o uso de recursos do Banco de dados SQL do Azure e de comparar a utilização de recursos atual com diferentes níveis de serviço.

  1. A exibição de catálogo sys.resource_stats é enriquecida com informações mais históricas sobre o uso do recurso no nível do banco de dados. Por exemplo, para examinar o uso de recursos da semana passada do banco de dados, “userdb1”, você pode executar a seguinte consulta.

    SELECT * 
    FROM sys.resource_stats 
    WHERE database_name = 'userdb1' AND 
          start_time > DATEADD(day, -7, GETDATE())
    ORDER BY start_time DESC;
    
    
  2. Para avaliar a adequação da sua carga de trabalho ao nível de desempenho, você precisa detalhar cada aspecto diferente das métricas de recursos: CPU, leituras, gravação, número de trabalhadores e número de sessões. Aqui está uma consulta revisada que usa sys.resource_stats para relatar os valores médio e máximo dessas métricas de recurso.

    SELECT 
        avg(avg_cpu_percent) AS 'Average CPU Utilization In Percent',
        max(avg_cpu_percent) AS 'Maximum CPU Utilization In Percent',
        avg(avg_physical_data_read_percent) AS 'Average Physical Data Read Utilization In Percent',
        max(avg_physical_data_read_percent) AS 'Maximum Physical Data Read Utilization In Percent',
        avg(avg_log_write_percent) AS 'Average Log Write Utilization In Percent',
        max(avg_log_write_percent) AS 'Maximum Log Write Utilization In Percent',
        avg(active_session_count) AS 'Average # of Sessions',
        max(active_session_count) AS 'Maximum # of Sessions',
        avg(active_worker_count) AS 'Average # of Workers',
        max(active_worker_count) AS 'Maximum # of Workers'
    FROM sys.resource_stats 
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    
  3. Com as informações acima de valores médio e máximo de cada métrica de recurso, você pode avaliar a adequação da sua carga de trabalho ao nível de desempenho escolhido. Na maioria dos casos, os valores médios de sys.resource_stats oferecem uma boa referência a ser usada com o tamanho de destino. Esse deve ser o seu padrão primário. Por exemplo, se você for usar a camada de serviço Standard com o nível de desempenho S2, as porcentagens médias de utilização de CPU, leituras e gravações forem inferiores a 20%, o número médio de trabalhadores for inferior a 50 e o número médio de sessões for inferior a 200, sua carga de trabalho talvez se enquadre no nível de desempenho S1. É fácil identificar se o seu banco de dados se enquadra dentro dos limites de trabalhadores e sessões. Para ver se um banco de dados se enquadra em um nível de desempenho inferior em termos de CPU, leituras e gravações, divida o número de DTUs do nível de desempenho inferior pelo número de DTUs do seu nível de desempenho atual e multiplique o resultado por 100:

    DTU do S1 / DTU do S2 * 100 = 5 / 25 * 100 = 20

    O resultado é a diferença de desempenho relativa entre os dois níveis de desempenho em porcentagem. Se sua utilização não exceder essa porcentagem, sua carga de trabalho talvez se enquadre no nível de desempenho inferior. No entanto, você também precisa analisar todos os intervalos de valores de uso de recursos e determinar, em porcentagem, com que frequência a carga de trabalho do seu banco de dados se enquadraria no nível de desempenho inferior. A consulta a seguir produz a porcentagem de enquadramento por dimensão de recurso com base no limite de 20% calculado acima.

    SELECT 
        (COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'CPU Fit Percent'
        ,(COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Log Write Fit Percent'
        ,(COUNT(database_name) - SUM(CASE WHEN avg_physical_data_read_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Physical Data Read Fit Percent'
    FROM sys.resource_stats
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    
    Com base no SLO (objetivo de nível de serviço) do seu banco de dados, você pode determinar se a sua carga de trabalho se enquadra no nível de desempenho inferior. Se o SLO da carga de trabalho do seu banco de dados for de 99,9% e a consulta acima retornar valores superiores a 99,9 para as três dimensões de recurso, é muito provável que sua carga de trabalho se enquadre no nível de desempenho inferior.

    A análise da porcentagem de enquadramento também mostra se você precisa avançar para o nível de desempenho superior para atender ao seu SLO. Por exemplo, "userdb1" mostra a seguinte utilização para a semana passada.

     

    Porcentagem média de CPU

    Porcentagem máxima de CPU

    24.5

    100.00

    A CPU média é de aproximadamente um quarto do limite do nível de desempenho, o que se enquadraria perfeitamente no nível de desempenho do banco de dados. No entanto, o valor máximo mostra que o banco de dados atinge o limite do nível de desempenho. Você precisa avançar para o próximo nível de desempenho superior? Novamente, é necessário analisar quantas vezes sua carga de trabalho atinge 100% e compará-la ao SLO da carga de trabalho do seu banco de dados.

    SELECT 
    (COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'CPU Fit Percent'
    ,(COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Log Write Fit Percent’
    ,(COUNT(database_name) - SUM(CASE WHEN avg_physical_data_read_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Physical Data Read Fit Percent'
    FROM sys.resource_stats
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    Se a consulta acima retornar um valor inferior a 99,9 em qualquer uma das três dimensões, você deverá considerar a possibilidade de avançar para o próximo nível de desempenho superior ou usar técnicas de ajuste de aplicativo para reduzir a carga no Banco de dados SQL do Azure.

  4. O exercício acima também deve levar em consideração o aumento projetado da carga de trabalho no futuro.

No SQL Server local tradicional, o processo de planejamento da capacidade inicial é, com frequência, separado do processo de execução de um aplicativo em produção. Em outras palavras, a compra de hardware e licenças associadas para execução do SQL Server é feita antecipadamente, enquanto o ajuste de desempenho é feito depois. Ao usar o Banco de dados SQL do Azure, geralmente é recomendável (e como você é cobrado por mês, provavelmente é desejável) intercalar o processo de execução e ajuste de um aplicativo. O modelo de pagar pela capacidade sob demanda permite ajustar o aplicativo para usar o mínimo de recursos necessários desde agora, em vez de provisionar excessivamente o hardware com base em palpites de planos de crescimento futuro para um aplicativo (que, com frequência, se mostram incorretos, pois precisam fazer previsões muito adiante no futuro). Observe que alguns clientes podem optar por não ajustar um aplicativo e optar por provisionar excessivamente os recursos de hardware. Essa abordagem pode fazer sentido quando você não deseja alterar o aplicativo principal durante um período ocupado para o aplicativo. Ajustar um aplicativo pode reduzir os requisitos de recurso e diminuir as contas mensais ao usar camadas de serviço no Banco de dados SQL do Azure.

Embora as camadas de serviço sejam projetadas para melhorar a estabilidade e a previsibilidade do desempenho de um aplicativo, haverá algumas práticas recomendadas para ajustar seu aplicativo a fim de aproveitar melhor o recurso. Embora você observe ganhos de desempenho significativos para muitos aplicativos ao simplesmente alternar para um nível de desempenho ou uma camada de serviço superior, nem todos os aplicativos poderão ser tão beneficiados sem ajuste adicional. O ajuste adicional também deve ser considerado para aplicativos com as seguintes características a fim de melhorar ainda mais o desempenho ao usar o Banco de dados SQL do Azure.

  • Aplicativos que têm um desempenho lento devido ao comportamento “tagarela”

    Isso inclui os aplicativos que realizam operações de acesso a dados excessivas que são sensíveis à latência de rede. Esses aplicativos talvez exijam modificação para reduzir o número de operações de acesso a dados no Banco de dados SQL do Azure. Por exemplo, o aplicativo pode ser melhorado com o uso de técnicas, como envio em lote de consultas ad hoc juntas ou movimentação das consultas para procedimentos armazenados. Para obter mais informações, consulte a seção 'Consultas em lote' a seguir.

  • Bancos de dados com uma carga de trabalho intensiva não podem ter o suporte de um único computador inteiro

    Bancos de dados que excedem os recursos do maior nível de desempenho Premium não são bons candidatos. Esses bancos de dados podem se beneficiar com a expansão da carga de trabalho. Para obter mais informações, consulte as seções 'Fragmentação entre banco de dados' e 'Particionamento funcional' a seguir.

  • Aplicativos que contêm consultas não ideais

    Os aplicativos, especialmente na camada de acesso a dados, que têm consultas mal ajustadas talvez não se beneficiem da seleção de um nível de desempenho superior, conforme esperado. Isso inclui consultas que carecem de uma cláusula WHERE, tem índices ausentes ou têm estatísticas desatualizadas. Esses aplicativos se beneficiarão das técnicas de ajuste de desempenho de consulta padrão. Para obter mais informações, consulte as seções 'Índices ausentes' e 'Ajuste/dicas de consulta' a seguir.

  • Aplicativos que têm o design não ideal de acesso a dados

    Os aplicativos que têm problemas inerentes de simultaneidade de acesso a dados, por exemplo, deadlock, talvez não se beneficiem da seleção de um nível de desempenho superior. Os desenvolvedores de aplicativos devem considerar a redução de viagens de ida e volta para o Banco de dados SQL do Azure armazenando os dados em cache no cliente com o serviço de Cache do Azure ou outras tecnologias de cache. Consulte a seção Cache da camada de aplicativo a seguir.

Esta seção explica algumas técnicas que você pode usar para ajustar o Banco de dados SQL do Azure para obter o melhor desempenho do seu aplicativo e poder executá-lo usando o menor nível de desempenho possível. Diversas técnicas condizem com as práticas recomendadas de ajuste do SQL Server, mas outras são específicas do Banco de dados SQL do Azure. Em alguns casos, é possível ampliar as técnicas tradicionais do SQL Server para que elas também funcionem no Banco de dados SQL do Azure examinando os recursos consumidos para que um banco de dados encontre áreas com margem para mais ajuste.

Um problema comum no desempenho de banco de dados OLTP está relacionado ao design do banco de dados físico. Frequentemente, os esquemas de banco de dados são projetados e enviados sem muitos testes (na carga ou no volume de dados). Infelizmente, o desempenho de um plano de consulta pode ser aceitável em pequena escala, mas pode ser substancialmente comprometido ao ter que lidar com volumes de dados no nível de produção. A origem mais comum desse problema se deve à falta de índices adequados para satisfazer filtros ou outras restrições em uma consulta. Geralmente, isso se manifesta como uma verificação de tabela quando uma pesquisa de índice poderia bastar.

O exemplo a seguir cria um caso em que o plano de consulta selecionado contém uma verificação de quando uma pesquisa seria 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;


SQL_DB

O Banco de dados SQL do Azure contém uma funcionalidade para ajudar os administradores de banco de dados a localizar e corrigir condições comuns de índice ausente. As DMVs (exibições de gerenciamento dinâmico) internas do Banco de dados SQL do Azure analisam a compilação da consulta em que um índice reduziria significativamente o custo estimado para executar uma consulta. Durante a execução da consulta, controla a frequência com que cada plano de consulta é executado, bem como o intervalo estimado entre a execução do plano de consulta o plano imaginado em que esse índice existia. Isso permite que um administrador de banco de dados rapidamente suponha que mudanças de design de banco de dados físico podem aprimorar a carga de trabalho geral para um determinado banco de dados e sua carga de trabalho real.

A consulta a seguir pode ser usada para avaliar potenciais í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, o seguinte índice é sugerido.

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

Depois de criada, essa mesma instrução SELECT agora escolhe um plano diferente que usa uma pequisa, em vez de uma verificação, apresentando execução mais eficiente conforme mostrado no plano de consulta a seguir.

SQL_DB

A ideia principal é que a capacidade de E/S de um sistema de mercadorias compartilhado geralmente seja mais limitado que um computador de servidor dedicado. Assim, há um bônus com a redução da E/S desnecessária para tirar o máximo proveito do sistema na DTU de cada nível de desempenho das camadas de serviço no Banco de dados SQL do Azure. As opções apropriadas de design de banco de dados físico podem melhorar significativamente a latência para consultas individuais, a taxa de transferência de solicitações simultâneas que você pode administrar por unidade de escala e minimizar os custos necessários para atender à consulta. Para obter mais informações sobre o DMVs de índice ausente, consulte sys.dm_db_missing_index_details.

O Otimizador de Consulta do Banco de dados SQL do Azure é bastante semelhante ao Otimizador de Consulta do SQL Server tradicional. Muitas das práticas recomendadas para ajuste de consultas e entendimento das limitações do modelo de raciocínio do Otimizador de Consulta também se aplicam ao Banco de dados SQL do Azure. O ajuste de consultas do Banco de dados SQL do Azure pode ter a vantagem adicional de reduzir as demandas de recursos agregados e permitir que um aplicativo seja executado com um custo menor do que um equivalente sem ajuste, pois ele pode ser executado em um nível de desempenho inferior.

Um exemplo comum observado no SQL Server que também se aplica ao Banco de dados SQL do Azure está relacionado ao modo como os parâmetros são detectados durante a compilação para tentar criar um plano melhor. A detecção de parâmetro é um processo com o qual o otimizador de consulta considera o valor atual de um parâmetro ao criar uma consulta com o objetivo de gerar um plano de consulta melhor. Embora essa estratégia possa frequentemente levar a um plano de consulta significativamente mais rápido do que um plano compilado sem o conhecimento dos valores de parâmetro, o comportamento atual do SQL Server/Banco de dados SQL do Azure é imperfeito: há casos em que o parâmetro não é detectado e outros em que o parâmetro é detectado, mas o plano gerado está abaixo do ideal para o conjunto completo de valores de parâmetro em uma carga de trabalho. A Microsoft inclui dicas de consulta (diretivas) para permitir especificar a intenção mais deliberadamente e substituir o comportamento padrão para a detecção do parâmetro. Frequentemente, o uso de dicas pode corrigir os casos em que o comportamento padrão do SQL Server/Banco de dados SQL do Azure é imperfeito para determinada carga de trabalho de cliente.

O exemplo a seguir demonstra como o processador de consulta pode gerar um plano abaixo do ideal para os requisitos de desempenho e de recurso e como o uso de uma dica de consulta pode reduzir os requisitos de tempo de execução e de recurso de consulta no Banco de dados SQL do Azure.

O que se segue é uma configuração de exemplo.

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 uma tabela que contém uma distribuição de dados distorcida. O plano de consulta ideal varia com base no parâmetro que está sendo selecionado. Infelizmente, o comportamento do cache de plano nem sempre recompila a consulta com base no valor de parâmetro mais comum, o que significa que é possível que um plano abaixo do ideal seja armazenado em cache e usado para muitos valores, mesmo que um plano diferente seja uma opção de plano médio melhor. Em seguida, cria dois procedimentos armazenados idênticos, a não ser pelo fato de que um contém uma dica de consulta especial (raciocínio explicado abaixo).

Exemplo (parte 1).

-- 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

Exemplo (parte 2 – espere 10 minutos antes de tentar essa parte para que seja obviamente diferente nos dados resultantes de telemetria).

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 desse exemplo tenta executar uma instrução de inserção com parâmetros 1000 vezes (para gerar a carga suficiente para ser interessante em um conjunto de dados de teste). Ao executar procedimentos armazenados, o processador de consulta examina o valor do parâmetro passado ao procedimento durante a primeira compilação (conhecida como "detecção" de parâmetro). O plano resultante é armazenado em cache e usado para invocações posteriores, mesmo que o valor do parâmetro seja diferente. Por isso, talvez o plano ideal não seja usado em todos os casos. Às vezes os clientes precisam de orientar o otimizador a escolher um plano que seja melhor para os casos comuns, em vez do caso específico em que uma consulta foi compilada pela primeira vez. Neste exemplo, o plano inicial gerará um plano de "verificação" que lê todas as linhas para localizar cada valor que corresponde ao parâmetro.

SQL_DB

Como executamos o procedimento com o valor 1, o plano resultante era ideal para 1, mas abaixo do ideal para todos os outros valores na tabela. O comportamento resultante provavelmente não será o desejado se você escolher cada plano aleatoriamente, pois o plano será executado com mais lentidão e sua execução consumirá mais recursos.

A execução do teste com "SET STATISTICS IO ON" mostra o trabalho de verificação lógica feito neste exemplo em segundo plano: você pode observar que há 1.148 leituras feitas pelo plano (o que será ineficaz se o caso comum for retornar apenas uma linha).

SQL_DB

A segunda parte do exemplo usa uma dica de consulta para informar ao otimizador para usar um valor específico durante o processo de compilação. Nesse caso, ele força o processador de consulta a ignorar o valor passado como parâmetro e assume um “UNKNOWN”, o que significa que um valor que tem a frequência média na tabela (ignorando a distorção). O plano resultante é um plano baseado na busca que será mais rápido e usará menos recursos, em média, do que o plano da parte 1 do exemplo.

SQL_DB

O impacto disso fica evidente na tabela sys.resource_stats (observação: haverá um atraso entre o momento em que o teste é executado e o momento em que os dados são preenchidos na tabela). Neste exemplo, a parte 1 foi executada durante a janela de tempo 22:25:00, e a parte 2 foi executada em 22:35:00. A primeira janela de tempo utilizou 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

SQL_DB

ImportantImportante
Embora o exemplo usado aqui seja pequeno de propósito, o impacto de parâmetros abaixo do ideal pode ser significativo, especialmente em bancos de dados maiores. A diferença, nos casos extremos, pode ser entre segundos e hora para os casos rápidos e lentos.

Você pode examinar o sys.resource_stats para determinar se o recurso de um determinado teste usa mais ou menos recursos do que outro teste. Ao comparar os dados, separe os testes por um tempo suficiente para que eles não sejam agrupados na mesma janela de tempo de cinco minutos na exibição sys.resource_stats. Além disso, observe que o objetivo do exercício é reduzir o total de recursos utilizado, e não reduzir o pico de recursos propriamente dito. De maneira geral, a otimização de um trecho de código para melhorar a latência também reduzirá o consumo de recursos. Verifique se as alterações consideradas em qualquer aplicativo são realmente necessárias e não afetam negativamente a experiência do cliente para qualquer pessoa que use um aplicativo ao utilizar as dicas de consulta.

Se uma carga de trabalho contiver um conjunto de consultas repetidas, geralmente faz sentido capturar e validar as opções ideais de plano, pois isso provavelmente resultará na unidade de tamanho mínimo do recurso necessária para hospedar o banco de dados. Após a validação, reexamine esses planos de vez em quando para ter certeza de que não se deterioraram. Para obter mais informações sobre dicas de consulta, consulte Dicas de consulta (Transact-SQL).

Como o Banco de dados SQL do Azure é executado em hardware comercial, geralmente há limites de capacidade mais baixos para um único banco de dados do que em uma instalação local tradicional do SQL Server. Portanto, há diversos clientes que usam técnicas de fragmentação para distribuir as operações do banco de dados entre vários bancos de dados quando não se ajustam aos limites de um único banco de dados no Banco de dados SQL do Azure. A maioria dos clientes que atualmente usa técnicas de fragmentação no Banco de dados SQL do Azure divide seus dados de uma única dimensão entre vários bancos de dados. A abordagem envolve entender que os aplicativos OLTP executam frequentemente transações que se aplicam apenas a uma linha ou a um pequeno grupo de linhas no esquema. Por exemplo, se um banco de dados contiver o cliente, o pedido e os detalhes do pedido (conforme observado no banco de dados de exemplo tradicional Northwind fornecido no SQL Server), esses dados poderão ser divididos em vários bancos de dados agrupando-se um cliente com o pedido relacionado e as informações de detalhes do pedido e garantindo que ele permaneça em um único banco de dados. O aplicativo dividiria clientes diferentes nos bancos de dados, distribuindo efetivamente a carga em vários bancos de dados. Isso não só permite que os clientes evitem o limite máximo de tamanho de banco de dados, mas também permite que o Banco de dados SQL do Azure processe cargas de trabalho consideravelmente maiores do que os limites dos diferentes níveis de desempenho, desde que cada banco de dados individual se ajuste à sua DTU.

Embora a fragmentação de banco de dados não reduza a capacidade agregada de recursos para uma solução, essa técnica é altamente eficaz para dar suporte a soluções muito grandes distribuídas entre vários bancos de dados e permite que cada banco de dados seja executado em um nível de desempenho diferente para dar suporte a bancos de dados "eficazes" muito grandes, com altos requisitos de recursos.

Os usuários do SQL Server combinam frequentemente muitas funções em um único banco de dados. Por exemplo, se um aplicativo contiver lógica para gerenciar o estoque de uma loja, esse banco de dados poderá conter a lógica associada ao estoque, o controle de ordens de compra, os procedimentos armazenados e as exibições indexadas/materializadas que gerenciaram os relatórios do fim do mês e outras funções. Essa técnica fornece o benefício de poder administrar facilmente o banco de dados para operações, como BACKUP, mas também requer dimensionar o hardware para lidar com a carga de pico em todas as funções de um aplicativo.

Na arquitetura de escalabilidade horizontal usada no Banco de dados SQL do Azure, geralmente é útil dividir funções diferentes de um aplicativo em bancos de dados diferentes. Isso permite que cada um deles seja dimensionado de forma independente. À medida que um aplicativo se torna mais ocupado (e recebe mais carga no banco de dados), isso permite que o administrador escolha níveis de desempenho de forma independente para cada função em um aplicativo. No limite, essa arquitetura permite que um aplicativo fique maior que um único computador de mercadoria pode tratar distribuindo a carga em vários computadores.

Para aplicativos que acessam dados na forma de muitas consultas ad hoc frequentes, uma grande parte do tempo de resposta é gasta na comunicação de rede entre a camada do aplicativo e a camada do Banco de dados SQL do Azure. Mesmo quando o aplicativo e o Banco de dados SQL do Azure residem no mesmo datacenter, a latência de rede entre os dois pode ser aumentada por um número alto de operações de acesso a dados. Para reduzir viagens de ida e volta da rede para essas operações de acesso a dados, o desenvolvedor do aplicativo deve considerar opções de envio em lote de consultas ad hoc ou sua compilação em procedimentos armazenados. A criação de lotes de consultas ad hoc pode enviar várias consultas como um único lote grande em uma única viagem para o Banco de dados SQL do Azure. A compilação de consultas ad hoc em um procedimento armazenado poderia obter o mesmo resultado do envio em lote. O uso de um procedimento armazenado também oferece o benefício de aumentar as chances do armazenamento em cache dos planos de consulta no Banco de dados SQL do Azure para execuções subsequentes do mesmo procedimento armazenado.

Alguns aplicativos apresentam gravação intensa. Às vezes, é possível reduzir a carga total de E/S em um banco de dados considerando como enviar gravações juntas em lote. Isso geralmente é 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. Uma avaliação de técnicas diferentes que podem ser usadas pode ser encontrada em Técnicas de envio em lote para aplicativos de Banco de dados SQL no Azure. Teste sua própria carga de trabalho para encontrar o modelo certo para o envio em lote, tomando o cuidado de entender que um determinado modelo pode ter garantias de consistência transacionais ligeiramente diferentes. Encontrar a carga de trabalho certa que minimiza o uso de recursos requer a localização da combinação certa de consistência e compensações de desempenho.

Alguns aplicativos de banco de dados contêm cargas de trabalho pesadas de leitura. É possível utilizar camadas de cache para reduzir a carga no banco de dados e possivelmente reduzir o nível de desempenho necessário para dar suporte a um banco de dados que usa o Banco de dados SQL do Azure. O Cache do Azure (Cache) permite que um cliente com uma carga de trabalho com alta taxa de leitura leia os dados uma vez (ou talvez uma vez por computador no nível do aplicativo, dependendo de como estiver configurado) e armazene esses dados fora do Banco de dados SQL do Azure. Isso fornece uma capacidade de reduzir a carga do banco de dados (CPU e E/S de leitura), mas há um impacto na consistência transacional, pois os dados que estão sendo lidos do cache podem estar desatualizados com os dados no banco de dados. Quando há muitos aplicativos onde uma quantidade de inconsistência é aceitável, isso não é válido para todas as cargas de trabalho. Entenda completamente os requisitos de qualquer aplicativo antes de implantar uma estratégia de cache da camada de aplicativo.

As camadas de serviço no Banco de dados SQL do Azure capacitam você a elevar o nível nos tipos de aplicativos construídos na nuvem. Quando combinadas com o ajuste cuidadoso de aplicativo, você pode obter um desempenho ideal e previsível para seu aplicativo. Este documento descreve as técnicas recomendadas para otimizar o consumo de recursos de um banco de dados para se ajustar adequadamente a um dos níveis de desempenho. O ajuste é um exercício contínuo no modelo de nuvem e as camadas de serviço e seus níveis de desempenho permitem que os administradores aumentem o desempenho e, ao mesmo tempo, reduzam os custos na plataforma Microsoft Azure.

Consulte também

Mostrar:
© 2015 Microsoft