1. Aspectos Generales de la Administración del Sistema

La administración de Bases de Datos incluye tareas como:

Instalación de motores de SQL Server y Backup Server Asignación de roles y permisos a usuarios de SQL Server Gestión y monitoreo de espacio en disco, memoria y conexiones Copias de seguridad y restauración de bases de datos Diagnóstico y solución de problemas Afinación del sistema para optimizar el desempeño

Adicionalmente un administrador de sistema puede tener tareas como estimación de espacio en disco con el objetivo de que los dispositivos de los usuarios no tengan problemas. Para estas tareas será necesario comprender conceptos de umbrales (thresholds) y alarmas.

Los conceptos adicionales de copias de seguridad y restauración de las mismas incluyen donde y cada cuanto tiempo realizarlas. Al mismo tiempo instalación de los motores de SQL Server y de Backup server para hacer copias de seguridad en servidores remotos.

Para poder administrar un sistema de base de datos es necesario conocer su arquitectura, es decir, tanto los elementos que componen el sistema, como su funcionalidad e interacción. Una vez establecidos estos puntos será posible establecer los procedimientos y políticas de administración de un sistema de bases de datos.

1.1 Las tablas del sistema

El componente esencial de un sistema de bases de datos son las tablas y sus relaciones, por esto, la gestión del sistema se basa en el manejo de tablas exclusivas del sistema en SQL Server. Estas tablas se distinguen por su nombre (sysxxxxxxx). No es aconsejable modificarlas por ISQL, ya que algunas no son tan fácilmente modificables. Es mejor utilizar los procedimientos del sistema creados para tal fin (siempre y cuando se cuente con los permisos necesarios). Existen algunas tablas son creadas por procesos del sistema de manera dinámica y contienen información codificada, esta información no es visible cuando la misma es consultada y puede originar errores de acceso, dejar objetos inaccesibles, eliminar permisos ó terminar su sesión de usuario.

1.2 Procedimientos del sistema

Existen algunos procedimientos almacenados que proveen información sobre las tablas del sistema, y estos son:

sp_commonkeysp_configuresp_dboptionsp_estspacesp_helpsp_helpconstraint

sp_helpdbsp_helpdevicesp_helpgroupsp_helpindexsp_helpjoinssp_helpkey

sp_helplanguagesp_helplogsp_helpremoteloginsp_helprotectsp_helpsegmentsp_helpserversp_helpsort

sp_helptextsp_helpthresholdsp_helpusersp_locksp_monitorsp_spaceusedsp_who

1.3 Bases de datos del sistema

En un modelo de bases de datos, las componentes de funcionamiento a nivel de bases de datos son bases de datos. Existen cuatro bases de datos que se instalan siempre con el motor y dos más que son opcionales. Estas bases de datos son:

La base de datos Master: Es la base de datos principal, desde la que se manejan las otras, dado que contiene las tablas de organización .

La base de datos Model: que es el patrón empleado en la creación de bases de datos. La base de datos de procedimientos sybsystemprocs: con los procedimientos

almacenados del sistema. La base de datos temporal tempdb: utilizada como espacio de trabajo en las

transacciones antes de hacerlo sobre los datos reales.

Otras dos bases de datos que son opcionales son:

La base de datos sybsecurity: para ejecutar los procesos de auditoría de la base de datos.

La base pubs2: base de datos de ejemplo.

La base de datos Master, contiene información acerca de: Cuentas de Usuarios (en syslogins) Cuentas de usuarios remotos (en sysremotelogins) Servidores remotos con los que puede interactuar el servidor local (en sysservers) Procesos en ejecución (en sysprocesses) Variables de ambiente configurables en el sistema (en sysconfigures) Mensajes de error del sistema (en sysmessages) Las bases de datos existentes en SQL Server (en sysdatabases) El espacio de almacenamiento asignado para cada base de datos (en sysusages) Los dispositivos (cintas y discos) montados en el sistema (en sysdevices) Locks (candados) activos (en syslocks) Conjuntos de caracter (en syscharsets) e idiomas (en syslanguages) Usuarios con roles a nive de servidor (en sysloginroles) Roles de Servidor (en syssrvroles) Motores de SQL Server en línea (en sysengines)

2

Cuando se instala SQL Server, las bases de datos del sistema, los segmentos definidos por el sistema y los dispositivos de base de datos se organizan como sigue:

Las bases de datos master , model y tempdb se instalan en el dispositivo master d_master .

La base de datos sybsystemprocs se instala en el dispositivo que usted elija durante la instalación.

Se crean tres segmentos en cada base de datos: system , default y logsegment. El dispositivo de almacenamiento predeterminado para todas las bases de datos creadas

por usuarios es d_master .

Nota: Tras inicializar nuevos dispositivos para el almacenamiento predeterminado, retire el dispositivo master del área de almacenamiento predeterminado con s p_diskdefault . No almacene bases de datos ni objetos de usuario en d_master .

Si ha instalado la base de datos de auditoría, sybsecurity , la encontrará ubicada en su propio dispositivo.

3

2. Roles en SQL Server

En SQL Server un rol se asemeja a un comportamiento,

2.1 Roles de Administración de Sistema y de Seguridad

En SQL Server los usuarios pueden recibir permisos especiales para operar y administrar el sistema. Los roles son asignados a nivel de login y proveen a los usuarios de capacidades para desempeñar tareas de administración. Para asignar y/o revocar roles se utiliza el procedimiento sp_role.

Los roles existentes son: SA: Administrador del Sistema. SSO: Oficial de Seguridad del Sistema. Oper: Rol de Operador del Sistema.

Adicionalmente hay dos tipos de propietarios en el sistema:

El propietario de la base de datos de usuario. El propietario de los objetos de base de datos.

El SA posee desempeña tareas específicas a nivel de aplicación (lo pueden tener ser varios logins). Dentro de las tareas más representativas del SA estan: Instalación de SQL Server. Administración de almacenamiento Asignación de permisos a usuarios de SQL Server Creación de bases de datos de usuario Asignación y revocatoria del rol de SA (a otros usuarios, el mismo no puede hacerlo) Conformación de grupos para facilitar tareas de asignación de permisos y roles. Afinación de la configuración del sistema Diagnóstico de problemas Manejo de cuentas a nivel de login.

