DP – 300 Administración de soluciones de Microsoft Azure SQL

Este curso proporciona a los estudiantes el conocimiento y las habilidades para administrar una infraestructura de
base de datos de SQL Server para bases de datos relacionales en la nube, locales e híbridas y quienes trabajan con las
ofertas de bases de datos relacionales PaaS de Microsoft. Además, será útil para las personas que desarrollan
aplicaciones que entregan contenido de bases de datos relacionales basadas en SQL.

Introducción a la administración de bases de datos de Azure

Preparación para el mantenimiento de bases de datos SQL en Azure

Descripción de los roles de la

Plataforma inteligente de datos
Microsoft
El rol Administrador de base de datos de Azure es solo uno de los que pueden ocupar
los profesionales que trabajan con los servicios de la Plataforma inteligente de datos
Microsoft. Microsoft ofrece cinco certificaciones basadas en roles diferentes para
personas cuyas responsabilidades de trabajo principales son los datos centrados en la
nube.

Descripción de SQL Server en una máquina virtual de Azure

Una instancia de SQL Server que se ejecuta en una máquina virtual de Azure (IaaS) es equivalente a una instancia de
SQL Server en el entorno local. Observará que varias características descritas para SQL Server en la máquina virtual
de Azure son aplicables a todos los servidores de SQL locales.

En muchas aplicaciones será necesario que SQL Server se ejecute en una máquina virtual. Entre las razones se
incluyen las siguientes:

 Compatibilidad e incompatibilidad general de aplicaciones: para las aplicaciones que necesitan una versión
anterior de SQL Server para el soporte técnico del proveedor. Además, algunos servicios de aplicación
pueden tener un requisito para instalarse con la instancia de base de datos de una manera que no sea
compatible con una oferta de PaaS.

 Uso de otros servicios de SQL Server: para maximizar las licencias, muchos usuarios deciden ejecutar
SQL Server Analysis Services (SSAS), SQL Server Integration Services (SSIS) o SQL Server Reporting Services
(SSRS) en la misma máquina que el motor de base de datos.

Versiones de SQL Server disponibles

Microsoft mantiene las imágenes de todas las versiones compatibles de SQL Server en Azure Marketplace. Si necesita
una versión anterior, que está cubierta por un contrato de soporte técnico extendido, debe instalar archivos binarios
de SQL Server propios.

Soluciones de copia de seguridad

En versiones recientes de SQL Server, Microsoft ha introducido varias características para admitir la ejecución de
SQL Server en una máquina virtual de Azure. Aquí se centrará en dos características clave de copia de seguridad:

 Copia de seguridad en dirección URL

 Azure Backup

La copia de seguridad en la dirección URL permite usar la sintaxis de copia de seguridad estándar para realizar copias
de seguridad de las bases de datos en el servicio Azure Blob Storage, mientras que Azure Backup para SQL Server en
Virtual Machines ofrece una solución de copia de seguridad empresarial completa que controla automáticamente las
copias de seguridad en toda la infraestructura.

Opciones de implementación

Todos los recursos de Azure comparten un proveedor común conocido como Azure Resource Manager que actúa
como servicio de administración e implementación para servicios en la nube. Aunque hay muchas maneras de
implementar recursos de Azure, en última instancia, todos terminan en documentos JSON conocidos como plantilla
de Azure Resource Manager, que es una de las opciones de implementación para los recursos de Azure.

La principal diferencia entre estos procesos es que las plantillas de Azure Resource Manager son un enfoque de
implementación declarativa que describe la estructura y el estado deseados de los recursos que se van a
implementar, mientras que los demás métodos se pueden describir como imperativos, en los que se usan modelos
de procedimientos para especificar explícitamente un proceso que se va a ejecutar. En las implementaciones a gran
escala, el enfoque declarativo es mejor y debe seguirse.

Introducción a Azure Storage

Azure ofrece un modelo de almacenamiento basado en objetos totalmente redundante y hay algunos aspectos que
debe tener en cuenta al diseñar e implementar la arquitectura de Virtual Machines. En cuanto a las máquinas
virtuales, puede usar cuatro tipos de almacenamiento:

 Estándar

 SSD estándar
  SSD Premium

 Disco Ultra

Para los archivos de datos y de registro de transacciones de SQL Server en producción, solo debe usar
almacenamiento SSD prémium y Disco Ultra. Con el almacenamiento premium, verá latencias en el intervalo de 5 a
10 ms en un sistema configurado correctamente. Como alternativa, con Disco Ultra puede tener una latencia inferior
a milisegundos, pero es probable que vea cargas de trabajo de 1 a 2 ms en el mundo real. Puede usar
almacenamiento Estándar para las copias de seguridad de la base de datos, ya que el rendimiento es adecuado para
la mayoría de las cargas de trabajo de copia de seguridad y restauración.

Alta disponibilidad en Azure

La plataforma Azure está diseñada para ser tolerante a errores y proporciona una recuperación rápida de
interrupciones del servicio y errores transitorios. De hecho, muchas organizaciones ven mayores niveles de
disponibilidad en implementaciones de máquina virtual única que las que tenían anteriormente en sus entornos
locales. Microsoft garantiza un tiempo de actividad de al menos el 99,9 % para una máquina virtual de Azure de
instancia única, cuando se usa SSD prémium o Disco Ultra para todos los discos.

Azure ofrece varias características para admitir la alta disponibilidad, como conjuntos de disponibilidad, zonas de
disponibilidad y técnicas de equilibrio de carga que proporcionan alta disponibilidad mediante la distribución del
tráfico entrante entre Virtual Machines.

Diseño de Azure SQL Database para aplicaciones nativas de nube

Azure SQL Database es una plataforma como servicio (PaaS) que proporciona funcionalidades de escalabilidad
elevadas, puede ser una excelente solución para determinadas cargas de trabajo y necesita esfuerzos de
mantenimiento mínimos.

Azure SQL Database está destinada al desarrollo de aplicaciones nuevas, ya que proporciona a los desarrolladores
una gran flexibilidad para crear servicios de aplicación y opciones de implementación granulares a gran escala.
SQL Database ofrece una solución de bajo mantenimiento que puede ser una excelente opción para determinadas
cargas de trabajo.

Modelo de compra

SQL Database incluye dos modelos de compra principales: modelo basado en núcleo virtual y modelo basado en
DTU. Cada modelo de compra ofrece los siguientes niveles de servicio:

Basado en núcleos virtuales

En este modelo de compra, los recursos de proceso y almacenamiento se desacoplan. Esto significa que puede
escalar los recursos de almacenamiento y proceso de forma independiente entre sí. A continuación se enumeran los
niveles de servicio disponibles:
Basado en DTU

En el modelo de DTU, hay tres niveles de servicio disponibles: Básico, Estándar y Premium. Los recursos de proceso y
almacenamiento dependen del nivel de DTU y proporcionan varias funcionalidades de rendimiento con un límite de
almacenamiento fijo, retención de copia de seguridad y costo.

Por ejemplo, si la base de datos crece hasta el punto en que alcanza el límite máximo de almacenamiento, tendría
que aumentar la capacidad de DTU, incluso si el uso del proceso es bajo.

La operación de escalado en SQL Database puede producir una breve interrupción de la conexión al final. Hay dos
cambios principales que desencadenan este comportamiento:

 Una vez que se inicia una operación de escalado que necesita una conmutación por error interna.

 Al agregar bases de datos al grupo elástico, o quitarlas.

Puede usar una lógica de reintento adecuada en la aplicación para controlar los errores de conexión.

Nota

Azure SQL Managed Instance no admite el modelo de compra basado en DTU.

Nivel de servicio de informática sin servidor

A pesar del nombre, para el nivel de proceso sin servidor es necesario tener un servidor con la base de datos. La
opción sin servidor se puede describir mejor como una solución de escalado automático y pausa automática para
SQL Database. Es eficaz para reducir los costos en entornos de desarrollo y pruebas. Por ejemplo, puede establecer
una configuración mínima y máxima de núcleos virtuales para la base de datos, donde se escalará dinámicamente en
función de la carga de trabajo.

La característica de retraso de pausa automática permite definir el período de tiempo durante el que la base de datos
estará inactiva antes de que se pause automáticamente. La característica de retraso de pausa automática se puede
configurar de una hora a siete días. Como alternativa, la característica de retraso de pausa automática se puede
deshabilitar.

La operación de reanudación se desencadena cuando se produce el siguiente intento de acceso a la base de datos y
solo se aplican cargos de almacenamiento cuando la base de datos está en pausa.
En la imagen anterior se muestra dónde puede cambiar las propiedades de escalado automático y pausa automática
para el nivel de proceso sin servidor.

Modelo de implementación

Hay dos modelos de implementación principales al implementar SQL Database en Azure: base de datos
única y grupo elástico. Los grupos elásticos comparten recursos con otras bases de datos que forman parte del
mismo grupo, mientras que los recursos de bases de datos únicas se administran de forma independiente.

SQL Database, al igual que las máquinas virtuales, se puede implementar mediante plantillas de Azure Resource
Manager, PowerShell, la CLI de Azure o Azure Portal.

Base de datos única

La base de datos única es el modelo de implementación más sencillo de Azure SQL Database. Cada una de las bases
de datos se administra individualmente desde perspectivas de escala y tamaño de datos. Cada base de datos
implementada en este modelo tiene sus propios recursos dedicados, incluso si se implementa en el mismo servidor
lógico.

Puede supervisar el uso de recursos de base de datos mediante Azure Portal. Esta característica le permite identificar
fácilmente el rendimiento de la base de datos, como se muestra en la imagen siguiente:
Grupo elástico

Los grupos elásticos permiten asignar recursos de almacenamiento y proceso a un grupo de bases de datos, en lugar
de tener que administrar los recursos de cada base de datos individualmente. Además, los grupos elásticos son más
fáciles de escalar que las bases de datos únicas, ya que no es necesario escalar bases de datos individuales debido a
los cambios realizados en el grupo elástico.

Los grupos elásticos proporcionan una solución rentable para el modelo de aplicación de software como servicio, ya
que los recursos se comparten entre todas las bases de datos. Puede configurar recursos basados en el modelo de
compra basado en DTU o en el modelo de compra basado en núcleo virtual.

Debido a la naturaleza de esta característica, se recomienda supervisar continuamente los recursos para identificar
picos de rendimiento simultáneos que podrían afectar a otras bases de datos que forman parte del mismo grupo
elástico. A menudo, es posible que tenga que revisar la estrategia de asignación para asegurarse de que hay
suficientes recursos disponibles para todas las bases de datos que comparten el mismo grupo elástico.

El grupo elástico es una buena opción para la arquitectura multiinquilino con un promedio de uso bajo, donde cada
inquilino tiene su propia copia de la base de datos.

Opciones de red

Azure SQL Database tiene un punto de conexión de Internet público de forma predeterminada. El acceso a este
punto de conexión se puede controlar por medio de reglas de firewall, o bien limitarse a redes de Azure específicas,
mediante características como puntos de conexión de Virtual Network o Private Link.

Copia de seguridad y restauración

Azure proporciona funcionalidades de copia de seguridad y restauración sin problemas para SQL Database y
SQL Managed Instance. Ahora obtendrá información sobre algunas de las características más importantes.

Copia de seguridad continua

Con SQL Database, puede aumentar la eficacia de administración sabiendo que se realizan copias de seguridad
periódicas de las bases de datos y que se copian continuamente en un almacenamiento con redundancia geográfica
con acceso de lectura (RA-GRS).

Se realizan copias de seguridad completas cada semana, copias de seguridad diferenciales cada 12-24 horas y copias
de seguridad del registro de transacciones cada 5-10 minutos.
Geo-restore

Como las copias de seguridad tienen redundancia geográfica de forma predeterminada para SQL Database y
SQL Managed Instance, puede restaurar fácilmente las bases de datos en otra región geográfica, lo que resulta
especialmente útil para escenarios de recuperación ante desastres menos estrictos.

El almacenamiento de copia de seguridad se factura de forma independiente al almacenamiento normal de archivos

de base de datos. Pero al aprovisionar una instancia de SQL Database, el almacenamiento de copia de seguridad se
crea con el tamaño máximo de la capa de datos seleccionada para la base de datos sin costo adicional.

La duración de una operación de restauración geográfica puede verse afectada por varios componentes subyacentes,
como el tamaño de la base de datos, el número de registros de transacciones implicados en una operación de
restauración y la cantidad de solicitudes de restauración simultáneas que se procesan en la región de destino.

Nota

La restauración geográfica está disponible cuando la propiedad de redundancia de almacenamiento de copia de

seguridad está establecida en almacenamiento de copia de seguridad con redundancia geográfica.

Restauración a un momento dado

Puede configurar una directiva de retención a un momento dado específica para cada base de datos que se ejecute
en una oferta de SQL Database. El período de retención de SQL Database se puede establecer de 1 a 35 días. De
hecho, si no se especifica, la configuración predeterminada es de siete días.

Puede restaurar las bases de datos a un momento específico en el tiempo según la retención definida, pero PITR solo
se admite si va a restaurar una base de datos en el mismo servidor en el que se ha originado la copia de seguridad.
Puede usar Azure Portal, Azure PowerShell, la CLI de Azure o la API REST para restaurar una instancia de
SQL Database.

Retención a largo plazo (LTR)

La retención a largo plazo es útil para escenarios en los que es necesario establecer la directiva de retención más allá
de lo que ofrece Azure. Puede establecer una directiva de retención durante un máximo de 10 años y esta opción
está deshabilitada de forma predeterminada.
En la imagen anterior, puede configurar directivas de retención a largo plazo mediante Azure Portal. Una vez que se
selecciona la base de datos, se abrirá un nuevo panel en el lado derecho de la pantalla, donde puede invalidar las
propiedades predeterminadas.

Para más información sobre las copias de seguridad automatizadas, vea Copias de seguridad automatizadas:
Azure SQL Database y Azure SQL Managed Instance.

Ajuste automático

El ajuste automático es una característica integrada que se basa en funcionalidades de regresión de aprendizaje
automático e identifica automáticamente las oportunidades de ajuste en función del rendimiento de las consultas.

Actualmente, el ajuste automático incluye las características siguientes:

 Identificación de consultas que consumen muchos recursos

 Forzar el último plan de ejecución bueno

 Adición de índices

 Eliminación de índices

Los servicios de Azure usan una combinación de características avanzadas integradas para determinar los mejores
índices para el patrón de consulta. Inicialmente, estos índices se prueban en una copia de la base de datos y, por
último, se aplican a la base de datos.

Todas las bases de datos heredan la configuración de su servidor primario y puede deshabilitar fácilmente esta
característica en cualquier momento.

Consulta elástica (versión preliminar)

La consulta elástica permite ejecutar consultas de T-SQL que unen varias bases de datos en SQL Database. Esta
característica es especialmente útil para las aplicaciones que usan nombres de tres y cuatro partes que no se pueden
cambiar. También aumenta la portabilidad a medida que permite la migración.

Las consultas elásticas admiten las siguientes estrategias de creación de particiones:

Trabajo elástico (versión preliminar)

La característica de trabajo elástico es el reemplazo del Agente SQL Server para Azure SQL Database. Hasta cierto
punto, el trabajo elástico es equivalente a la característica Administración multiservidor disponible en una instancia
de SQL Server local.

Puede ejecutar comandos de T-SQL en varias implementaciones de destino, como bases de datos de SQL, grupos
elásticos de SQL Database y bases de datos SQL en mapas de particiones. Los recursos de base de datos se pueden
ejecutar en otras suscripciones o regiones de Azure. La ejecución se realiza en paralelo, lo que resulta útil al
automatizar las tareas de mantenimiento de la base de datos.

SQL Data Sync

La característica Data Sync permite sincronizar de forma incremental los datos en varias bases de datos que se
ejecutan en SQL Database o en instancias de SQL Server locales. Del mismo modo, Data Sync es una buena opción si
tiene que descargar cargas de trabajo intensivas en producción con una base de datos independiente que se puede
usar para análisis u operaciones ad hoc.

Data Sync se basa en una topología de concentrador, donde se define una de las bases de datos del grupo de
sincronización para que funcione como una base de datos central. El grupo de sincronización puede tener varios
miembros y solo puede sincronizar los cambios entre la base de datos central y las individuales. Data Sync realiza el
seguimiento de los cambios mediante desencadenadores de inserción, actualización y eliminación por medio de una
tabla histórica creada en la base de datos de usuario.

Al crear un grupo de sincronización, se le pedirá que proporcione una base de datos responsable de almacenar los
metadatos del grupo de sincronización. La ubicación de los metadatos puede ser una base de datos nueva o una
existente siempre que resida en la misma región que el grupo de sincronización.

En la imagen anterior, puede especificar propiedades de grupo de sincronización como la sincronización de

programación, la opción de resolución de conflictos y el uso de un vínculo privado si es necesario.
DTU en Azure SQL Database

DTU (Database Transaction Unit) es una unidad de medida en Azure SQL Database que combina CPU, memoria y
rendimiento de I/O en una sola métrica. Se usa en el modelo de precios basado en DTU, que es una de las opciones
para aprovisionar bases de datos en Azure SQL.

🔹 Cómo funciona DTU

 Microsoft ha diseñado las DTUs para representar una cantidad combinada de recursos de CPU, RAM y IOPS
(operaciones de entrada/salida por segundo).

 En lugar de configurar estos recursos individualmente, puedes elegir un nivel de servicio con un número fijo
de DTUs, y Azure asigna los recursos proporcionalmente.

📌 Ejemplo:

 Un plan de 10 DTUs es más limitado en CPU, memoria y rendimiento de disco que un plan de 100 DTUs.

 Si una consulta consume demasiados recursos y supera las DTUs asignadas, el rendimiento se degrada hasta
que haya capacidad disponible.

🔹 Modelos de servicio con DTU

El modelo basado en DTU tiene tres niveles:

1️⃣ Básico (Basic) – Para cargas de trabajo ligeras.

 5 DTUs

 2 GB de almacenamiento máximo

 7 días de retención de copias de seguridad

2️⃣ Estándar (Standard) – Para bases de datos con uso moderado.

 10 - 3000 DTUs

 Hasta 1 TB de almacenamiento

 Copias de seguridad retenidas por 35 días

3️⃣ Premium – Para cargas de trabajo de alto rendimiento.

 125 - 4000 DTUs

 Almacenamiento basado en SSD

 Mejor rendimiento de transacciones y HA

🔹 Alternativa: Modelo vCore

En lugar de DTUs, el modelo vCore te permite elegir CPU, memoria y almacenamiento de manera más personalizada.
Este modelo suele ser más eficiente para cargas de trabajo grandes o migraciones desde SQL Server on-premises.

📌 ¿Cuándo usar DTU vs vCore?

✅ DTU: Si necesitas un plan sencillo sin preocuparte por asignar recursos manualmente.
✅ vCore: Si quieres mayor control sobre CPU, RAM y almacenamiento.
🔹 Cómo medir y escalar DTUs

🔹 Usa la herramienta DTU Calculator de Microsoft para estimar las DTUs necesarias basadas en tu carga de trabajo
on-premises.
🔹 En Azure Portal, puedes monitorear el uso de DTUs y escalar a un nivel superior si la base de datos llega al límite.

Resumen Final

 DTU = Unidad combinada de CPU, RAM e I/O en Azure SQL Database.

 Más DTUs = Mejor rendimiento (pero mayor costo).

 Ideal para cargas de trabajo predecibles y gestión simple.

 Alternativa: vCore si necesitas más personalización.

Exploración de Instancia administrada de Azure SQL Database

La mayoría de las características disponibles en Azure SQL Database también funcionarán para Azure SQL Managed
Instance, ya que comparten el mismo código base. La plataforma como servicio (PaaS) totalmente administrada
proporciona algunas de las ventajas siguientes:

 Copias de seguridad automáticas

 Aplicación de revisiones automática

 Alta disponibilidad integrada

  Herramientas de seguridad y rendimiento

 Funcionalidades de auditoría insertadas

Otra ventaja clave al migrar a una de las ofertas de PaaS en Azure es que ya no tiene que instalar o aplicar revisiones
a SQL Server, lo que puede aumentar el tiempo de actividad de la aplicación y reducir los esfuerzos de
mantenimiento.

A diferencia de Azure SQL Database, que está diseñado en torno a estructuras de base de datos únicas, SQL Managed
Instance proporciona otras características, como consultas entre bases de datos, Common Language Runtime (CLR),
acceso a las bases de datos del sistema y uso de las características del Agente SQL.

Para obtener una lista completa de las características disponibles en Azure SQL Managed Instance, vea Características
de SQL Database y SQL Managed Instance.

Opciones de licencias híbridas

Microsoft ofrece varias ventajas para las licencias de SQL Server. Tanto para SQL Database como SQL Managed
Instance, aprovechar las licencias existentes puede reducir el costo de ejecutar la oferta de PaaS.

 Por cada núcleo de Enterprise Edition con Active Software Assurance, puede optar a un núcleo virtual de
