Tema 32. Adm. de BBDD: motores, gestión del espacio,
seguridad, rendimiento, servicios de red, backup.
Introducción ... 1
Los motores de Bases de Datos ... 2
Gestión del almacenamiento ... 3
Gestión del espacio físico ... 3
Seguridad ... 5
Gestión del control de acceso a las bases de datos ... 6
Rendimiento ... 8
Servicios de red ... 9
Objetivos ... 9
Backup y recuperación de datos ... 10
Tipos de backups ... 10
Journaling ... 11
Recuperación ... 11
Introducción
Desde la década de los 70, la mayoría de las aplicaciones almacenan la información en bases de datos, en vez de hacerlo directamente sobre ficheros.
Una base de datos es un conjunto de datos relacionados con un significado y organizados según unas determinadas reglas.
Los Sistemas Gestores de Bases de Datos – SGBD – son el software encargado de dar soporte a las bases de datos y proporcionar servicios a los usuarios de las mismas. Los SGBD también se denominan motores de bases de datos.
Las bases de datos más utilizadas actualmente son las bases de datos relacionales que almacenan los datos de forma estructurada en forma de tablas. Por ello, mis explicaciones irán orientadas a los SGBD relacionales, no a otros como los SGBD orientados a objetos o SGBD Documentales.
Existen muchos SGBD relacionales que se organizan de forma similar. Las explicaciones que daré sobre la administración de bases de datos la realizaré enfocadas a los SGBD Oracle, pues son los más extendidos y son los usados por la CAIB.
Los motores de Bases de Datos
Los SGBD son aplicaciones autónomas que implementan las Bases de datos y gestionan sus recursos (memoria y espacio en disco) de forma independiente del sistema operativo.
Los SGBD proporcionan una serie de beneficios al tratar grandes volúmenes de datos:
Eliminan la redundancia de datos . Se evita tener almacenados datos repetidos o datos calculados. Con ello se consigue un almacenamiento eficiente y asegurar la consistencia de los datos.
Proporciona una visión abstracta de los datos . Ocultando los detalles del almacenamiento físico y permite un acceso a los datos de forma independiente a su localización y organización física.
Proporcionan lenguajes de alto nivel que facilitan el manejo de los datos. Generalmente SQL.
Flexibilidad respecto a los cambios. Facilita los cambios en la organización lógica de los datos ( P.ej: Modificar la estructura de una tabla). Permite cambiar la organización física de los datos sin modificar la lógica. Independencia de los datos respecto a las aplicaciones.
Permite el acceso concurrente de usuarios a los datos. La gestiona a través de transacciones y bloqueos.
Establece medidas de seguridad sobre los datos:
o Asegura la integridad de los datos respecto a accidentes ( backups, sistemas de recuperación contra fallos...)
o Garantiza la confidencialidad de los datos: Gestiona el control de acceso y de actividades de los usuarios.
La arquitectura de un SGBD se compone de cinco niveles y tres procesos transversales:
Nivel 5- Compilador y optimizador de sentencias DML y DQL que recibe de los clientes. Crea el plan de ejecución.
Nivel 4- Ejecución del plan de ejecución de las sentencias. (Realizar las operaciones relacionales que componen el plan).
Nivel 3- Soporte a los conceptos de ficheros e índices.
Nivel 2- Gestión de la memoria. El SGBD gestiona de forma independiente el espacio de memoria que tenga asignado.
Nivel 1- Gestión de disco. El SGBD implementa su propio sistema de ficheros en el espacio de disco que tenga asignado.
Los tres procesos transversales de soporte son: La gestión de transacciones
La gestión de bloqueos
Gestión del almacenamiento
La arquitectura de los datos dentro del SGBD se compone de tres niveles:
El nivel interno : Corresponde a la organización física de los datos: Tamaños, formatos, ficheros...
El nivel conceptual : Contiene la organización lógica de los datos: Tablas, vínculos, restricciones...
El nivel externo : Es un subconjunto del nivel conceptual, con una organización lógica diferente adaptada para una aplicación en concreto. Se utilizan las vistas.
El uso de tres niveles a la hora de gestionar los datos está motivado con el objeto de conseguir:
La independencia física de los datos: Se puede variar la organización física de los datos sin que se vean afectados los niveles superiores. Por ejemplo: Variar el tamaño de los sectores en disco.
La independencia lógica de los datos: Reduce el impacto de modificar la organización conceptual de los datos. Permite actualizar las vistas para que la organización externa no se vea afectada y los cambios sean transparentes a las aplicaciones.
Gestión del espacio físico
El SGBD gestiona su espacio de disco de forma independiente del SO.
El SGBD divide el espacio disponible en unidades lógicas denominadas “tablespace”, que tiene un nombre identificativo, espacio reservado y contiene elementos de una BD. Una BD puede estar dividida en uno o más ‘tablespace’.
A cada “tablespace” se le asocian uno o más ‘datafiles’, que son los ficheros donde se almacenan los datos de los elementos de la BD (Tablas, índices...). Cada datafile contiene el espacio necesario para almacenar los datos actuales más el que se prevea que tendrá. Cuando se agota el espacio del datafile, hay gestores que aumentan su tamaño asignado y otros que crean otro datafile.
Físicamente dentro del “tablespace”, los datos se organizan en bloques, extensiones y segmentos.
Los bloques: Es la unidad mínima de E/S del SGBD. Es un número específico de bytes en un dispositivo de almacenamiento. El tamaño del bloque no tiene porque ser igual que los bloques de E/S del SO pero conviene que sea múltiplo. Normalmente, un bloque almacena datos de un mismo elemento. Los parámetros que se pueden configurar de los bloques son: El tamaño: Oscila entre 2Kbits y 32Kbits. En entornos OLTP, donde se
efectúan muchas operaciones ligeras, conviene tener tamaños pequeños para que quepan en memoria principal el mayor número de bloques. En entornos OLAP, donde se efectúan pocas operaciones pesadas, conviene bloques grandes para mover muchos datos en cada operación de E/S.
Los parámetros PCT Free y PCT Used: El PCTFree es el porcentaje de espacio del bloque destinado a almacenar los posible aumentos del tamaño de las filas almacenadas en el bloque. Una vez que sólo queda el PCTFree libre, no se puede insertar nuevas filas en el bloque. El PCTUsed es el porcentaje de utilización que se debe volver a alcanzar para poder volver a insertar filas tras alcanzar el PCTFree. El objeto de esta restricción es evitar tener datos de una misma fila en varios bloques, porque resta rendimiento a las operaciones. Cuanto mayor es la variabilidad del tamaño de las filas de una tabla, mayor debe ser el PCTFree
Extensiones. Es la unidad compuesta por un grupo de bloques consecutivos en disco. Si todas los datos de un tablas están almacenados de forma consecutiva, las lecturas son eficientes, en cambio, tener los bloques repartidos por el disco unidos por punteros, mejora las operaciones de inserción, borrado y modificación. Los SGBD adoptan una solución intermedia, tienen grupos de bloques consecutivos (extensiones) unidos por punteros.
Segmentos. Es una colección de extensiones que pertenecen a un tablespace y están contenidos en uno o más ‘datafiles’.Existen 4 tipos de segmentos: de datos, de índices, temporales y de rollback.
Tareas del DBA respecto al almacenamiento de un BD:
Asesoramiento a los analistas y diseñadores, para que tengan en cuenta las peculiaridades del SGBD a la hora de realizar el diseño final de la BD y asegurar su eficiencia: Ayudar a decidir los parámetros del almacenamiento y la ubicación de los datafiles. Los datafiles que se acceden de forma simultánea conviene que estén en dispositivos de almacenamiento diferentes para permitir el acceso concurrente.
Monitorización de la BD durante su explotación con objeto de:
o Planificar el crecimiento del espacio almacenamiento . Tanto el previsto por los analistas, como el imprevisto. Decidir como se realizará este crecimiento.
o Reorganizar los elementos de la bd . Durante la explotación de la BD se puede evidenciar que la organización física de los elementos no es la más eficiente. El DBA debe detectar este hecho y tomar decisiones.
o Desfragmentar el espacio de disco . Durante la eliminación y modificación de filas
Seguridad
Los SGBD tienen como finalidad facilitar el acceso a los datos por parte de los usuarios, esta cualidad conlleva riesgos, pues también facilita el acceso a los datos por parte de usuarios no autorizados. Es por ello, que los SGBD disponen de servicios de seguridad para minimizar estos riesgos. Es función del DBA establecer y gestionar los sistemas de seguridad del SGBD.
Los principios básicos de seguridad son:
1. Identificación y autenticación: el usuario se identificará y autenticará con el procedimiento de introducir un usuario/contraseña (logon) con la finalidad de confirmar su identidad. Normalmente, el SO obliga a identificar al usuario, se pueden establecer mecanismos que permitan que esta identificación sea utilizada también por la base de datos (single-sign-on), aunque siempre será más seguro obligar a volver a identificarse al acceder al SGBD.
2. Autorización y controles de acceso: una vez identificado el usuario, el DBMS controla las operaciones que pueden hacer sobre los elementos de la base de datos.
3. Integridad y Consistencia: el DBMS será el encargado de mantener la integridad y la consistencia de los datos, siguiendo las especificaciones definidas al modelo de datos (constraints). Para asegurar la consistencia, además, se usan las transacciones.
4. Auditoría: Es la seguridad a posteriori. Los SGBD almacenan en ficheros “logs”, todas las operaciones realizadas en la base de datos. Si hay agujeros de seguridad, en la auditoría del fichero “log” pueden ser descubiertos y eliminarlos. Las auditorías pueden hacerse de forma periódica o cuando se sospecha que ha habido una violación de la seguridad. Hay SGBD generan ficheros “logs” específicos para las auditorías, denominadas “audit trail”. Un SGBD que facilite las auditorias, hace que sea más seguro
5. Disponibilidad: se trata de asegurar que los datos están disponibles y son accesibles para los usuarios durante unos horarios determinados. Si la disponibilidad es de 24 horas, la administración del SGBD es más compleja: los backups deben hacerse en caliente, el hardware debe ser de alta disponibilidad (hot-swap...) y también la conexión de red Extranet/Intranet. Para sistemas críticos, se pueden incorporar sistemas de redundancia a nivel de SO (RAID, Cluster, etc.) o del SGBD (BD Replicadas).
Gestión del control de acceso a las bases de datos
Una de las tareas del DBA es organizar los permisos de acceso a los datos por parte de los usuarios, de acuerdo a la política de la organización. El lenguaje SQL incorpora las sentencias necesarias para administrar la seguridad.
Las tareas a realizar son:
Crear cuentas de usuario: Utilizando la sentencia “CREATE USER nom_usuari IDENTIFIED BY contraseña” o “... IDENTIFY EXTERNALLY” si queremos aprovechar la identificación del SO. La administración de las contraseñas debe contemplar: Las contraseñas deben almacenarse de forma cifrada, los usuarios deben cambiar periódicamente de contraseñas, se puede establecer vías permitidas de acceso como número de intentos máximo de acceso.
Grupos de usuario (roles) : El uso de roles facilita la administración en bases de datos con multitud de usuarios. El rol actúa de contenedor de permisos, en vez de asignarlos a los usuarios, se asignan a los roles. Para cada base de datos contenida en el SGBD, se crea un rol para cada tipo de usuario posible, ej: ADMINISTRADOR, OPERADOR, CONSULTA... Un usuario puede tener varios roles.
Asignar y quitar permisos a los usuarios y roles. Los permisos son autorizaciones para poder realizar operaciones sobre determinados objetos de la base de datos. A mayor granularidad a la hora de otorgar los permisos, mayor control de la seguridad. Hay dos tipos de permisos:
- A nivel de objeto: Permitir o restringir el acceso a los datos y cambios sobre éstos. La sentencia SQL sería “GRANT ( SELECT | UPDATE | DELETE | INSERT ) ON nombre_tabla_o_vista TO user [WITH GRANT OPTION]”. Y se elimina con la operación “REVOKE”.
- A nivel de sistema: Permitir realizar funciones de administración del SGBD, poder cambiar el esquema de las BD (crear, modifiar,borrar tablas, vistas...) o administrar los mismos permisos.
Clasificar los datos y usuarios en niveles de seguridad. (No todos los SGBD) Otro método de seguridad es el uso de vistas. Con las vistas se pueden crear tablas virtuales a partir de tablas con información confidencial. La vista sólo muestra la información autorizada. El usuario tiene acceso a la vista pero no a la tabla.
En una base de datos podemos encontrar tres tipos de seguridad, que se pueden combinar:
Control de acceso discrecional . Es el sistema tradicional de seguridad. Los usuarios tienen permisos sobre los elementos de la BD, cuando el usuario quiere realizar una acción, el SGBD comprueba que tenga los permisos necesarios para realizar la acción.
Control de acceso “mandatory” . Utilizado en sistemas de alta seguridad. Tanto los datos como los usuarios están clasificados en niveles de seguridad: p.ej: secreto, confidencial y no clasificado. Los usuarios sólo pueden interactuar con los datos con nivel de seguridad menor o igual al suyo.
Seguridad en sistema estadísticos . Utilizado en SGBD con datos personales confidenciales. Se permite a los usuarios obtener datos estadísticos sobre ellos, pero no acceder a los datos individualmente.
El Real Decreto que desarrolla la Ley Orgánica de Protección de Datos establece unos requisitos mínimos de seguridad a aplicar a los datos almacenados en la BD, en caso de contener datos de carácter personal.
Rendimiento
El DBA debe asegurar que el rendimiento del SGBD sea el apropiado para satisfacer los requisitos de los usuarios.
El rendimiento del SGBD se puede medir utilizando tres indicadores:
La velocidad de respuesta de las transacciones . Es el rendimiento percibido por los usuarios.
La productividad del SGBD . El número de transacciones por segundo ejecutadas por el SGBD.
La utilización de los recursos. Especialmente la capacidad de almacenamiento de los discos.
El primer factor en el rendimiento de una BD es su diseño. Un buen diseño de la BD y de las aplicaciones permite obtener un buen rendimiento del SGBD. Ahorrar esfuerzo (= dinero y dedicación) a la hora de analizar, diseñar e implementar una aplicación, provoca problemas de rendimiento, entre otros.
Por esto es muy importante que a la hora de diseñar un nuevo sistema se tengan en cuenta los siguientes criterios:
- Definir las necesidades de servicio que tendrán las aplicaciones.
- Hacer un análisis correcto de los datos y como serán accedidos.
- Desarrollar un código de acceso a la BD eficiente.
La optimización de los elementos de un SGBD es un factor prioritario en su rendimiento. La optimización se puede conseguir:
El uso de índices . La consulta a las tablas puede acelerarse utilizando índices para las columnas utilizadas en las operaciones selecciones y “join”. El uso de los índices acelera las operaciones de “consulta”, pero no perjudica la velocidad de las operaciones de “modificación” y “borrado”. No se deben indexar columnas muy volátiles o con poca variedad de valores ni tablas con pocas filas.
El diseño de las consultas pueden invalidar el uso del índice. Por ejemplo, los optimizadores no utilizan los índices en columnas usadas en operaciones aritméticas, con operaciones con null o en consultas anidadas.
La organización física de los datos . Se pueden configurar el tamaño de los bloques en disco o reubicar los segmentos. Los elementos que se acceden de forma simultánea deben estar en dispositivos separados, para permitir la simultaneidad.
La red de comunicaciones . En la actualidad, con las bases de datos distribuidas y con la arquitectura de aplicaciones de dos y tres capas, el rendimiento de las comunicaciones afectan directamente al rendimiento del SGBD.
El modelo de datos físico . Hay casos que conviene “desnormalizar” el diseño de las bases de datos para ganar en rendimiento. Por ejemplo: Guardando datos calculados, cuando su cálculo supone mucho tiempo.
Servicios de red
Actualmente, el servicio informático de las organizaciones está distribuido y se comunica a través de las redes de comunicaciones. La arquitectura de aplicaciones que impera es la de cliente-servidor de tres capas y quedan todavía muchas aplicaciones de dos capas. Los SGBD han de incorporar en sus productos los protocolos y elementos que permiten la comunicación a través de red.
Ejemplos de servicios de red de los DBMS son SQL*Net de Oracle (net8 a partir de Oracle8) o OpenClient de Sybase.
Objetivos
Los servicios de red de los SGBD permiten:
1. la comunicación entre los procesos en las máquinas clientes y los procesos del SGBD en los servidores.
2. También permiten la comunicación servidor-servidor, para bases de datos distribuidas o cooperativas.
Se utilizan protocolos preparados para intercambiar a través de la red sentencias SQL y datos.
Es deseable que estos protocolos incorporen las siguientes funcionalidades:
- Transparencia respecto a las características de la red (topología, medios de transmisión…).
- Independencia de los protocolos de red utilizados.
- Transparencia respecto de las localizaciones de las máquinas.
- Seguridad y confiabilidad en las transacciones remotas. Veamos un ejemplo de las capas de interfaz de red de Oracle (SQL*net):
Código cliente Net8 Código estándar Net8 Adaptador Protocolo X
Interfaz Protocolo X Controlador dispositivo
Interfaz OS - Red
Código Servidor Net8 Código estándar Net8 Adaptador Protocolo X
Interfaz Protocolo X Controlador dispositivo Interfaz OS - Red Red Proceso Servidor SO Proceso Cliente SO Hardware Hardware
Backup y recuperación de datos
El administrador es el responsable que se realice la copia de seguridad de datos de las BD, para asegurar la integridad de los datos en caso de accidente.
En la mayoría de accidentes no catastróficos, como el fallo de una instancia del SGBD, el propio SGBD puede recuperar la integridad de los datos de forma automática. Para conseguirlo, el SGBD almacena todas las operaciones que se realicen en unos ficheros denominados “RedoLogs”, y para poder deshacer las operaciones de las transacciones no confirmadas.
Los accidentes más graves, como averías de discos, necesitan la intervención del administrador y tener una copia de seguridad de los datos.
Tipos de backups
Backups físicos: consisten en hacer una copia de los archivos de datos y otros tipos de archivos del DBMS (de control, de configuración, etc.) a nivel físico. Normalmente comporta una recuperación de la base de datos completa, a no ser que esta disponga de mecanismos especiales por asegurar la consistencia de una recuperación física parcial. Se permite hacer este tipo de backup de dos formas.
- Backup físico en frío (off-line). Consiste en parar la base de datos y hacer una copia completa de todos los archivos de datos (y configuración, control, etc.). Es un buen sistema porque implica una recuperación fiable y rápida (sólo se tienen que transferir ficheros y levantar la base de datos, no se tiene que hacer recuperación lógica posterior).
Sólo se podrá hacer si lo permiten las necesidades del servicio.
- Backup físico en caliente (on-line). Se hace mediante mecanismos de checkpoint . Los datos que se copian son inconsistentes. A la hora de hacer una recuperación, a partir del último checkpoint se tiene que hacer una recuperación lógica aplicando el commit o el rollback de las transacciones que estaban pendientes de validar en el momento de empezar la copia. Será necesario en entornos en qué se tenga que dar servicio ininterrumpido, o sin tiempo necesario para hacer los Backups en frio.
Backups lógicos: Las exportaciones generan unos ficheros dónde se guarda toda la información, en forma de definición de objetos más los datos que contienen, que permiten recrear las estructuras y los datos si se importan estos ficheros, ya sea sobre la misma u otra base de datos. Se pueden hacer a nivel de base de datos completa, o parcial. Pueden ser incrementales o acumulativos. Se tienen que hacer en caliente (la base de datos on-line), puesto que las utilidades de exportación van leyendo de la base de datos y escribiendo al fichero resultante. Muchas veces son necesarios por hacer backups selectivos (sólo de una parte de la BD), o por transferir datos de una base de datos a otra).
El tipo de backup más adecuado dependerá de los requerimientos de nuestro sistema, del tamaño de la BD, del tiempo disponible por hacer la recuperación, etc. El ideal es hacer copias tanto físicas como lógicas periódicamente, y en caso de pérdida de datos, poder aplicar el tipo de recuperación más adecuado.
Journaling
Esta técnica será necesaria si no es aceptable perder ningún dato de nuestro sistema en caso de fallo de algún fichero de datos.
Consiste en guardar todas las transacciones que se ejecutan a la base de datos copiándolas a archivos, sobre otro disco. Esto es una redundancia que puede resultar costosa, pero en caso de fallo del disco, se puede reconstruir todo el trabajo perdido. La recuperación consistiría en recuperar primero la última copia de la base de datos disponible, y aplicar después todos los cambios que se han hecho desde entonces, que se conocen gracias a estos ficheros.
Recuperación
El plan de backup se tiene que hacer siempre pensando en las necesidades que tendremos a la hora de hacer una recuperación. Habremos de considerar:
- Si tenemos que recuperar los datos totalmente o no son tan críticas y es suficiente restaurar la última copia.
- De qué tiempo se dispondrá por hacer la recuperación.
- Complejidad de la recuperación.
Es imprescindible que los mecanismos de recuperación se prueben habitualmente por comprobar el correcto funcionamiento. No sirve de nada tener todas las copias periódicamente realizadas y almacenadas si cuando se produce una pérdida, la recuperación no funciona.