VENTAS: 1-800-867-1389

Planificar un proyecto de migración de Base de datos SQL de Azure

Actualizado: abril de 2014

En este tema se describen las prácticas recomendadas para planear y migrar una base de datos de SQL Server local a Base de datos SQL de Microsoft Azure como parte de un proyecto de migración de . Este tema aborda los aspectos siguientes:

  1. Perspectivas de la migración de bases de datos

  2. El Análisis en el que se establecen los objetivos del proyecto para la migración de bases de datos

  3. Administrar el subproyecto de migración de datos mediante las fases de Plan y diseño, Desarrollo, Prueba, Estabilización y Implementación.

Autor: Shaun Tinline-Jones
Colaborador: Steve Howard
Revisor: Shawn Hernan

La migración de bases de datos es un subproyecto de un proyecto mayor de migración de la solución. Suele haber puntos de integración y dependencias entre los proyectos de migración de aplicaciones y bases de datos. Sin embargo, la migración de bases de datos puede continuar normalmente en paralelo con pocos cuellos de botella.

El enfoque de un proyecto de migración de Base de datos SQL de Azure debe tener en cuenta tres perspectivas:

  • El ciclo de vida del proyecto debe ser ágil e iterativo por naturaleza. Cree un plan inicial según un estudio preliminar. Al planear una nueva iteración, perfeccionar el plan según el estudio realizado en iteraciones anteriores.

  • El tamaño y la complejidad de la base de datos y sus aplicaciones asociadas afectan a muchos factores de un proyecto de migración:

    • La complejidad de la base de datos impone el esfuerzo de ingeniería necesario migrar la base de datos.

    • El tamaño de la base de datos, la cantidad de datos que contiene, afecta al tiempo necesario para rellenar la nueva base de datos y pasar de la base de datos local a la base de datos hospedada en Base de datos SQL de Azure.

  • La migración de una base de datos a una nueva plataforma suele implican cambios en la base de datos que afectan a las demás capas de la solución que usan dicha base de datos. El proyecto de migración debe coordinar el trabajo de desarrollo en todas las capas afectadas y proporcionar una implementación unificada de todos los componentes modificados.

Cada base de datos que se va a migrar se puede clasificar en uno de los cuatro cuadrantes definidos según el tamaño y la complejidad. El cuadrante en el que se encuentra una base de datos ayuda a comprender el ámbito de un proyecto necesario para migrar la base de datos a Base de datos SQL de Azure y elegir un buen mecanismo para la migración. Los cuadrantes son los siguientes:

Una base de datos grande necesita más tiempo para el cambio a Base de datos SQL de Azure porque se necesita más tiempo para transferir datos a través de Internet. Una mayor complejidad de la base de datos significa una mayor probabilidad de que sea necesario realizar cambios, lo que implica mayor cantidad de trabajo de ingeniería.

Es fundamental entender el tamaño y la complejidad de la base de datos de origen a la hora de establecer el objetivo del proyecto de migración.

Durante la fase de análisis se establecen el objetivo y la visión del proyecto. Los objetivos globales del proyecto deben incluir los objetivos para la base de datos que se va a migrar.

Todas las bases de datos deben cumplir los requisitos empresariales, como disponibilidad, recuperación, tiempo de respuesta y cumplimiento de reglas de seguridad y privacidad. Al migrar una base de datos a Base de datos SQL de Azure, configure el servicio de base de datos modo que cumpla estos requisitos empresariales o negocie un conjunto de requisitos nuevo que Base de datos SQL de Azure pueda satisfacer. También puede que tenga que cambiar sus procesos administrativos. Por ejemplo, si actualmente realiza copias de seguridad de la base de datos todas las noches, quizás tenga que cambiar a las características de copia de base de datos o de exportación de la aplicación de capa de datos admitidas por Base de datos SQL de Azure.

Los requisitos empresariales no se pueden determinar analizando la base de datos y el código de aplicación existentes. Debe recopilar los requisitos hablando con las partes interesadas y los administradores, y examinando documentos de proceso como contratos de nivel de servicio.

