Planificando La Migracion de SQL Server 2000 2005 a SQL Server 2008 R2

Serie Relacional

Planificando la migració n a SQL Server 2008 R2

Autor: Enrique Catala

Revisores: Eladio Rincón

Planificando la migración de SQL Server 2000-2005 a SQL Server 2008 R2

ADVERTENCIA LEGAL Todos los derechos de esta obra están reservados a Enrique Catalá y a SolidQTM Press. El editor prohíbe cualquier tipo de fijación, reproducción, transformación o distribución de esta obra, ya sea mediante venta, alquiler o cualquier otra forma de cesión de uso o comunicación pública de la misma, total o parcialmente, por cualquier sistema o en cualquier soporte, ya sea por fotocopia, medio mecánico o electrónico, incluido el tratamiento informático de la misma, en cualquier lugar del mundo. La vulneración de cualesquiera de estos derechos podrá ser considerada como una actividad penal tipificada en los artículos 270 y siguientes del Código Penal. La protección de esta obra se extiende al mundo entero, de acuerdo con las leyes y convenios internacionales.

© Enrique Catalá, 2011 © SolidQTM Press, 2011

Planificando la migración a SQL Server 2008 R2 Serie Relacional Autor: Enrique Catalá Bañuls Revisores: Eladio Rincón Editado por SolidQTM Press Apartado de correos 202 03340 Albatera, Alicante, España http://www.solidq.com

Precio: Gratuito ISBN: 978-84-936417-9-5

© Solid Quality™ Press

Page 2 of 102

Da un giro a tu carrera profesional.

Máster en BI http://www.solidq.com/es/MasterBI

Máster SQL Server DBA http://www.solidq.com/es/MasterSQLServerDBA

POR

SolidQ

MASTERS CERTIFICADOS

Es tiempo de oportunidades.

Máster en SharePoint http://www.solidq.com/es/MasterSharePoint

¡Infórmate Ya! Conviértete en un profesional altamente especializado en tecnologías Microsoft. Bonificable a través de la Fundación Tripartita

Para más información llama al 800.300.800 o +34 91 414 8950 o bien manda un e-mail a: [email protected]


Tabla de Contenidos 1.

Introducción ...................................................................................................................... 6

2.

Estrategias de Migración ................................................................................................... 7 Actualización “In-Place” ........................................................................................................ 7 Migración “Side-by-side” ....................................................................................................... 9 Enfoque del documento ...................................................................................................... 11

3.

Diseño de la solución ....................................................................................................... 12 Roles y departamentos implicados en una migración ........................................................ 12 Buenas prácticas en la configuración de SQL Server 2008 R2 ............................................. 13 Alineamiento de particiones ........................................................................................... 13 Formateo de NTFS a bloques de 64kb ............................................................................. 15 Log on as a service ........................................................................................................... 15 Lock pages in memory ..................................................................................................... 16 Instant File Initialization .................................................................................................. 17 Configuración de seguridad básica .................................................................................. 17

4.

Planificación de la migración ........................................................................................... 20 Características de SQL Server Obsoletas y/o discontinuadas ............................................. 20 SQL-DMO ......................................................................................................................... 20 Utilidades osql e isql ........................................................................................................ 20 Bcp ................................................................................................................................... 21 Rebuild.exe ...................................................................................................................... 21 SQL Mail ........................................................................................................................... 21 English Query ................................................................................................................... 21 Surface Area Configuration ............................................................................................. 21 Resumen de equivalencias entre herramientas de SQL Server 2000 y 2008 R2 ................. 22 Migración del motor relacional ........................................................................................... 23 Fases de una migración “side-by-side” ........................................................................... 23 Minimizar el proceso de actualización ............................................................................ 23 Planificación de la migración ........................................................................................... 24 Analisis de interconexiónes ................................................................................................. 25 Figura 4-2: Diagramas de dependencia entre bases de datos ........................................ 27


Page 3 of 102


¿Por qué querríamos calcular dependencias entre bases de datos? .............................. 28 Instalación y ejecución de SQL Server Upgrade Advisor ..................................................... 28 Visualizar e interpretar informes generados por SSUA ....................................................... 31 Motor de base de datos .................................................................................................. 32 Data Transformation Services ......................................................................................... 38 Análisis de consultas dinámicas ...................................................................................... 40 Migración de los paquetes DTS a SSIS. ................................................................................ 44 ¿Qué ocurre durante la migración? ................................................................................ 44 Guión de migración ............................................................................................................. 45 Migración del motor de base de datos ........................................................................... 45 Patrones de codificación TSQL adaptados para SQL Server 2008 R2 .............................. 47 Solución de problemas de actualización ......................................................................... 52 Migración de paquetes DTS a SSIS .................................................................................. 53 Migración de Análysis Services ........................................................................................ 70 Acciones Post migración ...................................................................................................... 76 5.

Apéndice .......................................................................................................................... 78 Actualizaciones de seguridad .............................................................................................. 78 Servidores vinculados desde entornos SQL Server x64 hacia SQL Server 2000 x32 ........... 78 Cadenas de conexión con el nombre de aplicación ............................................................ 78 Finalización de trazas de Sql Profiler ................................................................................... 78 Finalizar la traza ............................................................................................................... 79 Generación de Scripts de mantenimiento........................................................................... 79 Solución al error “allow remote connections through DCOM”........................................... 81 Crear una solución Visual Studio para gestionar todos los paquetes SSIS ...................... 82 Migración Analysis Services en dos pasos ........................................................................... 85 Idioma predeterminado de las conexiones ......................................................................... 86 Seguridad en paquetes SSIS ................................................................................................ 87 Integrar la nueva instancia en el parque de aplicaciones ................................................... 89 Instalar compatibilidad con SQL Server 2000 ...................................................................... 90 Runtime DTS .................................................................................................................... 90 Diseñador DTS ................................................................................................................. 91


Page 4 of 102


¿Por qué actualizar el nivel de compatibilidad? .................................................................. 92 Analisis de interconexiones ................................................................................................. 92 Análisis de aplicaciones que utilizan SQL Server ................................................................. 93 Documentos de referencia .................................................................................................. 96 Recursos de interés ............................................................................................................. 96 6.

Figuras ............................................................................................................................. 98


Page 5 of 102


1. Introducción El proceso de migración a SQL Server 2008 R2 no deberia ser un proceso traumático. Para conseguirlo, hay que consensuar un plan lo suficientemente robusto y estable como para satisfacer todas las posibles particularidades del entorno que desee migrar. Hay que ser consciente que como en cualquier proceso de riesgo, si es llevado a cabo negligentemente puede producir un resultado final lleno de errores e incompatibilidades de última hora que produzcan una migración traumática, defectuosa, o incluso que se deba abortar dicha migración. El siguiente documento pretende servir de guía para ayudar a realizar una planificación exitosa de migración hacia SQL Server 2008 R2 basándonos en experiencias adquiridas en diversos proyectos realizados en SolidQ. La información que aparece en este documento se trata de un suplemento a la información existente en los libros en pantalla de SQL Server 2008 R2 y no se pretende rebatir o contradecir la información que en él aparece, sino complementarla y facilitar su comprensión. En caso de existir discrepancias entre este ebook y la documentación oficial de Microsoft, prevalecerá la documentación oficial del fabricante. Además, sugerimos que consulte los enlaces referenciados en la sección “Documentos de Referencia”. Para entender el siguiente documento, creo conveniente definir los siguientes términos: •

•

•

Actualización o migración Transición entre una versión previa de SQL Server a una versión superior de la misma Servidor Computador físico o virtual con el sistema operativo Windows Server 2003 o superior Componente ó servicio Cualquiera de los ejecutables incluidos en la instalación de SQL Server (motor relacional, integration services, reporting services, analysis services,…)


Page 6 of 102


2. Estrategias de Migración A la hora de dar soluciones a la actualización de SQL Server hacia 2008 R2, podemos realizar dos tipos de planteamientos diferentes en función de nuestras necesidades: • •

Actualización “in-place”: Utilizando el propio instalador de SQL Server 2008 R2, podemos actualizar directamente los servicios de SQL Server a la nueva versión Migración “side-by-side”: Mover las bases de datos de la antigua a la nueva instancia de SQL Server 2008 R2 que se debe instalar previamente. Existen dos aproximaciones o Mismo servidor: La nueva instancia reside en el mismo servidor que la antigua o Nuevo servidor: Existe un nuevo servidor destinado a albergar la nueva instancia SQL Server 2008 R2

Actualización “In-Place” Se trata de una actualización en la que no es necesario realizar movimiento de datos. Una vez concluida la misma, en el servidor actualizado ya no existe la instancia anterior de SQL Server y solo existe la instancia SQL Server 2008 R2. Restricciones de una actualización “in-place”: •

•

•

Se requiere que todos los componentes de SQL Server sean actualizados a la vez. Esto incluye Integration Services, Analysis Services, Reporting Services, Full-Text Search, … todos aquellos que están instalados en el servidor en el momento de comenzar la migración. No es posible realizar una migración “in-place” de x32 a x64 o viceversa. En otras palabras, si se va a migrar una instancia SQL Server 2000 x32, solo se puede migrar a SQL Server 2008 R2 x32 No es posible migrar un subconjunto de bases de datos únicamente, puesto que se migra el servicio en su totalidad, lo que incluye a todas las bases de datos que alberga.

Este tipo de actualizaciones por el contrario, tienen como ventaja principal que el tiempo de migración es mínimo, puesto que nos ahorramos todo el proceso de movimiento de datos (copia de ficheros de backup, datos,…), pero hay que tener en cuenta sus principales restricciones, que no lo hacen ideal para la mayoría de las situaciones. Antes de comenzar con el proceso de migración en si, debe asegurarse que tiene salvaguardados todos los datos críticos de su instancia de SQL Server, es decir: •

Haber hecho copias se seguridad de sus bases de datos de usuario y sistema.


Page 7 of 102


•

Haber podido restaurar dichas bases de datos en un entorno de pruebas o calidad.

Nota: recuerde el siguiente dicho: “no tienes una copia de seguridad de una base de datos hasta que hayas podido restaurarla”. En definitiva, necesita tener salvaguarda de los datos relacionados con la instancia de SQL Server que desea migrar para en caso de migración defectuosa, pueda tener un plan alternativo del que recuperar sus bases de datos. A grandes rasgos, el siguiente conjunto de pasos son necesarios a la hora de llevar a cabo una migración “in-place”: 1. Instalar los prerrequisitos de SQL Server 2008 R2 2. Lanzar el proceso de actualización “in-place” 3. Reparar los potenciales problemas o advertencias que sean mostradas por el asistente de migración, que los detectará y listará de forma previa a la actualización. Una vez reparados, volver a lanzar el proceso de actualización desde el CD de instalación. 4. El proceso de migración “in-place” instalará ahora los ejecutables, parará los servicios de la instancia a migrar y actualizará los objetos y componentes de la misma antes de desinstalarlos por completo. Una vez finalizado el proceso automático, la instancia SQL Server 2008 R2 estará completamente disponible y la instancia en la versión previa de SQL Server ya no existirá como tal puesto que se encontrará en la nueva versión. Este tipo de actualizaciones, tradicionalmente vienen siendo consideradas como “automáticas” y por ello parece que la necesidad de un administrador de base de datos es menor que en la actualización “Side-by-side”. Ciertamente la gran mayoría del trabajo se realiza automáticamente y si todo va bien, prácticamente deberemos realizar pequeñas modificaciones al resultado final (actualizar estadísticas, instalar MDAC 2.8 en los PC clientes,…) que en su gran mayoría no necesitan de un DBA experto. En el caso de estar en esta situación, hay que tener presente siempre el punto de “no retorno”. ¿En qué momento de la migración “in-place” si algo sale mal necesitaremos ayuda? ¿Qué ocurre si llegamos a un estado en el momento de la actualización en el que por inexperiencia, mala planificación,…no podemos continuar? ¿Si se corrompen datos en cualquier punto de la actualización podremos volver atrás? En el momento en que tengamos dudas en cualquiera de las respuestas a las preguntas mencionadas anteriormente, hay que tener pensar en disponer de un DBA experto que al menos dé soporte ante cualquier eventualidad crítica que pueda surgir. En el caso de que aun así decidamos seguir adelante sin un DBA experto, las siguientes consideraciones deberán ser resueltas antes de plantearse la migración: © Solid Quality™ Press

Page 8 of 102


• • • •

¿Cuándo considerarás que tu actualización ha sido satisfactoria? ¿tienes alguna forma de testear las aplicaciones sobre el nuevo entorno SQL Server 2008 R2? ¿Puedes realizar una simulación de migración “in-place” sobre un entorno de testing? ¿has resuelto todas las advertencias propuestas por Upgrade Advisor?

Como mínimo, debes poder responder a estas preguntas de manera satisfactoria antes de plantearte realizar la actualización hacia SQL Server 2008 R2 sin un DBA. Este modelo de migración, además de todo lo comentado anteriormente, suele poseer un factor de riesgo más, derivado de la versión de sistema operativo donde reside la instancia de SQL Server a migrar. Puesto que SQL Server 2008 R2 no es compatible con Windows Server 2000 y Windows Server 2008 R2 no es compatible con SQL Server 2000, hay que añadir el factor migración de sistema operativo a una migración in-place en ocasiones (pese a que con frecuencia, se suele tener como algo habitual, la migración de SO independientemente de si es requerido o no). Los siguientes consejos deben ser seguidos en el caso de requerir una migración del sistema operativo: •

•

•

Si deseamos migrar un SQL Server 2000-2005 sobre Windows Server 2000, debemos realizar primero una migración de Sistema Operativo a Windows Server 2003 (recuerda que 2008R2 no seria válido) y posteriormente realizar la migración a Sql Server 2008 R2. Una vez realizado este proceso, ya se podrá realizar la migración a Windows Server 2008 R2 en el caso de que se desee, puesto que estaremos en SQL Server 2008R2. Windows Server 2008 R2, solo soporta iSCSI, SAS y fibra, por lo que si se está utilizando SCSI paralelo sobre Windows Server 2000, por ejemplo…hay que realizar primero la migración a soluciones de disco mas modernas compatibles con W2k8. Windows Server 2008 R2 no soporta el formato antiguo de domínios NT. Es preciso por tanto, si el servidor va a formar parte de un dominio de confianza en nuestra organización, que el dominio sea un dominio de Active Directory.

Para más información Upgrading to Windows Server 2008 R2.

Migración “Side-by-side” Se trata del modelo de migración mas común y mas versátil puesto que el destino final es una nueva instancia de SQL Server 2008 R2, bien sea en la misma máquina donde reside la antigua, o un nuevo servidor preparado especialmente para albergarla. Las ventajas frente al modelo de actualización “in-place” son: © Solid Quality™ Press

Page 9 of 102


•

• •

•

•

•

Se pueden migrar componentes de forma atómica que sean independientes entre sí. Esto quiere decir, que podemos migrar únicamente el motor relacional, dejando que el resto de servicios permanezcan funcionando en la antigua instancia de SQL Server Se permite la migración de 32 a 64 bits Se permite la actualización de la versión del Sistema Operativo (normalmente viene asociado a un nuevo servidor en el que se instala la última versión de Windows Server pasando por ejemplo de un Windows Server 2003 con SQL Server 2005 a Windows Server 2008 R2 R2 con SQL Server 2008 R2) Se permite la migración a un servidor mas potente. Al no estar ligados a la actualización del servicio, se puede comprar nuevo hardware destinado para SQL Server, y migrar los datos de la antigua instancia al nuevo servidor. Se puede migrar un conjunto de bases de datos, en lugar de todas las bases de datos: escenario apropiado en instancias de SQL Server que tienen aplicaciones de diferentes proveedores y alguno de ellos no soporta “todavía” la migración a SQL Server 2005-2008 R2. Revisar apartado “Análisis de interconexiones” Se puede consolidar diferentes instancias de bases de datos en una única instancia: generalmente, el incremento de capacidad de las nuevas máquinas adquiridas, dejan margen de maniobra suficiente para reducir el número de servidores a los que dar soporte y mantenimiento

En este modelo de migración, el principal inconveniente es que se necesita realizar un movimiento de datos. Esto quiere decir que los datos (backups ó ficheros de datos) deben moverse a su nueva ubicación, lo cual puede no ser algo simple si hablamos de bases de datos del orden de terabytes (TB) donde necesitamos espacio necesario para ello. Para llevar a cabo una migración “side-by-side” debemos realizar estos pasos a grandes rasgos: 1. Instalar una nueva instancia SQL Server 2008 R2 2. Lanzar SQL Server 2008 R2 Upgrade Advisor contra la instancia a migrar y resolver todas las advertencias 3. Parar toda actividad de la instancia SQL Server a migrar (desconexión de usuarios incluida) 4. Transferir los datos a la nueva instancia (mover backups, paquetes DTS/SSIS, …) 5. Restaurar los objetos sobre la nueva instancia 6. Una vez visto que todo funciona con normalidad, desconectar ó desinstalar la instancia SQL Server migrada si es necesario Este modelo por tanto ofrece mayor ventaja y flexibilidad sobre el modelo de actualización “in-place” debido a que en caso de problemas, se tiene la instancia original en funcionamiento y se puede planificar la vuelta atrás. Además, se permite realizar un testeo © Solid Quality™ Press

