Anterior

Seguinte

Exercício – Dimensionar o desempenho da sua carga de trabalho

Concluído

Neste exercício, você pegará o problema encontrado no primeiro exercício e melhorará o desempenho dimensionando mais CPUs para o Banco de Dados SQL do Azure. Você usará o banco de dados implantado no exercício anterior.

Você pode encontrar todos os scripts para este exercício na pasta 04-Performance\monitor_and_scale no repositório GitHub que você clonou ou no arquivo zip que você baixou.

Aumentar verticalmente o desempenho do SQL do Azure

Para dimensionar o desempenho relativamente a um problema que parece ser relativo à capacidade da CPU, deve definir as suas opções e, em seguida, proceder ao dimensionamento das CPUs através de interfaces fornecidas para o SQL do Azure.

1. Decida como pretende dimensionar o desempenho. Como a carga de trabalho está ligada à CPU, uma maneira de melhorar o desempenho é aumentar a capacidade ou a velocidade da CPU. Para obter mais capacidade de CPU, o utilizador do SQL Server teria de utilizar outro computador ou reconfigurar uma VM. Em alguns casos, até mesmo um administrador do SQL Server pode não ter permissão para fazer essas alterações de dimensionamento. O processo pode ser demorado e até necessitar de uma migração de base de dados.

   Para o Azure, você pode usar ALTER DATABASEo , a CLI do Azure ou o portal do Azure para aumentar a capacidade da CPU sem migração de banco de dados por parte do usuário.

2. Ao utilizar o portal do Azure, pode ver as opções sobre como dimensionar para obter mais recursos da CPU. No painel Visão geral do banco de dados, selecione a camada de preços para a implantação atual. O escalão de Preços permite-lhe alterar o escalão de serviço e o número de vCores.

   

3. Pode ver aqui as opções para alterar ou dimensionar recursos de computação. Para Fins Gerais, pode aumentar verticalmente sem dificuldade para 8 vCores.

   

   Também pode utilizar um método diferente para dimensionar a carga de trabalho.

4. Neste exercício, para ver as diferenças relevantes nos relatórios, tem de remover o Arquivo de Consultas. No SQL Server Management Studio (SSMS), selecione o banco de dados AdventureWorks e use o menu Abrir>>arquivo de arquivo. Abra o script flushhquerystore.sql no SSMS no contexto do banco de dados AdventureWorks . A janela do editor de consultas deverá ter um aspeto semelhante ao texto abaixo:

   EXEC sp_query_store_flush_db;
   

   Selecione Executar para executar este lote T-SQL.

   Nota

   A execução da consulta anterior libera a parte na memória dos dados do Repositório de Consultas para o disco.

5. No SQL Server Management Studio, abra o script get_service_objetive.sql. A janela do editor de consultas deverá ter um aspeto semelhante ao texto abaixo:

   SELECT database_name,slo_name,cpu_limit,max_db_memory, max_db_max_size_in_mb, primary_max_log_rate,primary_group_max_io, volume_local_iops,volume_pfs_iops
   FROM sys.dm_user_db_resource_governance;
   GO
   SELECT DATABASEPROPERTYEX('AdventureWorks', 'ServiceObjective');
   GO
   

   Este método serve para descobrir o seu escalão de serviço através do T-SQL. O escalão de preços ou de serviço também é conhecido como um objetivo de serviço. Selecione Executar para executar os lotes T-SQL.

   Em relação à atual implementação da Base de Dados SQL do Azure, os seus resultados devem ter um aspeto semelhante ao da imagem abaixo:

   

   Repare que o termo slo_name também é utilizado para o objetivo de serviço. slo significa objetivo de nível de serviço.

   Os vários slo_name valores não estão documentados, mas você pode ver pelo valor da cadeia de caracteres que esse banco de dados usa uma camada de serviço de uso geral com dois vCores:

   Nota

   SQLDB_OP_... é a cadeia utilizada para o escalão Crítico para a Empresa.

   Quando ver a documentação ALTER DATABASE, será possível selecionar a implementação do SQL Server de destino para obter as opções de sintaxe corretas. Selecione a base de dados individual/conjunto elástico da Base de Dados SQL para ver as opções relativas à Base de Dados SQL do Azure. Para corresponder à escala de computação que você encontrou no portal, você precisa do objetivo 'GP_Gen5_8'de serviço .

6. Altere o objetivo de serviço da base de dados de forma a dimensionar mais CPUs. Abra o script modify_service_objetive.sql no SSMS e execute o lote T-SQL. A janela do editor de consultas deverá ter um aspeto semelhante ao texto abaixo:

   ALTER DATABASE AdventureWorks MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');
   

   Esta instrução é devolvida imediatamente, mas o dimensionamento dos recursos de computação ocorre em segundo plano. Um dimensionamento tão pequeno deve demorar menos de um minuto. A base de dados fica offline durante alguns momentos para que a alteração seja aplicada. Pode monitorizar o progresso desta atividade de dimensionamento através do portal do Azure.

   