Los objetivos del proyecto de migración de relacionados con la migración de bases de datos deben cumplir los requisitos empresariales de la base de datos, y reflejar el tamaño y la complejidad de la base de datos. La migración de bases de datos complejas necesitan un esfuerzo de ingeniería mayor que las bases de datos simples. Un proyecto para migrar una base de datos compleja puede reducir el riesgo si se limita el proyecto inicial a migrar las características empleadas en la base de datos local. La incorporación de características exclusivas de Base de datos SQL de Azure se puede realizar en proyectos de seguimiento.

La fase de análisis proporciona instrucciones de alto nivel para la fase de planeación y diseño. Es importante revisar durante la fase de análisis todo el conjunto de problemas que podrían afectar a la migración, pero no centrarse demasiado en profundidad en los detalles durante esta fase. La primera iteración de las fases de planeación y diseño debe profundizar más en los detalles para producir diseños y planes más específicos. Ponga en práctica un proceso de comentarios para ajustar los documentos de visión y de ámbito a los resultados del trabajo preliminar de planeación y diseño.

La evaluación de la complejidad de un proyecto de migración de Base de datos SQL de Azure significa determinar la cantidad de cambios necesarios para completar una migración correcta. Las distintas etapas de un proyecto de migración de Base de datos SQL de Azure necesitan evaluaciones cada vez más precisas del ámbito de los cambios de ingeniería derivados de la migración. Se debe tener en cuenta una evaluación general inicial a la hora de definir el objetivo del proyecto y tomar la decisión de iniciar el proyecto. Esta evaluación también constituye la base del trabajo preliminar de planeación y diseño del proyecto. Los resultados de un estudio exhaustivo que se realizará posteriormente en el proyecto deben quedar reflejados en planes del proyecto, diseños y posiblemente ajustes en los objetivos del proyecto cada vez más detallados.

Aborde todas las dependencias de características no admitidas por Base de datos SQL de Azure como parte del proyecto de migración. Se pueden identificar inicialmente estas dependencias sin necesidad de tener acceso al sistema de producción. Para ello se compara la documentación existente sobre las características admitidas por Base de datos SQL de Azure con los documentos de diseño de la base de datos o las especificaciones de la aplicación. Otras personas familiarizadas con los diseños de bases de datos y aplicaciones también pueden revisar esa documentación. Más adelante se pueden confirmar ciertas clases de dependencias mediante herramientas como el Asistente para migración de Base de datos SQL de Azure.

Muchas bases de datos locales tienen dependencias de servicios ajenos a la base de datos. Por ejemplo, la participación en una topología de replicación, un proceso de extracción de SQL Server Integration Services o tareas de mantenimiento periódicas administradas por el Agente SQL Server. El proyecto de migración debe incluir el costo y el tiempo de desarrollo necesarios para cambiar las dependencias de dichos servicios. Quite las dependencias de cualquiera de los servicios que no admitan Base de datos SQL de Azure. Puede que tenga que realizar cambios en otros sistemas que admiten Base de datos SQL de Azure debido a las diferencias arquitectónicas entre SQL Server y Base de datos SQL de Azure.

Además, las bases de datos locales pueden tener objetos de Transact-SQL no admitidos en Base de datos SQL de Azure. Las aplicaciones que tienen acceso a la base de datos y el código de objetos de base de datos como procedimientos almacenados o desencadenadores también pueden usar elementos de sintaxis no admitidos por Base de datos SQL de Azure.

La evaluación inicial de la complejidad de la base de datos se puede realizar revisando los diseños o el código de la base de datos y de las aplicaciones con los aspectos descritos en los orígenes siguientes:

La migración de una base de datos a Base de datos SQL de Azure suele requerir cambios en las aplicaciones y los sistemas que usan la base de datos.

Primero debe realizar los cambios necesarios para que las aplicaciones funcionen eficazmente en un entorno de Base de datos SQL de Azure. Base de datos SQL de Azure es un servicio Web hospedado fuera del centro de datos. Esto significa que algunas prácticas recomendadas de bases de datos que tienen poco impacto cuando el servidor de bases de datos se encuentra en el mismo bastidor que el servidor de aplicaciones son importantes cuando la base de datos se migra a Base de datos SQL de Azure. Cada base de datos hospedada en Base de datos SQL de Azure se agrupa en varios servidores para mejorar la disponibilidad global. Sin embargo, algunas operaciones o el error del servidor actual pueden provocar un evento de conmutación por error transitorio que cierre todas las conexiones abiertas y revierta sus transacciones activas. Esto hace que sea importante que las aplicaciones tengan una lógica sólida de reintentos que reinicie una transacción cuando la aplicación obtenga un error de desconexión.

