Choosing Your Database Migration Path To Azure ES-MX

Microsoft Corporation
Primer borrador finalizado: marzo de 2018
Versión: 7.0
Autores: Amber Williams, Becky Isserman, Steve Burkett
Colaboradores: Eric Hudson, Murat Ozturan, Borko Novakovic, Andrey Antjufejevs, RAG Guru, Venkata Raj Pochiraju,
Ajay Jagannathan, Alain Dormehl
Revisores: Alain Dormehl, Eric Hudson, RAG Guru, Ajay Jagannathan
Para obtener la documentación más reciente sobre Azure SQL Database, consulte
https://azure.microsoft.com/es-xl/services/sql-database/
Declinación de responsabilidades
La información contenida en este documento representa la visión actual de Microsoft Corporation sobre los temas
analizados a la fecha de la publicación. Dado que Microsoft siempre responde a las cambiantes condiciones del
mercado, este documento no debe interpretarse como un compromiso por parte de Microsoft. Microsoft no puede
garantizar la exactitud de la información presentada después de la fecha de publicación.
MICROSOFT NO REALIZA GARANTÍAS EXPRESAS, IMPLÍCITAS O REGLAMENTARIAS CON RESPECTO A LA

INFORMACIÓN DE ESTE DOCUMENTO.
Página 2 de 62
ÍNDICE
1 Introducción ....................................................................................................................................................................... 4
1.1 Público objetivo .................................................................................................................................................................................. 4
1.2 Requisitos previos .............................................................................................................................................................................. 4
1.3 Fuera de alcance ................................................................................................................................................................................ 4
2 Información general ......................................................................................................................................................... 5
3 Iniciación y descubrimiento ............................................................................................................................................ 6
3.1 Herramientas y servicios de Microsoft: Guía de migración de base de datos ................................................................ 8
3.2 Herramientas y servicios de Microsoft: MAP Toolkit ............................................................................................................. 10
3.3 Herramientas y servicios de Microsoft: Asistente de migración de bases de datos .................................................... 14
4 Evaluación .......................................................................................................................................................................... 18
4.1 Evaluación de las cargas de trabajo para la migración ........................................................................................................ 19
4.2 Evaluación de los criterios de carga de trabajo ......................................................................................................................20
4.3 Evaluación de la base de datos con Database Migration Assistant (DMA) ....................................................................23
4.4 Pasos de evaluación mediante DMA .........................................................................................................................................24
4.5 Busque banderas rojas de alto nivel ..........................................................................................................................................29
5 Planificación...................................................................................................................................................................... 30
5.1 Planificar la plataforma de destino ............................................................................................................................................. 31
5.2 Cómo elegir la plataforma de destino adecuada ..................................................................................................................35
5.3 Elegir la plataforma de destino por escenarios de uso ........................................................................................................35
5.4 Elección de la plataforma de destino por características .....................................................................................................36
5.5 Elección de la plataforma de destino por costo .....................................................................................................................36
5.6 Migración de SSAS, SSIS y SSRS a una oferta de servicio completamente administrada de Azure .......................37
5.7 Migrar SSAS, SSIS y SSRS a VM de Azure ................................................................................................................................38
5.8 Planificar la herramienta de migración ......................................................................................................................................38
5.9 Ejemplos de selección de plataforma de destino ..................................................................................................................39
5.10 Resumen del ejemplo: selección de la plataforma de destino ...........................................................................................42
5.11 Ejemplo de Resumen: selección de herramientas de migración ...................................................................................... 44
6 Transformación y optimización ................................................................................................................................... 45
6.1 Transformación .................................................................................................................................................................................46
6.2 Optimización .....................................................................................................................................................................................47
7 Migración, validación y reparación ............................................................................................................................ 50
7.1 Información general sobre la migración ................................................................................................................................... 51
7.2 Selección de herramientas de migración .................................................................................................................................53
8 Conclusión ......................................................................................................................................................................... 60
9 Recursos.............................................................................................................................................................................. 61
Página 3 de 62
1 INTRODUCCIÓN
Azure SQL Database es un servicio totalmente administrado semejante a una implementación local de SQL Server
tradicional, pero mejora considerablemente el rendimiento y la solidez de SQL al hacer que los niveles de rendimiento
y la capacidad de almacenamiento se puedan actualizar fácilmente, y al proporcionar alta disponibilidad estándar.
Azure SQL Database ofrece un rendimiento predecible en varios niveles de servicio, que proporciona escalabilidad
dinámica sin tiempo de inactividad, con optimización inteligente integrada, con escalabilidad y disponibilidad globales,
y con opciones de seguridad avanzadas; todo ello con prácticamente cero administración. Estas capacidades le
permiten centrarse en desarrollar aplicaciones de una forma rápida y en acelerar su tiempo de comercialización,
en lugar de destinar tiempo y recursos valiosos a la administración de máquinas virtuales e infraestructura.
Azure SQL Database reside actualmente en 38 centros de datos de todo el mundo, y cada vez son más los centros
de datos que se habilitan en línea con regularidad, lo que le permite ejecutar su base de datos en un centro de
información cerca de usted.
Con tantas implementaciones locales en los sitios del cliente, ¿cómo hace para migrar desde la implementación
local de SQL Server tradicional a las tecnologías modernas de Azure SQL Database, y para sacar provecho de lo que
los servicios de base de datos en la nube ofrecen? Este informe técnico lo guiará por el proceso mental y los pasos
necesarios para migrar sus cargas de trabajo de base de datos desde los entornos locales a los servicios en la nube
basados en Azure, así como a los componentes de SQL Server, tales como SQL Server Reporting Services, SQL
Server Analysis Services y SQL Server Integration Services.
1.1 Público objetivo
Este informe técnico está dirigido a profesionales de datos, profesionales de TI y encargados de la toma de
decisiones de TI que buscan modernizar sus recursos de datos mediante la migración de cargas de trabajo
de SQL Server locales a los servicios en la nube de Microsoft Azure.
1.2 Requisitos previos
Damos por sentado que los lectores tienen cierta familiaridad con Microsoft SQL Server y los servicios en la
nube de Azure.
1.3 Fuera de alcance
Aunque las cargas de trabajo que no son de SQL Server sin duda se pueden migrar a los servicios en la nube
de Microsoft Azure, ese no es el objetivo principal de este informe técnico.
Introducción Página 4 de 62
2 INFORMACIÓN GENERAL
El plan para la migración de SQL consta de cinco fases, cada una de estas abarca varias tareas importantes que son
necesarias para completar una migración satisfactoria a los servicios en la nube de Azure.
La finalidad de las fases se resume a continuación, pero las analizaremos más detalladamente en las siguientes
secciones:
Iniciación y descubrimiento
Comprender la huella de su base de datos y los posibles enfoques para la migración.
Evaluación
Evaluar los requisitos detectados de la carga de trabajo y las dependencias.
Planificación
Planificar y describir las cargas de trabajo que se migrarán, la herramienta que se utilizará para la migración y la
plataforma de destino para la carga de trabajo.
Transformación y optimización
Transformar las cargas de trabajo que no sean compatibles actualmente con plataformas de datos modernas.
Optimizar las cargas de trabajo para aprovechar las nuevas características.
Migración, validación y reparación

Realizar la migración, verificar la correcta migración y reparar las aplicaciones cuando sea necesario.
Consejo: Recuerde que no es necesario que realice todo el trabajo usted mismo.
Microsoft puede proporcionar migraciones asistidas por medio de socios, como Movere y
Cloudamize, que tienen plataformas inteligentes de análisis de infraestructura en la nube disponibles
para automatizar la mayor parte de la evaluación, la planificación, la migración, la validación y la
administración en curso de las implementaciones de su base de datos en la nube.
Consulte https://www.cloudamize.com y https://www.movere.io para obtener más información.
Información general Página 5 de 62

3 INICIACIÓN Y DESCUBRIMIENTO
La primera fase del plan de migración es iniciación y descubrimiento. En esta primera fase, el objetivo es establecer
tres aspectos:
El inventario de sus recursos de datos

Esto constituye qué datos están disponibles, dónde se encuentran, en qué plataformas residen y su tamaño.
Dependencias de la base de datos de las aplicaciones

Las aplicaciones, a menudo, utilizan varias bases de datos o se integran con otras aplicaciones que tienen sus
propias bases de datos. Necesitamos conocer las dependencias de las bases de datos a otras bases de datos para
agruparlas de forma lógica según estas relaciones.
Cuáles son las bases de datos que se mueven juntas

Una vez que se han realizado las agrupaciones lógicas según las relaciones, podemos usarlas para formar lotes
de bases de datos para migrar a Azure.
Iniciación y descubrimiento Página 6 de 62

Para lograr estos objetivos, Microsoft tiene muchos recursos y herramientas disponibles. Estas incluyen las siguientes:
Guía de migración de base de datos

La nueva Guía de migración de base de datos es para clientes empresariales,
socios y encargados de la toma de decisiones empresariales que están
interesados en migrar a los servicios en la nube de Azure (es decir, la
migración de Oracle o SQL Server a Azure Data Services).
La Guía de migración de base de datos brinda una orientación detallada paso

a paso para realizar migraciones. Además, mejora la capacidad para detectar la
guía, las herramientas, el software y los programas que están disponibles para
ayudar a los clientes a realizar estas migraciones.
Más información en https://datamigration.microsoft.com
Microsoft Assessment & Planning (MAP) Toolkit

Microsoft Assessment & Planning (MAP) Toolkit facilita la evaluación de su
infraestructura de TI actual para varios proyectos de migración de tecnología.
Este acelerador de soluciones brinda una poderosa herramienta de inventario,
evaluación e informes para simplificar el proceso de planificación de la
migración. Si bien no esté estrictamente pensado para las migraciones de
bases de datos, el kit de herramientas MAP incluye información sobre bases de
datos y software de servidor que podemos utilizar para planificar la migración
en la nube.
Más información en
https://www.microsoft.com/en-us/download/details.aspx?id=7826
Data Migration Assistant (DMA)

Data Migration Assistant (DMA) le permite actualizar a los servicios de datos
de Azure; para ello, detecta los problemas de compatibilidad que pueden
afectar la funcionalidad de Azure SQL Database. Recomienda las mejoras de
rendimiento y confiabilidad para el entorno objetivo. Le permite no solo migrar
el esquema y los datos, sino también los objetos no contenidos del servidor
de origen al servicio de destino. DMA reemplaza la herramienta heredada
del Asesor de actualizaciones de SQL Server; y se debe utilizar para las
actualizaciones y migraciones de la mayoría de las versiones de SQL Server.
Más información en https://blogs.msdn.microsoft.com/datamigration/dma/

3.1 Herramientas y servicios de Microsoft: Guía de migración de base de datos
Se puede acceder a la Guía de migración de base de datos en el sitio web de Microsoft

https://datamigration.microsoft.com/. Esta guía proporciona un centro de información y recursos relacionados
con la migración centralizado.
Figura 1: página de introducción a la Guía de migración de base de datos
Puede crear un libro de tácticas de migración integral para muchos escenarios de migración de bases de datos.
También puede personalizar el libro de tácticas para que se adapte a su escenario en particular proporcionando
respuestas sobre dónde se almacenan actualmente sus datos y adónde desea migrarlos.
La Guía de migración de base de datos compila la información pertinente a su escenario y la presenta en pantalla
como un documento que contiene información relevante relacionada con la migración, materiales de discusión para
tomar las decisiones de diseño correctas y también enlaces a varios recursos, como informes técnicos de prácticas
óptimas, casos prácticos de clientes y videos de capacitación. Este documento también se puede imprimir o enviar
por correo electrónico a un destinatario para consultar más adelante.

Figura 2: libro de tácticas completo de la Guía de migración de base de datos
La Guía de migración de base de datos sirve no solo a Microsoft SQL Server como la plataforma de origen, sino
también a las migraciones de muchas otras plataformas comerciales y de código abierto, como Microsoft Access,
Oracle, MySQL, PostgreSQL y MongoDB.

3.2 Herramientas y servicios de Microsoft: MAP Toolkit
Microsoft Assessment & Planning (MAP) Toolkit se ha actualizado a lo largo de los años para varios tipos distintos
de migraciones de aplicaciones y SQL, con nuevas funcionalidades para admitir versiones posteriores de software
de aplicaciones y Windows. MAP Toolkit se puede descargar de forma gratuita desde el sitio de Microsoft. Los
pocos requisitos de recursos del kit de herramientas permiten que se instale y se ejecute en un servidor o en una
estación de trabajo.
La finalidad de MAP Toolkit es descubrir e inventariar computadoras y aplicaciones en la red para ayudar con las
actualizaciones y migraciones.
Figura 3: descripción general de MAP Toolkit
MAP Toolkit no hace esto exigiendo que se instale un agente en los equipos detectados, sino que descubre los
equipos que se inventarían desde Active Directory, System Center Configuration Manager (SCCM), analiza los
rangos de direcciones IP o utiliza una lista de nombres de equipo. Toda la información recopilada se almacena en
una base de datos de SQL Server Express instalada de forma local, sin que se envíe ninguna telemetría a Microsoft.
Una vez que se ha encontrado un equipo, su inventario de hardware y software se construye utilizando los orígenes
ingresados, como la información recopilada de Active Directory o las consultas mediante Windows Management
Instrumentation (WMI), servicio de registro remoto y PowerShell. Esto ocasiona un impacto mínimo en los equipos o
en la red que realizan las tareas; y por lo general se considera seguro hacerlo durante el horario comercial. Para el
análisis detallado de las aplicaciones del equipo detectado, se requieren derechos administrativos en el equipo de
destino mediante una cuenta de servicio en Active Directory.

