Exercício – Elevada disponibilidade do escalão Crítico para a empresa

10 minutos

Neste exercício, vai atualizar a base de dados para o escalão Crítico para a Empresa. Verá como proporciona réplicas de leitura e melhora o desempenho.

Vai utilizar a ferramenta ostress que utilizou no exercício anterior para criar uma carga de trabalho. Em seguida, vai iniciar uma ativação pós-falha com o módulo do Azure PowerShell no Azure Cloud Shell. Por fim, irá ver o efeito da ativação pós-falha na carga de trabalho ostress.

Elevada disponibilidade básica no escalão de serviço Crítico para a Empresa do SQL do Azure

Neste exercício, irá seguir os seguintes passos:

Implementar a base de dados do exercício anterior no escalão Crítico para a Empresa.
Executar a carga de trabalho de ostress.
Utilizar o PowerShell para iniciar uma ativação pós-falha.
Ver os resultados em ostress.
Ligar-se a um secundário legível.

Implementar a mesma base de dados no escalão Crítico para a Empresa

Em um módulo anterior, você aprendeu como dimensionar um banco de dados usando T-SQL. O objetivo deste exercício é atualizar a base de dados que utilizou no exercício anterior de Fins Gerais para Crítico para a Empresa. Você usará o Azure Cloud Shell para atualizar o banco de dados. Como existe um limite para a frequência de ativações pós-falha, vai utilizar a mesma base de dados de exemplo, mas mudar o nome para AdventureWorks-bc.

No terminal do Azure Cloud Shell, no lado direito desta página, execute o seguinte script do PowerShell para configurar o ambiente:

$resourceGroup = "<rgn>Sandbox resource group name</rgn>"
$database = "AdventureWorks-bc"
$server = Get-AzureRmSqlServer -ResourceGroupName $resourceGroup
$server = $server.ServerName

# Specify your default resource group and Azure SQL Database logical server
az configure --defaults group=$resourceGroup sql-server=$server

# Confirm the defaults are set
az configure --list-defaults

Execute este comando para criar uma base de dados no escalão de serviço Crítico para a Empresa:
```
az sql db create --name $database `
--edition BusinessCritical `
--family Gen5 `
--capacity 2 `
--sample-name AdventureWorksLT `
--read-scale Enabled `
--zone-redundant false
```
Este comando demora algum tempo a concluir. Enquanto está em execução, pode analisar alguns dos parâmetros utilizados:
- family: Este parâmetro especifica a geração do hardware. Para ser consistente com o exercício anterior, utilizamos Gen5.
- capacity: Este parâmetro especifica o número de DTUs ou vCores. Para ser consistente com o exercício anterior, utilizamos 2 vCores.
- sample-name: Para ser consistente com o exercício anterior, foi utilizada a amostra da AdventureWorksLT base de dados.
- edition: Este nome de parâmetro é um pouco enganoso. Na realidade, refere-se ao escalão de serviço, o que não é o mesmo que a edição utilizada no SQL Server.
- read-scale: Esta opção não está habilitada por padrão, mas não há nenhum custo adicional associado a ela. Ao ativá-la está a permitir que uma das réplicas secundárias seja utilizada como uma réplica secundária legível.
- zone-redundant: Por padrão, esse parâmetro é definido como false. Poderá defini-lo como verdadeiro se quiser uma implementação “Multi-Az”, sem custos adicionais. Ficará a saber mais sobre as Zonas de Disponibilidade na próxima unidade.
  
  Nota
  
  As Zonas de Disponibilidade estão disponíveis apenas em determinadas regiões. Estão atualmente indisponíveis para o Azure SQL Managed Instance.
Após a base de dados ser criada, deverá ver informações detalhadas sobre as atualizações na saída do Azure Cloud Shell. Verá duas categorias principais (apesar de também ver indicadores em várias outras propriedades):
- currentServiceObjectiveName: Deve ser BC_Gen5_2. BC significa Crítico para a Empresa.
- currentSku:
  - name: Deve ser BC_Gen5.
  - tier: Deve ser BusinessCritical.
Outra forma de verificar o escalão de serviço é aceder à base de dados no portal do Azure. No separador Descrição geral, veja Escalão de preço.

Gorjeta

Existem muitas outras formas de ver essas atualizações. Outra forma é utilizar o SQL Server Management Studio. Se clicar com o botão direito do rato na base de dados e selecionar Propriedades>Configurar SLO, poderá ver as alterações.

Executar a carga de trabalho de ostress

