Una de las novedades más interesantes de SQL Server 2012 nombre en clave “Denali” son las bases de datos contenidas. Desde hace mucho tiempo llevamos comentando que las bases de SQL Server no son demasiado portables. Ahora mismo, en SQL Server 2008 R2, dada una base de datos concreta, podemos hacerle una copia de seguridad y restaurarla en otra instancia.

Al hacer esto, efectivamente la base de dato y los datos se mueven, pero estamos perdiendo el vínculo con piezas que hacen que esa base de datos sea parte de una aplicación. Estas piezas de las que hablamos son piezas relacionadas con la parte administrativas, entre las cuales están:

  • Seguridad
  • Roles
  • Servidores vinculados
  • SQL CLR
  • Database Mail
  • Service Broker
  • Replicación
  • Agente de SQL Server
  • TempDB (collations diferentes)

En definitiva, se pierde el vínculo con las entidades o componentes que no están “incluidos” dentro de la base de datos. Para mejorar un poco este tipo de escenarios aparecen las bases de datos auto-contenidas.

En esta publicación vamos a ver una introducción a esta novedad de la nueva versión de SQL Server. Veremos los conceptos de las bases de datos autocontenidas, introduciremos nuevos términos relativos a esta nueva característica y por ultimo haremos demostraciones prácticas en cuanto a la creación de este tipo de bases de datos y en cuanto a la gestión de usuarios y conexiones directas sobre bases de datos autocontenidas.

¿Qué son las bases de datos autocontenidas?

Las bases de datos autocontenidas son un tipo nuevo de base de datos que aparecen en SQL Server 2012 nombre en clave “Denali” y que lo que pretenden es eliminar las dependencias entre base de datos e instancia. Por ejemplo los Usuarios podrán conectar a las bases de datos autocontenidas sin necesidad de tener un inicio de sesión a nivel de instancia, a partir de ahora podemos conectar única y exclusivamente a la base de datos. Con esta aislamiento entre base de datos e instancia de SQL Server se consigue que las migraciones de bases de datos de una instancia a otra sean más sencillas.

Para empezar a familiarizarnos con las bases de datos autocontenidas vamos a introducir antes una serie de conceptos y términos. Cuando definimos una base de datos con el comando DDL Create database, podemos especificar el tipo de base de datos que queremos crear. Ahora con Denali distinguimos tres tipos:

  • Fully contained database (completamente autocontenida):

Una base de datos completamente contenida no permite objetos que crucen la barrera a nivel e aplicación, es decir que no permite objetos que trabajen a nivel de instancia. Esta opción todavía no está soportada.

  • Partially contained database (parcialmente autocontenida):

Se trata de una base de datos autocontenida que permite la creación y uso de objetos que cruzan la barrera a nivel de aplicación, es decir que permite la creación y uso de objetos que trabajen a nivel de instancia.

  • Non-contained database (base de datos no autocontenida)

Es la opción por defecto que tienen todas las bases de datos, puesto que no versiones anteriores no existía esta característica. Recuerde que la política de Microsoft en relación a nuevas características es que se utilizarán si explícitamente se pide que así sea.

Para establecer una de estas tres opciones hay que utilizar la opción Containment y establecer los valores NONE, PARTIAL o FULL dependiendo del tipo de base de datos que queramos.

Así mismo, y debido a la aparición de este nuevo tipo de bases de datos, los objetos o entidades de base de datos pasan a clasificarse en dos categorías, entidades contenidas o entidades no contenidas. Dependiendo si dichas entidades sobrepasan las barreras definidas por la base de datos o no. La especificación de dichas barreras viene definidas por dos modelos que son Application model y Management Model. Dichos modelos especifican que objetos o entidades no referencian a la instancia en el caso de Application model y cuales si en el caso de Management model.

  • Las entidades contenidas son aquellas que no poseen referencias externas a la propia base de datos o al menos no referencias a la instancia de SQL Server. Un ejemplo de entidad contenida es por ejemplo la vista de tablas sys.tables que hace referencia a las tablas de la base de datos en la que se ejecuta. Para más información acerca de las entidades contenidas visita el siguiente enlace: Caracteristicas dentro del Application Model
  • Las entidades no contenidas son aquellas que tienen referencias externas como por ejemplo objetos que contengan nombres de tres o cuatro partes formados por [Nombre_servidor].[Base_de_datos].[Esquema].[Nombre_de_tabla] o [Base_de_datos].[Esquema].[Nombre_de_tabla]. También queda incluido aquellas entidades que no se pueden determinar como por ejemplo el código Transact SQL dinámico. Como hasta que no se ejecute no sabemos hace referencias externas o no lo clasificamos como no contenido. Para más información visita el enlace: Características que se salen del Application Model

Ejemplos prácticos

A continuación vamos a ver de una manera más práctica como trabajamos en SQL Server 2012 nombre en clave “Denali” con este tipo de base de datos. Para todos los ejemplos que se ven a continuación estaremos trabajando con un Windows server 2008R2 y una instancia de SQL Server 2012 nombre en clave “Denali”. Para estos ejemplos hemos utilizado la CTP3 que se puede descargar desde el siguiente enlace: Descargar Denali CTP3

Creación