La información recuperada de Active Directory y los equipos detectados se pueden consultar mediante MAP Toolkit
para generar informes y análisis. Microsoft proporciona informes listos para usar en MAP para muchos escenarios
distintos, como la preparación de la actualización para las nuevas versiones de los sistemas operativos y de las
aplicaciones de Microsoft. Sin embargo, los informes generados en torno a las bases de datos son más útiles para
los escenarios de migración de base de datos. Para esto, la pestaña Base de datos se puede utilizar para mostrar
una categorización de todas las versiones de SQL Server y la cantidad de versiones que existe en los entornos
detectados.
Figura 4: escenario de base de datos de MAP Toolkit
Al hacer clic en SQL Server Discovery, se presenta un desglose adicional no solo de las versiones de SQL Server que
se encuentran en los equipos inventariados, sino también de las instancias de SQL Server Reporting Services (SSRS),
SQL Server Integration Services (SSIS) y SQL Server Analysis Services (SSAS), que también podrían formar parte de la
migración general.

Figura 5: escenario de SQL Server Discovery de MAP Toolkit
En la parte superior derecha, se encuentran enlaces para generar informes de los detalles de la base de datos de
SQL Server Assessment y SQL Server. Al hacer clic en estos enlaces, MAP Toolkit procesa los datos inventariados
actuales y produce un informe predefinido en forma de una hoja de cálculo de Excel.

Figura 6: ejemplo de informe de SQL Server Assessment de MAP Toolkit
El informe de SQL Server Assessment brinda una buena descripción general acerca de las instancias de SQL Server
detectadas, la versión y la edición de cada una, el nivel actual del Service Pack, si está agrupado, qué idioma está
configurado para usar, y mucho más. También detalla el servidor en el que se ejecuta SQL Server, lo que incluye la
cantidad de procesadores que se destinan, la memoria del sistema asignada, la cantidad y el tamaño de los discos
lógicos, el espacio libre en disco y si el servidor es físico o virtual.
El informe más útil para el escenario de migración de base de datos es el informe detallado de SQL Server
Database, que proporciona información completa sobre todas las instancias de SQL Server encontradas, los
nombres de las bases de datos alojadas en esas instancias de SQL Server, su actual tamaño, así como estadísticas
sobre la cantidad de tablas, vistas y procedimientos almacenados dentro de esas bases de datos.

Figura 7: ejemplo del informe detallado de SQL Server Database de MAP Toolkit
MAP Toolkit también recopila métricas de rendimiento de equipos, lo cual puede ser útil para dimensionar las
máquinas virtuales o las bases de datos de SQL Azure.
Con todos los datos recopilados con MAP Toolkit, puede generar una lista detallada de las bases de datos y de las
cargas de trabajo que se encuentran en su entorno y luego puede crear una lista corta de las bases de datos y de
las cargas de trabajo que desee evaluar para determinar su idoneidad para migrar a servicios de datos de Azure.
Descargue MAP Toolkit desde la siguiente URL: https://www.microsoft.com/en-us/download/details.aspx?id=7826
3.3 Herramientas y servicios de Microsoft: Asistente de migración de bases de datos
Después de usar MAP Toolkit para ayudar a generar una lista corta de bases de datos y cargas de trabajo, los
posibles candidatos de migración pueden incorporarse a una herramienta denominada Microsoft Data Migration
Assistant (DMA) para una evaluación exhaustiva.
DMA es otra descarga gratuita del sitio web de Microsoft que ayuda con la migración de instancias locales de SQL
Server a Azure SQL Database o a una instancia moderna de SQL Server hospedada en una máquina virtual de
Azure. DMA, que por lo general se ejecuta en su estación de trabajo, reemplaza la herramienta heredada del Asesor
de actualizaciones de SQL Server y se ha extendido completamente para admitir plataformas en la nube como
destinos aptos.

Figura 8: Data Migration Assistant
DMA se explorará detalladamente en la siguiente sección, pero a continuación se incluye una breve descripción
general de lo que ofrece DMA. DMA le permite definir proyectos para la evaluación de datos o para la migración de
datos. Para ambos tipos, usted define los tipos de origen y de destino necesarios a medida que crea el proyecto.
Figura 9: creación de un nuevo proyecto de evaluación de DMA

El proyecto de evaluación utiliza el flujo de trabajo de evaluación de DMA para ayudarlo a detectar problemas que
puedan afectar a la migración de Azure SQL Database y, luego, proporciona indicaciones detalladas sobre cómo
resolverlos.
Figura 10: evaluación de la compatibilidad de bases de datos con DMA
Se incluyen los problemas de bloqueo de migración, como problemas de compatibilidad que impiden la migración
satisfactoria de una base de datos de SQL Server local a Azure SQL Database, o el resaltado de características
admitidas parcialmente o no admitidas que están actualmente en uso en el SQL Server de origen. A continuación,
proporciona recomendaciones para ayudar a solucionar esos problemas, así como enfoques alternativos para la
migración.

El proyecto de migración utilizará el flujo de trabajo de migración de DMA para ayudarlo a migrar los datos
seleccionados del origen al destino y, al mismo tiempo, controlará el proceso de copiado entre las dos entidades.
Además, DMA pronto podrá crear beneficios al indicar nuevas características en la plataforma de SQL Server
de destino, de las cuales la base de datos puede beneficiarse después de una actualización. Estos beneficios
podrían ayudar a mejorar la solución de base de datos en las áreas de rendimiento, seguridad o
almacenamiento. Esta característica de DMA se espera en breve.
Al utilizar MAP Toolkit, encontramos todos nuestros activos de base de datos y sus características, como el
tamaño y el servidor de hospedaje. DMA es una herramienta que se puede alimentar con bases de datos
encontradas mediante MAP Toolkit para su posterior análisis y evaluación. Trataremos el tema de la
evaluación con DMA de forma más detallada en la siguiente sección.

4 EVALUACIÓN
Ahora sabemos con qué cargas de trabajo tratamos, dónde están, qué tan grandes son y para qué se utilizan. Los
datos obtenidos de la fase de iniciación y descubrimiento ahora se pueden utilizar como introducción para la
segunda fase, evaluación. Los datos se deberán recopilar y analizar para lograr nuestros objetivos para esta fase,
que consiste en determinar lo siguiente:
Los bloqueadores de la migración
No se podrá continuar con una migración hasta que se resuelvan estos problemas.
Cambios importantes
Se podrá continuar con una migración, pero se deberá reparar la carga de trabajo después de la migración para
que funcione.
Características para aprovechar
Hay características de Azure disponibles que, si se utilizan, pueden potenciar los beneficios de migrar a los servicios
de Azure.
Esfuerzos implicados en la solución de problemas
Un cálculo del tiempo y de los procesos requeridos para rectificar las cuestiones señaladas anteriormente.
Para alcanzar esos objetivos, se realiza un examen más minucioso de las cargas de trabajo con énfasis en las
siguientes áreas:
 Evaluación de las cargas de trabajo para la migración
 Evaluación de los criterios de carga de trabajo
 Evaluación de la base de datos con Data Migration Assistant
Evaluación Página 18 de 62
4.1 Evaluación de las cargas de trabajo para la migración
Para establecer un plan de migración completo, una evaluación exhaustiva de las cargas de trabajo antes de la
migración ayudará a determinar qué bases de datos necesitarán migrar a la nube, así como las cantidades implicadas.
Si tiene la intención de migrar todas las cargas de trabajo locales a los servicios en la nube de Azure, un pase
de evaluación inicial con la intención de consolidar o desmantelar cargas de trabajo heredadas, siempre que sea
posible, puede ayudar a reducir la cantidad final de cargas de trabajo de base de datos que se necesitan migrar.
Se deben realizar investigaciones sobre si las aplicaciones locales en uso ahora tienen disponible un modelo de
implementación hospedado o basado en SaaS y, si es así, piense en la posibilidad de migrar a esa plataforma para
reducir los costos administrativos.
Continúe por la ruta de migración de la nube buscando migrar las bases de datos de bajo esfuerzo y de alto
impacto. Es decir, busque segregar las cargas de trabajo descubiertas según su impacto empresarial.
Las cargas de trabajo para las aplicaciones que un número selecto de usuarios de la empresa utiliza deben tener un
ámbito más pequeño para la interrupción que las aplicaciones que se utilizan ampliamente en toda la empresa. Las
cargas de trabajo no críticas, como las plataformas de desarrollo, pruebas y formación, serían una buena opción
para la primera ola de migraciones.
A continuación, las cargas de trabajo se pueden clasificar aún más por la gravedad de los problemas destacados
durante la fase de iniciación y descubrimiento. Los bloqueadores de migración o los cambios importantes conocidos
podrían requerir un trabajo de corrección considerable y posicionar las cargas de trabajo en la lista de migración.
Del mismo modo, los cambios de comportamiento podrían implicar que algunas cargas de trabajo necesitan más
investigación y planificación antes de que puedan realizar la transición a la nube para comprender por completo
cualquier impacto. Las cargas de trabajo que utilizan características en desuso aún deben poder migrarse, pero más
adelante merecen una investigación para eliminar su dependencia de esas características.
Uso de migraciones continuas

Es posible que las aplicaciones críticas utilizadas comercialmente no puedan permitirse las plazos de inactividad
cuantificables que se necesitan para migrar las cargas de trabajo a la nube. También pueden depender de otras
cargas de trabajo que deban migrarse a la misma agrupación, el tamaño de los datos en todas las aplicaciones
agrupadas determinan la cantidad de tiempo necesaria para un lapso de interrupción mientras se copian los datos.
Al utilizar las metodologías de migración continuas, las aplicaciones pueden seguir utilizando la base de datos de
origen mientras que la mayor parte de los datos se sincroniza con la nube en segundo plano. Los datos modificados
durante el proceso de migración se replican sobre la marcha en la plataforma de destino, lo que garantiza la
conservación de todas las transacciones de datos.
Figura 11: flujo continuo de trabajo de migraciones con DMA y DMS
Esta metodología proporciona un tiempo de inactividad general muy reducido, ya que este se limita al tiempo que
lleva completar el paso final para volver a colocar la aplicación de consumo a la base de datos de destino.
Sugerencia: Microsoft se ha asociado con Attunity para proporcionar su producto Attunity

Replicate for Microsoft Migrations a los clientes de Microsoft sin costo adicional.
Attunity Replicate migra continuamente las bases de datos de muchas plataformas comerciales y
de código abierto, como Oracle, PostgreSQL, MySQL y SAP Sybase ASE, a la plataforma de datos
de Microsoft prácticamente sin tiempo de inactividad. Los sistemas de origen permanecen en
funcionamiento durante el proceso de migración, y cualquier cambio en las bases de datos de
origen se replica continuamente en la base de datos de destino, por lo que siempre se trabaja
con datos en tiempo real.
Para obtener más información, consulte https://aka.ms/attunity-replicate
4.2 Evaluación de los criterios de carga de trabajo
Requisitos de rendimiento
Es importante comprender si cada carga de trabajo es un usuario de recursos alto o bajo y determinar cuántos
recursos de Azure se requerirán después de la migración. Si desea pasar a SQL Server en las VM de IaaS de Azure,
esto simplemente equivaldría a hacer coincidir la cantidad de núcleos de cálculo asignados actualmente con la
cantidad de núcleos de cálculo de la plataforma de destino. Si va a migrar a Azure SQL Databases, puede exigirse
que se calcule la cantidad de Unidades de transacción de base de datos (DTU) o los núcleos virtuales (vCores)
necesarios para cada base de datos. Azure SQL Database proporciona dos modelos distintos para la medición y la
compra de procesos: los que se basan en DTU y los que se basan en vCore.
¿Qué son las Unidades de transacción de base de datos (DTU)?
El rendimiento de Azure SQL Database se mide mediante la Unidad de transacción de base de datos o DTU, que
es una métrica agregada de CPU, memoria y E/S. Las DTU son útiles para comprender la cantidad relativa de
recursos asignados entre distintas Azure SQL Databases, ya que los diversos niveles de rendimiento disponibles se
caracterizan por sus DTU asignadas. Por ejemplo, el nivel de rendimiento básico tiene un recuento máximo de DTU
de 5, mientras que los niveles de rendimiento estándar comienzan en un recuento máximo de DTU de 10 para una
instancia “S0” y aumentan hasta un máximo de 3000 para una instancia “S12”. P15 es el nivel de rendimiento más
alto disponible, donde se pueden alcanzar hasta 4000 DTU. El modelo basado en DTU proporciona simplicidad
para aquellos que desean una solución preconfigurada.
Consejo: Justin Henriksen ha creado una herramienta gratuita llamada Azure SQL Database DTU
Calculator que puede ayudarlo a determinar el número de DTU para sus bases de datos actuales
de SQL Server y brindarle una recomendación sobre el nivel mínimo de rendimiento y de
servicio que necesita antes de migrar a Azure SQL Database. Azure SQL Database DTU
Calculator también admite el cálculo de los requisitos para los grupos elásticos.
Para obtener más información, consulte http://dtucalculator.azurewebsites.net/
¿Qué son los vCores?

