Microsoft SQL Server Analysis Services (SSAS) necesita recursos para realizar el procesamiento de estos nuevos datos, recursos que se traducen en memoria RAM, hilos de ejecución e incluso almacenamiento temporal. Estos recursos también son utilizados por Analysis Services cuando los usuarios realizan consultas al cubo o lanzan un refresco de sus informes.El problema viene cuando en nuestro escenario tenemos unos recursos limitados o tenemos unos horarios estrictos de carga de datos y no nos podemos permitir que algún usuario lance una consulta dentro de esos tiempos de carga, cogiendo recursos que iban dirigidos al procesamiento de ese cubo y terminando por ralentizar y bloquear la actualización de datos. Al final ni la carga termina en su tiempo previsto, ni los usuarios tienen los datos más actuales (aunque puedan pesar lo contrario).Existen varias opciones para evitar esto como podría ser técnicas de seguridad dinámica en MDX, pero en este post nos vamos a centrar en la flexibilidad que nos ofrecen los roles.Si nosotros, como administradores de nuestra solucion SSAS, quisiésemos que ciertos usuarios pertenecientes a un rol no pudiesen conectarse, podríamos ir a las propiedades de los roles que queremos desactivar y quitarle el acceso al cubo.
Por ejemplo, vamos a las propiedades de los roles de nuestro Adventure Works DW 2008R2:
Y elegimos el valor “None” para el acceso al cubo Adventure Works:
Una vez hecho esto, los usuarios de ese rol no podrán acceder al cubo mostrándose un mensaje de error, ya sea por Microsoft SQL Server Management Studio u otras herramientas como Microsoft Excel:
Todo esto lo hemos hecho de forma manual, pero también tenemos la posibilidad de hacerlo mediante un script Powershell.
En este script solo tenemos que simular lo mismo que hemos hecho manualmente, conectándonos al servidor de Analysis Services y a la base de datos y cubo correspondiente. A partir de aqui, leemos cada uno de los permisos del cubo y asignamos a la propiedad “Read” el valor que queramos (0=lectura desactivada,1=lectura activada).
Si queremos añadirle un poco de complejidad al script, podemos comprobar si el rol al cual le vamos a cambiar la propiedad “Read” está dentro de nuestra lista de roles de administrador que hemos asignado previamente, y en este caso, dejarle con su permiso de lectura activado.
El script de powershell quedaría así (sólo hay que cambiar aquellas variables con el simbolo $ que estan antes del comentario “#Comienza el script”):
#SolidQ 2011 Ruben Pertusa Lopez
#SSAS desactivar roles
#Para permitir ejecucion de Scrips PS ejecutar: "Set-ExecutionPolicy unrestricted"
#Poner lista con comas de los nombres de roles que no se tienen que desactivar,por
#ejemplo "Administradores,Control Total"
$admin_roles="ejemploroladmin1","ejemploroladmin2"
#Valor 1=activar lectura a cubo; 0=desactivar lectura a cubo
$read_allowed=0
#Datos de conexion, servidor, base de datos y nombre del cubo
$ServerName="."
$databasename="Adventure Works DW 2008 R2"
$cubo="Adventure Works"
#Comienza el script
[Reflection.Assembly]::LoadWithPartialName("Microsoft.AnalysisServices") >$NULL
$server = New-Object Microsoft.AnalysisServices.Server
$server.connect($ServerName)
if ($server.name -eq $null) {
Write-Output ("Servidor '{0}' no encontrado" -f $ServerName)
break
}
else
{
$db=$server.Databases.item($databasename)
if ($db.name -eq $null)
{
Write-Output ("Cubo '{0}' no encontrado" -f $databasename)
break
}
else
{
$cubo = $db.Cubes.item($cubo)
foreach($perm in $cubo.CubePermissions)
{
if(-not( $admin_roles -match $perm.Role.Name))
{
#Rol no admin, desactivamos o activamos lectura
$perm.Read = $read_allowed
$perm.Update()
write-output("Rol desactivado")
}else{
write-output("Rol administrador")
}
}
}
}
Con esto estaríamos listos para incluirlo dentro de nuestros procesos de carga, por ejemplo ejecutándolo como un paso más dentro de nuestro job de recarga del data warehouse que tenemos en el Agente SQL (SQL Agent).
Incluso podríamos ponerlos de tal forma que desactive los roles antes de la carga, realice la carga y vuelva a reactivar los roles.
Podemos ver un ejemplo:
Y la definición de estos nuevos pasos powershell quedaría de la siguiente forma:
Si queremos profundizar en el tema, podemos encontrar más información en estos enlaces:
Creación de pasos powershell en SQL Agent por MSDN
Ayuda para powershell con Analysis Services por MSDN
Rubén Pertusa, Twitter: @rpertusa
