SQL Server: Administrar la migración

Migrar bases de datos masivas nunca pueden ser llamados una tarea fácil, pero Microsoft tiene una herramienta que puede ayudar a facilitar el camino y asegurarse de que está listo.

Bienmente Lee

La iteración más reciente de SQL Server, con nombre en código "Denali," ofrece muchas características atractivas y llevará a muchas organizaciones a SQL Server. Incluso con el rendimiento y las ventajas de costo total de propiedad (TCO) para pasar a SQL Server, sin embargo, algunas organizaciones pueden tener preocupación por el costo y el riesgo de migración de base de datos.

Afortunadamente, Microsoft proporciona una herramienta SQL Server migración Assistant (SSMA), al automatizar el proceso de migración. La más reciente SSMA v.5.1 (lanzada este mes al mismo tiempo con SQL Server Denali CTP3) soporta migración de bases de datos Oracle, Sybase, MySQL y acceso a SQL Server. Puede utilizar SSMA para facilitar su proyecto de migración de la base de datos. Por ejemplo, aquí es un aspecto en el proceso de migración de una base de datos Oracle, pero el proceso y los pasos son los mismos al migrar desde otras bases de datos.

Evaluar la base de datos

SSMA automatiza la migración de más objetos de base de datos, incluyendo procedimientos almacenados, funciones, paquetes y desencadenadores. Hay algunos tipos de datos especiales como tipo de objeto o espaciales que no son compatibles con la versión actual de SSMA. Además, también tiene instrucciones de PL/SQL complejas que no se puede convertir automáticamente. Puede utilizar SSMA para ejecutar una evaluación de la migración sobre la base de datos Oracle y determinar si el esquema de base de datos contiene esas declaraciones.

Los informes de resumen de evaluación contienen la siguiente información:

• Vista de árbol de esquema: una lista de objetos de esquema de base de datos de Oracle de origen.
• Tasa de conversión: el porcentaje de declaraciones que SSMA es capaz de convertir automáticamente. En este ejemplo (véase figura 1), la herramienta SSMA puede convertir 99.39% de todas las declaraciones en el esquema de Oracle de origen.
• Recuento de objetos: el número de base de datos de objetos encontrados en el esquema de Oracle y el número de objetos "con errores" (más sobre esto más adelante).
• **Resumen del mensaje de conversión:**una descripción de los problemas que encontró al migrar el esquema de Oracle de origen.

Hay tres tipos de mensajes de conversión te vas a encontrar durante una migración mediante la herramienta SSMA: información, advertencia y error:

• Un mensaje de error se produce cuando SSMA no es capaz de convertir un objeto de base de datos o una declaración dentro de un objeto de base de datos.
• A mensaje de advertencia se produce cuando SSMA es capaz de convertir la declaración de Oracle, pero la instrucción puede no producir el mismo resultado para algunos casos. Por ejemplo, SSMA convierte SUBSTR() de Oracle a SQL Server SUBSTRING(). En la mayoría de los casos, SUBSTRING() volvería a los mismos productos. Existen algunas situaciones donde los resultados son diferentes. Por ejemplo, la función de Oracle SUBSTR() admite valores negativos para la posición de carácter. SUBSTR('TechNet',-3,3) devuelve 'Net' en Oracle, mientras que SUBSTRING('TechNet',-3,3) le devuelva una cadena vacía en SQL Server.
• Un mensaje de información es de SSMA proporcionar información adicional acerca de cómo convierte ciertos objetos.

Figura 1 un vistazo a la tasa de conversión al convertir de una base de datos de Oracle.

Cada mensaje de error incluye un enlace que muestra el objeto que contiene el error. También hay una comparación lado a lado con la Declaración original a la izquierda, lo que sería la declaración convertida en SQL Server (consulte figura 2) a la derecha. El mensaje de error incluye también una estimación de cuántas horas de conversión manual normalmente serían necesario para resolver el problema.

Figura 2 ocasionalmente recibirá un mensaje de Error de migración.