Un núcleo virtual (vCore) representa la CPU lógica que se ofrece con una elección entre generaciones de hardware.
Las CPU lógicas, generación 4 se basan en procesadores Intel E5-2673 V3 (Haswell) 2,4 GHz, y las CPU lógicas,
generación 5 se basan en los procesadores Intel E5-2673 V4 (Broadwell) 2,3 GHz. El modelo basado en vCore
proporciona más opciones y flexibilidad para aquellos que deseen optimizar sus cargas de trabajo en la nube al
permitir que el proceso, el almacenamiento y la E/S se configuren de forma independiente. Por ejemplo, instancia
administrada de Azure SQL Database le permite elegir entre 8, 16 o 24 instancias de vCore y hasta 8 TB de
almacenamiento.
Requisitos de cumplimiento
Determine si existen requisitos normativos o de seguridad específicos. La iniciativa de la nube de confianza de
Microsoft se basa en los cuatro principios fundacionales de seguridad, privacidad, cumplimiento y transparencia,
que se reflejan en las plataformas y los servicios ofrecidos mediante Azure. Los centros de datos de Azure cumplen
con estrictas normativas y estándares de cumplimiento para ayudar a los clientes a cumplir con las leyes
internacionales de protección de datos y con los requisitos del sector. Las leyes de residencia de datos también
pueden establecer que los datos de una aplicación determinada se deban conservar en el país o en la región
geográfica, lo cual restringe los centros de datos de Azure que se pueden utilizar.
Puede obtener más información sobre las prácticas de cumplimiento de Azure en el Centro de confianza de Azure:
https://azure.microsoft.com/support/trust-center/compliance/.
Tiempo de inactividad de migración
Conozca los requisitos empresariales en torno a la carga de trabajo que se migrará. ¿Existe alguna cantidad de
tiempo de inactividad que sea aceptable? Esto afectará al enfoque de migración, a los conjuntos de herramientas
utilizados y a los plazos implicados.
Disponibilidad
Después del tiempo de inactividad de la migración, ¿cuáles son los requisitos de disponibilidad en curso para la carga
de trabajo? Azure SQL Databases están disponibles localmente y de forma estándar, con tres copias de su base de
datos que se utilizan para mantener los datos en línea y accesibles durante las revisiones y errores transitorios en el
disco duro. SQL Server en las VM de Azure requeriría tecnologías de alta disponibilidad, como Failover por clúster
de Always On, grupos de disponibilidad de Always On, reflejo de base de datos o trasvase de registros.
Recuperación ante desastres
Establezca si hay requisitos de recuperación ante desastres para las cargas de trabajo de la aplicación que admite
la base de datos y comprenda los requisitos de RTO y RPO. Solo se necesitan unos pocos clics para implementar
la recuperación ante desastres en Azure SQL Database a fin de establecer una réplica de la base de datos fuera de
la región a un costo mínimo; la característica de replicación geográfica protege su base de datos y aplicación frente
a errores regionales más amplios. SQL Server en la VM de IaaS de Azure no dispone de compatibilidad con la
recuperación ante desastres y puede requerir la implementación de SQL Server Enterprise Edition mediante grupos
de disponibilidad de Always On a fin de cumplir con los requisitos agresivos de RTO para cargas de trabajo de
misión crítica. Las cargas de trabajo de prioridad más baja que utilizan Azure Site Recovery normalmente bastan si
la protección a nivel del servidor virtual es aceptable.
Cargas de trabajo personalizadas

Es posible que existan bases de datos que tengan integraciones de herramientas de terceros que no se admiten
actualmente en Azure SQL Database. Es posible que se deba contactar al tercer proveedor para una versión
compatible o productos alternativos considerados.
Azure tiene una plataforma de destino para prácticamente cualquier carga de trabajo de la base de datos.
Comprender los criterios de origen es clave para determinar dónde y cómo debe instalarse la carga de trabajo.
4.3 Evaluación de la base de datos con Database Migration Assistant (DMA)
Como se mencionó anteriormente, Data Migration Assistant (DMA) es una herramienta de descarga gratuita
de Microsoft que se instala y ejecuta localmente. DMA le permite actualizar a una plataforma de datos moderna
mediante la detección de problemas de compatibilidad que pueden afectar a la funcionalidad de la base de datos
antes de intentar migrar a una nueva versión de SQL Server o a Azure SQL Database. También ofrece
recomendaciones sobre cómo solucionar esos problemas.
 Evaluación de instancias locales de SQL Server que migran a Azure SQL Database
 Detección de problemas que pueden afectar a una actualización de una instancia local de SQL Server
 Detección de nuevas características en la plataforma de SQL Server de destino que la base de datos puede
aprovechar después de una actualización
 Migración de una instancia local de SQL Server a una instancia moderna de SQL Server
Puede acceder a una descripción general de DMA en el siguiente enlace:

https://docs.microsoft.com/es-xl/sql/dma/dma-overview
Al usar DMA, primero debe evaluar y detectar los problemas en la base de datos de origen que impiden una
migración satisfactoria. Con esta información, debe corregir la causa principal o implementar una metodología
alternativa para cada problema resaltado. Luego, los procesos de evaluación y corrección se repiten hasta que la
base de datos de origen pase todas las pruebas DMA; en ese momento, el esquema de la base de datos de origen
se puede implementar en la base de datos de destino en la nube con un suma confianza.
Figura 12: flujo de trabajo de evaluación y reparación mediante DMA
4.4 Pasos de evaluación mediante DMA
Para usar DMA para crear una evaluación, siga los pasos que se encuentran a continuación.
1. Descargue DMA y luego instálelo.

2. Cree un proyecto de Nueva evaluación.
a. Seleccione el ícono Nuevo (+), seleccione el tipo de proyecto de Evaluación, especifique un nombre de
proyecto, seleccione SQL Server como origen y Azure SQL Database como destino y luego seleccione Crear.
Figura 13: creación de un nuevo proyecto de DMA
b. Seleccione uno o ambos tipos de informe de evaluación (Comprobar compatibilidad de la base

de datos y Comprobar la paridad de características) y luego seleccione Siguiente.
Figura 14: opciones de evaluación de DMA
c. En la hoja conectar con un servidor, especifique el nombre de la instancia de SQL Server a la que desea
conectarse, especifique el tipo de autenticación y las propiedades de conexión y luego seleccione Conectar.
Figura 15: conexión al origen para la evaluación de DMA
d. En la salida Agregar orígenes, seleccione las bases de datos que desea evaluar y luego seleccione Agregar.
Figura 16: selección de origen en DMA
e. Seleccione Iniciar evaluación.
Ahora espere los resultados de la evaluación; la duración de la evaluación depende de la cantidad de bases
de datos agregada y del tamaño del esquema de cada base de datos. Los resultados se mostrarán por base
de datos en cuanto estén disponibles.
f. Seleccione la base de datos que ha completado la evaluación y luego seleccione Problemas de
compatibilidad para revisar los objetos incompatibles que se encuentran clasificados en Bloqueadores
de migración, Cambios de comportamiento y Características en desuso.
Figura 17: recomendaciones y resultados de compatibilidad de DMA
De forma similar, puede revisar las recomendaciones en las áreas de Rendimiento, Almacenamiento y
Seguridad. Las recomendaciones de características abarcan diversas características, como OLTP In-Memory
y Columnstore, Stretch Database, Always Encrypted, Enmascaramiento dinámico de datos y Cifrado
transparente de datos.
g. Seleccione Paridad de características de SQL Server para revisar las características incompatibles o las
características compatibles parcialmente en Azure SQL Database.
Figura 18: resultados y hallazgos de la paridad de características de DMA
DMA también proporciona un conjunto integral de recomendaciones, enfoques alternativos disponibles

en Azure y pasos de mitigación.
3. Revisión de los resultados de la evaluación

a. Después de completar todas las evaluaciones de la base de datos, seleccione Exportar informe para
exportar los resultados a un archivo JSON o CSV para analizar los datos cuando guste.
4.5 Busque banderas rojas de alto nivel
Ahora se deberían tener en cuenta los hallazgos que surgieron durante la fase de iniciación y descubrimiento, y las
herramientas de evaluación utilizadas durante la fase de evaluación. Si no se puede encontrar una solución viable,
las opciones posibles para solucionar los problemas detectados deben identificarse o marcarse como posibles
bloqueadores de migración.
¿Está utilizando características, tales como Correo de la base de datos, Agente SQL? Estas características están
disponibles en la instancia administrada de Azure SQL Database, que es muy compatible con SQL Server local.
Si la base de datos no utiliza características avanzadas de SQL Server, como MSDTC, MDS o QTS, Azure SQL
Database o los grupos elásticos de Azure SQL Database serían una buena opción, ya que Microsoft Operations se
encarga de la mayoría de la gestión de la infraestructura, lo cual disminuye drásticamente los costos administrativos.
¿También está buscando migrar SSRS, SSAS o SSIS? Lamentablemente, no todos los componentes de SQL Server
tienen actualmente un equivalente a los servicios de datos de Azure.
Actualmente, SSRS no tiene ningún equivalente directo basado en la nube, pero los informes se pueden volver
a escribir según Microsoft Power BI. Como alternativa, SSRS se puede implementar con SQL Server en una VM
de Azure.
SSAS se puede migrar a Azure Analysis Services, que es en gran medida compatible con las versiones recientes
de SQL Server Analysis Services Enterprise Edition. Como alternativa, SSAS se puede implementar con SQL Server
en una VM de Azure.
Los paquetes SSIS se pueden invocar mediante procedimientos almacenados en Azure Data Factory. Como
alternativa, SSIS se puede implementar con SQL Server en una VM de Azure.
5 PLANIFICACIÓN
La tercera etapa del plan de migración es la planificación. En esta etapa, que es la más importante, el objetivo es
establecer dos aspectos clave para cada carga de trabajo:
Plataforma de destino
Esta es la ubicación final para cada carga de trabajo.
Migración de una sola vez en lugar de sincronización continua

Una migración de una sola vez implica que se puede desconectar una carga de trabajo, mientras que una
sincronización continua implica que la base de datos de origen de carga de trabajo debe estar disponible durante
la migración.
La siguiente sección lo guiará por la toma de estas decisiones y lo ayudará a formular un plan de acción para cada
carga de trabajo, utilizando los siguientes temas:
 Planificar la plataforma de destino

 Cómo elegir la plataforma de destino adecuada
 Migrar SSAS, SSIS y SSRS a Azure
 Planificar la herramienta de migración
 Ejemplos de selección de plataforma de destino
Planificación Página 30 de 62
5.1 Planificar la plataforma de destino
Después de completar la evaluación del entorno de origen y de comprender los requisitos de la carga de trabajo,
puede elegir la ubicación de destino:
Figura 19: plataformas disponibles de base de datos de Azure
Azure SQL Database

Azure SQL Database es una oferta de servicio totalmente administrada en Azure con la que puede crear una base
de datos con gran parte de la funcionalidad de ejecutar su propio SQL Server en una máquina virtual, pero sin tener
que preocuparse por operarla. La sobrecarga de mantenimiento y administración asociada desaparece debido a
que Microsoft Operations se encarga de todo el sistema operativo subyacente y de la aplicación.
Azure SQL Database ofrece tres niveles de servicio dentro de su modelo basado en DTU para admitir cargas
de trabajo de base de datos tanto ligeras como pesadas:
 Básico
 Estándar
 Premium
El nivel de servicio afecta a la especificación y a las características de su base de datos, que conciernen el tamaño, el nivel
de rendimiento, la disponibilidad y la concurrencia. El nivel de servicio seleccionado dicta los límites del rendimiento
alcanzable, medido en Unidades de transacción de base de datos (DTU), así como el tamaño de la base de datos.
 Básico: ideal para bases de datos pequeñas, especialmente para aquellas en fases de desarrollo. Reducido
a 2 GB de tamaño, y se le asignan solo recursos informáticos limitados.
 Estándar: lo mejor para bases de datos de uso general con requisitos de rendimiento moderados, por lo que
probablemente constituirá la mayor parte de sus Azure SQL Databases. Admite bases de datos con tamaño de
hasta 250 GB.
 Premium: diseñado para bases de datos de misión crítica que tienen requisitos de alto rendimiento y alta
disponibilidad. El nivel Premium tiene baja latencia y puede admitir altas cargas de trabajo de entrada/salida, así
como bases de datos con un tamaño de hasta 4 TB.
Puede desarrollar su primera aplicación en una base de datos pequeña y sencilla a un costo mínimo por mes y, luego,
cambiar su nivel de servicio manualmente o mediante programación en cualquier momento para satisfacer las
necesidades de su solución. Puede ajustar un rendimiento sin tiempo de inactividad para su aplicación o para sus
clientes. La escalabilidad dinámica permite que la base de datos responda de manera transparente a los requisitos
de los recursos que cambian rápido y le permite pagar solo por los recursos que necesita cuando los necesita.
Azure SQL Database ofrece dos niveles de servicio dentro de su modelo basado en vCore:
 Uso general
 Crítico a nivel empresarial