SQL Database o SQL Managed Instance Crítico para la empresa y ocho núcleos virtuales de uso general.

 Por cada núcleo de Standard Edition con Active Software Assurance, puede optar a un núcleo virtual de uso
general.

Este modelo puede reducir los costos totales de licencia hasta un 40 %. Efectivamente, solo pagará los costos de
proceso y almacenamiento, y no los de licencia de software.

Para más información sobre el modelo de licencias bring-your-own, vea Movilidad de licencias a través de Software
Assurance en Azure

Arquitectura de conectividad

Las conexiones a SQL Managed Instance se realizan mediante puntos de conexión de TDS. Si bien el enrutamiento y
la seguridad de estas conexiones difieren, hay un componente de puerta de enlace que controla y enruta las
conexiones al servicio de la base de datos. Este componente de puerta de enlace también se implementa con alta
disponibilidad.

Copia de seguridad y restauración

La copia de seguridad automatizada de bases de datos proporciona un servicio de copia de seguridad totalmente
administrado que realiza copias de seguridad completas, diferenciales y de registro con regularidad para ofertas de
SQL Managed Instance y SQL Database. Las copias de seguridad automatizadas tienen redundancia geográfica y se
replican automáticamente en una región emparejada, lo que protege los datos frente a interrupciones localizadas en
la región primaria.

De forma similar, SQL Managed Instance facilita la migración de las aplicaciones existentes, lo que permite
restauraciones a partir de copias de seguridad locales.

Hay algunas consideraciones importantes al ejecutar operaciones de copia de seguridad y restauración en bases de
datos de SQL Managed Instance:

 No es posible sobrescribir una base de datos existente durante el proceso de restauración. Antes de restaurar
una base de datos, debe asegurarse de que no existe.

 Para SQL Managed Instance, las copias de seguridad solo se pueden restaurar en otra instancia administrada.
No es posible restaurar una copia de seguridad de base de datos de instancia administrada en una instancia
de SQL Server que se ejecute en una máquina virtual o SQL Database.
  La copia de seguridad de solo copia en Azure Blob Storage está disponible para SQL Managed Instance.
SQL Database no admite esta característica.

Para más información sobre las copias de seguridad automatizadas, vea Copias de seguridad automatizadas:
Azure SQL Database y Azure SQL Managed Instance.

Arquitectura de alta disponibilidad

SQL Database y SQL Managed Instance tienen arquitecturas de alta disponibilidad similares, lo que garantiza un
tiempo de actividad del 99,99 %. Las actualizaciones de Windows y SQL Server se controlan con la infraestructura de
back-end, por lo general sin ningún efecto en la aplicación, aunque es importante colocar una lógica de reintento en
la aplicación.

La característica de grupos de conmutación por error automática permite conmutar por error un grupo de bases de
datos replicadas en un servidor a otra región. Esta característica está diseñada sobre la funcionalidad de replicación
geográfica activa existente, que simplifica la implementación y administración de bases de datos con replicación
geográfica.

Un grupo de conmutación por error puede incluir una o varias bases de datos, habitualmente utilizadas por la misma
aplicación. Además, puede usar las bases de datos secundarias legibles para descargar las cargas de trabajo de
consulta de solo lectura.

Nota

La característica de grupos de conmutación por error automática se admite tanto en SQL Managed Instance como en
SQL Database.

Para más información sobre los grupos de conmutación por error automática, vea Uso de grupos de conmutación por
error automática para habilitar la conmutación por error geográfica transparente y coordinada de varias bases de
datos.

Opciones de migración

En general, la migración a SQL Managed Instance suele ser sencilla dado el gran conjunto de características
disponibles. Hay un par de formas de migrar bases de datos locales:

 Servicio de reproducción de registros. Es una opción de migración en línea y se usa cuando se necesita más
control sobre proyecto de migración de base de datos.

 Extensión Azure SQL Migration para Azure Data Studio. Es una herramienta que ayuda a prepararse para
migrar las bases de datos de SQL Server a Azure. Usa la versión más reciente de Azure Data Migration Service
(DMS) para evaluar la preparación para la migración, recomendar los mejores recursos de Azure en función
de las necesidades y ejecutar la migración. Es ideal para bases de datos pequeñas y medianas y admite la
migración en línea a SQL Managed Instance.

 Vínculo de Instancia administrada. El vínculo de Instancia administrada, que usa grupos de disponibilidad
distribuidos, amplía de forma segura el patrimonio de datos mediante la replicación de datos casi al instante
(en línea) entre cualquier instancia hospedada de SQL Server y Azure SQL Managed Instance, y viceversa.

 Copia de seguridad y restauración nativa. La copia de seguridad y la restauración son un método de

migración sencillo y ampliamente usado por muchos profesionales de SQL Server. Es la opción de migración
más sencilla para aquellos clientes que pueden proporcionar copias de seguridad de bases de datos
completas para Azure Storage.

 Replicación transaccional La replicación transaccional es una manera de mover datos entre servidores de
bases de datos conectados continuamente. Es lo más recomendable para la migración en línea o sin conexión
de bases de datos grandes y complejas.

Machine Learning Services

Machine Learning Services proporciona operaciones de aprendizaje automático dentro de la estructura de bases de
datos relacionales. Esta característica admite paquetes de Python y R, y es idónea para funcionalidades predictivas de
uso intensivo. Esta opción está disponible en SQL Managed Instance, SQL Server en la máquina virtual de Azure y
SQL Server en el entorno local.

Las aplicaciones pueden usar una base de datos relacional en Azure combinada con capacidades de alto rendimiento
de aprendizaje automático, donde puede:

 Entrenar modelos de Machine Learning basados en un conjunto de datos muestreado o de población.

 Reducir la complejidad de la seguridad y el cumplimiento, donde no es necesario reubicar los datos para
compilar y entrenar los modelos de Machine Learning.

 Implementar modelos de Machine Learning mediante procedimientos almacenados de T-SQL que admiten el
lenguaje de programación Python o R.

 Usar bibliotecas de código abierto como scikit-learn, PyTorch y TensorFlow.

En entornos ocupados, puede usar la función PREDICT de T-SQL, que permite acelerar las predicciones en función del
modelo almacenado.

La característica Machine Learning Services se puede habilitar mediante la ejecución del comando siguiente:

SQLCopiar

EXEC sp_configure 'external scripts enabled', 1;

RECONFIGURE WITH OVERRIDE;

El comando anterior permite la ejecución de scripts externos en la instancia administrada y se debe habilitar antes de
intentar usar sp_execute_external_script para ejecutar scripts de Python o R en la base de datos.

Nota

SQL Database no admite la característica Machine Learning Services.

Para más información sobre Machine Learning Services, vea Machine Learning Services en Azure SQL Managed
Instance.

Planeación e implementación de
recursos de plataformas de datos
Implementación de soluciones IaaS con Azure SQL

La razón más común para implementar SQL Server en una máquina virtual (VM) de Azure es el deseo de disponer de
un método sencillo para migrar un servidor SQL Server del entorno local a la nube.

Conocer las opciones y los métodos para implementar SQL Server en una máquina virtual de Azure es fundamental
para asegurar una migración satisfactoria. La infraestructura como servicio (IaaS) permite una mayor flexibilidad en la
configuración. Esta flexibilidad significa que usted, como administrador de bases de datos, debe planear la
configuración con cuidado. Elegir las opciones adecuadas de tamaño, almacenamiento y red de las máquinas
virtuales es fundamental para asegurar un buen rendimiento de las cargas de trabajo.

Explicar las opciones de IaaS para implementar SQL Server en Azure

Muchas aplicaciones necesitarán una máquina virtual donde se ejecute SQL Server. Algunos de los motivos para
elegir esta opción son:
  Versiones anteriores de SQL Server: si una aplicación requiere una versión anterior de SQL Server para la
compatibilidad con un proveedor, la ejecución en una máquina virtual es la mejor opción para esas
aplicaciones, ya que permite la compatibilidad entre el proveedor y la aplicación.

 Uso de otros servicios de SQL Server: aunque Analysis Services y, hasta cierto punto, Integration Services
(mediante el uso de Azure Data Factory) están disponibles como ofertas de PaaS, muchos usuarios
maximizan sus licencias ejecutando SQL Server Analysis Services, Integration Services o Reporting Services en
el mismo equipo que el motor de base de datos.

 Incompatibilidad general entre aplicaciones: este motivo es un poco comodín. Por ejemplo, Azure SQL
Database no admite consultas entre bases de datos, mientras que Managed Instance sí las admite. Puede
que algunas aplicaciones necesiten servicios adicionales coubicados con la instancia de la base de datos de
una manera que no sea compatible con una oferta de PaaS.

La infraestructura como servicio (IaaS) permite al administrador tener un acceso más pormenorizado en una
configuración específica de la infraestructura subyacente que las otras ofertas de Azure. Aunque la plataforma Azure
administra el servidor y el hardware de red subyacentes, usted sigue teniendo acceso al almacenamiento virtual, a la
configuración de red virtual y a cualquier otro software que pueda instalar en la máquina virtual. Esto incluye
Microsoft SQL Server.

En la imagen anterior, se muestra el mayor control que se tiene cuando se utiliza IaaS, en comparación con las otras
ofertas de Azure SQL. Aunque las opciones de configuración exactas varían entre las distintas ofertas de servicio,
normalmente, en las ofertas de SaaS, el administrador es responsable solo de la seguridad de los usuarios y,
posiblemente, de la administración de los datos. Al usar los servicios de PaaS, el proveedor de nube administra el
sistema operativo (SO) y otro software. Un buen ejemplo de esto es la plataforma de bases de datos de Azure, donde
Microsoft se ocupa de instalar y configurar el sistema operativo y el sistema RDBMS, lo que le permite empezar a
crear aplicaciones de base de datos rápidamente. Las soluciones de IaaS son las más abiertas. Usted es responsable
de la aplicación de revisiones del sistema operativo y de la óptima configuración de las opciones de red y
almacenamiento. Con una implementación de IaaS, usted también es responsable de la configuración del software.

En el caso de las soluciones IaaS que se ejecutan en Azure, Microsoft administra los recursos que se encuentran
debajo del sistema operativo, incluidos los servidores físicos, el almacenamiento y la red física. El administrador de
bases de datos es responsable de la configuración de las instancias de SQL Server que se ejecutan en el sistema
operativo.
Puede que algunas de sus aplicaciones no sean adecuadas para otras ofertas de Azure, como Azure SQL Database,
porque requieren condiciones de funcionamiento específicas. Estas condiciones pueden ser una combinación
específica de versiones de SQL Server y Windows por motivos de compatibilidad con proveedores, o software
adicional que deba instalarse junto con SQL Server. SQL Server emparejado con la plataforma de IaaS de Azure
proporciona las opciones de control necesarias para muchas organizaciones, ya sean características específicas (como
CLR o replicación) o el uso de la autenticación de Active Directory (en lugar de Microsoft Entra ID). Otro requisito es
que algunas aplicaciones instalen software junto con SQL Server, lo que requiere acceso directo al sistema operativo
subyacente. En un modelo PaaS, no se admite el acceso directo al sistema operativo. Estas organizaciones y sus
aplicaciones pueden obtener las ventajas de migrar a un servicio en la nube sin perder la funcionalidad crítica que
requiere su organización.

Extensión Agente de IaaS de SQL Server

Cuando se implementa una máquina virtual con SQL Server desde Azure Marketplace, parte del proceso instala la
extensión Agente de IaaS.

Las extensiones son código que se ejecuta en la máquina virtual después de la implementación, normalmente, para
llevar a cabo alguna configuración posterior a la implementación. Algunos ejemplos son la instalación de soluciones
antivirus o de características de Windows. La extensión Agente de IaaS de SQL Server proporciona las siguientes
características clave que pueden reducir la sobrecarga administrativa.

 Copia de seguridad automatizada

 Aplicación de revisión automatizada

 Integración de Azure Key Vault

 Integración de Defender para Cloud Portal

 Ver el uso del disco en el portal

 Licencias flexibles

 Versión o edición flexibles

 Evaluación de procedimientos recomendados de SQL

Además de estas características, la extensión permite ver información sobre la configuración del servidor SQL Server
y el uso del almacenamiento.
Modelos de licencias de SQL Server

Hay varias opciones diferentes relacionadas con la forma en la que se obtienen licencias de SQL Server cuando se usa
la oferta de IaaS de Azure.

Si no participa en el programa Microsoft Software Assurance (SA), puede implementar una imagen de Azure
Marketplace que contenga un servidor SQL Server preconfigurado y pagar el uso de este servidor por minutos. Esta
opción se conoce como el modelo de pago por uso y el costo de la licencia de SQL Server está incluido en el costo de
la máquina virtual.

Si participa en el programa Microsoft Software Assurance (SA), dispone de más flexibilidad en cuanto a la forma de
obtener la licencia de SQL Server:

 Puede usar el método anterior y pagar por minutos tras implementar una imagen de máquina virtual de
Azure Marketplace que contenga un servidor SQL Server.

 Puede traer su propia licencia (BYOL) si implementa una máquina virtual que no tiene una instancia de
SQL Server preconfigurada. Esta opción es posible si ya ha adquirido una licencia de SQL Server válida para la
infraestructura de su entorno local. Puede aplicar esta licencia a la máquina virtual para asegurarse de que
tiene la licencia correspondiente. Debe notificar el uso de licencias a Microsoft mediante el formulario de
comprobación de Movilidad de licencias en un plazo de diez días a partir de la implementación de la máquina
virtual.

Al elegir este método, puede instalar manualmente SQL Server desde el soporte que haya obtenido, o bien puede
cargar una imagen de máquina virtual en Azure.

Además de las opciones de licencia flexibles para SQL Server, hay también opciones de licencia de Windows Server
que pueden aprovecharse. Estas opciones de Windows Server se conocen como Ventaja híbrida de Azure (AHB). De
forma similar a la aplicación de una licencia de SQL Server que ya había adquirido, puede aprovechar las licencias de
Windows Server que ya tenga.

La reserva de una máquina virtual para uno a tres años es otra opción para ahorrar costos. Este compromiso no
requiere ningún pago por adelantado y se puede facturar mensualmente. El uso de la opción de reserva puede ser
beneficioso si sabe que las cargas de trabajo se van a mantener. El ahorro de costos puede ser importante,
especialmente en el caso de las máquinas virtuales de mayor tamaño.

Familias de máquinas virtuales

Cuando se implementa una máquina virtual de Azure, hay varias series, o “familias”, de tamaños de máquina virtual
que se pueden seleccionar. Cada serie es una combinación de memoria, CPU y almacenamiento que cumple
determinados requisitos. Por ejemplo, la serie optimizada para proceso tiene una mayor proporción de CPU por
memoria. Tener varias opciones permite seleccionar una configuración de hardware adecuada para la carga de
trabajo prevista. Las seis series siguientes tienen varios tamaños disponibles. En Azure Portal, se proporcionan todos
los detalles cuando se elige la opción para seleccionar el tamaño de la máquina virtual.

De uso general: estas máquinas virtuales proporcionan una relación equilibrada CPU-memoria. Esta clase de máquina
virtual es ideal para pruebas y desarrollo, servidores de bases de datos de tamaño pequeño a mediano y servidores
web con una cantidad de tráfico de baja a media.

Optimizadas para proceso: las máquinas virtuales optimizadas para proceso tienen una elevada proporción de CPU
por memoria y son adecuadas para servidores web con una cantidad media de tráfico, dispositivos de red, procesos
por lotes y servidores de aplicaciones. Estas máquinas virtuales también admiten cargas de trabajo de aprendizaje
automático que no se pueden beneficiar de las máquinas virtuales basadas en GPU.

Optimizadas para memoria: estas máquinas virtuales tienen una elevada proporción de memoria por CPU. Cubren
una amplia gama de opciones de CPU y memoria (hasta 4 TB de RAM) y son adecuadas para la mayoría de las cargas
de trabajo de base de datos.

Optimizadas para almacenamiento: las máquinas virtuales optimizadas para almacenamiento proporcionan un
almacenamiento NVMe rápido y local que es efímero. Son una buena opción para las cargas de trabajo de datos de
escalabilidad horizontal, como Cassandra. Pueden usarse con SQL Server, sin embargo, dado que el almacenamiento
es efímero, es necesario asegurarse de configurar la protección de datos con una característica como los grupos de
disponibilidad Always On o el trasvase de registros.

GPU: las máquinas virtuales de Azure con GPU están dirigidas a dos tipos de cargas de trabajo principales:
operaciones de procesamiento de gráficos de forma natural, como la representación y el procesamiento de vídeo, y
las cargas de trabajo de aprendizaje automático en paralelo de forma masiva que pueden aprovechar las GPU.

Informática de alto rendimiento: las cargas de trabajo de informática de alto rendimiento admiten aplicaciones que
se pueden escalar horizontalmente hasta miles de núcleos de CPU. Esto es posible gracias al uso de CPU de alto
rendimiento y redes de acceso directo a memoria remota (RDMA), que proporcionan una comunicación de baja
latencia entre las máquinas virtuales.

La forma más sencilla de ver las opciones de tamaño de cada serie es a través de Azure Portal. En la hoja para crear
una máquina virtual, puede hacer clic en la opción “Seleccionar tamaño” y ver una lista.
La imagen anterior muestra solo un pequeño conjunto de las posibilidades de series y tamaños. Para cada opción,
puede ver el número de CPU virtuales, la cantidad de RAM, el número de discos de datos, el número máximo de
operaciones IOPS, el almacenamiento temporal proporcionado y si se admite Premium Storage.

Para obtener más información sobre los procedimientos recomendados del tamaño de máquinas virtuales,
consulte Procedimientos recomendados para SQL Server en máquinas virtuales de Azure.

Azure Marketplace

Azure Marketplace es, básicamente, una ubicación centralizada que permite crear recursos de Azure basados en una
plantilla prediseñada. Por ejemplo, puede crear rápidamente una instancia de SQL Server 2019 en
Windows Server 2019 con un par de clics del mouse y alguna información básica, como el nombre de la máquina
virtual, y algunos datos de configuración de SQL Server. Una vez proporcionados, Azure Resource Manager inicia la
creación de la máquina virtual y, en cuestión de minutos, estará en funcionamiento.

A continuación se muestra la hoja de SQL Server 2019 en Windows Server 2019 en Azure Marketplace. Esta hoja
ofrece la opción de preestablecer configuraciones para las cargas de trabajo de OLTP o Data Warehouse, y permite
especificar opciones de almacenamiento, aplicación de revisiones y copias de seguridad.
El inconveniente de usar el portal para crear recursos de Azure es que no es un
proceso fácilmente repetible. Sin embargo, es fácil empezar a trabajar con el portal,
donde puede hacer uso rápidamente de los recursos.

Configuración de SQL Server

Al aprovisionar SQL Server en una máquina virtual de Azure, también puede
configurar opciones de SQL Server específicas, como Seguridad y redes, Preferencias
de autenticación de SQL, Configuración de la instancia de SQL y otras opciones. Estas
opciones se encuentran en la pestaña configuración de SQL Server, como se
muestra en la imagen siguiente.
Descripción de escenarios híbridos

Supongamos que su organización tiene una inversión significativa en infraestructura SQL Server local y en centros de
datos locales. En ese caso, es fundamental tener en cuenta que el uso de la nube no es una propuesta de todo o
nada. Hay maneras de usar la infraestructura local existente de forma híbrida con Azure para mejorar la resistencia
operativa y reducir el costo.

La implementación de una infraestructura híbrida también es un primer paso excelente para evaluar la informática
en la nube de las organizaciones que han sido tradicionalmente locales y escépticas de la nube. Es habitual que las
organizaciones actuales tengan una combinación de implementaciones físicas y virtualizadas de SQL Server locales,
que pueden extenderse a la nube como parte de una solución híbrida. La plataforma híbrida de SQL Server ofrece las
ventajas de los servicios locales y en la nube; es un punto medio entre ambos. Normalmente, el componente en la
nube usa servicios IaaS, como el almacenamiento o máquinas virtuales de SQL Server, como se indica a continuación.

Además de ampliar las soluciones locales, se pueden aplicar los mismos patrones a las soluciones en la nube
alternativas existentes, lo que permite implementaciones híbridas de nube a nube. Vamos a revisar algunos de los
escenarios híbridos más comunes para SQL Server.

Escenarios híbridos para SQL Server

Vamos a revisar algunas estrategias para la implementación de una solución híbrida en SQL Server.

Recuperación ante desastres

La recuperación ante desastres es el escenario más común para una implementación híbrida de SQL Server. La
recuperación ante desastres significa que las organizaciones garantizan la continuidad empresarial en caso de
eventos catastróficos. Las organizaciones pueden distribuir implementaciones entre varios centros de datos para la
conmutación por error en un enfoque local. Estos centros de datos normalmente residen dentro de la misma región
geográfica que la organización, por lo que son susceptibles a desastres regionales más significativos. Los centros de
datos físicos también son costosos de implementar, supervisar y mantener. Posiblemente, el costo de poner en
marcha máquinas virtuales de Azure SQL Server en varias regiones geográficas sea mucho menor que establecer un
nuevo centro de datos físico en otro lugar.
En este enfoque híbrido, se usa Azure para la conmutación por error de DR (a una o varias regiones) mientras que el
procesamiento diario normal continúa usando servidores locales para disponer de una alta disponibilidad local.

