Hace uno dias, en los foros de noticias uno de los compañeros preguntaba por herramientas de administración multiservidor. Me explico, una herramienta que cuando ejecutes un script, no solo lo ejecute en un server, sino que se encargue de que tu comando (tanto si es de manipulación de datos -DML es decir insert,update…- , como si es de definición de datos -DDL, es decir create table, etc- se ejecute en un conjunto de servidores.

Me sorprendió ver como muy poca gente conocía que esta funcionalidad la tiene SQL Server Management Studio, es cierto que no es probablemente una funcionalidad para un gran porcentaje de usuarios, pasará desapercibido, no tendrá utilidad. Sin embargo veo algunos escenarios de mucha utilidad:

Seguro que hay otro montón de escenarios útiles, pero creo que con estos dos, el lector interesado sabrá de que estoy hablando, y si no esta en estos, el que lo necesite, seguramente sea capaz de inferir que esta funcionalidad puede ser útil, también para él.

Voy a hacer la demostración y la captura de pantallas con el SQL Server Management Studio de la CTP3 de Denali, pero esto ya funciona, desde versiones anteriores (desde SQL 2008).

Lo primero que haremos será, tras abrir nuestro SQL Server Management Studio, ir al menú de Ver, y ahí elegir servidores registrados, notad como hay una carpeta llamada Central Management Servers, como puede observarse en la siguiente figura. Disculpad aquellos que no utiliceis las versiones en inglés, entiendo que para un hispano hablante, quizá debiera usar esas versiones, pero por mi trabajo, me veo muy a menudo obligado a usarlo en inglés y prefiero no hacerme un lio con las traducciones. Mis disculpas al que le moleste.

Pulsando con el botón derecho sobre Central Management Servers nos aparecerá un  menú contextual con leyenda “Register Central Management Server”, este será el servidor que nos valga como nodo principal, por decirlo de una forma poco ortodoxa, pero bastante comprensible.  En el asistente nos permite especificar tanto una descripción como una forma de conectarse, en mi caso, lo haré con mi usuario Administrador y con seguridad integrada. Cabe destacar que para no almacenar contraseñas que además lo serían de usuarios con muchos privilegios, solamente está permitida la seguridad integrada, según se detalla en este artículo http://msdn.microsoft.com/en-us/library/bb934126(v=SQL.100).aspx Aquí simplemente hemos de conectarnos con los suficientes privilegios. (Son privilegios obviamente de administración de los servidores es decir, unos privilegios bastante elevados)

Tras comprobar que nos conectamos de forma adecuada, pulsaremos save, a partir de este momento hemos de añadir los servidores que serán administrados desde éste.  No es necesario añadirlo dentro de la subcarpeta Central Management Servers, es más podemos crear grupos de servidores que se comporten como tales. Por ejemplo, podemos crear un grupo Desarrollo, de forma que script aplicados a server de desarrollo se apliquen a tantos servidores de desarrollo como tengamos registrados.

Veamos un ejemplo de como hacerlo. Sobre “Local Server Groups” pulsamos botón derecho y “New SQL Server Group”, esto hace que creemos una carpeta común bajo la que ubicar servers. dentro de esa carpeta, botón derecho de nuevo y registraremos nuestros servers, como puede verse en la siguiente figura.

En el caso del ejemplo tenemos registrados dos servidores, en realidad son las instancias SQL 2008 R2 y SQL 2005 que tengo instaladas en mi equipo.

Si sobre el grupo Desarrollo, presionamos botón derecho new query, nos aparecerá una ventanita, en la que, podremos comprobar como la barra de estado, no es amarilla ni gris, sino de un color rosado, También nos dice cuantos servidores hay contectados. Cualquier query ejecutado ahí, se ejecutará en ambos servers. Ojo, con el tipo de queries que hacemos, puesto que pueden fallar. Suelo decir que cuando alguien ejecuta un SELECT * , Dios mata un gatito, es una broma que me gusta hacer y que en este caso cobra especial relevancia, en mi caso por ejemplo, si hago esto saldrá este mensaje.

.\SQK2K8R2(WIN-P3PS5OB2GSJ\Administrator): (15 row(s) affected)

.\SQL2K5(WIN-P3PS5OB2GSJ\Administrator): An error occurred while executing batch. Error message is: The result set could not be merged because the result schema did not match the schema from the first responding server.

.\SQL2K5(WIN-P3PS5OB2GSJ\Administrator): (8 row(s) affected)

Esto es básicamente porque lo que hace SQL Server Management Studio es ejecutar el mismo comando en ambos servers y unir el resultado como si de un UNION ALL se tratara. En mi caso, entre la versión SQL 2005 y la versión SQL 2008 R2, la tabla sys.sysdatabases tiene estructuras distintas, así pues.. no puede unir el resultado. Cambiaré ese * y así podré ver como si que funciona. La sentencia que ejecutaré y el resultado podeis verlo en la siguiente captura de pantalla. Notad como aparece una columna que yo no he solicitado ([Server Name]) que indica a que server pertenecen esos objetos.

Si os fijais ha aparecido esa columna que mencionabamos además de aparecer la barra de estado en color rosa.

Esta opción es una opción del propio SQL Server Management Studio,  tanto que mezcle los resultados ( lo que hablabamos antes y que tiene problemas con servidores con distintas versiones) tanto que añada el nombre del servidor o incluso el nombre de login. Si vamos al menú Tools (herramientas) a la opcion “Options” (Opciones), bajo Query Results, SQL Server veremos un apartado Multiserver Results  en el que controlar ese comportamiento. Obviamente podremos cambiarlo hasta que se adecúe lo mejor posible a nuestro propio entorno. Como puede verse en la siguiente figura.

Conclusion: SQL Server Management Studio, es una herramienta realmente potente, con un gran número de opciones y funcionalidades, algunas que permanecen ocultas para muchos, merece la pena bucear un poquito en su funcionamiento para realmente sacarle el máximo provecho.  En este caso, para la administración multi servidor.