Para obtener más información sobre los cambios de la aplicación necesarios para admitir un buen rendimiento, vea Consideraciones sobre el rendimiento con Base de datos SQL de Windows Azure.

En los documentos siguientes se describen los cambios adicionales que es necesario realizar en la aplicación para lograr un funcionamiento eficaz con Base de datos SQL de Azure:

También debe realizar en las aplicaciones todos los cambios necesarios para ajustarse a todos los cambios realizados en la base de datos. Por ejemplo, si se quita de la base de datos un agregado definido por el usuario, debe modificar todas las aplicaciones que ejecuten instrucciones Transact-SQL que hagan referencia a ese agregado.

El trabajo de planeación y diseño debe comenzar durante la evaluación de la complejidad. Una parte fundamental de esta fase es realizar un estudio cada vez más detallado de los aspectos tratados en estas dos secciones:

A medida que se identifiquen características que haya que cambiar, formule las estimaciones iniciales del trabajo necesario para realizar esos cambios en las primeras iteraciones del proyecto. Cada iteración posterior debe realizar un examen más exhaustivo de la base de datos para identificar todos los cambios y formular definiciones más detalladas del ámbito de los cambios necesarios. Configure un proceso de comentarios en el que se puedan ajustar los objetivos y el ámbito del proyecto para reflejar los resultados del estudio más detallado realizado durante las iteraciones de planeación y diseño. La primera iteración no necesita acceso al entorno de producción, pero necesita una imagen razonablemente precisa de lo que existe en producción.

Puede obtener esta vista inicial de planeación si aprovecha el Asistente para migración de Base de datos SQL de Azure y refuerza las diferencias existentes entre SQL Server local y Base de datos SQL de Azure. Estos aspectos se explican con más detalle bajo sus títulos respectivos. SQL Server Data Tools (SSDT) puede ser una herramienta útil en esta etapa, especialmente si la Administración del ciclo de vida de las aplicaciones (ALM) de la capa de datos incluye el uso de esta herramienta o scripts de objetos de base de datos. El esfuerzo es bajo, un poco más que con el Asistente para migración de Base de datos SQL de Azure, pero no demasiado costoso. La elegancia recae en las características de productividad habituales de Visual Studio, como hacer doble clic en una advertencia e ir directamente a la línea incorrecta.

Puede comprobar la evaluación de problemas como la compatibilidad con Transact-SQL mediante varias herramientas:

  • Puede conectar el Asistente para migración de Base de datos SQL de Azure a una copia de prueba o de producción de la base de datos local y generar un informe de los objetos que se deben cambiar para poder ejecutarse en Base de datos SQL de Azure. Para obtener más información, vea Usar el Asistente para migración de SQL Azure.

  • Si una aplicación de capa de datos (DAC) admite todos los objetos de la base de datos local, puede extraer un paquete DAC y hacer lo siguiente:

    • Ejecutar el paquete DAC con el servicio Compatibility Assessment de Base de datos SQL de Azure para obtener un informe de los cambios necesarios (actualmente en versión beta).

    • Importar el paquete DAC para crear un proyecto de base de datos en SQL Server Data Tools y establecer el destino del proyecto en Base de datos SQL de Azure.

    • Para obtener más información, vea Usar un paquete DAC para migrar una base de datos a Base de datos SQL de Windows Azure.

Si bien las herramientas de evaluación pueden ayudar a identificar las características que no se admiten en Base de datos SQL de Azure, no identifican necesariamente características alternativas que se pueden usar para lograr la misma funcionalidad. Las personas que planean el proyecto deben entender los usos empresariales de las alternativas de funcionalidad y de diseño que también admitirán esos usos empresariales. La decisión de continuar se debe basar en una evaluación de los costos que supone desarrollar e implementar las alternativas, en lugar de ampararse simplemente en la ausencia de compatibilidad con una característica como razón para no usar Base de datos SQL de Azure.