Copias de seguridad de SQL Server

Las copias de seguridad de SQL Server son otro escenario híbrido común. Las copias de seguridad se pueden realizar
directamente en Azure Storage a través de una dirección URL o un recurso compartido de archivos de Azure (SMB).
Este escenario protege contra la pérdida de datos cuando se produce un error en el almacenamiento de la copia de
seguridad local. Además, estas copias de seguridad también se pueden restaurar en máquinas virtuales de Azure y
probarse como parte de los procedimientos de recuperación ante desastres.

Otro escenario usa Azure Storage para almacenar localmente archivos de datos de SQL Server para bases de datos
de usuario. Tenga en cuenta que son archivos de usuario y no bases de datos del sistema. En el caso de un error de
almacenamiento local, los archivos de usuario se almacenan de forma segura en la nube, lo que impide la pérdida de
datos. Además, mediante el uso de Azure Storage, hay garantías de confiabilidad integradas, por lo que almacenar
estos archivos en la nube es más resistente. En este escenario híbrido, es esencial mantener la comunicación de red
segura, evaluar la latencia de red de la solución y asegurarse de que la cuenta de almacenamiento esté bloqueada
mediante ACL y Microsoft Entra ID.

Servidores SQL Server habilitados para Azure Arc

Tener servidores SQL Server habilitados para Azure Arc amplía y centraliza los servicios de administración de Azure
para instancias de SQL Server hospedadas en el entorno local, en los centros de datos, en el perímetro y en entornos
de varias nubes. En este escenario híbrido, Azure Arc permite realizar el inventario de todas las implementaciones de
SQL Server registradas y evalúa sus configuraciones, patrones de uso y seguridad para proporcionar acciones y
recomendaciones basadas en procedimientos recomendados. Mediante el uso de servidores SQL Server habilitados
para Azure Arc, obtendrá las ventajas de la administración centralizada de servidores. También obtendrá alertas de
seguridad en tiempo real de Azure Defender e informes de vulnerabilidades tanto en servidores SQL Server locales
como en sus sistemas operativos host. Además, Azure Sentinel puede proporcionar más introspección sobre
amenazas de seguridad si es necesario.
Consideraciones sobre la seguridad

Al implementar una solución de SQL híbrida, toda la infraestructura principal, como Active Directory y DNS, debe
existir en el entorno local y en Azure. Además, debe existir una comunicación bidireccional segura entre la red local y
Azure. Esta comunicación protegida puede adoptar la forma de una VPN de sitio a sitio (S2S) o un
túnel ExpressRoute dedicado. Al evaluar diferentes métodos de conectividad, es fundamental determinar la cantidad
de latencia aceptable para su organización. Independientemente de la solución elegida, la seguridad de red también
debe estar al frente de la implementación.

La imagen anterior muestra que la ventaja de una solución VPN de sitio a sitio es que tiende a costar menos y su
implementación es una tarea común entre los ingenieros de red. Sin embargo, con esta solución, toda la
comunicación se produce a través de la red pública de Internet y está limitada por la velocidad de Internet de la
organización.
Como podemos ver anteriormente, mientras que la solución ExpressRoute tiende a ser más costosa, también
proporciona la mejor seguridad y la latencia más baja, ya que todas las comunicaciones fluyen a través de un canal
seguro directo independiente de la red pública de Internet. Sin embargo, los detractores comunes para esta solución
incluyen el costo total y la incapacidad de aplicar ExpressRoute entre proveedores de nube en una solución de varias
nubes.

Explorar el rendimiento y la seguridad

El ecosistema de Azure ofrece varias opciones de rendimiento y seguridad para la instancia de SQL Server en la
máquina virtual de Azure. Cada opción proporciona varias funcionalidades, como diferentes tipos de disco que
cumplen los requisitos de capacidad y rendimiento de la carga de trabajo.

Consideraciones sobre el almacenamiento

SQL Server requiere un buen rendimiento del almacenamiento para proporcionar un sólido rendimiento de la
aplicación, ya sea una instancia en el entorno local o instalada en una máquina virtual de Azure. Azure proporciona
una amplia variedad de soluciones de almacenamiento para satisfacer las necesidades de su carga de trabajo.
Aunque Azure ofrece varios tipos de almacenamiento (blobs, archivos, colas y tablas), en la mayoría de los casos, las
cargas de trabajo de SQL Server usan Azure Managed Disks. Las excepciones son que se puede crear una instancia de
clúster de conmutación por error basada en File Storage y las copias de seguridad usarán Blob Storage. Los discos de
Azure Managed Disks actúan como un dispositivo de almacenamiento en bloque que se presenta a la máquina virtual
de Azure. Managed Disks ofrece una serie de ventajas, entre las que se incluyen una disponibilidad del 99,999 %, una
implementación escalable (puede tener hasta 50 000 discos de máquina virtual por suscripción y región) y la
integración con conjuntos y zonas de disponibilidad para ofrecer niveles más altos de resistencia en caso de error.

Los discos administrados por Azure ofrecen dos tipos de cifrado. El servicio de almacenamiento proporciona cifrado
del lado servidor de Azure, que actúa como cifrado en reposo. Azure Disk Encryption usa BitLocker en Windows y
DM-Crypt en Linux para proporcionar el cifrado de los discos de datos y del sistema operativo en la máquina virtual.
Ambas tecnologías se integran con Azure Key Vault y le permiten traer su propia clave de cifrado.

Cada máquina virtual tendrá al menos dos discos asociados:

 Disco del sistema operativo: cada máquina virtual necesita un disco del sistema operativo que contenga el
volumen de arranque. Este disco sería la unidad C: en el caso de una máquina virtual de la plataforma
Windows, o/dev/sda1 en Linux. El sistema operativo se instala automáticamente en el disco del sistema
operativo.
  Disco temporal: cada máquina virtual incluye un disco que se usa para el almacenamiento temporal. Este
almacenamiento está diseñado para datos que no es necesario que sean duraderos, como archivos de
paginación o archivos de intercambio. Como el disco es temporal, no debe usarlo para almacenar
información crítica, como archivos de base de datos o de registro de transacciones, ya que se perderán
durante las tareas de mantenimiento o al reiniciar la máquina virtual. Esta unidad se monta como D:\ en
Windows, y/dev/sdb1 en Linux.

Además, puede y debe agregar discos de datos adicionales a las máquinas virtuales de Azure que ejecutan
SQL Server.

 Discos de datos: el término disco de datos se usa en Azure Portal, pero, en la práctica, son simplemente
discos administrados adicionales que se agregan a una máquina virtual. Estos discos se pueden agrupar para
aumentar las operaciones IOPS y la capacidad de almacenamiento disponibles, usando Espacios de
almacenamiento en Windows o la gestión de volúmenes lógicos en Linux.

Además, los discos pueden ser de varios tipos:

Los procedimientos recomendados para SQL Server en Azure aconsejan el uso de discos prémium agrupados para
aumentar la capacidad de operaciones IOPS y de almacenamiento. Los archivos de datos deben almacenarse en su
propio grupo con almacenamiento en caché de lectura en los discos de Azure.

Los archivos de registro de transacciones no se benefician de este almacenamiento en caché, por lo que esos
archivos deben incluirse en su propio grupo sin almacenamiento en caché. La base de datos tempdb puede estar en
su propio grupo o usar el disco temporal de la máquina virtual, que ofrece una baja latencia, ya que está conectado
físicamente al servidor físico donde se ejecutan las máquinas virtuales. Los discos SSD prémium bien configurados
ofrecen una latencia inferior a 10 milisegundos. Para las cargas de trabajo críticas que requieren una latencia inferior
a esta, debe considerar el uso de discos SSD Ultra.

Consideraciones sobre la seguridad

Hay varias regulaciones y estándares del sector que Azure cumple, lo que permite crear una solución compatible con
SQL Server que se ejecuta en una máquina virtual.

Microsoft Defender para SQL

Microsoft Defender para SQL proporciona las características de seguridad de Azure Security Center, como las
evaluaciones de vulnerabilidades y las alertas de seguridad.

Azure Defender para SQL se puede usar para identificar y mitigar posibles vulnerabilidades en la instancia y la base
de datos de SQL Server. La característica de evaluación de vulnerabilidades puede detectar posibles riesgos en el
entorno de SQL Server y ayudarle a corregirlos. También ofrece información sobre el estado de la seguridad y los
pasos necesarios para resolver problemas de seguridad.

Azure Security Center

Azure Security Center es un sistema de administración de seguridad unificado que evalúa y ofrece oportunidades
para mejorar varios aspectos de seguridad del entorno de datos. Azure Security Center proporciona una visión
completa del estado de seguridad de todos los recursos de la nube híbrida.

Consideraciones de rendimiento

La mayoría de las características de rendimiento locales de SQL Server existentes también están disponibles en
máquinas virtuales (VM) de Azure. Entre las opciones que se ofrecen se incluye la compresión de datos, que puede
mejorar el rendimiento de las cargas de trabajo intensivas de E/S, a la vez que disminuye el tamaño de la base de
datos. De forma similar, las particiones de tabla e índice pueden mejorar el rendimiento de las consultas de tablas
grandes a la vez que mejoran el rendimiento y la escalabilidad.

Partición de tablas

La creación de particiones de tablas ofrece muchas ventajas, pero a menudo esta estrategia solo se considera cuando
la tabla es lo suficientemente grande como para empezar a poner en peligro el rendimiento de las consultas.
Identificar qué tablas son buenas candidatas para la creación de particiones es un procedimiento recomendado que
puede disminuir las interrupciones e intervenciones. Al filtrar los datos mediante la columna de partición, solo se
tiene acceso a un subconjunto de los datos, no a toda la tabla. De forma similar, las operaciones de mantenimiento
en una tabla con particiones reducirán la duración del mantenimiento, por ejemplo, puede comprimir datos
específicos en una partición determinada o recompilar particiones concretas de un índice.

Hay cuatro pasos principales que se deben seguir al definir una partición de tabla:

 Creación de grupos de archivos, que define los archivos implicados cuando se crean las particiones.

 Creación de la función de partición, que define las reglas de partición basadas en la columna especificada.

 Creación del esquema de partición, que define el grupo de archivos de cada partición.

 Selección de la tabla en la que se va a realizar la partición.

En el ejemplo siguiente se muestra cómo crear una función de partición para el 1 de enero de 2021 hasta el 1 de
diciembre de 2021 y distribuir las particiones entre diferentes grupos de archivos.

-- Partition function

CREATE PARTITION FUNCTION PartitionByMonth (datetime2)

AS RANGE RIGHT

-- The boundary values defined is the first day of each month, where the table will be partitioned into 13 partitions

FOR VALUES ('20210101', '20210201', '20210301',

'20210401', '20210501', '20210601', '20210701',

'20210801', '20210901', '20211001', '20211101',

'20211201');

-- The partition scheme below will use the partition function created above, and assign each partition to a specific
filegroup.

CREATE PARTITION SCHEME PartitionByMonthSch

 AS PARTITION PartitionByMonth

TO (FILEGROUP1, FILEGROUP2, FILEGROUP3, FILEGROUP4,

FILEGROUP5, FILEGROUP6, FILEGROUP7, FILEGROUP8,

FILEGROUP9, FILEGROUP10, FILEGROUP11, FILEGROUP12);

-- Creates a partitioned table called Order that applies PartitionByMonthSch partition scheme to partition the
OrderDate column

CREATE TABLE Order ([Id] int PRIMARY KEY, OrderDate datetime2)

ON PartitionByMonthSch (OrderDate) ;

GO

Compresión de datos

SQL Server ofrece diferentes opciones para comprimir datos. Si bien SQL Server todavía almacena los datos
comprimidos en páginas de 8 KB, cuando los datos están comprimidos, se pueden almacenar más filas de datos en
una página determinada, lo que permite que la consulta lea menos páginas. Leer menos páginas supone una ventaja
doble: permite realizar menos operaciones físicas de E/S y almacenar más filas en el grupo de búferes, lo que hace un
uso más eficiente de la memoria. Se recomienda habilitar la compresión de página de base de datos cuando
corresponda.

El inconveniente de la compresión es que requiere una pequeña cantidad de sobrecarga de la CPU; sin embargo, en
la mayoría de los casos, las ventajas de E/S del almacenamiento superan con creces cualquier uso adicional del
procesador.
En la imagen anterior, se muestra esta ventaja con respecto al rendimiento. Estas tablas tienen los mismos índices
subyacentes; la única diferencia es que los índices agrupados y no agrupados de la
tabla Production.TransactionHistory_Page presentan compresión de página. La consulta en el objeto con compresión
de página realiza un 72 % menos de lecturas lógicas que la consulta que utiliza los objetos sin comprimir.

La compresión se implementa en SQL Server en el nivel de objeto. Cada índice o tabla se puede comprimir
individualmente. Además, tiene la opción de comprimir las particiones de una tabla o índice con particiones. Puede
evaluar la cantidad de espacio que se ahorrará mediante el procedimiento almacenado del sistema
sp_estimate_data_compression_savings. En las versiones anteriores a SQL Server 2019, este procedimiento no
admitía índices de almacén de columnas ni compresión de archivo del almacén de columnas.

 Compresión de fila: la compresión de fila es bastante básica y no provoca mucha sobrecarga, pero no ofrece
la misma cantidad de compresión (medida mediante el porcentaje de reducción del espacio de
almacenamiento necesario) que puede ofrecer la compresión de página. La compresión de fila básicamente
almacena cada valor de cada columna en una fila en la cantidad mínima de espacio necesaria para almacenar
ese valor. Usa un formato de almacenamiento de longitud variable para los tipos de datos numéricos, como
los enteros, los float y los decimales, y almacena cadenas de caracteres de longitud fija con el formato de
longitud variable.

 Compresión de página: la compresión de página es un supraconjunto de la compresión de fila, ya que todas

las páginas se comprimirán inicialmente en filas antes de aplicar la compresión de página. A continuación, se
aplican a los datos una combinación de técnicas denominada "compresión de prefijo y diccionario". La
compresión de prefijo elimina los datos redundantes de una sola columna y almacena los punteros de nuevo
en el encabezado de página. Después de ese paso, la compresión de diccionario busca valores repetidos en
una página y los reemplaza por punteros, lo que reduce aún más el almacenamiento. Cuanto mayor sea la
redundancia de los datos, mayor será el ahorro de espacio al comprimir los datos.
  Compresión de archivo del almacén de columnas: los objetos del almacén de columnas siempre están
comprimidos; sin embargo, se pueden comprimir aún más mediante la compresión de archivo, que usa el
algoritmo de compresión XPRESS de Microsoft en los datos. Es mejor usar este tipo de compresión para los
datos que se leen con poca frecuencia, pero que deben conservarse por motivos legales o empresariales, ya
que, aunque estos datos puedan comprimirse aún más, el costo de la CPU que implica la descompresión
tiende a ser mayor que las ventajas de rendimiento derivadas de la reducción de E/S.

Opciones adicionales

A continuación se muestra una lista de características y acciones adicionales de SQL Server que se deben tener en
cuenta para las cargas de trabajo de producción:

 Habilite la compresión de copias de seguridad.

 Habilite la inicialización instantánea de archivos para archivos de datos.

 Limite el crecimiento automático de la base de datos.

 Deshabilitar autohrink/autoclose para las bases de datos

 Mueva todas las bases de datos a discos de datos, incluidas bases de datos del sistema

 Mueva los directorios de archivos de seguimiento y registros de errores de SQL Server a discos de datos

 Establecer límites máximos de memoria de SQL Server

 Habilite el bloqueo de las páginas en la memoria.

 Habilitar la optimización para cargas de trabajo ad hoc para entornos pesados de OLTP

 Habilite el Almacén de consultas.

 Programar trabajos del Agente SQL Server para ejecutar DBCC CHECKDB, reorganizar índices, recompilar
índices y actualizar estadísticas

 Supervisar y administrar el estado y el tamaño de los archivos de registro de transacciones

Para obtener más información sobre los procedimientos recomendados de rendimiento, consulte Best practices for
SQL Server on Azure VMs (Procedimientos recomendados para SQL Server en máquinas virtuales de Azure).

Explorar las opciones de alta disponibilidad y recuperación ante desastres

Además de la alta disponibilidad integrada, la plataforma Azure ofrece dos opciones para proporcionar niveles más
altos de disponibilidad para las máquinas virtuales y algunas cargas de trabajo de PaaS. Las zonas y los conjuntos de
disponibilidad protegen las cargas de trabajo de la actividad de mantenimiento planeado y los posibles errores de
hardware.

Opciones de alta disponibilidad

La mayoría de las soluciones de alta disponibilidad de SQL Server están disponibles en máquinas virtuales (VM) de
Azure. En una solución exclusiva de Azure, todo el sistema HADR se ejecuta en Azure. En una configuración híbrida,
una parte de la solución se ejecuta en Azure y la otra parte se ejecuta localmente en su organización. La flexibilidad
del entorno Azure permite migrar total o parcialmente a Azure a fin de satisfacer los requisitos de presupuesto y
HADR de sus sistemas de bases de datos de SQL Server.

Zonas de disponibilidad

Las zonas de disponibilidad son ubicaciones físicas únicas dentro de una región. Cada zona consta de uno o varios
centros de datos equipados con alimentación, refrigeración y redes independientes. En las regiones de Azure donde
está disponible el servicio Availability Zones, puede especificar en qué zona desea que resida la máquina virtual
cuando elija utilizar zonas de disponibilidad durante la creación de la máquina virtual. Hay tres zonas de
disponibilidad en cada región de Azure donde está disponible el servicio. La característica Availability Zones
proporciona alta disponibilidad frente a errores en el centro de datos cuando se implementan varias máquinas
virtuales en diferentes zonas. Además, también proporcionan un medio para que Microsoft lleve a cabo los trabajos
de mantenimiento (mediante una agrupación denominada dominio de actualización) dentro de cada región,
actualizando solo una zona en un momento dado. Puede distribuir su ecosistema de máquinas virtuales en tres zonas
de la región. El uso de zonas de disponibilidad junto con las máquinas virtuales de Azure aumenta el tiempo de
actividad a cuatro nueves (99,99 %), que equivale a un máximo de 52,60 minutos de tiempo de inactividad al año.
Para saber en qué regiones de Azure está disponible el servicio Availability Zones, consulte docs.microsoft.com. Si el
servicio Availability Zones está disponible en su región y la aplicación admite la latencia mínima entre zonas, las zonas
de disponibilidad le proporcionarán el máximo nivel de disponibilidad a la aplicación.

En la imagen anterior, se muestra la configuración de las zonas de disponibilidad. Cuando implementa una máquina
virtual en una región con una zona de disponibilidad, se le ofrece la opción de implementarla en las zonas 1, 2 y 3.
Estas zonas son representaciones lógicas de centros de datos físicos, es decir, una implementación en la zona 1 en
una suscripción no significa que la zona 1 representa el mismo centro de datos en otra suscripción.

Conjuntos de disponibilidad

Los conjuntos de disponibilidad son similares a Availability Zones, pero, en lugar de distribuir las cargas de trabajo
entre los centros de datos de una región, se reparten entre los servidores y los bastidores de un centro de datos.
Dado que casi todas las cargas de trabajo de Azure son virtuales, puede usar conjuntos de disponibilidad para
garantizar que las dos máquinas virtuales que contienen los miembros del grupo de disponibilidad Always On no se
ejecuten en el mismo host físico. Los conjuntos de disponibilidad pueden proporcionar hasta un 99,95% de
disponibilidad y deben usarse cuando el servicio Availability Zones no esté disponible en una región, o cuando una
aplicación no pueda tolerar la latencia dentro de la zona.

Grupos de disponibilidad (AG) Always On

Los grupos de disponibilidad Always On pueden implementarse entre dos o más (hasta un máximo de nueve)
instancias de SQL Server que se ejecuten en máquinas virtuales de Azure o en un centro de datos local y Azure. En un
grupo de disponibilidad, las transacciones de bases de datos se confirman en la réplica principal y, después, se envían
de forma sincrónica o asincrónica a todas las réplicas secundarias. La distancia física entre los servidores (es decir, si
están o no en la misma región de Azure) indica el modo de disponibilidad que debe elegir. En general, si la carga de
trabajo requiere la menor latencia posible o si las réplicas secundarias están distribuidas geográficamente, se
recomienda el modo de disponibilidad asincrónica. Si las réplicas están en la misma región de Azure y las aplicaciones
pueden soportar cierto nivel de latencia, debe considerarse el modo de confirmación sincrónica. El modo sincrónico
ayuda a asegurarse de que cada transacción se confirme en una o varias réplicas secundarias antes de permitir que la
aplicación continúe. Los grupos de disponibilidad Always On proporcionan alta disponibilidad y recuperación ante
desastres, ya que un único grupo de disponibilidad puede admitir los modos de disponibilidad sincrónico y
asincrónico. La unidad de conmutación por error para un grupo de disponibilidad es un grupo de bases de datos, no
toda la instancia.

