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), puede 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 tiene 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. En este ejercicio no se conectará a SQL Server.

Conéctese al servidor lógico de Azure SQL Database. Complete Detalles de conexión con los valores siguientes 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.
En el caso de Azure SQL Database, como no se obtiene un servidor completo, USE [DatabaseName] no se admite para cambiar el contexto de la base de datos. Debe 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. Cambie al contexto de la base de datos AdventureWorks. Para hacerlo, seleccione la opción situada 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. Si el sistema le pregunta, seleccione Sí, confío en los autores.
A continuación, seleccione el icono de Explorer en la barra de tareas de la izquierda para navegar por los archivos del módulo. 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 descargar y configurar esta información una vez.

A lo largo de los ejercicios de la ruta de aprendizaje y del módulo, se le indica en varios puntos que abran un archivo de cuaderno que tenga la siguiente extensión de nombre de archivo: .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

Después de implementar una instancia de SQL, por lo general, 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 este servidor es 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. 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.
Examine las vistas de catálogo sys.databases y sys.objects. Por lo general, consulta estas vistas 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 aparecen las bases de datos del sistema msdb, tempdb y model. Solo se enumeran la base de datos maestra y la de usuario. La base de datos maestra de un servidor de bases 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.

Sin embargo, sys.objects es similar a una instancia normal de SQL Server. Esto es verdadero 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 se miran las vistas 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 vista DMV sys.dm_user_db_resource_governance para revisar la capacidad y los límites de 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. Compare los resultados 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 otros límites de recursos (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_requests para 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. Este comportamiento 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, use el cuaderno VerifyDeployment.ipynb. Está en 02-DeployAndConfigure\verifydeployment\VerifyDeployment.ipynb en el repositorio de GitHub o en el archivo ZIP que ha descargado anteriormente. 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