Para las aplicaciones de SQL Database actuales que utilizan el modelo DTU, el nivel de servicio de uso general es
similar a la edición estándar. El nivel de servicio de Crítico a nivel empresarial es similar a la edición Premium. Los
niveles de servicio basados en vCore proporcionan flexibilidad mediante un control independiente sobre las
configuraciones de almacenamiento y cálculo para que pueda optimizarlo a lo que precisamente requiere la
aplicación, y pagar según corresponda.
 Uso general: para la mayoría de las cargas de trabajo empresariales. Ofrece opciones de cálculo y
almacenamiento, equilibradas y escalables, orientadas al presupuesto.
 Crítica a nivel empresarial: lo mejor para aplicaciones empresariales con altos requisitos de I/O. Ofrece la
máxima resistencia a fallas con varias réplicas aisladas.
¿Por qué usar Azure SQL Database?
Azure SQL Database ofrece un rendimiento predecible en varios niveles de servicio que proporcionan lo siguiente:
 Compatibilidad con el motor de SQL Server y compatibilidad con redes virtuales nativas (VNET)
 Escalabilidad dinámica sin tiempo de inactividad
 Optimización inteligente integrada, escalabilidad y disponibilidad globales, y opciones de seguridad avanzadas
 Elimina los costos de hardware y reduce los costos administrativos
 Capacidades integradas de infraestructura de tolerancia a errores, Azure SQL Database proporciona
características, tales como copias de seguridad automatizadas, restauración a un momento dado, restauración
geográfica y replicación geográfica activa para aumentar la continuidad del negocio para aplicaciones que
alojan datos en Azure SQL Database
 Bases de datos de hasta 4 TB o bases de datos más grandes que se pueden dividir horizontal o verticalmente
con un patrón de escalado horizontal
Microsoft Azure SQL Database puede cambiar entre los niveles de servicio, de modo que pueda asignar fácilmente
más recursos y capacidad (por un costo extra) a medida que las necesidades de la base de datos crezcan con el
tiempo. Cambiar el nivel en el portal de Azure o del script de PowerShell puede desencadenar una operación en
segundo plano para crear una réplica de la base de datos seguida de una interrupción pequeña, de solo unos
segundos, mientras se produce el cambio. Esto también significa que la subestimación durante el proceso de
dimensionamiento inicial se puede rectificar fácilmente en una etapa posterior.
Grupos elásticos de Azure SQL Database

Para muchos procesos y aplicaciones empresariales, ser capaz de crear bases de datos únicas y de aumentar o
disminuir el rendimiento a petición es suficiente, especialmente si los patrones de uso son relativamente previsibles.
Pero si tiene patrones de uso imprevisibles, estos pueden hacer que sea difícil administrar los costos y su modelo
de negocio. Los grupos elásticos se idearon para resolver este problema. Se asignan recursos de rendimiento a un
grupo en lugar de a una base de datos individual, y se paga por los recursos de rendimiento colectivo del grupo en
lugar de por el rendimiento de una sola base de datos.
¿Por qué usar los grupos elásticos de Azure SQL Database?

Los grupos elásticos son más adecuados para las aplicaciones con muchas
bases de datos que generalmente tienen poca utilización con picos
esporádicos. Esto es especialmente útil para las ofertas de software como
servicio con varios inquilinos, donde todos tienen su propia base de datos.
Se pueden lograr ahorros considerables en los costos mediante el uso de los
grupos elásticos de Azure SQL Database en esta situación; incluso, se pueden
obtener mayores ahorros cuando se agregan más bases de datos al grupo.
Si se consumen todos los DTU del grupo elástico, el rendimiento del grupo se
regulará con cada base de datos que reciba una cantidad igual de recursos
informáticos, como la característica Resource Governor de SQL Server.
Descripción técnica:
https://docs.microsoft.com/es-xl/azure/sql-database/sql-database-technical-overview
Instancia administrada de Azure SQL Database
La instancia administrada de Azure SQL Database ofrece una amplia compatibilidad con SQL Server y aislamiento de
red, lo que facilita elevar y desplazar las bases de datos de SQL Server a Azure. Ahora sencillamente puede respaldar
una base de datos local y restaurarla en una instancia administrada de Azure SQL Database. Se basa en el mismo
servicio totalmente administrado que ofrece infraestructura como Azure SQL Database y que mantiene todas las
características de Azure SQL Database, como la replicación geográfica activa, la alta disponibilidad, las copias de
seguridad automáticas, el asesor de bases de datos, la detección de amenazas, los conocimientos inteligentes y la
evaluación de vulnerabilidad. También agrega compatibilidad con tamaños de base de datos de hasta 8 TB y
características de SQL Server, tales como el Agente SQL, las consultas entre bases de datos y la replicación.
Para las organizaciones que buscan migrar una gran cantidad de bases de datos de SQL Server (desde bases de
datos locales o VM/alojadas, autocreadas o proporcionadas por ISV), con el menor esfuerzo posible, la instancia
administrada brinda un destino de migración simple, seguro y económico.
¿Por qué usar la instancia administrada de Azure SQL Database?

 Entorno aislado (servicio de un solo inquilino con VNET, recursos informáticos y de almacenamiento dedicados)
 Retención y recuperación de copias de seguridad que el cliente puede configurar
 Database Advisor y Log Analytics para el análisis avanzado de cargas de trabajo
 Ajuste y mantenimiento automáticos de bases de datos para lograr un rendimiento previsible
 Supervisión, resolución de problemas y administración a escala
 Funcionalidad del portal Azure para el aprovisionamiento y escalamiento de servicios manuales
 Autenticación de Azure AD, compatibilidad con el inicio de sesión único
 Se adhiere a los mismos estándares de cumplimiento que Azure SQL Database
 Cifrado de los datos en tránsito y en reposo con claves de cifrado proporcionadas por el cliente
 Sin gastos de parches ni de actualización de la versión
SQL Server en VM de Azure
En esta sección, se analiza SQL Server instalado y hospedado en la nube en máquinas virtuales (VM) de Windows
Server que se ejecutan en Azure, también conocido como infraestructura como servicio (IaaS). SQL Server en
máquinas virtuales de Azure está optimizado para migrar aplicaciones de SQL Server existentes. Todas las versiones
y ediciones de SQL Server están disponibles. Las VM ofrecen 100 % de compatibilidad con SQL Server, lo que le
permite hospedar tantas bases de datos como sea necesario y ejecutar transacciones entre bases de datos. Las VM
permiten el control total en SQL Server y Windows.
¿Por qué usar SQL Server en VM de Azure?
Las VM son excelentes para las aplicaciones existentes que requieren una migración rápida a la nube con cambios
mínimos. Las VM son adecuadas para escenarios rápidos de prueba y desarrollo, cuando no desea comprar un
hardware de SQL Server local que no sea de producción.
Otras razones para usar las VM para la implementación de SQL Server en la nube:
 Configurar y administrar la alta disponibilidad, la recuperación ante desastres y los parches para SQL Server de
un forma más fácil que con las máquinas locales
 Entorno personalizado con plenos derechos administrativos
 Instancias de SQL Server con un máximo de 64 TB de almacenamiento y tantas bases de datos como sea necesario
 Totalmente compatible con la replicación transaccional de SQL Server, grupos de disponibilidad de AlwaysOn,
servicios de integración, trasvase de registros para replicar datos y copias de seguridad tradicionales de SQL Server
5.2 Cómo elegir la plataforma de destino adecuada
Cuando se busca elegir una plataforma de destino adecuada para cada carga de trabajo, hay tres aspectos que se
deben tener en cuenta:
 Escenarios de uso
 Características
 Costo total de propiedad
5.3 Elegir la plataforma de destino por escenarios de uso
Bases de datos individuales y grupos elásticos de Azure SQL Database

Azure SQL Database es ideal para los clientes que desarrollan nuevas aplicaciones SaaS multiinquilino o que
transforman intencionalmente sus aplicaciones locales existentes en una aplicación SaaS multiinquilino. Hay tantas
diferencias entre las bases de datos únicas de Azure SQL Database y los grupos elásticos y SQL Server local que no
suele ser sencillo levantar y desplazar cargas de trabajo de base de datos locales a Azure SQL Database.
Igualmente, las aplicaciones de terceros aún no admiten la plataforma de Azure SQL Database.
Esta versión de SQL Server está diseñada para un alto nivel de tiempo de actividad, con alta disponibilidad que
viene como estándar, y que se puede extender para proporcionar topologías replicadas geográficamente.
Las instancias administradas son buenas para los clientes que buscan migrar varias aplicaciones desde bases de
datos locales o VM/alojadas, autocreadas o proporcionadas por ISV, con el menor esfuerzo de migración posible.
Además, estas características hacen que las instancias administradas sean más deseables:
 Alto nivel de compatibilidad con SQL Server local
 Compatibilidad con el aislamiento de cargas de trabajo desde la Internet pública mediante la compatibilidad
con VNET con direcciones IP privadas y VPN a redes locales
Las máquinas virtuales pueden ayudar a los clientes que necesiten personalizar el sistema operativo o el servidor de
bases de datos, así como a los clientes que tengan requisitos específicos en cuanto a ejecutar aplicaciones de
terceros en paralelo con SQL Server (en la misma máquina virtual).
5.4 Elección de la plataforma de destino por características
Bases de datos individuales y grupos elásticos de Azure SQL Database

Sería adecuado usar Azure SQL Database si el área de superficie de la aplicación tuviese un ámbito de base de datos.
Si la aplicación utiliza algunas características de SQL, es posible que Azure SQL Database no sea adecuado, ya que
no todas las características están disponibles todavía.

Su uso sería adecuado si el área de superficie de la aplicación tuviese un ámbito de instancia y requiriese
características que no están disponibles en Azure SQL Database, como lo siguiente:
 Agente SQL
 MSDTC
 DQS
 MDS
 Correo de base de datos
 Filestream
 Filetable
 PolyBase
A continuación, se mencionan algunas características adicionales:
 Compatibilidad con servidores vinculados

 Compatible con nuevos servicios en la nube de Azure, como la detección de amenazas
SQL Server en IaaS de Azure

Utilícelo si el área de superficie de la aplicación tiene un ámbito de instancia y requiere características que no están
disponibles en Azure SQL Database
Además, admite las instancias locales de lo siguiente:
 SSRS
 SSAS
 SSIS
5.5 Elección de la plataforma de destino por costo
Azure SQL Database

La naturaleza de la plataforma como servicio de Azure SQL Database reduce considerablemente los costos de
administración y gestión en la topología de IaaS más tradicional de SQL Server en Azure, ya que la mayor parte del
trabajo necesario se completa silenciosamente en segundo plano mediante Microsoft Operations. Esto es evidente a
escala donde se pueden realizar ahorros considerables en tiempo y esfuerzo.
Grupos elásticos de Azure SQL Database

Los grupos elásticos de Azure SQL Database pueden ofrecer ahorros considerables si los utilizan varias bases de
datos que tengan demandas de uso variables e imprevisibles. El uso compartido de recursos informáticos entre
todas las bases de datos del grupo significa que los clientes no están obligados a aprovisionar recursos en ex ceso
para todas las bases de datos a fin de satisfacer sus picos de uso poco frecuentes. Se realizan más ahorros en el
mantenimiento del servidor y los costos administrativos, ya que la mayor parte del trabajo necesario se completa
silenciosamente en segundo plano mediante Microsoft Operations.

Las instancias administradas se ofrecen a los clientes que desean una oferta de servicio totalmente administrada,
donde puedan levantar y desplazar fácilmente su entorno local con cambios de configuración mínimos. El entorno
ofrece un mínimo de ocho núcleos y hasta 35 TB de almacenamiento, y se encuentra en una red virtual aislada. Esta
oferta es ideal para los clientes que quieren llegar rápido a la nube y evitar la sobrecarga de las máquinas virtuales.

Las VM imponen mayores costos de computación, almacenamiento y administración por medio de las ofertas de
Azure SQL Database, pero conceden un mayor control mediante SQL Server y la infraestructura.
Sugerencia: beneficio híbrido de Azure para ahorros extras
Si tiene Software Assurance activo en licencias de Windows o SQL Server existentes, puede usar
el beneficio híbrido de Azure para obtener ahorros en las opciones de SQL Database basadas en
Window Server o vCore.
Consulte https://azure.microsoft.com/es-xl/pricing/hybrid-benefit/ para obtener más

información.
5.6 Migración de SSAS, SSIS y SSRS a una oferta de servicio completamente administrada de Azure
¿También está buscando migrar SSRS, SSAS o SSIS? Lamentablemente, no todos los componentes de SQL Server
tienen actualmente un equivalente a los servicios de datos de Azure.
SQL Services Analysis Services (SSAS)

SSAS se puede migrar a Azure Analysis Services, que es en gran medida compatible con las versiones recientes de
SQL Server Analysis Services Enterprise Edition.
Para obtener más información, consulte los videos de Azure Analysis Services en el canal 9.
SQL Server Integration Services (SSIS)

Use Azure SSIS Integration Runtime, que es la infraestructura de proceso que usa Azure Data Factory.
Los paquetes SSIS se pueden invocar mediante procedimientos almacenados en Azure Data Factory para
proporcionar una verdadera compatibilidad de primera clase de la ejecución de paquetes SSIS.
Para obtener más información, consulte la descripción general de levantamiento y desplazamiento de Azure SSIS y
el tutorial de Azure Data Factory.
SQL Server Reporting Services (SSRS)