Se pueden usar grupos de disponibilidad Always On para la recuperación ante desastres. Puede implementar hasta
nueve réplicas de una base de datos en las regiones de Azure y ampliar esta arquitectura aún más usando grupos de
disponibilidad distribuidos. Los grupos de disponibilidad garantizan que haya una copia viable de las bases de datos
en otra ubicación aparte de la región primaria. De esta forma, se asegura de que su ecosistema de datos esté
protegido frente a desastres naturales y algunos producidos por personas.

En la imagen anterior, se muestra un diagrama lógico de un grupo de disponibilidad Always On que se ejecuta en un
clúster de conmutación por error de Windows Server. Hay una réplica principal y cuatro réplicas secundarias. En este
escenario, las cinco réplicas podrían ser sincrónicas o una combinación de réplicas sincrónicas y asincrónicas. Tenga
en cuenta que la unidad de conmutación por error es el grupo de bases de datos, no la instancia. Aunque una
instancia de clúster de conmutación por error proporciona alta disponibilidad a nivel de instancia, no proporciona
recuperación ante desastres.

Instancias del clúster de conmutación por error de SQL Server

Si necesita proteger toda la instancia, puede usar una instancia de clúster de conmutación por error (FCI) de
SQL Server, que proporciona alta disponibilidad para una instancia completa, en una sola región. Una instancia FCI no
proporciona recuperación ante desastres si no se combina con otra característica, como los grupos de disponibilidad
o el trasvase de registros. Las instancias FCI requieren también almacenamiento compartido, que se puede
proporcionar en Azure mediante el almacenamiento de archivos compartido o mediante Espacios de
almacenamiento directo en Windows Server.

En el caso de las cargas de trabajo de Azure, los grupos de disponibilidad son la solución de preferencia para las
implementaciones más recientes, ya que el almacenamiento compartido que requieren las instancias FCI aumenta la
complejidad de las implementaciones. Sin embargo, para las migraciones desde soluciones locales, puede ser
necesaria una instancia FCI para la compatibilidad con aplicaciones.

Opciones de recuperación de desastres

Aunque la plataforma Azure ofrece un 99,9 % de tiempo de actividad de forma predeterminada, todavía pueden
producirse desastres que afecten al tiempo de actividad de la aplicación. Es importante tener un plan de
recuperación ante desastres adecuado cuando se esté realizando cualquier tipo de migración. Azure ofrece varios
métodos para asegurarse de que el servidor SQL Server de una máquina virtual esté protegido en el caso de que se
produzca un desastre. Hay dos componentes para esta protección. En primer lugar, hay opciones de la plataforma de
Azure, como el almacenamiento con replicación geográfica para copias de seguridad y Azure Site Recovery, que es
una solución de recuperación ante desastres completa para todas las cargas de trabajo. En segundo lugar, hay ofertas
específicas de SQL Server, como los grupos de disponibilidad y las copias de seguridad.

Copias de seguridad de SQL Server nativas

Las copias de seguridad se consideran un elemento vital para cualquier administrador de bases de datos, también
cuando se trabaja con una solución en la nube. Con SQL Server en una máquina virtual de Azure, tiene un control
pormenorizado sobre cuándo se realizan las copias de seguridad y dónde se almacenan. Puede usar trabajos del
Agente SQL para realizar una copia de seguridad directamente en una dirección URL vinculada a Azure Blob Storage.
Azure ofrece la opción de usar almacenamiento con redundancia geográfica (GRS) o almacenamiento con
redundancia geográfica con acceso de lectura (RA-GRS) para asegurarse de que los archivos de copia de seguridad se
almacenan de forma segura en el entorno geográfico.

Además, como parte del proveedor de servicios de máquina virtual de Azure SQL, puede dejar que la plataforma
administre las copias de seguridad automáticamente.

Azure Backup para SQL Server

La solución Azure Backup requiere que haya un agente instalado en la máquina virtual. El agente, después, se
comunica con un servicio de Azure que administra las copias de seguridad automáticas de las bases de datos de
SQL Server. Azure Backup proporciona también una ubicación central que puede usar para administrar y supervisar
las copias de seguridad con el fin de alcanzar posibles métricas de RPO/RTO que se hayan especificado.

Como se muestra aquí, Azure Backup es una solución completa de copias de seguridad para empresas que
proporciona retención de los datos a largo plazo, administración automatizada y protección adicional de los datos.
Esta opción cuesta algo más que simplemente realizar sus propias copias de seguridad o usar el proveedor de
recursos de Azure para SQL Server, pero ofrece un conjunto de características de copia de seguridad más completo.

Azure Site Recovery

Azure Site Recovery es una solución de bajo costo que permite replicar máquinas virtuales de Azure a nivel de
bloque. Este servicio ofrece varias opciones, incluida la capacidad para probar y comprobar la estrategia de
recuperación ante desastres. Esta solución es más adecuada para entornos sin estado (por ejemplo, servidores web)
frente a las máquinas virtuales de bases de datos transaccionales.

Azure Site Recovery se puede usar con SQL Server, pero tenga en cuenta que deberá establecer un punto de
recuperación más alto, lo que significa una posible pérdida. En este caso, el RTO será básicamente el RPO.

RTO (Recovery Time Objective) y RPO (Recovery Point Objective):

 RTO (Recovery Time Objective): Es el tiempo máximo aceptable en el que un sistema debe restaurarse
después de una falla para evitar impactos graves en el negocio.

 RPO (Recovery Point Objective): Es la cantidad máxima de datos que una organización está dispuesta a
perder en caso de una interrupción. Se mide en tiempo (ejemplo: 15 minutos, 1 hora).

1. La máquina virtual está registrada en Azure Site Recovery.

2. Los datos se replican continuamente en la memoria caché

3. La memoria caché se replica en la cuenta de almacenamiento de destino

4. Durante la conmutación por error, la máquina virtual se agrega al entorno de destino.

Implementación de soluciones PaaS con Azure SQL

La oferta de plataforma como servicio (PaaS) para SQL Server puede ser una excelente solución para ciertas cargas de
trabajo. La oferta de PaaS proporciona un control menos pormenorizado sobre la infraestructura. También relega la
administración de los componentes subyacentes (memoria, CPU, almacenamiento, sistema operativo, etc.) a
Microsoft Azure.

Este módulo se centrará en las maneras de aprovisionar e implementar Azure SQL Database, instancias de Azure SQL
Managed Instance y Azure SQL Edge, y proporcionará instrucciones sobre las diversas opciones al realizar una
migración a estas plataformas.

Explicación de las opciones de PaaS para implementar SQL Server en Azure

Una plataforma como servicio (PaaS) proporciona un entorno de desarrollo e implementación completo en la nube,
que se puede usar para aplicaciones sencillas basadas en la nube, así como para aplicaciones empresariales
avanzadas.

Azure SQL Database y Azure SQL Managed Instance forman parte de la oferta de PaaS para Azure SQL.

 Azure SQL Database: parte de una familia de productos creados sobre el motor de SQL Server, en la nube.
Proporciona a los desarrolladores una gran flexibilidad para crear servicios de aplicación y opciones de
 implementación granulares a gran escala. SQL Database ofrece una solución de bajo mantenimiento que
puede ser una excelente opción para determinadas cargas de trabajo.

 Azure SQL Managed Instance: es mejor para la mayoría de los escenarios de migración a la nube, ya que
proporciona servicios y funcionalidades totalmente administrados.

Como se ve en la imagen anterior, cada oferta proporciona un cierto nivel de administración que se tiene sobre la
infraestructura y el grado de relación coste-eficacia.

Modelos de implementación

Azure SQL Database está disponible en dos modelos de implementación diferentes:

 Una sola base de datos: una base de datos única que se factura y administra por nivel de base de datos.
Cada una de las bases de datos se administra individualmente desde perspectivas de escala y tamaño de
datos. Cada base de datos implementada en este modelo tiene sus propios recursos dedicados, incluso si se
implementa en el mismo servidor lógico.

 Grupos elásticos: un grupo de bases de datos que se administran juntas y comparten un conjunto común de
recursos. Los grupos elásticos proporcionan una solución rentable para el modelo de aplicación de software
como servicio, ya que los recursos se comparten entre todas las bases de datos. Puede configurar recursos
basados en el modelo de compra basado en DTU o en el modelo de compra basado en núcleo virtual.

Modelo de compra

En Azure, todos los servicios están respaldados por hardware físico y puede elegir entre dos modelos de compra
diferentes:

Unidad de transacción de base de datos (DTU)

Las DTU se calculan en función de una fórmula que combina el proceso, el almacenamiento y los recursos de E/S. Es
una buena opción para los clientes que quieren disponer de opciones de recursos sencillas y configuradas
previamente.
El modelo de compra de DTU viene en varios niveles de servicio diferentes: Básico, Estándar y Premium. Cada nivel
tiene funcionalidades distintas, que proporcionan una amplia gama de opciones al elegir esta plataforma.

En términos de rendimiento, el nivel Básico se usa para cargas de trabajo menos exigentes, mientras que el Premium
se usa para los requisitos de cargas de trabajo intensivas.

Los recursos de proceso y almacenamiento dependen del nivel de DTU y proporcionan varias funcionalidades de
rendimiento con un límite de almacenamiento fijo, retención de copia de seguridad y costo.

Nota: El modelo de compra de DTU solo es compatible con Azure SQL Database.

Para más información sobre el modelo de compra de DTU, consulte Información general sobre el modelo de compra
basado en DTU.

vCore

El modelo de núcleo virtual permite comprar un número especificado de núcleos virtuales basado en las cargas de
trabajo dadas. El núcleo virtual es el modelo de compra predeterminado al comprar recursos de Azure SQL Database.
Las bases de datos de núcleo virtual tienen una relación específica entre el número de núcleos y la cantidad de
memoria y almacenamiento que se proporciona a la base de datos. El modelo de compra de núcleo virtual es
compatible con Azure SQL Database y Azure SQL Managed Instance.

También puede adquirir bases de datos de núcleo virtual en tres niveles de servicio diferentes:

 De uso general: este nivel es para cargas de trabajo de uso general. Está respaldado por el almacenamiento
prémium de Azure. Tendrá una latencia mayor que Crítico para la empresa. También proporciona los
siguientes niveles de proceso:

o Aprovisionado: los recursos de proceso se reasignan previamente. Facturación por hora según los
núcleos virtuales configurados.

o Sin servidor: los recursos de proceso se escalan automáticamente. Facturación por segundo según
los núcleos virtuales usados.

 Crítico para la empresa: este nivel es para cargas de trabajo de alto rendimiento que ofrecen la menor
latencia de cualquier nivel de servicio. Este nivel está respaldado por SSD locales, en lugar de Azure Blob
Storage. También ofrece la máxima resistencia a los errores, además de proporcionar una réplica de base de
datos de solo lectura integrada que se puede usar para descargar cargas de trabajo de informes.

 Hiperescala: las bases de datos de hiperescala pueden escalar más allá del límite de 4 TB el resto de las
ofertas de Azure SQL Database y tener una arquitectura única que admita bases de datos de hasta 100 TB.

Sin servidor

La denominación “Sin servidor” puede resultar un poco confusa, dado que el usuario sigue implementando Azure
SQL Database en un servidor lógico, al que se conecta. Azure SQL Database sin servidor es un nivel de proceso que
aumenta o reduce verticalmente los recursos de una base de datos determinada en función de la demanda de cargas
de trabajo. Si la carga de trabajo ya no requiere recursos de proceso, la base de datos se pondrá "en pausa" y solo se
cobrará el almacenamiento durante el período en el que la base de datos se encuentre inactiva. Cuando se realice un
intento de conexión, la base de datos se “reanudará” y estará disponible.
La configuración para controlar la puesta en pausa se conoce como retraso de pausa automática y tiene un valor
mínimo de 60 minutos y un valor máximo de siete días. Si la base de datos ha estado inactiva durante ese período, se
pausará.

Una vez que la base de datos ha estado inactiva durante el período especificado, se pausará hasta que se intente
realizar una conexión posterior. La configuración de un intervalo de escalado automático de proceso y un retraso de
pausa automática afectan al rendimiento de la base de datos y a los costos de proceso.

Cualquier aplicación que use el modelo sin servidor debe configurarse para controlar los errores de conexión e incluir
lógica de reintento, ya que, al conectarse a una base de datos en pausa, se generará un error de conexión.

Otra diferencia entre el modelo sin servidor y el modelo de núcleo virtual normal de Azure SQL Database es que con
el modelo sin servidor puede especificar un número mínimo y máximo de núcleos virtuales. Los límites de memoria y
E/S son proporcionales al intervalo de núcleos virtuales especificado.

En la imagen anterior, se muestra la pantalla de configuración de una base de datos sin servidor en Azure Portal.
Tiene la opción de seleccionar como mínimo la mitad de un núcleo virtual y un máximo de 16 núcleos virtuales.

Sin servidor no es totalmente compatible con todas las características de Azure SQL Database, ya que algunas
requieren la ejecución de procesos en segundo plano en todo momento, como por ejemplo:

 Replicación geográfica

 Retención de copia de seguridad a largo plazo

 Una base de datos de trabajo en trabajos elásticos

  La base de datos de sincronización en SQL Data Sync (Data Sync es un servicio que replica datos entre un
grupo de bases de datos)

Nota: SQL Database sin servidor solo se admite actualmente en el nivel de uso general en el modelo de compra de
núcleos virtuales.

Copias de seguridad

Una de las características más importantes de la oferta de plataforma como servicio son las copias de seguridad. En
este caso, las copias de seguridad se realizan automáticamente sin intervención del usuario. Las copias de seguridad
se almacenan en el almacenamiento con redundancia geográfica de blobs de Azure y, de forma predeterminada, se
conservan entre 7 y 35 días, según el nivel de servicio de la base de datos. Las bases de datos básicas y de núcleo
virtual tienen como valor predeterminado siete días de retención y, en las bases de datos de núcleo virtual, el
administrador puede ajustar este valor. El tiempo de retención se puede extender mediante la configuración de la
retención a largo plazo (LTR), que permite conservar las copias de seguridad durante un máximo de 10 años.

Para proporcionar redundancia, también puede usar el almacenamiento de blobs con redundancia geográfica con
acceso de lectura. Este almacenamiento replicará las copias de seguridad de base de datos en una región secundaria.
También permite leer la región secundaria, si es necesario. Las copias de seguridad manuales de las bases de datos
no están admitidas y la plataforma denegará cualquier solicitud para llevarlas a cabo.

Las copias de seguridad de base de datos se realizan según una programación determinada:

 Completa: una vez a la semana

 Diferencial: cada 12 horas

 Registro: cada 5-10 minutos, según la actividad del registro de transacciones

Esta programación de copia de seguridad debe satisfacer las necesidades de la mayoría de los objetivos de punto y
tiempo de recuperación (RPO/RTO); sin embargo, cada cliente debe evaluar si cumplen sus requisitos empresariales.

Hay varias opciones disponibles para restaurar una base de datos. Debido a la naturaleza de PaaS, no puede restaurar
una base de datos manualmente mediante métodos convencionales, como la emisión del comando T-SQL RESTORE
DATABASE.

Independientemente del método de restauración que se implemente, no es posible realizar una restauración en una
base de datos existente. Si es necesario restaurar una base de datos, se debe anular o cambiar el nombre de la base
de datos existente antes de iniciar el proceso de restauración. Además, tenga en cuenta que, según el nivel de
servicio de la plataforma, los tiempos de restauración no están garantizados y podrían fluctuar. Se recomienda probar
el proceso de restauración para obtener métricas de línea base sobre cuánto tiempo podría tardar una restauración.

Las opciones de restauración disponibles son las siguientes:

 Restauración mediante Azure Portal: con Azure Portal tiene la opción de restaurar una base de datos al
mismo servidor de Azure SQL Database, o bien puede usar la restauración para crear una nueva base de
datos en un nuevo servidor de cualquier región de Azure.

 Restauración mediante lenguajes de scripting: se puede usar tanto PowerShell como la CLI de Azure para
restaurar una base de datos.

Nota

La copia de seguridad de solo copia en Azure Blob Storage está disponible para SQL Managed Instance. SQL Database
no admite esta característica.

Para más información sobre las copias de seguridad automatizadas, vea Copias de seguridad automatizadas:
Azure SQL Database y Azure SQL Managed Instance.
Replicación geográfica activa

La replicación geográfica es una característica de continuidad del negocio que replica de forma asincrónica una base
de datos en un máximo de cuatro réplicas secundarias. A medida que las transacciones se confirman en la réplica
principal (y sus réplicas dentro de la misma región), las transacciones se envían a las réplicas secundarias que se van
a reproducir. Dado que esta comunicación se realiza de forma asincrónica, la aplicación que realiza la llamada no
tiene que esperar a que la réplica secundaria confirme la transacción antes de que SQL Server devuelva el control al
autor de la llamada.

Las bases de datos secundarias son legibles y se pueden usar para descargar cargas de trabajo de solo lectura,
liberando así los recursos para cargas de trabajo transaccionales en el servidor principal o colocando los datos más
cerca de los usuarios finales. Además, las bases de datos secundarias pueden estar en la misma región que la
principal o en otra región de Azure.

Con la replicación geográfica, puede iniciar una conmutación por error, manualmente por parte del usuario o desde
la aplicación. Si se produce una conmutación por error, es posible que necesite actualizar las cadenas de conexión de
la aplicación para reflejar el nuevo punto de conexión de lo que ahora es la base de datos principal.

Grupos de conmutación por error

Los grupos de conmutación por error se basan en la tecnología usada en la replicación geográfica, pero proporcionan
un punto de conexión único para la conexión. La principal razón para el uso de grupos de conmutación por error es
que la tecnología proporciona puntos de conexión, que se pueden usar para enrutar el tráfico a la réplica adecuada.
La aplicación puede conectarse después de una conmutación por error sin cambios en la cadena de conexión.

Explorar una única base de datos SQL

Veremos varios métodos para implementar un singleton de Azure SQL Database.

Implementación mediante el portal

El proceso para crear una base de datos singleton mediante Azure Portal es sencillo. En el portal, en el menú de
navegación izquierdo, seleccione “bases de datos SQL”. En el cuadro de diálogo deslizante resultante, haga clic en
“Crear”:
En la hoja de la imagen siguiente, observará que la suscripción ya debe haberse proporcionado. Necesitará tener a
mano la siguiente información:

 Grupo de recursos: si hay un grupo de recursos que quiere usar, puede seleccionarlo en la lista desplegable.
Puede hacer clic en la opción “Crear nuevo” si quiere crear un nuevo grupo de recursos para Azure SQL
Database.

 Nombre de la base de datos: debe proporcionar un nombre de base de datos.

 Servidor – cada base de datos debe residir en un servidor lógico. Si ya existe uno en la región adecuada,
puede optar por usarlo. De lo contrario, puede hacer clic en Crear nuevo y seguir las indicaciones para crear
un nuevo servidor lógico para alojar la base de datos.

 ¿Quiere usar un grupo elástico de SQL? Determinar si se va a usar un grupo elástico.

 Proceso y almacenamiento: determine los recursos de proceso adecuados necesarios. De forma

predeterminada, será de 2 núcleos virtuales, quinta generación (Gen5), con 32 GB de almacenamiento, hasta
que se seleccione otra opción. Haga clic en Configurar base de datos para ver las opciones de configuración
alternativas.
En la imagen siguiente se muestra la hoja del portal en la que puede configurar las opciones de la base de datos. Aquí
observará que el nivel de servicio es De uso general y que el nivel de proceso es Aprovisionado. Aprovisionado
implica que los recursos de proceso se asignan previamente y se facturan por hora según el número de núcleos
virtuales configurados. La otra opción es Sin servidor, que se explicó anteriormente. Sin servidor se factura por
segundo según el número de núcleos virtuales que se usen.

Implementación de Azure SQL Database mediante PowerShell o CLI

También puede implementar la base de datos mediante Azure PowerShell o la CLI de Azure. En la imagen siguiente se
muestra el ejemplo de PowerShell en el que se crea un grupo de recursos y se define un administrador denominado
SqlAdmin y, posteriormente, se crea un servidor, una base de datos y una regla de firewall.

# Connect-AzAccount

# The SubscriptionId in which to create these objects

$SubscriptionId = ''

# Set the resource group name and location for your server

$resourceGroupName = "myResourceGroup-$(Get-Random)"

$location = "westus2"

# Set an admin login and password for your server

$adminSqlLogin = "SqlAdmin"
$password = "ChangeYourAdminPassword1"

# Set server name - the logical server name has to be unique in the system