Mayoría de las organizaciones suelen realiza evaluaciones contra una serie de esquemas de base de datos de Oracle. Utilizará el tipo de conversión total y tiempo total estimado de conversión manual para comparar y establecer prioridades de esquema de base de datos de Oracle para la migración.

Convertir el esquema de base de datos

SSMA le ofrece muchas opciones para la conversión de esquema. Por ejemplo, puede modificar la asignación de tipos de datos. SSMA proporciona asignación de tipo de datos predeterminada entre Oracle y SQL Server. Sin embargo, puede personalizar la asignación de tipos de datos de una tabla específica, para todas las tablas, para un objeto específico (por ejemplo, un procedimiento almacenado o función) o para usos diferentes (como el tipo de datos en la columna, el tipo de datos en la variable o el tipo de datos en el parámetro de entrada y salida de su procedimiento).

Convertir el esquema de base de datos haciendo clic en el botón "Convertir el esquema". A continuación, puede desplazarse al objeto de base de datos diferente y comparar el objeto de esquema original y el objeto convertido (véase figura 3)

Figura 3 ver el esquema de conversión.

Cuando un objeto contiene una declaración que no se puede convertir automáticamente SSMA, la herramienta Agregar una descripción del error de migración, comentar la declaración concreta o reemplazarlo con un tipo genérico. Este enfoque de aislamiento permite continuar con la migración de base de datos y resolver la cuestión más adelante.

También podría resolver el problema y modificar la instrucción directamente de SSMA. Por ejemplo, en figura 3, hay una función definida por el usuario llamada "Tenencia". Esto devuelve un tipo de datos de intervalo que SQL Server no es compatible. Puede modificar el tipo de valor devuelto al número (véase figura 4) y reconvertir la función. Esto elimina el error y convierte el valor devuelto a float(53).

Figura 4 puede modificar declaraciones en SSMA para resolver incompatibilidades.

También puede modificar declaraciones convertidas. Por ejemplo, puede sustituir "float(53)" de tipo de valor devuelto con "int". Tenga en cuenta que cualquier modificación que realice con SSMA se almacena localmente. Los cambios realizados a las declaraciones de origen no se aplican al esquema de base de datos Oracle que tiene en producción. Del mismo modo, los cambios realizados en el instrucción SQL Server de destino no se aplican inmediatamente al servidor. Esto le permite seguir perfeccionando y hacer las modificaciones necesarias al esquema convertido sin afectar el servidor de destino.

Puede desplegar esquema convertido en el destino de SQL Server pulsando el nombre de esquema en la ventana del explorador de metadatos de SQL Server. También puede generar una secuencia de comandos para crear la información de esquema completo, que puede implementar en el servidor de destino (véase figura 5).

Figura 5 implementar convertido esquema para SQL Server.

Migración de datos

Después de crear el esquema de base de datos en el destino de SQL Server, puede utilizar SSMA para migrar datos de Oracle. SSMA no es la única opción para migrar datos, sin embargo. También se puede utilizar SQL Server Integration Services (SSIS). Sin embargo, migración de datos con SSMA permite utilizar el mismo tipo de asignación para la conversión de esquema. También algunos de los problemas comunes de migración de datos controla la migración de Oracle a SQL Server.

Por ejemplo, Oracle tiene una gama más amplia de tipos de datos compatibles que SQL Server. De forma predeterminada, SSMA provoca el error de migración de datos cuando encuentre ese caso. Puede tener SSMA convertir automáticamente los valores de fecha fuera de alcance con NULL o la fecha más cercana que SQL Server puede usar. Puede modificar esta configuración a través de herramientas | Configuración del proyecto | General | Migración de datos (véase figura 6).

Figura 6 hay opciones para el tratamiento de errores de migración de datos.

Después de completar la migración de datos, la voluntad SSMA migrado mostrar un informe con el número de filas, la tasa de éxito y los tiempos para migrar cada tabla (véase figura 7).

Figura 7 SSMA le dará un informe completa de migración de datos.

Verificación de la migración de base de datos