Lo primero que vamos a ver es como crear una base de datos autocontenida. Para ello, antes d empezar tenemos que activar esta nueva característica a nivel de instancia. Para ello se ha incluido una nueva configuración avanzada en SQL Server 2012 nombre en clave “Denali” llamada contained database authentication. Si no configuramos esto al intentar crear la base de datos autocontenida obtendremos el siguiente error:

Msg 12824, Level 16, State 1, Line 1

The sp_configure value ‘contained database authentication’ must be set to 1 in order to create a contained database. You may need to use RECONFIGURE to set the value_in_use.

De modo que vamos a crearnos nuestra base de datos autocontenida, para ello empleamos el siguiente código T-SQL:

--modifico la configuración de la instancia
EXEC sp_configure 'show advanced options', 1
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sp_configure 'contained database authentication', 1
EXEC sp_configure 'show advanced options', 0
GO
RECONFIGURE WITH OVERRIDE
GO

--creo al base de datos autocontenida
CREATE DATABASE [BDAutocontenida1]
 CONTAINMENT = PARTIAL
GO

Si la creamos con el interfaz gráfico de Management Studio veremos que aparece una nueva opción donde se puede especificar el tipo de base de datos:

En caso que queramos modificar una base de datos ya existente y queramos que pase a ser autocontenida podemos utilizar el comando ALTER DATABASE para modificarla como se muestra a continuación:

--modifico la base de datos	
ALTER DATABASE BDAutocontenida1
SET CONTAINMENT=PARTIAL
GO

 

Usuarios y conexiones

Con la aparición de este nuevo tipo de bases de datos, que lo que pretenden es aislarnos de la instancia, aparece un nuevo tipo de usuario a nivel de base de datos. A partir de ahora ya no será necesario tener un inicio de sesión a nivel de instancia sino que podemos crearnos un usuario que acceda única y exclusivamente a la base de datos autocontenidas. Hasta ahora uno de los problemas más frecuentes que se afrontaban en una migración era el movimiento de los inicios de sesión de un servidor a otro y la vinculación mediante el SID. Con este nuevo tipo de base de datos veremos como este problema se minimiza.

Vamos a crear un usuario en la base de datos sin inicio de sesión asociado. A continuación se muestra el código necesario:

 

--nos ponemos en contexto de la autocontenida
use BDAutocontenida1
go

--creo usuario con password en la base de datos
create user kike with password='P4$$w0rd'
go

Si vemos los usuarios de la base de datos ya nos aparece nuestro usuario recién creado:

 

Ahora vamos a intentar conectar:

Al intentar conectar obtenemos el siguiente error:

Esto sucede porque no hemos creado un inicio de sesión que se llame Kike, y si no especificamos que queremos conectar sobre la base de datos autocontenida no podremos acceder. Por defecto la conexión se realiza sobre master. Para cambiar esto nos vamos a Options en el formulario de conexión y especificamos la Base de datos:

Ahora si intentamos conectar lo haremos satisfactoriamente, porque al tratarse de una base de datos autocontenida, además de comprobar si es un inicio de sesión correcto comprueba también si es un usuario de la base de datos con permisos. En este caso lo es porque así lo hemos creado y los permisos que tiene son los que tiene el rol public, ya que no le hemos otorgado más permisos.

Cuando conectamos con este usuario también se pueden apreciar las diferencias entre las conexiones:

 

 

Como se puede observar en la imagen, al conectar con este tipo de usuarios conectamos únicamente a la base de datos. No hay opción de acceso a nada relativo a la instancia, simplemente la base de datos autocontenida con todas sus propiedades.

Recomendaciones

Hay que ser cauto a la hora de utilizar este nuevo tipo de base de datos. Cuando utilizarlas y cuando no dependerá del escenario de cada uno. Si necesitamos una aplicación portable que sabemos a priori que vamos a tener que cambiar de servidor es interesante utilizar las bases de datos parcialmente contenidas. Por ejemplo para un servicio de hosting donde queremos encapsular bases de datos con usuarios únicos en cada una también podría ser un escenario factible, o si tenemos un escenario donde necesitamos 2 administradores de 2 bases de datos donde queremos queremos que se llamen admin, esto ahora con los inicios de sesión no es posible. Para todo este tipo de escenarios puede ser factible el uso de base de datos autocontenidas. Pero hay que tener en cuenta las restricciones que existen, si queremos entornos que utilicen replicación, change data capture o change tracking no podremos usar esta característica, al menos por ahora. Mi opinión personal es que en un futuro todas las bases de datos serán parcialmente autocontenidas por definición porque es la opción que, salvando las restricciones existentes por ahora, nos ofrece lo mejor de los dos mundos.

Conclusión

Como hemos visto a lo largo de este artículo, esta nueva característica en SQL Server 2012 nombre en clave “Denali” representa un cambio importante tanto a nivel de motor de base de datos como a nivel de seguridad. Con este nuevo tipo de bases de datos resultará más sencillo migraciones al eliminar la dependencia de entidades externas a la base de datos y por otro lado, se proporciona una mayor encapsulación de las aplicaciones de nuestra organización. Faltaría comentar y ver el comportamiento de este tipo de bases de datos con TempDB, el agente de SQL Server e incluso de como monitorizar y tener controladas aquellas entidades que pasen esa frontera que hemos comentado a lo largo de este post. Pero eso será en futuras publicaciones, así que permaneced atentos al blog !