$serverName = "server-$(Get-Random)"

# The sample database name

$databaseName = "mySampleDatabase"

# The ip address range that you want to allow to access your server

$startIp = "0.0.0.0"

$endIp = "0.0.0.0"

# Set subscription

Set-AzContext -SubscriptionId $subscriptionId

# Create a resource group

$resourceGroup = New-AzResourceGroup -Name $resourceGroupName -Location $location

# Create a server with a system wide unique server name

$server = New-AzSqlServer -ResourceGroupName $resourceGroupName -ServerName $serverName -Location

$location -SqlAdministratorCredentials $(New-Object -TypeName System.Management.Automation.PSCredential -
ArgumentList $adminSqlLogin, $(ConvertTo-SecureString -String $password -AsPlainText -Force))

# Create a server firewall rule that allows access from the specified IP range

$serverFirewallRule = New-AzSqlServerFirewallRule -ResourceGroupName $resourceGroupName -ServerName

$serverName -FirewallRuleName "AllowedIPs" -StartIpAddress $startIp -EndIpAddress $endIp

# Create a blank database with an S0 performance level

$database = New-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -

DatabaseName $databaseName -RequestedServiceObjectiveName "S0" -SampleName "AdventureWorksLT"
También se puede usar la CLI de Azure para implementar Azure SQL Database, como se muestra a continuación:

#!/bin/bash

# set execution context (if necessary)

az account set --subscription <replace with your subscription name or id>

# Set the resource group name and location for your server

resourceGroupName=myResourceGroup-$RANDOM

location=westus2

# Set an admin login and password for your database

adminlogin=ServerAdmin

password=`openssl rand -base64 16`

# password=<EnterYourComplexPasswordHere1>

# The logical server name has to be unique in all of Azure

servername=server-$RANDOM

# The ip address range that you want to allow to access your DB

startip=0.0.0.0

endip=0.0.0.0

# Create a resource group

az group create \

--name $resourceGroupName \

--location $location

# Create a logical server in the resource group

az sql server create \

--name $servername \

--resource-group $resourceGroupName \

--location $location \

--admin-user $adminlogin \
--admin-password $password

# Configure a firewall rule for the server

az sql server firewall-rule create \

--resource-group $resourceGroupName \

--server $servername \

-n AllowYourIp \

--start-ip-address $startip \

--end-ip-address $endip

# Create a database in the server

az sql db create \

--resource-group $resourceGroupName \

--server $servername

--name mySampleDatabase \

--sample-name AdventureWorksLT \

--edition GeneralPurpose \

--family Gen4 \

--capacity 1 \

# Echo random password

echo $password

Implementación de Azure SQL Database con plantillas de Azure Resource Manager

Otro método para implementar recursos es mediante una plantilla de Azure Resource Manager, tal como se
mencionó anteriormente. Una plantilla de Resource Manager ofrece el control más pormenorizado sobre los
recursos y Microsoft proporciona un repositorio de GitHub llamado “Azure-Quickstart-Templates”, que hospeda
plantillas de Azure Resource Manager a las que puede hacer referencia en sus implementaciones. A continuación se
muestra un ejemplo de PowerShell de implementación de una plantilla basada en GitHub:

#Define Variables for parameters to pass to template

$projectName = Read-Host -Prompt "Enter a project name"

$location = Read-Host -Prompt "Enter an Azure location (i.e. centralus)"

$adminUser = Read-Host -Prompt "Enter the SQL server administrator username"

$adminPassword = Read-Host -Prompt "Enter the SQl server administrator password" -AsSecureString

$resourceGroupName = "${projectName}rg"

#Create Resource Group and Deploy Template to Resource Group

New-AzResourceGroup -Name $resourceGroupName -Location $location

New-AzResourceGroupDeployment -ResourceGroupName $resourceGroupName -TemplateUri

"https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/101-sql-logical-server/
azuredeploy.json" -administratorLogin $adminUser -administratorLoginPassword $adminPassword

Read-Host -Prompt "Press [ENTER] to continue ..."

Implementación de un grupo elástico de Azure SQL Database

Los grupos elásticos son una opción de implementación en la que se compran recursos de proceso de Azure (CPU,
memoria y almacenamiento) que, posteriormente, se comparten entre varias bases de datos definidas como
pertenecientes al mismo grupo. Una comparación sencilla con SQL Server local es que un grupo elástico es como una
instancia de SQL Server que tiene varias bases de datos de usuario. Mediante el uso de grupos elásticos, puede
administrar fácilmente los recursos del grupo y, al mismo tiempo, ahorrar costos. Los grupos elásticos también
facilitan la escalabilidad hasta los límites establecidos, de modo que si una sola base de datos del grupo necesita
recursos debido a una carga de trabajo imprevisible, los recursos están allí. Si todo el grupo necesita recursos
adicionales, una opción de control deslizante simple en el Azure Portal facilitará el escalado horizontal o vertical del
grupo elástico.

Creación de nuevos grupos elásticos

En Azure Portal, haga clic en Crear un recurso y, después, busque Grupo de bases de datos elásticas SQL y verá la
pantalla que se muestra a continuación.

Haga clic en la opción Crear que se muestra en la imagen anterior para iniciar la pantalla que se muestra en la imagen
siguiente.
Adición de una base de datos a un grupo existente

Con Azure Portal, busque el grupo al que está agregando una base de datos, tal como se muestra en la imagen
siguiente.

En la imagen siguiente se muestra el proceso de selección de las bases de datos que quiere agregar al grupo.
Haga clic en Aplicar en la pantalla que aparece en la imagen siguiente.

Haga clic en Aplicar una vez más y la base de datos se agregará al grupo elástico.

Administración de recursos del grupo

En Azure Portal se ofrece una gran cantidad de información sobre el estado del grupo elástico. Puede ver el uso de
los recursos y qué base de datos está consumiendo la mayoría de los recursos. Esta información puede ser útil para
diagnosticar problemas de rendimiento o identificar una base de datos que podría no ser una buena elección para el
grupo, por ejemplo, cuando una base de datos está consumiendo la mayoría de los recursos del grupo. La imagen
siguiente muestra un grupo elástico con un uso de recursos equilibrado.
Si necesita ajustar el grupo para reducir o aumentar los recursos asignados al grupo, puede realizar el cambio
mediante la opción Configurar en la sección Configuración de grupo de la hoja de administración de Grupo elástico.

En esa hoja, puede ajustar de forma rápida y sencilla estos elementos:

 Tamaño del grupo, incluidos DTU, núcleos virtuales y tamaño de almacenamiento.

 Nivel de servicio

 Recursos por base de datos

 Las bases de datos que se incluyen en el grupo, agregándolas o quitándolas.

Como se muestra en la imagen siguiente, puede ajustar numerosos valores de configuración en el grupo elástico.
Muchos de estos cambios pueden realizarse en línea, incluidas las DTU mínima y máxima o los núcleos virtuales por
base de datos. Puede cambiar el tamaño total del grupo o agregar y quitar bases de datos del grupo según sea
necesario. Las conexiones activas se quitarán cuando se complete el cambio de tamaño.

Probablemente, la característica más útil es la capacidad de supervisar el uso de recursos de base de datos, tal y
como se muestra en la imagen siguiente. Esta característica le permite ver con facilidad el rendimiento de las bases
de datos en el grupo.
Un grupo elástico es una buena opción para las bases de datos de varios inquilinos, donde cada inquilino tiene su
propia copia de la base de datos. Equilibre la carga de trabajo entre bases de datos para evitar que una base de datos
monopolice todos los recursos del grupo.

Descripción de Hiperescala de base de datos SQL

Azure SQL Database se ha limitado a 4 TB de almacenamiento por base de datos durante muchos años. Esta
restricción se debe a una limitación física de la infraestructura de Azure. La Hiperescala de Azure SQL Database
cambia el paradigma y permite que las bases de datos sean de 100 TB o más. La Hiperscala presenta nuevas técnicas
de escalado horizontal para agregar nodos de proceso a medida que aumentan los tamaños de los datos. El costo de
la Hiperescala es el mismo que el costo de Azure SQL Database; sin embargo, hay un costo por terabyte de
almacenamiento. Debe tener en cuenta que una vez que Azure SQL Database se convierte en Hiperescala, no puede
volver a convertirse en un base de datos "regular" de Azure SQL. La Hiperescala es la capacidad de una arquitectura
para escalar correctamente de acuerdo con la demanda.

La Hiperescala de Azure SQL Database es una opción ideal para la mayoría de las cargas de trabajo empresariales, ya
que proporciona una gran flexibilidad y un alto rendimiento con recursos de proceso y almacenamiento escalables de
forma independiente.

Hiperescala separa el motor de procesamiento de consultas, donde la semántica de los distintos motores de datos
diverge, de los componentes que proporcionan el almacenamiento a largo plazo y la durabilidad de los datos. De este
modo, la capacidad de almacenamiento se puede escalar horizontalmente fácilmente en cuanto sea necesario.

El nivel de servicio Hiperescala de Azure SQL Database es el nivel de servicio más reciente en el modelo de compra
basado en núcleo virtual. Este nivel de servicio es un nivel altamente escalable de almacenamiento y de rendimiento
de proceso que usa Azure para escalar horizontalmente el almacenamiento y los recursos de proceso para una base
de datos de Azure SQL considerablemente más allá de los límites disponibles para los niveles de servicio Uso general
y Crítico para la empresa.

Ventajas

El nivel de servicio Hiperescala elimina muchos de los límites prácticos que tradicionalmente se ven en las bases de
datos en la nube. Donde la mayoría de las otras bases de datos están limitados por los recursos disponibles en un
único nodo, las bases de datos en el nivel de servicio Hiperescala no tienen límites de este tipo. Con su arquitectura
de almacenamiento flexible, el almacenamiento crece a medida que sea necesario. De hecho, las bases de datos de
Hiperescala no se crean con un tamaño máximo definido. Una base de datos de hiperescala aumenta según sea
necesario, y se le cobrará solo la capacidad que use. Para cargas de trabajo de lectura intensiva, el nivel de servicio
Hiperescala proporciona rápida escalabilidad horizontal mediante el aprovisionamiento de réplicas adicionales según
sea necesario para descargar las cargas de trabajo de lectura.

Además, el tiempo necesario para crear copias de seguridad de bases de datos o para escalar o reducir verticalmente
ya no está ligado al volumen de los datos en la base de datos. Pueden crearse copias de seguridad de las bases de
datos de hiperescala de manera instantánea. También puede escalar o reducir verticalmente una base de datos de
decenas de terabytes en cuestión de minutos. Esta funcionalidad le libra de la preocupación de estar atado por las
opciones de la configuración inicial. Hiperescala también proporciona restauraciones rápidas de base de datos que se
ejecutan en minutos en lugar de horas o días.

Hiperescala proporciona una rápida escalabilidad según la demanda de la carga de trabajo.

 Escalar y reducir verticalmente: puede escalar verticalmente el tamaño de proceso principal en términos de
recursos como CPU y memoria y, posteriormente, reducir verticalmente, en tiempo constante. Dado que el
almacenamiento se comparte, el escalado y la reducción vertical no están vinculados al volumen de datos de
la base de datos.

 Escalar y reducir horizontalmente: también tiene la posibilidad de aprovisionar una o varias réplicas de
proceso que puede usar para atender las solicitudes de lectura. Esto significa que puede usar estas réplicas
de proceso adicionales como réplicas de solo lectura para descargar la carga de trabajo de lectura del
proceso principal. Además de solo lectura, estas réplicas también pueden funcionar como servidores en
espera activa en caso de una conmutación por error de la réplica principal.

El aprovisionamiento de cada una de estas réplicas de proceso adicionales se puede realizar en tiempo constante y se
trata de una operación en línea. Puede conectarse a las réplicas de proceso de solo lectura estableciendo el
argumento ApplicationIntent de la cadena de conexión en ReadOnly. Todas las conexiones con la intención de
aplicaciones ReadOnly se enrutan automáticamente a una de las réplicas de proceso de solo lectura.

Hiperescala separa el motor de procesamiento de consultas de los componentes que proporcionan almacenamiento
a largo plazo y durabilidad de los datos. Esta arquitectura ofrece la posibilidad de escalar fácilmente la capacidad de
almacenamiento en la medida en que sea necesario (el objetivo inicial es de 100 TB), así como de escalar
rápidamente los recursos de proceso.

Consideraciones sobre la seguridad

La seguridad para el nivel de servicio Hiperescala comparte las mismas funcionalidades excelentes que el resto de
niveles de Azure SQL Database. Están protegidos mediante el enfoque por capas de defensa en profundidad, como se
muestra en la siguiente imagen, y se mueve desde el exterior hacia el centro:

 La seguridad de red es el primer nivel de defensa y usa reglas de firewall de IP para permitir el acceso en
función de la dirección IP de origen y las reglas de firewall de red virtual para permitir la posibilidad de
aceptar las comunicaciones enviadas desde subredes seleccionadas dentro de una red virtual.

 La administración de acceso se proporciona a través de los siguientes métodos de autenticación para

asegurarse de que un usuario es quien dice ser:

o Autenticación de SQL

o Autenticación de Microsoft Entra

o Autenticación de Windows para entidades de seguridad de Microsoft Entra (versión preliminar)

La Hiperescala de Azure SQL Database también admite la seguridad de nivel de fila. La seguridad de nivel de fila
permite a los clientes controlar el acceso a las filas de una tabla de base de datos según las características del usuario
que ejecuta una consulta (por ejemplo, la pertenencia a grupos o el contexto de ejecución).
  Capacidades de protección contra amenazas en las funciones de auditoría y detección de amenazas. La
auditoría de SQL Database e Instancia administrada de SQL hace un seguimiento de las actividades de la base
de datos y ayuda a mantener el cumplimiento de los estándares de seguridad mediante la grabación de
eventos de la base de datos en un registro de auditoría de una cuenta de almacenamiento de Azure
propiedad del cliente. La Protección avanzada contra amenazas puede habilitarse por servidor mediante una
tarifa adicional y analiza los registros para detectar comportamientos inusuales e intentos potencialmente
dañinos de acceder a las bases de datos o aprovecharse de ellas. Las alertas se crean para detectar
actividades sospechosas, como inyección de código SQL, infiltración potencial de datos y ataques de fuerza
bruta, o anomalías en los patrones de acceso para detectar elevaciones de privilegios y uso de credenciales
vulneradas.

 Information Protection se proporciona de las siguientes maneras:

o Seguridad de la capa de transporte (cifrado en tránsito)

o Cifrado de datos transparente (cifrado en reposo)

o Administración de claves con Azure Key Vault

o Always Encrypted (cifrado en uso)

o Enmascaramiento de datos dinámicos

Consideraciones de rendimiento

El nivel de servicio Hiperescala está pensado para clientes que tienen grandes bases de datos locales de SQL Server y
quieren modernizar las aplicaciones mediante su traslado a la nube o para clientes que ya utilizan
Azure SQL Database y desean ampliar significativamente las posibilidades de crecimiento de la base de datos.
También está pensado para clientes que buscan un alto rendimiento y escalabilidad.

La Hiperescala proporciona las siguientes funciones de rendimiento:

 Copias de seguridad de base de datos casi instantáneas (basadas en las instantáneas de archivos
almacenadas en Azure Blob Storage) independientemente del tamaño sin efecto de la E/S en los recursos de
proceso.

 Restauraciones rápidas de bases de datos (basadas en instantáneas de archivos) en minutos en lugar de

horas o días (no del tamaño de la operación de datos).

 Mayor rendimiento general debido a una mayor capacidad de proceso de los registros de transacciones y
tiempos más rápidos de confirmación de estas, independientemente de los volúmenes de datos.

 Rápido escalado horizontal: puede aprovisionar una o varias réplicas de solo lectura para la descarga de la
carga de trabajo de lectura y para su uso como esperas activas.

 Rápido escalado vertical: en tiempo constante, puede escalar verticalmente los recursos de proceso para dar
cabida a cargas de trabajo pesadas cuando sea necesario y, después, reducir verticalmente los recursos de
proceso cuando no sean necesarios.

Nota

La Hiperescala de SQL Database no admite las siguientes características:

 Instancia administrada de SQL

 Grupos elásticos

 Replicación geográfica

 Información del rendimiento de las consultas

Implementación de la Hiperescala de Azure SQL Database

Para implementar Azure SQL Database con el nivel Hiperescala:

1. Vaya a la página Seleccione una opción de implementación de SQL.

2. En Bases de datos SQL, deje Tipo de recurso establecido en Base de datos única y seleccione Crear.

3. En la pestaña Aspectos básicos de la página Crear SQL Database, seleccione la suscripción que quiera, el
grupo de recursos y el nombre de la base de datos.

4. Seleccione el vínculo Crear nuevo para el Servidor y rellene la nueva información del servidor, como el
nombre del servidor, el inicio de sesión y la contraseña del administrador del servidor y la ubicación.

5. En Proceso y almacenamiento, seleccione el vínculo Configurar base de datos.

6. En Nivel de servicio, seleccione Hiperescala.
7. En Configuración de hardware, seleccione el vínculo Cambiar configuración. Revise las configuraciones de
hardware disponibles y seleccione la configuración más adecuada para la base de datos. Para este ejemplo,
vamos a seleccionar la configuración Gen5.
8. Seleccione Aceptar para confirmar la generación de hardware.
9. Opcionalmente, ajuste el control deslizante Núcleos virtuales si desea aumentar el número de núcleos
virtuales de la base de datos. En este ejemplo, vamos a seleccionar 2 núcleos virtuales.
10. Ajuste el control deslizante Réplicas secundarias de alta disponibilidad para crear una réplica de alta
disponibilidad (HA). Seleccione Aplicar.
11. Seleccione Siguiente: Redes en la parte inferior de la página.
 12. En Reglas de firewall, en la pestaña Redes, establezca Agregar dirección IP del cliente actual en Sí. Deje la
opción Permitir que los servicios y recursos de Azure accedan a este grupo de servidores establecida en No.
13. Seleccione Siguiente: Seguridad en la parte inferior de la página.
14. En la pestaña Revisar y crear, seleccione Crear.

Examinar Azure SQL Managed Instance

Aunque muchas organizaciones migran inicialmente a Azure mediante las ofertas de IaaS, la oferta de servicio de
plataforma como servicio (PaaS) permite obtener ventajas adicionales. Además, ya no tiene que instalar o aplicar
parches de SQL Server, ya que lo lleva a cabo el servicio. La comprobación de coherencia y las copias de seguridad
también forman parte del servicio administrado, que incluye herramientas adicionales de seguridad y rendimiento
que forman parte de las ofertas de PaaS.

Azure SQL Managed Instance es una instancia de SQL Server totalmente funcional que es casi 100 % compatible con
el ecosistema local. Incluye características como Agente SQL, acceso a tempdb, consulta entre bases de datos y
Common Language Runtime (CLR). El servicio utiliza la misma infraestructura que Azure SQL Database y todas las
ventajas del servicio PaaS, como copias de seguridad automáticas, revisiones automáticas y alta disponibilidad
integrada.

Características de Azure SQL Managed Instance

Azure SQL Managed Instance permite rutas de migración sencilla para las aplicaciones existentes, ya que permite
realizar restauraciones desde copias de seguridad locales. A diferencia de Azure SQL Database, que está diseñado en
torno a estructuras de base de datos única,SQL Managed Instance proporciona una instancia de SQL Server
completa, que permite hasta 100 bases de datos y proporciona acceso a las bases de datos del sistema. SQL
Managed Instance proporciona otras características que no están disponibles en Azure SQL Database, incluidas las
consultas entre bases de datos y Common Language Runtime (CLR); además, junto con la base de datos del sistema
msdb, permite el uso del Agente SQL.

Opciones

Hay dos niveles de servicio disponibles al crear una instancia de Azure SQL Managed Instance y son los mismos que el
modelo de núcleo virtual de Azure SQL Database (la instancia administrada se compra con el modelo de núcleo
virtual), el nivel Crítico para la empresa y el nivel De uso general. Existen diferencias de funcionalidad mínimas entre
los dos niveles: las dos principales son que Crítico para la empresa incluye OLTP en memoria y ofrece una instancia
secundaria legible, y ninguna de ellas está disponible con el nivel De uso general. Ambos niveles ofrecen la misma
disponibilidad y permiten la configuración independiente del almacenamiento y el proceso.

Versión preliminar de la característica de vinculación

La característica de vinculación proporciona funcionalidad híbrida de replicación de bases de datos de instancias de

SQL Server a Azure SQL Managed Instance. La característica de vinculación replica los datos mediante grupos de
disponibilidad distribuidos disponibles en la tecnología de grupos de disponibilidad Always On. Los registros de
transacciones se replican como parte de los grupos de disponibilidad distribuidos.

Los registros de transacciones de la instancia principal no se pueden truncar hasta que se hayan replicado en la
instancia secundaria. La realización de copias de seguridad del registro de transacciones de forma periódica reduce el
riesgo de quedarse sin espacio en la instancia principal.

