Si alguna vez te has planteado hacer un downgrade de edición de SQL Server (por ejemplo, pasar de edición Enterprise a Standard), este es tu artículo :). Este no va a ser tu artículo si quieres pasar de versión superior (SQL Server 2012) a versión inferior (SQL Server 2008R2?).
Me lo han preguntado en bastantes ocasiones por curiosidad algunos, por necesidad otros…pero no me habia decidido escribir al respecto hasta hoy.
Como sabrás (y si no te lo digo yo :)), cuando instalas cualquier versión de SQL Server (2005, 2008,2012,…) siempre tienes la opción de realizar un upgrade de edición con el instalador para por ejemplo pasar tu edición Standard de SQL Server a Enterprise (por ejemplo). Básicamente, si lo que necesitas es hacer un upgrade (esto es, pasar hacia arriba de edición) lo único a tener en cuenta a grandes rasgos es:
- Meter el “cd”
- Entrar en la opción “Maintenance”->”Edition Upgrade”
- Seguir los pasos y esperar unos tensos minutos
Pero…¿qué pasa si queremos hacer el proceso contrario? ¿Qué pasa si tenemos una edición Enterprise ó Developer que queremos ahora convertir a Standard? (o de Enterprise a Developer, por ejemplo)
Si estás en esta situación, entonces prepárate porque tienes 2 opciones:
- Downgrade side-by-side
- Downgrade in-place
Downgrade side-by-side
El downgrade side-by-side consiste en básicamente instalar otra instancia con la edición menor (por ejemplo la standard) y mover a ella nuestras bases de datos (bien sea detach-attach ó backup-restore).
Pros:
- Podemos mover los datos a otra máquina y matamos 2 pájaros de un tiro
- Obviamente si planeas seguir usando la misma máquina actual, esto no es un “pro” a tener en cuenta
Contras:
- No es transparente y puede conllevar bastantes cambios de aplicacion y sistemas involucrados
- Instalar una nueva instancia conlleva el problema de conectividad hacia la nueva instancia
- Cambio de cadenas de conexión de todas las aplicaciones
- Actualización de servidores vinculados que apuntan a la instancia antigua (¿los conoces?)
- Aplicaciones de terceros cerradas que apuntan a la máquina
- y un largo etcétera a tener en cuenta
- Hay que acordarse de desinstalar la instancia vieja
- Hay que recrear todos los objetos de seguridad exactamente igual
- ogins, credenciales, proxys,…
- Hay que reconfigurar manualmente todo
- SQL Agent jobs
- Roles de servidor
- …
- ¿Qué pasa con la replicación?¿Qué pasa con log shipping?¿Mirroring?,…
- Efectivamente, hay que destruirlo todo antes y remontarlo de 0, toda una fiesta1
En definitiva, esta alternativa no la vamos a explorar porque básicamente se trata de hacer borron y cuenta nueva y no es lo que queremos (vamos, que para eso no escribo un post :)).
Downgrade in-place
Este tipo de downgrade es el más indicado y razonable en cualquier entorno de producción que se vea envuelto en esta situación, puesto que es absolutamente transparente a todos los niveles. Si se hace bien y en condiciones, el resultado es exáctamente igual al de hacer un upgrade in-place. No tendremos que hacer nada adicional.
¿Qué pasos debemos seguir?
1. Ten a mano tu plan “B”
Cuando digo tener a mano el plan “B” me refiero a tener a mano:
- Nivel de Service Pack aplicado
- Nombre de instancia
- Collation de instancia (importantísimo)
- Configuración de los parámetros de la instancia
- Cuenta de inicio de servicio (importantísimo)
- Tipo de autenticación
- Configuraciones específicas que tengamos en sys.configurations
- Ubicaciones predeterminadas de bases de datos de usuario
- Scripts de recreación de logins, replicación log shipping, jobs de sql agent,…
Es decir, todo lo necesario para recrear desde 0 la instalación si algo fuera mal. Igual piensas, pero a ver…si me dices que se puede hacer un downgrade in-place, ¿esto es realmente necesario? Bueno, yo SIEMPRE lo primero que hago es salvaguardarme ante un supuesto desastre. Si, es obvio y quizás sobre decirlo, pero mas te vale tener un plan “B” SIEMPRE, ya sea aplicar un parche o hacer un “inofensivo” upgrade…si algo va mal te gustará tenerlo…y en este caso que vamos a jugar con datos maestros, más todavía. 🙂
2. Analiza si tus BBDD están haciendo uso de features enterprise actualmente
Si intentas restaurar una base de datos que hace uso de features enterprise, NO TE VA A RESTAURAR EN EDICIÓN INFERIOR.
Afortunadamente, en SQL Server 2008 en adelante podemos consultar la vista de sistema sys.dm_db_persisted_sku_features para ver si la BBDD en cuestión usa algo “no downgradeable”
1: select db_name(), feature_name from sys.dm_db_persisted_sku_features
Para más información: http://msdn.microsoft.com/en-us/library/cc280724.aspx
¿qué pasa si resulta que alguna base de datos hace uso de feature enterprise?
Pues mala suerte, vas a tener que desactivarla y dependiendo de lo que sea vas a tardar más o menos.
Te pondré dos ejemplos:
- Tengo un índice nonclustered comprimido
- Bórralo y dependiendo de su criticidad recrea el índice (sin compresión obviamente) ahora o una vez en standard
- Tengo una tabla comprimida
- Descomprímela, aqui no vas a tener otra que esperar
No olvides revisar código externo
Recuerda que la dmv anterior solo hace tracking de features usadas por una determinada BBDD, pero no puede revisar código dinámico ni features usadas explicitamente por la instancia, que deberás adaptar tu. Por ejemplo:
- ¿Tienes planes de mantenimiento de backup donde especificas compresión? Quitala
- Tienes jobs o aplicaciones que crean objetos particionados, vistas indexadas,…adaptalos
- ¿Tienes activo Resource Governor? Quitalo
- …
NOTA: Recuerda la lista de features enterprise no soportadas en versiones inferiores http://msdn.microsoft.com/en-us/library/cc645993.aspx
3. Haz backup de la service master key
SIEMPRE, repito SIEMPRE que instales una nueva instancia SQL Server, acuérdate de sacar backup a la service master key y ponerla a buen recaudo. Lo que puede pasarte si no lo haces es que si intentas machacar la BBDD “master” (como va a ser nuestro caso ahora), como no le pongas exáctamente el mismo login de inicio de servicio durante el proceso de instalación de SQL Server, toda entidad segura contenida en master y msdb van a ser inservibles. Esto quiere decir que si tenias credenciales o linked servers creados…no te van a funcionar y tendrás que hacer un forzado de reinicialización de master…con lo que tendrás que recrear credenciales. Esto afecta directamente a instancias con replicación acivada.
Recuerda, núnca está de mas tenerlo pero ahora más todavia porque lo necesitaremos:
BACKUP SERVICE MASTER KEY TO FILE = 'D:COPIA SEGURIDADservice_master_key'
ENCRYPTION BY PASSWORD = 'Pa$$w0rd';
Si estás leyendo esto y te has dado cuenta que ya hiciste todo y olvidaste sacar un backup, tu única opción ahora va a ser lanzar un regenerate con la opción FORCE
ALTER SERVICE MASTER KEY FORCE REGENERATE; GO
Una vez lanzado ya podrás trabajar con credenciales, logins,…pero lamentablemente se habrán perdido todos los objetos cifrados con la service master key antigua y deberás recrearlos (incluyendo credenciales)
4. Haz backup de las bases de datos de sistema
Vas a necesitar backup de:
- master
- model
- msdb
Esto es de vital importancia y es sin duda el paso más importante de todos porque vamos básicamente a:
- Desinstalar la instancia actual (por ejemplo la enterprise)
- Reinstalar la nueva instancia en versión inferior (por ejemplo standard)
- Machacar master, model y msdb para que a todos los efectos tengamos la misma instancia
No obstante, recuerda que previamente tienes que asegurarte el famoso plan “B”, que aunque no deberias necesitar recurrir a él, ya te digo que no te arriesgues nunca
4. Desactivar tareas externas
Vamos a proceder a hacer el downgrade con seguridad y mi consejo es que pares toda tarea externa que involucra esta instancia
- Cierra aplicaciones que usen la instancia
- Desactiva (que no destrulle) la replicación que pueda involucrar a la instancia (parando sus agentes )
- Desactiva los jobs de inicio de servicio en caso de haberlos,…
5. Desinstalar la instancia
Si, vamos a hacer un downgrade in-place y la única forma de hacerlo es desinstalando la instancia actual, porque no hay forma de machacarla con los binarios de una edición inferior.
Solo recuerda que no debes hacer nada más de lo especificado anteriormente, es decir…no hace falta que destruyas log shipping o replicación que tengas, por ejemplo. Esto lo recalco porque precisamente la gracia de esto está en que no es necesario reconstruir ni reconfigurar nada.
6. Instala de nuevo la instancia
¿Apuntaste lo que te comenté en el punto 1? Excelente, pues al instalar recuerda poner lo mismo que tenias anteriormente
7. Aplica el mismo service pack exacto que tenias antes de la desinstalación
Si estabas en RTM, no tienes que hacer nada, pero si estabas en un SP1 o algún hotfix específico por aplicar…es el momento de aplicarlo o no funcionará el siguiente punto
8. Restaura las bases de datos del sistema
Todo el downgrade in-place se culmina en este punto, es el momento de restaurar la instancia a su estado inmediatamente anterior a su desinstalación.
Te recuerdo que:
- Restaurando master, estas restaurando la configuración de la instancia
- seguridad (logins, credenciales,…), configuracion de instancia (worker threads, maxdop,…)
- Estas dejando por tanto la instancia en su estado anterior y si lo has hecho bien, todo seguirá funcionando igual
- tus aplicaciones conectarán sin problemas porque los logins existirán
- tus configuraciones de afinamiento de instancia seguirán como las dejaste,…
- Restaurando msdb estas restaurando la configuración de SQL Server Agent
- todos tus jobs
- tu configuración de log shipping, replicación,…
- Restaurando model estas restaurando la configuración de rutas por defecto
- esta concretamente no es prioritario restaurarla, pero tampoco está de mas
Restaurar master
1- Lo primero es parar la instancia si la tienes activa
2- Luego debes lanzar en modo single user el servicio SQL Server:
sqlservr.exe –sINSTANCIA -m
3- Abrir otro cmd.exe y lanzar sqlcommand especificando la ruta de restauración de master
Una vez lanzado el comando, lo que veremos será que el servicio de SQL Server que hemos abierto en la otra consola se detiene. No te asustes, es lo que debe pasar
Para más información http://technet.microsoft.com/en-us/library/ms190679.aspx
Restaurar msdb
Una vez restaurado master, lo siguiente es restaurar msdb. Para hacerlo, asegúrate que el servicio SQL Server Agent está detenido y una vez hecho, lo mas facil es lanzar de nuevo con la misma ventana el replace de msdb
Ahora ya puedes arrancar tu servicio SQL Server Agent
Tal cual lo tienes ahora, has realizado un downgrade de SQL Server exitosamente 🙂
El tiempo medio de downgrade utilizando esta técnica es de 15 minutos (no se cuenta obviamente el tiempo de preparación del plan “B” que es donde más tiempo se invierte)
Te recuerdo que en SolidQ somos expertos en realizar acciones como esta en entornos críticos, si tienes dudas ponte en contacto con nosotros en ibinfo@solidq.com
