Es bastante frecuente encontrar hoy en día aplicaciones de producción en las que BBBDDs trabajan todavía contra SQL Server 2000. Pese a que SQL Server 2000 es un buen motor de BBDD que probablemente está dando un servicio excelente para nuestra aplicación de producción, no hemos de olvidar que el soporte de SQL Server 2000 ha finalizado y han aparecido versiones mas eficientes (2005 y recientemente 2008). Es ahora el momento en el que se plantean numerosas situaciones que involucran una migración de todo un sistema de producción basado en SQL Server 2000 a SQL Server 2008.Antes de nada, solo quiero comentar que SQL Server 2008 permite la migración “in place” de un SQL Server 2000, pero que la próxima versión de SQL Server no lo hará. Por otro lado, pese a que permite la migración “in place”, esta solo podrá ser llevada a cabo si el host se trata de un Windows Server 2003, ya que no está certificado SQL Server 2008 sobre Windows Server 2000, y SQL Server 2000 no está certificado para Windows Server 2008…(vaya lio 😉
A continuación vemos algunas cosas que debemos conocer si estamos en la tesitura de realizar migraciones “in place”:
- Si vamos a migrar “in place”, asegurarse que tenemos SP2 de Win2k3 como mínimo instalado y SP4 de SQL Server 2000 aplicado.
- No se puede instalar si existe algún reinicio pendiente (por ejemplo por alguna actualización de windows pendiente).
- Debemos actualizar a una edición de la misma rama o superior, nunca inferior (no podremos pasar de SQL 2000 Enterprise a SQL 2008 Standard, por ejemplo)
- No es posible pasar de x32 a x64 “in place”, a menos que hagamos una estrategia de detach-and-restore, lo que nos obligaria (como es lógico) a recrear logins, jobs,… y a que en algun momento convivieran las dos instancias en el mismo servidor.
- No están soportadas actualizaciones “in place” en clústers de IA64
- No se va a poder actualizar SSAS 2000 si está clusterizado (esto último no lo he podido validar personalmente)
 |
Todas estas validaciones las realiza SQL Server 2008 al intentar realizar la actualización in place. En el CD de instalación, podremos elegir la opción de actualizar de un SQL server 2000 (ver imagen de arriba). En la imagen de la derecha podemos ver como al intentar realizar la actualización, se ha detectado un reinicio pendiente y nos indica que para poder seguir debemos realizarlo.
Pero este post no trata de como migrar el motor, sino de cómo planificaremos nuestra migración. Para ello disponemos de una herramienta llamada SQL Server 2008 Upgrade Advisor. Lo que tenemos que hacer es instalar dicha herramienta que viene con el propio CD de instalación de SQL Server 2008 o mediante descarga directa aquí.
Esta herramienta, entre otras cosas nos permite realizar un análisis de la instancia SQL Server 2000 deseada, detectando que cambios deben llevarse a cabo para la actualización a 2008, así como la información del por qué (links explicando cada una de las “amenazas” detectadas).
Al contrario que la herramienta de actualización del motor propiamente dicha, en este caso la herramienta está pensada para instalarse en un equipo diferente al de producción, por lo que está preparada para solicitar la instancia a analizar, así como el usuario (con permiso sysadmin) que necesitemos para conectar y realizar el análisis.
 |
 |
 |
Ahora que ya conocemos algo acerca de Upgrade Advisor y como conectarnos, vamos a ver qué hacer para realizar el análisis.
Análisis motor relacional:
En relación al análisis del motor relacional, una de las cosas que debemos saber es que esta herramienta no realiza por nosotros un análisis de la tipología de consultas que se lanzan contra el servidor. Recordemos que en SQL Server 2008, se implementan las políticas descontinuadas. Esto quiere decir que existe sintaxis T-SQL que no es compatible en SQL Server 2008. Esto es muy importante y puede producirnos un verdadero dolor de cabeza si migramos el motor de BBDD y no nos hemos centrado en analizar estas cosas.
La herramienta, sí que realiza este análisis a los objetos existentes en las BBDDs de la instancia a migrar (procedimientos almacenados, funciones, …) pero no sabe que consultas ad-hoc le mandan las aplicaciones, y para eso nosotros tendremos que poner de nuestra parte.
Lo que debemos hacer por tanto es definirnos una traza de SQL Profiler, que capture los eventos RPC:Completed y SMTP:BatchCompleted durante el tiempo que estimemos conveniente (una semana, un día,…) para que las aplicaciones que funcionan contra las BBDD se muevan a sus anchas y envíen todas las peticiones al motor que necesiten.
 |
Una vez tengamos la/s traza/s capturadas, las utilizaremos mas adelante para analizarlas y determinar si existe alguna consulta depreciada, para actuar en consecuencia (modificar la aplicación para que la consulta en cuestión cambie de sintaxis).
Podemos mientras, analizar los objetos de la instancia simplemente haciendo click en Upgrade Advisor y seleccionando que partes deseamos analizar (se entiende que todas 😉
 |
Al final del análisis, se nos mostrará un report que tendremos que estudiar con detenimiento y con el que sabremos cuanto trabajo nos va a costar migrar la BBDD (si existen incompatibilidades) y qué deberemos modificar para ello.
Por otro lado, analizar la traza es tan facil como seleccionarla en la sección de análisis del motor relacional
 |
Análisis SSAS
El análisis de SSAS lo realiza la propia herramienta
 |
En este punto me gustaría puntualizar que Microsoft no recomienda realizar un upgrade de SSAS 2000 a 2008 in place y que la mejor estrategia es instalar un SSAS2008 y luego utilizar el SSAS migration assistant para migrar de una instancia a la otra. Después de migrar, desinstalar SSAS2000.
Análisis DTS
El análisis de los DTS se puede realizar o bien de SQL server o bien de DTS que residan en sistema de ficheros
 |
Este es un tema sobre el que espero poder escribir bastante en un futuro ya que hay muchas variables a tener en cuenta, pero para comenzar, seguro que a mas de uno le asombra la potencia de las herramientas suministradas por Microsoft para ayudarnos a tal fin.
2 comments
buenas tardes
estoy tratando de migrar una base de datos de 2000 en un servidor A, a UNA VERSION 2008 R2 en un servidor B. EJECUTANDO el upgrade Advisor de 2008, referencio la instancia de 2000 pero no la encuentra. ambos servidores estan en el mismo dominio pero en diferente segmento de red. quisiera saber que puede estar evitando que no detecte las instancias de sql server, cuando referencio el servidor por su nombre.
Hola buenas, recuerdo que cuando me pasaba eso, la solución que daba era primero probar a poner solo el nombre de máquina, lo que me luego me permitía al pasar al siguiente paso del GUI seleccionar la instancia y/o directamente poner la IP,puerto de la instancia a analizar.
Si no te detecta la instancia por nombre es muy posible que sea porque el servicio sqlbrowser esté apagado o el firewall esté bloqueándolo