La característica de vinculación también se puede usar como solución de recuperación ante desastres híbrida, donde
puede conmutar por error las bases de datos de SQL Server hospedadas en cualquier lugar en una base de datos que
se ejecute en SQL Managed Instance. Del mismo modo, puede usar la característica de vinculación para proporcionar
una base de datos secundaria de solo lectura en SQL Database SQL Managed Instance para descargar operaciones de
solo lectura intensivas.

Para obtener más información sobre cómo configurar la característica de vínculo para Azure SQL Managed Instance,
consulte Preparación del entorno para la característica de vinculación: Azure SQL Managed Instance.

Grupo de instancias (versión preliminar)

El grupo de instancias proporciona una manera rentable de migrar pequeñas instancias de SQL Server a la nube. Al
migrar a Azure, en lugar de consolidar bases de datos más pequeñas en una instancia administrada más grande, lo
que requiere un planeamiento adicional de gobernanza y seguridad, los grupos de instancias le permiten
aprovisionar previamente los recursos en función de los requisitos y los recursos de migración totales.

La característica del grupo de instancias proporciona un tiempo de implementación rápido de hasta cinco minutos,
una buena opción para escenarios en los que la duración de la implementación es importante. Además, todas las
instancias de un grupo comparten la misma máquina virtual y la asignación de IP total es independiente del número
de instancias implementadas.

Para obtener información sobre cómo implementar un grupo de instancias para SQL Managed Instance,
consulte Implementación de Instancia administrada de Azure SQL en un grupo de instancias.

Alta disponibilidad
Dado que Azure SQL Managed Instance tiene el respaldo del servicio PaaS, tiene alta disponibilidad en el producto.
Un instancia administrada de SQL independiente ofrece un Acuerdo de Nivel de Servicio (SLA) del 99,99 %, y esto
garantiza un máximo de 52,60 minutos de tiempo de inactividad al año. La arquitectura es la misma que Azure SQL
Database con el nivel De uso general, que usa la replicación de almacenamiento para la disponibilidad, mientras que
el nivel Crítico para la empresa usa varias réplicas.

Copias de seguridad

Las copias de seguridad automáticas también se configuran automáticamente para Azure SQL Managed Instance.
Una diferencia importante entre Azure SQL Managed Instance y Azure SQL Database es que con MI puede realizar
manualmente una copia de seguridad de solo copia de una base de datos. Debe realizar una copia de seguridad en
una dirección URL, ya que no se permite el acceso al almacenamiento local. También puede configurar la retención a
largo plazo (LTR) para conservar las copias de seguridad automáticas durante un máximo de 10 años en el
almacenamiento de blobs de Azure con redundancia geográfica.

Las copias de seguridad de base de datos se realizan en la misma programación que con Azure SQL Database. Estas
programaciones no son ajustables.

 Completa: una vez a la semana

 Diferencial: cada 12 horas

 Registro de transacciones: cada 5-10 minutos, según la actividad del registro de transacciones

El proceso de restaurar una base de datos a Azure SQL Managed Instance también es similar al proceso que se realiza
con Azure SQL Database. Puede usar:

 Azure portal

 PowerShell

 Azure CLI

Sin embargo, existen algunas limitaciones a la hora de restaurar. Para restaurar de una instancia a otra, ambas
instancias deben residir en la misma suscripción y en la misma región de Azure. Tampoco se puede restaurar toda la
instancia administrada, solo las bases de datos individuales dentro de SQL Managed Instance.

Al igual que con Azure SQL Database, no se puede restaurar sobre una base de datos existente. Debe anular o
cambiar el nombre de la base de datos existente antes de restaurarla desde la copia de seguridad. Como SQL
Managed Instance es una instancia de SQL Server totalmente funcional, puede ejecutar un comando RESTORE,
mientras que con Azure SQL Database esto no es posible. Sin embargo, dado que es un servicio PaaS, hay algunas
limitaciones, como las siguientes:

 Debe restaurar desde un punto de conexión de dirección URL. No tiene acceso a unidades locales

 Puede usar las siguientes opciones (además de especificar la base de datos):

o FILELISTONLY

o HEADERONLY

o LABELONLY

o VERIFYONLY

 Los archivos de copia de seguridad que contienen varios archivos de registro no se pueden restaurar.

 Los archivos de copia de seguridad que contienen varios conjuntos de copia de seguridad no se pueden
restaurar.

 No se pueden restaurar las copias de seguridad que contengan In-Memory/FILESTREAM.

De forma predeterminada, las bases de datos de una instancia administrada se cifran mediante Cifrado de datos
transparente (TDE) con una clave administrada de Microsoft. Para realizar una copia de seguridad de solo copia
iniciada por el usuario, debe desactivar TDE para la base de datos específica. Sin embargo, si una base de datos está
cifrada, puede restaurarla, por lo que tendrá que asegurarse de que tiene acceso al certificado o a la clave asimétrica
que se usó para cifrar la base de datos. Si no tiene ninguno de estos dos elementos, no podrá restaurar la base de
datos a un instancia administrada de SQL.

Recuperación ante desastres

Azure SQL Managed Instance ofrece grupos de conmutación por error automática como un medio para implementar
la recuperación ante desastres. Esta característica protege toda la instancia administrada y todas las bases de datos
que contiene, no solo las bases de datos específicas. Este proceso replica asincrónicamente los datos de Azure SQL
Managed Instance en una instancia secundaria; sin embargo, actualmente se limita a la región de Azure emparejada
de la copia principal y solo se permite una réplica.

Como Azure SQL Database, los grupos de conmutación por error automática ofrecen puntos de conexión de escucha
de lectura y escritura y de solo lectura, lo cual facilita la administración de cadenas de conexión. Si se produce una
conmutación por error, las cadenas de conexión de la aplicación se enrutarán automáticamente a la instancia
adecuada. Aunque es bastante coherente con Azure SQL Database, estos puntos de conexión siguen un formato
ligeramente diferente, el formato <fog-name>.zone_id.database.windows.net whereas Azure SQL Database is in the
<fog-name>.secondary.database.windows.net.

Cada instancia administrada, principal y secundaria, debe estar dentro de la misma zona DNS. Esta ubicación
garantizará que se puede usar el mismo certificado de varios dominios para la autenticación de la conexión de cliente
entre cualquiera de las dos instancias del mismo grupo de conmutación por error. Puede especificar un “Asociado de
zona DNS” mediante varios métodos, como Azure Portal, PowerShell o la CLI de Azure.

Para obtener información sobre las nuevas características de Azure SQL Managed Instance, consulte Novedades de
Azure SQL Managed Instance.

Describir SQL Edge

Muchas organizaciones tienen inversiones sustanciales en la infraestructura de IoT. Una arquitectura de solución de
IoT típica incluye dispositivos IoT responsables de leer sensores ambientales para generar datos de los clientes.
Normalmente, estos datos se procesan en el sitio mediante dispositivos Edge. Además, un dispositivo de IoT Edge
puede ejecutar contenedores compatibles con Docker que contengan lógica de negocios personalizada o versiones
ligeras de servicios en la nube, como Azure Stream Analytics, Azure Machine Learning, Azure Functions, Azure
SQL, etc. La ventaja de IoT Edge es que el procesamiento se produce en la red local, lo que da lugar a un bucle de
comentarios más rápido si es necesario realizar cualquier acción, al mismo tiempo que se minimizan los costos de
ancho de banda y procesamiento en la nube.

Azure SQL Edge es un motor de base de datos relacional optimizado diseñado específicamente para cargas de trabajo
de IoT. Proporciona funcionalidades para transmitir, procesar y analizar datos relacionales y no relacionales, como
JSON, grafos y datos de serie temporal. Azure SQL Edge se basa en la versión más reciente del SQL Server Motor de
base de datos: el mismo motor que sirve como base de SQL Server y Azure SQL. Azure SQL Edge aporta
funcionalidades de programación de T-SQL, rendimiento líder del sector, seguridad y procesamiento de consultas al
perímetro.

Ventajas

Sintaxis y herramientas de T-SQL conocidas

Los desarrolladores y administradores de SQL pueden seguir aprovechando la conocida sintaxis y herramientas de T-
SQL, ya que Azure SQL Edge se basa en el Motor de base de datos de SQL Server. Las herramientas disponibles
incluyen Azure Portal, SQL Server Management Studio, Azure Data Studio, Visual Studio Code y SQL Server Data Tools
en Visual Studio.

Portabilidad

Azure SQL Edge es una versión en contenedor del Motor de base de datos de SQL Server optimizada para IoT. Azure
SQL Edge se puede implementar en varios servidores basados en Windows y Linux capaces de ejecutar el entorno de
ejecución de IoT Edge, que van desde servidores completos eficaces hasta dispositivos basados en ARM más
pequeños.

Compatibilidad con varios estados de conexión y sincronización de datos

En IoT, la conectividad a Internet no siempre es posible ni confiable. Por lo tanto, los módulos de IoT Edge deben
admitir todos los estados de conectividad. Azure SQL Edge admite escenarios conectados, desconectados e híbridos
semiconectados. La sincronización de datos incrementales es posible con el servicio Azure SQL Data Sync y la
configuración de grupos de sincronización para sincronizar las tablas que elija bidireccionalmente entre varias bases
de datos en Azure SQL e instancias de SQL Server.

El siguiente diagrama representa visualmente el modelo de sincronización personalizada. El proceso de

sincronización usa un agente de sincronización en Azure SQL Edge para sincronizar datos con la base de datos central.
Desde la perspectiva del centro, el proceso de sincronización se controla mediante una aplicación de sincronización
guiada por los detalles disponibles en la base de datos de sincronización, donde se almacenan los metadatos y los
registros de sincronización.

Streaming de datos integrado y aprendizaje automático

Azure SQL Edge tiene compatibilidad integrada con el streaming de datos hacia y desde varias entradas y salidas. Esta
funcionalidad toma prestada la misma tecnología que impulsa Azure Stream Analytics y permite la introspección de
los datos de serie temporal entrantes mediante la detección de anomalías, la ventana de tiempo, la agregación y el
filtrado. Azure SQL Edge también tiene funciones de T-SQL que admiten la consulta de datos de serie temporal.
Además, Azure SQL Edge admite la inferencia de aprendizaje automático y la instrucción PREDICT.

Consideraciones sobre la seguridad

La seguridad en Azure SQL Edge aporta controles de cifrado, clasificación y acceso de datos desde el SQL Server
Motor de base de datos. Además, Azure SQL Edge proporciona seguridad de nivel de fila, enmascaramiento dinámico
de datos y cifrado de datos transparente (TDE) como una ventaja de seguridad adicional. También es beneficioso
cifrar los archivos de copia de seguridad creados mediante un certificado o una clave asimétrica.

En cuanto al transporte de red, Azure SQL Edge utiliza la seguridad de la capa de transporte (TLS) y los certificados
para cifrar toda la comunicación. Por último, Microsoft Defender para IoT proporciona una solución de seguridad
centralizada y unificada para detectar e identificar dispositivos IoT, vulnerabilidades y amenazas. Al igual que con
cualquier solución relacionada con los datos, también es prudente asegurarse de que a los usuarios de la base de
datos se les concede el privilegio mínimo en los objetos de base de datos.

Implementación de Azure SQL Edge desde el Azure Marketplace

Azure SQL Edge está disponible en el Azure Marketplace con dos planes, Azure SQL Desarrollador de Edge (solo para
desarrollo, limitado a 4 núcleos y 32 GB de memoria) y Azure SQL Edge (para producción, limitado a 8 núcleos y
64 GB de memoria).

Como requisito previo para implementar Azure SQL Edge, debe tener un IoT Hub aprovisionado con al menos un
dispositivo IoT Edge. En este ejemplo, se ha aprovisionado previamente un IoT Hub denominado org-iot-hub y un
dispositivo de IoT Edge basado en Linux denominado iot-edge-device-1.

1.
Busque el módulo Azure SQL Edge en el Azure Marketplace y seleccione el botón Obtener ahora.

2. En el formulario modal, seleccione la SKU de plan de software deseada. En este ejemplo, se elige Azure SQL
Desarrollador de Edge. A continuación, rellene cualquier otra información de perfil requerida por el
formulario y seleccione Continuar.
3. En la pantalla Dispositivos de destino para Módulos de IoT Edge, escriba el valor de IoT Edge Nombre del
dispositivo manualmente o use la funcionalidad Buscar dispositivo para buscar el dispositivo perimetral en el
IoT Hub seleccionado. En este ejemplo, el nombre del dispositivo Edge es iot-device-edge-1. A continuación,
seleccione el botón Crear.
4. En la hoja Establecer módulos en el dispositivo, elija el elemento AzureSQLEdge en Módulos de IoT Edge.
5. En la hoja Actualizar Módulo de IoT Edge, seleccione la pestaña Variables de entorno. A continuación,
reemplace la contraseña de la cuenta de administrador de SQL Edge estableciendo el valor de la
variable MSSQL_SA_PASSWORD. Opcionalmente, agregue opciones de configuración en la pestaña Opciones
de creación de Container. Una vez completado, seleccione el botón Actualizar.

6. Si vuelve al panel Establecer módulos en el dispositivo, puede configurar el enrutamiento de mensajes para
el módulo debajo de la pestaña Rutas. Una vez completado, seleccione Revisar y crear y Crear una vez más
en la pantalla de validación.
7. Se mostrará la pantalla del dispositivo de IoT Edge. Espere unos instantes y la lista de módulos notificados del
dispositivo mostrará AzureSQLEdge en un estado en ejecución. Si el inicio del módulo no está completo,
indicará temporalmente un estado de error: espere unos minutos y actualice.
 8. Use el método de conexión deseado y empiece a usar Azure SQL Edge.

Evaluación de estrategias para migrar a Azure SQL

Comprender el nivel de compatibilidad

Históricamente, los proveedores de software que compilan software para SQL Server han certificado su software para
ejecutarlo en una versión específica del motor de base de datos. Por ejemplo, SharePoint 2016 solo se certificó para
ejecutarse en SQL Server 2014. Este proceso, denominado certificación de compatibilidad, permite que una
aplicación se ejecute en la última versión de SQL Server, manteniendo el nivel de compatibilidad admitido por el
proveedor.

El nivel de compatibilidad de SQL Server siempre ha sido una configuración del nivel de base de datos. Establecer el
nivel de compatibilidad en una versión específica permite usar palabras clave de T-SQL específicas, ya que también
determina ciertos comportamientos del optimizador de consultas. Por ejemplo, si tenía una base de datos en un nivel
de compatibilidad específico y la migró a SQL Server 2019, las formas del plan de ejecución y la sintaxis de consulta
deben seguir siendo las mismas que antes de la migración, si se trata de una versión compatible.

La versión del motor de base de datos para Azure SQL Database y Azure SQL Managed Instance no es comparable con
los números de compilación internos de SQL Server, pero hace referencia al mismo nivel de compatibilidad.

Puede comprobar el nivel de compatibilidad de las bases de datos ejecutando la consulta como se muestra a
continuación:

SQLCopiar

SELECT name, compatibility_level FROM sys.databases;

Directiva de soporte técnico para SQL Server

Microsoft tiene una directiva de soporte técnico para SQL Server. Las versiones son compatibles durante cinco años
con el soporte principal y, después, durante otros cinco años con el soporte extendido. Durante los primeros cinco
años, Microsoft actualiza todas las versiones con funcionalidades mejoradas, cierra las brechas de características y
soluciona errores de rendimiento, funcionales y de seguridad. Una vez que una versión pasa al soporte extendido,
Microsoft solo solucionará los errores de seguridad.

La ejecución en la última versión de SQL Server aporta muchas ventajas, como las mejoras de las categorías
siguientes:

 Rendimiento

 Seguridad

 Disponibilidad

 Funcionalidad de consulta

Estas ventajas se mejoran aún más con la cadencia de lanzamiento de uno a dos años de SQL Server y la naturaleza
de los servicios de Azure SQL Database, lo que significa que nunca es necesario aplicar revisiones ni actualizaciones
cuando se agregan nuevas características y se aplican correcciones automáticamente.

Microsoft ha recomendado que los proveedores de aplicaciones las certifiquen en un nivel de compatibilidad
específico, en lugar de para una versión de software determinada. Este enfoque ayudará a los clientes a aprovechar
las últimas versiones de SQL Server, pero manteniendo la compatibilidad del proveedor con las aplicaciones.

Microsoft incluye la protección de formas del plan de consulta, lo que significa que los planes de ejecución de
consultas y su rendimiento deben ser prácticamente iguales (en hardware similar). Esta característica elimina uno de
los principales riesgos de actualizar SQL Server: cambios del optimizador que provocan una degradación en el
rendimiento de las consultas. Microsoft todavía recomienda actualizar a un nivel de compatibilidad más reciente
siempre que sea posible, pero admitirá bases de datos en niveles de compatibilidad más antiguos siempre que la
versión de SQL Server en la que se ejecuta sea una versión compatible de SQL Server.

Obtenga más información sobre los niveles de compatibilidad admitidos.

Información sobre las características en versión preliminar de Azure

Azure evoluciona constantemente, y se lanzan nuevas características continuamente. Las nuevas características
pueden tardar algún tiempo en estar disponibles con carácter general mediante el proceso de versión preliminar.
Aunque las características en versión preliminar pueden beneficiar a las aplicaciones, hay algunas ventajas y
desventajas en relación a la compatibilidad.

Azure ofrece características en versión preliminar diseñadas para usos que no son de producción. Es importante
tener en cuenta que las versiones preliminares están sujetas a términos de servicio reducidos o diferentes.
Dependiendo de la región en la que se hospedan los recursos, es posible que las características en versión preliminar
no estén disponibles y que tengan una funcionalidad y Acuerdos de Nivel de Servicio (SLA) limitados.

Microsoft no recomienda usar características en versión preliminar en un entorno de producción, a menos que
trabaje directamente con el equipo de productos para garantizar el soporte técnico.

Las características en versión preliminar se dividen en las siguientes categorías:

 Versión preliminar privada

 Versión preliminar pública

Las características en versión preliminar privada requerirán que Microsoft agregue su suscripción a una lista de
permitidos para una característica determinada.

Las características en versión preliminar pública se pueden seleccionar en el portal, pero están disponibles para todos
los usuarios. Algunas características pueden requerir una mayor participación en el recurso individual. La experiencia
de la versión preliminar pública no es coherente entre los servicios de Azure.

Puede comprobar las últimas características en versión preliminar pública; para ello, abra la página de la versión
preliminar de Azure Portal.
Después de la versión preliminar pública, el estado de la característica cambia a disponibilidad general. La
disponibilidad general (GA) es el estado de la versión final y significa que la funcionalidad está completa y es
accesible para todos los usuarios.

Descripción de las opciones de migración de bases de datos de Azure

Muchas organizaciones migran su plataforma de base de datos a Azure SQL para reducir los costos de las licencias.
Azure Database Migration Service (DMS) facilita la migración a la plataforma de Azure SQL. DMS admite orígenes
homogéneos (por ejemplo, MySQL en una máquina virtual a Azure SQL Database) y heterogéneos (por ejemplo,
Oracle en una máquina virtual a Azure Database for PostgreSQL).

Hay varias herramientas disponibles para ayudarlo en el proceso de migración. En esta sección, se analizan algunas
de las opciones y los métodos para llevar a cabo una migración.

Azure Database Migration Service

Azure Database Migration Service le ayuda a simplificar, guiar y automatizar la migración de bases de datos a Azure.
DMS migra los datos, el esquema y los objetos de varios orígenes a la nube a escala.

Para las migraciones en línea a Azure SQL, Azure Database Migration Service proporciona un servicio de migración de
alta resistencia y de recuperación automática con resultados confiables y un tiempo de inactividad casi nulo. A
continuación, se resaltan los pasos principales implicados:

1. Cargue completamente la base de datos local en Azure SQL.

2. Sincronice continuamente nuevas transacciones de base de datos con el destino de Azure.

3. Migre al servicio de Azure de destino cuando esté preparado. Puede detener la replicación y cambiar las
cadenas de conexión de la aplicación a Azure SQL.

Extensión Azure SQL Migration para Azure Data Studio

La extensión de migración de Azure SQL para Azure Data Studio es una herramienta que le ayuda a prepararse para
migrar las bases de datos de SQL Server a Azure. Usa la versión más reciente de Azure Data Migration Service para
evaluar la preparación para la migración, recomendar los mejores recursos de Azure en función de las necesidades y
ejecutar la migración. Es ideal para bases de datos pequeñas y medianas y admite la migración en línea a SQL
Managed Instance.

Azure Migrate

Azure Migrate proporciona una ubicación centralizada para evaluar y migrar servidores, infraestructuras, aplicaciones
y datos locales a Azure. Permite detectar y evaluar los servidores, tanto si son máquinas físicas, como si son
máquinas virtuales VMware o Hyper-V.