7. No Object Explorer, na pasta System Databases (Bases de Dados do Sistema), clique com o botão direito do rato na base de dados mestra e selecione New Query (Nova Consulta). Execute esta consulta na janela do editor de consultas do SQL Server Management Studio:

   SELECT * FROM sys.dm_operation_status;
   

   Trata-se de outra forma de monitorizar o progresso da alteração do objetivo do serviço da Base de Dados SQL do Azure. Esta vista de gestão dinâmica (DMV) apresenta o histórico de alterações da base de dados com a instrução ALTER DATABASE como objetivo de serviço. Mostra o progresso ativo da alteração.

   Eis um exemplo da saída desta DMV em formato de tabela após a execução da instrução ALTER DATABASE acima:

   Item	valor
   session_activity_id	97F9474C-0334-4FC5-BFD5-337CDD1F9A21
   resource_type	0
   resource_type_desc	Base de dados
   major_resource_id	AdventureWorks
   minor_resource_id
   operation	ALTER DATABASE
   state	1
   state_desc	IN_PROGRESS
   percent_complete	0
   error_code	0
   error_desc
   error_severity	0
   error_state	0
   hora de início	[data e hora]
   last_modify_time	[data e hora]

   Durante uma alteração do objetivo de serviço, as consultas na base de dados são permitidas antes à implementação da alteração final. As aplicações não poderão estabelecer ligação durante um breve período de tempo. No Azure SQL Managed Instance, uma alteração de escalão permite consultas e ligações, mas impede todas as operações de bases de dados, como a criação de novas bases de dados. Nesses casos, você recebe a seguinte mensagem de erro: "A operação não pôde ser concluída porque uma alteração da camada de serviço está em andamento para a instância gerenciada '[servidor]'. Aguarde pela conclusão da operação em curso e tente novamente".

8. Quando isso for feito, use as consultas anteriores listadas do get_service_objetive.sql no SSMS para verificar se o novo objetivo de serviço ou camada de serviço de 8 vCores entrou em vigor.

Executar a carga de trabalho após o aumento vertical

Agora que a base de dados tem mais capacidade de CPU, vamos executar a carga de trabalho que fizemos no exercício anterior para observar se há uma melhoria do desempenho.

1. Agora que o dimensionamento está concluído, verifique se a duração da carga de trabalho está mais rápida e se as esperas nos recursos da CPU diminuíram. Execute a carga de trabalho novamente usando o comando sqlworkload.cmd executado no exercício anterior.

2. No SSMS, execute a mesma consulta do primeiro exercício deste módulo para observar os resultados do script dmdbresourcestats.sql:

   SELECT * FROM sys.dm_db_resource_stats;
   

   Deverá verificar se a utilização média de recursos da CPU diminuiu em relação à utilização de quase 100 por cento no exercício anterior. Normalmente, sys.dm_db_resource_stats exibe uma hora de atividade. O redimensionamento do banco de dados faz com que sys.dm_db_resource_stats seja redefinido.

3. No SQL Server Management Studio, execute a mesma consulta do primeiro exercício deste módulo para observar os resultados do script dmexecrequests.sql.

   SELECT er.session_id, er.status, er.command, er.wait_type, er.last_wait_type, er.wait_resource, er.wait_time
   FROM sys.dm_exec_requests er
   INNER JOIN sys.dm_exec_sessions es
   ON er.session_id = es.session_id
   AND es.is_user_process = 1;
   

   Verá que existem consultas com o estado RUNNING (Em Execução). Tal significa que os nossos trabalhos têm mais capacidade da CPU para executar.

4. Observe a duração da nova carga de trabalho. A duração da carga de trabalho de sqlworkload.cmd deve agora ser muito menor e durar aproximadamente 25 a 30 segundos.

Observar os relatórios do Arquivo de Consultas

Vejamos os mesmos relatórios do Arquivo de Consultas tal como fizemos no exercício anterior.

1. Através das mesmas técnicas utilizadas no primeiro exercício deste módulo, vejamos o relatório Top Resource Consuming Queries (Principal recurso de consultas de consumo) do SQL Server Management Studio:

   

   Ser-lhe-ão apresentadas duas consultas (query_id). Trata-se da mesma consulta, mas aparecem como valores query_id diferentes no Arquivo de Consultas, porque a operação de dimensionamento exigiu um reinício e a consulta teve de ser recompilada. No relatório, poderá constatar que a duração média e global foi significativamente menor.

2. Observe também o relatório Estatísticas de espera de consulta e selecione a barra de espera da CPU. Poderá constatar que o tempo de espera médio da consulta é menor e que a percentagem da duração geral é inferior. Trata-se de uma boa indicação de que a CPU não constitui um estrangulamento de recursos quando a base de dados tem um número inferior de vCores:

   

3. Pode fechar todas as janelas do editor de relatórios e consultas. Deixe o SSMS conectado, porque você precisará dele no próximo exercício.

Observar as alterações das Métricas do Azure

1. Vá para o banco de dados AdventureWorks no portal do Azure e examine a guia Monitoramento no painel Visão geral novamente para Utilização de computação:

   

   Repare que, em caso de utilização elevada de CPU, a duração é mais curta, o que representa uma diminuição global dos recursos de CPU necessários para executar a carga de trabalho.

2. Este gráfico pode ser algo enganador. No menu Monitoramento , use Métricas e defina a Métrica como limite de CPU. O gráfico de comparação de CPU tem um aspeto semelhante ao seguinte:

   

Gorjeta

Se continuar a aumentar os vCores desta base de dados, poderá melhorar o desempenho até um limiar em que todas as consultas tenham muitos recursos da CPU. Tal não significa que tenha de corresponder o número de vCores ao número de utilizadores simultâneos da sua carga de trabalho. Além disso, você pode alterar a Camada de Preço para usar a Camada de Computação sem Servidor, em vez de Provisionada. Tal ajuda a garantir uma abordagem mais dimensionada de forma automática a uma carga de trabalho. Por exemplo, se você escolher um valor vCore mínimo de 2 para essa carga de trabalho e um valor máximo de vCore de 8, essa carga de trabalho será imediatamente dimensionada para 8 vCores.

No próximo exercício, você observará um problema de desempenho e o resolverá aplicando as práticas recomendadas para o desempenho do aplicativo.

Continuar