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

10 minutos

Agora que você já viu como o SQL do Azure aparece no SQL Server Management Studio (SSMS), pode explorar uma ferramenta de código aberto chamada Azure Data Studio. O Azure Data Studio fornece um editor leve e outras ferramentas para interagir com os Serviços de Dados do Azure, como SQL Server local, SQL do Azure e Banco de Dados do Azure para PostgreSQL. Faça um breve tour para se familiarizar.

Conectar-se com o Azure Data Studio

No seu dispositivo local, abra o Azure Data Studio. Ao abrir pela primeira vez, você será solicitado a fazer uma conexão.

Se perguntado se deseja habilitar a versão prévia dos recursos, selecione Sim.

Se você não vir essa janela ou, a qualquer momento, desejar adicionar outra conexão, pressione o botão Nova conexão na barra Servidores. No exemplo a seguir, você também obtém uma visualização da aparência de uma conexão do SQL Server. Neste exercício, você não se conectará ao SQL Server.

Conecte-se ao servidor lógico do Banco de Dados SQL do Azure. Conclua Detalhes da conexão com os seguintes valores e selecione Conectar.

Parâmetro	Valor
Tipo de conexão	Microsoft SQL Server
Servidor	Insira o nome do servidor lógico
Tipo de autenticação	Logon do SQL
Nome de usuário	cloudadmin
Senha	Insira a senha para a conta cloudadmin
Lembrar senha	Selecionado
Banco de dados	AdventureWorks
Grupo de servidores	Deixe como `<Default>`
Nome (opcional)	Deixar em branco

Na guia Conexões, em Servidores, agora a sua conexão de Banco de Dados SQL do Azure deverá estar visível. A conexão do SQL Server mostrada na imagem a seguir serve apenas para comparação.
A execução de consultas no Azure Data Studio é semelhante à execução de consultas no SSMS. Clique com o botão direito do mouse em um nome do servidor ou em um banco de dados e selecione Nova consulta.
Para o Banco de Dados SQL do Azure, como você não está obtendo um servidor completo, não há suporte para o USE [DatabaseName] alterar o contexto do banco de dados. Você precisa alterar a conexão para se conectar especificamente ao banco de dados no qual deseja executar uma consulta ou usar o menu suspenso. Altere para o contexto de seu banco de dados AdventureWorks selecionando a opção ao lado de master e execute SELECT @@VERSION.

Mais adiante neste exercício, você se aprofundará no motivo pelo qual esse resultado é diferente do que você vê no SQL Server.

Configurar o acesso fácil a arquivos com o Azure Data Studio

Agora que você está conectado, talvez queira uma forma fácil de acessar scripts e Jupyter Notebooks. Um Jupyter Notebook é uma forma de integrar o código executável com o texto. Se você ainda não está familiarizado com os Jupyter Notebooks, isso mudará em breve.

No Azure Data Studio, selecione Arquivo>Abrir Pasta.
Navegue até onde você extraiu o arquivo zip dos recursos para este exercício. Se você seguiu os pré-requisitos, o caminho deverá ser de semelhante a C:\Users\<machine-username>\mslearn-azure-sql-fundamentals. Quando estiver lá, clique em Selecionar Pasta. Se solicitado, selecione Sim, eu confio nos autores.
Em seguida, selecione o ícone Explorer na barra de tarefas à esquerda para navegar pelos arquivos no módulo. Essa pasta contém todos os recursos necessários para o roteiro de aprendizagem sobre os princípios básicos do SQL do Azure, portanto, você só precisa fazer o download e configurar essas informações uma vez!

Ao longo do módulo e dos exercícios do roteiro de aprendizagem, você é instruído em vários pontos a abrir um arquivo notebook que tenha a seguinte extensão de nome de arquivo: .ipynb. Você pode acessar o notebook diretamente aqui. Como alternativa, é possível acessá-lo na guia do ícone Notebook.

Verificar a implantação

Após implantar uma instância do SQL, você normalmente executará consultas para verificar a implantação. No SQL do Azure, algumas dessas consultas são diferentes daquelas no SQL Server. Nesta etapa, você verá o que e como as coisas foram alteradas em relação ao SQL Server e quais são as novidades.

Há duas opções para concluir esse exercício:

T-SQL no SSMS
Notebooks do SQL no Azure Data Studio

Ambos os exercícios contêm os mesmos comandos e conteúdo, então você pode escolher a opção que preferir.

Opção 1: T-SQL no SSMS

Nesta opção, examine algumas consultas comuns em relação a funções do sistema, exibições de gerenciamento dinâmico (DMVs) e exibições de catálogo que você pode utilizar após a implantação no SSMS. Veja quais funcionam da mesma forma que o SQL Server, quais não funcionam e quais são novas no SQL do Azure.