El SSO (System Security Officer) cumple con tareas como: Creación de cuentas a nivel de servidor Asignación y revocatoria de roles de SSO y Operador a los usuarios del sistema. Cambios de password para cualquier cuenta Administración de la auditoría del sistema Configurar la expiración de passwords de los logins

El Oper tiene permisos para ejecutar tareas de tipo rutinario como: Comandos de volcado Carga de bases de datos Backups

2.2 Propietarios en SQL Server

Las dos clases de propietario definidas en SQL Server son los propietarios de bases de datos de usuario y los propietarios de objetos de base de datos.

Propietarios de Base de Datos

El propietario de una base de datos ingresa a SQL Server con el login de la cuenta que le sea asignado y es reconocido por SQL Server como “dbo” en su Base de datos. El puede: Por medio del procecimiento sp_adduser adicionar usuarios a su base de datos. Dar permisos o revocarlos para crear objetos y ejecutar comandos en su base de datos.

El propietario de la base de datos tiene propiedad sobre todos los objetos de su base de datos.

Propietarios de objetos de la base de datos

Los objetos de la base de datos son tablas, índices, vistas, valores por defecto, triggers, procedimientos almacenados, reglas y restricciones. El usuario que los crea es el propietario. Y el puede dar permisos a otros usuarios de la base de datos sobre objetos, sus utilización y sus ejecuciones ó consultas.

2.3 Administración de roles en SQL Server

Después de hacer la instalación del SQL Server el usuario SA puede hacer creación de logins de servidor para que otros usuarios puedan tener sus mismas funciones. Cabe hacer la anotación que independientemente del login con el que se ingrese si tiene el rol SA, las transacciones que realice quedan cargadas como SA.

El procedimiento sp_role pemite asignar y/o revocar roles de usuarios, su sintaxis es:

sp_role {"grant" | "revoke"},{sa_role | sso_role | oper_role}, login_name

con el procedimiento sp_displaylogin es posible obtener información de una cuenta.

sp_displaylogin [ login_name]

5

3. Gestión de los recursos físicos

Para gestionar los recursos físicos es necesario conocer los elementos que permiten gestionar el espacio, y los elementos que sirven de apoyo para estimar la cantidad de espacio requerida. Los recursos físicos básicos para SQL Server son los dispositivos ya que son la entidad principal de almacenamiento relacionada con la parte física. Existen tres tipos de dispositivos básicos:

Dispositivos para base de datos. Dispositivos espejo. Dispositivos para backups (cintas o discos).

3.1 Comandos de gestión de recursos

Hay algunos comandos que permiten manejar los dispositivos desde su inicialización hasta su uso.

3.1.1 Inicialización de dispositivos de base de datos

Por dispositivo entendemos el contenedor de las tablas y los objetos del sistema de base de datos. Este contenedor puede ser un archivo ó una partición del disco (partición RAW), dependiendo del sistema operativo sobre el que se esté trabajando. Este contenedor debe ser inicializado para que el sistema de base de datos lo reconozca como dispositivo válido, es decir debe ser “formateado” de tal manera que sea accequible para SQL Server.

Los dispositivos pueden cumplir diversas funciones: Almacenar objetos del sistema. Asignarse como espacio disponible por defecto para la creación de bases de datos. Asignarse para almacenar el diario de transacciones de una base de datos.

Para determinar los parámetros de creación del dispositivo es necesario establecer qué uso se le va a dar. Si el dispositivo va a ser asignado para la creación de una base de datos de usuario primero hay que establecer qué espacio requiere, tanto la base de datos como el log de transacciones ó si se han de colocar por separado. Las políticas de diseño de bases de datos permiten establecer el tamañoque deberá tener la base de datos y por tanto el dispositivo a crear.

Para inicializar un dispositivo se utiliza el comando disk init, cuya sintaxis es:

disk init name = " device_name " , physname = " physicalname " , vdevno = virtual_device_number , size = number_of_blocks [, vstart = virtual_address , cntrltype = controller_number ] [, contiguous] ( Sólo para OpenVMS)

donde los parámetros son:

name: nombre lógico del dispositivo y es el nombre con el que SQL Server lo identificará una vez creado.Physname: nombre físico del dispositivo, es decir, nombre del archivo o de la partición.Vdevno: número virtual de dispositivo, que es un número que identifica unívocamente a un dispositivo inicializado y en uso. Al eliminar este dispositivo éste número es liberado, pero sólo esta disponible después de reinicializar el servidor.Size: es el tamaño del dispositivo en bloques de 2K. Mínimo 512 bloques (1MB), máximo 1.048.576 bloques (2GB). Vstart: hace referencia a una dirección virtual de arranque dentro del dispositivo una vez inicializado.Cntrltype: es requerido cuando hay necesidad de especificar un controlador (número de controlador).

Para obtener información acerca de los dispositivos se utiliza el procedimiento almacenado sp_helpdevice. Que muestra información de la tabla master..sysdevices.Para eliminar un dispositivo se utiliza el procedimiento almacenado sp_dropdevice, con el que se libera de manera lógica el dispositivo, allí se hace necesario liberar el dispositivo físico por sistema operativo, esto es, borrarlo o deshacer la partición.

Cuando el dispositivo es creado es posible adicionarlo al conjunto de dispositivos por defecto (predeterminados) en el que se crean las bases de datos de usuario y objetos que no cuentan con dispositivos específicos. Para adicionar al (o eliminar del) grupo de predeterminados se utiliza el procedimiento sp_diskdefault.

Los dispositivos predeterminados son utilizados por el sistema para almacenar todas las bases de datos y/u objetos. Por esto mismo asegurese que no sean dispositivos por defecto aquellos donde almacene la base de datos master, sybsecurity o bases de datos que requieren un rendimiento óptimo.

3.1.2 Dispositivos espejo

