Ejercicio: Comprobación de una base de datos de Azure SQL Database

10 minutos

Ahora que ha visto cómo aparece Azure SQL en SQL Server Management Studio (SSMS), explorará una herramienta de código abierto denominada Azure Data Studio. Azure Data Studio proporciona un editor ligero y otras herramientas para interactuar con Azure Data Services como, por ejemplo, SQL Server local, Azure SQL y Azure Database for PostgreSQL. Echemos un vistazo breve para que se familiarice.

Conexión con Azure Data Studio

En el dispositivo local, abra Azure Data Studio. Al abrirlo por primera vez, se le pedirá que realice una conexión.

Si se le pide que habilite las características en vista previa, seleccione Sí.

Si no ve esta ventana, o en algún momento quiere agregar otra conexión, puede seleccionar el botón Nueva conexión de la barra Servidores. En el ejemplo siguiente, también obtendrá una vista previa del aspecto que tendría una conexión a SQL Server. Pero en este ejercicio no se conectará a SQL Server.

Conéctese al servidor lógico de Azure SQL Database. Complete el cuadro de inicio de sesión con los siguientes valores y seleccione Conectar.

Parámetro	Value
Tipo de conexión	Microsoft SQL Server
Servidor	Escriba el nombre del servidor lógico
Tipo de autenticación	Inicio de sesión de SQL
Nombre de usuario	cloudadmin
Contraseña	Especifique la contraseña de la cuenta de cloudadmin.
Recordar contraseña	Seleccionado
Base de datos	AdventureWorks
Grupo de servidores	Déjelo como `<Default>`.
Nombre (opcional)	Déjelo en blanco.

En la pestaña Conexiones, en Servidores, ahora debería ver la conexión de Azure SQL Database. (La conexión de SQL Server que se muestra en la imagen siguiente es solo para compararlas).
La ejecución de consultas en Azure Data Studio es similar a SSMS. Haga clic con el botón derecho en un nombre de servidor o base de datos y seleccione Nueva consulta.
Para Azure SQL Database, como no se obtiene un "servidor" completo, USE [nombre_de_base_de_datos] no se admite para cambiar el contexto de la base de datos. Tiene que cambiar la conexión para conectarse específicamente a la base de datos en la que quiere ejecutar una consulta o usar el menú desplegable. Para cambiar al contexto de la base de datos AdventureWorks, seleccione el menú desplegable situado junto a master y ejecute SELECT @@VERSION.

Más adelante en este ejercicio, profundizará en el motivo por el que el resultado es diferente de lo que se ve en SQL Server.

Configuración del acceso sencillo a archivos con Azure Data Studio

Ahora que está conectado, es posible que quiera una forma sencilla de acceder a scripts y cuadernos de Jupyter. Un cuaderno de Jupyter es una forma de integrar el código ejecutable con texto. Si no está familiarizado con los cuadernos de Jupyter, pronto lo estará.

En Azure Data Studio, seleccione Archivo>Abrir carpeta.
Vaya a la ubicación donde haya extraído el archivo ZIP de los recursos de este ejercicio. Si ha seguido los requisitos previos, la ruta de acceso debe ser similar a C:\Users\<machine-username>\mslearn-azure-sql-fundamentals. Cuando esté allí, elija Seleccionar carpeta.
A continuación, seleccione el icono de Explorer en la barra de tareas de la izquierda para navegar por los archivos del módulo. Tenga en cuenta que esta carpeta contiene todos los recursos necesarios para la ruta de aprendizaje sobre los aspectos básicos de Azure SQL, por lo que solo tiene que descargarlo y configurarlo una vez.

A lo largo de los ejercicios del módulo y la ruta de aprendizaje, en varios momentos se le pedirá que abra un cuaderno (el archivo que finaliza en .ipynb). Pueda acceder directamente al cuaderno desde aquí. Como alternativa, puede acceder desde la pestaña del icono Notebook.

Comprobación de la implementación

Una vez que haya implementado una instancia de SQL, normalmente ejecutará algunas consultas para comprobar la implementación. En Azure SQL, algunas de estas consultas varían con respecto a SQL Server. En este paso, verá qué y cómo cambia el proceso con respecto a SQL Server, así como las novedades.

Existen dos opciones para completar este ejercicio:

T-SQL en SSMS
Cuadernos de SQL en Azure Data Studio

Los dos ejercicios contienen los mismos comandos y el mismo contenido, por lo que puede elegir la opción que prefiera.

Opción 1: T-SQL en SSMS

En esta opción, se le guiará por algunas consultas comunes de las funciones del sistema, vistas de administración dinámica (DMV) y vistas de catálogo que puede usar después de la implementación en SSMS. Verá cuáles funcionan igual que en SQL Server, cuáles no y cuáles son nuevas en Azure SQL.

