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:
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:
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:
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:
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.
Sigue descubriendo:
ÚLTIMAS NOTÍCIAS
Novedades de Global Mapper v26.017/09/2024 - 18:00
Madrid Tech Show 202416/09/2024 - 16:04
Novedades de Delphi 12.210/09/2024 - 17:58
Navicat BI – Libere el poder de los datos.10/09/2024 - 11:34
Dejar un comentario
¿Quieres unirte a la conversación?¡Siéntete libre de contribuir!