Conecte-se ao seu servidor lógico do Banco de Dados SQL do Azure no SSMS se você ainda não estiver conectado.
Clique com o botão direito do mouse no banco de dados AdventureWorks e selecione Nova consulta.
Verifique a versão que você implantou executando a função conhecida do sistema @@VERSION.
```
SELECT @@VERSION
```
O resultado está um pouco diferente do SQL Server. Você pode dizer que esse servidor é o SQL do Azure, que não tem versões. O Banco de Dados SQL do Azure inclui as alterações mais atualizadas embutidas com a versão mais recente do SQL Server. No entanto, usar a função do sistema @@VERSION é um método comum para verificar se você pode "consultar" o SQL Server.
Determine o tipo específico de implantação do SQL do Azure, com base no número retornado:
- 1 = Personal ou Desktop Engine
- 2 = Standard
- 3 = Enterprise
- 4 = Express
- 5 = Banco de Dados SQL
- 6 = SQL Data Warehouse
- 8 = Instância Gerenciada de SQL
Execute o comando T-SQL a seguir para ver se você obtém o resultado esperado.
```
SELECT SERVERPROPERTY('EngineEdition');
```
O resultado é 5, o que faz sentido porque você implantou o Banco de Dados SQL do Azure, não a Instância Gerenciada de SQL nem o SQL Server Enterprise. Não existe um número especial para o SQL Server nas máquinas virtuais do Azure. O número corresponderia à edição que você instalou na máquina virtual. A Personal ou Desktop Engine é uma edição anterior que não é mais usada com o SQL Server.
Examinar as exibições de catálogo sys.databases e sys.objects. Normalmente, essas exibições são usadas para verificar a instalação e o status dos bancos de dados do sistema e para verificar os objetos do sistema em seu banco de dados.
```
SELECT * FROM sys.databases;
SELECT * FROM sys.objects;
```
No primeiro conjunto de resultados, os bancos de dados do sistema msdb, tempdb e model não são listados. Somente o seu banco de dados de usuário e o mestre são listados. O banco de dados mestre de um servidor de banco de dados para o Banco de Dados SQL do Azure não é o mesmo que o banco de dados mestre físico instalado com o SQL Server. Na Instância Gerenciada de SQL do Azure, você vê o conjunto normal de bancos de dados do sistema, como em qualquer Instância do SQL Server.

No entanto, sys.objects é semelhante a uma instância normal do SQL Server. Esse fato é verdadeiro para tabelas de sistema, tabelas internas e objetos de usuário para o banco de dados de amostra AdventureWorksLT.
Verifique se todos os agendadores estão online e se você está detectando as CPUs disponíveis esperadas, considerando que você implantou com um modelo de dois vCore.
```
SELECT * FROM sys.dm_os_schedulers where STATUS = 'VISIBLE ONLINE';
```
A expectativa é de que tenhamos dois agendadores VISIBLE ONLINE quando dois vCores estiverem disponíveis para a instância do SQL Server na qual o Banco de Dados SQL está implantado.
Em uma implantação do SQL Server, você normalmente examina DMVs como sys.dm_process_memory para ver os limites de CPU, memória e trabalhos. Não há suporte para esse DMV com o Banco de Dados SQL do Azure, porque o usuário não expõe nem controla os detalhes do host que dá suporte ao banco de dados. É possível usar a DMV sys.dm_user_db_resource_governance para examinar as capacidades e os limites do banco de dados SQL implantado. Também é possível usar sys.dm_instance_resource_governance na Instância Gerenciada de SQL do Azure.

Execute e examine os resultados de consulta a seguir. Compare os resultados com seu tipo de preço e os limites documentados na sua camada implantada. slo_name é o SLO (Objetivo de Nível de Serviço) que declara a opção de implantação, a camada de serviço, o hardware e o valor de computação. Além disso, como o Banco de Dados SQL do Azure utiliza os Objetos de Trabalho do Windows para outros limites de recursos, como memória, você pode utilizar o DMV sys.dm_os_job_object para ver quais recursos estão disponíveis para a implantação.
```
SELECT * FROM sys.dm_user_db_resource_governance;
```
Uma técnica comum para examinar uma implantação do SQL Server é examinar uma lista de solicitações ativas. Assim como no SQL Server, é possível usar sys.dm_exec_requests para exibir as solicitações SQL em execução no momento.
```
SELECT * FROM sys.dm_exec_requests;
```
Usar sys.dm_exec_requests para o Banco de Dados SQL do Azure é diferente de usá-lo para o SQL Server ou para a Instância Gerenciada de SQL. Esse DMV mostra apenas as solicitações ativas relacionadas ao seu banco de dados, incluindo tarefas em segundo plano ou tarefas em segundo plano que não tenham um contexto de banco de dados que é mostrado como mestre. Esse comportamento se deve à natureza da implantação de um Banco de Dados SQL do Azure, em que cada banco de dados é implantado em sua própria instância do SQL Server.

Opção 2: Notebooks do SQL no Azure Data Studio

Para essa opção, utilize o notebook VerifyDeployment.ipynb. Ele está em 02-DeployAndConfigure\verifydeployment\VerifyDeployment.ipynb no repositório GitHub ou no arquivo zip baixado anteriormente. Acesse o arquivo no Azure Data Studio para concluir essa parte do exercício e retorne aqui. Na mesma pasta, você também encontra notebooks extras que contêm os resultados das mesmas consultas na Instância Gerenciada de SQL do Azure e no SQL Server 2019.

Se não for possível concluir o exercício por qualquer motivo, você poderá examinar os resultados no arquivo de notebook correspondente no GitHub.

Continuar