Conéctese al servidor lógico de Azure SQL Database en SSMS, si todavía no lo ha hecho.
Haga clic con el botón derecho en la base de datos AdventureWorks y seleccione Nueva consulta.
Compruebe la versión que ha implementado mediante la ejecución de la conocida función del sistema @@VERSION.
```
SELECT @@VERSION
```
Los resultados son algo diferentes a los de SQL Server. Puede apreciar que se trata de Azure SQL, que no tiene versiones. Azure SQL Database incluye los cambios más actualizados en línea con la versión más reciente de SQL Server. Pero el uso de la función del sistema @@VERSION es un método común para comprobar que se puede "consultar" SQL Server.
Determine el tipo específico de implementación de Azure SQL en función del número devuelto:

1 = Personal o Desktop Engine
2 = Standard
3 = Enterprise
4 = Express
5 = SQL Database
6 = SQL Data Warehouse
8 = SQL Managed Instance

Ejecute el siguiente comando de T-SQL para ver si obtiene el resultado esperado.
```
SELECT SERVERPROPERTY('EngineEdition');
```
El resultado es 5, lo que tiene sentido porque ha implementado Azure SQL Database, no Azure SQL Managed Instance ni SQL Server Enterprise. Observe que no hay ningún número especial para SQL Server en Azure Virtual Machines. El número se corresponderá con la edición que ha instalado en la máquina virtual. Personal o Desktop Engine es una edición anterior que ya no se usa con SQL Server.
Ahora se examinarán las vistas de catálogo sys.databases y sys.objects. Normalmente, se examinan para comprobar la instalación y el estado de las bases de datos del sistema, y para comprobar los objetos del sistema en la base de datos.
```
SELECT * FROM sys.databases;
SELECT * FROM sys.objects;
```
En el primer conjunto de resultados, no se muestran las bases de datos del sistema msdb, tempdb y model. Solo se enumeran la base de datos maestra y la de usuario. Esto se debe a que la base de datos maestra de un servidor de base de datos para Azure SQL Database no es la misma que la base de datos maestra física instalada con SQL Server. En Azure SQL Managed Instance, verá el conjunto normal de bases de datos del sistema como con cualquier instancia de SQL Server.

Pero sys.objects es similar a una instancia de SQL Server normal. Es así para las tablas del sistema, las tablas internas y los objetos de usuario para la base de datos AdventureWorksLT de ejemplo.
Compruebe que todos los programadores están en línea y que detecta las CPU disponibles esperadas, si ha implementado con un modelo de dos núcleos virtuales.
```
SELECT * FROM sys.dm_os_schedulers where STATUS = 'VISIBLE ONLINE';
```
Dos programadores VISIBLE ONLINE son lo que cabría esperar cuando hay dos núcleos virtuales disponibles para la instancia de SQL Server en la que ha implementado la base de datos SQL.
En el caso de una implementación de SQL Server, normalmente examinaría DMV como sys.dm_process_memory para ver los límites de CPU, memoria y trabajos. Estas DMV no se admiten con Azure SQL Database, ya que el usuario no expone ni controla los detalles del host que admite la base de datos. Puede usar la DMV sys.dm_user_db_resource_governance a fin de revisar funciones y límites para la base de datos SQL implementada. También puede usar sys.dm_instance_resource_governance en Azure SQL Managed Instance.

Ejecute y revise los resultados de la consulta siguiente. Compárelos con el plan de tarifa y los límites documentados para el nivel implementado. slo_name es el objetivo de nivel de servicio (SLO) que indica la opción de implementación, el nivel de servicio, el hardware y la cantidad de proceso. Además, dado que Azure SQL Database usa objetos de trabajo de Windows para obtener límites de recursos adicionales (como memoria), puede usar la DMV sys.dm_os_job_object para ver qué recursos están disponibles para la implementación.
```
SELECT * FROM sys.dm_user_db_resource_governance;
```
Una técnica común para examinar una implementación de SQL Server consiste en examinar una lista de solicitudes activas. Al igual que SQL Server, puede usar sys.dm_exec_requests para ver las solicitudes SQL que se están ejecutando actualmente.
```
SELECT * FROM sys.dm_exec_requests;
```
El uso de sys.dm_exec_requestspara Azure SQL Database es diferente al de SQL Server o SQL Managed Instance. En esta DMV solo se muestran las solicitudes activas relacionadas con la base de datos, incluidas las tareas en segundo plano (o las tareas en segundo plano que no tienen un contexto de base de datos que se muestra como "maestra"). Esto se debe a la naturaleza de una implementación de Azure SQL Database donde cada base de datos se implementa en una instancia propia de SQL Server.

Opción 2: cuadernos de SQL en Azure Data Studio

Para esta opción, usará el cuaderno VerifyDeployment.ipynb. Está bajo 02-DeployAndConfigure\verifydeployment\VerifyDeployment.ipynb en el repositorio de GitHub o en el archivo ZIP que ha descargado antes. Vaya a ese archivo en Azure Data Studio para completar esta parte del ejercicio y después vuelva aquí. En la misma carpeta, también encontrará cuadernos adicionales con los resultados de las mismas consultas en Azure SQL Managed Instance y SQL Server 2019.

Si no puede completar el ejercicio por cualquier motivo, puede revisar los resultados en el archivo de cuaderno correspondiente en GitHub.

Continuar