Actualmente, SSRS no tiene ningún equivalente basado en la nube directo, pero los informes se pueden volver
a escribir con Microsoft Power BI o migrar a SSRS que se ejecute en una VM de Azure.
5.7 Migrar SSAS, SSIS y SSRS a VM de Azure
En primer lugar, instale los servicios en una VM de Azure y conéctese a Azure SQL Database o a la instancia
administrada.
Algunos vínculos de referencia para las migraciones de SSRS y SSAS:
 SSAS multidimensional
 SSAS tabular
 Orígenes de datos de SSRS
 Tipo de conexión de SSRS
Como alternativa, todavía es posible utilizar un servidor de SSRS local existente para conectarse a Azure SQL
Database o a una instancia administrada para generar informes.
5.8 Planificar la herramienta de migración
A menudo, el lapso de mantenimiento o el tiempo de inactividad aceptable que estipula el propietario de la

aplicación determinará qué método de migración debe utilizarse, con una herramienta de migración
correspondiente para que coincida.
Crítico (sin tiempo de inactividad): replicación transaccional de SQL Server

Management Studio (SSMS)
Alto (pequeño lapso de mantenimiento): Azure Database Migration Service

(DMS)
Bajo (lapso de mantenimiento largo): exportación/importación de BACPAC

de SQL Server Management Studio
Para las cargas de trabajo críticas, que deben permanecer en línea y disponibles, el uso de tecnologías de
replicación transaccional puede copiar la mayoría de los datos en Azure en segundo plano y, luego, mantener los
datos de destino en el paso con los datos de origen hasta que se produzca un cambio. SQL Server Management
Studio se puede utilizar para establecer este proceso de copia.
Para las aplicaciones importantes que pueden permitirse algún tiempo de inactividad, el servicio de migración
de base de datos de Azure debe utilizarse para realizar la evaluación inicial y migrar los datos de una manera
coherente y correcta.
Por último, SQL Server Management Studio se puede utilizar para exportar los datos y el esquema de una base
en forma de un archivo BACPAC. Para las bases de datos más grandes, el tiempo que lleva exportar e importar el
BACPAC puede ser considerable, por lo que este método es más adecuado para cargas de trabajo de baja prioridad
con grandes lapsos de mantenimiento disponibles.
5.9 Ejemplos de selección de plataforma de destino
En esta sección, veremos cuatro ejemplos de cargas de trabajo y requisitos de los clientes, y decidiremos cuál es la
plataforma de destino adecuada y qué método de migración usar.
Ejemplo 1: base de datos única de Azure SQL Database

El cliente tiene una aplicación que utiliza una instalación de SQL Server 2008 R2 local. Esta aplicación es importante
para negocios que abren permanentemente y que se ven afectados por cualquier tiempo de inactividad durante el
año. Este estricto requisito operacional ha implicado que no haya lapsos de mantenimiento programados disponibles y
que el mantenimiento no programado sea inaceptable. Para facilitar esto, la infraestructura subyacente está diseñada
para una alta disponibilidad con redundancia total en todos los componentes. La base de datos real tiene un
crecimiento mínimo por año, pero una tasa de transacción extremadamente alta que exige cantidades considerables
de recursos informáticos junto con almacenamiento y redes de baja latencia/alto rendimiento. Los requisitos de
redundancia de todos los componentes significan que hay una gran cantidad de SQL Servers, máquinas virtuales,
almacenamiento y redes para mantener ocupados a los DBA y a los administradores de sistemas durante bastante
tiempo, el cual sería mejor que gasten para mejorar el rendimiento y la seguridad de la aplicación.
Solución:
En este escenario, la utilización de la plataforma de oferta de servicio completamente administrada de Azure SQL
Database sería provechosa, ya que elimina el problema de la administración de los requisitos de proceso y
almacenamiento. Con Azure SQL Database, que incluye la alta disponibilidad local como estándar para un SLA
de tiempo de actividad del 99,99 %, y la posibilidad de utilizar réplicas localizadas geográficamente para la alta
disponibilidad regional y para la recuperación ante desastres, los requisitos de tiempo de actividad elevados deben
cumplirse fácilmente. El nivel de rendimiento premium de Azure SQL Database es capaz de latencia de I/O de 2 ms
con un rendimiento de I/O medido en aproximadamente 48 IOPS por DTU, un nivel de rendimiento a la par con los
dispositivos de almacenamiento SAN basados en flash empresariales.
La falta de un lapso de mantenimiento permitido significa que no sería posible migrar las bases de datos locales a
Azure SQL Database mediante una técnica de copia de seguridad y de restauración debido al gran tamaño de los
datos implicados. Llevaría demasiado tiempo copiar los archivos de copia de seguridad por medio de la conexión
WAN. En su lugar, la replicación transaccional se utilizaría para sincronizar los datos en segundo plano y, al mismo
tiempo, mantener la base de datos de origen en línea y disponible.
Migrar a Azure SQL Database ahorraría costos en la sobrecarga de hardware y de administración al eliminar la
necesidad de supervisar, revisar y corregir la gran cantidad de servidores de la solución local.
La aplicación también se beneficiaría de la optimización y supervisión inteligentes integradas de Azure SQL

Database. Azure SQL Database Advisor puede hacer recomendaciones de los índices que faltan que se deben
agregar o de los índices no utilizados que se podrían quitar, para mejorar de forma proactiva el rendimiento de la
aplicación. Azure SQL Database Intelligent Insights analiza el rendimiento de SQL Database mediante la
comparación de la carga de trabajo de la base de datos actual con una línea base histórica para resaltar las
degradaciones de rendimiento y sus posibles causas. La detección de amenazas se puede utilizar mediante Azure
Security Center para detectar y responder a las posibles amenazas a medida que se producen.
Empelo 2: grupos elásticos de Azure SQL Database

El cliente tiene una aplicación que utiliza muchas bases de datos que residen actualmente en una versión local de
Microsoft SQL Server 2008. La huella total de la base de datos es grande y crece rápidamente en varios terabytes al
año. El actual almacenamiento de SAN en el que se ubican las bases de datos está casi al limite de su capacidad, su
expansión es costosa y se aproxima al final de su vida útil. La aplicación es importante para la empresa, con una tasa
de transacción moderada, y cualquier tiempo de inactividad tendría una repercusión comercial importante. Existen
pequeños intervalos de mantenimiento en los que se pueden realizar cambios para maximizar la disponibilidad de
la aplicación. La alta tasa de crecimiento muestra que los DBA y los administradores de sistemas pasan cada vez
más tiempo manteniendo todo en funcionamiento.
Solución:
En este escenario, la utilización de la plataforma de oferta de servicio completamente administrada de Azure SQL
Database sería provechosa, ya que elimina el problema de administrar los requisitos de almacenamiento
y de recursos informáticos, que se encuentran en constante aumento. Microsoft Operations administra el
aprovisionamiento de almacenamiento y proceso en los centros de datos de Azure. Además, el aumento de
recursos para las Azure SQL Databases se convierte en una tarea sencilla en el Portal de Azure. Esto conduce a
ahorrar considerablemente tanto en costos de hardware como en horas de trabajo. Además, permite liberar a los
DBA y a los administradores de sistemas a fin de agregar más valor al negocio en otras áreas.
Al elegir la opción de grupos elásticos de Azure SQL Database, los recursos asignados se pueden compartir
entre todas las bases de datos con la idea de que no todas las bases de datos requerirán el máximo de recursos
asignados en un momento dado. Esto puede producir considerables ahorros de costos, ya que se necesita una
cantidad total de recursos mucho más baja para dar servicio a todas las bases de datos del grupo. También significa
que, a medida que la carga de trabajo crece, se pueden agregar más recursos al grupo elástico. Esto beneficia a
todas las bases de datos que utilizan el grupo, lo que mejora considerablemente la escalabilidad de las aplicaciones
de consumo. Además, se puede implementar el particionamiento para extender fragmentos de la base de datos
a fin de ayudar a permanecer bajo la limitación de 4 TB.
Un pequeño intervalo de mantenimiento implica que se pueden usar los servicios de migración de base de datos
(DMS) en Azure, ya que el intervalo de tiempo de inactividad es mínimo. Varias bases de datos se pueden migrar
simultáneamente durante las horas de mantenimiento, ya que varios trabajos programados se ejecutan
conjuntamente en un concentrador centralizado.
Ejemplo 3: instancia administrada de Azure SQL

El cliente tiene una aplicación personalizada basada en una instancia de SQL Server local que contiene datos
confidenciales relacionados con la propiedad intelectual. El código de aplicación ha tenido algunas prácticas de
desarrollo excéntricas utilizadas en el pasado, lo que ha causado problemas de compatibilidad a lo largo de los
años durante las actualizaciones de SQL Server 2000 a 2005, 2008 y, finalmente, 2012. Cualquier cambio realizado
en esta aplicación es costoso debido a que siempre se ha encargado del trabajo de desarrollo un equipo de
desarrollo de terceros. La aplicación también realiza muchas consultas entre bases de datos a efectos de presentar
informes y de realizar análisis.
Una interrupción programada de la aplicación tendría un impacto de nivel medio en el negocio, pero sería
aceptable con alguna planificación a futuro. Al haber fallas frecuentes debido a la falta de espacio libre en disco o a
procesos de agente de copia de seguridad bloqueados, el cliente no está convencido de que su solución de copia
de seguridad y de recuperación actual sea fiable. El cliente desea quitarse los dolores de cabeza que implican estas
tareas operativas, como realizar copias de seguridad, parches y actualizaciones de versiones.
El cliente también ha escuchado que la naturaleza multiinquilino de los servicios basados en la nube implica que los
usuarios tendrán que recordar otro conjunto de credenciales de usuario. Esto podría provocar una sobrecarga extra
para los usuarios.
Solución:
La plataforma preferida de bases de datos únicas de Azure SQL Database aún no admite todas las características y los
niveles de compatibilidad que admitiría un SQL Server local tradicional. Por ejemplo, una de las características de las
que carece es la capacidad para realizar consultas entre bases de datos, algo que el cliente ha señalado que necesita.
En lugar de tener que volver a diseñar la aplicación para que se adapte a una solución que será costosa y que
consumirá mucho tiempo, se puede utilizar la instancia administrada de Azure SQL Database para ofrecer un alto
nivel de compatibilidad con SQL Server local, mientras sigue disfrutando de muchos de los beneficios de la nube.
Para migrar, se puede realizar una copia de seguridad nativa de SQL de las bases de datos de SQL Server locales,
cargarla en almacenamiento de Azure BLOB y restaurarla directamente en la instancia administrada de Azure SQL
Database.
Una vez en la instancia administrada de Azure SQL Database, la copia de seguridad integrada y automatizada, y las
funcionalidades de restauración en un momento dado pueden acabar con los dolores de cabeza que provoca tener
que garantizar una protección de datos fiable, pero la retención y la recuperación de copias de seguridad
configurables por el cliente implica que todavía tienen control cuando es necesario.
Para promover su protección de datos, la compatibilidad nativa de cifrado de la instancia administrada de Azure
SQL Database implica que los datos de propiedad intelectual valiosos se puedan proteger mediante datos cifrados
en tránsito y en reposo mediante claves de cifrado que brinda el cliente.
El ahorro de costos se puede realizar en áreas de administración y mantenimiento de servidores, sin revisiones ni
actualizaciones de versiones, para que los administradores puedan cumplir tareas de mayor prioridad. Se podrían
realizar ahorros extras al traer sus propias licencias de SQL con Software Assurance activo mediante el beneficio
híbrido de Azure para SQL Server.
Por último, al sincronizar su Active Directory local con Azure Active Directory mediante la herramienta gratuita de
sincronización de directorios de Microsoft AADConnect, es posible proporcionar una experiencia de sesión única, de
modo que las bases de datos de la instancia administrada de Azure SQL Database se puedan acceder con credenciales
de usuario de Windows, sin que se muestren otros mensajes de inicio de sesión. Las instancias administradas también
respetan los estándares de cumplimiento disponibles para Azure SQL Server, para que los clientes no necesiten
mantener una gran cantidad de gastos administrativos a fin de mantenerse al tanto de los nuevos estándares.
Ejemplo 4: SQL Server en infraestructura de Azure como servicio (IaaS)