Evite incluir objetivos que no sean propios de la migración, especialmente en el caso de migraciones complejas. Agregar complejidades es una razón frecuente por la que fracasan los proyectos de migración. Un área común que suele entrar dentro del ámbito es el deseo de aprovechar un modelo de base de datos de escalado horizontal. Hágalo solo si es necesario, por ejemplo:

  • Está migrando una base de datos que es mayor que el tamaño máximo admitido por Base de datos SQL de Azure.

  • El caso de negocio solo es viable si se implementa el modelo multiempresa al principio.

  • Los requisitos de proceso de la base de datos superan lo que es posible con una sola base de datos de Base de datos SQL de Azure.

La planeación y el diseño deben incluir consideraciones de costos. Se deben evaluar los factores de costos durante cada fase y con cada iteración, ya que son una parte importante de cada decisión sobre si se continúa o no. Este elemento se puede excluir de la planeación y el diseño porque la probabilidad de que este riesgo se convierta en un problema es baja, pero la gravedad de subestimar los costos puede ser muy alta.

Un factor de éxito clave es identificar los riesgos, y asignares una clasificación de probabilidad y gravedad. Enumere todos los riesgos, incluso aquellos que parezcan triviales. Asegúrese de que todas las partes interesadas estén de acuerdo en que los riesgos más probables se han calificado correctamente. Asegúrese de que cada riesgo probable tenga un plan de mitigación con un nivel aceptable de planeación por si el riesgo se convierte en un problema. Establezca un proceso para agregar planes para los nuevos riesgos encontrados durante todas las fases de la migración. Los problemas encontrados y resueltos durante la fase de implementación final se deben registrar como riesgos para proyectos futuros. También es importante evaluar los riesgos según su aplicación a un entorno de nube, no por cómo se aplican en entornos locales más conocidos.

Es importante que el proyecto cuente con un examen exhaustivo de todas las características usadas por la base de datos en el conjunto de características admitidas en Base de datos SQL de Azure, junto con estimaciones de los costos de conversión y los costos de ejecutar la base de datos en Base de datos SQL de Azure. Este examen debe realizarse en una iteración suficientemente temprana de forma que el proyecto se pueda cancelar si los costos superan a las ventajas. Un proyecto de migración de Base de datos SQL de Azure se topó con dificultades relativamente tarde porque los diseñadores del proyecto no tuvieron en cuenta que Base de datos SQL de Azure no admitía la compresión de datos usada por la base de datos local. Esto supuso un cambio considerable en los costos previstos de ejecutar la base de datos en Base de datos SQL de Azure y es el tipo de problema que se debe identificar relativamente al principio del proyecto.

Cada iteración durante la fase de planeación y diseño debe incluir una evaluación más profunda de los cambios necesarios en la capa de datos. Por ejemplo, la segunda iteración puede incluir la creación de un seguimiento del generador de perfiles del entorno de pruebas funcionales y su ejecución mediante SQLAzureMW. Una tercera iteración puede pasar al entorno de pruebas de rendimiento, donde las herramientas de Monitor de rendimiento se incluyen en el cuadro de herramientas para identificar posibles áreas para estar preparados para la migración.

Base de datos SQL de Azure no admite características de SQL Server 2000 y SQL Server 2005 que se quitaron de SQL Server 2008 y versiones posteriores. Por ejemplo, Base de datos SQL de Azure no admite la sintaxis *= o =* para especificar combinaciones. Por lo tanto, la migración de estas bases de datos a Base de datos SQL de Azure también debe solucionar muchos de los mismos problemas encontrados en la actualización desde SQL Server 2000 o SQL Server 2005. Puede usar herramientas como contadores de Monitor de rendimiento, XEvents y Asesores de actualizaciones de SQL Server para buscar estas dependencias. Para obtener más información sobre cómo investigar estos problemas, vea Actualizar el motor de base de datos.

El desarrollo es una operación distinta de realizar tareas generadas en la fase de planeación y diseño. Las personas asignadas a tareas de desarrollo no deben tener asignadas tareas en otras fases del proyecto de migración.

La mayoría de las bases de datos migradas a Base de datos SQL de Azure necesitan cambios que afectan a las capas de aplicación. En cuanto se modifiquen elementos como los tipos de datos, el número de columnas devueltas, Transact-SQL dinámico o los parámetros de entrada, será necesario modificar la capa de datos del código de aplicación. Aunque la migración no cambie ningún objeto de base de datos, la arquitectura de Base de datos SQL de Azure requiere cambios en la aplicación como una lógica de reintentos y un control de errores sólidos. Es decir, el desarrollo de base de datos debe integrarse con el desarrollo de la capa de aplicación.