Page 10 of 102


previo a modo de preproducción de manera independiente, lo cual facilita en mayor medida la detección de potenciales problemas hardware o de migración que puedan existir el dia de paso a producción. En definitiva, pese a que el esfuerzo para llevar a cabo una migración mediante el modelo “side-by-side” es mayor, este es debido al mayor grado de control de todo el proceso. Es por ello que este tipo de actualización debe realizarse siempre por profesionales experimentados en SQL Server 2008 R2. Además, este tipo de migración permite que el periodo en que están las aplicaciones sin dar servicio pueda ser inferior al tiempo necesario de hacer la actualización del motor de SQL Server.

Enfoque del documento Una vez hemos visto los dos planteamientos posibles, se indica al lector que debido al gran número de ventajas existentes del modelo de migración “side-by-side” y la necesidad de dar un enfoque lo mas práctico posible al mismo, el documento se centra primordialmente en una solución de migración “side-by-side”.


Page 11 of 102


3. Diseño de la solución El proceso de migración “side-by-side” de SQL Server 2000-2005-2008 debe involucrar tanto la parte de instalación del entorno de servidor, como la parte de migración de los datos y aplicaciones que hacen uso de ellos. En los siguientes puntos se discutirán cada uno de dichos apartados. En este artículo se va a realizar un mayor énfasis en la migración desde SQL Server 2000 por tratarse de la que mayor problemática puede desatar debido al drástico cambio de arquitectura en sus servicios.

Roles y departamentos implicados en una migración Lo primero que hay que tener presente es que un proceso de migración, debe ser visto siempre como un proyecto dentro de nuestra empresa. En dicho proyecto, se van a ver implicados varios departamentos dependiendo de nuestra estructura organizativa y además lo serán tanto de la parte de desarrollo, como de la parte de sistemas. A continuación se expone un pequeño ejemplo de definición de roles recomendables en un proyecto de migración, así como las funciones que desarrollaran dentro del propio proyecto: -

-

-

-

Responsable de la migración de SQL Server: RELLENAR NOMBRE. En el equipo de BBDD, estarán por parte de SolidQ : Enrique Catalá…;por parte de “EMPRESA ADJUDICATARIA”: RELLENAR NOMBRES Su rol será el de gestionar y llevar a cabo el proceso de migración. Se encargará de indicar a cada responsable de departamento las tareas a realizar así como gestionar y/o realizar los cambios que fuesen necesarios. Se trata del punto de unión entre todos los departamentos implicados. Responsable de sistemas: RELLENAR NOMBRE. En el equipo de Sistemas, estarán aquellos Administradores de Sistemas designados, con el fin de reconfigurar los servidores de aplicaciones para apuntar al nuevo entorno. Quedan excluidos los sistemas que forman parte directa de la instancia SQL Server 2008 R2 que será producción. Responsable de desarrollo: RELLENAR NOMBRE. En el equipo de Desarrollo deberían estar todos los Jefes de Sección de Desarrollo implicados en el proyecto, así como los desarrolladores que ellos designen, en el ámbito de los Sistemas de Información que son de su respectiva competencia. Se encargaran o bien de aplicar los cambios propuestos por el responsable de la migración, o de validarlos (según los requerimientos de la firma del proyecto). Responsable de testeo de aplicaciones: RELLENAR NOMBRE. En el equipo de testeo deberían estar todos los Jefes de Sección de Desarrollo implicados en el proyecto, así como los usuarios que se considere oportuno para


Page 12 of 102


probar las funcionalidades básicas de los sistemas de información que sean críticos y deban estar operativos al arrancar con la nueva instancia productiva. Hay que tener muy presente al equipo de testeo, puesto que de ellos va a depender una grandísima parte del éxito de la migración, puesto que solo si se prueba bien el entorno serán detectados las potenciales incompatibilidades entre versiones a reparar.

Buenas prácticas en la configuración de SQL Server 2008 R2 En el futuro entorno de producción de SQL Server 2008 R2, se recomienda seguir estas pautas para sacar el mayor provecho a SQL Server 2008 R2. NOTA: Todas estas pautas se recomienda seguirlas en cualquier servidor donde residan instancias de SQL Server

Alineamiento de particiones Si el entorno de producción involucra un Windows Server 2008 R2, y desde las herramientas del propio sistema operativo se han creado las particiones, este apartado no hace falta validarlo puesto que por defecto realiza un alineamiento de particiones de 1Mb: Referencia: http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fded599bac8184a/Perf-tun-srv.docx (página 30, sección DISKPART) Si el entorno de producción involucra por contra un Windows Server 2000 o 2003, o el subsistema de disco ha sido particionado bajo las herramientas administrativas de un Sistema Operativo previo, se recomienda realizar un alineamiento de las particiones donde se albergarán los ficheros .mdf y .ldf de las Bases de datos utilizando diskpart.

Figura 3-1: Diagrama de alineamiento en almacenamiento NTFS


Page 13 of 102


Nota: Este diagrama se corresponde con una unidad de almacenamiento por defecto de NTFS (4kb). El diagrama no se encuentra a escala (ver que los trozos 1 y 2 tienen el mismo tamaño a pesar de no serlo realmente) Asumiendo un valor de 64kb por banda del disco, existen 8 sectores de 512B por cada cluster de 4Kb NTFS y existen 16 clusters de 4Kb por cada banda de 64Kb. Nótese que existen sectores ocultos (63 por defecto en el ejemplo desalineado y 64 en el ejemplo alineado) En el ejemplo, la línea 3 se encuentra desalineada mientras que la 4 está alineada Teniendo esto presente, se puede ver como cada lectura enésima, produce un salto en la banda en el caso de los sectores desalineados, debido a que el último cluster de 4Kb no ha cabido completamente en la misma y se encuentra en otra diferente. Esto produce que al realizar la lectura, se tengan que realizar dos accesos a disco. Con el valor por defecto de 4Kb por cluster, cada 16 lecturas, se tiene que realizar una lectura extra. Para conocer el estado del alineamiento de las particiones actualmente, podemos lanzar la siguiente consulta WMI desde powershell:

gwmi –query “SELECT Name,Size,StartingOffset from Win32_DiskPartition” Siendo Name, la ubicación proporcionada por el subsistema de disco para dicha particion, Size el tamaño de la misma, y StartingOffset la posición de comienzo de la misma, dentro del disco.

Figura 3-2: Consulta gwmi en cmd.exe


Page 14 of 102


Para más información sobre alineamiento de particiones: http://technet.microsoft.com/enus/library/cc766465.aspx sección “alignment”

Formateo de NTFS a bloques de 64kb Los discos que alberguen los ficheros de logs y datos se han de formatear a 64kb por bloque para mejorar el rendimiento de SQL Server. Con ello favorecemos que se almacenen en un mismo bloque, lo que se denominan “extensiones” (conjuntos de 8 páginas). De esta forma se mejorarán las lecturas en los casos en los que SQL Server decida realizar operaciones de lectura adelantada.

Figura 3-3: Recomendacion de formato mediante interfaz windows Referencia: http://download.microsoft.com/download/d/9/4/d948f981-926e-40faa026-5bfcf076d9b9/SAP_SQL2005_Best%20Practices.doc (página 67)

Log on as a service Se recomienda definir un grupo de usuarios dentro del dominio que levante los servicios de SQL Server. Si el servicio va a estar dentro de un entorno clusterizado, para que no ocurra ningún problema al levantar los servicios, se recomienda dar a dichos usuarios el permiso de “log on as a service”. Para ello podemos entrar en “Administrative Tools” -> “Local Security Policy” y mediante botón derecho dentro de “Local Policies”->”User Rights Assignment”->”Log on as a service”, añadimos el grupo.


Page 15 of 102


Figura 3-4: Aplicacion de Seguridad “Log on as a service”

Lock pages in memory Es altamente recomendable configurar “lock pages in memory” para SQL Server. Para ello podemos entrar en “Administrative Tools” -> “Local Security Policy” y mediante botón derecho dentro de “Local Policies”->”User Rights Assignment”->”lock pages in memory”, añadimos el usuario que levanta el servicio de SQL Server.

Figura 3-5: Aplicacion de Seguridad “Lock pages in memory” Con este permiso, nos aseguraremos que SQL Server no paginará la memoria destinada al motor, a disco. Mejoraremos con ello el rendimiento del sistema en entornos con mucha presión de memoria. Referencia: http://technet.microsoft.com/en-us/library/ms190730.aspx


Page 16 of 102


Instant File Initialization Para poder sacarle ventaja a las capacidades de inicialización instantánea de ficheros, hemos de agregar el permiso SE_MANAGE_VOLUME_NAME a la cuenta del servicio que levante SQL Server. Los usuarios de administración locales de Windows poseen dicho permiso habilitado, pero dado que se presupone que un usuario con permisos mínimos del dominio levante los servicios, hemos de agregarle dichos permisos. Dicho permiso se concede cuando les añadimos la política de seguridad “Perform Volume Maintenance Task”.

Figura 3-6: Aplicacion de Seguridad “Instant file initialization” Referencia: http://msdn.microsoft.com/en-us/library/ms175935.aspx

Configuración de seguridad básica Permisos de sysadmin De forma predeterminada, los miembros de BUILTIN\Administrators poseen derechos de administración. Se recomienda evitar que ninguno de los logins sea incluido en el grupo de usuarios BUILTIN\Administrators.

Permisos de la cuenta de servicio de SQL Server Se recomienda que los servicios de SQL Server sean iniciados por un una cuenta del dominio, y que esta misma tenga los mínimos permisos necesarios (algunos de los que debe tener ya se han enunciado anteriormente) para minimizar un potencial riesgo de seguridad en caso de exploit futuro.


Page 17 of 102


Por ello, se recomienda crear usuarios del dominio con los mínimos privilegios posibles para levantar los servicios de SQL Server, SQL Server Agent, Reporting Services y Analysis Services.

Sql Server Auditing Asegurarse que existe la auditoria de loggins fallidos. Con ella, el sistema captura tanto intentos infructuosos a SQL Server de logins Windows y sql. De esta forma se pueden detectar ataques por fuerza bruta.

Figura 3-7: Configuración básica

Puerto de escucha de SQL Server Se recomienda cambiar el puerto de escucha de SQL Server 2008 R2 para que no sea utilizado el puerto por defecto (1433). Para ello, es tan fácil como entrar en el “SQL Server Configuration Manager”-> “SQL Server Network Configuration”-> “Protocols for $(InstanceName)”

Figura 3-8: Propiedades TCP/IP de instancia © Solid Quality™ Press

Page 18 of 102