En este ejemplo, nuestro cliente tiene una aplicación personalizada que utiliza la característica FileStream en SQL
Server para almacenar archivos de sonido grandes en el disco, los cuales tienen volver a leerse a altas velocidades.
Varias herramientas de terceros, que deben instalarse localmente, se integran con esta instancia de SQL Server para
proporcionar un procesamiento avanzado de los metadatos relacionados. Los proveedores de estas herramientas
todavía tienen que producir una versión que funcione con Azure SQL Database.
Solución
Lamentablemente, el requisito para la característica FileStream descarta Azure SQL Database, ya que esta
plataforma aún no la admite. Además, la necesidad de instalar las herramientas de terceros localmente en el SQL
Server descarta la instancia administrada de Azure SQL Database, mientras que la instancia completa de SQL Server
se expone al usuario final en la instancia administrada, pero el sistema operativo subyacente no lo hace.
Por lo tanto, en este ejemplo, la solución debe usar SQL Server en las VM de Azure (IaaS), que ofrece un entorno
virtual personalizado para ejecutar SQL Server e incluye derechos administrativos completos para permitir la
instalación de herramientas de terceros. Se pueden utilizar las especificaciones completas de SQL Server: la
compatibilidad con hasta 64 TB de almacenamiento, todas las bases de datos por instancia que sean necesarias,
la replicación transaccional de SQL Server, los grupos de disponibilidad de AlwaysOn, los servicios de integración,
la trasvase de registros para replicar datos y las copias de seguridad nativas de SQL Server.
La caída del uso de SQL Server en VM de Azure en Azure SQL Database se debe a que todavía existen muchos costos
de mantenimiento y de administración del servidor, al igual que la necesidad de configurar y administrar manualmente
la alta disponibilidad, la recuperación ante desastres y la aplicación de parches. Esto crea más sobrecarga administrativa.
Para migrar, Azure Site Recovery podría utilizarse para levantar y desplazar el SQL Server existente al centro de
datos de Azure. Esto produce una réplica exacta del servidor, llena de herramientas de terceros ya instaladas y
configuradas que ahorran tiempo y reducen el riesgo de errores cuando se instalan desde cero. Los datos del
servidor se sincronizan con Azure en segundo plano mientras el servidor local permanece en línea y está disponible
para las solicitudes de servicio, con una interrupción mínima necesaria para conmutar por error la imagen del
servidor completamente sincronizada en un momento acordado.
5.10 Resumen del ejemplo: selección de la plataforma de destino
En las siguientes tablas, se resumen los escenarios de los ejemplos anteriores donde cada una de las plataformas
de destino es adecuada.
Común en las plataformas de Azure SQL:
Plataforma de destino Indicadores que buscar Ventajas
Base de datos única de Problemas actuales de Las capas de proceso y almacenamiento se

Azure SQL Database capacidad o gestión proporcionan y administran por usted
Grupos elásticos de Exige alta disponibilidad Capacidad casi ilimitada disponible a petición
Azure SQL Database
Nivel premium disponible para cumplir con los
Instancias requisitos más altos de capacidad y rendimiento
administradas de Azure
Altamente disponible como estándar
SQL Database
Opciones disponibles para la protección regional de
alta disponibilidad y recuperación ante desastres
Azure administra copias de seguridad, actualizaciones
y parches
Azure proporciona análisis automatizados y
recomendaciones para los eventos de rendimiento
y seguridad.
Compatibilidad con el cifrado de datos
Compatibilidad con el registro único con Azure AAD
Específico para cada plataforma:
Plataforma de destino Indicadores que buscar Ventajas exclusivas
Base de datos única de Pequeña cantidad de bases El costo más bajo para bases de datos
Azure SQL Database de datos o muchas bases de individuales
datos, pero todas con mucho
uso constante
Grupos elásticos de Muchas bases de datos Rentable, ya que los recursos agrupados se
Azure SQL Database o implementaciones comparten entre varias bases de datos
de multiinquilinos
Instancias No se posee el código de la Servicio totalmente administrado, mientras se

administradas de Azure aplicación, o es costoso de conserva un alto nivel de compatibilidad con
SQL Database modificar SQL Server
Requiere un alto nivel de Admite características de SQL, tales como las
compatibilidad consultas entre bases de datos, que no están
disponibles en Azure SQL Database
Utiliza las características de
SQL Server que aún no son
compatibles con Azure SQL
Databases
SQL Server en Uso de las características de Totalmente compatible con SQL Server local
infraestructura de SQL Server que aún no son
Aplicaciones de terceros y complementos
Azure como servicio compatibles con Azure SQL
altamente propensos a funcionar como se
Databases
encuentran
Herramientas de terceros
Acceso completo al sistema operativo subyacente
instaladas localmente en SQL
para instalar herramientas y servicios de terceros
Server
5.11 Ejemplo de Resumen: selección de herramientas de migración
En las siguientes tablas, se resumen los escenarios de los ejemplos anteriores donde cada una de las herramientas
de migración es adecuada.
Herramienta de
Indicadores que buscar Ventajas exclusivas
migración
Replicación Base de datos importante Requisitos de interrupción más pequeña posible
transaccional con un intervalo de para el cambio, ya que la base de datos de
mantenimiento pequeño origen permanece en línea y atendiendo
o inexistente solicitudes durante la sincronización de datos
Bases de datos grandes
(>1 TB)
Azure Database Muchas bases de datos para Admite la migración simultánea de varias bases
Migration Service (DMS) migrar con un permiso de de datos
intervalo de mantenimiento
moderado
Bases de datos grandes
(>1 TB)
Exportación/importación Pequeña cantidad de bases Rápido y fácil sin necesidad de configuración real
BACPAC de datos ad hoc que migrar
Bases de datos de tamaño
pequeño a mediano (<1 TB)
Requisitos de baja
disponibilidad con intervalos
de mantenimiento relajados
Azure Site Recovery SQL Server existente para Levanta y desplaza una réplica exacta del
migrar tal cual a Azure servidor a la VM de IaaS de Azure
El servidor de origen permanece en línea y
atiende las solicitudes durante la sincronización
de datos del servidor
6 TRANSFORMACIÓN Y OPTIMIZACIÓN
Ahora, con una idea sólida de qué se migra, adónde se migra y cómo se logrará, el siguiente paso es transformar
y optimizar, y realizar los cambios necesarios en el entorno de origen para prepararse para la próxima fase de
migración. Después de completar la fase de transformación y optimización, tendremos lo siguiente:
Esquema compatible con la plataforma de destino

El esquema de base de datos estará en un estado de compatibilidad con la plataforma de destino y listo para
migrar
Preparativos completos para la migración de datos

Todos los errores se rectificarán, y los datos están listos para migrar.
Durante el resto de esta sección, investigaremos cómo transformar los datos de origen o los mecanismos utilizados
para solucionar cualquier problema e investigar posibles optimizaciones que se pueden realizar para aprovechar al
máximo la plataforma de Azure SQL.
Transformación y optimización Página 45 de 62

6.1 Transformación
En condiciones ideales, la migración de datos de entornos locales a la nube simplemente funcionaría, pero es muy
posible que se deban cambiar algunas cosas para garantizar una migración funcional y exitosa. Las áreas para
enfocar los cambios necesarios serían las siguientes:
Actualización y comprobación de los esquemas de base de datos

Las conclusiones de las tareas de evaluación anteriores deberían haber resaltado los cambios que se debían realizar
en el esquema de la base de datos, y estas modificaciones deberían implementarse en esta etapa.
Implementación de los requisitos de actualización de versión para el entorno

El origen de SQL Server debe estar normalmente en, al menos, SQL Server 2005 o superior para usar las herramientas
de migración que proporciona Microsoft, tales como Azure Database Migration Service (Azure DMS) y Data Migration
Assistant (DMA). Si el SQL Server de origen no cumple con este requisito mínimo, será necesario incluir una
actualización antes de que se puedan usar estas herramientas de migración para facilitar el resto de la migración.
Corrección de los errores o advertencias proporcionados por las herramientas de evaluación de la migración
Algunas características se deben complementar o quitar debido a no estar disponibles en Azure SQL Database, se
incluyen el uso de referencias entre bases de datos, el agente de servicio, el trasvase de registros o los servidores
vinculados. La sintaxis SQL en desuso podría necesitar actualizarse o reescribirse para cumplir con la versión
requerida de SQL en Azure SQL Database.
Migración de los servicios de base de datos integrados existentes en Azure

Como hemos descubierto anteriormente, Azure todavía no tiene un servicio de nube comparable similar para SSIS o
SSRS. Estas cargas de trabajo requerirán la implementación de nuevos servicios de Azure que puedan admitir
parcialmente las cargas de trabajo requeridas, mantener las cargas de trabajo locales o implementarlas en máquinas
virtuales.
Gestión de cargas de trabajo SSIS en la nube

Las razones por las que es posible que desee migrar las cargas de trabajo de SSIS locales a Azure pueden reducir
los costos operativos y disminuir la carga de administrar la infraestructura que puede ejecutar SSIS en entornos
locales o en máquinas virtuales de Azure. Se puede aumentar la alta disponibilidad especificando varios nodos por
clúster o usando la característica de alta disponibilidad en Azure SQL Database. Por último, puede aumentar la
escalabilidad con la capacidad de especificar varios núcleos por nodo (escalado horizontal) y varios nodos por
clúster (escalado horizontal).
Ligeramente diferente a SSIS local, donde el tiempo de ejecución de SSIS está hospedado en SQL Server. En Azure,
en cambio, Azure Data Factory hospeda el motor en tiempo de ejecución para los paquetes SSIS. El motor en
tiempo de ejecución se denomina Azure SSIS Integration Runtime (SSIS IR). La base de datos de catálogo de SSIS
que utiliza SSIS (denominada SSISDB) se aprovisiona en Azure SQL Database, que debe implementarse en la misma
región de Azure que SSIS IR.
La creación de Azure Data Factory se logra fácilmente en el Portal de Azure o en PowerShell. El tiempo de ejecución
de integración necesario de Azure SSIS se puede crear y comenzar, lo que lo prepara para el servicio de paquetes
SSIS. Para implementar paquetes SSIS en Azure, puede usar SQL Server Data Tools (SSDT) o SQL Server
Management Studio (SSMS), que se conecta a Azure SQL Server que hospeda el catálogo de SSIS (SSISDB).

SSIS también se puede utilizar para migrar datos de entornos locales a Azure. En este caso, Azure Data Factory
hospeda de nuevo el tiempo de ejecución de integración de Azure SSIS. Un conjunto de ejemplo de pasos para la
implementación de un mecanismo de migración de datos mediante paquetes SSIS podría ser similar a lo siguiente:
 Crear un Azure Data Factory

 Crear un Azure-SSIS Integration Runtime (SSIS IR)
 Crear servicios vinculados de SQL Server y Azure Storage
 Crear conjuntos de datos de SQL Server y Azure BLOB
 Crear Azure SQL Table
 Crear un proceso con una actividad de copia para migrar datos
 Iniciar una ejecución de procesos
 Supervisar la ejecución de procesos
 Prueba de finalización
6.2 Optimización
La optimización puede constar de los siguientes pasos:
Evaluación de cuáles son las nuevas características que pueden estar disponibles en la plataforma de
destino
Las nuevas características que antes eran demasiado complejas o que suponían un costo
mínimo para justificar la implementación local ahora pueden estar disponibles haciendo
algunos clics en el Portal de Azure. Estas características deberían tenerse en cuenta en el
caso de que aporten ventajas para cada carga de trabajo y luego deberían implementarse
según corresponda.
Reestructurar las cargas de trabajo en conjuntos más rentables o eficaces en términos de rendimiento
Esto puede incluir la asignación de bases de datos que componen una carga de trabajo a varios niveles de servicio
y de rendimiento en Azure SQL Database. Estos se agrupaban anteriormente en el mismo SQL Server local debido
a los costos de hardware y licencias, pero con la oferta de servicio completamente administrada de Azure SQL
Database ahora es rentable conceder recursos adicionales a las bases de datos individuales, en el caso de que sea
beneficioso.

Garantizar que las cargas de trabajo tengan el tamaño correcto
Busque realinear las cargas de trabajo en los niveles de servicio y de rendimiento más apropiados. Anteriormente
compartían un grupo combinado de recursos informáticos y de almacenamiento en el servidor físico donde
residían, que se usaba poco para permitir que crezca más adelante. Ahora, con la oferta de servicio completamente
administrada de Azure SQL Database, es posible obtener un tamaño más preciso de las bases de datos mediante el
uso de herramientas, tales como la Azure SQL Database DTU o la comparación de los requisitos básicos locales con
los vCores y el aumento de los recursos asignados solo si es necesario.
La siguiente lista contiene recomendaciones para lograr un mejor rendimiento durante el proceso de importación:
Elija el nivel de servicio y de rendimiento más alto que su presupuesto le permita para el tiempo de migración
a fin de maximizar el rendimiento de la transferencia.
Durante la migración, la base de datos realizará una enorme cantidad de operaciones de escritura, y, al dimensionar
el nivel de rendimiento seleccionado, puede limitar involuntariamente el rendimiento, lo cual provocará una línea de
tiempo de migración muy extensa. En su lugar, elija un nivel de rendimiento superior al necesario temporalmente
durante la migración y luego reduzca la escala después de la migración para minimizar los costos.
Reducir la distancia entre el archivo BACPAC y el centro de datos de destino

Al reducir la distancia física entre el archivo BACPAC y el centro de datos de destino, se reducirá la latencia de la
red. Esto, a su vez, aumentará el rendimiento general de la migración, ya que se podrán completar más operaciones
de lectura y escritura en la base de datos de destino en el mismo período.
Deshabilitar las estadísticas automáticas durante la migración

En Azure SQL Database, los objetos de estadísticas tienen activada la opción “actualización automática” de forma
predeterminada. La actualización automática de las estadísticas se realiza cuando se ha producido una cantidad
suficiente de cambios en una tabla. Durante el proceso de importación, cuando casi todas las filas de todas las tablas
están cambiando, este desencadenador se cumple repetidamente, lo que provoca continuos intentos de actualizar las
estadísticas. Esta actualización utiliza recursos de I/O valiosos para completar, que se desvían del grupo global de
recursos de I/O disponibles para el proceso de importación y amplían la línea de tiempo de migración.
Tablas de partición e índices

