Exercício – Verificar a Base de Dados SQL do Azure

10 minutos

Agora que você viu como o SQL do Azure aparece no SQL Server Management Studio (SSMS), você 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, Azure SQL e Banco de Dados do Azure para PostgreSQL. Faça um breve tour para se familiarizar.

Ligação ao Azure Data Studio

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

Se lhe for pedido para ativar funcionalidades de pré-visualização, selecione Sim.

Se você não tiver essa janela ou quiser adicionar outra conexão, selecione o botão Nova conexão na barra Servidores . No exemplo seguinte, também pode obter uma pré-visualização da aparência da ligação do SQL Server. Neste exercício, você não se conecta ao SQL Server.

Ligue-se ao servidor lógico da Base de Dados SQL do Azure. Preencha os Detalhes da Conexão com os seguintes valores e selecione Conectar.

Parâmetro	Value
Tipo de ligação	Microsoft SQL Server
Servidor	Introduza o nome do servidor lógico
Tipo de autenticação	SQL Login: (Início de Sessão do SQL)
Nome de utilizador	cloudadmin
Palavra-passe	Introduza a palavra-passe da conta cloudadmin
Memorizar palavra-passe	Selecionado
Base de dados	AdventureWorks
Grupo de servidores	Deixar como `<Default>`
Nome (opcional)	Deixar em branco

No separador Ligações, em Servidores, deverá agora ver a ligação da Base de Dados SQL do Azure A conexão do SQL Server mostrada na imagem a seguir é apenas para comparação.
A execução de consultas no Azure Data Studio é semelhante ao SSMS. Clique com o botão direito do rato numa base de dados ou nome do servidor e selecione Nova consulta.
Para o Banco de Dados SQL do Azure, como você não está recebendo um servidor completo, não há suporte para USE [DatabaseName] para alterar o contexto do banco de dados. Você deve alterar a conexão para se conectar especificamente ao banco de dados no qual deseja executar uma consulta ou usar a lista suspensa. Altere para o contexto do seu AdventureWorks banco de dados selecionando a opção ao lado de master e execute SELECT @@VERSION.

Mais adiante neste exercício, você mergulhará no motivo pelo qual esse resultado é diferente do que você obtém no SQL Server.

Configurar o acesso fácil aos ficheiros com o Azure Data Studio

Agora que estabeleceu ligação, talvez queira uma forma fácil de aceder aos scripts e blocos de notas do Jupyter. Os blocos de notas do Jupyter são uma forma de integrar código executável com texto. Se não estiver familiarizado com os blocos de notas do Jupyter, estará em breve.

No Azure Data Studio, selecione Ficheiro>Abrir Pasta.
Navegue para o local onde extraiu o ficheiro zip dos recursos para este exercício. Se você seguiu os pré-requisitos, o caminho deve ser semelhante a C:\Users\<machine-username>\mslearn-azure-sql-fundamentals. Quando chegar lá, selecione Selecionar Pasta. Se solicitado, selecione Sim, confio nos autores.
Em seguida, selecione o ícone Explorador na barra de tarefas esquerda para navegar pelos ficheiros do módulo. Esta pasta contém todos os recursos necessários para o caminho de aprendizagem sobre os fundamentos do SQL do Azure, portanto, você só precisa baixar e configurar essas informações uma vez.

Ao longo do módulo e dos exercícios do caminho de aprendizagem, você é instruído em vários pontos a abrir um arquivo de bloco de anotações que tenha a seguinte extensão de nome de arquivo: .ipynb. Pode aceder ao bloco de notas diretamente a partir daqui. Em alternativa, pode aceder a partir do separador com o ícone de Bloco de notas.

Verificar a implementação

Depois de implantar uma instância do SQL, você normalmente executa consultas para verificar sua implantação. No SQL do Azure, algumas destas consultas diferem das do SQL Server. Nesta etapa, você verá o que muda o SQL Server, como eles mudam e o que há de novo.

Para concluir este exercício, existem duas opções:

T-SQL no SQL Server Management Studio
Blocos de Notas do SQL no Azure Data Studio

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

Opção 1: T-SQL no SSMS

Nesta opção, você percorre algumas consultas comuns em funções do sistema, exibições de gerenciamento dinâmico (DMVs) e exibições de catálogo que podem ser usadas após a implantação no SSMS. Você vê quais funcionam da mesma forma que o SQL Server, quais não funcionam e quais são novos no Azure SQL.