El dispositivo espejo es un dispositivo que permite tener una copia en ejecución de una base de datos o de su log de transacciones. Esto implica que la información es en todo momento duplicada, pero al mismo tiempo que es posible hacer una recuperación de una base de datos sin interrumpir la operación del sistema. Para inicializar un dispositivo como disco espejo se utiliza el comando disk mirror. Cuando sucede un error de disco SQL Server interrumpe la duplicación y sólo es posible reiniciarla con el comando disk remirror. Para eliminar el disco espejo se utiliza el comando disk unmirror.

Nota: un dispositivo espejo no se inicializa con el comando disk init.

7

Los dispositivos espejo también son almacenados en la tabla sysdevices y los comandos mencionados la modifican. A continuación la sintaxis de los comandos.

Comando disk mirror

disk mirror name = "device_name " , mirror = "physicalname " [ , writes = { serial | noserial }] [ , contiguous ] (Sólo para OpenVMS)

Comando disk remirror

disk remirrorname = " device_name"

Comando disk unmirror

disk unmirror name = " device_name " [, side = { "primary" | secondary }] [, mode = { retain | remove }]

3.1.3 Dispositivos de volcado

Los dispositivos de volcado son las cintas y/o discos en los que se hacen copias de seguridad. También son encuentran identificados en la tabla sysdevices.

3.2 Consideraciones sobre la administración del almacenamiento

Para asignar espacio en disco para una base de datos primero es necesario estimar el tamaño requerido por la base de datos, sus objetos, su log de transacciones, etc. Luego con los comandos vistos de disk init se inicializa el dispositivo teniendo en cuenta los parámetros estimados. Y por último es fundamental asignar los objetos que han de residir en dicho dispositivo.

La asignación de bases de datos a dispositivos se hace en el momento de su creación. Por medio del comando create database es posible indicarle en qué dispositivo se va a ubicar, si este dato no es suministrado, es creada en las bases de datos por defecto.

Asimismo cuando es necesario utilizar más de un dispositivo para almacenar una base de datos ó alguna de sus componentes es posible crear un segmento. Un segmento es una agrupación de dispositivos ó parte de un dispositivo que se comporta como una unidad lógica para soportar el manejo disperso de espacio físico real.

8

El administrador del sistema de una instalación de SQL Server debe tomar decisiones respecto a la asignación física de espacio a las bases de datos de SQL Server. Los principales aspectos a considerar son:

Recuperación : La duplicación de discos y/o el mantenimiento de diarios en un dispositivo físico distinto suponen dos mecanismos para la recuperación total en caso de fallos físicos de los discos.

Rendimiento : Para ciertas tablas o bases de datos en que la velocidad de las lecturas y escrituras en disco es crucial, la ubicación correcta de los objetos de base de datos en dispositivos físicos produce mejoras en el rendimiento. La duplicación de discos reduce la velocidad de las escrituras en disco.

3.2.1 Recuperación La recuperación es el motivo fundamental para utilizar varios dispositivos de disco. La recuperación ininterrumpida puede lograrse duplicando los dispositivos de base de datos. La completa recuperación también puede garantizarse almacenando el diario de una base de datos en un dispositivo físico aparte.

La recuperación ininterrumpida en caso de fallo del disco duro está garantizada por el mecanismo de duplicación de los dispositivos de SQL Server en otro disco físico. La duplicación de los dispositivos de base de datos con los datos e índices (no sólo del dispositivo con el diario de transacciones) es necesaria para que la recuperación pueda realizarse sin necesidad de detener SQL Server.

3.2.2 Rendimiento

El rendimiento del sistema puede mejorarse situando los diarios y objetos de base de datos en dispositivos distintos:

Situar una tabla en un disco duro y los índices no agrupados en otro, garantiza que las lecturas y escrituras físicas sean más rápidas, ya que el trabajo se reparte entre dos unidades de disco.

Dividir las tablas de gran tamaño en dos discos puede mejorar el rendimiento, en especial con aplicaciones multiusuario.

3.3 Segmentos

Los segmentos son llamados subconjuntos de los dispositivos de base de datos disponibles para una base de datos SQL Server, en particular. Un segmento puede ser definido como una etiqueta que apunta a uno o más dispositivos de base de datos. Los nombres de segmento pueden ser utilizados en los comandos create table y create index para colocar

9

tablas o índices en dispositivos de bases de datos específicos. El uso de segmentos puede incrementar el desempeño de SQL Server.

Los segmentos son creados dentro del dispositivo asignado a una base de datos. Cada base de datos SQL Server puede tener hasta 32 segmentos, y deben haber sido inicializados y estar disponibles para la base de datos antes de que se les asignen nombres.

Cuando se crea una base de datos se crean tres segmentos: system: que almacena las tablas de sistema. logsegment: que almacena el log de transacciones. default: almacena todos los otros objetos de la base de datos.

A menos que se hayan creado segmentos adicionales utilizando create table ... on segment_name o create index ... on segment_name.

Tres tablas del sistema almacenan la información de los segmentos: la tabla master..sysusages y dos tablas de sistema en la base de datos de usuario sysindexes y syssegments.

3.3.1 Procedimientos con segmentos

Creación de segmentos con el procedimiento sp_addsegment. Sintaxis:

sp_addsegment segname, dbname, devname

Luego, los objetos pueden ser ubicados en este segmento haciendo referencia al mismo con la clausula on.

create table table_name (col_name datatype...) [on segment_name]

create [clustered|nonclustered] index index_name on table (col_name) [on segment_name]

Extensión (adición de dispositivos a un segmento) de los segmentos con el procedimiento sp_extendsegment. Sintaxis:

sp_extendsegment segname, dbname, devname

Soltado (drop) de segmentos con el procedimiento sp_dropsegment. Sintaxis:

sp_dropsegment segname, dbname

10

además es posible usarlo para remover dispositivos de base de datos de un segmento.

sp_dropsegment segname, dbname, devname

Para obtener información de los segmentos esta el procedimiento almacenado sp_helpsegment.

3.4 Creando Bases de Datos de Usuario

Se utiliza el comando create database. Las bases de datos son creadas mientras se usa la base de datos master. Por tanto se debe ser un usuario valido y debe tener permisos de creación.

El comando create database limpia todas las páginas del dispositivo de la base de datos. Si esta creando una base de datos desde una carga de datos puede utilizar una opción que se salta la limpieza y es ejecutada después de que se completa la carga. create database syntaxis:

create database database_name [on {default | database_device } [= size ] [, database_device [= size ]...] [log on database_device [ = size ] [, database_device [= size ]]...] [with override] [for load]

Solo se puede crear una base de datos al tiempo y es creada en los dispositivos por defecto disponibles en su servidor. Todos los dispositivos que se utilicen en la creación de la base de datos deben haber sido inicializados con disk init. Por ejemplo:

3.4.1 Como son creadas las bases de datos de usuarios

Cuando una sentencia create database es utilizada, SQL Server realiza los siguientes pasos:

Verifica la unicidad del nombre de base de datos. Se asegura que el dispositivo de base de datos especificado esta disponible. Halla un número de identificación único. Asigna espacio para la base de datos en los dispositivos especificados y actualiza esta

información en master..sysusages para registrar estas asignaciones. Inserta una fila en sysdatabases. Hace una copia de la base de datos model en el nuevo espacio de base de datos, creando

las nuevas tablas de sistema en la nueva base de datos. Limpia las páginas restantes (a menos que se cree por una carga de datos).

11

La nueva base de datos hereda todas las características que tenga la base de datos model.

3.4.2 Permisos para Crear Bases de Datos

Normalmente el Administrador del sistema tiene el “monopolio” de creación de las bases de datos con el fin de centralizar el control de las ubicaciones y la asignación de dispositivos de base de datos. En tal caso se crea la base de dtos y luego se transfiere la propiedad al usuario apropiado.

Para hacer ésto son tres pasos:

Crear la base de datos. Conmutar a la base de datos con el comando use. Ejecutar el procedimiento de sistema sp_changedbowner.

El Administrador del Sistema puede, además, dar permisos para crear bases de datos. En este caso él opera los servicios de protección del sistema por fuera como una precaución.

3.4.3 Asignando Bases de Datos a Dispositivos de Bases de Datos

En la sentencias create database o alter database se especifica en cual se ha de crear en uno o si se van a utilizar varios dispositivos,o si se coloca default o se omite se crea en el dispositivo por defecto. También se indica en que dispositivo se creará el log de transacciones (si no se hace se utiliza el “default”).

Tamaño de la base de datos (size): Si el parámetro es omitido se crea con la cantidad por defecto en la variable de configuración (sp_configure) o la base de datos model (alter database).

3.4.4 Colocando el Log de Transacciones en un dispositivo separado: log on

El log de transacciones (la tabla syslogs) es ubicado en el dispositivo que se especifíque en la clausula log on . Por defecto se utilizan 2 megabytes de almacenamiento. Se puede colocar separado porque:

Permite hacer descarga del log de transacciones de manera aislada. Permite establecer un tamaño fijo eliminandolo de la competencia de recurso físico de

almacenamiento. Crea umbrales de espacio libre por defecto para el log y para la base de datos por aparte. Incrementa su desempeño. Asegura recuperación total en el evento de daño físico de disco.

El tamaño del log de transacciones es “a ojo” del 10% al 25% del tamaño requerido por la base de datos.

12

3.4.5 La opción de for load para recuperación de bases de datos

Es una opción que se emplea cuando se va a utilizar la base de datos desde una descarga, sea por un daño físico o se va a cambiar de una máquina a otra. for load utiliza una versión modificada de create database para crear una base de datos que puede ser usada solo para cargar.

El procedimiento sp_logdevice permite cambiar el dispositivo mueve las futuras asignaciones para el log de transacciones para otro dispostivo (cuando el actual se complete). Su sintaxis:

sp_logdevice database_name , device_name

Ese dispositivo de base de datos debe haber sido inicializado con disk init y asignado a la base de datos con create o alter database .

3.4.6 Cambiando la Propiedad de una Base de Datos

Para esto se utiliza el procedimiento sp_changedbowner. La sintaxis es:

sp_changedbowner loginame [, true ]

El nuevo usuario debe tener login name en SQL Server, pero no puede ser un usuario o tener un alias en la base de datos. Para garantizar esto se pueden usar los procedimientos sp_dropuser o sp_dropalias antes de hacer el cambio. El parámetro true transfiere alias y permisos.

3.4.7 Incrementando el tamaño de una base de datos

Es posible incrementar el tamaño de la base de datos con el comando alter database adicionando espacio, tanto para los objetos de la base de datos como para el log de transacciones o ambos a la vez. Los permisos para usar el comando alter database son, por defecto, los del propietario de la base de datos y no pueden ser cambiados con grant o revoke.

alter database database_name [on {default | database_device } [= size ] [, database_device [= size ]]...] [log on {default | database_device } [= size ] [, database_device [= size ]]...] [with override] [for load]

13

El mínimo incremento que se puede especificar es 1 megabyte (512 2K páginas).

3.5 El comando drop database

Este comando remueve una base de datos del servidor borrando la base de datos y todos sus objetos, liberando el espacio asignado a la base de datos y borrando las referencias a ésta en las tablas de la base de datos master. Sintaxis:

Drop database database_name [, database_name]...

14

4. Logins y Usuarios de Bases de Datos

En este capítulo se describe el manejo de las cuentas de login y los usuarios de base de datos.

4.1 Adicionando nuevos usuarios

Para adicionar usuarios a un sistema de base de datos se debe hacer lo siguiente: Un SSO debe crear las cuentas de login a nivel de servidor (sp_addlogin). Un SA o propietario de la base de datos adiciona al usuario (user) a la base de datos

(sp_adduser) o lo adiciona a un grupo (sp_addgroup). Un SA o propietario de la base de datos asigna los permisos necesarios.

Sintaxis del procedimiento sp_addlogin

sp_addlogin login_name, password [, defdb][, deflanguage [, fullname]]]

donde el login_name es el nombre con el que se iniciará una sesión en SQL Server, el password es la clave, y defdb es la base de datos por defecto. Si este último es omitido la base de datos por defecto ese master y se puede modificar con el procedimiento almacenado sp_modifylogin. La tabla que modifican estos procedimientos es la master.dbo.syslogins. Esto sólo lo puede hacer un SSO.

