Ejercicio: Comprobación de una base de datos de Azure SQL Database
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 Server 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 amaster
y ejecuteSELECT @@VERSION
.Más adelante en este ejercicio, profundizará en por qué ese resultado es diferente de lo que obtiene 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 debe 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é cosas cambian SQL Server, cómo cambian y 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, recorrerá algunas consultas comunes en 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 SQL Server, cuáles no y cuáles son nuevos 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 de
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: Motor personal o de escritorio
- 2: Estándar
- 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 SQL Managed Instance ni SQL Server Enterprise. No hay ningún número especial para SQL Server en Azure Virtual Machines. El número corresponde a la edición que instaló 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
ysys.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
ymodel
. Solo se muestranmaster
y la base de datos de usuario. La base de datosmaster
de un servidor lógico de Azure SQL no es la misma que la base de datos físicamaster
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 datosAdventureWorksLT
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 dos núcleos virtuales están disponibles para la instancia de SQL Server donde se implementa 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 DMVsys.dm_user_db_resource_governance
para revisar la capacidad y los límites de la base de datos SQL implementada. También puede usarsys.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 DMVsys.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. Esta DMV muestra solo 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 comomaster
. Este comportamiento se debe a la naturaleza de una implementación de Azure SQL Database.
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 puede encontrar cuadernos adicionales que contengan 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.