Volver al Índice | Anterior: Índices de almacén de columnas. Actualizaciones de la tabla | Siguiente: Distributed Replay
Descubriendo SQL 2012 – Contained database (Base de datos autocontenida)
Autora: Raquel Vicente de la Rosa
Hoy vamos a mostrar que son y cómo trabajar con bases de datos autocontenidas. Como ya comentamos en la introducción a la serie, esta configuración es el complemento ideal en una topología de AlwaysOn, aunque es útil en muchos otros escenarios.
Veamos antes de nada en qué consiste una base de datos autocontenida: es una base de datos que almacena en la misma base de datos todos aquellos metadatos que necesita, eliminando dependencias con “master”.
¿En qué se diferencia de una base de datos sin esta configuración? En una base de datos “normal”, los metadatos que describen la base de datos se almacenan en master; mientras que en una base de datos autocontenida también se almacenan en la propia base de datos. Esto implica que los metadatos se almacenan utilizando la collation de la propia base de datos.
Y sobre todo, se elimina la dependencia de master para la autenticación: Cuando nos conectamos a una base de datos “tradicional”, primero se comprueba el login a nivel de servidor, y a continuación se encuentra a qué usuario (user) se asigna dentro de esta base de datos. Esto provoca que cuando restauramos una base de datos en otro servidor, tenemos usuarios huérfanos.
En el párrafo anterior acabamos de intuir cuál es la gran ventaja de las bases de datos autocontenidas: Cuando las movemos a otro servidor, su comportamiento es exactamente el mismo que en el servidor de origen, sin necesidad de solucionar el problema de los usuarios huérfanos que aunque sencillo (https://msdn.microsoft.com/en-us/library/ms175475.aspx), era engorroso, especialmente con un número alto de usuarios.
Pasemos a cómo configurar una base de datos para que sea autocontenida. En este ejemplo vamos a utilizar las bases de datos que pertenecen al grupo de alta disponibilidad que creamos en el artículo de AlwaysOn, pero el procedimiento es igual para cualquier otra base de datos.
El primer paso es permitir a nivel de servidor el uso de bases de datos autocontenidas.Para ello, con el botón derecho en el nombre del servidor, seleccionamos propiedades, y en el apartado “Advanced”, podemos elegir “Enable contained databases”:
.png)
Por supuesto, también podemos realizar este cambio mediante código transact, ejecutando:
sp_configure'contained database authentication' , 1
GO
RECONFIGURE
Con el botón derecho sobre la base de datos, seleccionamos propiedades, y en la pestaña de opciones elegimos:
.png)
En este momento, la base de datos ya está configurada. Ahora necesitamos crear un usuario en esta base de datos. Al haberla configurado como autocontenida, el menú será diferente, aunque lo iniciamos de la misma forma:
.png)
La primera y principal diferencia es que aparecerá el menú que nos permite elegir el tipo de usuario:
.png)
Vamos a centrarnos en las opciones más frecuentes, usuarios de SQL y usuarios de Windows.
La primera opción “usuario de SQL con login”, nos permitirá configurar un usuario “tradicional”, es decir, asociado a un login de SQL ya existente. Para crear un usuario “independiente” de tipo autenticación SQL, utilizaremos “SQL user with password”:
.png)
En el caso de crear un login de Windows, utilizaremos “Windows user”. Si dejamos el campo login en blanco, será cuando creemos un usuario solamente contenido en la base de datos. Si añadimos un login ya existente, estaremos creando un usuario “tradicional”:
.png)
Si quisiéramos realizar las mismas operaciones utilizando transact, los comandos respectivos serían (ejecutados en el contexto de la base de datos):
CREATE USER[app1_user]WITH PASSWORD = N'xxxxx'
CREATE USER[dsd\sqluser]
Finalmente, veamos como conectarnos utilizando cualquiera de estos usuarios, vamos a hacer la muestra con Management Studio, pero el método sería el mismo en cualquier otra aplicación. Después de especificar el usuario, abriremos el menú “Options”:
.png)
Y seleccionaremos la pestaña “Connection properties”, donde incluiremos la base de datos. Este paso es imprescindible ya que este usuario solamente existe en el contexto de la base de datos:
.png)
En la mayoría de aplicaciones esto se hará en la cadena de conexión, por lo que no será transparente para el usuario, pero imprescindible para el programador.