Azure Migrate también lo ayuda a asegurarse de que selecciona el tamaño de máquina virtual adecuado para que las
cargas de trabajo tengan suficientes recursos disponibles. Además, la herramienta proporciona una estimación de los
costos para que pueda elaborar el presupuesto correspondiente.

Para usar la herramienta Azure Migrate, debe implementar un dispositivo ligero, que se puede implementar en una
máquina virtual o física. Una vez que se han detectado los servidores del entorno local, el dispositivo envía
continuamente metadatos sobre cada uno de ellos (junto con las métricas de rendimiento) a Azure Migrate, que
reside en la nube.
Como ya hemos mencionado, la experiencia de Azure Migrate se puede iniciar desde el portal para comenzar el
proceso de migración. El servicio consta de una plataforma de migración unificada que proporciona un único portal
para hacer un seguimiento de todo el proceso de migración a Azure.

Hay varias herramientas más que puede usar para asignar su patrimonio de servidores e identificar la compatibilidad
con la plataforma Azure de destino:

 MAP Toolkit: Microsoft Assessment and Planning Toolkit recopila y proporciona automáticamente un informe
que contiene el inventario de todos los servidores SQL Server de la red, la versión y la información del
servidor.

 Asistente para experimentación con bases de datos: esta herramienta se puede usar para evaluar las
actualizaciones de la versión de SQL Server mediante la comprobación de la compatibilidad de la sintaxis, y
proporciona una plataforma para evaluar el rendimiento de las consultas en la versión de destino.

Data Migration Assistant

MAP Toolkit y el Asistente para experimentación con bases de datos pueden ayudarlo a identificar las bases de datos
y a detectar las incompatibilidades o posibles problemas de rendimiento de las bases de datos, pero Data Migration
Assistant (DMA) es un kit de herramientas completo que evalúa, identifica las nuevas características que puede usar
en beneficio de sus aplicaciones y, finalmente, lleva a cabo la migración. Esta herramienta se puede usar para
migraciones entre versiones de SQL Server, del entorno local a una máquina virtual de Azure, Azure SQL Database o
Azure SQL Managed Instance.

Nota

Aunque Database Migration Assistant es una herramienta útil disponible, se recomienda usar Azure Database
Migration Service para migraciones de gran tamaño y una experiencia general mejorada, que está disponible
como Azure SQL Migration, una extensión para Azure Data Studio o a través de Azure Portal, o a través de Azure
PowerShell y la CLI de Azure.

Opciones de migración adicionales admitidas

Hay una serie de enfoques diferentes para migrar bases de datos a Azure SQL. Estas soluciones no se diseñaron
principalmente para realizar migraciones, pero se pueden usar con ese fin. La técnica que se use para migrar
físicamente los datos dependerá de la cantidad de tiempo de inactividad que se puede mantener durante el proceso
de migración.

 Servicio de reproducción de registros. Es una opción de migración en línea a Azure SQL Managed Instance y
se usa cuando se necesita más control sobre proyecto de migración de base de datos.
  Vínculo de Instancia administrada. El vínculo de Instancia administrada, que usa grupos de disponibilidad
distribuidos, amplía de forma segura el patrimonio de datos mediante la replicación de datos casi al instante
(en línea) entre cualquier instancia hospedada de SQL Server y Azure SQL Managed Instance, y viceversa.

 Copia de seguridad y restauración nativa. La copia de seguridad y la restauración son un método de

migración sencillo y ampliamente usado por muchos profesionales de SQL Server. Es la opción de migración
más sencilla para aquellos clientes que pueden proporcionar copias de seguridad de bases de datos
completas para Azure Storage.

 Replicación transaccional La replicación transaccional es una manera de mover datos entre servidores de
bases de datos conectados continuamente. Es lo más recomendable para la migración en línea o sin conexión
de bases de datos grandes y complejas.

Obtenga más información sobre las herramientas utilizadas para migrar bases de datos SQL a Azure.

Migración de las cargas de trabajo de SQL Server a Azure SQL Database

Azure SQL Database es un motor de base de datos de plataforma como servicio (PaaS) que proporciona un entorno
de desarrollo e implementación completo en la nube, que se puede usar para aplicaciones sencillas basadas
en la nube y aplicaciones empresariales avanzadas.

La migración a SQL Database le permite modernizar la aplicación aprovechando sus funcionalidades de PaaS. Esto le
permite eliminar dependencias en los componentes técnicos cuyo ámbito se encuentre en el nivel de
instancia, como los trabajos del Agente SQL. Azure SQL Database ofrece una solución de bajo mantenimiento
que puede ser una excelente opción para determinadas cargas de trabajo.

Es posible que tenga requisitos específicos que sean más adecuados para Azure SQL Database en lugar de Azure SQL
Managed Instance en los escenarios siguientes:

 Debe simplificar la implementación de bases de datos con un uso intermitente e imprevisible.

 Nuevas bases de datos sin historial de uso donde el tamaño de proceso es difícil (o incluso imposible) de
estimar antes de la implementación.

 La complejidad de la implementación y el desarrollo es un problema.

 Los requisitos de almacenamiento son mayores que los que ofrece Azure SQL Managed Instance y la
consolidación de bases de datos no es una opción.

El proceso de migración de una base de datos de SQL Server que se ejecuta en una máquina virtual de Azure a
Azure SQL Database es similar a los pasos que veremos en este módulo.

Nota

Antes de continuar, es importante asegurarse de que ha revisado Evaluación de bases de datos de SQL Server para la
migración a Azure SQL. Este módulo le presentará las herramientas de evaluación y le ayudará a detectar
nuevas características en la plataforma de SQL Server de destino de la que la base de datos puede
beneficiarse después de una actualización.

Escenarios de casos de uso

Durante este módulo vamos a usar un escenario de ejemplo para explicar los principales conceptos sobre la
migración de datos.

Supongamos que trabaja para una empresa que fabrica bicicletas y piezas de bicicleta. Tiene varios servidores de
bases de datos heredados que quiere actualizar, incluida una base de datos de productos, una base de datos
de existencia de piezas y una base de datos de recursos humanos. También desea pasar de un modelo de
gastos de capital a un modelo de gastos operativos, y beneficiarse de la escalabilidad y la disponibilidad de
los servicios de Azure. Planea migrar sus base de datos de SQL Server a Azure SQL Database. La junta
 directiva le ha pedido que planee el proyecto de migración y le ha hecho responsable de la ejecución de las
tareas de migración.

Obtendrá información sobre cómo migrar bases de datos de SQL Server a Azure SQL Database. Para comenzar,
explorará las consideraciones previas a la migración que debe tener en cuenta y cómo crear una instancia de
base de datos de Azure SQL. A continuación, explorará los distintos métodos para las migraciones sin
conexión y en línea, y verá formas de mover los datos a Azure SQL Database.

Evaluación de bases de datos de SQL Server para la migración a Azure SQL

La migración de bases de datos de SQL Server a Azure SQL puede proporcionar muchas ventajas, incluida la
escalabilidad, el rendimiento y el ahorro de costos mejorados. Sin embargo, antes de migrar, es importante
identificar cualquier problema de compatibilidad o posibles bloqueadores que puedan evitar una migración
correcta.

Escenario de casos de uso

En este módulo, se usa un escenario de ejemplo para explicar los conceptos clave de migración de datos.

Ha sido contratado como administrador sénior de bases de datos en una empresa minorista global y trabaja con
consultores y arquitectos para iniciar un proyecto de modernización de plataforma de datos que cumpla los
requisitos técnicos y empresariales de la organización.

La organización tiene un gran número de bases de datos diferentes que respaldan funciones críticas para la empresa,
como Customer Relationship Management (CRM), administración de existencias, distribución y recursos
humanos. A medida que la empresa ha crecido mediante la adquisición, se han incorporado nuevas
instancias y bases de datos basadas en SQL Server a la responsabilidad de un departamento de TI unificado.
La empresa ahora ejecuta muchas bases de datos locales en distintas versiones en varios servidores. Le
gustaría estandarizar y modernizar su patrimonio de datos, pero no sabe cuánto esfuerzo administrativo y de
desarrollo requiere.

Su responsabilidad principal es identificar lo que se necesita y, en última instancia, migrar varias bases de datos de
SQL Server de servidores locales a Azure con la menor interrupción posible.

En este módulo, obtendrá información sobre los problemas de compatibilidad y los bloqueadores comunes, así como
las diversas herramientas y opciones disponibles para evaluar y migrar bases de datos de SQL Server a Azure
SQL.

Revisión de la base de datos para obtener compatibilidad

Al migrar bases de datos a cualquiera de las ofertas de Azure SQL, es importante evaluar las bases de datos para
detectar posibles bloqueadores de migración y cambios importantes que pueden requerir correcciones
posteriores a la migración.

Varias herramientas de migración proporcionan la característica de evaluación de la base de datos, que implica
validar el código y el esquema de la base de datos de origen para garantizar el cumplimiento de los requisitos
de la plataforma de destino. Esta validación ayuda a detectar incoherencias, errores o características en
desuso que deben solucionarse antes de la migración, garantizando una transición fluida y sin errores.

Identificación de problemas de compatibilidad

Las herramientas de migración pueden identificar cambios importantes, cambios de comportamiento y

características en desuso. Puede usar estas herramientas para comprobar un destino de migración sin
necesidad de tenerlo instalado en ningún lugar. Esto le permite evaluar rápidamente una base de datos para
ver el impacto de la migración sin ningún costo inicial de instalación o licencia.

Un ejemplo de incompatibilidad que puede impedir la migración a Azure SQL Database es el uso de consultas entre
bases de datos. Las consultas entre bases de datos no se admiten en Azure SQL Database. Las herramientas
 de migración como la extensión de migración de Azure SQL para Azure Data Studio pueden ayudarle a
identificar este y otros problemas de compatibilidad y bloqueadores que pueden impedir una migración.

Puede ejecutar la evaluación en una o varias bases de datos y en una o varias instancias. El tamaño de cada base de
datos seleccionada afecta al tiempo necesario para ejecutar la evaluación.

Se recomienda ejecutar evaluaciones en una versión de desarrollo o prueba de la base de datos. Una vez
completadas las evaluaciones, puede decidir ejecutar las mismas comprobaciones en la base de datos de
producción. Cuando sea el momento de ejecutar la evaluación en producción, asegúrese de que se realiza en
el momento de la actividad más baja para no afectar a los usuarios.

Reglas de evaluación

Las distintas herramientas de migración realizan evaluaciones completas en la instancia de SQL Server de origen y
ejecutan varias reglas para identificar los problemas críticos que deben resolverse antes de migrar la base de
datos de SQL Server a Azure SQL.

Comprender las reglas de evaluación usadas en el proceso de migración es importante porque permite identificar y
solucionar posibles problemas o desafíos antes de migrar la base de datos de SQL Server a Azure SQL
Database. Al familiarizarse con estas reglas, obtendrá información valiosa sobre los requisitos específicos
para una migración correcta.

Por ejemplo, una de las reglas en las directrices de evaluación para migrar su base de datos de SQL Server a Azure
SQL Database es la regla LinkedServer. Esta regla comprueba la presencia de servidores vinculados, que no se
admiten en Azure SQL Database. Al revisar esta regla, puede identificar las dependencias del servidor
vinculado y planear enfoques o modificaciones alternativos en la aplicación para garantizar una transición
correcta a Azure SQL Database.

Para obtener más información sobre las reglas que se usan para evaluar la viabilidad de migrar su base de datos de
SQL Server a Azure SQL Database o a Instancia administrada de Azure SQL, consulte los siguientes vínculos:
reglas de evaluación para la migración de SQL Server a Azure SQL Database y reglas de evaluación para la
migración de SQL Server a Instancia administrada de Azure SQL .

Otros escenarios admitidos

Hay otros escenarios en los que el uso de una herramienta de evaluación puede merecer la pena. Por ejemplo:

 Actualizar a una nueva versión: Si va a actualizar las bases de datos a una versión más reciente de SQL
Server, puede usar una herramienta de migración para evaluar la compatibilidad e identificar las
características en desuso o cambios importantes que podrían afectar a las cargas de trabajo.

 Consolidación de bases de datos: Si va a consolidar varias bases de datos en una sola base de datos o
instancia, es posible usar una herramienta de migración para evaluar la compatibilidad e identificar cualquier
problema que pueda impedir una consolidación correcta. Por ejemplo, supongamos que va a administrar
varias bases de datos de SQL Server que se distribuyen entre varias instancias o servidores. Para simplificar la
administración y reducir los costos, es posible que desee consolidar estas bases de datos en una sola
instancia o servidor.

 Detección de nuevas características: Por ejemplo, antes de migrar o actualizar con la ayuda de Azure Data
Migration Service (DMS), la base de datos puede aprovechar las nuevas características disponibles en la
plataforma de SQL Server de destino.

Exploración de las opciones de evaluación para la migración de bases de datos

Cuando se trata de migrar una base de datos a una nueva plataforma o versión, es importante evaluar la base de
datos de antemano para identificar los posibles problemas que podrían afectar al proceso de migración.
Herramientas como extensión de migración de Azure para Azure Data Studio, Azure Migratey Data Migration
Assistant (DMA) pueden ayudarle en este proceso.

Nota

Aunque Database Migration Assistant es una herramienta útil disponible, se recomienda usar la azure Database
Migration Service para migraciones de gran tamaño y una experiencia general mejorada.

Extensión de migración de Azure para Azure Data Studio

La extensión Azure SQL Migration para Azure Data Studio ayuda a evaluar la preparación de la migración,
proporcionar recomendaciones de SKU adecuadas para los recursos de Azure y facilitar la migración de la
base de datos de SQL Server a Azure y es ideal para bases de datos pequeñas y medianas. Cuenta con la
tecnología de la versión más reciente de Azure Database Migration Servicey también proporciona una
característica de evaluación avanzada que evalúa las bases de datos de SQL Server que están listas para la
migración a Azure SQL.

Además, la extensión de migración es una herramienta ligera que proporciona compatibilidad con los modos de
migración en línea y sin conexión, lo que le permite migrar de SQL Server a Azure SQL Managed Instance,
Azure SQL Database o SQL Server en azure Virtual Machine. Sin embargo, tenga en cuenta que para la
migración de SQL Server a Azure SQL Database, solo el modo de migración sin conexión está disponible
actualmente.

Nota

Para obtener una lista de las características admitidas por la extensión, consulte extensión de migración de Azure
SQL para Azure Data Studio

Azure Migrate

Azure Migrate es un servicio de migración completo que admite una amplia gama de escenarios de migración,
incluida la migración de SQL Server. Azure Migrate proporciona un conjunto de herramientas diseñadas para
la evaluación y migración de servidores locales, infraestructura, aplicaciones y datos a escala, con el fin de
migrarlos a Azure.

Estas herramientas incluyen Azure Migrate: detección y evaluación, que evalúa el entorno existente y Migración y
modernización, lo que facilita el proceso real de migración y modernización. Además, Azure Migrate se
integra perfectamente con varios servicios, herramientas y ofertas de proveedor de software independiente
(ISV) de Azure, lo que garantiza una experiencia de migración flexible y eficaz adaptada a sus requisitos
específicos.

Azure Migrate es adecuado para migraciones y escenarios a mayor escala.

Nota

Para ver una lista de las herramientas integradas compatibles con Azure Migrate, consulte herramientas integradas

Asistente de Migración de Datos (DMA)

Database Migration Assistant (DMA) es una aplicación independiente que ayuda a migrar o actualizar bases de datos
de SQL Server. Automatiza el proceso de comprobación de problemas de compatibilidad y ofrece
recomendaciones. DMA se conecta a los servidores de origen y de destino, identifica los cambios
importantes, las características en desuso y evalúa las nuevas características para mejorar el rendimiento.
Admite migraciones de host de SQL Server locales y migraciones a Azure SQL.
Aunque DMA admite Azure SQL Managed Instance y SQL Server en Azure Virtual Machines como opciones de
destino, es más adecuado para las organizaciones que migran sus bases de datos a Azure SQL Database o SQL
Server.

Para obtener más información sobre Data Migration Assistant, consulte Procedimientos recomendados para ejecutar
Data Migration Assistant

Independientemente de la herramienta elegida, es importante evaluar los requisitos y objetivos específicos del
proyecto de migración. La selección de la herramienta adecuada en función de su escenario ayuda a
garantizar una migración correcta y eficaz de SQL Server a Azure.

Evaluación de una base de datos con la extensión azure Migration

Al usar la extensión de migración de Azure para Azure Data Studio, los usuarios pueden elegir entre la migración en
línea o sin conexión en función del destino de Azure seleccionado. También pueden configurar un entorno de
ejecución de integración autohospedado para acceder a los archivos de copia de seguridad desde la instancia
de SQL Server de origen en su entorno local.

La extensión también proporciona una experiencia de usuario segura y mejorada para migrar bases de datos de
cifrado de datos transparente (TDE) y inicios de sesión de SQL Server y Windows a Azure SQL.

Instalación de la extensión de migración de Azure para Azure Data Studio

Como requisito previo, primero debe instalar Azure Data Studio. La extensión está disponible en Marketplace de
Azure Data Studio.
Para instalar la extensión de migración, siga estos pasos:

1. Abra el administrador de extensiones en Azure Data Studio.

2. Busque azure SQL Migration y seleccione la extensión.

3. Instale la extensión. Una vez que lo instale, encontrará la extensión azure SQL Migration en la lista de
extensiones instaladas.

4. Conéctese a una instancia de SQL Server en Azure Data Studio.

5. Haga clic con el botón derecho en el nombre de la instancia y seleccione Administrar para acceder al panel y
a la página de aterrizaje de la extensión Azure SQL Migration.

Evaluación de la preparación de la base de datos

La extensión de migración realiza una evaluación detallada de la instancia de SQL Server de origen ejecutando varias
reglas para identificar los problemas críticos que se deben solucionar antes de migrar la base de datos de SQL
Server a Azure SQL.

Una cuenta de Azure no es necesaria para las evaluaciones ni las recomendaciones de SKU. No requerir una cuenta
de Azure para evaluaciones o recomendaciones de SKU tiene la ventaja de permitir a los usuarios evaluar la
preparación y el costo de migrar sus bases de datos a Azure sin necesidad de confirmar la creación de una
cuenta de Azure. Esto ahorra tiempo y esfuerzo para los usuarios que aún están en el proceso de toma de
decisiones.

Como podemos ver, hay varios destinos de Azure SQL disponibles para la selección y los resultados se actualizan
automáticamente en función de su elección. Esta característica le ayuda a identificar los posibles obstáculos y
determinar si otra opción de destino puede ser más adecuada para su entorno.
También puede guardar el informe de evaluación; esto genera un archivo JSON que contiene todas las propiedades
principales de la base de datos y también los resultados de la evaluación. Además, puede usar el archivo
JSON para extraer datos o información específicos mediante programación para su posterior análisis o
procesamiento.

Recomendaciones de SKU de tamaño correcto (versión preliminar)

La extensión también proporciona la configuración de proceso y almacenamiento recomendada para el destino de

Azure SQL en función de los datos de rendimiento recopilados de la instancia de SQL de origen, ya sea local o
en otro entorno en la nube. Esta función ayuda a garantizar que el destino de Azure SQL cumpla con las
necesidades de tu carga de trabajo.

Aunque la característica de recomendaciones de Azure no proporciona estimaciones de precios debido a la

naturaleza fluctuante de los precios, hay métodos alternativos para obtener estimaciones de precios. Puede
acceder a calculadora de precios de Azureo generar una evaluación de SQL en azure Migrate para recopilar
estimaciones de precios precisas. Estas opciones le permiten tomar decisiones fundamentadas teniendo en
cuenta los detalles de precios específicos relevantes para su escenario.
Como podemos ver, una vez iniciado el Asistente para la extensión de migración de Azure, tiene la opción de
seleccionar Obtener recomendación de Azure para habilitar la recopilación de datos de rendimiento.

Importante

Recopilamos datos de rendimiento de todas las bases de datos de una instancia específica simultáneamente y los
mismos datos se pueden usar varias veces para migrar bases de datos de origen diferentes.

Automatización de la evaluación

Además de ejecutar los pasos de evaluación y recomendaciones de Azure a través del asistente de extensión de
migración, puede ejecutarlos en PowerShell o Azure CLI para realizar estas tareas a escala.

Por ejemplo, en PowerShell, para ejecutar la evaluación en una base de datos de SQL Server de ejemplo y guardar el
informe de evaluación en la carpeta de salida de la unidad C.

Copiar

Get-AzDataMigrationAssessment -ConnectionString "Data Source=localhost;Initial

Catalog=AdventureWorks;Integrated Security=True" -OutputFolder C:\Output -Overwrite

Como alternativa, puede realizar la misma tarea mediante la CLI de Azure.

Copiar

az datamigration get-assessment --connection-string "Data Source=localhost;Initial

Catalog=AdventureWorks;Integrated Security=True" --output-folder "C:\Output" --overwrite