Tal como no exercício anterior, vai utilizar o ostress para consultar repetidamente a base de dados SQL do Azure.

Se você fechou o Prompt de Comando usado no exercício anterior, abra uma nova janela de Prompt de Comando no computador local. Utilize cd para ir para o diretório no repositório que clonou ou transferiu anteriormente e que contém o módulo de disponibilidade. Por exemplo, poderá utilizar este comando:
```
cd C:\Users\username\mslearn-azure-sql-fundamentals\05-Availability
```
A carga de trabalho de ostress liga-se e executa uma consulta simples 50 000 vezes.
Utilize o seguinte script de ostress para executar a carga de trabalho. Substitua serverName pelo nome do servidor lógico da Base de Dados SQL do Azure. Substitua password pela sua palavra-passe. Este comando é ligeiramente diferente do utilizado no exercício anterior. O nome da base de dados é agora AdventureWorks-bc.
```
.\ostress.exe -S"serverName.database.windows.net" -Q"SELECT COUNT(*) FROM SalesLT.Customer" -U"cloudadmin" -d"AdventureWorks-bc" -P"password" -n1 -r50000
```
Se a carga de trabalho estiver a ser executada corretamente, deverá ver o resultado da consulta, 847, a aparecer repetidamente na janela da Linha de Comandos.

Se quiser parar a execução da carga de trabalho ostress antes de esta estar concluída, poderá selecionar CTRL+C no terminal.

Se quiser executar novamente a carga de trabalho, poderá executar de novo o comando.

Iniciar uma ativação pós-falha e ver os resultados

Configure as janelas para que possa ver este browser e a janela da Linha de Comandos ao mesmo tempo.

Execute o seguinte código no terminal do Azure Cloud Shell. Este comando é o mesmo que o utilizado no exercício anterior.

# create a failover
Invoke-AzSqlDatabaseFailover -ResourceGroupName $resourceGroup `
    -ServerName $server `
    -DatabaseName $database

Enquanto este comando estiver em execução, observe todas as alterações apresentadas no terminal. Vai reparar que não consegue aceder à base de dados enquanto a ativação pós-falha ocorre. Este tempo de indisponibilidade é muito curto. Depois de perder a ligação, esta deverá ser restabelecida após cerca de 5 segundos! Esta ativação pós-falha é seis vezes mais rápida do que a do escalão Fins Gerais.

Lembre-se de que os bancos de dados ou instâncias gerenciadas na camada de serviço Crítica para Negócios têm essencialmente um grupo de disponibilidade Always On implantado nos bastidores, portanto, quando você faz failover, tudo o que acontece é uma alteração nos ponteiros no back-end à medida que o Azure redireciona você para um dos secundários. É por isso que a ativação pós-falha é muito mais rápida do que seria nos Fins Gerais.

Ligar à réplica só de leitura

Dado que ativou o parâmetro read-scale, pode utilizar uma das réplicas secundárias para as cargas de trabalho só de leitura. Para aceder à réplica só de leitura nas aplicações, basta adicionar este parâmetro à cadeia de ligação de uma base de dados:

ApplicationIntent=ReadOnly;

No SQL Server Management Studio, crie uma nova ligação de consulta (selecione Ficheiro>Novo>Consulta do Motor de Base de Dados).
Na caixa de diálogo Ligar ao Servidor, utilize a configuração que esteve a utilizar para se ligar ao servidor lógico da Base de Dados SQL do Azure (Ou seja, use Autenticação do SQL Server.) Selecione Opções.
Selecione Propriedades da Ligação e, em seguida, Repor Tudo. Em Ligar à base de dados, selecione Procurar servidor e selecione a base de dados AdventureWorks-bc. Selecione OK.
Selecione Parâmetros de Ligação Adicionais e cole o seguinte na caixa de texto. Selecione Ligar.
```
ApplicationIntent=ReadOnly;
```
Com o SQL Server Management Studio, tem de especificar o servidor e a base de dados às quais se quer ligar no nodo só de leitura. Este procedimento deve ser realizado devido à possível existência de várias bases de dados num servidor que possui capacidades diferentes para base de dados secundárias legíveis.
Para testar, experimente a seguinte consulta na nova consulta do motor da base de dados. Observe os resultados. São o que estava à espera?
```
SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability')
```
Opcionalmente, pode ligar-se novamente e atualizar os Parâmetros de Ligação Adicionais (Substitua ReadOnly por ReadWrite.) Confirme se você está acessando a réplica primária de leitura/gravação. ReadWrite é a predefinição. Assim, se não selecionar nada, obterá isto: