Un problema habitual al que nos tenemos que enfrentar es el realizar downgrades de SQL Server Enterprise Edition a Standard Edition. Las razones pueden ser desde un error cuando se realizó el despliegue inicial hasta un cambio para obtener una reducción de costes en licenciamiento. La forma soportada para realizar este cambio pasa por una desinstalación completa de la instancia y una reinstalación.
Esta aproximación implica un tiempo de parada importante, así como un trabajo minucioso de copia/restauración de bases de datos, preservar la configuración de la instalación original, las rutas originales de la instalación, mantener la cuenta de servicio original, recordar realizar los backups/restores de las claves de servicio SMK, etc. En nuestra opinión creemos que Microsoft debería soportar el downgrade de la misma forma que se soporta el upgrade, directamente desde el instalador.
Intentando cambiar la versión desde el instalador
Si intentamos realizar un “upgrade” desde el setup e indicamos una clave de licencia Standard ocurre lo siguiente:
Curiosamente vemos que hay una regla llamada “downgrade” que pasa correctamente y sin errores, lo cual da ciertas esperanzas de que pueda realizarse la operación:
Sin embargo, no parece existir ninguna “action” asociada a ese proceso de downgrade en el setup (¿editiondowngrade?), o al menos no existe una documentada:
Sin embargo, si lanzamos un EditionUpgrade haciendo un skip de la regla que nos falla veremos como podemos lanzar el proceso hasta el final:
setup.exe /ACTION=EDITIONUPGRADE /SkipRules=EditionUpgradeMatrixCheck
Tras unos segundos, el proceso completará y parece todo correcto con el cambio de versión a Standard:
Sin embargo, si comprobamos que versión reporta el motor relacional, aunque lo reiniciemos, sigue apareciendo Enterprise, es como si todo el setup no hubiera hecho absolutamente nada:
Podemos validar que efectivamente se comporta como Enterprise por ejemplo haciendo uso de una funcionalidad Enterprise only, como es la reconstrucción de índices online:
Creemos que el no permitir realizar este downgrade es realmente una mala idea por parte de Microsoft. La razón es que quien tenga decidido ir de Enterprise a Standard no va a dejar de hacerlo por no estar disponible esta opción en el setup, se buscará la forma de conseguirlo, aunque probablemente “maldiciendo” durante el proceso a Microsoft por dificultar este cambio innecesariamente. Creemos que esto no encaja con la política de agilidad, de flexibilidad y elección que Microsoft quiere promover en general por lo que esperamos que esto pueda cambiar en un futuro.
Para poder realizar este downgrade es comprensible y deseable que se realizaran algunas validaciones previas, como por ejemplo consultar sys.dm_db_persisted_sku_features en cada una de las bases de datos para avisar de incompatibilidades y no permitir el cambio de licencia en estos casos. También habría que comprobar que no se estén usando características “Enterprise only” en otros servicios como por ejemplo Analysis Services habría que asegurarnos que no tenemos muchas particiones, ni writeback, etc. En aquellos casos donde todo esté “limpio” debería poderse realizar con un mero reinicio de la instancia sin embargo vemos que pasar de una versión Enterprise a Standard no está dentro de la lista de cambios soportados:
Sin embargo, si nos fijamos existe un escenario de migración soportado de Evaluation Enterprise a Standard por lo que realmente todo aquello que sea necesario detectar/hacer para pasar de Enterprise a Standard ya debe estar contemplado por el setup. Creemos por tanto que es más un tema de voluntad por parte de Microsoft, de desbloquear esta posibilidad más que un problema técnico real.
Que ocurre por debajo
Con fines educativos podemos intentar determinar qué cambios realmente ocurren a bajo nivel cuando seleccionamos Enterprise Edition versus Standard Edition. Para ello vamos a comparar dos VM iguales donde se ha instalado SQL Server y donde la única diferencia es el uso de una versión u otra.
Una vez tenemos estas dos máquinas, comenzamos comparando los sistemas de ficheros, en búsqueda de diferencias a nivel de DLLs, etc. A este nivel encontramos algunas diferencias, la mayoría normales, debido a ficheros que se generan durante la instalación, a logs de arranque o relacionadas con MDS (Master Data Services) que no existe en versión Standar. También vemos que tenemos dos documentos de licencias distintos, uno para Enterprise y otro para STD, pero de nuevo diferencias esperables y previsibles:
Por tanto, en principio, a nivel de binarios no vemos nada que nos indique que tengamos ninguna diferencia. El siguiente paso será comparar los logs de registro de Windows. En este punto sí encontramos diferencias en lo que respecta a varias entradas de ProductID, DigitalProductID, EditionType y Checksums:
Vamos a proceder a crear un patch del registro que nos copie estos valores (ProductID, DigitalProductID, Edition, EditionType y Checksum) para cada una de las rutas en las que aparecen. Crearemos un fichero .reg con las entradas de la versión Standard y otro con las de la versión Enterprise:
Convetir instancia Enterprise a Standard
Una vez tenemos los ficheros .REG, apagaremos el servicio de la instancia Enterprise y probaremos a sobreescribir los valores del registro con los de la versión Standard. Tras rearrancar el servicio podemos comprobar como aparentemente la versión reportada cambia de Enterprise Edition a Standard Edition:
Si intentamos ejecutar alguna operación que es solo Enterprise, como un rebuild online de índices, obtendremos el error esperado:
Vuelta atrás de Standard a Enterprise
Si volvemos a apagar la instancia y reaplicamos los valores del registro de la versión Enterprise, vemos como la instancia vuelve a comportarse como una versión Enterprise:
Convertir instancia Standard a Enterprise
Ahora podemos proceder a testear la acción inversa (convertir un Standard en Enterprise y viceversa) y veremos que también parece funcionar correctamente:
Si intentamos ejecutar alguna operación que es solo Enterprise, como un rebuild online de índices, vemos que funciona correctamente:
Vuelta atrás de Enterprise a Standard
Si volvemos a apagar la instancia y reaplicamos los valores del registro de la versión Standard, vemos como la instancia vuelve a comportarse como una versión Standard y por tanto fallará la reconstrucción online:
Conclusiones
Obviamente no podemos recomendar el utilizar un mecanismo como este para realizar un downgrade en un entorno productivo ya que estaríamos invalidando el soporte que pudiéramos necesitar por parte de Microsoft en un futuro. Además, únicamente hemos probado el funcionamiento en uno de los servicios que incluye SQL Server, el motor relacional, por lo que puede que este proceso falle estrepitósamente para otros servicios como Analysis Services, Integration Services, etc. si hacemos uso de alguna función solo disponible en Enterprise. Anteriormente comentamos algunos casos que podrían hacer fallar Analysis Services pero en el caso de Integration Services también tenemos varias fuentes y destinos que solo están disponibles en Enterprise lo cual puede hacer fallar nuestros paquetes si bajamos a Standard:
Sin embargo, pese a los riesgos, consideramos que puede ser de utilidad el conocer esta posibilidad para, por ejemplo, entornos de testing. En ocasiones se nos ha hecho la pregunta “¿Cuánto rendimiento obtendríamos con Enterprise al ejecutar este conjunto de consutas?” o “¿Cuánto rendimiento perderíamos si bajáramos a Standard?”. Es bastante frecuente esta duda en entornos datawarehouse, donde muchas optimizaciones de Enterprise que afectan al optimizador, a los índices columnares, etc. pueden marcar una gran diferencia entre versiones.
También ocurre con bastante frecuencia que los entornos de pruebas utilizan versión Developer, que es equivalente a Enterprise, y cuando nos movemos a un entorno productivo se utiliza Standard y nos encontramos cambios en el comportamiento (negativos) que no se detectaron durante los tests. Por tanto, creemos que el procedimiento descrito puede ser útil en escenarios de prueba donde necesitemos cambiar de Developer a Standard o de Standard a Enterprise o de Enterprise a Standard de forma temporal, evitando una reinstalación completa de la instancia, cuando solo queremos realizar algunas pruebas de concepto o de evaluación de rendimiento.
Si has llegado hasta aquí, probablemente te encuentres de vez en cuando consultas en SQL Server que no responden como hubiera sido esperado. Si es así y quieres aprender Planes de Ejecución, para entender qué es lo que está ocurriendo y saber cómo solucionarlo, te recomiendo nuestro curso de Planes de Ejecución en modalidad on-demand en promoción hasta el 20 de Diciembre, así como suscribirte a nuestra newsletter.