Para obtener más información sobre los comandos de PowerShell y de la CLI de Azure disponibles para la extensión
de migración de datos, consulte los siguientes vínculos: módulo de PowerShell para la extensión de migración
de datos y CLI de Azure para la extensión de migración de datos.

Evaluación de una base de datos con Azure Migrate

Azure Migrate ofrece herramientas para evaluar las cargas de trabajo locales actuales, lo que proporciona
información sobre el planeamiento de la migración. Además, puede realizar una detección de entornos sin
agente o usar agentes para realizar un análisis de dependencias. Esto ayuda a identificar las dependencias
entre distintos componentes del entorno.

¿Qué es Azure Migrate?

Azure Migrate simplifica el proceso de migración, modernización y optimización del entorno de Azure al ofrecer una
amplia gama de servicios completos. Abarca todos los pasos previos a la migración, como la detección, las
evaluaciones y el ajuste de tamaño correcto de los recursos locales para la infraestructura, los datos y las
aplicaciones. Además, Azure Migrate permite la integración con herramientas de terceros, ampliando sus
funcionalidades para admitir una amplia gama de casos de uso.

Azure Migrate admite la detección y evaluación de diferentes implementaciones de SQL Server, como instancias de
clúster de conmutación por error (FCI) de SQL Server y grupos de disponibilidad AlwaysOn (AG).

Hay varias herramientas disponibles en Azure Migrate, como Azure Migrate: detección y evaluación y migración y
modernización, que se pueden integrar con otros servicios de Azure, ofertas de proveedor de software
independiente (ISV) y admitir la evaluación, migración y modernización de servidores, bases de datos,
aplicaciones web y escritorios virtuales.

Por ejemplo, si va a evaluar todo el patrimonio de datos de SQL Server a escala en VMware, puede usar Azure
Migrate para obtener recomendaciones de implementación de Azure SQL, ajuste de tamaño de destino y
estimaciones mensuales.
Durante la fase de detección, Azure Migrate también se puede usar para examinar la red e identificar todas las
instancias y características de SQL Server que se usan en la organización.

Herramientas de evaluación

El centro de Azure Migrate para la evaluación incluye estas herramientas:

Azure Migrate: detección y evaluación

Hay tres tipos de evaluación que puede crear mediante la herramienta Azure Migrate: detección y evaluación.

 Descubrimiento y evaluación de SQL Server

Admite implementaciones de SQL Server que se ejecutan en VMware, Microsoft Hyper-V y entornos físicos, además
de servicios IaaS de otras nubes públicas. Proporciona una detección sin agente, una estimación de costos y
una configuración óptima de Azure SQL. Sí requiere un dispositivo de Azure Migrate que despliegue de forma
local. Esta herramienta es adecuada para cargas de trabajo en las que necesita evaluar la preparación de las
máquinas virtuales y los servidores físicos, no se limita solo a los servidores SQL Server.
Durante la fase de detección, también se pueden usar de detección y evaluación de SQL Server para examinar la red
e identificar todas las instancias y características de SQL Server que se usan en la organización. Esto puede
proporcionar información valiosa sobre el entorno de SQL Server existente, lo que le permite evaluar la
preparación y el ámbito del proyecto de migración.

 Caso de negocio

Este tipo de evaluación le ayuda a desarrollar un caso empresarial completo para evaluar la rentabilidad de la
inversión para migrar servidores, implementaciones de SQL Server y ASP.NET aplicaciones web a Azure.
También puede eliminar la incertidumbre y obtener información sobre el costo total de propiedad (TCO), el
uso de recursos y los beneficios rápidos para la migración y la modernización.

 Optimizar costos

Este tipo de evaluación usa la detección sin agente, las comprobaciones de preparación de Azure y el análisis de
dependencias para un mapeo en las instalaciones eficaz y la identificación de los recursos listos para la
migración. Usa información para calcular el costo de migrar los recursos a Azure.

Data Migration Assistant (DMA)

Veremos más sobre DMA en la unidad siguiente. Sin embargo, es importante tener en cuenta que DMA se usa al
ejecutar una Database (solo) evaluación en Azure Migrate. En el caso de las migraciones a Azure SQL, DMA
también comprueba la paridad de características para descubrir características parcialmente o no admitidas
en Azure. Para aprovechar al máximo las características que ofrece Azure Migrate, debe instalar y crear un
proyecto de evaluación mediante DMA y cargar el informe de evaluación en Azure Migrate.
Nota

Aunque Database Migration Assistant es una herramienta útil disponible, se recomienda usar la azure Database
Migration Service para migraciones de gran tamaño y una experiencia general mejorada.

Ejercicio: Evaluación de una base de datos y sincronización de resultados en Azure Migrate

Para ejecutar este ejercicio, asegúrese de seguir estos pasos antes de continuar:

Nota

Para completar este ejercicio, necesita acceso a una suscripción de Azure para crear recursos de Azure. Si no tiene
una suscripción de Azure, cree una cuenta gratuita antes de comenzar.

Si decide realizar este ejercicio en este módulo, tenga en cuenta que podría incurrir en costos en su suscripción de
Azure.

Prerrequisitos

 SQL Server 2022 con la base de datos AdventureWorks más reciente.

 Una vez restaurada la base de datos, ejecute el siguiente comando:

SQLCopiar

USE [AdventureWorks]

GO

ALTER TABLE [Person].[Person] ADD [Next] VARCHAR(5);

CREATE PROCEDURE [HumanResources].[usp_legacyIntegration]

AS

SELECT DataCreated, UserID, ActionID

FROM LogDB..Logs

 Un usuario de SQL Server con acceso de lectura a la base de datos de origen.

Tarea 1: Creación de un proyecto de Azure Migrate

1. En el portal de Azure, busque Azure Migrate.

2. En Services, seleccione Azure Migrate.

3. En la sección de objetivos de migración , seleccione Servidores, bases de datos, y aplicaciones web, y a

continuación, seleccione + Crear proyecto.

4. En la página Crear proyecto, seleccione la suscripción de Azure y el grupo de recursos.

5. En Detalles del Proyecto, especifique el Proyecto y la Geografía en la que desea crear el proyecto.

6. Seleccione Crear.

Tarea 2: Evaluación de una base de datos mediante DMA

1. Descargue e instale la versión más reciente de DMA desde Centro de descarga de Microsofty, a continuación,
ejecute el archivo DataMigrationAssistant.msi.

2. Inicie microsoft Data Migration Assistant, seleccione + Nuevo y proporcione la siguiente información:

 Tipo de proyecto - Evaluación

 Nombre del proyecto:<proporcione un nombre de su preferencia>

 Tipo de evaluación - Motor de base de datos

 Tipo de servidor de origen - SQL Server

 tipo de servidor de destino: Azure SQL Database. Este es el servidor de destino que evaluará por
compatibilidad.

3. Seleccione Crear

4. En la página de evaluación, seleccione Comprobar paridad de características. Seleccione Siguiente.

5. En la Conectarse a un servidor de la barra lateral, proporcione los detalles de conexión del servidor de
origen. Seleccione Conectar.

6. En la barra lateral Añadir fuentes, seleccione la base de datos para evaluación. Seleccione Agregar.

7. Seleccione Iniciar evaluacióny, una vez finalizada la evaluación, puede ver los resultados en la pestaña
Revisar resultados .
Tarea 3: Carga del informe de evaluación en Azure Migrate

1. En la página de resultados de la evaluación de DMA, seleccione Cargar en Azure Migrate.

2. En la barra lateral Conectar a Azure, seleccione Connect. Siga los pasos para iniciar sesión en su cuenta de
Azure.

3. En la barra lateral Cargar en Azure Migrate, seleccione su suscripción seguida del proyecto de Azure
Migrate creado en la primera tarea de este ejercicio.

4. Seleccione Cargar.

Tarea 4: Revisión de los resultados en Azure Migrate

1. En la sección (solo) de bases de datos de Azure Migrate, seleccione Actualizar. Esto garantiza que el panel se
actualice según corresponda.

Nota

Ahora se presentan los resultados de la evaluación cargados desde DMA en la tarea anterior.

2. Seleccione bases de datos evaluadas y revise los resultados.

Tenga en cuenta que el informe ya está disponible en Azure Migrate y los distintos equipos pueden hacer referencia a
él. Dedique un momento a revisar los resultados de la evaluación y las columnas del informe de evaluación.

Evaluación de una base de datos con Data Migration Assistant

Data Migration Assistant (DMA) es una aplicación independiente que ejecuta un conjunto de tareas para ayudar a
migrar o actualizar las bases de datos de SQL Server. DMA le ayuda a detectar cambios importantes, cambios
de comportamiento y características en desuso. Si va a migrar a un host de SQL Server local, también puede
ejecutar una evaluación de paridad de características para buscar características en la versión de destino que
pueden mejorar el rendimiento de la base de datos. Para las migraciones a Azure SQL, DMA comprueba la
paridad de características para descubrir características parcialmente o no admitidas en Azure.

La duración de la evaluación de DMA depende del tamaño de la base de datos de origen. Para reducir el tiempo de
evaluación de las bases de datos grandes, puede ejecutar las evaluaciones de la compatibilidad y las nuevas
recomendaciones de características por separado.

Nota

Aunque Database Migration Assistant es una herramienta útil disponible, se recomienda usar la azure Database
Migration Service para migraciones de gran tamaño y una experiencia general mejorada.

Instalación de Microsoft Data Migration Assistant

Data Migration Assistant se puede descargar e instalar en la máquina desde la que administra actualmente las bases
de datos. DMA está aislado de cualquier otro software y no tiene dependencias distintas de las credenciales
de la instancia de SQL Server que desea actualizar. Se recomienda no instalar DMA en el mismo servidor que
SQL Server.

Para instalar DMA, descargue la versión más reciente de la herramienta desde Centro de descarga de Microsofty, a
continuación, ejecute el archivo DataMigrationAssistant.msi.

Después de instalar DMA, necesitará acceso a las instancias de SQL Server y a la infraestructura de red.

 Al ejecutar una evaluación, DMA requiere acceso en la base de datos de origen.

 Al ejecutar una actualización o migración, DMA requiere acceso en las bases de datos de origen y de destino.
La cuenta debe tener el permiso CONTROL SERVER en el origen y permisos de administrador en el destino.

Se recomienda ejecutar el DMA en las bases de datos de los entornos de desarrollo o de prueba antes de las bases de
datos de producción.

Detección de problemas de compatibilidad y paridad de características

En nuestro escenario de bufete de abogados, ha identificado las instancias de SQL Server dentro de su organización
que requieren la actualización. Desea comprobar que las bases de datos seguirán funcionando después de la
migración. El director de tecnología está creando un informe que detalla la rentabilidad de la inversión (ROI)
obtenida mediante la migración de las bases de datos a la versión más reciente de SQL Server. Quieren que
proporcione detalles de las características admitidas que proporcionan ventajas a los usuarios. Esta
información ayuda a demostrar las ventajas de la inversión para los usuarios.
Microsoft Data Migration Assistant (DMA) comprueba cada base de datos por problemas de compatibilidad y, dado
que algunas bases de datos se mueven a Azure SQL Database, identifica las características que no se
admitirán después de la migración. DMA también recomienda usar nuevas características en la base de datos
de destino.

Compatibilidad de bases de datos

Detectar problemas que pueden afectar a una actualización a una instancia local de SQL Server. Estos se describen
como problemas de compatibilidad y se organizan en las siguientes categorías:

 Cambios importantes

 Cambios de comportamiento

 Características en desuso

Importante

La migración de la base de datos a una versión más reciente de SQL Server no garantiza un rendimiento mejorado. Es
posible que sin realizar cambios en la base de datos durante o después de la migración, es posible que las
consultas no se ejecuten de forma óptima en el destino debido a cambios en el motor de consultas.

Paridad de características

Data Migration Assistant crea una lista de características no admitidas y parcialmente admitidas si realiza una
evaluación de paridad de características en una Azure SQL Database de destino, Azure SQL Managed Instance
o SQL Server para Linux.

DMA identifica características no admitidas comparando los componentes instalados en la instancia de origen con el
entorno de destino. Por ejemplo, actualmente, Master Data Services (MDS), SQL Server Analysis Services
(SSAS) y SQL Server Reporting Services (SSRS) no se admiten en Azure SQL Database ni SQL Server para Linux.
Cualquier interacción con estos servicios requeriría la eliminación o el desarrollo para garantizar la
compatibilidad con el entorno de destino.

Las características admitidas parcialmente en Azure SQL Database o SQL Server para Linux no tienen la misma
profundidad de funcionalidad que las versiones locales de Windows. DMA detecta automáticamente
discrepancias en las funciones para que pueda planificar en torno a cualquier posible obstáculo.

Ejercicio: Ejecución de una evaluación de paridad de características

1. En DMA, seleccione + Nuevo y proporcione la siguiente información:

 Tipo de proyecto - Evaluación

 Nombre del proyecto:<proporcione un nombre de su preferencia>

 Tipo de evaluación - Motor de base de datos

 tipo de servidor de origen : SQL Server

 tipo de servidor de destino: Azure SQL Database. Este es el servidor de destino que está evaluando
para verificar su compatibilidad.

2. Seleccione Crear

3. En la página de evaluación, seleccione Comprobar paridad de características. Seleccione Siguiente.

Nota

Según la versión de destino de SQL, Comprobar la paridad de características evaluación no estará disponible.

4. En la barra lateral Conectarse a un servidor, proporcione los detalles de conexión de su servidor de origen.
Seleccione Conectar.
 5. En la barra lateral Agregar fuentes, seleccione la base de datos para evaluación. Seleccione Agregar.

Nota

Opcionalmente, puede introducir una ruta de acceso a una carpeta que contenga archivos con eventos extendidos
para evaluar los rastros.

6. Seleccione Iniciar evaluacióny, una vez finalizada la evaluación, puede ver los resultados en la pestaña
Revisar resultados .

Resultados de la evaluación de compatibilidad

Si elige la opción Comprobar problemas de compatibilidad en la página de evaluación, los resultados se muestran en
un formato ligeramente diferente.

 Hay una pestaña para cada versión probada. Para cada pestaña de compatibilidad, puede haber una nota
de cambios de comportamiento, enumerando algunos problemas para revisión.

 Dependiendo del problema, también puede haber una sección de objetos afectados, con notas sobre
las soluciones recomendadas.

Opcionalmente, tiene la capacidad de guardar cada proyecto de evaluación y volver a abrirlo más adelante para ver
los resultados. Esto le permite volver a revisar y volver a evaluar la evaluación si se han realizado cambios
desde la última comprobación. También puede eliminar las evaluaciones que ya no sean necesarias.

Elección de la característica de Azure SQL Database adecuada

En nuestro escenario de fabricación de bicicletas, ya ha identificado y caracterizado las bases de datos que desea
migrar a Azure SQL Database. Ahora, quiere planificar la migración, teniendo en cuenta la capacidad de
recuperación de datos, la recuperación ante desastres, la seguridad y otros detalles de implementación.

Le gustaría conocer las herramientas y características disponibles para admitir con el proceso de migración a
Azure SQL Database.

Ventajas de Azure SQL Database

A continuación se resumen las ventajas de implementar bases de datos únicas y de grupos elásticos:

Expandir tabla

Categoría Característica

Copia de seguridad y Copia de seguridad automática

recuperación

Restauración a un momento dado

Retención de copias de seguridad durante más de 7 días

La retención de copias de seguridad a largo plazo almacena copias de seguridad durante 10 año

Alta disponibilidad Garantía de disponibilidad del 99,99 %

Disponibilidad integrada con tres réplicas secundarias

Redundancia de zona a través de zonas de disponibilidad de Azure

Recuperación ante desastres Restauración geográfica de copias de seguridad de bases de datos

Replicación geográfica activa entre regiones de Azure

Escalabilidad del servicio Escalado y reducción verticales dinámicos

Escalado horizontal con varias particiones

Uso compartido de recursos de proceso entre bases de datos mediante grupos elásticos

Seguridad Compatibilidad con la autenticación de Microsoft Entra

Características de seguridad solo de nube, como Protección contra amenazas avanzada

Cifrado de datos transparente (TDE) habilitado de manera predeterminada

Compatibilidad con el enmascaramiento de datos dinámico y estático, seguridad a nivel de filas

Encrypted

Lista de permitidos del firewall

Licencias Modelo de compra de DTU para costos predictivos

Modelo de compra de núcleos virtuales, que permite escalar el almacenamiento de forma inde
proceso

Combinación del modelo de compra de núcleos virtuales con la Ventaja híbrida de Azure para S
fin de obtener un ahorro de costos de hasta un 30 %

Sugerencia

Para revisar las ventajas de migrar a Azure SQL Database y las características disponibles, consulte el
módulo Implementación de soluciones PaaS con Azure SQL.
Características exclusivas de Azure SQL Database

Algunas características que no están disponibles en otras ofertas de Azure SQL se admiten en Azure SQL Database:

Expandir tabla

Característica Definición

Hiperescala Arquitectura nativa de la nube que permite un proceso y almacenamiento escalables de forma
que proporciona mayor flexibilidad y recursos que otros niveles.

Escalado automático Con nivel de proceso sin servidor

Ajuste automático (índices) Esta característica integrada identifica y crea automáticamente índices que pueden mejorar el
carga de trabajo. También comprueba que el rendimiento de las consultas ha mejorad
sin usar o duplicados.

Consulta elástica Le permite ejecutar consultas de T-SQL que unen varias bases de datos en SQL Database. Esta
útil para las aplicaciones que usan nombres de tres y cuatro partes que no se pueden c

Trabajos elásticos La característica de trabajo elástico es el reemplazo del Agente SQL Server para Azure SQL Dat
punto, el trabajo elástico es equivalente a la característica Administración multiservido
una instancia de SQL Server.

SQL Data Sync Le permite sincronizar de forma incremental los datos en varias bases de datos que se ejecuta
o SQL Server.

Información de rendimiento Esta herramienta le ayudará a encontrar consultas que optimizan el rendimiento general de la
de consultas (QPI) que usan de forma eficaz el recurso por el que paga.

Importante

Para comprender las diferencias en las características adicionales de SQL Database, SQL Server y Azure SQL
Managed Instance, así como las que existen entre distintas opciones de Azure SQL Database,
Consulte Características de SQL Database.

Opciones de migración admitidas

Hay dos modos de migración a Azure SQL Database: en línea y sin conexión. El modo en línea tiene un tiempo de
inactividad mínimo o sin tiempo de inactividad, mientras que el modo sin conexión experimenta tiempo de
inactividad durante el proceso de migración.

Expandir tabla

Herramienta Modo de migración

Azure Database Migration Service Offline

Replicación transaccional En línea

Azure Migrate Offline

SQL Data Sync * Sin conexión

Asistente de importación y exportación/BACPAC Offline

Copia masiva (utilidad bcp) Offline

Azure Data Factory Offline

Data Migration Assistant (DMA) Offline

* Puede tener un mayor impacto en el rendimiento en función de la carga de trabajo.

Nota

Aunque Database Migration Assistant es una herramienta útil que está disponible, se recomienda usar Azure
Database Migration Service para migraciones de gran tamaño y una experiencia general mejorada.

Rendimiento de la migración

Tenga en cuenta las siguientes recomendaciones al migrar a Azure SQL Database:

 Supervise la E/S y la latencia del archivo de datos en el origen y mitigue los cuellos de botella.

 Escale verticalmente la base de datos de Azure SQL de destino a un núcleo virtual Gen5 8 Crítico para la
empresa o use el nivel de servicio Hiperescala para minimizar la latencia de los archivos de registro.

 Asegúrese de que el ancho de banda de red pueda adaptarse a la velocidad máxima de ingesta de registros.

 Elija el nivel de servicio y el tamaño de proceso más altos para obtener el rendimiento máximo de la
transferencia y reduzca verticalmente después de la migración.

 Minimice la distancia entre los archivos BACPAC y el centro de datos de destino.

 Deshabilite la actualización automática y cree automáticamente las estadísticas durante la migración.

 Cree particiones de tablas e índices, quite vistas indexadas y vuelva a crearlas después de la migración.

 Considere la posibilidad de migrar datos históricos consultados raramente a una base de datos
independiente en Azure SQL Database y consúltela mediante consultas elásticas.

Reintento de conexiones de aplicación

Al migrar a Azure SQL Database, es importante prever errores transitorios ocasionales al conectarse al recurso de
base de datos e implementar un método lógico de reintento adecuado. También es importante establecer un
número máximo de reintentos antes de que finalice el programa.

Se recomienda esperar 5 segundos como mínimo en el primer reintento. Cada intento siguiente debe aumentar
exponencialmente el retraso, hasta un máximo de 60 segundos.

Nota

Si se produce un error transitorio en una instrucción SELECT para SQL Database, no vuelva a intentarlo directamente.
En su lugar, vuelva a intentar usar la instrucción SELECT en una nueva conexión.

Para obtener más información sobre las entidades de seguridad de reintento de conexión, consulte Solución de
errores de conexión transitorios en SQL Database y SQL Managed Instance.