AlwaysOn con PowerShell II

Introducción

En nuestro anterior artículo vimos cómo parte de la administración de AlwaysOn se puede realizar desde PowerShell usando SQLPS, pero no tocamos los objetos de administración de SQL Server, conocidos como SMO por sus siglas en inglés. Aquí veremos cómo utilizar la jerarquía de objetos para realizar parte de la administración de AlwaysOn.

Objetos de Administración de SQL Server (SMO)

Como dijimos en el anterior artículo, mientras que para consultar las bases de datos lo mejor es emplear un lenguaje específico, para administrar los servidores podemos perfectamente usar PowerShell que nos ayuda a automatizar las labores repetitivas. También vimos el módulo SQLPS donde están los comandos de SQL Server. Dentro de este módulo está también el acceso a los objetos de administración: son una colección de objetos diseñados para programar todos los aspectos de la administración de Microsoft SQL Server.

Cuando hablamos de un modelo de objetos nos estamos refiriendo a que desde programación externa podemos acceder remotamente a los objetos del motor de base de datos para administrar el servidor. Cada objeto tiene su propia clase que debemos instanciar como cualquier otro objeto remoto. Todas estas clases están dentro del espacio de nombres Microsoft.SqlServer.Management.Smo. Se implementa como un ensamblado de .NET, por lo que hay que tener el Framework correspondiente a la versión de SQL Server, y se instalan de forma predeterminada en la caché de ensamblados global.

De todo esto se encarga de verificar e instalar SQL Server. Lo tenemos que tener en cuenta en caso de que hagamos una instalación de herramientas de cliente exclusivamente, incluyendo SQL Server PoweShell. También se pueden instalar desde el Feature Pack de SQL Server, archivo Shared Management Objects. En todo caso, siempre van a necesitar el cliente de SQL Server, que suele venir instalado con .NET.

La referencia para SMO, al ser un ensamblado de .NET, suele venir para los leguajes C# y Visual Basic, aunque también podemos encontrar ejemplos de PowerShell, que son muy parecidos.

Categorías SMO

Debemos distinguir las clases SMO en dos categorías: de instancia y de utilidad.

Las clases de instancia representan los objetos internos del servidor de bases de datos, de la instancia. El objeto de nivel superior es Microsoft.SqlServer.Management.Smo.Server del cual deriva el resto de la jerarquía. Es decir, partiendo de la instancia de SQL Server, encontramos las bases de datos, las tablas, las columnas, etc. En caso de que un elemento tenga varios secundarios (una tabla tiene varias columnas), SMO implementa colecciones «normales» con las que podemos trabajar como con cualquier colección, aunque teniendo en cuenta que detrás hay objetos remotos de base de datos, no solamente objetos en memoria.

Podríamos decir que por encima de la instancia se encuentra la clase Microsoft.SqlServer.Management.Smo.Wmi.ManagedComputer que representa, por ejemplo, la configuración de red y los servicios de SQL Server.

Las clases de utilidad son grupos de objetos creados explícitamente para realizar tareas concretas: clase de transferencia, clases de copia de seguridad y restauración y clase Scripter. Veremos alguna más adelante.

Clases de Instancia

Pongámonos con un ejemplo que usa las clases de instancia. Cuando se crea un entorno nuevo, hay que crear también los inicios de sesión, que nos viene muy bien que se pueda hacer automáticamente con AlwaysOn, pues lo tendremos que ejecutar en cada instancia. Para ello empleamos:

  • En primer lugar conectamos con el servidor instanciando el objeto Server. En este caso empleamos el usuario de Windows. $Replica1 es el nombre completo del servidor SQL Server:
  • Acudimos a la colección Logins para ver si ya existe. Como un inicio de sesión pertenece a la instancia, el objeto correspondiente está debajo de Server.
  • Si existe, accediendo al inicio de sesión dentro de la colección, lo eliminamos.
  • Creamos –instanciamos– un nuevo objeto inicio de sesión. Ojo, primero creamos el objeto en memoria y al final, cuanto ya tiene toda la configuración, lo creamos en la instancia de base de datos.
  • Asignamos el tipo –observamos que estamos empleando el espacio de nombres completo para que no haya confusión de inicio de sesión.
  • Si tiene base de datos o idioma por defecto, se los asignamos.
  • Si es un inicio de sesión de un usuario de SQL Server, le asignamos propiedades adicionales.
  • Fijémonos cómo acudimos directamente dentro de la jerarquía al Sid del usuario de la base de datos donde ya está asignado para que el inicio de sesión lo use y se conecten automáticamente. Para ello recorremos, además de la jerarquía, las colecciones correspondientes.
  • Por último se crea el inicio de sesión en la instancia de SQL Server.

Esto lo podemos hacer tanto en el servidor primario como en los secundarios, asignando al nuevo objeto inicio de sesión, directamente las propiedades que ya tenemos del objeto inicio de sesión del primario, especialmente el SID si aplica.

Clases de Utilidad

En este caso vamos a ver un ejemplo de restauración. Necesitamos automatizar el proceso de restauración de las bases de datos en entornos volátiles de desarrollo para luego crear AlwaysOn. Para ello, una vez tenemos instanciado el objeto Server y hemos llenado una matriz con los nombres de las bases de datos:

  • Asignamos la ruta completa del archivo .bak a una variable.
  • Instanciamos la utilidad de restauración y asignamos el archivo a un BackupDeviceItem que añadiremos a la utilidad.
  • Recorremos los archivos lógicos diferenciando si es un archivo de registro, el primer archivo de datos o el segundo de datos.
  • Como queremos poner los archivos de base de datos en directorios distintos, hay que crear un objeto RelocateFile que también es una clase de utilidad.
  • Añadimos la nueva ubicación del archivo.
  • Una vez hemos hecho la parte complicada, nos queda asignar unas propiedades adicionales, por ejemplo, como estamos en un servidor secundario, dejamos la base de datos en modo NORECOVERY.
  • Por último, ejecutamos la restauración.

Clases Scripter

Esta es una clase muy útil especialmente cuando queremos copiar ciertos objetos de un servidor a otro y sería complicado asignar todas las propiedades una a una. Por ejemplo, cuando se crea una instancia AlwaysOn, hay que transferir los trabajos del Agente SQL Server a todos los servidores que puedan estar activos. Para ello:

  • Instanciamos la instancia de SQL Server y el Agente SQL Server correspondiente, tanto en el origen como en el destino:
  • A continuación, por cada trabajo que existe en el origen.
  • Verificamos que el trabajo tenga pasos.
  • Para luego verificar que la base de datos del primer paso es una de las que queremos en el servidor origen puede haber varios grupos AlwaysOn o bases de datos que no están replicadas.
  • Si estamos creando los trabajos en el servidor secundario, hay que hacerlo deshabilitados porque las bases de datos no están en línea.
  • Vemos lo sencillo que es crear el script y luego ejecutarlo en el destino.

Conclusión

Los Objetos de Administración de SQL Server (SMO) nos provee un modelo de objetos muy poderoso y sencillo para la administración de cualquier instancia de SQL Server y nos permite automatizar la creación de los objetos adicionales en las instancias de AlwaysOn.

0 comentarios

Dejar un comentario

¿Quieres unirte a la conversación?
Siéntete libre de contribuir

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Utilizamos cookies propias y de terceros para mejorar nuestros servicios. Al utilizar el Sitio, usted acepta el uso de cookies. más información

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close