El trabajo de desarrollo de base de datos se puede realizar mediante cualquier herramienta de desarrollo de base de datos que admita bases de datos de SQL Server. Una ventaja de usar una herramienta como SSDT que cuenta con lógica para Base de datos SQL de Azure es que puede configurar el destino de compilación del proyecto de base de datos en Base de datos SQL de Azure, momento en el cual SSDT identificará la sintaxis compatible a medida que escribe el código. Para obtener más información, vea Microsoft SQL Server Data Tools. Antes del lanzamiento de SSDT, los desarrolladores usaban el Azure Emulation Kit y se conectaban a SQL Server Express. Esto agrega comodidad y proporciona un cierto sentido de desarrollo sin conexión, pero sigue siendo un conjunto de características locales y por consiguiente puede inducir a errores respecto a lo que es posible en Base de datos SQL de Azure. Una experiencia más productiva y eficiente consiste en identificar los problemas lo más cerca posible del tiempo de diseño y antes de escribir el código. Si no está desarrollando con una herramienta que tenga lógica para Base de datos SQL de Azure, puede iniciar el desarrollo en Base de datos SQL de Azure lo antes posible. Las herramientas de desarrollo sin conexión como SSDT ofrecen la propuesta de valor de varios desarrolladores que trabajan simultáneamente en el mismo proyecto. SSDT también se integra con las características de control de código fuente y de compilación, como las de Team Foundation Server. Si la migración afecta al código de la aplicación y de la base de datos, el proyecto de base de datos se puede integrar en el mismo entorno de compilación. Si la migración afecta a las aplicaciones y a la base de datos, el proyecto de SSDT puede integrarse en la misma solución que los procesos de compilación de proyectos de aplicación. Estos son algunas ventajas de las que puede disfrutar aparte de los desafíos obvios de conectividad que supone el desarrollo directo en Base de datos SQL de Azure.

Cuando la migración necesite relativamente pocos cambios en el modelo de datos, importe ese modelo de datos en SSDT y empiece a aplicar los cambios. La propuesta de valor aquí es que los recursos de desarrollo individuales pueden trabajar en sus áreas centrales respectivas e integrarlos durante la fase de compilación.

En cada iteración del proyecto, el equipo de desarrollo debe proporcionar al equipo de planeación comentarios periódicos y responder a sus ciclos de forma proactiva. Debe reconocer que es menos arriesgado validar periódicamente y después obtener errores y recuperarse rápidamente de ellos que codificar durante largos períodos de tiempo sin realizar ninguna validación. No se trata de un nuevo paradigma; es simplemente que no respetar estos paradigmas al desarrollar soluciones basadas en la nube puede ser muy costoso.

De la misma forma que las demás actividades del ciclo de vida de la aplicación de un proyecto de la migración, hay varias actividades y objetivos que permanecen constantes independientemente de que se trate de una migración a Base de datos SQL de Azure. He aquí las áreas de pruebas que se importantes para Base de datos SQL de Azure, pero que los diseñadores y los desarrolladores suelen pasar por alto:

  • Control de errores

  • Lógica de reintento

  • Respuesta a limitaciones

  • Implementación de cambios

  • Paradigma de escalado horizontal

  • Efectos de la latencia de red

  • Seguridad

  • Registro

Preste atención a estas áreas porque proporcionan una base a partir de la cual se pueden derivar casos de uso de pruebas de funcionalidad y rendimiento. Existen muchas herramientas para realizar pruebas, pero lo que es importante es la capacidad de aislar la actividad de base de datos. Las pruebas funcionales aumentará la productividad mitigando la inmadurez de las herramientas de desarrollo para detectar con precisión la funcionalidad de SQL Server que no aparece en Base de datos SQL de Azure. En función de las herramientas de desarrollo y los mecanismos de compilación, las pruebas funcionales pueden no producir ningún problema y servir únicamente como un seguro adicional antes de encontrarse con pruebas de rendimiento más largas y costosas.

