次の方法で共有


BASES DE DATOS REMOVIBLES EN SQL SERVER

Todos los que trabajan con SQL Server han necesitado en algún momento, y en mayor o menor medida, trasladar datos de un servidor a otro. Todos han tenido entonces que lidiar con cintas, DVD u otro tipo de media, cuando no es posible copiar los archivos por una conexión de red. Estos luego son colocados en el Servidor SQL mediante una operación de restauración (RESTORE) o de acoplamiento de la BD (sp_attach_db).

Hay situaciones particulares en las cuales se desea que una base de datos no sea modificada mientras se hace el proceso de mudanza. Si bien es posible quitar los permisos de escritura en las tablas la base de datos no está protegida totalmente, ya que alguien con permisos de sysadmin podrá alterar los datos. Sin embargo existe una forma de distribuir los datos de manera protegida mediante la creación de bases de datos removibles. Estas bases son generalmente solo lectura y normalmente son datos históricos que no sufrirán operaciones de actualización. Esta opción está disponible desde SQL Server 7.0 hasta SQL Server 2008.

Cuando se genera una base de datos removible SQL Server se crearan tres tipos de archivos:

  • Un archivo conteniendo las tablas del sistema
  • Uno o más archivos conteniendo los datos
  • Un archivo de log

El archivo de log y el archivo de las tablas del sistema se deben colocar en una unidad en la que se pueda escribir.

Es necesario aclarar que los archivos de data de una base de datos puede ocupar más de una media removible (CD, DVD) en forma simultánea, todas ellas deberán estar disponibles a la vez cuando esa base esté operativa. Es decir, si los archivos de data de una base de datos necesita 2 DVDs, se necesitara tener 2 unidades de DVDs y ambos DVDs insertados al momento de usarla.

Crear una BD removible:

La creación de una base de datos de este tipo es diferente al proceso standard. No se deberá utilizar la sintaxis de CREATE DATABASE sino un stored procedure llamado sp_create_removable. solo los miembros de sysadmin podrán ejecutar esto. Este stored procedure tiene unos parámetros que se detallan a continuación:

sp_create_removable [ @dbname = ] ' dbname '
,
[ @syslogical = ] ' syslogical '
,
[ @sysphysical = ] ' sysphysical '
,
[ @syssize = ] syssize
, [ @loglogical = ] ' loglogical '
,
[ @logphysical = ] ' logphysical '
,
[ @logsize = ] logsize
, [ @datalogical1 = ] ' datalogical1 '
,
[ @dataphysical1 = ] ' dataphysical1 '
,
[ @datasize1 = ] datasize1
, [ @datalogical16 = ] ' datalogical16 '
,
[ @dataphysical16 = ] ' dataphysical16 '
,
[ @datasize16 = ] datasize16 ]

Los parámetros @....16 se utilizan cuando la base de datos ocupa más de una media (hasta un máximo de 16).

Un ejemplo de esta instrucción:

sp_create_removable 'BD_Removible',

'Rem_Sys', 'X:\DATA\remsys.mdf', 2,

'Rem_Log',' X:\DATA \remlog.ldf', 2,

'Rem_Data', ' X:\DATA \remdata.ndf', 50

Con el comando anterior creamos una base de datos llamada BD_Removible (es el nombre que se verá en el Management Studio) y sus archivos componentes que son: tablas de sistema (2 MB), archivo de log (2 MB) y archivo de datos (50 MB).

Una vez hecho esto, se procede a manipularla como una base de datos común y corriente. Se crean sus tablas, sus referencias, sus usuarios, se cargan los datos, etc. Es decir, se la deja lista para usarla.

Cuando la base de datos está lista para ser copiada a una media para su distribución, se deberá usar el stored procedure sp_certify_removable. El trabajo que realiza consiste en actualizar las estadísticas de las tablas, chequear posibles problemas, marcar los data file-groups como de solo-lectura (de forma tal que se puedan copiar a un soporte de solo-lectura) y setear la base como ‘off-line’.

 La sintaxis completa es:

sp_certify_removable [ @dbname = ] ' dbname ' [ , [ @autofix = ] ' auto ' ]

El System Administrator (SA) deberá ser el owner de la base de datos y de todos los objetos que hubiere en ella. Esto es así dado que el SA existirá en todas las instalaciones de SQL Server y, es con este usuario, que se hará la posterior administración y manipulación de derechos. Por ello, es conveniente ejecutar este stored procedure para que el segundo parámetro (@AutoFix = ‘AUTO’) se encargue de todo esto. Si no se especifica esto, hará el proceso igual, pero si encuentra algún inconveniente lo reportará y detendrá el proceso.

Ejemplo:

sp_certify_removable BD_Removible, AUTO

De no estar ningún usuario conectado y no generarse problemas, la base de datos quedará en estado ‘off-line’ para ser copiada.

Distribuir la Base de Datos removible

El proceso ahora es sencillo: se deberán copiar los archivos componentes de la base de datos a la media que usaras para distribuirla. Cuando se necesite poner en producción la base de datos removible se deberá acoplar la misma al servidor (sp_attach_db o utilizar el Management Studio). Se deberán insertar todas las medias usadas por la base de datos. Esto se hace por única vez. De aquí en adelante se la pone ‘on-line’ u ‘off-line’ para poder usarla o no.

Es conveniente aclarar que el archivo de log y el de tablas del sistema se deberán copiar a una unidad de lectura y escritura y quitarle a los archivos el atributo de read-only.

El stored procedures sp_certify_removabley sp_atach_db está marcados en SQL Server 2008 como deprecados y serán descontinuados en futuras, pero esta capacidad está disponible desde SQL Server 7.0 hasta SQL Server 2008 y puede ser útil en diferentes situaciones.

 

“Las opiniones e ideas expresadas en este blog son las de los Autores y no necesariamente declaran o reflejan la opinión de Microsoft”