Exercício – configurar o Banco de Dados SQL do Azure

  • 10 minutos

Agora você viu o portal do Azure, o SSMS (SQL Server Management Studio) e os notebooks do SQL no Azure Data Studio. Outras ferramentas estão disponíveis para você para gerenciar o SQL do Azure. Duas das mais populares são a CLI do Azure e o Azure PowerShell. Elas são semelhantes em termos de funcionalidade. Essa atividade se concentra na CLI do Azure.

Para concluir esta atividade, você pode usar um notebook do PowerShell, que tem o mesmo conceito de um notebook do SQL, mas cuja linguagem de codificação é o PowerShell. Você pode usar notebooks do PowerShell para aproveitar a CLI do Azure ou o Azure PowerShell. Este artigo se concentra nos comandos da CLI do Azure. Nessas duas ferramentas, você também pode usar o Azure Cloud Shell, que é um ambiente de shell interativo que pode ser usado por meio do seu navegador no portal do Azure.

Neste exercício, use o Cloud Shell. Ele já inclui os módulos da CLI do Azure e do Azure PowerShell.

Conectar-se com o Azure Cloud Shell e a CLI do Azure

No exemplo a seguir, explore os efeitos de latência do uso de políticas de conexão diferentes no SQL do Azure.

Execute todos os comandos pelo Cloud Shell. Você pode copiá-los facilmente e selecionar Shift+Insert para colar no terminal.

Observação

No PowerShell usando o Azure Cloud Shell, você pode usar o módulo Az do PowerShell ou a CLI do Azure. Nesta atividade, explore a CLI do Azure, mas comandos semelhantes estão disponíveis para o módulo Az do PowerShell.

  1. Vá para shell.azure.com e entre em sua conta do Azure, se solicitado.

  2. Configure um grupo de recursos padrão e um servidor lógico do Banco de Dados SQL do Azure, para que não seja necessário especificá-los com cada comando az. Execute os comandos a seguir para definir algumas variáveis. Substitua <resource-group> e <your-server> pelos valores que você usou ao criar sua instância SQL no exercício anterior.

    resourceGroup="<resource-group>"
logical_server="<your-server>"
databaseName="AdventureWorks"

  3. Defina os padrões no Cloud Shell para especificar o grupo de recursos padrão e o servidor lógico do Banco de Dados SQL do Azure:

    az configure --defaults group=$resourceGroup sql-server=$logical_server

  4. Execute o seguinte comando para confirmar que os padrões foram configurados:

    az configure --list-defaults

  5. Execute o seguinte comando para mostrar todos os bancos de dados no servidor lógico do Banco de Dados SQL do Azure:

    az sql db list

  6. A lista de bancos de dados tem uma grande quantidade de informações. Execute o seguinte comando para ver apenas as especificações do banco de dados AdventureWorks:

    az sql db show --name $databaseName

  7. Execute o seguinte comando para determinar o uso e o tamanho do banco de dados:

    az sql db list-usages --name $databaseName

Esses exemplos usam os comandos az sql db. Também há comandos relacionados ao servidor lógico do Banco de Dados SQL do Azure. Eles se enquadram no az sql server.

Há comandos semelhantes para az sql mi e az sql midb. Eles são comandos para bancos de dados em uma instância gerenciada, às vezes chamados de bancos de dados gerenciados.

Para obter explicações detalhadas sobre todos os comandos disponíveis, confira a documentação da CLI do Azure.

Gerenciar políticas de conexão com a CLI do Azure

Uma possível aplicação dos comandos da CLI do Azure ou do Azure PowerShell é a atualização da política de conexão. Essa atualização é um exemplo de como você pode gerenciar o SQL do Azure usando uma ferramenta como a CLI do Azure. Neste exemplo, você analisa o Banco de Dados SQL do Azure e seus comandos para gerenciar as políticas de conexão. A implementação é semelhante na Instância Gerenciada de SQL do Azure.

  1. Veja qual é a política atual usando a CLI do Azure.

    az sql server conn-policy show

    Os resultados informam que o tipo de conexão é Default.

  2. Defina a política de conexão como Proxy e determine o tempo da viagem de ida e volta.

    # update policy
az sql server conn-policy update --connection-type Proxy
# confirm update
az sql server conn-policy show

  3. Para testar o tempo de ida e volta, conecte-se usando o SSMS. Em seu dispositivo, abra o SSMS e conecte-se ao seu banco de dados. Clique com o botão direito do mouse no banco de dados e selecione Nova Consulta. Crie uma consulta com o texto a seguir e selecione Consultar>Incluir Estatísticas do Cliente. Nos resultados, o Tempo de espera em respostas do servidor é o melhor indicador de latência de rede. Você pode executar essa consulta algumas vezes para obter uma boa média.

    -- Proxy
SELECT * FROM SalesLT.Product
GO 10

    Após dez avaliações, o tempo de espera médio nas respostas do servidor pode ser aproximadamente 46.6000. Dependendo da conexão com a Internet, os resultados podem variar. Anote o tempo que você observar.

  4. E se você quiser transformar tudo em Redirect para tentar obter uma latência reduzida?

    Para qualquer coisa que esteja fora do Azure, você precisa permitir a comunicação de entrada e saída em portas no intervalo de 11000 a 11999. Abrir essas portas é necessário para a política de conexão Redirect.

    Observação

    Isso provavelmente já está configurado no seu dispositivo local. Caso receba erros nas próximas etapas, talvez seja necessário habilitar as portas mencionadas anteriormente. Para obter mais informações, confira Portas além de 1433 para ADO.NET 4.5.

    Atualize a política de conexão e confirme essa atualização com os dois comandos a seguir.

    # update policy
az sql server conn-policy update --connection-type Redirect
# confirm update
az sql server conn-policy show

  5. Para testar a latência de rede da política Redirect, conecte-se com o SSMS no seu dispositivo local. Crie uma consulta usando o texto a seguir e escolha Incluir Estatísticas de Cliente nos seus resultados. Compare o Tempo de espera em respostas do servidor com a sua consulta para Proxy.

    -- Redirect
SELECT * FROM SalesLT.Product
GO 10

    Após dez avaliações, o tempo de espera médio das respostas do servidor pode ser aproximadamente 25.8000, que é quase metade do obtido com a política de conexão de proxy. Os intervalos exatos variam dependendo da conexão. O tempo deve ser significativamente reduzido em comparação com o teste de proxy anterior.

  6. Para o próximo exercício, defina a política de volta para o padrão usando os seguintes comandos:

    # update policy
az sql server conn-policy update --connection-type Default
# confirm update
az sql server conn-policy show

O redirecionamento é mais rápido porque, após a conexão inicial, você pode ignorar o gateway e ir diretamente para o banco de dados. Esse atalho significa menos saltos, resultando em menos latência. Menos latência ajuda a prevenir gargalos, o que é especialmente importante para aplicativos "verborrágicos". No módulo de desempenho, você aprenderá mais sobre como melhorar e otimizar o desempenho.