Las tablas de partición y los índices pueden ayudar con la transferencia y el acceso de los datos durante una migración.
Los datos se pueden dividir en uno o más subconjuntos que sean similares y que permitirán que la transferencia de
datos sea más rápida. La partición de conjuntos de datos grandes también puede reducir la contención de bloqueos,
ya que el escalado de bloqueos se puede activar en el nivel de partición sin dañar todo el conjunto de datos. Una vez
que los datos se migren a la nube, las consultas pueden tener un rendimiento más rápido y reducir los costos
generales de las aplicaciones. Las tablas de partición y los índices generales ayudan al costo de la migración y mitigan
el riesgo posterior a la migración al contribuir con el aumento del rendimiento de los datos.
Eliminar y volver a crear las vistas indexadas una vez que estén listas
Cuando se utiliza una vista indexada, cada vez que se modifican los datos en una tabla subyacente, Azure SQL
mantiene las entradas de índice en esas tablas, pero también mantiene las entradas de índice de la vista. Esto puede
afectar al rendimiento de escritura y volver a reducir los recursos de I/O disponibles para el proceso de importación,
lo que amplía la escala de tiempo de migración. Además, también tienen el potencial de causar otros problemas,
como contenciones de bloqueo.

Quite los datos históricos consultados con poca frecuencia a otra base de datos y mígrelos a una Azure SQL
Database aparte. A continuación, puede consultar estos datos históricos mediante consultas elásticas.
Al purgar los datos históricos de una base de datos, el tamaño de la base de datos y, por lo tanto, la cantidad
de información que se necesita migrar se pueden reducir radicalmente. Esto ayuda a cumplir con los objetivos de
intervalos ajustados de mantenimiento, ya que los datos principales se pueden migrar a Azure SQL en un tiempo
mucho más corto, lo que permite que la aplicación vuelva a estar en línea antes. Los datos históricos que se
consultan con poca frecuencia se pueden migrar en un período menos agresivo dado que es una prioridad mucho
menor.

7 MIGRACIÓN, VALIDACIÓN Y REPARACIÓN
Pasamos a la etapa final: la migración de datos. Las etapas anteriores de planificación, evaluación y
transformaciones se han asegurado de que todo esté listo para migrarse y funcionar correctamente en Azure.
Por eso, todo lo que queda por hacer es preparar las herramientas de migración necesarias, realizar la migración
y ejecutar validaciones funcionales y de rendimiento posteriores a la migración.
Migración, validación y reparación Página 50 de 62

7.1 Información general sobre la migración
Tener en cuenta los intervalos de mantenimiento que están disponibles para la aplicación y la base de datos
destinadas a la migración
Si son cargas de trabajo importantes, es posible que solo puedan estar sin conexión durante unos minutos en un
momento muy específico. Por otra parte, una carga de trabajo se puede utilizar a efectos de presentar informes
históricos. Además, se puede desconectar fácilmente la mayoría de los días de la semana sin afectar a los usuarios
finales. Estas diferencias ayudarán a decidir qué técnica de migración debe utilizarse.
Comenzar primero con bases de datos de baja prioridad
Esto puede ayudar a garantizar que el proceso de migración funcione y a medir el tiempo que es probable que la
migración demore cuando llegue a las cargas de trabajo más importantes.
Solucionar problemas de compatibilidad descritos en Data Migration Assistant
Estos problemas deben solucionarse durante la fase de transformación y optimización. Sin embargo, validan que
DMA ya no presenta problemas restantes.
Ejecutar una migración de prueba con la herramienta elegida
Antes de migrar la base de datos, ejecute una migración de prueba de
la base de datos para corroborar la cantidad de tiempo que demorará la
migración y si detectaron problemas durante el proceso de migración.
Prueba de la base de datos para la detección de problemas
Cuando finalice la migración de prueba, realice los pasos de validación
para confirmar que los datos se migren en su totalidad y compruebe si
se detectaron problemas en la plataforma de Azure SQL.
Repetir correcciones de problemas hasta que se arregle la base de
datos
Para cada problema detectado durante las pruebas, busque una corrección y luego vuelva a probar. Siga repitiendo
este ciclo de corrección de pruebas hasta que se hayan encontrado y reparado todos los problemas.
Volver a escribir aplicaciones de terceros para la nube según corresponda
Las aplicaciones de terceros pueden sacar provecho de la Guía de arquitectura de aplicaciones de Azure porque
analiza los modelos de arquitectura locales anteriores frente a los de nube que podrían ayudar a optimizar el
rendimiento y a reducir la sobrecarga con enfoques de codificación más delgado. Cada aplicación se debe analizar
caso por caso para ver si se necesita una elevación y cambio, o una reescritura.
Probar aplicaciones de terceros
Confirme que las aplicaciones de terceros seguirán funcionando como se esperaba en la nube a medida que se
migran las aplicaciones, incluidas las dependencias.
Desconectar las bases de datos y las aplicaciones anteriores

Recuerde desconectar la base de datos de origen y la aplicación antes de iniciar el proceso de migración para evitar
la confusión y conservar los datos originales en caso de que se deban consultar, o en caso de que se deban
deshacer los cambios.

Crear nuevos planes de mantenimiento y de recuperación ante desastres
Tómese el tiempo para actualizar sus planes de recuperación ante desastres, ya que los datos ahora se han
cambiado de ubicación y se los accede de una manera diferente. Piense en la posibilidad de mejorar los planes de
recuperación ante desastres mediante la utilización de las características de replicación geográfica de Azure para
proteger los datos que anteriormente podrían haber sido demasiado complejos o costosos de proteger de forma
local. Los planes de mantenimiento también se deberán revisar, ya que Azure ahora realiza muchas de esas tareas
de mantenimiento automáticamente en segundo plano, y se elimina la necesidad de realizarlas manualmente.
Utilizar conjuntos de herramientas para obtener mayor información sobre su entorno y ayudar
considerablemente con el proceso de migración
Existen muchas herramientas de Microsoft y de terceros que pueden ayudar a mantener las pestañas de los
entornos de SQL tanto locales como en la nube, por ejemplo:
 Azure Database Migration Service (DMS) ayuda a realizar un seguimiento del progreso de las migraciones
a gran escala de datos a Azure.
 Microsoft Operations Management Suite puede ayudar a supervisar y a visualizar las cargas de trabajo de SQL
tanto locales como en la nube. Esto incluye el recuento de versiones de SQL Server, el rendimiento actual de la
CPU, los errores y los éxitos de los trabajos, y los eventos registrados.
 Azure SQL Database Intelligent Insights es una herramienta que utiliza inteligencia integrada para supervisar
continuamente el uso de la base de datos y detectar eventos disruptivos que provocan un rendimiento
deficiente. Además, ofrece recomendaciones para mejoras que podrían ayudar con la funcionalidad.
Evaluar las herramientas de migración en función de las interrupciones para reducir el riesgo de inactividad de la
base de datos
En las próximas secciones, veremos qué herramientas de migración requieren tiempo de inactividad para completar la
migración y cuáles pueden funcionar en segundo plano mientras la carga de trabajo permanece en línea y disponible.
Conocer los requisitos de carga de trabajo desde el comienzo
Los requisitos pueden incluir el tamaño de almacenamiento, el rendimiento de almacenamiento y la alta disponibilidad.
Crear un plan para mitigar el riesgo asociado con los problemas de tiempo de inactividad y compatibilidad
Muchos de los puntos discutidos en este documento técnico ayudarán a reducir el riesgo de errores durante la
migración. Realice migraciones de prueba antes de realizar la migración final mediante el conocimiento de los errores
antes de llegar a cargas de trabajo más importantes y tenga un plan de reversión preparado en caso de una emergencia.
Conocer la paridad de características entre las versiones de SQL Server y utilice las herramientas de evaluación
para mitigar la elección de la opción de destino equivocada
Las herramientas como Data Migration Assistant (DMA) ayudarán a determinar si la carga de trabajo de origen está
utilizando características que no están disponibles en algunas plataformas de Azure.
Para la migración, seleccionar primero las cargas de trabajo que no son importantes
Esto puede ayudar a garantizar que el proceso de migración funcione y a medir el tiempo que es probable que la
migración demore cuando llegue a las cargas de trabajo más importantes.
Repetir continuamente el proceso de migración
Durante las primeras migraciones se van a encontrar pequeños cambios, se tendrán que crear la documentación
o los procesos, o se deberán quitar los pasos de migración innecesarios. Estos hallazgos se deben volver a aplicar
al proceso de migración que está siguiendo para optimizar las migraciones de mayor prioridad restantes.

7.2 Selección de herramientas de migración
Las herramientas de migración empleadas para migrar datos a Azure se seleccionarán en función de la importancia
de la carga de trabajo y del tiempo que la aplicación puede estar sin conexión durante el cambio.
Aquí hay un flujo de trabajo simple que puede ayudar con la selección de herramientas:
Para cargas de trabajo importantes, que no pueden permitirse un tiempo de inactividad de la base de datos, se
debe usar SQL Server Transactional Replication para sincronizar todos los datos entre entornos locales y Azure
mientras se mantiene la base de datos de origen en línea y se atienden las solicitudes. Para cargas de trabajo
generales, donde se aceptan pequeñas cantidades de tiempo de inactividad, puede usarse Azure Data Migration
Service para administrar el proceso de migración de todas estas bases de datos. Para todas las demás cargas de
trabajo que se pueden desconectar a una hora programada, una buena opción sería exportar un archivo BACPAC
que contenga los datos y el esquema de la base de datos de origen e importarlo en Azure.
Se pueden utilizar distintas herramientas para diversas necesidades, y no se debe utilizar una sola herramienta para
todas las migraciones de base de datos. Investigaremos más a fondo cada uno de estas en las siguientes secciones.
Migración mediante SQL Server Transactional Replication
La replicación transaccional migra gradualmente una base de datos de SQL Server a la nube, al mismo tiempo que deja
los servidores de producción en línea y crea transacciones. A medida que se crean nuevas transacciones en el origen,
estas también se migran a la base de datos de destino, y se mantiene el origen y el destino en el paso de bloqueo. Esta
técnica permite un alto nivel de disponibilidad, ya que el único tiempo de inactividad implicado se va a cambiar sobre
la aplicación para que apunte a Azure SQL Database que se acaba de migrar. Es adecuada sobre todo para escenarios
híbridos donde se desea una migración gradual o parcial, en lugar de una migración masiva de todos los datos.
La replicación transaccional se puede configurar mediante instrucciones de SQL Server Management Studio (SSMS)
o T-SQL, con Azure SQL Database configurada como suscriptor de inserción del publicador de SQL Server de
origen. La base de datos de distribución y los agentes de replicación exigidos no se pueden colocar en la base
de datos SQL que se está migrando.
Se admite la replicación transaccional instantánea y unidireccional, pero no se admite la replicación transaccional
de punto a punto y la replicación de mezcla.
Para utilizar este método, la base de datos de origen debe cumplir los requisitos para la replicación transaccional
y ser compatible con Azure SQL Database. Todas las versiones de SQL Server de SQL Server 2012 y posteriores son
compatibles para usarse en una configuración de replicación transaccional, pero podrían requerir un determinado
Service Pack y una actualización acumulativa instalada antes de que se puedan utilizar.

Los orígenes de SQL Server admitidos con la replicación transaccional son los siguientes:
 SQL Server 2016 RTM

 SQL Server 2014 SP1 CU3
 SQL Server 2014 RTM CU10
 SQL Server 2012 SP2 CU8
Para utilizar esta solución, configure su Azure SQL Database como suscriptor de la instancia de SQL Server
que desea migrar. El distribuidor de duplicación transaccional sincroniza los datos de la base de datos que se
sincronizarán (el publicador) mientras se siguen produciendo nuevas transacciones.
Figura 20: replicación transaccional con SQL Server
Con la replicación transaccional, todos los cambios realizados en los datos o en el esquema se muestran en Azure
SQL Database. Una vez que finalice la sincronización y que los datos están listos para el cambio, cambie la cadena
de conexión de las aplicaciones para que apunte a Azure SQL Database y publique la aplicación en producción.
A medida que la replicación transaccional finaliza los cambios que quedan en la base de datos de origen y todas las
aplicaciones apuntan a la nueva Azure SQL Database, puede desinstalar la replicación transaccional.
Migración mediante Azure Data Migration Service (DMS)

Azure Data Migration Service es un servicio de migración totalmente administrado ideado para permitir migraciones
sin interrupciones de varios orígenes de base de datos a plataformas de datos de Azure con un tiempo de
inactividad mínimo. Para lograrlo, Azure DMS combina varios motores de migración de Microsoft, como Data
Migration Assistant (DMA), Database Experimentation Assistant (DEA) y SQL Server Migration Assistant (SSMA)
para abarcar una amplia gama de escenarios.