Con el comando sp_addgroup es posible crear un grupo de usuarios ó para adicionar usuarios conservando las características que se le establezcan al grupo mismo.

Para eliminar cuentas, usuarios y grupos existen tres procedimientos sp_droplogin, sp_dropuser, sp_dropgroup. Sintaxis:

sp_droplogin login_name

sp_dropuser name_in_db

sp_dropgroup groupname

Con el comando sp_locklogin se puede prevenir que un usuario ingrese, es decir es posible bloquear temporalmente una cuenta.

sp_locklogin [ login_name, "{lock | unlock}"]

Otra forma de asignar a varios usuarios un mismo comportamiento es por medio de la utilización de alias. Un alias es un identidad de usuario colectiva que asigna los permisos y propiedades del login de usuario inicial. Se asignan alias por medio del procedimiento sp_addalias y para liberar el alias se utiliza el procedimiento sp_dropalias.

Con el procedimiento sp_who es posible conocer la información de los usuarios actuales y los procesos en ejecución.

Con el procedimiento sp_displaylogin obtenemos información acerca de cuentas de usuario.

Con el procedimiento sp_helpuser información de usuarios y alias en la base de datos.

Con el procedimiento sp_helpgroup información de grupos en la base de datos.

16

5. Administrando Permisos de Usuario

Los comandos grant y revoke se utilizan para asignar permisos de uso, consulta o ejecución sobre los objetos de la base de datos y constituyen un mecanismo de seguridad.

Los administradores del sistema tienen permisos y propiedad sobre todos los objetos del sistema. El propietario de una base de datos no recibe automáticamente los permisos sobre los objetos en su base de datos, pero puede tener acceso a ellos por medio del comando setuser. Una vez obtenidos los permisos necesarios sobree los objetos de la base de datos puede utilizar grant para asignarse permisos.

Los tipos de usuarios y sus privilegios en SQL Server son: Administrador del sistema. Oficial de seguridad del sistema. Operador. Propietario de Base de Datos. Propietario de objeto de base de datos. Otros usuarios (“public”).

Un Administrador del sistema tiene permisos para: Creación de bases de datos. Asignación de permisos para creación de bases de datos.

Aunque lo más conveniente es que un único administrador del sistema tenga el monopolio de la creación de bases de datos y de utilización y creación de dispositivos con el fín de detentar el control en las tareas de asignación y desempeño

El SSO tiene los privilegios para crear cuentas a nivel de servidor, asignar y cambiar passwords y asignar roles. Todas estas tareas únicamente a nivel de seguridad en el sistema. Este tipo de usuario no tiene privilegios especiales sobre los objetos de la base de datos.

Los usuarios Oper tienen privilegios para ejecución de tareas rutinarias como volcado de dispositivos o carga de los mismos.

Los privilegios de los propietarios de una base de datos son: Asignación de permisos a otros usuarios dentro de su base de datos (grant), verificaciones de consistencia en la base de datos (dbcc), emular usuarios (set user), volcado y carga de bases de datos y/o sus logs de transacciones, creación y borrado de objetos dentro de su base de datos.

Adicionalmente el procedimiento sp_changedbowner permite al administrador del sistema cambiar el propietario de una base de datos.

6. Chequeo de la consistencia de la base de datos

La verificación de la consistencia, Database Consistency Checker (dbcc), es un conjunto de utilidades que permiten hacer un chequeo lógico y físico de la consistencia de una base de datos.

6.1 Distribución Física

Cuando se inicializa un dispositivo de base de datos, el comando disk init divide el nuevo espacio en unidades de asignación de 256 páginas de datos de 2K. La primera página de cada unidad es una página de asignación , que controla el uso de todas las páginas de la unidad de asignación. Las páginas de asignación tienen una ID de objeto de 99; no son objetos reales de base de datos y no aparecen en las tablas del sistema, pero los errores detectados por dbcc en las páginas de asignación mencionan este valor.

Cuando una tabla o un índice requieren espacio, SQL Server asigna un bloque de 8 páginas de 2K al objeto. Este bloque de 8 páginas se denomina sector . Cada unidad de asignación de 256 páginas contiene 32 sectores. SQL Server utiliza los sectores como una unidad de administración de espacio para asignar y desasignar espacio:

Cuando se crea una tabla o un índice, SQL Server asigna un sector para el objeto. Cuando se añaden filas en una tabla existente, si las páginas existentes están llenas,

SQL Server asigna otra página. Si todas las páginas de un sector están llenas, SQL Server asigna un sector adicional.

Cuando se omite una tabla o un índice, SQL Server desasigna los sectores que ocupaba.

Cuando se eliminan suficientes filas de una tabla como para que disminuya en una página, SQL Server desasigna la página. Si la tabla disminuye el sector, SQL Server desasigna el sector.

Cada vez que se asigna o desasigna espacio en un sector, SQL Server registra el evento en la página de asignación que controla los sectores de ese objeto. Esto proporciona un método rápido de controlar las asignaciones de espacio en la base de datos, ya que los objetos pueden menguar o crecer sin mucha sobrecarga.

Dbcc provee del comando checkalloc para verificar las páginas de asignación, indexalloc y tablealloc para verificar la asignación de los objetos específicos de la base de datos.

6.2 Mapa de Asignación de Objetos (OAM)

Cada tabla y cada índice de una tabla tiene un mapa de asignación de objetos. El OAM se almacena en las páginas asignadas a la tabla o al índice y se verifican cuando es necesario una nueva página para el índice o la tabla. En una página OAM se pueden ubicar correlaciones de asignaciónde 2.000 a 63.750 páginas de datos ó índice.

El enlace de las páginas relacionadas de un mismo objeto se realiza con un encabezado que se ubica en la página misma, en el que se relaciona la página previa y la siguiente. Los comandos dbcc comparan el enlace de páginas y verifican la información.

6.3 Comandos dbcc

La sintaxis de dbcc checktable es:

dbcc checktable ({ table_name | table_id } [, skip_ncindex] )

El comando dbcc checktable verifica la tabla especificada chequeando:

Las páginas de índice y datos estén enlazadas correctamente. Los índices estén ordenados correctamente. Todos los punteros sean consistentes. Las filas de datos de cada página tengan entradas en la primera página OAM cuyas