Se ainda não o tiver feito, ligue-se ao servidor lógico da Base de Dados SQL do Azure no SQL Server Management Studio.
Clique com o botão direito do mouse no AdventureWorks banco de dados e selecione Nova consulta.
Verifique a versão que implementou ao executar a bem conhecida função do sistema @@VERSION.
```
SELECT @@VERSION
```
O resultado parece algo diferente do SQL Server. Você pode dizer que esse servidor é o SQL do Azure, que não tem versões. A Base de Dados SQL do Azure inclui as atualizações de versão mais recentes do SQL Server. Contudo, a função do sistema @@VERSION é um método comum para verificar se pode “consultar” o SQL Server.
Determine o tipo específico de implementação do SQL do Azure, com base no número devolvido:
- 1: Motor Pessoal ou Desktop
- 2: Padrão
- 3: Empresa
- 4: Expresso
- 5: Banco de dados SQL
- 6: SQL Data Warehouse
- 8: Instância gerenciada SQL
Execute o seguinte comando T-SQL para ver se 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 do SQL ou o SQL Server Enterprise. Não há nenhum número especial para o SQL Server nas Máquinas Virtuais do Azure. O número corresponde à edição que você instalou na máquina virtual. O Personal ou Desktop Engine é uma edição anterior que já não é utilizada com o SQL Server.
Examine as visualizações sys.databases do catálogo e sys.objectso . Normalmente, você examina essas exibições 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 msdbdo sistema , tempdbe model não estão listados. Apenas master e seu banco de dados de usuários são listados. O master banco de dados em um servidor lógico SQL do Azure não é o mesmo que o banco de dados físico master instalado com o SQL Server. Na Instância Gerenciada 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 do sistema, tabelas internas e objetos de usuário para o banco de dados de exemplo AdventureWorksLT .
Verifique se todos os agendadores estão online e se você está detetando 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';
```
Dois VISIBLE ONLINE agendadores são o que você esperaria quando dois vCores estão disponíveis para a instância do SQL Server onde seu banco de dados SQL é implantado.
Para uma implantação do SQL Server, normalmente você pode olhar para DMVs como sys.dm_process_memory ver limites para CPU, memória e trabalhadores. Este DMV não tem suporte com o Banco de Dados SQL do Azure, porque o usuário não expõe ou controla os detalhes do host que dá suporte ao banco de dados. Você pode usar o DMV sys.dm_user_db_resource_governance para revisar as capacidades e os limites do banco de dados SQL implantado. Você também pode usar sys.dm_instance_resource_governance na Instância Gerenciada SQL do Azure.

Execute e analise os seguintes resultados da consulta. Compare os resultados com sua camada de preço e os limites documentados para sua camada implantada. O slo_name é o Objetivo de Nível de Serviço (SLO) que declara a opção de implementação, o escalão de serviço, o hardware e o valor de computação. Além disso, como o Banco de Dados SQL do Azure usa Objetos de Trabalho do Windows para outros limites de recursos, como memória, você pode usar o sys.dm_os_job_object DMV 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 olhar para uma implementação do SQL Server é examinar uma lista de pedidos ativos. Assim como o SQL Server, você pode usar sys.dm_exec_requests para exibir 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 a Instância Gerenciada do SQL. Este Detran mostra apenas solicitações ativas relacionadas ao seu banco de dados, incluindo tarefas em segundo plano ou tarefas em segundo plano que não têm um contexto de banco de dados que aparece como master. Esse comportamento é devido à natureza de uma implantação do Banco de Dados SQL do Azure.

Opção 2: Blocos de Anotações SQL no Azure Data Studio

Para essa opção, use o bloco de anotações VerifyDeployment.ipynb. Ele está em 02-DeployAndConfigure\verifydeployment\VerifyDeployment.ipynb no repositório GitHub ou no arquivo zip baixado anteriormente. Navegue até esse arquivo no Azure Data Studio para concluir esta parte do exercício e retorne aqui. Na mesma pasta, você também pode encontrar blocos de anotações extras que contêm os resultados das mesmas consultas na Instância Gerenciada SQL do Azure e no SQL Server 2019.