Se tiene acceso a Azure DMS en el Portal de Azure (https://portal.azure.com) donde se puede crear una instancia de
Azure DMS a partir de distintas regiones con una variedad de opciones de vCore disponibles. Al asignar más vCores
al servicio, puede proporcionar migraciones más rápidas para cumplir con la línea de tiempo prevista, pero a
expensas de un costo extra.
Figura 21: creación de Azure Database Migration Service
Azure DMS admite la migración a todas las opciones de servicio de Azure SQL Database (instancia única, elástica
y administrada), así como a SQL Server en una máquina virtual de IaaS de Azure.
Desde allí, es posible crear proyectos que le permitan realizar evaluaciones de origen, esquema, conversión de
datos y actividades de validación que ayudan a preparar el origen para la migración. Las tareas de migración
también se pueden crear fácilmente, como las migraciones y los scripts de automatización de prueba de concepto.
Para obtener más información, consulte https://azure.microsoft.com/es-xl/services/database-migration/

La base de datos de SQL Server debe evaluarse para ver si contiene bloqueadores antes de poder migrar datos de
una instancia de SQL Server local a Azure SQL Database. Database Migration Assistant se utiliza para realizar esta
tarea, como se mostró anteriormente en la sección Evaluación.
Figura 22: revisión de los resultados de la evaluación con DMA

Después de completar la evaluación y de descubrir que la base de datos seleccionada es una buena opción para
la migración a Azure SQL Database, Data Migration Assistant se utiliza para migrar el esquema de base de datos
a Azure SQL Database.
Figura 23: selección de objetos para migrar con DMA
DMA hace esto generando una Secuencia de comandos SQL que se vuelve a reproducir en Azure SQL Database
para establecer el esquema de base de datos y preparar la base de datos de destino para la inserción de datos.

A continuación, se emplea el servicio Azure DMS para migrar los datos a los servicios de datos de Azure.
Figura 24: supervisión del progreso de la migración de datos con DMS
Migración mediante la exportación/importación de aplicaciones de nivel de datos (BACPAC)

SQL Server Management Studio puede exportar un archivo BACPAC que encapsula el esquema de la base de datos,
así como los datos almacenados en una aplicación de base de datos. Esto puede ser útil ya que el archivo BACPAC
se puede importar fácilmente a una Azure SQL Database a fin de proporcionar un medio sencillo para la migración
de datos entre entornos locales y Azure.
Para garantizar que el BACPAC exportado contenga todos los datos en un estado completo y coherente, las cargas
de trabajo que utilicen la base de datos de origen deben desconectarse durante el proceso de exportación, de
modo que las transacciones no se realicen durante la exportación. Esto significa que se requerirán interrupciones
programadas para exportar un archivo BACPAC, lo cual puede necesitar una cantidad significativa de tiempo. Es
posible exportar hasta 200 GB a BLOB Storage, por lo que la migración con archivos BACPAC solo es buena para
bases de datos más pequeñas. Esta limitación puede ser un punto discutible, ya que el tiempo que se toma para
exportar bases de datos más grandes a un archivo BacPac, copiar el archivo BACPAC en Azure BLOB Storage
y luego importar el archivo BACPAC a una base de datos de SQL Azure puede ser significativo, y otras técnicas
de migración serían más adecuadas para reducir el tiempo de inactividad.
Para obtener más información sobre la migración de SQL Server a Azure SQL Database mediante archivos BACPAC,
consulte el siguiente vínculo: https://blogs.msdn.microsoft.com/sqlcat/2016/10/20/migrating-from-sql-server-to-
azure-sql-database-using-bacpac-files/

Para importar un archivo BACPAC a Azure SQL Database
1. Inicie sesión en el portal de administración de Azure en https://portal.azure.com
2. Haga clic en Nuevo > Data Services > SQL Database > Importar. Se abrirá el cuadro de diálogo Importar
base de datos.
3. Vaya al archivo .bacpac para importar: haga clic en Cuenta de almacenamiento > Contenedor > BACPAC
y luego haga clic en Abrir.
4. Determine un nombre para la nueva base de datos SQL. El nombre de la base de datos debe ser único en el
servidor, por lo que no puede ser el mismo que otro SQL Server y debe cumplir con las normas de SQL Server
para los identificadores. Para obtener más información, consulte Identificadores.
5. Especifique los detalles de la suscripción, de la edición, del tamaño máximo y del servidor host. Para
continuar, haga clic en la flecha situada en la parte inferior del cuadro de diálogo.
6. Especifique los detalles de inicio de sesión para el servidor host.
7. Para iniciar la operación de importación, haga clic en la marca de verificación que se encuentra en la parte
inferior del cuadro de diálogo. El portal mostrará información de estado en la cinta de la parte inferior de la
página.
8. Para ver la nueva base de datos, haga clic en SQL Database en el panel de navegación y actualice la página.
Para importar un archivo BACPAC a Azure SQL Database:

https://docs.microsoft.com/es-xl/azure/sql-database/sql-database-import

8 CONCLUSIÓN
La informática en la nube es un paso evolutivo importante para la industria de TI y, si bien las ventajas son
evidentes, el camino para llegar desde el estado de datos local tradicional a uno en la nube ha demostrado hasta
hace poco que es desafiante y consume mucho tiempo. La continua inversión de Microsoft en las herramientas y en
los servicios útiles para las migraciones de datos ha simplificado enormemente el proceso, y ahora es posible migrar
de entornos locales a la nube en plazos mucho más cortos y con mucho menos esfuerzo que antes.
Este documento técnico lo ha guiado por las etapas de descubrimiento de lo que debe migrar y dónde, antes de
pasar a la evaluación de bases de datos preferidas para la migración y la cantidad de trabajo que se necesita para
prepararlas. A continuación, comparamos las posibles opciones de carga de trabajo de destino en Azure y pasamos
por algunos ejemplos de casos de uso de migración de clientes. A continuación, hablamos de cómo adaptar las
cargas de trabajo de Azure y cómo optimizarlas una vez que se migren a la nube. Finalmente, analizamos las
herramientas y los mecanismos disponibles para migrar los datos a la nube, y cuándo usar cada uno.
Sin embargo, debido a la rápida naturaleza cambiante de la nube, consulte los blogs del equipo de Microsoft Docs
y Microsoft, que se mencionan en la sección de recursos a continuación, para conocer los cambios en las herramientas
de migración y las mejores prácticas, ya que Microsoft anuncia cada mes nuevas metodologías o configuraciones
compatibles.
Conclusión Página 60 de 62
9 RECURSOS
Comparaciones de características de Azure SQL Database
Azure SQL DB Instancia administrada de
Características SQL Server en VM de Azure
único/elástico Azure SQL DB
Modelo de negocio
Unidades para precios DTU/eDTU vCore/almacenamiento/IOPS vCPU/almacenamiento
Premium/SSD Sí Sí Sí
Limitación de tamaño 4 TB 8 TB por instancia 500 TB

Incluido o beneficio híbrido
Licencias Incluido Incluido o BYOL
de Azure
Continuidad empresarial/recuperación ante desastres
Alta disponibilidad Integrado Integrado Administrado por el usuario
SLA disponibilidad 99.99% 99.99% 99.9%

Copias de seguridad Opciones disponibles para
Sí Sí
automáticas configurar
Restauración en un momento
Sí Sí No
dado
Retención de copia de
35 días Más de 7 días Depende
seguridad
Replicación geográfica Sí Sí+ Sí, administrado por el usuario
Superficie de SQL Server

Copia de
No Sí Sí
seguridad/restauración nativa
Transacciones entre bases de
Parcialmente Sí Sí
datos
Agente SQL No Sí Sí
Correo de base de datos No Sí Sí
Cifrado TDE/Always Encrypted TDE/Always Encrypted+ Sí
FileStream/filetable No No* Sí
Inteligencia integrada
Ajuste automático Sí Sí+ Parcial (correcciones de plan)
Detección de amenazas Sí Sí+ No

Evaluación de
Sí No* No
vulnerabilidades
Intelligent Insights Sí Sí+ No
+
Antes de la disponibilidad general del servicio
* Para tener en cuenta luego de la disponibilidad general
Recursos Página 61 de 62
Consideraciones económicas
Recurso de orientación de
Componentes Nivel Descripción
costos
Azure SQL Básico Cargas de trabajo no productivas Guía de costos

Database (única)
Estándar Cargas de trabajo moderadas con disponibilidad Guía de costos
moderada
Premium Altas cargas de trabajo de transacciones con Guía de costos

requisitos de alta disponibilidad
Azure SQL Básico Cargas de trabajo no productivas Guía de costos

Database
(Grupos elásticos) Estándar Cargas de trabajo moderadas con disponibilidad Guía de costos
moderada
Premium Altas cargas de trabajo de transacciones con Guía de costos

requisitos de alta disponibilidad
Instancia Uso general Cargas de trabajo moderadas con disponibilidad Guía de costos
administrada de moderada
Azure SQL
Database Crítico a nivel Altas cargas de trabajo de transacciones con Guía de costos
empresarial requisitos de alta disponibilidad
SQL Server en Varía Depende de las consideraciones de tamaño, Guía de costos

IaaS de Azure redundancia y resistencia de la máquina virtual.
Blogs y documentación relacionados con Azure SQL Database

Blog de base de datos de Microsoft
https://azure.microsoft.com/en-us/blog/topics/database/
Blog de Microsoft Azure SQL

https://azure.microsoft.com/en-us/blog/tag/azure-sql-database/
Blog del motor de Microsoft SQL Server Database

https://blogs.msdn.microsoft.com/sqlserverstorageengine/
Blog de migración de base de datos de Microsoft

https://blogs.msdn.microsoft.com/datamigration/
Documentación de Microsoft Azure SQL

https://docs.microsoft.com/es-xl/azure/sql-database/
Documentación de Microsoft Azure Data Migration Assistant

https://docs.microsoft.com/es-xl/sql/dma/dma-overview
Documentación de Microsoft Azure Database Migration Service

https://docs.microsoft.com/es-xl/azure/dms/dms-overview
Documentación de Microsoft SQL Server

https://docs.microsoft.com/es-xl/sql/sql-server/sql-server-technical-documentation
Recursos Página 62 de 62

Choosing Your Database Migration Path To Azure ES-MX

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Choosing Your Database Migration Path To Azure ES-MX

Diunggah oleh

Hak Cipta:

Format Tersedia

Microsoft Corporation

Primer borrador finalizado: marzo de 2018

Autores: Amber Williams, Becky Isserman, Steve Burkett

Revisores: Alain Dormehl, Eric Hudson, RAG Guru, Ajay Jagannathan

MICROSOFT NO REALIZA GARANTÍAS EXPRESAS, IMPLÍCITAS O REGLAMENTARIAS CON RESPECTO A LA

1.1 Público objetivo

1.2 Requisitos previos

1.3 Fuera de alcance

Migración, validación y reparación

Información general Página 5 de 62

El inventario de sus recursos de datos

Dependencias de la base de datos de las aplicaciones

Cuáles son las bases de datos que se mueven juntas

Iniciación y descubrimiento Página 6 de 62

Guía de migración de base de datos

La Guía de migración de base de datos brinda una orientación detallada paso

Más información en https://datamigration.microsoft.com

Microsoft Assessment & Planning (MAP) Toolkit

Data Migration Assistant (DMA)

Más información en https://blogs.msdn.microsoft.com/datamigration/dma/

Iniciación y descubrimiento Página 7 de 62

Se puede acceder a la Guía de migración de base de datos en el sitio web de Microsoft

Figura 1: página de introducción a la Guía de migración de base de datos

Iniciación y descubrimiento Página 8 de 62

Iniciación y descubrimiento Página 9 de 62

Figura 3: descripción general de MAP Toolkit

Iniciación y descubrimiento Página 10 de 62

Figura 4: escenario de base de datos de MAP Toolkit

Iniciación y descubrimiento Página 11 de 62

Iniciación y descubrimiento Página 12 de 62

Iniciación y descubrimiento Página 13 de 62

Descargue MAP Toolkit desde la siguiente URL: https://www.microsoft.com/en-us/download/details.aspx?id=7826

3.3 Herramientas y servicios de Microsoft: Asistente de migración de bases de datos

Iniciación y descubrimiento Página 14 de 62

Figura 9: creación de un nuevo proyecto de evaluación de DMA

Iniciación y descubrimiento Página 15 de 62

Figura 10: evaluación de la compatibilidad de bases de datos con DMA

Iniciación y descubrimiento Página 16 de 62

Iniciación y descubrimiento Página 17 de 62

Uso de migraciones continuas

Figura 11: flujo continuo de trabajo de migraciones con DMA y DMS

Sugerencia: Microsoft se ha asociado con Attunity para proporcionar su producto Attunity

4.2 Evaluación de los criterios de carga de trabajo

Para obtener más información, consulte http://dtucalculator.azurewebsites.net/

¿Qué son los vCores?

Cargas de trabajo personalizadas

Puede acceder a una descripción general de DMA en el siguiente enlace:

Figura 12: flujo de trabajo de evaluación y reparación mediante DMA

1. Descargue DMA y luego instálelo.

Figura 13: creación de un nuevo proyecto de DMA

b. Seleccione uno o ambos tipos de informe de evaluación (Comprobar compatibilidad de la base

Figura 15: conexión al origen para la evaluación de DMA

e. Seleccione Iniciar evaluación.

Figura 17: recomendaciones y resultados de compatibilidad de DMA

Figura 18: resultados y hallazgos de la paridad de características de DMA

DMA también proporciona un conjunto integral de recomendaciones, enfoques alternativos disponibles

3. Revisión de los resultados de la evaluación

Migración de una sola vez en lugar de sincronización continua

 Planificar la plataforma de destino

Figura 19: plataformas disponibles de base de datos de Azure

Azure SQL Database

Grupos elásticos de Azure SQL Database

¿Por qué usar los grupos elásticos de Azure SQL Database?