Crear el directorio compartido para pasar las copias de seguridad.
Introducción
Aunque es muy fácil crear todo lo relacionado con AlwaysOn desde el «wizard», cuando se necesita una automatización podemos recurrir a PowerShell para facilitar la creación, por ejemplo, de máquinas nuevas en entornos de desarrollo. Además es interesante conocer las técnicas para acceder a SQL Server.
SQL Server PowerShell
Para trabajar con SQL Server se puede usar el Entorno de Scripting Integrado Windows PowerShell que mediante líneas de comandos nos permite trabajar con las características de SQL Server. El entorno es interactivo al ser interpretado y no perderse los objetos entre ejecuciones.
El lenguaje de PowerShell, al ser un lenguaje de programación, permite una lógica más compleja que Transact-SQL, que es un lenguaje matemático. Por lo tanto, en el caso de la administración, que es la tarea de este artículo, nos puede ayudar bastante.
El módulo que nos proporciona SQL Server es SQLPS, un módulo comprensivo que incluye todo lo necesario para trabajar con el servidor de base de datos. Al cargarlo, estamos trayendo al entorno un proveedor de SQL Server que usa un mecanismo de navegación basado en rutas, como veremos, y un conjunto de comandos llamados en PowerShell cmdlets.
Módulo SQLPS
Lo primero es importar el módulo SQLPS. Para ello, antes tenemos que tener en cuenta la seguridad en PowerShell, que por defecto está puesta en restringida e impide que se cargue dicho módulo. Lo normal es que se habilite la ejecución de scripts firmados y solo para este proceso.
A continuación podemos importar el módulo. Pero si lo hacemos con las opciones por defecto van a aparecer advertencias porque los verbos usados en los nombres de dos cmdlets (Encode-Sqlname y Decode-Sqlname) no coinciden con los verbos aprobados para Windows PowerShell. Para no recibir una advertencia que nos puede distraer en nuestro desarrollo, le decimos que no verifique los nombres.
Proveedor de PowerShell de SQL Server
Vamos a empezar por explicar las rutas que usa el proveedor de SQL Server. Lo que hacen es transformar las jerarquías de objetos del motor de base de datos en unas rutas de acceso similares a las del sistema de archivos. Tan similares que hasta se puede usar, por ejemplo, cd cambiar directorio.
La jerarquía empieza en SQLSERVER: que es la raíz para el proveedor de SQL Server. Es decir, otros proveedores pueden implementar otras unidades, pero SQL Server solo implementa una que es la mencionada. A partir de ahí hay un conjunto de carpetas principales que se corresponden con los componentes de SQL Server: recordemos que SQL Server es un paquete de utilidades en realidad como Servidor de bases de datos, Analysis Services, etc. Para los objetos de base de datos la carpeta es SQL, que además incluye el Agente, Broker y correo.
Luego tenemos que decir con qué instancia nos queremos conectar. Si la instancia es la por defecto, su nombre es DEFAULT. Veamos un ejemplo para crear el extremo que necesita AlwaysOn para que se comuniquen las instancias:
Como no me gustan las líneas largas porque son difíciles de leer, suelo estructurar los comandos en varias líneas. Para separarlas hay que emplear el acento grave (`). También, aunque no es necesario, me gusta poner un punto y coma para dejar claro dónde termina cada comando.
cmdlets del motor de base de datos
El principal es el que ejecuta scripts de Transact-SQL y de XQuery, es decir, que nos permite llevar a cabo una gran parte de lo que se puede hacer con sqlcmd. Aunque el modelo de objetos permite hacer casi todo en SQL Server, a veces nos conviene usar directamente un script de SQL Server. Una de las ventajas de PowerShell es que podemos embeber variables dentro de la cadena que se envía a la instancia de SQL Server, siempre y cuando esté debidamente acotada. Es decir, que PowerShell sea capaz de diferencia el nombre de la variable del resto del texto. De otra manera, hay que componer el texto aparte.
En el ejemplo, como para que funcione AlwaysOn las bases de datos tienen que estar en modo de recuperación completo, lo hacemos para todas y así nos aseguramos:
Siguientes pasos
Antes de empezar a crear el grupo de disponibilidad, podemos necesitar:
Una vez tenemos los requisitos, podemos ya crear el grupo de disponibilidad, en este caso con las características:
Lo siguiente es hacer en el primario las copias de seguridad completas y de registro usando el cmdlet Backup-SqlDatabase.
Pasamos al secundario y unimos la réplica al grupo de disponibilidad:
Restauramos en el secundario las copias de seguridad anteriores en modo de no recuperación, por ejemplo usando el comando Restore-SqlDatabase.
Por último unimos las bases de datos al grupo de disponibilidad:
Conclusión
Aunque en este artículo solo presentamos los comandos específicos de AlwaysOn, dado que cada instalación es propia, hemos podido ver la utilidad de crear un script parametrizable para generar cualquier grupo de disponibilidad.
En el siguiente artículo vemos lo útil que es SMO y cómo utilizar la jerarquía de objetos para realizar parte de la administración de AlwaysOn:
Sigue descubriendo:
ÚLTIMAS NOTÍCIAS
ABBYY OCR Container09/12/2024 - 12:04
Gestión Documental para Desarrolladores.04/12/2024 - 16:02
Licencias Academicas25/11/2024 - 10:41
Global Mapper v.26 Imágenes ráster en detalle20/11/2024 - 10:05
Dejar un comentario
¿Quieres unirte a la conversación?¡Siéntete libre de contribuir!