ubicaciones respectivas en la página coincidan.

La opción skip_ncindex permite saltar la verificación de enlace de páginas, de punteros y de criterio de ordenación en índices no agrupados. El enlace y los punteros de índices agrupados y las páginas de datos son esenciales para la integridad de las tablas. Si SQL Server informa sobre problemas con el enlace de páginas o los punteros, es posible omitir y volver a crear los índices agrupados con facilidad.

La sintaxis de dbcc checkdb es:

dbcc checkdb [( database_name [, skip_ncindex]) ]

El comando dbcc checkdb ejecuta las mismas verificaciones que dbcc checktable en cada tabla de la base de datos especificada. Si no se suministra el nombre de una base de datos, dbcc checkdb verifica la actual. dbcc checkdb devuelve mensajes similares a los generados por dbcc checktable y realiza el mismo tipo de correcciones.

Si se especifica el modo opcional skip_ncindex , dbcc checkdb no verifica ninguno de los índices no agrupados de las tablas de usuario de la base de datos.

La sintaxis de dbcc checkcatalog es:

dbcc checkcatalog [( database_name )]

El comando dbcc checkcatalog verifica la consistencia dentro y entre las tablas del sistema de una base de datos en particular. Si no se suministra el nombre de una base de datos, dbcc checkcatalog verifica la actual. Verifica que:

Todo tipo incluido en syscolumns tenga una entrada correspondiente en systypes . Toda tabla y vista de sysobjects tenga al menos una columna en syscolumns .

19

El último punto de verificación de syslogs sea válido. También enumera los segmentos definidos para uso de la base de datos.

La sintaxis de dbcc checkalloc es:

dbcc checkalloc [( database_name [, fix | nofix] )]

El comando dbcc checkalloc verifica la base de datos especificada para ver que: Todas las páginas estén asignadas correctamente. Ninguna página esté asignada sin estar en uso. Ninguna página esté en uso sin estar asignada.

Si no se proporciona el nombre de una base de datos, dbcc checkalloc verifica la actual.

El modo predeterminado de dbcc checkalloc es nofix . Para utilizar dbcc checkalloc con la opción fix , primero es necesario poner la base de datos en modo de usuario único con el comando:

sp_dboption dbname, "single user", true

Este comando sólo puede ejecutarse cuando nadie esté usando la base de datos. dbcc checkalloc informa la cantidad de espacio asignado y utilizado. La salida de dbcc checkalloc consta de un bloque de datos para cada tabla, incluyendo las tablas del sistema y los índices de cada tabla. Por cada tabla o índice, informa el número de páginas y sectores utilizados.

La sintaxis de dbcc tablealloc es:

dbcc tablealloc ({ table_name | table_id } [, {full | optimized | fast | null} [, fix | nofix]])

Nota: fix o nofix pueden especificarse sólo si se incluye un valor para el tipo de informe (full , optimized , fast o null ). Este comando realiza las mismas verificaciones que dbcc checkalloc en una sola tabla. Es posible especificar el nombre de la tabla o su ID de objeto (la columna id de sysobjects ). Con dbcc tablealloc pueden generarse tres tipos de informes: full , optimized y fast :

La opción full equivale a dbcc checkalloc a nivel de tabla; informa de todos los tipos de errores de asignación .

La opción optimized produce un informe basado en las páginas de asignación enumeradas en las páginas del mapa de asignación de objetos (OAM) de la tabla. No informa ni puede corregir sectores no referenciados en las páginas de asignación que no están presentes en las páginas OAM. Si el tipo de informe no se indica en el comando, o si se indica null , optimized es el informe predeterminado.

20

La opción fast produce un informe de excepciones de páginas referenciadas pero no asignadas en el sector (errores del nivel 2521). No produce un informe de asignaciones.

La opción fix | nofix determina si tablealloc corrige o no los errores de asignación encontrados en la tabla. El valor predeterminado para todas las tablas de usuario es fix; para las del sistema, es nofix. Para utilizar la opción fix con las tablas del sistema, antes es necesario poner la base de datos en modo de usuario único.

Esta es la sintaxis de dbcc indexalloc :

dbcc indexalloc ( { table_name | table_id }, index_id [, {full | optimized | fast | null} [, fix | nofix]])

Not: Sólo puede especificarse fix o nofix si se incluye un valor para el tipo de informe (full , optimized , fast o null ). El comando dbcc indexalloc verifica el índice especificado para ver que:

Todas las páginas estén asignadas correctamente. Ninguna página esté asignada sin estar en uso. Ninguna página esté en uso sin estar asignada.

Esta es una versión a nivel de índice de dbcc checkalloc , que proporciona las mismas verificaciones de integridad en un índice individual. Es posible especificar el nombre de la tabla o su ID de objeto (la columna id de sysobjects) y la indid del índice en sysindexes . dbcc checkalloc y dbcc indexalloc incluyen la ID del índice en su salida.

dbcc indexalloc produce los mismos tres tipos de informes que dbcc tablealloc : full, optimized y fast (consulte t ablealloc ). La opción fix | nofix funciona igual en dbcc indexalloc que en dbcc tablealloc.

Esta es la sintaxis de dbcc dbrepair :

dbcc dbrepair ( database_name , dropdb)

El comando dbcc dbrepair dropdb omite una base de datos dañada. El comando drop database de Transact-SQL no funciona en una base de datos que no pueda recuperarse o usarse. Ejecute la instrucción dbrepair desde la base de datos master . Ningún usuario, incluido el de dbrepair , puede estar usando la base de datos cuando se la omite.

El administrador del sistema o el propietario de la tabla deberán ejecutar dbcc reindex después de cambiar los criterios de ordenación de SQL Server. Esta es la sintaxis de dbcc reindex :

dbcc reindex ({ table_name | table_id })

21

El comando dbcc reindex verifica la integridad de los índices de las tablas de usuario ejecutando una versión "rápida" de dbcc checktable. dbcc reindex omite y reconstruye los índices que sospecha que están corruptos, (es decir, el orden en que los índices ordenan los datos no es consistente con el nuevo criterio de ordenamiento).