Y escribir en el TCP Port un valor fijo (eliminando el texto existente en “TCP Dynamic Ports”. NOTA: Recuerda reiniciar la instancia SQL Server

Ofuscar el servicio SQL Server a conexiones externas Suele ser común pensar en detener el servicio SQL Browser para dificultar la labor de detección de instancias de SQL Server en la red. Ciertamente, este servicio si se para, producirá que no podamos realizar consultas a ningún sitio para determinar el puerto y nombre de instancia al que conectarnos… El problema de detener el servicio de SQL Browser es que dicho servicio no solo es utilizado para eso, sino que el detenerlo puede dar lugar a verdaderos quebraderos de cabeza en según qué escenarios (clustering, conexión DAC con nombre de instancia, …) Lo cierto es que no es necesario detener el servicio para “ofuscar” la conexión hacia SQL Server, puesto que a nivel de protocolos de red, es posible marcar la instancia como “oculta”, de forma que solo conociendo su nombre de instancia y puerto, seamos capaces de conectarnos a ella.

Figura 3-9: Ofuscación de instancia Según se puede apreciar en la imagen, al hacer click sobre “Protocols for xxxx”, disponemos de la opción de ocultar la instancia (que por defecto está a No). Con esto no queremos dar la sensación al lector de que el servicio se encuentra a salvo de detectores de SQL Server, pero al menos se lo ponemos más difícil impidiendo que el servicio SQLBrowser devuelva información sobre esta instancia. A partir del momento en que se active, ya no se listará en el buscador de instancias SQL Server.


Page 19 of 102


4. Planificación de la migración Antes de realizar la planificación de la migración, hay que tener presente una serie de cambios de arquitectura y mejoras de herramientas, que han derivado entre otras cosas, a la depreciación y descarte de algunas funcionalidades. Por tanto, previa a cualquier planificación se recomienda revisar encarecidamente los siguientes apartados para detectar potenciales pérdidas de funcionalidad actual que podamos sufrir.

Características de SQL Server Obsoletas y/o discontinuadas Existen una serie de características que serán eliminadas de la siguiente versión de SQL Server, pero que siguen funcionando en la versión 2008 R2 mediante lo que se denomina “Compatibilidad hacia atrás”: http://msdn.microsoft.com/es-es/library/cc707789.aspx Además, existen una serie de características que ya no se encuentran disponibles en la nueva versión de SQL Server 2008 R2. Para más información: http://msdn.microsoft.com/eses/library/cc707782.aspx

SQL-DMO Se ha actualizado la librería de SQL-DMO de versiones anteriores para dar soporte a funcionalidades propias de SQL Server 2008 R2, pero simplemente por compatibilidad hacia atrás. Evite usar esta característica puesto que será eliminada en futuras versiones de SQL Server. Para más información: http://msdn.microsoft.com/es-es/library/ms132055.aspx

Utilidades osql e isql Se ha modificado la herramienta osql para eliminar el soporte de consultas ODBC. Para mantener scripts que sean funcionales con la versión de osql de SQL Server 2000, lea el siguiente documento: http://msdn.microsoft.com/es-es/library/ms174190.aspx Por otra parte, se ha eliminado definitivamente el soporte para isql. Aparece con SQL Server 2005 el reemplazo a dichas herramientas mediante la utilidad sqlcmd, que es útil tanto a nivel de script T-SQL en SQL Server Management Studio y a nivel de consola de sistema operativo. Para más información sobre la utilidad sqlcmd: http://msdn.microsoft.com/eses/library/ms162773.aspx


Page 20 of 102


Bcp En la versión de SQL Server 2000, la utilidad de carga masiva de datos por línea de comando solo requería los permisos INSERT y SELECT en la tabla destino de la carga de datos.

Bcp IN -c -T Desde la versión SQL Server 2005 se necesita también el permiso ALTER sobre la tabla, puesto que se permite el chequeo de restricciones y el lanzamiento de triggers durante la carga por parte de opciones de ejecución de la herramienta.

Bcp IN -c –T –h “CHECK CONSTRAINTS, FIRE TRIGGERS” Al contrario que ocurria con la versión anterior de bcp, no existe una pérdida de rendimiento considerable en la carga. Para más información: http://msdn.microsoft.com/es-es/library/ms186247.aspx

Rebuild.exe En SQL Server 2008 R2 no se soporta Rebuild.exe. Han de revisarse todos aquellos scripts que utilizan dicha herramienta para adaptarlos a la nueva opción REBUILDDATABASES de la utilidad de Setup.exe de SQL Server 2008 R2. Para más información: http://msdn.microsoft.com/es-es/library/ms144259.aspx

SQL Mail Pese a que SQL Mail fue marcado como obsoleto ya en SQL Server 2005, todavía es posible utilizarlo en SQL Server 2008 R2. Se recomienda además, que sean revisados aquellos scripts que mandan ficheros adjuntos mediante SQL Mail, puesto que la versión de SQL Server 2008 R2 no soporta esta sfuncionalidad si no se está utilizando autentificación Windows para el cliente SQL Mail. Se recomienda utilizar en su lugar, Database Mail, puesto que es completamente independiente de APIs externas como MAPI, utilizando en su lugar el framework .NET. Para más información: http://msdn.microsoft.com/es-es/library/ms187891.aspx

English Query Este conjunto de herramientas que proporcionaba una interfaz “natural” de consulta a la BBDD fue ya eliminado de soporte en SQL Server 2005 y por tanto no está soportado ya en SQL Server 2008 R2. Pese a que no es posible instalarlo en actualizaciones side-by-side, en actualizaciones in-place no se toca.

Surface Area Configuration © Solid Quality™ Press

Page 21 of 102


Esta herramienta que apareció con SQL Server 2005 ha sido descontinuada en SQL Server 2008 R2. La razón no es otra que la aparición del framework de administración declarativa (DMF), donde podremos configurar la faceta “Surface Area Configurator” realizando las mismas acciones que realizábamos anteriormente con la herramienta de SQL Server 2005. Para más información: http://msdn.microsoft.com/es-es/library/cc707782.aspx

Resumen de equivalencias entre herramientas de SQL Server 2000 y 2008 R2 SQL Server 2000

SQL Server 2008 R2

Enterprise Manager

SQL Server Management Studio

SQL Server Reporting Services 2000

SQL Server Reporting Services + Report Builder

SQL Server Profiler

SQL Server Profiler

Analysis Manager

Bussiness Intelligence Management Studio

Data Transformation Services (DTS)

Sql Server Integration Services (SSIS)

Isql/osql

Sqlcmd/powershell

Sql Mail

Database Mail

Configurador de superficie

Framework de administración declarativa (DMF)

English query

Obsoleto

Planes de mantenimiento (a traves de trabajos de SQL Server Agent)

Planes de mantenimiento (a través de paquetes SSIS)

Index Tunning Wizard (ITW)

Database Tunning Advisor (DTA)

SQL-DMO

SQL-DMO (solo por compatibilidad hacia atrás)

BCP

BCP (mejorado)


Page 22 of 102


Migración del motor relacional El siguiente apartado condensa las recomendaciones específicas para la migración del motor relacional.

Fases de una migración “side-by-side” A la hora de acometer una migración de SQL Server, el siguiente conjunto de tareas debe llevarse siempre a cabo: • • • • •

•

Ejecución del SQL Upgrade Advisor Interpretación y explicación del resultado del SQL Upgrade Advisor Instalar SQL Server 2008 R2 siguiendo buenas prácticas Plantear migración de paquetes DTS a SSIS o ejecución en modo compatibilidad. Plantear migración de Cubos SQL 2000 a 2008 R2 recreándolos desde 0, actualizándolos automáticamente con el asistente o simplemente manteniendo la instancia de SQL 2000 pero atacando a SQL Server 2008 R2 Creación de un guión de migración para el dia de paso a producción y testearlo en pre-producción.

Independientemente del modelo de migración a implementar (“in-place” ó “side-by-side”), se recomienda siempre realizar los pasos 3 al 7 del proceso de migración del motor relacional.

Minimizar el proceso de actualización Para tratar de minimizar el proceso de migración hacia SQL Server 2008 R2, se propone al lector las siguientes prácticas previas al dia de la misma: •

•

•

Validar requerimientos de instalación de actualizaciones “in-place”. Disponer del service pack y actualización necesaria para poder realizar la migración hacia SQL Server 2008 R2, así como la correcta validación de los requerimientos de actualización propuestos por la herramienta “SQL Server Upgrade Advisor”. Pese a que esto es necesario en cualquier tipo de actualización, es especialmente importante en actualizaciones “in-place”, para evitar retrasos el dia “D”. Preinstalar componentes .NET y de Windows necesarios. Se recomienda instalar la versión .NET 3.5 SP1 y Windows Installer (msi) 4.5 de forma previa, en el servidor destino. Esto puede hacerse mediante descarga individual o desde el propio proceso de instalación de SQL Server 2008 R2 (que ya contiene estos instalables). La instalación de Windows Installer 4.5 requerirá un reinicio del Sistema Operativo. Preinstalar herramientas de administración. En el proceso de instalación, si se seleccionan, se van a instalar las herramientas de administración de sql server y desarrollo de inteligencia de negocio. Estas


Page 23 of 102


•

•

•

•

herramientas son tanto SQL Server Management studio, como el propio Visual Studio 2008 R2 Business Intelligence. Si ya se encuentran instaladas y actualizadas como mínimo al SP1, podremos evitarnos el tiempo de instalación el mismo dia de actualización. Precrear usuarios del dominio. Se recomienda disponer de usuarios del dominio específicos para cada servicio de SQL Server. Es recomendable tener dichos usuarios y grupos precreados antes de la instalación, para no invertir tiempo en ello. Chequear consistencia de datos. Es altamente recomendable realizar un chequeo de consistencia de todas y cada una de las bases de datos a migrar, de forma previa a su migración. Puesto que es un proceso costoso, se recomienda que sea realizado el dia anterior al de la migración, para evitar hacerlo el mismo dia. Formación para administradores de base de datos. No menos importante es la formación de los DBA que se van a encargar de la nueva/s instancia de SQL Server 2008 R2. Antes de cualquier migración debe existir un proceso de formación/adaptación a SQL Server 2008 R2, para que los DBA sean capaces tanto de administrar, como de desplegar características nuevas. El cambio que existe entre SQL Server 2000 y SQL Server 2008 R2 es tan grande y las mejoras son tantas, que no es viable ponerse a aprenderlas una vez se ha migrado el entorno. Disponer de este conocimiento en etapas tempranas de la planificación de la migración, mejorará el tiempo de despliegue en sí mismo. Formación para desarrolladores de base de datos y equipo de Inteligencia de Negocio. El producto incorpora nuevas funcionalidades desde el foco de desarrollo de aplicaciones y análisis de información, y es deseable que los equipos involucrados conozcan y puedan utilizar todas estas novedades que redundan directamente en la eficiencia y productividad de los desarrollos; por ejemplo, las capacidades de SSIS desde el punto de vista de usabilidad y desarrollo hacen que tareas anteriormente realizadas con DTS conlleven la mitad de tiempo en desarrollo, pruebas y despliegue que anteriormente. En la misma línea están las nuevas construcciones del lenguaje TSQL como la sentencia MERGE, particioamiento de información, gestión de información espacial, tipos de datos nuevos como Filestream, o integración de .NET CLR en el gestor de bases de datos.

Planificación de la migración La planificación de la migración del motor relacional se compone de tres grandes apartados: •

Análisis de consultas dinámicas generadas por las aplicaciones que explotan las bases de datos.


Page 24 of 102


•

•

•

•

Hemos de realizar una traza de consultas que llegan al motor, para determinar si existe código en las aplicaciones cliente depreciado. Para su análisis nos apoyaremos en SSUA (Sql Server Upgrade Advisor). Ver apartado “análisis de consultas dinámicas”. Análisis de objetos estáticos de las bases de datos y servicios a migrar Utilizando SSUA, obtendremos los reportes de migración que deberemos analizar para tratar de superar incompatibilidades. Ver apartado “Interpretación y explicación del resultado del SQL Upgrade Advisor” Modificación de incompatibilidades en origen Pese a no ser requerimiento imprescindible, es altamente recomendable salvar todas las incompatibilidades detectadas en los puntos anteriores antes de acometer la migración. Esto nos evitará tener que lidiar con los problemas sobre la BBDD migrada a 2008 R2, teniéndola que configurar en compatibilidad 90 u 80 por dichos requerimientos. Análisis de interconexión o De instancias SQL Server o De bases de datos en la misma instancia SQL Server Es de vital importancia conocer las relaciones de dependencia entre instancias de motores relacionales y bases de datos. Esto es debido a que al migrar de un motor a otro en entornos side-by-side, por regla general también se migran nómbres de máquina, direccionamiento IP,…y obviamente todo debe funcionar, por lo que si perdemos la pista a una aplicación que conecta contra la instancia o viceversa, incurrimos en errores potencialmente críticos Análisis de aplicaciones que utilizan la instancia SQL Server Al igual que al analizar las interconexiones entre instancias y bases de datos, debemos conocer qué aplicaciones y equipos conectan contra la instancia, puesto que debemos ser capaces de identificar a todas las aplicaciones que se vean afectadas.

Analisis de interconexiónes En este punto se van a tratar aspectos relacionados con la detección de interdependencias de instancias y bases de datos de una migración. La importancia de una buena detección de interconexión entre instancias va a determinar como de fiables al hacer las estimaciones de costes y tiempos vayamos a ser en fases tempranas del proyecto, a pesar de que obviamente si no lo detectamos correctamente incurriremos en una mala solución de migración.


Page 25 of 102


Figura 4-1: Diagrama de dependencias entre instancias Nota: La imagen anterior proviene de un escenario real con nombres renombrados por seguridad. Generado automáticamente con software de análisis de migraciones propietario de SolidQ De este análisis, obtendremos información relativa a: • •

¿Qué servidores abren conexiones hacia la instancia a migrar? Flechas de entrada hacia el servidor ¿Hacia qué servidores abre conexiones la instancia a migrar? Flechas de salida del servidor

Por tanto, debemos analizar la instancia a migrar en busca de: • • • •

¿Qué servidores vinculados existen hacia otras instancias? ¿Qué componentes crean servidores vinculados al vuelo mediante sp_addlinkedserver? ¿Qué componentes utilizan OPENROWSET? ¿Qué componentes utilizan OPENDATASOURCE?

Visto el diagrama anterior, no será lo mismo migrar la instancia “I”, que la instancia “C”, por ejemplo, ya que queda bastante patente que la instancia “I” posee relaciones hacia 6 instancias con entrada-salida, mientras que la instancia “C” solo posee relaciones de entrada. Y lo mismo, pero buscando en trazas de SQL Server Profiler, puesto que recordemos que una aplicación también puede realizar lo propio y trabajar al vuelo con estas opciones.


Page 26 of 102


Pero al igual que buscamos dependencias entre distintos equipos, también puede darse el caso de ser necesario obtener dependencias de bases de datos:

Figura 4-2: Diagramas de dependencia entre bases de datos

NOTA: Las imágenes anteriores provienen de escenarios reales de dependencias entre bases de datos, generadas con software propietario de SolidQ para análisis de migraciones.


Page 27 of 102


¿Por qué querríamos calcular dependencias entre bases de datos? Si nuestra migración no va a ser de toda la instancia completa, sino de algunas bases de datos, que serán movidas al nuevo servidor en 2008 R2, debemos conocer las implicaciones de llevarnos dichas BBDD a otro equipo. Dicho de otro modo, deberemos saber qué bases de datos deberemos llevarnos en bloque, o qué queries u objetos modificar para que sigan funcionando. Buscaremos los siguientes patrones: -

-

Accesos a objetos utilizando nomenclatura de 4 partes: SERVER.BBDD.SCHEMA.OBJECT En este caso, obviamente SERVER debe ser el mismo server y BBDD debe ser una BBDD diferente a la que se está conectado Accesos a nombres de 3 partes: BBDD.schema.object Al igual que antes, BBDD deberá ser un nombre de BBDD diferente a la que se está conectado

Para información sobre ayuda para crear los scripts ir a la siguiente sección del apéndice.

Instalación y ejecución de SQL Server Upgrade Advisor La herramienta se encuentra tanto en el propio CD de instalación de SQL Server 2008 R2, como disponible para descarga en la siguiente ubicación: Link x86: http://go.microsoft.com/fwlink/?LinkID=188397&clcid=0x409 Link x64: http://go.microsoft.com/fwlink/?LinkID=188398&clcid=0x409 En caso de utilizar la herramienta incluida en el DVD del producto, se recomienda validar la existencia de versiones nuevas de la herramienta (opción “search for product updates”).

Figura 4-3: Instalación de SSUA © Solid Quality™ Press

Page 28 of 102


Al contrario que la herramienta de actualización del motor propiamente dicha, SQL Server Upgrade Advisor (SSUA) está pensado para instalarse en un equipo diferente al de producción, por lo que está preparado tanto para solicitar la instancia y servicios a analizar, como el usuario (con permiso sysadmin) que necesitemos para conectar y realizar el análisis. A continuación se expone el análisis realizado sobre los resultados proporcionados por la herramienta SQL Upgrade Advisor sobre un supuesto entorno de producción. En él, podremos ver algunas de las incidencias detectadas mas habituales a la hora de migrar de SQL Server 2000 a SQL Server 2008 R2: 1. Una vez instalada la herramienta, el siguiente paso es ejecutarla para obtener el informe de migración 2. Luego pulsamos sobre “Launch Upgrade Advisor Analysis Wizard” y seguidamente seleccionamos los componentes que deseamos actualizar, así como el servidor donde se encuentran instalados:

Figura 4-4: Según el proyecto, se analizarán los servicios pertinentes


Page 29 of 102


3. Ahora la herramienta nos irá solicitando las credenciales necesarias por los servicios para poder realizar el análisis

Figura 4-5: Conexión a instancia 4. En el caso del servicio del motor relacional, la herramienta nos solicitará información sobre qué bases de datos deseamos analizar:

Figura 4-6: Selección de bases de datos y ficheros a analizar 5. Una vez seleccionadas dichas bases de datos, podremos continuar pulsando en siguiente y dejando que la herramienta comience el análisis Una vez finalizado el análisis por parte de la herramienta, el siguiente paso será visualizar los informes generados para su posterior análisis de resolución de conflictos.


Page 30 of 102


Visualizar e interpretar informes generados por SSUA Una vez la herramienta ha finalizado el análisis, disponemos de una opción para visualizar sus resultados de forma cómoda. Para ello, dentro de la propia herramienta SSUA, podemos hacer click en “Launch Upgrade Advisor Report Viewer”

Figura 4-7: Abrir reporte de resultados SSUA La siguiente imagen ilustra las incidencias detectadas por el asesor de actualización de SQL Server lanzado contra una instancia de SQL Server 2000 de producción de ejemplo:

Figura 4-8: Ejemplo de resultados de análisis SSUA © Solid Quality™ Press

Page 31 of 102


Los XML que genera dependen de la selección de análisis realizada de forma que: • • •

AS.xml es el análisis de Analysis Services DE.xml es el análisis del motor de base de datos (Database Engine) DTS.xml es el análisis de los DTS

Los errores que se van a tratar en este punto, son los errores que mayor frecuencia de aparición tienen en los proyectos de migración de SQL Server 2000 a 2008 R2; entender tanto su aparición como su solución es de vital importancia para el proyecto global de migración.

Motor de base de datos A continuación se detalla el análisis de cada una de las puntualizaciones proporcionadas por SSUA:

Mensaje de advertencia sobre imposibilidad de detección de potenciales problemas

Figura 4-9: Mensaje genérico La herramienta nos informa que existen potenciales problemas de actualización del motor de BBDD que no pueden ser detectados de forma automática con certeza y nos invita a revisarlos manualmente: •

Cambios de collation Hemos de cerciorarnos que al migrar, el collation del motor destino sea idéntico. Es importante tenerlo en cuenta durante el proceso de instalación de la nueva instancia SQL 2008 R2 para que coincida con el antiguo SQL Server 2000.

•

Configuraciones de max server memory En SQL 2000, si definimos un “max server memory”, una consulta que puntualmente requiera mas memoria y esté disponible, podrá acceder a ella. Por el contrario, desde SQL 2005, si una consulta necesita más memoria de la máxima configurada, esta no será asignada y devolverá un error de tipo “insufficient system memory”. Se nos avisa de ello para que seamos conscientes.


Page 32 of 102


•

Cambio de modo de compatibilidad Por defecto, al migrar una BBDD, su modo de compatibilidad no varia. Por tanto hemos de cambiar su modo de compatibilidad de 80 (sql server 2000) a 100 (SQL Server 2008 R2) mediante la instrucción “ALTER DATABASE database_name SET COMPATIBILITY_LEVEL = { 80 | 90 | 100 }” ó mediante el procedimiento almacenado “sp_dbcmptlevel” (depreciado). Este paso queda reflejado en el apartado de pasos necesarios para el proceso de migración.

•

Tipos de datos char(0),varchar(0) y nvarchar(0) no soportados En SQL 2000, se pueden definir columnas calculadas que almacenen cadenas vacías, almacenándolas como cadenas de longitud 0. Desde SQL Server 2005 su comportamiento varía, y por defecto son creadas con un tamaño mínimo de 1. Si se detecta esta situación, hay que volver a recrear la columna calculada con un tamaño mínimo de 1.

•

UNION Cuando un operador UNION está dentro de una instrucción INSERT, desde la versión de SQL Server 2005 se convierte el tipo de datos de cada operación UNION por separado, según las reglas de la conversión de tipo de datos. En SQL Server 2000, se hacia la conversión directamente al tipo de datos de la tabla destino. Esto puede incurrir en problemas ya que operaciones que en SQL Server 2000 no producían error, si pueden hacerlo en 2005 y 2008 R2. Para validar este apartado, lo mejor es que se pruebe la aplicación una vez se haya migrado la BBDD en un entorno de preproducción y su modo de compatibilidad esté asignado ya a 100 (SQL Server 2008 R2)

•

Vistas indexadas Desde SQL Serve 2005, las referencias a literales de cadena que se convierten de manera implícita en datetime y smalldatetime no son deterministas. Sus resultados dependen de LANGUAGE y DATEFORMAT de la sesión del servidor, por lo que CONVERT(datetime,'30 listopad 1996',113) puede valer diferente en función de LANGUAGE. La conversión implícita de datos de caracteres no Unicode entre intercalaciones ya no son deterministas. Además, la creación de índices en vistas que contienen estas expresiones no se admite ni en el nivel de compatibilidad de base de datos 90 ni en nivel 100. Aunque puedan mantenerse las vistas existentes que contengan estas expresiones de una base de datos actualizada, el optimizador de consultas no las tendrá en cuenta en los planes de consulta, ya sea el nivel de compatibilidad 80, 90 o 100.


Page 33 of 102


Para solventar esta situación, desde la versión de SQL Server 2005, se debe convertir explícitamente el literal al tipo de fecha deseada mediante un estilo de formato de fecha determinista. Ver CAST y CONVERT (Transact-SQL). Por lo tanto, partir del momento de la migración, si se utilizan conversiones implícitas de cadena a fecha en vistas indizadas existentes que se han actualizado a SQL Server 2008 R2, hay que asegurarse de que los valores LANGUAGE y DATEFORMAT son coherentes en las bases de datos y en las aplicaciones para impedir posibles daños en las vistas indizadas. • •

FOR XML Desde SQL Server 2005, un carácter de 3-bytes Unicode genera 6 caracteres en XML, mientras que en SQL Server 2000, se generaban 8 caracteres. Uso de objetos del sistema Se han modificado muchos de los procedimientos almacenados y tablas del sistema entre las versiones SQL Server 2000, 2005 y 2008 R2 (especialmente entre 2000 y 2008 R2), por lo que si se consulta información directamente sobre ellos hay que repasar si es correcto. Entre otras cosas, los objetos del sistema ahora residen sobre el esquema sys, no sobre dbo y residen sobre cada BBDD en lugar de únicamente sobre la BBDD master.

•

Cambio en invocaciones múltiples de funciones RAND y NEWID En SQL Server 2005 y 2008 R2, la invocación múltiple de estas funciones no genera varios valores, al contrario de lo que ocurre en SQL Server 2000. Se puede comprobar su comportamiento lanzando la siguiente consulta T-SQL contra un servidor SQL 2000 y un SQL 2008 R2

SELECT Column1, Column1 FROM ( SELECT RAND() Column1 FROM ( SELECT 1 c UNION SELECT 2 c )s )t •

•

WITH CHECK OPTION INSERTS y UPDATES pueden fallar sobre vistas creadas con WITH CHECK OPTION cuando incurren en tablas remotas. Recrear la vista sin WITH CHECK OPTION para evitar este error Ensamblados SQLCLR SQL Server 2008 R2 instala .NET Framework 3.5 SP1, que se encarga de actualizar las


Page 34 of 102


•

•

•

•

bibliotecas de la memoria caché de ensamblados global (GAC). Si tiene bibliotecas no admitidas registradas en una base de datos de SQL Server, es posible que la aplicación de SQL Server deje de funcionar después de realizar la actualización a SQL Server 2008 R2. El motivo es que cuando se da servicio o se actualizan bibliotecas de la GAC, no se actualizan los ensamblados de SQL Server. Si un ensamblado existe tanto en una base de datos de SQL Server como en la GAC, las dos copias deberán coincidir exactamente. Si no coinciden, se producirá un error cuando la integración CLR de SQL Server use el ensamblado. Para obtener más información, vea “Bibliotecas de .NET Framework admitidas” (http://msdn.microsoft.com/eses/library/ms403279.aspx). Después de actualizar la base de datos, dé servicio o actualice la copia del ensamblado situada en las bases de datos de SQL Server con la instrucción ALTER ASSEMBLY. Para obtener más información, vea el artículo “949080 de Knowledge Base” (http://support.microsoft.com/kb/949080). Nuevo error de inicio de sesión incorrecto En SQL Server 2005, se devuelve el error 18452 cuando se usa un inicio de sesión de SQL para conectar con un servidor que está configurado para usar únicamente la autenticación de Windows. En SQL Server 2008 R2, se devuelve el error 18456 en su lugar. Modificaciones en XML de planes de presentación Se ha agregado un nuevo atributo IndexKind al tipo complejo ObjectType en el esquema XML del plan de presentación. En las aplicaciones que validen de forma estricta los planes de SQL Server con el esquema de SQL Server 2005 se producirá un error. Opción recompute Rank a nivel de servidor Esta opción no se admite en SQL Server 2008 R2. Modifique las aplicaciones que actualmente utilizan esta característica lo antes posible. Expresiones XPath y XQuery En SQL Server 2005, se permiten los pasos de una expresión de XQuery o XPath que comienzan con un signo de dos puntos (':'). Por ejemplo, la instrucción siguiente contiene una prueba del nombre (CTR02) dentro de la expresión de ruta de acceso que comienza con dos puntos.

SELECT FileContext.query('for n$ in //CTR return {data )(n$/:CTR02)} ) AS Files FROM dbo.MyTable; En SQL Server 2008 R2, este uso se rechaza porque no cumple los estándares de XML. Se devuelve el error 9341. Como solución hay que quitar el signo de dos puntos inicial o especificar un prefijo para la prueba del nombre, por ejemplo (n$/p1:CTR02) o (n$/CTR02). Como se ha visto, al margen de que exista un componente de análisis estático, la herramienta nos informa de que también deberemos realizar un análisis que valide © Solid Quality™ Press

Page 35 of 102


situaciones imposibles de evaluar automáticamente. Se trata en su mayoría de situaciones no habituales, pero que conviene conocer puesto que en nuestro entorno podemos estar utilizándolas. NOTA: Para información más detallada, consultar http://msdn.microsoft.com/es-es/library/ms143179.aspx

Mensaje de advertencia sobre Búsqueda de Texto (fulltext search)

Figura 4-10: Mensaje para fulltext search Su mensaje es suficientemente descriptivo y se aplica a SQL Server 2008 R2.

Versión de MDAC 2.6

Figura 4-11: Actualizar version MDAC Esta advertencia solo es necesario validarla en escenarios de migración “in-place”, donde hay que actualizar la versión de MDAC para poder conectar contra SQL Server 2008 R2. En el caso de encontrarnos en una migración “Side-by-side” (migración a otro equipo nuevo), donde ya está instalado SQL Server 2008 R2, podremos dar por validado este apartado. NOTA: Dependiendo de la actualización será MDAC 2.8 o superior

Planes de mantenimiento en SQL Server 2008 R2

Figura 4-12: Planes de mantenimiento desfasados


Page 36 of 102


En este apartado se nos informa de que a pesar de que se podrán migrar los planes de mantenimiento creados en la instancia 2000, en SQL Server 2008 R2 se implementan de forma diferente (mediante paquetes SSIS)

Figura 4-13: ORDER BY deprecado

Cláusulas ORDER BY no compatibles Al contrario de SQL Server 2000, en un ORDER BY debemos poner las columnas especificando únicamente el alias proporcionado, o el nombre de dos partes real (TABLA.COLUMNA), pero no está soportado el doble alias ALIASTABLA.ALIASCOLUMNA. Esta validación nos indica que exiten 3 objetos que no funcionarán al poner la BBDD en compatibilidad 100. En estos casos la única solución es recrearlos para evitar este uso incompatible de ORDER BY, actualizándolo a su sintaxis aceptada.

Cláusulas OUTER JOIN depreciadas (*= y =*)

Figura 4-14: OUTER JOIN deprecado El asistente de actualización ha detectado que existen 66 objetos con sintaxis no ANSI SQL para determinar operaciones OUTER JOIN. La única solución para dichos objetos es la de ser modificados para hacer referencia a LEFT OUTER JOIN y RIGHT OUTER JOIN en lugar de sus operadores no compatibles (*= y =* respectivamente).

Políticas de seguridad para usuarios de SQL Server En SQL Server 2008 R2 no es posible crear usuarios con password en blanco y al detectarse esta situación en la instancia de SQL Server 2000 se nos avisa de que es algo que tendremos que modificar en nuestras aplicaciones.


Page 37 of 102


Figura 4-15: Mensaje generic sobre full-text search

Data Transformation Services La siguiente imagen ilustra las incidencias detectadas por el asesor de actualización de SQL Server, lanzado contra una instancia de SQL Server 2000 durante el análisis de los paquetes DTS:

Figura 4-16: Resultados análisis DTS

Instalar DTS en msdb en caso de actualización in-place

Figura 4-17: Mensaje indicando que DTS no está soportado En el caso de una actualización “in place”, es necesario que los paquetes DTS estén almacenados en la base de datos msdb. Si no es el caso, este mensaje podremos obviarlo

Componentes de edición para DTS en SQL Server 2008 R2

Figura 4-18: No se podran editar paquetes DTS en versión 2008 R2


Page 38 of 102


Si estuviéramos en el caso de una actualización “in place”, en el momento que desinstaláramos SQL Server 2000 no podríamos editar ni crear paquetes DTS hasta instalar las herramientas para tal fin sobre SQL Server 2008 R2, cosa que como veremos mas adelante no están soportadas desde SQL Server 2008. Las herramientas en cuestión se pueden encontrar en la siguiente ubicación: http://www.microsoft.com/downloads/details.aspx?FamilyId=C6C3E9EF-BA29-4A43-8D69A2BED18FE73C&displaylang=en en la sección “Microsoft SQL Server 2005 Backward Compatibility Components”

Tareas complejas en DTS no migradas completamente

Figura 4-19: Mensaje indicando que revises los DTS puesto que algunos se han encapsulado como DTS dentro de SSIS debido a su complejidad y se deben reprogramar manualmente

Debido a que existe lógica “compleja” en los DTS, el asistente de migración no podrá migrar al 100% alguna de las partes del mismo, dejándolas como paquete de ejecución DTS de forma interna. Se nos avisa de esta circunstancia, para que lo tengamos en cuenta y en los paquetes de SSIS, realicemos la modificación cuando lo estimemos oportuno, pero ya sobre un paquetes SSIS. En este ejemplo concreto, la parte que no puede convertir automáticamente es la encargada de obtener información de otro motor de base de datos mediante un conector ODBC no estándar instalado en el servidor. Obviamente dicho conector deberá ser instalado en el nuevo servidor y deberemos realizar pruebas de conectividad sobre el mismo para validar si su comportamiento es el correcto en la nueva instancia-servidor.

Aviso de característica depreciada: DTS

Figura 4-20: Mensaje generic indicando que DTS está deprecado


Page 39 of 102


Esta advertencia nos indica básicamente que los paquetes DTS son una característica depreciada que posee compatibilidad en SQL Server 2005 pero que será eliminada en SQL Server 2008 R2 en pro de SSIS. Pese a ello, es posible todavía seguir lanzando DTS desde Sql Server 2008 R2 con sus herramientas de compatibilidad. Esto último no es aconsejable puesto que algunas de las mismas no han sido portadas a Sql Server 2008 R2 y se usan las que en su dia fueron diseñadas para compatibilidad con Sql Server 2005.

Solo la última versión será migrada

Figura 4-21: Se realiza la migración automática de paquetes DTS en su última versión de msdb Se nos advierte que el proceso de migración de DTS está ligado a la última versión del mismo, no migrándose a SSIS el resto de versiones inferiores. El control de versiones se debe llevar a cabo mediante Visual Studio 2008 R2, que es la herramienta de edición de paquetes SSIS.

Análisis de consultas dinámicas La herramienta SSUA realiza un análisis estático de servicios y objetos, pero obviamente no es capaz de prevenirnos acerca de la tipología de consultas que nuestras aplicaciones están lanzando contra el servidor porque las desconoce a priori. Para que sea capaz de analizar la tipología de consultas que nuestras aplicaciones están utilizando tendremos que ayudarlo proporcionándole una traza lo más representativa posible de las consultas que están lanzándose. Gracias a ella, seremos capaces mediante SSUA de analizar la tipología de consultas que está procesando el servidor. Para analizar las consultas dinámicas que las aplicaciones lanzan contra el servidor hemos de crear una traza que capture sentencias ad-hoc, así como sentencias que ejecuten procedimientos almacenados en las BBDD a migrar. Para ello SQL Server 2008 R2 dispone de la herramienta SQL Profiler.

Figura 4-22: Abrir SQL Profiler desde SSMS


Page 40 of 102


Los siguientes pasos, ilustran el proceso de creación de una traza personalizada, que capture por un lado la información necesaria para el análisis, y por otro evite tener que dejar la herramienta de profiler en marcha durante el proceso: 1. Crearemos una nueva traza

Figura 4-23: Crear nueva traza 2. Nos conectaremos a la instancia que alberga las BBDD a migrar (la instancia 2000 o 2005)

Figura 4-24: Configuración de instancia a analizar

3. Haremos click en la sección de eventos de definición de la traza

Figura 4-25: Eventos de traza 4. Seleccionaremos únicamente RPC:Completed y SQL:BatchCompleted, asegurándonos que como mínimo la columna TextData está marcada © Solid Quality™ Press

Page 41 of 102


Figura 4-26: Captura de datos por evento 5. Lanzaremos la traza

Figura 4-27: El boton Run lanza la traza 6. Inmediatamente después de ejecutarla, la pararemos pulsando sobre el botón de “stop”. La razón de esto es que lo queremos será la definición de la traza en T-SQL para que no sea necesario tener SQL Profiler abierto.

Figura 4-28: El boton stop para la ejecución de traza 7. Una vez hemos parado la traza, exportaremos su definición


Page 42 of 102


Figura 4-29: Se puede exporter definición para recreación rápida posterior NOTA: La definición debe coincidir con el motor a analizar (2000 ó 2005) 8. Abrimos el fichero .sql exportado y modificaremos estos dos apartados

Figura 4-30: Existen dos sencillas partes a modificar en el script para creación de traza de profiler. Donde @maxfilesize representa el tamaño en megas máximo que queremos que ocupe la traza (cuando la traza ocupe ese tamaño automáticamente se parará y finalizará; e “InsertFileNameHere” representa la ubicación (local al servidor que estamos analizando) donde se irá escribiendo la traza. © Solid Quality™ Press

Page 43 of 102


9. Ejecución del script En este momento, ejecutamos el script contra la BBDD que deseamos analizar para que comience la captura. A partir de este momento, lo deseable es que todas las aplicaciones que hagan uso de la BBDD a migrar lo hagan, para que cualquier consulta que se lance contra la misma, sea capturada. Lo ideal es que la captura de datos mediante la traza sea realizado contra producción y que se esté capturando un periodo razonable según nuestro proceso de negocio. Si en 3 dias el lector estima que es suficiente para que las aplicaciones hayan podido ejecutar todas las consultas contra la BBDD posible, es suficiente. Por poner un ejemplo real, en la mayoría de proyectos de migración en las que hemos trabajado, se ha capturado información durante 7 dias consecutivos de media (nótese que se habla de rango temporal, no de tamaño de trazas capturado). Para conocer el método de cómo parar y finalizar las trazas, consultar apéndice la sección “Finalización de trazas de profiler”.

Migración de los paquetes DTS a SSIS. Antes de enfocar una migración de paquetes DTS de SQL Server 2000, hay que preguntarse qué estrategia vamos a seguir. De nuevo, SSUA es una excelente herramienta para la planificación, puesto que previo a nuestra migración podemos saber de antemano qué ocurrirá con nuestros paquetes. El cambio de DTS a SSIS no es solo un salto generacional, sino un rediseño completo y desde 0 del planteamiento anterior de la herramienta de carga y transformación de datos. Es por ello que el paquete SSIS resultado puede no migrarse fácilmente mediante el asistente y probablemente contenga porciones de DTS internas que deberemos modificar a posteriori si lo creemos conveniente.

¿Qué ocurre durante la migración? Todo el proceso de migración lo realiza el asistente de migración de DTS que existe en SQL Server 2008 R2 y lo realiza sin alterar la estructura de los paquetes DTS originales a migrar puesto que únicamente los abre momentáneamente para leer su estructura. El proceso de análisis se puede realizar tanto a partir de ficheros DTS que se encuentren en una ruta en disco, como a partir de los DTS que se encuentren alojados en msdb. Algo que debemos tener en cuenta es que el servidor SQL Server 2000 debe tener instalado SP3 como mínimo instalado puesto que en dicho SP se modificó la estructura interna y la forma en que almacenaban los DTS.


Page 44 of 102


Si la migración se realizara “in-place”, justo después de realizar la migración, todavía podríamos seguir accediendo a los DTS de SQL Server 2000, pero no podríamos hacerlo para edición, puesto que las cadenas de conexión se actualizan a SQL Server 2008 R2 y Enterprise Manager de 2000 no puede conectar contra SQL 2008 R2 (ocurrirá lo mismo si migramos paquetes SSIS 2005 con las cadenas de conexión). Para ello tendríamos que utilizar SSMS de 2008 R2. Hay que tener en cuenta que dependiendo de la complejidad de los DTS, puede que el asistente no obtenga la mejor aproximación de solución en términos de rendimiento utilizando SSIS, pero realmente realiza una buena aproximación, que si no nos dice lo contrario el proceso mediante error o advertencia, es completamente equivalente a la implementación DTS. En cualquier caso siempre se recomienda abrir los paquetes SSIS migrados para no solo actualizar cadenas de conexión, sino repasar si los flujos de control han sido correctamente interpretados puesto que en alguna ocasión me he encontrado que pese a no dar advertencia alguna SSUA, se habían quedado sin conectar algunos de ellos.

Guión de migración Migración del motor de base de datos Todos los scripts mencionados en este apartado pueden ser fácilmente generados mediante la aplicación SQL Server Management Studio. Para más información consultar apéndice, sección de generación de scripts de mantenimiento. Se asume que llegados a este punto, se han resuelto todas las advertencias que han sido señaladas por SSUA. De lo contrario podremos encontrar problemas a la hora de afrontar cualquiera de los siguientes pasos. El proceso a seguir el día de la migración de una supuesta base de datos sql server 2000 a producción es el siguiente (en orden): 1. Realizar Backup de las BBDD a migrar 2. Realizar Restore de dichas BBDD en SQL Server 2008 R2 En este punto, las BBDD se encuentran en modo de compatibilidad 80 (SQL Server 2000), por lo que no podemos obtener todo el potencial de SQL Server 2008 R2 (acceso a algunas funciones del sistema, vistas, nuevas cláusulas,…), aunque sí que podemos trabajar con dichas BBDD. 3. Realizar un checkeo físico y lógico de las BBDD restauradas


Page 45 of 102


use database_name go DBCC CHECKDB; GO 4. Cambiar el modo de compatibilidad a 100 (SQL Server 2008 R2) Para ello, vamos a lanzar el siguiente script, que actualizará las BBDD a modo de compatibilidad 100, que nos permitirá obtener todo el potencial y nueva sintaxis de SQL Server 2008 R2

-- Actualización del nivel de compatibilidad a SQL Server 2008 R2 USE [master] GO ALTER DATABASE database_name SET COMPATIBILITY_LEVEL = 100 GO NOTA: Se puede volver a modo de compatibilidad 80 o 90 en cualquier momento si se detecta algún problema de compatibilidad con T-SQL que previamente no haya sido detectado. 5. DBCC UPDATEUSAGE para actualizar el conteo de filas 6. Reconstruir índices Lanzar scripts de reconstrucción de índices. 7. Actualizar estadísticas Lanzar scripts de actualización de estadísticas. NOTA: Hay que actualizar las estadísticas de las tablas y vistas indexadas. 8. Reducción de BBDD


Page 46 of 102


Figura 4-31: Interfaz de configuración de tarea “Shrink database”

Lanzar script de reducción de BBDD en el caso de que no sea habitual realizarlo. Es útil seleccionar “Retain freed space in database files” en el caso de que diariamente se sufran procesos de incorporación de información que hagan crecer las BBDDs; el disponer del espacio de BBDD reservado al sistema operativo nos ahorrará esperas para la obtención de ese recurso cuando sea requerido. 9. Migración de usuarios En la mayoría de situaciones, lo mejor es recrear los usuarios existentes en SQL Server 2000, más aún cuando se han detectado inicios de sesión que no poseen password. Considere que la migración de inicios de sesión con autenticación SQL Server debe realizarse con SIDs en concordancia entre la instancia de SQL Server y la base de datos a la que accede el usuario; para ello debería usar la opción “CREATE LOGIN … WITH SID = XXX”; además, como medida de precaución, recomendamos utilizar el procedimiento almacenado de sistema sp_change_users_login (revise la documentación del producto) para asegurarse que no quedan usuarios de bases de datos huérfanos. 10. Modificar las cadenas de conexión de las aplicaciones para que apunten a la nueva instancia de SQL Server 2005

Patrones de codificación TSQL adaptados para SQL Server 2008 R2 El proceso de migración hacia SQL Server 2008 incluye por supuesto, una serie de tareas que están ligadas al proceso de desarrollo de aplicaciones que explotan la información. Es necesario por tanto, conocer una serie de incompatibilidades existentes en la nueva versión T-SQL de SQL Server 2008 R2 con código proveniente de T-SQL 2000. © Solid Quality™ Press

Page 47 of 102


El siguiente documento pretende dar los aspectos básicos a tener en cuenta a la hora de desarrollar TSQL compatible para SQL Server 2000 y 2008 R2, basado en los patrones encontrados mas frecuentemente en nuestros clientes.

Cláusulas ORDER BY no compatibles Al contrario de SQL Server 2000, en un ORDER BY debemos poner las columnas especificando únicamente el alias proporcionado, o el nombre de dos partes real (TABLA.COLUMNA), pero no está soportado el doble alias ALIASTABLA.ALIASCOLUMNA. En casos existentes, la única solución es recrearlos para evitar este uso incompatible de ORDER BY, actualizándolo a su sintaxis aceptada. Esto es incompatible en SQL Server 2008:

Select columna as alias_columna From dbo.mitabla alias_tabla Order by alias_tabla.alias_columna Esto es compatible

Select columna as alias_columna From dbo.mitabla alias_tabla Order by alias_columna -- Tambien serán compatibles Order by mitabla.columna Order by 1 Order by columna Cláusulas OUTER JOIN depreciadas (*= y =*) Las cláusulas *= y =* no forman parte del ANSI SQL para determinar operaciones OUTER JOIN. La única solución para dichos objetos es la de ser modificados para hacer referencia a LEFT OUTER JOIN y RIGHT OUTER JOIN en lugar de sus operadores no compatibles (*= y =* respectivamente). Esto es incompatible en SQL Server 2008

select * from dbo.EmployeeTerritories et, dbo.Employees e where et.employeeid *= e.employeeid © Solid Quality™ Press

Page 48 of 102


Esto es compatible

select * from dbo.EmployeeTerritories et left join dbo.Employees e on et.employeeid = e.employeeid Tipos de datos char(0),varchar(0) y nvarchar(0) no soportados En SQL 2000, se pueden definir columnas calculadas que almacenen cadenas vacías, almacenándolas como cadenas de longitud 0. Desde SQL Server 2005 su comportamiento varía, y por defecto son creadas con un tamaño mínimo de 1. En nuevos desarrollos hay que prevenirlo puesto que no funcionará en SQL Server 2008 R2.

UNION Cuando un operador UNION está dentro de una instrucción INSERT, desde la versión de SQL Server 2005 se convierte el tipo de datos de cada operación UNION por separado, según las reglas de la conversión de tipo de datos. En SQL Server 2000, se hacia la conversión directamente al tipo de datos de la tabla destino. Esto puede incurrir en problemas ya que operaciones que en SQL Server 2000 no producían error, si pueden hacerlo en 2005 y 2008. Para validar este apartado, lo mejor es que se pruebe la aplicación una vez se haya migrado la BBDD en un entorno de preproducción y su modo de compatibilidad esté asignado ya a 100 (SQL Server 2008 R2) En el siguiente ejemplo se muestra un error de conversión de tipos de datos. En niveles de compatibilidad 80 y anteriores, la constante entera 1 de la primera instrucción SELECT se convierte directamente en el tipo de dato de la columna de destino ReturnedValue, que es varchar(255). En el nivel de compatibilidad 90, el tipo de datos del conjunto de resultados UNION se determina antes de la conversión en la columna de destino. Para la segunda columna de la primera instrucción SELECT, se determina que el tipo de datos sea int. Para la segunda columna de la segunda instrucción SELECT, se determina que el tipo de datos sea varchar(4). Como el tipo de datos int tiene una prioridad mayor que el tipo de datos varchar(4), cuando se determinan los tipos de datos del conjunto de resultados UNION, el valor test se convierte en el tipo de datos int y produce un error de conversión de tipos de datos.

CREATE TABLE #test(ReturnedName varchar(255) NOT NULL, ReturnedValue varchar(255) NULL)

INSERT INTO #test SELECT 'col1', 1 © Solid Quality™ Press

Page 49 of 102


UNION ALL SELECT 'test', 'test' DROP TABLE #test Cuando se lanza contra SQL Server 2000, el código anterior funciona perfectamente, pero al lanzarse contra SQL Server 2008 R2, se devuelve el siguiente código de error: Msg 245, Level 16, State 1, Line 4 Conversion failed when converting the varchar value 'test' to data type int.

Constantes y variables grandes Hasta la aparición de SQL Server 2005 no era posible utilizar tipos de datos varbinary(max), varchar(max) o nvarchar(max). No se trata de ningún error, pero a partir de la aparición de SQL Server 2005, se recomienda la utilización para dichos objetos, de los tipos de datos. Se recomiendan por tanto Varchar(max), varbinary(max) en lugar de declaraciones de varchar(8000), text o image.

FOR XML Desde SQL Server 2005, un carácter de 3-bytes Unicode genera 6 caracteres en XML, mientras que en SQL Server 2000, se generaban 8 caracteres. Hay que comprobar por tanto, que las consultas que utilizan FOR XML, siguen funcionando a la hora de ser recuperada su información por las aplicaciones.

FOR XML AUTO Las consultas que ejecutan FOR XML AUTO, devuelven información sobre aliases de tabla, mientras que en versiones anteriores a SQL Server 2005, se devolvía información relativa a la tabla base. La siguiente consulta

CREATE TABLE Test(id int); INSERT INTO Test VALUES(1); INSERT INTO Test VALUES(2);

SELECT * FROM (SELECT a.id AS a, b.id AS b FROM Test a JOIN Test b ON a.id=b.id)


Page 50 of 102


AS DerivedTest FOR XML AUTO; Devuelve la siguiente construcción XML en SQL Server 2000

Y la siguiente construcción en XML sobre SQL Server 2008 R2

Hay que cerciorarse que las consultas que hacen uso de FOR XML AUTO se comportan de igual manera por las aplicaciones. Si no fuera el caso, habría que adaptar la aplicación o la consulta para que fuera así. Se suministrará una lista con los objetos y consultas que utilizan FOR XML AUTO.

Uso de objetos del sistema Se han modificado muchos de los procedimientos almacenados y tablas del sistema entre las versiones SQL Server 2000, 2005 y 2008 R2 (especialmente entre 2000 y 2008), por lo que si se consulta información directamente sobre ellos hay que repasar si es correcto. Entre otras cosas, los objetos del sistema ahora residen sobre el esquema sys, no sobre dbo y residen sobre cada BBDD en lugar de únicamente sobre la BBDD master.

Cambio en invocaciones múltiples de funciones RAND y NEWID A partir de SQL Server 2005, la invocación múltiple de estas funciones no genera varios valores, al contrario de lo que ocurre en SQL Server 2000. Se puede comprobar su comportamiento lanzando la siguiente consulta T-SQL contra un servidor SQL 2000 y un SQL 2008 r2

SELECT Column1, Column1 FROM ( SELECT RAND() Column1 FROM ( SELECT 1 c UNION SELECT 2 c )s )t WITH CHECK OPTION INSERTS y UPDATES pueden fallar sobre vistas creadas con WITH CHECK OPTION cuando © Solid Quality™ Press

Page 51 of 102


incurren en tablas remotas. Recrear la vista sin WITH CHECK OPTION para evitar este error, en el caso de que exista alguna vista en desarrollo actualmente con dicha declaración. Pese a que no se ha encontrado ningun caso en la junta de Extremadura, se encuentra frecuentemente en escenarios de migración, por lo que se ha creido conveniente comentarlo.

Vistas indexadas Desde SQL Serve 2005, las referencias a literales de cadena que se convierten de manera implícita en datetime y smalldatetime no son deterministas. Sus resultados dependen de LANGUAGE y DATEFORMAT de la sesión del servidor, por lo que CONVERT(datetime,'30 listopad 1996',113) puede valer diferente en función de LANGUAGE. La conversión implícita de datos de caracteres no Unicode entre intercalaciones ya no son deterministas. Además, la creación de índices en vistas que contienen estas expresiones no se admite ni en el nivel de compatibilidad de base de datos 90 ni en nivel 100. Aunque puedan mantenerse las vistas existentes que contengan estas expresiones de una base de datos actualizada, el optimizador de consultas no las tendrá en cuenta en los planes de consulta, ya sea el nivel de compatibilidad 80, 90 o 100. Para solventar esta situación, desde la versión de SQL Server 2005, se debe convertir explícitamente el literal al tipo de fecha deseada mediante un estilo de formato de fecha determinista. Ver CAST y CONVERT (Transact-SQL). Por lo tanto, partir del momento de la migración, si se utilizan conversiones implícitas de cadena a fecha en vistas indizadas existentes que se han actualizado a SQL Server 2008 R2, hay que asegurarse de que los valores LANGUAGE y DATEFORMAT son coherentes en las bases de datos y en las aplicaciones para impedir posibles daños en las vistas indizadas.

Solución de problemas de actualización El momento de detectar problemas de actualización, hemos visto que es el de la planificación. Como ya hemos introducido anteriormente, el mejor escenario es aquel en el que podemos realizar una actualización en un entorno de pruebas, ya que ahí será donde validemos si todo se puede realizar correctamente, y en el caso de que no, poder ver los potenciales errores para poder proporcionar una solución. Las siguiente guía, pretende dar una pauta de inicio por donde comenzar a investigar el origen de un problema ocurrido: •

En la ruta Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG, existe un fichero denominado summary.txt donde podremos encontrar un resumen de la actualización de SQL Server 2008 R2, en el caso de que se haya realizado “in-place”.


Page 52 of 102


•

•

Cada ejecución de setup.exe, creará una carpeta de log, con un formato de nombre similar a YYYYMMDD_hhmmss, de forma que dentro de el, aparecerá información relativa al proceso de instalación Se recomienda buscar por las cadenas de texto “Watson bucket”, “Error:” y “Exception has been”

Para más información: How to: View SQL Server 2008 R2 Setup Log Files

Migración de paquetes DTS a SSIS Si lo que estamos planificando es una migración “Side by Side” la forma más fácil de realizar la migración de nuestros paquetes DTS es desde el propio SSMS 2008 R2 del servidor destino. Para continuar con el proceso de migración, previamente hay que cumplir los requisitos de compatibilidad con DTS de SQL Server 2000. Para ello, se recomienda la lectura de la sección “Requisitos para compatibilidad con SQL Server 2000”. Una vez cubiertos los requisitos en el equipo desde el que realicemos la migración, procederemos con las siguientes instrucciones.

Migración automática • •

Entrar en Management->Legacy->Data Transformation Services Nos ponemos sobre cualquiera de ellos y boton derecho->migrate

Figura 4-32: Migración de DTSs •

Ahora seguiremos el asistente de migración de paquetes DTS a SSIS


Page 53 of 102


Figura 4-33: Pantalla principal de asistente de migración •

Seleccionaremos el origen de datos donde se encuentran los DTS que queremos migrar. En nuestro caso vamos a migrar directamente los del servidor por lo que aplicamos sus credenciales de conexión. Se permite que el origen sea una carpeta donde se encuentran los ficheros .dts

Figura 4-34: Instancia con datos origen de DTSs


Page 54 of 102


•

Seleccionaremos el destino. Lo mejor en nuestro caso es que el destino sea el sistema de ficheros, porque la siguiente acción a realizar una vez migrados los paquetes será editarlos para como mínimo, cambiar sus orígenes de datos

Figura 4-35: Tipo de destino y ubicación

•

Seleccionaremos los paquetes DTS que deseamos migrar con el asistente

Figura 4-36: Resumen •

Por último, se nos solicita la ruta a un fichero de log que se creará durante el proceso y en el que se reportarán las acciones pertinentes y su estado final


Page 55 of 102


Figura 4-37: Ubicación de log de procesamiento •

Por último solo nos queda esperar a que finalice la migración

Figura 4-38: Información de progres

Edición de paquetes SSIS migrados Una vez migrado, debemos editarlo para verificar si la migración ha sido exitosa y para cambiar los orígenes de datos ya que ahora deberemos apuntar a SQL Server 2008 R2 y no a SQL Server 2000.


Page 56 of 102


Una vez abierto el paquete de SSIS (botón derecho->editar), se nos abrirá el entorno de desarrollo de paquetes SSIS (Visual Studio 2008 R2) y entraremos automáticamente en su zona de edición.

Figura 4-39: Componente DTS embebido a editar •

Pulsaremos sobre el botón “Edit Package…”

Figura 4-40: Pantalla de apertura de editor de compatibilidad DTS •

Una vez se nos abra el editor de compatibilidad de paquetes DTS 2000, procederemos a modificar sus orígenes de datos. Lo primero será modificar el origen (llamado en este caso Sybase) para que utilice el ODBC que hemos creado apuntando al servidor (ver apéndice sección Configuración driver ODBC Sybase)


Page 57 of 102


Figura 4-41: Ejemplo de tarea interna como DTS incrustada en SSIS (algo a evitar)

Figura 4-42: Selección de driver


Page 58 of 102


Figura 4-43: Especificación de conexion

•

Lo siguiente será modificar el destino para que apunte a SQL Server 2008 R2

Figura 4-44: Propiedades de la conexión (pulsar sobre la flecha) con botón derecho


Page 59 of 102


Figura 4-45: Propiedades de conexión •

Por último, actualizaremos el flujo de control (que automáticamente nos recreará las transformaciones sin error) y validaremos que es correcto.

Figura 4-46: Propiedades de conexion •

Una vez salvado el paquete DTS, lo siguiente a realizar será actualizar las conexiones del propio paquete SSIS para que apunten a sus orígenes de datos de forma correcta (antes apuntaban a SQL 2000 y ahora deben hacerlo a un SQL 2008 R2)


Page 60 of 102


Figura 4-47: Conexión NOTA: Se recomienda utilizar la seguridad integrada

Importación de paquetes a SSIS Una vez tengamos los paquetes SSIS apuntando correctamente a los servidores y revisada su funcionalidad comprobando que se hace lo que se espera, el siguiente paso es subir a producción el paquete. Para ello: •

Conectamos a Integration Services y “botón derecho->Import Package…”

Figura 4-48: Importar paquete •

Seleccionamos el paquete que queramos subir al servidor


Page 61 of 102


Figura 4-49: Importar paquete Especificamos que queremos que la seguridad de partes sensibles de la configuración del SSIS recaiga sobre el propio motor. Esto es así porque en el caso de haber utilizado conexiones usuario-password por ejemplo, no queremos que aparezca en texto claro en la definición XML del paquete SSIS.

Figura 4-50: Protección de datos sensibles en paquete


Page 62 of 102


•

Si el paquete SSIS estaba cifrado con password (ver apéndice), nos lo va a solicitar antes de proceder con la importación, para asegurarse que disponemos de los permisos necesarios

Figura 4-51: Especificación de contraseña para almacenar datos sensibles en el paquete SSIS

Trabajar en modo compatibilidad 2000 Ya no es posible trabajar con DTS desde SQL Server 2008R2. Esta situación hace imposible que podamos seguir utilizando los DTS de SQL Server 2000 con SQL Server 2008 R2 durante todo el tiempo necesario mientras planificamos la migración real a SSIS bien sea rediseño o migración. Pese a que se indica al lector que existe un método para forzar la compatibilidad con la opción que se permitia en SQL Server 2008, no se recomienda y por tanto se asume que el lector tiene en cuenta este hecho. En caso de encontrarse funcional la opción propuesta, esta debe tomarse como un paso temporal de cara a la migración a SSIS.

Ejecución de paquetes SSIS En el siguiente punto se adjunta una guía de como realizar la ejecución de paquetes SSIS siguiendo varias vías posibles con las herramientas de SQL Server 2008 R2 Manualmente Para lanzar manualmente un paquete SSIS:


Page 63 of 102


•

Conectar al servidor de SSIS (por ejemplo vulcano2):

Figura 4-52: Integration Services en SSMS NOTA: No es posible utilizar las herramientas de SQL Server Express para conectar a Integration Services, hay que utilizar la versión Standard, Developer o Enterprise •

Ir a Stored Packages->MSDB->DTS (la carpeta DTS ha sido creada manualmente por nosotros para el ejemplo)

Figura 4-53: Paquetes SSIS almacenados en BBDD •

Con botón derecho en el paquete SSIS a ejecutar, si lanzar “Run Package”:

Figura 4-54: Lanzar paquete © Solid Quality™ Press

Page 64 of 102


Este es el formulario de ejecución donde poder dar valor a variables. Para terminar ejecutando, click en “execute”.

Figura 4-55: Interfaz de configuración del lanzamiento del paquete

Por código Visual Basic.NET Existen dos opciones para realizar ejecuciones de paquetes SSIS mediante código, la primera consiste en utilizar las clases de la librería Microsoft.SqlServer.ManagedDTS.dll y la otra utilizar la aplicación enominada dtexec que viene con las herramientas de inteligencia de negocio de SQL Server. En ambos casos, hay que instalar como mínimo las herramientas cliente de inteligencia de negocio como vemos en la imagen:

Figura 4-56: Instalación minima recomendada NOTA: La imagen corresponde a instalación de SQL Server express con herramientas avanzadas Versión express con herramientas cliente avanzadas: http://www.microsoft.com/downloads/details.aspx?familyid=B5D1B8C3-FDA5-4508-B0D01311D670E336&displaylang=es


Page 65 of 102


Ejecución mediante código Visual Basic Una vez tenemos las librerías instaladas en el equipo desde donde queramos lanzar los paquetes SSIS, podemos utilizar código como el siguiente para efectuar ejecuciones de los mismos: A continuación vemos como sería el código en Visual Basic.NET para ejecutar un Paquete SSIS. NOTA: Si la aplicación no es .NET (por ejemplo, si es VB6) hay que programar un wrapper de acceso a la libreria ManagedDTS mencionada anteriormente (el código de más abajo es VB.NET). Más adelante, se da opción de utilizar dtexec, si no se quiere implementar dicho wrapper Los paquetes deben estar desplegados en el servicio de Integration Services y además según se puede ver en el ejemplo de código, haberse desplegado sobre la carpeta DTS (no es requisito, pero para el ejemplo se ha realizado de esta forma, para ir alineados con las imágenes anteriores también). En este caso vemos el ejemplo de ejecución de un paquete cualquiera.

Imports DTS = Microsoft.SqlServer.Dts.Runtime

Module Module1

Sub Main() Dim instance As DTS.Application Dim packagePath As String Dim serverName As String Dim serverUserName As String Dim serverPassword As String Dim events As DTS.IDTSEvents Dim returnValue As DTS.Package Dim executionResult As DTS.DTSExecResult

instance = New DTS.Application()


Page 66 of 102


packagePath = "\DTS\ TuPaqueteDTSX " serverName = "tuservidor" serverUserName = "solidq" 'Nombre de usuario serverPassword = "solidq" 'Password de usuario events = Nothing returnValue = instance.LoadFromSqlServer(packagePath, serverName, serverUserName, serverPassword, Nothing)

‘Para asignar propiedades a variables ‘pkg.Variables("VarName").Value = "Value"

executionResult = returnValue.Execute()

If executionResult = DTS.DTSExecResult.Success Then Console.WriteLine("Paquete ejecutado correctamente") Else If executionResult = DTS.DTSExecResult.Failure Then Console.WriteLine("Se produjo un error al ejecutar el paquete") End If End If

Console.ReadKey()

End Sub

End Module NOTA: El usuario que ejecute debe tener permisos en la Base de datos MSDB, puesto que es necesario listar las carpetas acceder a la carpeta DTS y cargar el paquete.


Page 67 of 102


Ejecución mediante línea de commandos dtexec Este método es el más sencillo y consiste en lanzar el paquete utilizando la aplicación dtexec, destinada especialment para ello. Se parte de la base nuevamente en que se ha instalado la herramienta en el cliente y por tanto se encuentra instalada y accessible (por defecto se encuentra en C:\Program Files\Microsoft SQL Server\100\DTS\Binn\) Se trataria por tanto de realizar una llamada desde visual basic a la aplicación dtexec con los parámetros necesarios (ver imagen adjunta como ejemplo sencillo):

Figura 4-57: Ejemplo de ejecución manual mediante dtexec.exe en cmd.exe Por ejemplo, para lanzar el paquete llamado “paquetePrueba” que se encuentra en el servidor “yo-pc\sql2008r2”, utilizando un usuario de sql “usuariosql” y password “passwordusuario”, asignando valor a la variable llamada “miVariable”, podríamos crear una llamada como esta:

Dtexec /ser yo-pc\sql2008r2 /U usuariosql /P passwordusuario /sq paquetePrueba /set \package.variable[miVariable].Value;AquiPonesElValorQueQuieresAs ignar NOTA: Para información sobre los parámetros de entrada podemos utiliza dtexec /? O diréctamente dirigirnos a la web de consulta de dtexec aqui: http://technet.microsoft.com/enus/library/ms162810(SQL.100).aspx Recordemos no obstante, que para ejecutar paquetes SSIS mediante línea de commandos, al igual que si se desea realizer manualmente utilizando el administrador de SQL Server, es necesario disponer localmente del servicio de SQL Server Integration Services en la máquina que lanza la operación dtexec ya que no todos los componentes de SSIS permiten su ejecución sin disponer del servicio instalado localmente. Ejecución remota de paquetes SSIS La ejecución de paquetes SSIS requiere que sea instalado el servicio SQL Server Integration Services en las máquinas que van a lanzarlos. Esto quiere decir que si se desea lanzar por un © Solid Quality™ Press

Page 68 of 102


equipo diferente al de producción (donde se encuentra instalado SSIS) hay que tener instalado dicho servicio. En este apartado veremos cómo conseguir lanzar remotamente dichos paquetes SSIS y que no sea necesaria la instalación de SSIS en los clientes.Para conseguir esto, debemos lanzar los paquetes de forma remota y para ello podemos optar por dos vias: • •

Ejecutar los paquetes remotamente utilizando herramientas como psexec Ejecutar los paquetes remotamente mediante PowerShell

Ejecución mediante psexec Se trata de la forma más facil de todas de conseguir la ejecución remota. Con los permisos apropiados en el usuario que lanza el ejecutable remoto, basta con copiar el ejecutable psexec.exe en alguna ubicación conocida accesible por la variable de entorno $PATH para lanzarlo de la forma siguiente:

Psexec \\servername ejecutable_con_parámetros Es decir, que basta añadir “psexec \\servername” al comienzo de la línea que tenemos preparada para ejecutar por consola dtexec y lo tendremos listo. Permisos necesarios para ejecutar con psexec El usuario que ejecuta finalmente la operación psexec debe ser un usuario dado de alta como administrador local del equipo remoto como requisito imprescindible. Ejecución mediante PowerShell Se trata de utilizar la nueva arquitectura Shell PowerShell de Microsoft, para hacer ejecución remota del ejecutable dtexec. La ventaja frente a psexec es que es más modular y potente encuanto a configuración de seguridad que psexec, pero requiere adaptabilidad por parte de los clientes que finalmente van a lanzar PowerShell. No es tan transparente como psexec y requiere de entre otros, la instalación del propio Shell PowerShell instalado tanto en servidor, como en los clientes. En este caso, los pasos para configurar PowerShell 2.0 serian: 1. Instalar Windows Management Framework para la versión de Windows que queramos trabajar (De serie con Win7 y 2008R2) http://support.microsoft.com/kb/968930 2. Entrar en el servidor SSIS y abrir una consola powershell y ejecutar

enable-psremoting 3. Ir al equipo que lanzará el comando remoto PowerShell sobre el servidor y activar la ejecución de scripts © Solid Quality™ Press

Page 69 of 102


Set-executionpolicy –scope CurrentUser –executionPolicy Unrestricted -force 4. Escribir código para lanzar los paquetes remotamente desde PS

$server = new-pssession ServidorSSIS enter-pssession $server dtexec.exe /ser servidor /sq paquetePrueba … Migración de Análysis Services Pese a que en la mayoría de los proyectos de migración desde SQL Server 2000 se suele recomendar el rediseño de la solución utilizando las características de AS 2008 R2, es posible realizar una migración automática hacia AS2008 R2. El resultado final es similar al que se obtiene con la migración desde DTS hacia SSIS…es decir, que aporta una solución que aunque acaba haciendo lo mismo que el original, no es lo mas óptima posible, entendiendo por esto, que no se explotan las nuevas características. Adicionalmente, debido a la profunda re-arquitectura conceptual del producto, hay que considerar que el cubo resultante no es una fiel réplica operativa del cubo de 2000, y que esto puede afectar a los informes existentes. Por ejemplo, en caso de tener multiples jerarquías en una dimensión, el asistente generará dos dimensiones físicas diferentes. Así mismo, ante la existencia de un cubo virtual, al ser migrado quedará convertido en un cubo físico , dado que en SQL 2008 R2 no existen los cubos virtuales. Los siguientes pasos, ilustran el proceso necesario a seguir, en el caso de desear migrar un cubo de AS2000 hacia AS2008 R2: 1. Iniciar el asistente desde Management Studio


Page 70 of 102


Figura 4-58: Migracion AS 2. Especificar las instancias de origen y destino de AS.

Figura 4-59: Selección de instancia AS 2000 a migrar


Page 71 of 102


3. Selección de las bases de datos a migrar.

Figura 4-60: Cubo a migrar 4. Fase de análisis y validación de la base de datos seleccionada.

Figura 4-61: Formulario de validación de migración


Page 72 of 102


5. Migración.

Figura 4-62: Proceso de migración 6. Fin de migración y visualización de objetos migrados a AS 2005, es necesario procesar el cubo para poder visualizar /navegar.

Figura 4-63: Resumen del proceso de migración de AS 7. Procesado de los cubos. Cada cubo debe ser procesado individualmente. Esto debido a que la migración no realiza una migración de datos sino una migración de © Solid Quality™ Press

Page 73 of 102


esquema. Es importante planificar dentro del tiempo estimado de migración, el tiempo necesario para el reprocesamiento de los objetos de SSAS

Figura 4-64: Procesamiento manual de cubo migrado 8. Generando una solución de Visual Studio para poder rediseñar el resultado de la migración.

Figura 4-65: Creación de proyecto BIDS 9. Ejecutar la herramienta Business Intelligence Developement Studio (BIDS) como se indica en la figura y elegir crear un proyecto nuevo

Figura 4-66: Nuevo proyecto en BIDS 10. Elegir tipo de proyecto importar bbdd de Analysis Services 2005 en la plantilla de proyectos y aceptar.


Page 74 of 102


Figura 4-67: Nuevo proyecto de importación de cubo analysis service 11. Elegir instancia de SQL Server 2008 R2 y la base de datos desde la que se quiere crear el proyecto.

Figura 4-68: Selección de su BBDD 12. Fase de finalización de importado.

Figura 4-69: Resumen y proceso de importación © Solid Quality™ Press

Page 75 of 102


Con estos sencillos pasos, hemos obtenido un cubo en AS2008 R2 funcionando gracias al asistente. Evidentemente, el proceso se puede complicar y para ver en qué medida, tendremos que analizar mediante SSUA los potenciales problemas con los que nos podemos encontrar, y por otro lado, la viabilidad de una migración frente a un rediseño completo utilizando ya la nueva funcionalidad de AS2008 R2.

Acciones Post migración Generalmente, tras un proceso de migración no debería finalizar el proyecto. Tras la migración existosa de cualquier instancia siempre se recomienda realizar ajustes a la nueva instancia y optimizar dentro de los nuevos parámetros de SQL Server 2008 R2 las BBDD para exprimir al máximo el nuevo motor relacional. Para ello, aquí se aportan algunas ideas que producen rendimientos extra sin demasiados esfuerzos: 1. Aplicar compresión Siempre es buena práctica aplicar compresión de fila para datos, históricos o tablas que reciben pocas actualizaciones. Se recomienda además, revisar si merece la pena en algún caso la compresión de página. 2. Aplicar particionado Si se han detectado tablas que se beneficiarían de particionamiento debido al elevado número de filas o la profundidad de los árboles de los índices que poseen, es un buen momento para considerarlo. 3. Aplicar Resource Governor Por regla general, en todo un empresarial suelen existir ciertas aplicaciones de usuario que pueden ejecutar espontáneamente consultas ad-hoc que desemboquen en un comportamiento no predecible del servidor, causando problemas de rendimiento e incluso interrumpiendo otros procesos de negocio. Resource Governor puede agregar predictibilidad a este tipo de escenarios. También resultará útil en escenarios en que se solapan operaciones de mantenimiento de sistema con operativa diaira del sistema y se desea ajusta el uso de recursos de los diferentes componentes. 4. Aplicar políticas de administración declarativa Asegurar cierto tipo de opciones de configuración del servidor para evitar o notificar posibles modificaciones por parte de usuarios DBA o aplicaciones no autorizados (nombres, esquemas,…) 5. Ejecutar servicios como SolidQ HealthCheck o “Database Tunning Advisor” para detección y optimización de problemas de rendimiento 6. Formación Es importante que los desarrolladores y administradores de BBDD dominen la tecnología a utilizar y los marcos de desarrollo creados. Para ello es necesario incluir © Solid Quality™ Press

Page 76 of 102


formación en el proceso. Dicha formación debe incluir tanto a los desarrolladores como a los administradores de BBDD. Pese a que se recomienda impartirla previamente al proceso de migración, generalmente se aprovecha incluso más, una segunda tanda de formación unas semanas tras la migración exitosa, donde los desarrolladores y dba ya han tenido el placer de gestionar el nuevo entorno.


Page 77 of 102


5. Apéndice En esta sección, se da información sobre aspectos, que aunque tienen que ver con el proceso de migración, su tratamiento no se ha querido que fuese en los puntos donde se utiliza para mejorar la lectura del documento.

Actualizaciones de seguridad Se recomienda actualizar a la última versión tanto los motores de origen como destino de SQL Server. Esto incluye también, cualquier actualización de seguridad de Sistema Operativo, con la finalidad de minimizar al mínimo cualquier potencial riesgo de seguridad que haya sido corregido hasta la fecha en la que comienza la migración.

Servidores vinculados desde entornos SQL Server x64 hacia SQL Server 2000 x32 Es imposible realizar un servidor vinculado ni operaciones openrowset desde un entorno SQL Server 64-bits hacia un SQL Server 2000 que no tenga SP4 correctamente aplicado. Si se da la circunstancia de tener que realizarlo a un nuevo servidor, se recomienda revisar el siguiente enlace http://support.microsoft.com/?scid=kb;en-us;906954&x=16&y=11 donde se dan los detalles de qué pasos seguir en el caso de requerirlo.

Cadenas de conexión con el nombre de aplicación Dado que van a convivir múltiples aplicaciones en el mismo servidor, para que la labor de detección de origen de consultas al realizar un profiling sea más sencilla, se recomienda simplemente añadir lo siguiente a la cadena de conexión (al final, por ejemplo): ;Application Name=Miaplicacion De esta forma, en la conexión viaja el nombre de la aplicación que queramos y de esta forma es más fácil distinguir conexiones y procedencias de las mismas. Para más información www.connectionstrings.com

Finalización de trazas de Sql Profiler Una vez declarada una traza de SQL Server Profiler desde código T-SQL, el proceso de finalización de la misma (para poder utilizar su información) consta de dos pasos: 1. Parar traza 2. Finalizar traza Con el siguiente script podemos ver el estado de cualquier traza en ejecución


Page 78 of 102


select traceid,value, case when value = 1 then 'running' when value = 0 then 'stopped' else null end status from fn_trace_getinfo(null) where property in (2,5) Finalizar la traza Como hemos comentado, para finalizar una traza, hemos de pararla y posteriormente cerrarla y finalizarla. Esto se hace mediante el siguiente script: -- Paramos la traza X --

sp_trace_setstatus @traceid = x , @status = 0 go -- Finalizamos la traza X --

sp_trace_setstatus @traceid = x , @status = 2 go NOTA: El valor de “x” es el valor reportado por “traceid” del script de “ver el estado actual”

Generación de Scripts de mantenimiento La herramienta SQL Server Management Studio posee entre sus características más útiles para los DBA, que prácticamente cualquier acción que realicemos con ella, es susceptible de ser convertida en script. Para el caso de los scripts que deberemos lanzar una vez se haya migrado la BBDD de SQL Server 2000 a 2008 R2, se puede hacer simplemente haciendo doble click sobre cada uno de los componentes de mantenimiento que queramos. Para ello, podemos crear nuestra tarea de mantenimiento post-migración, que incluirá Recreación de índices, actualización de estadísticas y shrink de base de datos y luego crear un script para que sea más rápida su ejecución el día de puesta en producción (evitándonos crear/modificar la tarea de mantenimiento)


Page 79 of 102


Para crear una tarea de mantenimiento:

Figura 5-1: Nuevo plan de mantenimiento Una vez dentro de ella, podemos arrastrar componentes de la barra de herramientas a los sub-planes. Cuando hemos definido nuestra tarea de mantenimiento, generar los scripts (algo opcional) puede realizarse simplemente mediante botón derecho->editar (ver siguientes dos imágenes)

Figura 5-2: Edición de tarea de plan de mantenimiento

Figura 5-3: Edición


Page 80 of 102


Solución al error “allow remote connections through DCOM” Cuando tratamos de conectar remotamente a SSIS eventualmente podemos recibir el siguiente mensaje de error, cuando no hemos realizado una correcta configuración de seguridad:

Figura 5-4: Error DCOM genérico En este caso lo que se nos está diciendo es que aunque hemos llegado al servicio, se nos ha denegado el acceso. Además de esto nos está dando una pista que es debido a que no hemos configurado correctamente el acceso remoto. La solución es bien sencilla y pasa por añadir en la configuración DCOM del servicio MsDtsServer100 o MsDtsServer (según si estamos en SQL Server 2008 o 2005) al usuario que queremos que tenga acceso remoto y listo. Para ello abrimos “Component services”, buscamos dentro de DCOM las propiedades del servicio MsDtsServer100 y añadimos en su pestaña de seguridad al usuario en cuestión:

Figura 5-5: Propiedades DCOM a nivel de sistema operativo Buscamos en DCOM la configuración de MsDtsServer o MsDtsServer100 (según si es Sql Server 2005 o 2008).


Page 81 of 102


Figura 5-6: Propiedades de paquetes SSIS

En las propiedades, se añaden los permisos que necesitemos para el usuario que queramos que conecte remoto:

Figura 5-7: Edición de permisos en componente DCOM Para más información, recomiendo leer el siguiente artículo: http://msdn.microsoft.com/enus/library/aa337083.aspx

Crear una solución Visual Studio para gestionar todos los paquetes SSIS Esta opción es útil para gestionar con control de versiones los paquete SSIS. Visual Studio permite trabajar con control de versiones y por lo tanto, se pueden gestionar paquetes SSIS mediante Team Foundation Server ó Visual SourceSafe. Para ello, lo que debemos hacer es abrir el entorno Visual Studio 2008 R2 (viene incorporado en las herramientas cliente de SQL Server 2008 R2). •

Crearemos un nuevo proyecto de Integration Services


Page 82 of 102


Figura 5-8: Nuevo proyecto BIDS par Integration Services NOTA: Dependiendo de la edición de Visual Studio instalada puede diferir algo la pantalla •

Eliminaremos el paquete que nos crea por defecto y lo sustituiremos por todos nuestros paquetes .dtsx que hemos migrado

Figura 5-9: Eliminar paquete por defecto en proyecto SSIS de BIDS


Page 83 of 102


•

Una vez eliminado el paquete, ahora añadiremos todos los paquetes que queramos

Figura 5-10: Añadir Nuevo paquete .dtsx

Figura 5-11: Ubicación del nuevo paquete SSIS

Figura 5-12: Vista de paquetes en BIDS


Page 84 of 102


•

Una vez tengamos esto, el entorno los deja depurar entre otras cosas

Figura 5-13: Botón de depuración NOTA: la depuración de tareas DTS en SSIS no funciona en entornos x64

Migración Analysis Services en dos pasos El cambio de Analysis Services entre SQL Server 2000 y 2008 R2 es tan grande, que en la mayoría de ocasiones, se suele proponer rehacer el cubo de nuevo utilizando las características de Analysis Services 2008 R2. En casos como este, evidentemetne no se va a paralizar todo el proyecto porque primero tengamos que rediseñar la solución de Analysis Services (o partes de la misma) para explotar al máximo la nueva tecnología. En esos casos se suele optar por algo intermedio como es migrar el motor de SQL Server, pero dejar que siga funcionando Analysis Services 2000 temporalmente, mientras se finaliza el rediseño de la solución. En estos casos por tanto, existirá una primera etapa en la que tendremos todos nuestros servicios de SQL Server migrados a excepción de Analysis Services, y que posteriormente será migrado (recreado) en Analysis Services 2008 R2. Para que AS2000 pueda tener acceso a SQL Server 2008 R2, debemos instalar el soporte nativo de SQL Server 2008 R2 en el servidor donde se encuentre funcionando la instancia de AS2000. De esta forma, cambiando los orígenes de datos de los cubos hacia el DW en SQL Server 2008 R2, el cubo de AS2000 tendrá como origen un DW en SQL Server 2008 R2.


Page 85 of 102


Idioma predeterminado de las conexiones En el caso de que las aplicaciones cliente realicen consultas que involucren cadenas de texto que deban ser convertidas a datetime, es necesario cerciorarse de que el idioma de las conexiones que se abran contra el servidor es el adecuado. En el caso de que el formato que está utilizándose en Sql Server 2000 es ,por ejemplo, “Spanish”, hay que cerciorarse que en SQL Server 2008 R2 tambien lo sea. Para ello: •

Nos cercioraremos que por defecto el idioma de los nuevos logins que se añadan será castellano.

Figura 5-14: Propiedades a nivel de instancia

Figura 5-15: Selección de idioma por defecto en instancia SQL Server 2008 R2


Page 86 of 102


Una vez modificado el valor (no requiere reinicio de la instancia pero sí que se vuelva a reconectar el cliente), todos los logins nuevos se crearán con lenguaje Spanish y soportarán la especificación de cast string-datetime que las aplicaciones estén utilizando. •

Por último, cerciorarse que no exista ningún login creado previamente a la modificación anterior con idioma diferente a “Spanish”.

Figura 5-16: Propiedades de login Gracias a esto, consultas como la siguiente

SELECT top 10 * FROM tabla where fecha = '30/11/2006' No arrojarán el siguiente error: Msg 242, Level 16, State 3, Line 1 The conversion of a char data type to a datetime data type resulted in an out-of-range datetime value.

Seguridad en paquetes SSIS Los paquetes SSIS son internamente XMLs. Puesto que en su definición podemos configurar usuarios y contraseñas, es importante tener en cuenta el tipo de seguridad que se aplica a los mismos para que nadie pueda llegar a acceder a dicha información sin permiso. © Solid Quality™ Press

Page 87 of 102


Por defecto, la seguridad de SSIS está ligada al usuario que crea el paquete, de forma que dicho usuario sin saberlo cifra la información contenida en él y le posibilita modificar y ejecutar el paquete sin introducir sus credenciales. El problema viene cuando más de un desarrollador va a realizar modificaciones sobre un paquete. En ese caso necesitaremos realizar una modificación de seguridad para que la información sensible sea cifrada mediante password en lugar de mediante un “UserKey”. Para ello basta con seguir los siguientes pasos:

Figura 5-17: Ventana de propiedades de proyecto BIDS

Figura 5-18: Selección de nivel de protección de datos sensibles en paquete SSIS

Figura 5-19: Password de paquete SSIS


Page 88 of 102


Figura 5-20: Confirmación de password A partir de ese momento, cuando un desarrollador quiera modificar o subir a producción el paquete, se le solicitará dicho password.

Integrar la nueva instancia en el parque de aplicaciones El cambio del motor de base de datos va a afectar a más cosas que solo a las bases de datos que maneja. Deberemos por tanto adecuar el entorno donde se ha instalado, para que pueda acceder sin problemas al nuevo motor de SQL Server 2008 R2: •

•

•

•

Drivers Puesto que las aplicaciones van a apuntar sobre un nuevo motor de SQL Sever, es necesario actualizar los drivers de conexión de las mismas instalando los drivers de conexión MDAC 2.8 y Sql Native Client 2008 R2. Servidores vinculados En el caso de actualizaciones “Side-by-side”, hay que crear los servidores vinculados desde y hacia la nueva instancia de SQL Server 2008 R2. Es por tanto necesario previamente definir aquellos componentes que puedan verse afectados por la actualización. Procesos de carga Deberemos actualizar los procesos de carga (DTSs) bien sea mediante la migración a SSIS o mediante la utilización de los componentes heredados para compatibilidad hacia atrás. En cualquiera de las dos situaciones, deberemos actualizar las cadenas de conexión 64 bits En migraciones en las que además de la propia migración a SQL Server 2008 R2, exista una migración de 32 a 64 bits, hay que poner especial atención a los drivers de conexión sobre todo en el caso de requerir conexión a motores de base de datos como Oracle, AS400,…desde la nueva instancia. Podria darse el caso de tener que instalar componentes de 64 bits para poder acceder a las mismas desde el nuevo SQL Server 2008 R2.

Recursos: •

MDAC 2.8: http://www.microsoft.com/downloadS/details.aspx?FamilyID=6c050fe3c795-4b7d-b037-185d0506396c&displaylang=en


Page 89 of 102


• •

SQL Native Client 2005: http://msdn.microsoft.com/en-us/data/aa937733.aspx Cadenas de conexión: www.connectionstrings.com

Instalar compatibilidad con SQL Server 2000 Para poder realizar la migración de los paquetes DTS, es necesario instalar la compatibilidad con el runtime de Servicios de Transformación de datos, así como la compatibilidad de modo diseño de los servicios de transformación de datos. Actualmente se ofrece para SQL Server 2008 R2 únicamente el runtime para DTSs de SQL Server 2000, pero existe la posibilidad de instalarse el diseñador de DTS 2000 sobre SQL Server 2008 R2 haciendo unas cuantas modificaciones que enseguida detallaremos. NOTA: Esta sección no está soportada oficialmente y por tanto se comenta como una posible via de investigación de última necesidad. Se encuentra actualmente fuera de soporte.

Runtime DTS Para disponer del runtime, debemos instalarnos los “Componentes de compatibilidad con versiones anteriores de Microsoft SQL Server 2005”: http://go.microsoft.com/fwlink/?LinkId=123703&clcid=0xc0a Como vemos en la imagen, para nuestro caso únicamente instalaremos el runtime DTS

Figura 5-21: Instalación de components de compatibilidad con SQL Server 2005 opcionales © Solid Quality™ Press

Page 90 of 102


Una vez los tengamos instalados, podremos ejecutar paquetes DTS desde el servidor, pero no podremos editarlos. Para editarlos necesitaremos el componente de edición DTS.

Diseñador DTS Como hemos comentado varias veces a lo largo del documento, este procedimiento debe realizarse bajo cuenta y riesgo del lector, ya que no está soportado en SQL Server 2008 R2 oficialmente. Para instalar la compatibilidad en tiempo de diseño para paquetes de Servicios de transformación de datos, hay que descargarse el siguiente instalable: http://download.microsoft.com/download/2/3/4/2346ff78-ba75-4ba6-83e95c9d66a0a89a/SQLServer2005_DTS.msi De forma predeterminada, los archivos binarios para SQL Server 2000 están en la carpeta %ProgramFiles%\Microsoft SQL Server\80\Tools\Binn y los archivos binarios para SQL Server 2008 R2 están en la carpeta %ProgramFiles%\Microsoft SQL Server\100\Tools\Binn. Estas ubicaciones predeterminadas podrían hacer la ruta de acceso de los archivos binarios para SQL Server 2000 aparezca en la variable de entorno PATH antes que la ruta de acceso de los archivos binarios para SQL Server 2008 R2. Si ocurre así, puede aparecer un mensaje de error al intentar utilizar el Diseñador DTS. Para resolver este error, copie los archivos que requiere el diseñador a una nueva ubicación, tal y como se describe en los procedimientos siguientes. Para asegurarse de que el Diseñador DTS puede utilizarse en SQL Server Management Studio 1. Copie los archivos, SEMSFC.DLL, SQLGUI.DLL y SQLSVC.DLL, de la carpeta %ProgramFiles%\Microsoft SQL Server\80\Tools\Binn a la carpeta %ProgramFiles%\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE. 2. Copie los archivos, SEMSFC.RLL, SQLGUI.RLL y SQLSVC.RLL, de la carpeta %ProgramFiles%\Microsoft SQL Server\80\Tools\Binn\Resources a la © Solid Quality™ Press

Page 91 of 102


carpeta %ProgramFiles%\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Resources. Para asegurarse de que el Diseñador DTS se puede utilizar en Business Intelligence Development Studio 1. Copie los archivos, SEMSFC.DLL, SQLGUI.DLL y SQLSVC.DLL, de la carpeta %ProgramFiles%\Microsoft SQL Server\80\Tools\Binn a la carpeta %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE.

2. Copie los archivos, SEMSFC.RLL, SQLGUI.RLL y SQLSVC.RLL, de la carpeta %ProgramFiles%\Microsoft SQL Server\80\Tools\Binn\Resources a la carpeta %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\Resources.

¿Por qué actualizar el nivel de compatibilidad? El nivel de compatibilidad afecta sólo al comportamiento de la base de datos especificada y no a todo el servidor. El nivel de compatibilidad sólo proporciona compatibilidad parcial con versiones anteriores de SQL Server. La razón de actualizar el nivel de compatibilidad es para poder soportar mejoras en la sintaxis T-SQL que hagan uso de nuevas características soportadas por la última versión de SQL Server 2008 R2. Además, nuevos operadores existentes en SQL Server 2008 R2 respecto a SQL Server 2000 pueden producir planes de ejecución más eficientes. Por ejemplo, en la nueva versión de SQL Server 2008 R2 existen operaciones MERGE, CUBE, ROLLUP, …que no pueden utilizarse si la base de datos no está en compabilidad 100 (SQL Server 2008 R2). Hay que tener cuidado a la hora de cambiar el nivel de compatibilidad, puesto que si se hace en mitad de la compilación de un plan de ejecución, el nuevo plan podría resultar inconsistente y los datos devueltos podrían ser inválidos. No es necesario reiniciar la instancia para realizar el cambio. Para más información: http://msdn.microsoft.com/es-es/library/bb510680.aspx

Analisis de interconexiones En este apartado se proporciona un script de partida de referencia a la hora de buscar interconexiones entre instancias SQL Server: Por ejemplo, el siguiente código serviría para detectar qué aplicaciones están intentando realizar consultas distribuidas ad-hoc: © Solid Quality™ Press

Page 92 of 102


select DatabaseID, ISNULL(databaseName, '???') AS databaseName, ISNULL(LoginName ,'') as LoginName, ISNULL(NTUserName,'') as NTUserName, ISNULL(NTDomainName,'') as NTDomainName, ISNULL(HostName,'') as HostName, ISNULL(ApplicationName,'') as ApplicationName, TextData, StartTime, EndTime, case when TextData like '%openrowset%' then 'openrowset' when TextData like '%opendatasource%' then 'opendatasource' when TextData like '%sp_addlinkedserver%' then 'add_linkedse rver' else 'null' end as pattern_match FROM fn_trace_gettable ( '$ trace_file$' , $ numberfiles$) WHERE textdata IS NOT NULL AND EventClass = 12 and( TextData like '%openrowset%' or TextData like '%opendatasource%' or TextData like '%sp_addlinkedserver%' ) NOTA: Quedaria realizer el mismo proceso para todas las definiciones de objetos de cada BBDD implicada en la migración

Análisis de aplicaciones que utilizan SQL Server La idea en este punto es conseguir analizar los ficheros de traza de SQL Server profiler, con el fin de detectar qué aplicaciones, usuarios, Logins, equipos,…están conectando contra la instancia actualmente, para tenerlos presentes en las fases de testeo de aplicaciones.


Page 93 of 102


Este punto también es crítico si se tiene en cuenta que dicho proceso de migración generalmente destapa aplicaciones que no siempre tenemos catalogadas, equipos que no deberían conectarse, usuarios que no deberían de tener acceso…En este momento saltarán a la luz.

--- 1) Include profiler data into database -USE database_in_your_own_instance GO

-- Create table with data -CREATE TABLE [dbo].ExternalConnectionAnalysis( [ServerName] [nvarchar](256) NOT NULL, [databaseid] [int] NULL, databaseName sysname null, [applicationname] [nvarchar](256) NULL, [hostname] [nvarchar](256) NULL, [loginname] [nvarchar](256) NULL, queries_executed bigint not null ) ON [PRIMARY]

GO

-Aqui tienes que añadir todos los .trc que tengas de todos los servid ores -INSERT into dbo.ExternalConnectionAnalysis(ServerName, database id, DatabaseName, applicationname, hostname, loginname,queries_e xecuted) © Solid Quality™ Press

Page 94 of 102


SELECT 'HIDRA' AS ServerName , databaseid, DatabaseName,applic ationname, hostname, loginname,COUNT(*) FROM ::fn_trace_gettable('E:\file_.trc', default) GROUP BY databaseid,DatabaseName, applicationname, hostname, l oginname go

-Aqui está lo mismo que antes, pero de forma que solo se añaden los nuevos datos. Está pensado para que si lanzas -una carga de un servidor que ya has cargado, no te inserte datos du plicados -Para evitar que si vuelves a procesar una traza, o un fichero trc que o lvidaste -- de un mismo servidor se inserten datos duplicados. -- es opcional -declare @srvname sysname = ‘srv’ declare @trcpath varchar(max) = ‘file_.trc' ;

with existent_data as( select ServerName, databaseid, applicationname,hostname,loginna me from dbo.ExternalConnectionAnalysis where ServerName = @srvname ), trc as ( SELECT @srvname AS ServerName , trc.databaseid, trc.applicatio nname, trc.hostname, trc.loginname FROM ::fn_trace_gettable(@trcpath, default) trc © Solid Quality™ Press

Page 95 of 102


) INSERT into dbo.ExternalConnectionAnalysis(ServerName, database id, applicationname, hostname, loginname,queries_executed) SELECT @srvname AS ServerName , trc.databaseid, trc.applicationn ame, trc.hostname, trc.loginname ,COUNT(*) FROM trc left join existent_data ed on (trc.DatabaseID = ed.databaseid and trc.ApplicationName = ed.applicationname and trc.HostName = ed.hostname and trc.LoginName = ed.loginname ) where ed.databaseid is null or ed.applicationname is null or ed.hostn ame is null or ed.loginname is null GROUP BY trc.databaseid, trc.applicationname, trc.hostname, trc.log inname Una vez finalizada la importación, en la tabla destino llamada “dbo.ExternalConnectionAnalysis” dispondremos de la información relativa a qué aplicaciones, usuarios,Logins, queries,…han sido lanzadas contra él. El resultado final por tanto será un inventario de aplicaciones que deberemos escrutar y tener presente siempre en el proceso de testing del nuevo entorno migrado. NOTA: Si bien cuanto mayor rango temporal analicemos, mejor y mas fiables serán los resultados, en este tipo de proyectos debemos asegurarnos que se analiza un período completo de aplicaciones. Si se escapa algo, no será detectado y por tanto potencialmente no testeado y en un futuro ser un foco de fallo.

Documentos de referencia •

SQL Server 2008 R2 Upgrade Technical Reference Guide http://download.microsoft.com/download/3/0/D/30DB8D46-8ACF-442A-99A20F4CE74AE14D/SQL_Server_2008_R2_Upgrade_Technical_Reference_Guide.docx

Recursos de interés •

Pack de extensibilidad para SQL Server 2008 R2:

http://www.microsoft.com/download/en/details.aspx?id=16978 © Solid Quality™ Press

Page 96 of 102


• •

MDAC 2.8: http://www.microsoft.com/downloadS/details.aspx?FamilyID=6c050fe3c795-4b7d-b037-185d0506396c&displaylang=en SQL Native Client 2008 R2:

http://go.microsoft.com/fwlink/?LinkID=188401&clcid=0x409 • •

Cadenas de conexión: www.connectionstrings.com Diseñador de DTS para SQL Server 2008(compatibilidad 2000): http://download.microsoft.com/download/2/7/c/27c60d49-6dbe-423e-9a9e1c873f269484/SQLServer2005_DTS.msi


Page 97 of 102


6. Figuras Figura 3-1: Diagrama de alineamiento en almacenamiento NTFS .......................................... 13 Figura 3-2: Consulta gwmi en cmd.exe ................................................................................... 14 Figura 3-3: Recomendacion de formato mediante interfaz windows..................................... 15 Figura 3-4: Aplicacion de Seguridad “Log on as a service” ...................................................... 16 Figura 3-5: Aplicacion de Seguridad “Lock pages in memory” ................................................ 16 Figura 3-6: Aplicacion de Seguridad “Instant file initialization” .............................................. 17 Figura 3-7: Configuración básica ............................................................................................. 18 Figura 3-8: Propiedades TCP/IP de instancia ........................................................................... 18 Figura 3-9: Ofuscación de instancia......................................................................................... 19 Figura 4-1: Diagrama de dependencias entre instancias ........................................................ 26 Figura 4-2: Diagramas de dependencia entre bases de datos ................................................ 27 Figura 4-3: Instalación de SSUA ............................................................................................... 28 Figura 4-4: Según el proyecto, se analizarán los servicios pertinentes ................................... 29 Figura 4-5: Conexión a instancia.............................................................................................. 30 Figura 4-6: Selección de bases de datos y ficheros a analizar ................................................. 30 Figura 4-7: Abrir reporte de resultados SSUA ......................................................................... 31 Figura 4-8: Ejemplo de resultados de análisis SSUA ................................................................ 31 Figura 4-9: Mensaje genérico .................................................................................................. 32 Figura 4-10: Mensaje para fulltext search ............................................................................... 36 Figura 4-11: Actualizar version MDAC ..................................................................................... 36 Figura 4-12: Planes de mantenimiento desfasados ................................................................ 36 Figura 4-13: ORDER BY deprecado .......................................................................................... 37 Figura 4-14: OUTER JOIN deprecado ....................................................................................... 37 Figura 4-15: Mensaje generic sobre full-text search .............................................................. 38 Figura 4-16: Resultados análisis DTS ....................................................................................... 38 Figura 4-17: Mensaje indicando que DTS no está soportado.................................................. 38 Figura 4-18: No se podran editar paquetes DTS en versión 2008 R2 ...................................... 38 Figura 4-19: Mensaje indicando que revises los DTS puesto que algunos se han encapsulado como DTS dentro de SSIS debido a su complejidad y se deben reprogramar manualmente . 39 Figura 4-20: Mensaje generic indicando que DTS está deprecado ......................................... 39 Figura 4-21: Se realiza la migración automática de paquetes DTS en su última versión de msdb ........................................................................................................................................ 40 Figura 4-22: Abrir SQL Profiler desde SSMS ............................................................................ 40 Figura 4-23: Crear nueva traza ................................................................................................ 41 Figura 4-24: Configuración de instancia a analizar .................................................................. 41 Figura 4-25: Eventos de traza .................................................................................................. 41 Figura 4-26: Captura de datos por evento .............................................................................. 42 Figura 4-27: El boton Run lanza la traza .................................................................................. 42 © Solid Quality™ Press

Page 98 of 102


Figura 4-28: El boton stop para la ejecución de traza ............................................................. 42 Figura 4-29: Se puede exporter definición para recreación rápida posterior ......................... 43 Figura 4-30: Existen dos sencillas partes a modificar en el script para creación de traza de profiler. .................................................................................................................................... 43 Figura 4-31: Interfaz de configuración de tarea “Shrink database” ........................................ 47 Figura 4-32: Migración de DTSs ............................................................................................... 53 Figura 4-33: Pantalla principal de asistente de migración ...................................................... 54 Figura 4-34: Instancia con datos origen de DTSs ..................................................................... 54 Figura 4-35: Tipo de destino y ubicación ................................................................................. 55 Figura 4-36: Resumen .............................................................................................................. 55 Figura 4-37: Ubicación de log de procesamiento .................................................................... 56 Figura 4-38: Información de progres ....................................................................................... 56 Figura 4-39: Componente DTS embebido a editar .................................................................. 57 Figura 4-40: Pantalla de apertura de editor de compatibilidad DTS ....................................... 57 Figura 4-41: Ejemplo de tarea interna como DTS incrustada en SSIS (algo a evitar) .............. 58 Figura 4-42: Selección de driver .............................................................................................. 58 Figura 4-43: Especificación de conexion ................................................................................. 59 Figura 4-44: Propiedades de la conexión (pulsar sobre la flecha) con botón derecho ........... 59 Figura 4-45: Propiedades de conexión .................................................................................... 60 Figura 4-46: Propiedades de conexion .................................................................................... 60 Figura 4-47: Conexión.............................................................................................................. 61 Figura 4-48: Importar paquete ................................................................................................ 61 Figura 4-49: Importar paquete ................................................................................................ 62 Figura 4-50: Protección de datos sensibles en paquete.......................................................... 62 Figura 4-51: Especificación de contraseña para almacenar datos sensibles en el paquete SSIS ................................................................................................................................................. 63 Figura 4-52: Integration Services en SSMS .............................................................................. 64 Figura 4-53: Paquetes SSIS almacenados en BBDD ................................................................. 64 Figura 4-54: Lanzar paquete .................................................................................................... 64 Figura 4-55: Interfaz de configuración del lanzamiento del paquete ..................................... 65 Figura 4-56: Instalación minima recomendada ....................................................................... 65 Figura 4-57: Ejemplo de ejecución manual mediante dtexec.exe en cmd.exe ....................... 68 Figura 4-58: Migracion AS ....................................................................................................... 71 Figura 4-59: Selección de instancia AS 2000 a migrar ............................................................. 71 Figura 4-60: Cubo a migrar ...................................................................................................... 72 Figura 4-61: Formulario de validación de migración ............................................................... 72 Figura 4-62: Proceso de migración .......................................................................................... 73 Figura 4-63: Resumen del proceso de migración de AS .......................................................... 73 Figura 4-64: Procesamiento manual de cubo migrado .......................................................... 74 Figura 4-65: Creación de proyecto BIDS .................................................................................. 74 Figura 4-66: Nuevo proyecto en BIDS ..................................................................................... 74 © Solid Quality™ Press

Page 99 of 102


Figura 4-67: Nuevo proyecto de importación de cubo analysis service.................................. 75 Figura 4-68: Selección de su BBDD .......................................................................................... 75 Figura 4-69: Resumen y proceso de importación.................................................................... 75 Figura 5-1: Nuevo plan de mantenimiento ............................................................................. 80 Figura 5-2: Edición de tarea de plan de mantenimiento ......................................................... 80 Figura 5-3: Edición ................................................................................................................... 80 Figura 5-4: Error DCOM genérico ............................................................................................ 81 Figura 5-5: Propiedades DCOM a nivel de sistema operativo ................................................. 81 Figura 5-6: Propiedades de paquetes SSIS .............................................................................. 82 Figura 5-7: Edición de permisos en componente DCOM ........................................................ 82 Figura 5-8: Nuevo proyecto BIDS par Integration Services ..................................................... 83 Figura 5-9: Eliminar paquete por defecto en proyecto SSIS de BIDS ...................................... 83 Figura 5-10: Añadir Nuevo paquete .dtsx................................................................................ 84 Figura 5-11: Ubicación del nuevo paquete SSIS ...................................................................... 84 Figura 5-12: Vista de paquetes en BIDS................................................................................... 84 Figura 5-13: Botón de depuración ........................................................................................... 85 Figura 5-14: Propiedades a nivel de instancia ......................................................................... 86 Figura 5-15: Selección de idioma por defecto en instancia SQL Server 2008 R2 .................... 86 Figura 5-16: Propiedades de login ........................................................................................... 87 Figura 5-17: Ventana de propiedades de proyecto BIDS ........................................................ 88 Figura 5-18: Selección de nivel de protección de datos sensibles en paquete SSIS ............... 88 Figura 5-19: Password de paquete SSIS .................................................................................. 88 Figura 5-20: Confirmación de password.................................................................................. 89 Figura 5-21: Instalación de components de compatibilidad con SQL Server 2005 opcionales ................................................................................................................................................. 90


Page 100 of 102


Acerca del Autor Enrique Catalá Mentor en SolidQ. Colaborador destacado en la comunidad SQL Server en MSDN (http://msdn.microsoft.com/es-es/sqlserver/) donde colabora como Technical Ranger. Ingeniero en informática, obtuvo la única matrícula de honor de su promoción en el proyecto de fin de carrera por su proyecto propuesto de definición e implementación de un sistema de modelado de bases de datos multidimensionales orientadas a objetos usando lenguajes de especificación de dominio (DSL). Es Microsoft Certified Trainer (MCT) y fue nombrado MAP 2010 (Microsoft Active Professional). Centrado en el motor relacional SQL Server, tanto en la resolución de problemas de rendimiento y escalabilidad en sistemas OLTP como la definición e implementación de entornos de alta disponibilidad confiables, en donde ha llevado con éxito más de 70 proyectos no solo en España, sino en diferentes países como EEUU, Holanda, México o Austria. Es el arquitecto principal de las soluciones para SolidQ llamadas HealthCheck, SQL2Cloud, SCODA y del generador de SSIS de SolidQ. Ponente habitual del SolidQ SUMMIT, miembro y ponente en SQL PASS tanto en España como Iberoamérica. Colabora con Microsoft realizando Webcast y conferencias para MSDN y TechNet. Mantiene tanto su blog personal (http://ecatalab.blogspot.com/), como "El Rincón del DBA" (http://blogs.solidq.com/es/elrincondeldba/) con colegas de SolidQ. Twitter: @enriquecatala

Especialidades Sql Server, .NET, Tuning relational engines, High availability systems


Page 101 of 102


Acerca de SolidQ SolidQ es el estándar para servicios de administración de información al proporcionar servicios de administración de datos fiables, inteligencia de negocios, colaboración y soluciones de tecnología avanzada para plataformas de nube y en las instalaciones de Microsoft más confiable del mundo. •

SolidQ representa el más altamente reconocido equipo de BI y administración de datos con el mayor porcentaje de MVP de Microsoft (SQL Server) en el mundo.

•

Como un asesor clave y proveedor de contenido a Microsoft, con más de treinta libros publicados y más apariciones de orador en conferencias técnicas, líderes del mundo, excepto Microsoft, SolidQ es el experto llamado por los expertos.

•

Como confiamos en la capacidad de nuestro equipo y el valor que ofrecemos, incondicionalmente garantizamos su satisfacción con nuestros servicios.


Page 102 of 102

Planificando La Migracion de SQL Server 2000 2005 a SQL Server 2008 R2

Recommend Documents