Después ha migrado correctamente la base de datos, el siguiente paso es la validación. Migración de Oracle y Sybase, SSMA permite comparar la base de datos de origen y la base de datos migrado. Puede definir una serie de casos de prueba; luego SSMA ejecuta los casos de prueba sobre el origen y la base de datos de destino. Compara los resultados, así como los cambios los casos de prueba en las tablas subyacentes.

Para definir un caso de prueba, seleccione Nuevo casos de prueba en el menú de Tester. Un caso de prueba asistente le guiará a través del proceso de creación de un caso de prueba. También puede seleccionar objetos de base de datos específica para probar. Por ejemplo, es un procedimiento llamado ADD_EMPLOYEE. Este procedimiento inserta un nuevo registro en la tabla empleado basada en el valor proporcionado en el parámetro de entrada. Puede definir los parámetros de entrada específicos para utilizar en la prueba a través de la ficha llamar valores (véase figura 8). Puede definir tantos valores de llamada como sea necesario.

Figura 8 llamar a especificar valores en el Asistente de caso de prueba.

Además de comparar la ejecución del objeto de la prueba, SSMA también puede probar cambios en la tabla subyacente. Por ejemplo, al ejecutar el ADD_EMPLOYEE procedimiento almacenado, SQL Server se insertará una fila adicional en la tabla empleados. SSMA compara las filas modificadas en la tabla afectados entre el origen y el destino. Si es necesario, también puede especificar el nivel de detalle para la comparación (véase figura 9).

Figura 9 especificar las tablas subyacentes para la comparación.

El paso final en la definición de caso de prueba es una configuración adicional. Un valor importante es si se va a deshacer los cambios realizados en la tabla debido a pruebas (véase figura 10). En mi ejemplo, al ejecutar el ADD_EMPLOYEE procedimiento almacenado, se agregará a la base de datos Oracle y la base de datos de SQL Server de destino un nuevo registro. Si selecciona la opción de restauración de datos, SSMA eliminará el valor insertado después de completar la prueba.

Figura 10 Configuración de definición de caso de prueba.

Después de definir el caso, puede ejecutar tantas veces como sea necesario. Por cada ejecución, recibirá un informe de resultado de la prueba que compara resultados (véase figura 11).

Figura 11 SSMA le dará un informe de resultado de prueba completa.

SSMA proporciona gran funcionalidad para automatizar la migración de base de datos. Puede utilizar la herramienta para evaluar la complejidad de la base de datos va a migrar, convertir el esquema de base de datos, resolver problemas comunes de migración de la base de datos, migración de datos desde la base de datos y validar la base de datos migrado.

La herramienta está diseñada para migrar a SQL Server, pero también soporta migración directa a SQL Azure (de bases de datos MySQL, Sybase y acceso). Al migrar a SQL Azure, SSMA toma en cuenta los requisitos de la plataforma de SQL Azure. Por ejemplo, SQL Azure requiere que sus tablas tienen un índice agrupado. Si la tabla de origen no incluye una clave principal o un índice agrupado, la herramienta automáticamente puede agregar una columna ROWID y establecer el índice agrupado en la columna durante la conversión.

Se puede Descargar SSMA desde el sitio Web de Microsoft SQL Server. No sólo es la herramienta gratuita, pero también puede obtener soporte de correo electrónico gratuito de soporte y servicio al cliente de Microsoft. Para obtener más información sobre SSMA, visite la blog del equipo de SSMA para una demostración en video y artículos de procedimientos, así como orientación en la solución de problemas comunes de migración.

Bienmente Leees administrador de programas de alto nivel con el equipo de SQL Server Migration Assistant, y es el propietario de la función de la herramienta de migración de la base de datos de Oracle y MySQL a SQL Server. Antes de incorporarse a Microsoft en 2007, trabajó como consultor en desarrollo de soluciones de bases de datos y la implementación de aplicaciones de empresa para más de 10 años.

Contenido relacionado

• SQL Server: Planificación de la migración a SQL Server 2008 R2
• SQL Server: Proteger a toda costa los datos
• Trabajando juntos: SQL Server 2008 R2 Reporting Services integración en SharePoint 2010