22

7. Copias de Seguridad y Restauración de Bases de Datos de Usuario

Las copias de seguridad hacen parte importante de las políticas de administracion de un sistema de bases de datos ya que garantizan una recuperación del sistema en el eventual suceso de una falla irrecuperable de disco o cualquier otro problema que desemboque en inconsistencia de los datos.

Pero cómo se realiza la recuperación de una base de datos desde un backup? Es necesario entender primero cómo almacena los cambios sufridos por una base de datos y cómo estimar si los últimos cambios son validos para llegar al estado más próximo de la base de datos antes del suceso del fallo.

SQL Server lleva un registro de todos los cambios hechos a una base de datos, por medio del rastreo de las transacciones realizadas. Las transacciones son unidades de comandos de SQL y de comandos de flujo y control tales que como una sola son válidas o no lo son. Comunmente estas transacciones son encabezadas con la clausula begin transaction y finalizadas con la clausula end transaction. Por tanto todos los comandos que se encuentren dentro de éstas dos clausulas hacen parte integrante de la transaccion y junto con ella o fallan, o son válidas.

Cada base de datos tiene su propio espacio de almacenamiento de transacciones, es conocido como el log de transacciones. Para esto se utiliza la tabla de sistema syslogs.

Por tanto es posible obtener copias de seguridad de la base de datos o del log de transacciones con el fin de ajustar de una forma garantizada la recuperación de la base de datos.

7.1 Comandos de volcado y carga

Los principales comandos en la elaboración de copias de seguridad y restauración de las mismas son:

dump transaction copia la información del log de transacciones, lo que garantiza una recuperación de las transacciones exitosas.

Nota: Nunca utilice insert, update o delete sobre la tabla de log syslogs.

checkpoint permite hacer sincronización de una base de datos y de su log de transacciones actualizando las páginas “sucias” (es decir las que no han sido actualizadas en disco sino únicamente en memoria). Se puede ejecutar de manera automática o manual.

recovery interval es el tiempo estimado de recuperación de una base de datos en minutos. Y este tiempo depende del tamaño de la base de datos.

trunc log on chkpt es una opción de configuración que permite truncar el log de transacciones cada vez que se ejecuta un checkpoint automático.

El mecanismo de recuperación compara cada base de datos con su log de transacciones. Si el registro es más reciente que la página de datos el mecanismo de recuperación aplica los cambios. Si la transacción no fue completada con éxito se reversa hasta el punto de inicio. Este mecanismo asegura que la transacción se completa de forma segura o falla. Cuando SQL Server es iniciado (por shutdown o por caida abrupta) es inicializado en el siguiente orden.1. Recupera master2. Recupera sybsecurity3. Recupera model4. Crea tempdb (copiando model)5. Recupera sybsystemprocs6. Recupera bases de datos de usuariode acuerdo a su dbid.

En el evento de un daño de disco se puede recuperar la base de datos en su totalidad (o al máximo) siempre y cuando existan copias de seguridad de la base de datos y de su log de transacciones. Para estas actividades se requieren los siguientes comandos dump database, dump transaction, load database, load transaction.

Nota: no es posible recuperar una base de datos copiando con los comandos de sistema operativo, esto puede generar un error de carga masiva.

Antes de sacar una copia de seguridad es recomendable hacer una verificación de la consistencia para obtener una copia confiable. Para hacer una copia de seguridad al evento de un fallo utilice la opción with no_truncate del comando dump transaction, lo que es posible únicamente si el log de transacciones se encuentra fuera del dispositivo que ha fallado y la base de datos master es accesible. Si se hace restauración de un backup de base de datos, se modifica la base de datos y luego se intentan restaurar las transacciones del backup del log de transacciones la operación falla.

Es posible recuperar una base de datos desde un backup incluyendo la opción for load en la clausula create database.

El comando sp_volchanged puede ser ejecutado por cualquier usuario y se utiliza para indicar a SQL Server que el volumen de cinta se ha cambiado.

Backup Server es un servidos dedicado exclusivamente a sacar y restaurar copias de seguridad. Backup Server se encarga de hacer backups en red, particionar los datos de manera que pueda dividir el backup en varios dispositivos (en el caso de las cintas), hacer copias de seguridad remotas.

24

Los dispositivos para copias de seguridad (local) se encuentran enumerados en la tabla sysdevices. Son adicionados por medio de la clausula sp_addumpdevice. Sintaxis:

sp_addumpdevice{ "tape" | "disk"} , device_name,physicalname, size

donde physicalname representa la ubicación física del archivo (o partición) a utilizar como dispositivo de copia de seguridad. Para eliminarlo utilizar el procedimiento sp_dropdevice.

Recomendación: hacer un dump de la base de datos master después de hacer un cambio en discos, almacenamiento, bases de datos o segmentos. De la misma forma es conveniente hacer copias de seguridad de model cuando sea modificada su estructura ya que de ella parten todas las bases de datos que se produzcan.

La sintaxis de los comandos de copia y volcado es muy similar:

dump loaddump {database | tran} database_nameto stripe_device[at server_name][density = density,blocksize = number_bytes,capacity = number_kilobytes,dumpvolume = volume_name,file = file_name][stripe on stripe_device[at server_name][density = density,blocksize = number_bytes,capacity = number_kilobytes,dumpvolume = volume_name,file = file_name] ...][with{density = density,blocksize = number_bytes,capacity = number_kilobytes,dumpvolume = volume_name,file = file_name,[nodismount | dismount],[nounload | unload],retaindays = number_days,[noinit | init],[notify = {client | operator_console}]}]

load {database | tran} database_namefrom stripe_device [at server_name][density = density,blocksize = number_bytesdumpvolume = volume_namefile = file_name][stripe on stripe_device[at server_name][density = density,blocksize = number_bytes,dumpvolume = volume_name,file = file_name] ...][with{density = density,blocksize = number_bytes,dumpvolume = volume_name,file = file_name,[nodismount | dismount],[nounload | unload],[notify = {client | operator_console}]}]

7.2 Reglas para especificar dispositivos de volcado

Utilice las siguientes reglas para especificar el dispositivo de volcado:

El dispositivo de volcado puede especificarse como literal, variable local o parámetro de un procedimiento almacenado.

25

No es posible volcar a o cargar del "dispositivo nulo" (en UNIX, /dev/null ; en OpenVMS, cualquier dispositivo cuyo nombre comience con NL; no aplicable a plataformas PC ).

Al volcar a o cargar desde un dispositivo local, se puede utilizar cualquiera de las formas siguientes para especificar el dispositivo de volcado:

Un nombre absoluto de ruta de acceso Un nombre relativo de ruta de acceso Un nombre lógico de dispositivo de la tabla del sistema sysdevices

El Backup Server resuelve los nombres relativos usando el directorio de trabajo actual de SQL Server.

Al volcar o cargar a través de la red:

Debe especificarse el nombre absoluto de ruta de acceso del dispositivo de volcado. (No es posible utilizar un nombre relativo de ruta ni un nombre lógico de dispositivo de la tabla del sistema sysdevices .)

El nombre de ruta debe ser válido en la máquina donde se ejecuta el Backup Server. Si el nombre incluye caracteres que no sean letras, números o el guión de subrayado

(_), debe ir entre comillas.

7.3 Procedimiento de recuperación

1. Obtenga una copia de seguridad del log de todas las bases de datos en el dispositivo.2. Examine el espacio utilizado por cada base de datos en el dispositivo.3. Una vez haya consolidado esta información borre cada base de datos (drop database).4. Suelte el dispositivo que falló.5. Inicializar los nuevos dispositivos.6. Re-crear las bases de datos, una a la vez.7. Bloquear usuarios en cada base de datos.8. Cargue el volcado más reciente en cada base de datos.9. Aplique cada transacción del volcado del log en el orden en que fueron creados.

7.4 Procedimientos de recuperación de las base de datos de sistema

1. Haga copias de seguridad de las tablas delsistema necesarias para restaurar discos, bases de datos y logins.2. Si hay otras bases de datos en el dispositivo master (no es recomendable tenerlas), y son accesibles sáqueles copia de seguridad.3. Utilice buildmaster para construir una nueva base de datos master.4. Reinicie SQL Server en modo mono-usuario con el comando startserver.5. Si su base de datos es mayor de 3MB, debe re-crear las asignaciones en sysusages.

26

6. Si su Backup Server no es syb_bakcup, cambie el nombre en sysservers.7. Verifique que su Backup Server este corriendo.8. Utilice load database para cargar los más recientes copias de la base de datos master.9. Reinicie SQL Server en modo mono-usuario con el comando startserver.10. Si tiene dispositivos de bases de datos adicionales, utilice disk reinit para reconstruir

sysdevices. 11. Si corrió disk reinit, o si creo bases de datos o las modificó desde la última copia de la base de datos haga copias de sysusages y sysdatabases y luego utilice disk refit para reconstruir estas tablas de sistema.12. Verifique la consistenacia, compare sus copias de sysusages y sysdatabases con la nueva versión de la base de datos, ejecute dbcc checkalloc en cada base de datos y examine las tablas importantes en cada base de datos13. Si usted restauró completamente master restaure model.14. Recargar las bases de datos de usuario.15. Verifique syslogins si usted ha adicionado nuevos logins desde la última copia de seguridad.

27

8. Administrando espacio libre con umbrales

Las limitaciones de espacio en los dispositivos (al momento de ser creados el espacio se establece) implica que al momento en que se llenen se han de bloquear y no permitirán su acceso. Por esto es necesario definir alarmas que se disparen en el momento en que se rebasen los límites conocidos como umbrales.

La existencia de umbrales permiten definir las acciones a tomar en el evento que sean alcanzados, tanto en el espacio de datos como en el diario de transacciones. Un umbral esta asociado con un procedimiento almacenado y funciona como un trigger en el evento de ser rebasado o simplemente alcanzado (sp_thresholdaction).

Por ejemplo cada log de transacciones tiene un umbral de ultima oportunidad que es el espacio necesario para hacer el volcado del diario (espacio dado en páginas).

El umbral de última oportunidad otorga suficiente espacio de log libre para registrar un comando dump transaction . Cuando se cruza el umbral de última oportunidad, SQL Server suspende los procesos de usuario y muestra un mensaje de suspensión de operaciones.

Cuando esto sucede es necesario suspender los procesos que estan activos y luego ejecutar un checkpoint con el fín de que se actualicen las páginas sucias. Los procesos que quedan suspendidos son automáticamente reiniciados cuando hay el suficiente espacio en el log de transacciones para ser registrados.

Los Umbrales pueden ser modificados, o eliminados y además pueden ser creados nuevos umbrales. Los procedimientos del sistema sp_addthreshold (crear nuevos umbrales), sp_modifythreshold (modificar el evento programado ó el valor) y sp_dropthreshold permiten crear, cambiar y eliminar umbrales. Con procedimiento del sistema sp_helpthreshold se puede obtener información sobre todos los umbrales de una base de datos.

Volcado del diario de transacciones

Si el procedimiento sp_thresholdaction asociado al evento del umbral incluye un comando dump transaction, SQL Server vuelca el diario a los dispositivos indicados en el procedimiento. El comando dump transaction trunca el diario de transacciones borrando las páginas desde el principio del diario hasta la página situada justo antes de la que contiene un registro de transacción no registrada.

En general, no se recomienda el volcado a un disco, especialmente a un disco que esté en la misma máquina, o el mismo controlador de disco que el disco, de la base de datos. Sin embargo, dado que los volcados iniciados por un umbral pueden ocurrir en cualquier

momento, tal vez convenga hacer un volcado al disco y luego copiar los archivos resultantes a un medio fuera de línea. La decisión dependerá de: Si hay un dispositivo de volcado dedicado en línea, que esté cargado y preparado para

recibir datos volcados. Si hay operadores disponibles para montar volúmenes de cinta durante los momentos en

que la base de datos está disponible. El tamaño del diario de transacciones. La cantidad de transacciones. La planificación periódica del volcado de las bases de datos y de los diarios de

transacciones. El espacio de disco disponible. Otros recursos de volcado y restricciones específicos del sitio.

29