La prueba de la solución migrada debe abordar nuevos casos de uso que tenían poco impacto en el caso de implementaciones locales. Cree pruebas que fuercen errores que exijan la necesidad de reintentar transacciones, y pruebe el impacto que supone alcanzar cargas máximas. Las buenas soluciones de la nube reducen el tiempo de la solución de problemas. Esto se puede conseguir desarrollando lógica de aplicación que registre la actividad y analice periódicamente el estado actual del sistema. Puesto que las acciones de registro de la base de datos pueden resultar costosas y están limitadas a escribir en otra tabla, el código de aplicación que ejecuta las llamadas de base de datos debe registrar los errores, las advertencias y las duraciones. Por ejemplo, un cliente pasó varias horas solucionando problemas en algunos servidores que presentaban degradación del rendimiento. Intentaron aprovechar muchas herramientas para identificar de forma reactiva la causa del problema para poder resolverlo. Después de varias horas, los servidores empezaron a funcionar repentinamente como se esperaba. El problema no tenía nada que ver con su aplicación, sino que estaba en curso una actualización de la plataforma. El esfuerzo para resolver el problema se podría haber reducido considerablemente si la aplicación hubiera estado mejor diseñada para registrar puntos de datos y los administradores analizaran periódicamente el estado de la solución. Podrían haber ofrecido al ingeniero de soporte técnico mejores datos que simplificaran la identificación de la causa principal del problema. Por supuesto, entre los usos futuros de este tipo de datos se incluye la redirección de los consumidores a otro centro de datos.

La experiencia de implementación es un área que se puede olvidar fácilmente. La prueba debe incluir la experiencia de implementación y proporcionar información o seguridad sobre cómo se pueden aplicar los cambios futuros en un entorno existente. Implementar una base de datos nueva, inicializarla y lograr que esté lista para su uso en producción es muy diferentes que implementar cambios en un entorno de producción existente. No tiene consideraciones distintas a las locales, pero se menciona por 2 motivos:

  • Las acciones de implementación que funcionaban de forma local pueden no funcionar para las soluciones basadas en la nube.

  • Supone bastante esfuerzo adicional incluir esto en el plan de pruebas, con pocos resultados inmediatos.

Las pruebas también deben participar en el modelo iterativo, donde los problemas se transmiten a los equipos de desarrollo y planeación. Al principio las pruebas pueden ser bastante rudimentarias y muy similares a las pruebas locales. Con cada iteración, incorpore casos de prueba más preparados para la nube. Los casos de prueba deben abarcar los problemas identificados en la documentación mencionada en la sección dedicada a la evaluación de la complejidad anteriormente.

La complejidad de la migración puede deberse a restricciones de tiempo de inactividad, lo que aumenta la prioridad de probar el plan de implementación propuesto.

Esta etapa no es distinta de su propósito en el Ciclo de vida de desarrollo de software normal. Para el proyecto de migración se trata de alcanzar el punto en el que los desarrolladores solo trabajan en los problemas detectados por las pruebas; ya no están codificando la primera versión de la versión migrada de la base de datos.

De manera similar a la estabilización, la fase de implementación para la migración a la nube no es distinta de los proyectos de migración locales. Unas buenas pruebas aumentan la probabilidad de éxito en esta fase.

Unas buenas comunicaciones son un factor de éxito clave para la migración. Las actualizaciones de estado periódicas con un nivel de detalle adecuado para el consumidor del estado son vitales para lograr una buena experiencia, o al menos una experiencia que pueda seguir al tanto de los objetivos empresariales más amplios de migración a la nube.

El éxito en la fase de implementación depende de calidad del trabajo realizado en las fases anteriores. Unas fases deficientes de estudio, planeación, desarrollo y pruebas aumentan considerablemente el riesgo de encontrar problemas durante la implementación. Algunas veces los problemas de implementación son lo suficientemente graves como para detener el proyecto con una reversión a los sistemas locales. Se han dado casos en que algunas organizaciones ponían en duda su capacidad para usar sistemas basados en la nube. Unas buenas fases de estudio, planeación, desarrollo y pruebas suelen dar como resultado una implementación que funciona de acuerdo con el plan establecido. Incluso si se detectan problemas, una buena planeación suele haber incorporado contingencias que reducen el impacto de los problemas.

¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2014 Microsoft