Administración de Sistemas Gestores de Bases de Datos

A ddeministración
sistemas
gestores de
bases de datos
Consulte nuestra página web: www.sintesis.com
En ella encontrará el catálogo completo y comentado
A ddeministración
sistemas
gestores de
bases de datos
Alex Dapena
Asesor editorial:
Juan Carlos Moreno Pérez
© Alex Dapena
© EDITORIAL SÍNTESIS, S. A.
Vallehermoso, 34. 28015 Madrid
Teléfono 91 593 20 98
http://www.sintesis.com
ISBN: 978-84-1357-068-6
ISBN: 978-84-135760-1-5
Depósito Legal: M-2.435-2021
Impreso en España - Printed in Spain
Reservados todos los derechos. Está prohibido, bajo las sanciones

penales y el resarcimiento civil previstos en las leyes, reproducir,
registrar o transmitir esta publicación, íntegra o parcialmente,
por cualquier sistema de recuperación y por cualquier medio,
sea mecánico, electrónico, magnético, electroóptico, por fotocopia
o por cualquier otro, sin la autorización previa por escrito
de Editorial Síntesis, S. A.
Índice
PRESENTACIÓN ............................................................................................................................................................... 11
1.. INSTALACIÓN DEL SISTEMA GESTOR DE BASES DE DATOS .................................................... 13

Objetivos .................................................................................................................................................................... 13
Mapa conceptual .................................................................................................................................................. 14
Glosario ....................................................................................................................................................................... 14
1.1.. Introducción ............................................................................................................................................. 15
1.2.. El administrador de bases de datos .......................................................................................... 15
1.3.. El sistema gestor de bases de datos ......................................................................................... 16
1.3.1.. Funciones del sistema gestor de bases de datos ....................................................... 17
1.3.2.. Componentes de un sistema gestor de bases de datos .......................................... 19
1.4.. Factores de elección del sistema gestor de bases de datos .................................... 22
1.4.1.. Tipos de sistemas gestores de bases de datos ........................................................... 23
1.4.2.. Arquitectura del sistema gestor de base de datos .................................................... 30
1.4.3.. Tipos de licencias .................................................................................................................... 32
1.4.4.. Tipos de bases de datos ...................................................................................................... 35
1.4.5.. Requisitos necesarios ............................................................................................................. 37
1.5.. Contextos de utilización de cada sistema gestor de bases de datos ................. 37
1.6.. Instalación .................................................................................................................................................. 39
1.6.1. Componentes de la instalación .......................................................................................... 39
1.6.2.. Configuración inicial ................................................................................................................ 40
1.6.3.. Registro de instalación ........................................................................................................... 41
1.7.. Instalación de Oracle .......................................................................................................................... 41
1.7.1.. Requisitos .................................................................................................................................... 42
1.7.2.. Componentes de la instalación .......................................................................................... 42
Índice
6 Administración de sistemas gestores de bases de datos
1.7.3.. El asistente de instalación OUI ........................................................................................... 45

1.7.4.. Instalación Windows vs instalación Linux ....................................................................... 47
Resumen ..................................................................................................................................................................... 48
Ejercicios propuestos ......................................................................................................................................... 49
Actividades de autoevaluación ................................................................................................................... 51
2.. CONFIGURACIÓN DEL SISTEMA GESTOR DE BASES DE DATOS ............................................ 53

Objetivos .................................................................................................................................................................... 53
Mapa conceptual .................................................................................................................................................. 54
Glosario ....................................................................................................................................................................... 54
2.1.. Introducción ............................................................................................................................................. 55
2.2.. Configuración del sistema gestor de bases de datos ..................................................... 56
2.2.1.. Configuración del entorno ................................................................................................... 56
2.2.2.. Configuración de las conexiones ....................................................................................... 56
2.2.3.. Configuración del servidor ................................................................................................... 57
2.2.4.. Configuración del almacenamiento .................................................................................. 57
2.2.5.. Configuración de las cuentas del sistema ...................................................................... 59
2.3.. Arranque y parada del sistema ..................................................................................................... 59
2.4.. El diccionario de datos ...................................................................................................................... 60
2.5.. El cuaderno de bitácora ................................................................................................................... 61
2.6.. Documentación ...................................................................................................................................... 62
2.7.. Configuración de Oracle ................................................................................................................... 63
2.7.1.. Configuración del entorno ................................................................................................... 63
2.7.2.. Configuración de las conexiones ....................................................................................... 64
2.7.3.. Configuración de la instancia de Oracle ......................................................................... 66
2.7.4.. Configuración del almacenamiento .................................................................................. 68
2.7.5.. Cuentas de administración ................................................................................................... 69
2.7.6.. Creación y borrado de bases de datos .......................................................................... 70
2.7.7.. Ficheros de LOG ....................................................................................................................... 70
2.7.8.. Arranque y parada del sistema gestor de bases de datos ...................................... 70
2.7.9.. El diccionario de datos en Oracle .................................................................................... 74
Resumen ..................................................................................................................................................................... 75
3.. GESTIÓN DE USUARIOS Y PERMISOS ..................................................................................................... 79

Objetivos .................................................................................................................................................................... 79
Mapa conceptual .................................................................................................................................................. 80
Glosario ....................................................................................................................................................................... 80
3.1.. Introducción ............................................................................................................................................. 81
3.2.. Gestión de usuarios y permisos ................................................................................................... 81
3.2.1.. Usuarios ........................................................................................................................................ 83
3.2.2.. Permisos ....................................................................................................................................... 84
3.2.3.. Roles .............................................................................................................................................. 84
3.2.4.. Perfiles (profile) ........................................................................................................................ 86
3.3.. Gestión de usuarios y permisos en Oracle ........................................................................... 86
3.3.1.. Usuarios ........................................................................................................................................ 87
3.3.2.. Permisos ....................................................................................................................................... 90
Índice
Administración de sistemas gestores de bases de datos 7
3.3.3.. Roles .............................................................................................................................................. 92

3.3.4.. Perfiles .......................................................................................................................................... 93
3.3.5.. Diccionario de datos .............................................................................................................. 95
3.4.. Esquemas externos ............................................................................................................................... 97
3.4.1.. Vistas ............................................................................................................................................. 100
3.4.2.. Sinónimos ................................................................................................................................... 102
3.5.. Esquemas externos en Oracle ....................................................................................................... 103
Resumen ..................................................................................................................................................................... 104
4..SEGURIDAD .............................................................................................................................................................. 111

Objetivos .................................................................................................................................................................... 111
Mapa conceptual .................................................................................................................................................. 112
Glosario ....................................................................................................................................................................... 113
4.1.. Introducción ............................................................................................................................................. 113
4.2.. Confidencialidad .................................................................................................................................... 114
4.2.1.. Encriptación ............................................................................................................................... 114
4.2.2.. Auditoría ...................................................................................................................................... 116
4.3.. Confidencialidad en Oracle ............................................................................................................ 117
4.3.1.. Encriptación ............................................................................................................................... 117
4.3.2.. Auditoría ...................................................................................................................................... 121
4.4.. Integridad ................................................................................................................................................... 126
4.4.1.. Restricciones .............................................................................................................................. 126
4.4.2.. Control de concurrencia ....................................................................................................... 128
4.4.3.. Recuperación ............................................................................................................................. 132
4.4.4.. Tipos de copias de seguridad ............................................................................................ 133
4.5.. Integridad en Oracle ........................................................................................................................... 134
4.5.1.. Restricciones .............................................................................................................................. 134
4.5.2.. Control de concurrencia ....................................................................................................... 135
4.5.3.. Copias de seguridad .............................................................................................................. 135
4.6.. La normativa de protección de datos ..................................................................................... 140
4.6.1.. La LOPD ........................................................................................................................................ 140
4.6.2.. El papel del sistema gestor en la LOPD ........................................................................... 141
Resumen ..................................................................................................................................................................... 142
5.. MONITORIZACIÓN Y OPTIMIZACIÓN ..................................................................................................... 147

Objetivos .................................................................................................................................................................... 147
Mapa conceptual .................................................................................................................................................. 148
Glosario ....................................................................................................................................................................... 149
5.1.. Introducción ............................................................................................................................................. 149
5.2.. Monitorización ........................................................................................................................................ 149
5.2.1.. Monitor de rendimiento ........................................................................................................ 150
5.2.2.. Registro de errores ................................................................................................................... 151
5.2.3.. Diccionario de datos .............................................................................................................. 151
Índice
5.3.. Monitorización en Oracle ................................................................................................................ 152

5.3.1.. Monitor de rendimiento ........................................................................................................ 152
5.3.2.. Registro de errores ................................................................................................................... 153
5.4.. Optimización ............................................................................................................................................ 154
5.4.1.. Optimización del entorno ................................................................................................... 154
5.4.2.. Optimización del sistema gestor ....................................................................................... 155
5.4.3.. Optimización de la base de datos ................................................................................... 156
5.4.4.. Creación de índices ................................................................................................................ 158
5.4.5.. Optimización de consultas .................................................................................................. 163
5.4.6.. Herramientas de optimización ........................................................................................... 169
5.5.. Optimización en Oracle .................................................................................................................... 171
5.5.1.. Optimización del sistema gestor ....................................................................................... 171
5.5.2.. Optimización de los objetos de base de datos ......................................................... 172
5.5.3.. Optimización de consultas .................................................................................................. 175
5.5.4.. Herramientas de optimización ........................................................................................... 176
Resumen ..................................................................................................................................................................... 181
6.. AUTOMATIZACIÓN DE TAREAS ................................................................................................................... 187

Objetivos .................................................................................................................................................................... 187
Mapa conceptual .................................................................................................................................................. 188
Glosario ....................................................................................................................................................................... 189
6.1.. Introducción ............................................................................................................................................. 189
6.2.. Rutinas de base de datos ................................................................................................................. 190
6.3.. Rutinas internas en Oracle ............................................................................................................... 192
6.3.1.. Permisos ....................................................................................................................................... 192
6.3.2.. Procedimientos ......................................................................................................................... 193
6.3.3.. Funciones .................................................................................................................................... 195
6.3.4.. Disparadores .............................................................................................................................. 196
6.3.5.. Estructuras de programación .............................................................................................. 197
6.3.6.. Llamadas a funciones y procedimientos ........................................................................ 204
6.4.. Automatización de tareas ................................................................................................................ 205
6.4.1.. Tareas de administración automatizables ...................................................................... 206
6.4.2.. Copias de seguridad .............................................................................................................. 207
6.4.3.. Particionamiento ....................................................................................................................... 207
6.4.4.. Ejecución de estadísticas ..................................................................................................... 210
6.4.5.. Desfragmentación .................................................................................................................... 210
6.4.6.. Reconstrucción de índices ................................................................................................... 211
6.4.7.. Purgado y paso a histórico ................................................................................................... 211
6.5.. Automatización de tareas en Oracle ........................................................................................ 212
6.5.1.. Herramientas del SO ............................................................................................................. 212
6.5.2.. DBMS Scheduler ....................................................................................................................... 212
Resumen ..................................................................................................................................................................... 214
7.. ALTA DISPONIBILIDAD ...................................................................................................................................... 219

Objetivos .................................................................................................................................................................... 219
Mapa conceptual .................................................................................................................................................. 220
Índice
Administración de sistemas gestores de bases de datos 9
Glosario ....................................................................................................................................................................... 220

7.1.. Introducción ............................................................................................................................................. 221
7.2.. Sistemas gestores de bases de datos en la nube ............................................................. 221
7.2.1.. Características ............................................................................................................................ 222
7.2.2.. Ventajas e inconvenientes .................................................................................................... 222
7.3.. Oracle en la nube ................................................................................................................................. 223
7.4.. Sistema de gestión de base de datos distribuidos .......................................................... 224
7.4.3.. Tipos de sistemas gestores distribuidos ......................................................................... 226
7.4.4.. Fragmentación y replicación ................................................................................................ 227
7.5.. Distribución de información en Oracle ................................................................................... 232
7.5.1.. Fragmentación ........................................................................................................................... 232
7.5.2.. Replicación ................................................................................................................................. 234
7.6.. Clúster de servidores ........................................................................................................................... 235
7.7.. El clúster de Oracle .............................................................................................................................. 237
Resumen ..................................................................................................................................................................... 238
PRÁCTICAS GUIADAS
1.1.. Instalación SGBD Oracle

2.1.. Configuración de la conexión
2.2.. Parámetros de configuración
2.3.. Arranque y parada y configuración del almacenamiento
3.1.. Usuarios externos
4.1..Encriptación
4.2..Auditoría
4.3.. Copias de seguridad exp
4.4.. Copias de seguridad datapump
4.5.. Copias de seguridad RMAN
5.1.. Monitorización con EM
5.2.. Monitorización con Developer
5.3.. Optimización de la base de datos
5.4.. Optimización de consultas
6.1.. Ejemplos PLSQL
6.2.. Procedimientos de base de datos
6.3.. Automatización de tareas con SQL Developer
7.1.. Base de datos en la nube
7.2.. Replicación con Oracle Golden Gate
RECURSOS DIGITALES
1.1.. Base de datos transaccional vs data warehouse

1.2.. Arquitectura de Oracle
Índice
ACTIVIDADES PROPUESTAS
1.2.. Elección del SGBD

3.1.. Gestión de usuarios y permisos
3.2.. Esquemas externos
4.1..Encriptación
5.1.. Creación de índices
6.1.. Procedimientos de administracion
6.2.. Automatización de tareas
7.1.. Fragmentación y replicación
7.2.. Distribución de datos en Oracle
Índice
Presentación
Vivimos en una era digital en la que existe la amplia creencia de que todo está en internet. Es
cierto que los sistemas gestores de bases de datos comerciales disponen de documentación, foros
y tutoriales acerca de cómo llevar a cabo cualquier operación empleando las herramientas del
sistema gestor, pero esta información se centra en “cómo hacer”, y no se explica “qué hay que
hacer” o “por qué” hay que hacerlo. El objetivo de este libro es dar respuesta simultáneamente
a esas tres preguntas y aportar los trasfondos y matices que no se encuentran en internet.
El planteamiento de la obra está orientado a la impartición del módulo Administración de
Sistemas Gestores de Bases de Datos del ciclo superior de formación profesional Administra-
ción de Sistemas Informáticos en Red. Además, se han adaptado, actualizado y completado los
contenidos que establece el currículo formativo de dicho módulo para reflejar de forma fiel la
realidad del sector y dar cabida a las nuevas tecnologías empleadas en los sistemas de informa-
ción, dando lugar a un libro muy versátil que puede ser empleado tanto en el ámbito académico
(ciclos de formación profesional o a nivel universitario) como profesional, pues en sus páginas
se reflejan más de diez años de experiencia en el análisis, desarrollo y mantenimiento de siste-
mas de información.
Sus contenidos están secuenciados y organizados de forma lógica siguiendo el hilo conduc-
tor que constituyen las funciones que debe llevar a cabo un administrador de bases de datos a
lo largo del ciclo de vida de un sistema de información:
● La elección del sistema gestor que mejor permita cubrir sus necesidades (sabiendo qué
opciones existen y qué nos aporta cada una de ellas) y su instalación.
● La configuración inicial del sistema, teniendo en cuenta todos los factores que influirán
en su correcto funcionamiento.
● El establecimiento de medidas de seguridad que permitan garantizar la confidenciali-
dad y la integridad de los datos almacenados.
● La monitorización y optimización del sistema.
Presentación
● La automatización de tareas de administración.

● La implementación de medidas destinadas a garantizar la disponibilidad de los datos.
A lo largo de los capítulos del libro se van tratando estas funciones, planteando de manera
genérica su fundamento teórico (qué tareas hay que realizar y por qué) desde una perspectiva
general aplicable a cualquier sistema gestor de base de datos, y contextualizando los conceptos
planteados en las prácticas guiadas (disponibles en los recursos digitales que complementan
al libro) que en forma de actividades, guías o tutoriales, darán respuesta al “cómo hacer”, y faci-
litarán la comprensión de los contenidos planteados aplicándolos a un SGBD concreto: Oracle.
La secuenciación lógica de contenidos, junto con las prácticas guiadas y los ejercicios propuestos,
facilitará que el lector poco versado en este sistema gestor pueda comprender paso a paso su
estructura y funcionamiento, y pueda llevar a cabo sin mayor esfuerzo todo tipo de tareas de
administración por medio del SGBD líder del mercado.
Presentación
1
Instalación del sistema

gestor de bases de datos
Objetivos
3 Conocer los aspectos básicos relacionados con los sistemas gestores de ba-
ses de datos.
3 Comprender las funciones básicas que debe llevar a cabo el administrador
de base de datos.
3 Diferenciar las distintas opciones existentes en el mercado para almacenar
información por medio de un sistema gestor y saber escoger el más adecua-
do para cada caso.
3 Realizar la instalación de un sistema gestor de bases de datos relacional.
Mapa conceptual
ADMINISTRADOR DE BASES DE DATOS
emplea Sistema gestor de bases de datos
Componentes
Funcionalidades
realiza Funciones
Puesta en marcha
Elección del SGBD Factores elección
Contextos utilización
Instalación
Seguridad
Explotación
Administración
Glosario
Administrador de bases de datos (DBA: Database Administrator). Persona o equipo de

personas responsable de asegurar la disponibilidad de los datos de una organización
y el acceso a los mismos de manera óptima.
Base de datos. Conjunto de datos relacionados y almacenados de forma organizada para
su posterior uso.
Consistencia. Mantenimiento de la coherencia de los datos de una base de datos. La
consistencia se garantiza asegurando que las transacciones se lleven a cabo comple-
tamente, o se deshagan todas sus operaciones en caso de que se produzca un fallo en
medio de la transacción.
Capítulo 1
Instalación del sistema gestor de bases de datos 15
Diccionario de datos. Repositorio donde se almacenan los metadatos del sistema gestor
de base de datos, es decir, toda la información acerca de su contenido (bases de datos
existentes, tablas, columnas, usuarios, permisos, etc.).
Integridad. Mantenimiento de la corrección de los datos de una base de datos. La integri-
dad se garantiza asegurando que los datos se ajusten a las reglas y restricciones defini-
das sobre ellos (de dominio, de nulidad, de integridad referencial, de unicidad, etc.).
Not only SQL (NoSQL). Modelo de base de datos alternativo al modelo relacional basado
en la utilización de estructuras de almacenamiento más flexibles que las tablas del
modelo relacional y el uso de sistemas gestores distribuidos y altamente escalables,
capaces de procesar grandes cantidades de información.
Sistema gestor de bases de datos (SGBD). Conjunto de programas que permiten el al-
macenamiento, modificación y extracción de la información en una base de datos,
además de proporcionar herramientas para explotar, administrar y gestionar las bases
de datos.
Transacción. Conjunto de operaciones que se deben ejecutar de manera atómica (como
una sola): o se ejecutan todas o no se ejecutará ninguna.
1.1. Introducción
El objetivo del módulo de administración de sistemas gestores de bases de datos es adquirir las
capacidades necesarias para llevar a cabo el rol de administrador de una base de datos (DBA). El
DBA es la persona (o personas) responsable de gestionar de forma adecuada el almacenamiento
de la información de una organización y optimizar el acceso a la misma.
Para ello, normalmente, hará uso de un sistema gestor de bases de datos (SGBD): el software
que gestiona todo el sistema de almacenamiento de la información.
El DBA será responsable de todo el ciclo de vida del sistema de información: desde la elec-
ción del sistema de almacenamiento que se usará para almacenar la información hasta la gestión
del acceso, la explotación, optimización, monitorización y mantenimiento de este.
En este primer capítulo veremos en detalle la diferencia entre DBA y SGBD, las funciones
de cada uno de ellos, y conoceremos las dos primeras funciones que debe llevar a cabo el DBA:
seleccionar e instalar el SGBD.
1.2. El administrador de bases de datos

La figura del DBA hace referencia a la persona o al equipo de personas responsable de asegurar
la disponibilidad de los datos de una organización y el acceso a los mismos de manera óptima.
Tal como se ha comentado anteriormente, el DBA será responsable de todo el ciclo de vida
del sistema de información, por lo que tendrá que llevar a cabo las siguientes funciones:
Capítulo 1
a) Poner en marcha del sistema:
– Diseñar la arquitectura, desplegar y configurar los sistemas gestores de bases de datos.

– Elegir el sistema gestor más idóneo.
– Instalar y configurar el SGBD y las bases de datos.
b) Establecer mecanismos de seguridad:
– Crear y mantener las cuentas de usuarios y sus permisos.

– Establecer auditorías del sistema para detectar anomalías, intentos de violación de la
seguridad, accesos inadecuados, etc.
– Establecer medidas de seguridad adicionales que permitan garantizar la confiden-
cialidad e integridad de la información.
c) Explotar el SGBD: la explotación del sistema consiste en utilizar las funciones de las
que provee para dar un servicio adecuado a los usuarios. Esto engloba:
– Arrancar y parar el SGBD.

– Crear, dar soporte y gestionar las bases de datos corporativas.
– Hacer copias de seguridad periódicas de los datos y mantenerlos a salvo de la des-
trucción accidental o intencional.
– Monitorizar y optimizar el sistema gestor, los objetos de base de datos y las consul-
tas más habituales.
d) Administrar:
– Colaborar con el administrador del sistema operativo en la gestión de los archivos

de almacenamiento y gestión del espacio en disco ocupado.
– Establecer estándares de uso, políticas de acceso y buenas prácticas de diseño de
bases de datos.
– Diseñar un plan de recuperación para que cuando se presenten problemas, los datos
se pueden restaurar rápidamente.
– Automatizar tareas de administración del sistema gestor.
– Asegurar la disponibilidad de los datos.
1.3. El sistema gestor de bases de datos

Un SGBD es un conjunto de programas que permiten el almacenamiento, la modificación y la
extracción de la información en una base de datos, además de proporcionar herramientas para
explotar, administrar y gestionar las bases de datos.
Antes de aparecer los SGBD, la información se trataba y se gestionaba utilizando sistemas de
gestión de archivos, que iban soportados sobre un sistema operativo. Estos consistían en un con-
junto de programas que definían y manipulaban sus propios datos. Los datos se almacenaban en
archivos y los programas manejaban esos archivos para obtener la información y modificarla si era
preciso. El mayor problema de este tipo de sistemas es la dependencia que se establece entre los
datos y los programas que hacen uso de ellos: si la estructura de los datos de los archivos cambia,
todos los programas que los manejan se deben modificar para adaptarlos a dichos cambios.
Capítulo 1
En estos sistemas de gestión de archivos, la definición de los datos se encuentra codificada

dentro de los programas de aplicación en lugar de almacenarse de forma independiente, y ade-
más son los programas quienes deben controlar el acceso y la manipulación de los datos.
Los sistemas gestores de bases de datos aparecen con el objetivo de solucionar todos estos
problemas que presentaban los sistemas de ficheros y añadir nuevas funcionalidades adicionales.
1.3.1. Funciones del sistema gestor de bases de datos

Las principales funciones que debe proveer un SGBD son las siguientes:
a) Definición de datos: mediante el lenguaje de definición de datos (DDL) el SGBD per-

mite describir y definir los esquemas de la base de datos. Este lenguaje debe permitir
la creación de objetos y su descripción, la modificación y el borrado de los objetos
existentes. Un DDL está compuesto por un conjunto de comandos que actúan sobre
los objetos.
Toma nota
Toda la información referente a los objetos que se crean en un sistema gestor de base de
datos se almacenan en un repositorio denominado diccionario de datos.
b) Manipulación de datos: la función de manipulación de datos se encarga de todas las ope-

raciones de gestión de los datos de la base de datos. Esta función se hace con la ayuda
del lenguaje de manipulación de datos (DML), que está compuesto por un conjunto
de comandos que permiten la consulta o actualización (inserción, modificación y bo-
rrado) de los datos de una base de datos. Cada SGBD tiene sus propios DDL y DML,
que funcionan de forma diferente. Por ejemplo, los modelos en red y jerárquicos uti-
lizan lenguajes de manipulación de datos procedimentales (es decir, el programador
debe indicar el camino a seguir para acceder a los datos solicitados), mientras que en el
modelo relacional se utiliza un lenguaje declarativo, SQL (Structured Query Langua-
ge), con el que únicamente es necesario indicar qué datos se quieren, y no la forma de
obtenerlos.
c) Seguridad e integridad de los datos: garantizar la coherencia de los datos, por medio de la
protección contra accesos malintencionados y los fallos. Los accesos malintencionados
se suelen evitar por medio de la autentificación de usuarios y la asignación de permisos
(de modo que solo los usuarios registrados puedan efectuar sobre el SGBD las opera-
ciones para las cuales están autorizados), la definición de esquemas externos y la protec-
ción física de los datos (encriptación). Con respecto a los fallos causados por manipu-
laciones incorrectas, o accidentes lógicos o físicos, los SGBD disponen de herramientas
para garantizar la integridad de los datos y su consistencia ante accesos concurrentes, y
suelen disponer de utilidades para la recuperación de los datos después de un fallo.
d) Gestión de acceso concurrente: los SGBD deben ser capaces de habilitar el acceso a los da-
tos simultáneamente para gran número de usuarios asegurando la consistencia de los
datos. La gestión de accesos concurrentes debe asegurar que la ejecución simultánea
de transacciones por parte de diferentes usuarios da el mismo resultado que una
Capítulo 1
ejecución secuencial de las misas. Esto se consigue habitualmente por medio de la

utilización de bloqueos. Esta función es muy importante en los sistemas relacionales,
pero no en todos los SGBD. En los sistemas de bases de datos NoSQL, esta caracte-
rística no solo no es prioritaria sino que algunos ni siquiera la implementan, ya que
el objetivo principal de estos sistemas se centra en el rendimiento y la disponibilidad
de datos en tiempo real, para lo que sacrifica características como la atomicidad o la
consistencia.
e) Gestión de las transacciones: una transacción se define como una unidad lógica de trata-
miento (conjunto de órdenes) que aplicada a un estado consistente de la base de datos
la deja, de nuevo, en un estado consistente, después de hacer las modificaciones. Una
transacción solo se puede ejecutar completamente o ser anulada. El gestor de transac-
ciones debe garantizar que en caso de que se produzca algún error en alguna de las
operaciones de una transacción se deshagan los cambios realizados por las operaciones
anteriores.
f) Auditoría: para el administrador de la base de datos es muy importante conocer quien
accede a la base de datos y que operaciones realiza, información que debe proporcionar
el SGBD.
g) Garantizar un tiempo de respuesta idóneo: debe buscar la forma de ejecutar todas las ope-
raciones de los usuarios de la forma más rápida y eficiente posible.
h) Independencia física y lógica: la forma de almacenar los datos no debe afectar a cómo se
ha definido su estructura (independencia física), y la modificación de su estructura no
debe afectar a cómo perciben los datos los usuarios o aplicaciones que acceden a ellos
(independencia lógica). La independencia física y lógica se consigue por medio de la
abstracción de información. La arquitectura de las BBDD creadas por medio de los siste-
mas gestores de bases de datos relacionales sigue el modelo en tres niveles definido por
ANSI-SPARC, que permite garantizar la abstracción de la información:
Usuarios
vista vista vista vista vista vista vista vista Esquemas

externos
vista vista vista vista vista
Esquema
conceptual
tabla tabla tabla tabla
Esquema
interno
disco disco disco disco disco
Figura 1.1
Arquitectura ANSI-SPARC de bases de datos.
Capítulo 1
En este modelo se definen tres niveles o capas de abstracción para una base de da-
tos, que son independientes entre ellos:
– el nivel interno (indica cómo se almacenará la información, y se define por medio

del esquema interno de la base de datos);
– el nivel conceptual (determina cómo se estructurará la información, y se define por
medio del esquema conceptual de la base de datos);
– el nivel externo (que estará compuesto de esquemas externos que determinarán
cómo se mostrará la información a los usuarios).
La estructuración de la arquitectura de las bases de datos en estos tres niveles per-

mite abstraer al usuario los detalles acerca de cómo se organiza la información de la
base de datos y cómo se almacena, permitiendo que un cambio en la estructura de
la base de datos (la creación de un campo nuevo en una tabla, por ejemplo) no afecte
a la forma de ver los datos del usuario, y que un cambio en la forma de almacenamiento
de los datos (crear un índice o cambiar los datos a otro disco) no afecte a su estructura
(la estructura de la tabla será la misma aunque cree un índice nuevo).
i) Monitorización del sistema gestor de bases de datos: el sistema gestor debe disponer de
herramientas que permitan comprobar qué está pasando internamente en el sistema,
saber cómo se están empleando los recursos, detectar errores o problemas que afecten
al rendimiento y elaborar estadísticas de uso de este.
j) Conectividad: los sistemas basados en una arquitectura cliente/servidor deben proveer
herramientas de conectividad que permitan a los clientes (usuarios o aplicaciones) co-
nectarse al sistema gestor para acceder a los datos.
k) Respaldo y recuperación: incorporan herramientas para la realización de copias de seguri-
dad y restauración, para permitir la recuperación ante caídas del sistema.
1.3.2. Componentes de un sistema gestor de bases de datos

Cada SGBD implementará una arquitectura propia, pero las funciones que deben realizar son
muy similares, por lo que normalmente tienen una serie de componentes comunes:
A) Procesador de consultas

Es el componente fundamental de un SGBD. Transforma las consultas en lenguaje de base
de datos a un conjunto de instrucciones de bajo nivel que se dirigen al gestor de la base de
datos. El lenguaje de base de datos más habitual en las bases de datos relacionales es SQL, que
tiene cuatro componentes:
● DDL (lenguaje de definición de datos: create table, alter table…).

● DML (lenguaje de manipulación de datos: select, insert, update).
● DCL (lenguaje de control de datos: grant, revoke).
● TCL (lenguaje de control de transacciones: commit, rollback).
● Lenguajes de 4.º generación: lenguajes de programación que permiten definir progra-
mas sobre el SGBD.
Capítulo 1
B) Gestor de la base de datos

Es el elemento principal, ya que es el encargado de recibir las peticiones de los usuarios y
procesarlas. Acepta consultas y examina los esquemas externo y conceptual de la base de datos
para determinar qué registros se requieren para satisfacer la petición. Después, enviará las pe-
ticiones necesarias al gestor de ficheros para que le remita los datos solicitados. El gestor de la
base de datos suele estar formado por los siguientes módulos:
Cuadro 1.1
Módulos habituales del gestor de la base de datos
Control de Comprueba que el usuario tiene los permisos necesarios para llevar a cabo
autorización la operación que solicita.
Procesador Interpreta los comandos recibidos.
de comandos
Control Cuando una operación cambia los datos de la base de datos, este módulo debe
de la comprobar que la operación que se ha de realizar satisface todas las restricciones
integridad de integridad definidas (unicidad de las claves primarias, referencias de las claves
foráneas, nulidad, etc.).
Optimizador Determina la estrategia óptima para la ejecución de las consultas.
de consultas
Gestor de Encargado de garantizar la atomicidad de las transacciones.
transacciones
Planificador Responsable de asegurar que las operaciones que se realizan concurrentemente
(scheduler) sobre la base de datos se llevan a cabo sin conflictos.
Gestor de Garantiza que la base de datos permanece en un estado consistente en caso
recuperación de que se produzca algún fallo.
Gestor Responsable de transferir los datos entre memoria principal y los dispositivos
de buffers de almacenamiento secundario.
C) Gestor de ficheros

Encargado de gestionar el acceso físico a los ficheros en disco donde se almacena la infor-
mación de las bases de datos. Este gestor establece y mantiene la lista de estructuras e índices
definidos en el esquema interno. El gestor de ficheros no realiza directamente la entrada y salida
de datos, lo que hace es pasar la petición a los métodos de acceso del sistema operativo que se
encargan de leer o escribir los datos en el buffer del sistema.
D) Interfaces externas

Que permitirán a los usuarios y aplicaciones conectarse al SGBD en ambos sentidos (E/S)
y hacer uso de sus funcionalidades. Estas interfaces se implementan por medio de drivers o
Capítulo 1
conectores que contienen una API (una interfaz de programación) que pueden invocar los
clientes que se quieren conectar al SGBD. Los conectores más habituales son ODBC y JDBC.
La norma ODBC es un estándar de acceso a bases de datos cuyo objetivo es proporcionar
independencia entre los sistemas de bases de datos y los programas de aplicación por medio de
un API que se encarga de realizar toda la comunicación. La norma JDBC es también una API
pero en este caso solamente es válida para los programas Java. Además de estos drivers genéricos
para las aplicaciones existen numerosos drivers específicos de cada sistema gestor.
E) Preprocesador del lenguaje de manipulación de datos

Muchas aplicaciones contienen sentencias SQL embebidas en su código (escrito en algún
lenguaje de programación de alto nivel: java, python, php, etc.). Cuando las aplicaciones envían
sus peticiones al sistema gestor de base de datos, este emplea el preprocesador del DML para in-
terpretar estas peticiones y convertirlas a sentencias SQL que entienda el procesador de consultas.
F) Compilador del lenguaje de definición de datos

Convierte las sentencias del DDL en un conjunto de tablas que contienen metadatos. Estas
tablas se almacenan en el diccionario de datos. El diccionario de datos almacena los esquemas
de las distintas bases de datos del gestor. Normalmente este almacenamiento se realiza en una
base de datos propia del sistema, de forma que se puede consultar la información del esquema
por medio de consultas SQL.
G) Gestor del diccionario

El diccionario de datos es uno de los elementos fundamentales del SGBD, ya que almacena
toda la información referente a la estructura de las bases de datos y su almacenamiento. Nor-
malmente se implementa por medio de una base de datos interna que contendrá una tabla de
bases de datos, otra de tablas, de índices, de restricciones de integridad, de columnas, etc.,
de forma que si por ejemplo creamos una tabla con tres campos (de los cuales uno de ellos es la
clave), en el diccionario de datos se insertará un registro en la tabla de “tablas” para dar de alta
la nueva tabla que hemos creado, se insertarán tres registros en la tabla de “columnas” (uno por
cada campo de la tabla), y se insertará otro registro en la tabla de “índices” correspondiente al
índice que se creara por la clave primaria.
El gestor del diccionario es el elemento encargado de realizar todas estas operaciones: con-
trola los accesos al diccionario de datos y se encarga de mantenerlo.
Ten en cuenta
Los sistemas monousuario tienen una arquitectura mucho más sencilla, ya que no requieren pro-
cesar peticiones de varios usuarios, por lo que muchos de estos componentes no son necesarios.
Capítulo 1
Cuando trabajamos con sistemas gestores de bases de datos distribuidas (SGBDD), el sis-
tema gestor deberá tener un conocimiento tanto a nivel local del contenido de cada base de
datos, como a nivel global (qué información está en cada nodo). Para ello implementan una
arquitectura cliente/servidor en 3 niveles: las peticiones de los clientes llegarán a un servidor
encargado de determinar dónde se encuentra la información solicitada, y será este quien realice
la petición de información al servidor local.
Esta arquitectura requiere, por tanto, de algunos componentes adicionales:
● Componente de comunicación: es el software que permite que todos los nodos se comuni-
quen entre sí. Contiene información acerca de nodos y enlaces.
● Catálogo global del sistema: responsable de interpretar las peticiones de información y
determinar en qué lugar se ubica cada uno de los datos solicitados.
Esta arquitectura es la utilizada también mayormente por los sistemas NoSQL (con varian-
tes particulares en cada implementación), ya que no dejan de ser sistemas distribuidos. Estos
sistemas presentan particularidades adicionales, ya que son sistemas orientados a maximizar el
rendimiento de las consultas de información sobre la base de datos, para lo que distribuyen tanto
los datos como su procesamiento a través de los nodos de la red, por medio del uso de la técnica
map/reduce (una función map distribuirá la información entre los distintos nodos en base a un
campo clave o un patrón común, y una función reduce unirá los datos de cada clave o patrón en
un resultado común) y la utilización de sistemas de ficheros especialmente diseñados para dis-
tribuir la información a través de la red (el más usado es HDFS: hadoop distributed file system).
1.4. Factores de elección del sistema gestor de bases de datos

Antes de proceder a la instalación del SGBD será necesario determinar qué tipo de SGBD será
más adecuado para nuestra organización.
De cara a tomar estas decisiones, hay que tener en cuenta varios factores:
● El tipo de SGBD que necesitaremos: en función del número de usuarios, por la locali-
zación de la información y por su estructura.
● La arquitectura del SGBD y la conectividad que necesitaremos (si necesitamos que la
base de datos sea accesible desde internet, una intranet o incluso si bastaría con un solo
equipo de acceso).
● Los recursos disponibles y la política de empresa: el coste del SGBD y la disponibilidad de
recursos de la organización (hardware disponible, costes de licencias que puede asumir la
organización, etc.) puede limitar el margen de maniobra a la hora de seleccionar el SGBD.
Del mismo modo, si la empresa tiene una política de impulso de software libre o acuerdos
con empresas concretas de software puede limitar el número de opciones disponibles.
● El tipo de bases de datos que vayamos a crear en ese SGBD (y por tanto su tamaño): a
medida que se incrementan los volúmenes de información almacenados, crece conside-
rablemente la complejidad del sistema que necesitamos para almacenar esa información.
● Requisitos del sistema: por ejemplo el número de conexiones simultáneas que debe
soportar el sistema gestor suele ser uno de los requisitos claves en la elección, ya que un
gran número de conexiones simultáneas implica sistemas gestores con grandes capaci-
dades de trabajo concurrente y pocos sistemas serían capaces de aceptarlo.
Capítulo 1
1.4.1. Tipos de sistemas gestores de bases de datos
Existen diversas clasificaciones de los sistemas gestores atendiendo a diferentes características:
A) Por el número de usuarios

1. Monousuario: sistemas de un solo usuario. Estos sistemas son muy básicos y carecen de
muchas de las posibilidades de los sistemas multiusuario (monitorización, auditoría,
gestión de copias de seguridad, etc.), pero ofrecen algunas ventajas como una mayor
seguridad de los datos y no necesitan realizar un control de concurrencia.
2. Multiusuario: un sistema multiusuario se encarga de dar servicio a un gran número de
usuarios que están conectados al sistema a través de terminales. Habitualmente estos
sistemas disponen de algún mecanismo para priorizar tareas y controlar el uso que los
usuarios hacen del sistema, pudiendo limitarlo para que no copen los recursos.
Actividad propuesta 1.1
Investiga cuáles son los sistemas gestores de datos más utilizados y localiza entre
ellos dos sistemas monousuario y dos sistemas multiusuario.
¿Para qué se usan principalmente unos y otros?
B) Por la localización de la información

1. Centralizados: los sistemas de bases de datos centralizados son aquellos que se ejecutan
en un único sistema informático, que gestiona todos los recursos. Esto no implica que
sea una máquina física, sino que aunque físicamente el sistema conste de un clúster
de servidores, lógicamente se verá como un solo servidor. Estos sistemas tienen varias
ventajas: evitan la redundancia (normalmente en los sistemas distribuidos cada nodo
maneja sus propios maestros locales), evitan inconsistencias (al tener una sola versión
de los datos), es más sencillo aplicar restricciones de seguridad. Entre sus inconve-
nientes: las prestaciones del servidor central tienen que ser mucho más elevadas que
en servidores distribuidos, por lo que económicamente suele ser más costoso, en caso
de fallo del sistema no existe posibilidad de acceder a los datos, y son poco escalables.
2. Distribuidos: un sistema de bases de datos distribuido es un sistema en el cual múltiples
nodos de bases de datos están ligados por un sistema de comunicaciones, de tal forma
que un usuario en cualquier nodo puede acceder a los datos en cualquier parte de la red
exactamente como si los datos estuvieran almacenados en su propio nodo. Cada nodo
es autónomo, y no hay dependencia de un nodo central. La operación de los nodos es
continua (no es necesario parar los nodos para realizar operaciones como añadir nuevos
nodos a la red o instalar nuevas versiones), y existe una independencia de localización
(los usuarios no tienen que saber dónde están almacenados los datos a los que están
accediendo). Entre las ventajas de los sistemas distribuidos: son más adaptables a una
Capítulo 1
estructura organizacional, tienen autonomía local (cada departamento controla sus pro-
pios datos), tienen mayor disponibilidad (no dependen de un solo nodo), son sistemas
más baratos que los centralizados y son fácilmente escalables.
C) Por su estructura

1. Sistemas navegacionales
A mediados de los 60 fueron apareciendo los primeros sistemas de bases de datos de propó-
sito general. En 1971 se definió el estándar de CODASYL (el grupo responsable de la creación
y estandarización de COBOL), y en breve aparecieron algunos productos basados en esta línea.
Este estándar se implementó tanto en sistemas en árbol como en sistemas en red, y evolucionó
incorporando incluso un sistema de consulta, pero todos estos sistemas resultaban muy comple-
jos y requerían de mucho esfuerzo y práctica para producir aplicaciones útiles, además de que la
forma de acceder a la información no era uniforme (no es lo mismo acceder al nodo raíz de un
árbol que a un nodo hoja, por ejemplo), lo que complicaba considerablemente la recuperación
de información.
¿Sabías que...?
La estrategia de CODASYL estaba basada en la navegación manual por un conjunto de datos

enlazados en red. Cuando se arrancaba la base de datos, el programa devolvía un enlace al pri-
mer registro de la base de datos, el cual a su vez contenía punteros a otros datos. Para encontrar
un registro concreto el programador debía ir siguiendo punteros hasta llegar al registro buscado.
2. Sistemas relacionales
A principios de los años setenta surge el modelo relacional, planteado por Edgar Codd. La
principal ventaja de este modelo respecto a los anteriores es la simplicidad, tanto en la repre-
sentación de la información (toda la información se almacena en tablas de registros de tamaño
fijo relacionadas entre ellas) como en su tratamiento (el acceso a las tablas es uniforme: a todas
las tablas se accederá del mismo modo). Este modelo permitía solucionar los dos principales
problemas de los modelos anteriores: la compleja mantenibilidad de las relaciones (ya que
las relaciones se implementarán como nuevas tablas) y la posibilidad de definir restricciones
que aseguren la integridad de los datos (ya no tendrá que hacerlo el programador a mano),
lo que facilitó que los sistemas relacionales tuviesen una gran aceptación en el mercado y reem
plazasen a los navegacionales.
A lo largo de la década de los setenta se crearon varias soluciones basadas en el modelo
propuesto por Codd, pero estos sistemas tenían un problema: no estaban preparados para la
consulta de la información almacenada de forma sencilla (los lenguajes tradicionales no estaban
pensados para recuperar la información en un solo registro). Para solventar este problema Codd
propuso una solución basada en un lenguaje orientado a conjuntos, que más tarde cristalizaría
en el SQL.
Capítulo 1
Entre los sistemas gestores más importantes de este tipo destacan Oracle, SQL Server, Ac-
cess, PostgreSQL o MySQL.
3. Sistemas orientados a objetos
Con el auge de la programación orientada a objetos aparece el modelo orientado a objetos.

El principal problema de utilizar sistemas relacionales para almacenar objetos es que los objetos
no se pueden almacenar directamente en un sistema gestor relacional (que solamente permite
representar la información por medio de tablas), lo que obliga a incorporar una capa de software
intermedia entre la aplicación y la base de datos que realizase la conversión de objetos a tablas
y viceversa. Inicialmente esta capa debía crearse a mano, lo cual incorporaba una complejidad
adicional a las aplicaciones y reducía la productividad en su desarrollo. En este contexto apa-
recieron los sistemas orientados a objetos, que permiten hacer persistentes los objetos en base
de datos sin necesidad de transformaciones intermedias, además de establecer relaciones entre
objetos y atributos, en lugar de hacerlo entre campos individuales.
Estos sistemas, sin embargo, se encontraron con dos problemas: por un lado, la simplicidad
de representación de los sistemas relacionales (además de su madurez) hacía que su rendimiento
fuese mucho mayor que el de los sistemas orientados a objetos, y por otro lado, la aparición de
herramientas de mapeo objeto-relacional, como Hibernate, que permitían realizar la conver-
sión de objeto a tabla de forma prácticamente automática, lo que provocó que la presencia de
este tipo de sistemas en el mercado sea prácticamente testimonial.
Son de este tipo los sistemas gestores ObjecStore y O2.
4. Sistemas NoSQL
Las bases de datos relacionales tradicionales presentan dos grandes problemas a la hora de
dar respuesta a los nuevos requisitos de almacenamiento de información existentes a día de hoy:
● Poca flexibilidad de representación: todos los elementos representados en una tabla de-
ben tener necesariamente el mismo número de filas y columnas, lo cual puede ser muy
ineficiente para representar información no estructurada.
● Poca escalabilidad: a pesar de que un SGBD relacional se puede implementar por medio
de un clúster al que se le pueden ir añadiendo equipos y discos según las necesidades,
este tiene un límite finito en cuanto a sus posibilidades de crecimiento (SQL Server no
soporta más de 524 272 TB, y Oracle 2047 PB), lo que no serviría para grandes aplica-
ciones de internet (redes sociales, buscadores, etc.), que generan enormes cantidades de
información y requieren respuesta inmediata.
Los sistemas NoSQL surgen fundamentalmente para paliar estas dos carencias: estos sistemas
no requieren por lo general esquemas fijos y están diseñadas para escalar horizontalmente tanto
como sea necesario. Esto lo hacen de la siguiente manera:
a) Distribución de los datos: en lugar de emplear servidores de gran capacidad que puedan mo-
ver un SGBD muy complejo, están compuestos de múltiples nodos entre los que se dis-
tribuye tanto la información como el procesamiento de la misma. Si hay que incrementar
el rendimiento o la capacidad de almacenamiento, bastaría con añadir más nodos a la red.
Capítulo 1
Servidor
Figura 1.2
Clientes Arquitectura genérica
de sistemas NoSQL.
b) Manejan datos no estructurados. Los datos con los que trabajan no tienen una estructura
fija, y el concepto de relación es más cercano al existente en orientación a objetos que
al utilizado en el modelo relacional, lo que las hace más adecuadas para almacenar bases
de datos con estructura más bien simple (con escasas relaciones y reglas): tweets de Twi-
tter, estadísticas en tiempo real, streaming de vídeo, conexiones a servidores remotos,
logs de aplicaciones,… datos simples, con distintas estructuras, de los que apenas se usan
unos pocos valores clave, pero que llegan a gran velocidad.
c) Evitan las operaciones join almacenando datos desnormalizados. En estos sistemas prima
la velocidad de respuesta y sobra capacidad de almacenamiento, así que si dos datos se
suelen consultar juntos, pues se guardan juntos (aunque ello suponga incorporar infor-
mación redundante).
d) Su base teórica se basa en el teorema de CAP (consistencia, disponibilidad y tolerancia
a fallos), que viene a decir que el sistema fomentará la disponibilidad aunque ello im-
plique asumir que puntualmente la consistencia de los datos no esté garantizada (puede
suceder que envíes una foto por Whatsapp y luego un texto y que el texto se entregue
antes que la foto: lo importante es que lleguen lo antes posible, y si temporalmente el
orden de visualización es incorrecto, no pasa nada).
e) Estos sistemas están basados en el uso de la técnica “Map reduce”, basada principalmen-
te en la división del trabajo entre los nodos de la red, que funcionan como un sistema
homogéneo (se distribuye tanto la información como el procesamiento de la misma).
Los nodos realizan mucho trabajo en memoria, y poco en disco, por lo que son muy
rápidos, aunque son menos consistentes que los sistemas relacionales.
Ten en cuenta
Su nombre (NoSQL) no significa que no usen SQL, sino “Not Only SQL”, que se traduciría
por “no solo SQL”. De hecho, varios de los principales sistemas NoSQL sí permiten utilizar
SQL como lenguaje de consulta de información, aunque la mayoría suelen usar lenguajes de
consulta propios o derivados de SQL.
Capítulo 1
Su principal desventaja es que al no poder establecer relaciones y reglas complejas sobre los
datos, no sirven para almacenar bases de datos complejas o donde se desee realizar tareas como
ordenar los datos en base a distintas claves o realizar búsquedas avanzadas en base a múltiples
criterios. Son sistemas pensados para entornos donde ese tipo de tareas de gestión de informa-
ción no son críticas, como las redes sociales o los sistemas big data en general, donde las cosas
solo se suelen ordenar en base a la fecha y hora.
Las bases de datos NoSQL se usan habitualmente para almacenar datos de aplicaciones que
requieren realizar muchas operaciones de lectura y escritura simultaneas, que generan datos
a gran velocidad, que emplean datos no estructurados o que necesitan representar relaciones
complejas que se establecen entre los datos.
Existen 4 tipos de bases de datos NoSQL:
1. Clave/valor: los datos se almacenan en forma de pares (clave, valor), y se indexan siempre
por el campo clave, de forma que realizar una búsqueda por la clave será muy eficiente.
Normalmente estos pares se almacenan en grupos de pares, por lo que la misma clave
puede estar repetida en distintas agrupaciones.
Ejemplo
El sistema de almacenamiento de la configuración de usuario de Google podría implementarse

por medio de un sistema clave/valor, almacenando la información de la siguiente manera:
Favoritos: {‘usuario1’:[’www.as.com’,’www.marca.com’], ’usuario2’:[‘www.elpais.com’,

’www.abc.es’, ’www.elconfidencial.es’]}
Idioma:{‘usuario1’:’ES’,’usuario2’:’ES’,’usuario3’,’CA’}
Marcadores:{‘usuario1’:[‘mismarcadores.com’], ’usuario3’:[‘www.sport.es’, ’www.elpais.com’]]}
Si el usuario1 iniciase sesión en un equipo cualquiera, consultaría en su base de datos

de configuración de usuarios toda la información correspondiente al usuario1 (al ser la clave,
estarían todos los datos indexados en base a ese campo) y recuperaría rápidamente sus favo-
ritos, su idioma, sus marcadores, sus contraseñas, y cualquier otra información que estuviese
asociada a dicho usuario.
Las bases de datos de este tipo más usadas son:
– Redis: es una base de datos que trabaja con pares clave/valor almacenados en me-
moria en forma de tablas hash, aunque permite también hacerlos persistentes. Está
liberado bajo una licencia de código abierto BSD.
– Amazon DynamoDB: base de datos con licencia propietaria desarrollada por Ama-
zon. Surgió con el objetivo de gestionar la enorme cantidad de transacciones de
esta empresa y pasó a ser una de las bases de su negocio en la nube.
– Microsoft Azure Cosmos DB: servicio de base de datos NoSQL en la nube de Micro-
soft, especialmente indicado para aplicaciones que realizan multitud de operaciones
de lectura y escritura simultáneas: registro de información de dispositivos de IOT
(internet de las cosas), compra online o análisis de datos en tiempo real.
Capítulo 1
– Memcached: empleado por sitios web como YouTube, Twitter, Reddit o Facebook
para almacenar datos en caché u objetos en memoria RAM para reducir los accesos
a orígenes de datos externos.
2. Columnares: las bases de datos columnares almacenan la información en columnas en

lugar de almacenarlas por filas como hacen las bases de datos relacionales. Estas bases de
datos están basadas en las de clave/valor, ya que los datos no se agrupan en tablas, sino
que se guardan como conjuntos de pares (clave,valor), cada uno de ellos asociado a una
columna de la tabla.
Ejemplo
Conceptualmente, el funcionamiento de las bases de datos columnares sería el siguiente. Pon-

gamos que tenemos una tabla de colaboradores en la que guardamos los perfiles de redes
sociales de cada colaborador:
Figura 1.3
Ejemplo base de datos
NoSQL columnar.
La clave de la tabla sería el nombre, y cada colaborador puede tener o no usuarios en las
distintas redes sociales.
Si almacenásemos esta tabla en una base de datos columnar, cada una de las columnas se
guardaría como un conjunto de pares (clave, valor), de la siguiente manera:
Twitter: { ‘Pedro’:’p.sanchez’, ‘Natalia’:’nati04’, ‘Rodrigo’:’rodrg.rg’}

Facebook: {‘Pedro’:’p.sanchez’}
Google: {‘Natalia’:’natalia.blanco’}
El valor de cada fila solo se guarda si hay datos, y si consultamos toda la información de un
usuario concreto, la consulta se realizará en paralelo en todas las columnas a través de la clave,
lo cual es muy rápido y por eso son muy adecuadas para manejar información no estructurada.
Las bases de datos columnares más empleadas son:
– Apache Cassandra. Con licencia Apache (de código abierto) es la más popular y de
contrastada potencia ya que es de código abierto. Se desarrolló inicialmente por Fa-
cebook. Los datos se almacenan en tuplas sin relaciones de integridad (una variante
de datos clave-valor, donde hay varios valores por cada clave). Presume, además, de
Capítulo 1
un crecimiento exponencial en estos últimos tiempos y de ser el motor de base de

datos de servicios como Twitter o Netflix.
– Google Cloud BigTable. Base de datos propietaria utilizada para muchos de los
servicios de almacenamiento de Google. Los datos se almacenan en una estructura
multidimensional de tres claves (fila, columna y fecha) que puede ser particionada.
El sistema se ejecuta sobre un sistema de archivos distribuido propio de Google: el
Google File System.
– HBase. Evolución de Big Table desarrollada por Apache. Tiene licencia Apache, de
código abierto y permite más opciones de configuración que BigTable, que delega
en el propio sistema muchas opciones de configuración e impide personalizarlas.
– Vertica: la solución de HP. Integra tanto el sistema gestor como herramientas ana-
líticas para el procesamiento de la información.
3. Documentales: las bases de datos documentales almacenan la información en forma de

documentos, representados en formatos como XML, JSON o BSON (un JSON bina-
rio). Cuando se crea un documento, el sistema le asigna un código interno único que
será la clave a través de la cual se indexarán los documentos. Las bases de datos nativas
XML son un caso particular de bases de datos documentales en los que la información
se almacena utilizando XML.
Ejemplo
La tabla de colaboradores empleada en el ejemplo anterior, se definiría en una base de datos
documental por medio de una colección de documentos “colaborador”, que tendría la siguien-
te estructura:
{
‘nombre’:’Pedro’,
‘twitter’:’p.sanchez’,
‘facebook’:’p.sanchez’
},
{
‘nombre’:’Natalia’,
‘twitter’:’nati04’,
‘google:’natalia.blanco’
},
{
‘nombre’:’Rodrigo’,
‘twitter’:’rodrg.rg’
}
Algunas bases de datos comerciales documentales son:
– MongoDB. La más popular de las bases de datos NoSQL. Está publicada bajo una
licencia GNU, aunque dispone también de versiones comerciales. Emplea docu-
mentos en formato BSON (son documentos JSON pero almacenados en binario).
Capítulo 1
La emplean numerosas compañías de todo tipo: Telefónica, Google, Nokia, Adobe,

Cisco, Facebook, PayPal…
– Elasticsearch. Más que un servidor de base de datos es un servidor de búsqueda de
textos en documentos, basado en Apache Lucene (publicado bajo una licencia Apa-
che de código abierto). Trabaja también con documentos JSON. Entre sus clientes
se encuentran ING, Telefónica, eDreams, Orange…
– Apache CouchDB. Dentro de la familia Apache (y usando licencia de código abierto
Apache) es la base de datos NoSQL orientada a documentos. Usa formato JSON
para los datos y las consultas se realizan mediante JavaScript. Es utilizado por Ubun-
tu, la BBC, Meebo…
– Amazon SimpleDB. Proporcionada de forma comercial por Amazon (es parte de AWS,
Amazon Web Services), se utiliza para el almacenamiento extensivo de datos en la nube.
4. Basados en grafos: almacenan la información en forma de grafos o red de nodos, que

permiten relacionar los datos a través de enlaces entre ellos a los que se les puede asignar
un peso. Esto es muy adecuado para representar vinculaciones, como las existentes entre
los usuarios de las redes sociales o entre puntos geográficos (con pesos indicativos de
la distancia entre ellos o el tiempo necesario para llegar de uno a otro, como las que se
pueden utilizar en Google Maps).
Comentario
publica like
Pedro conoce Natalia publica Comentario
conoce pertenece
Figura 1.4
Rodrigo pertenece Grupo Ejemplo base de datos
NoSQL de grafos.
La base de datos de grafos más empleada es Neo4j, que es un sistema de base de datos
de software libre empleado especialmente para representar redes (de computadoras, de
usuarios, etc.), recomendaciones de películas, etc. La base de datos NoSQL de Microsoft
(Azure Cosmos DB) también permite representar la información por medio de grafos.
1.4.2. Arquitectura del sistema gestor de base de datos

Es importante no confundir la arquitectura del SGBD con la arquitectura de las bases de datos que
contiene (que suele ser una arquitectura ANSI/SPARC en tres niveles). Cada SGBD tiene su propia
arquitectura y componentes, pero fundamentalmente podemos hablar de las siguientes arquitecturas:
Capítulo 1
A) Sistema gestor de bases de datos monocapa

El sistema gestor está instalado en la misma máquina donde se conecta el usuario. Son sis-
temas monousuario y poco pesados, ya que no necesitan gestionar conexiones concurrentes
de múltiples usuarios, transacciones, auditorías ni otras operaciones que son necesarias cuando
tenemos múltiples usuarios.
Es un modelo que solo se utiliza con bases de datos pequeñas y poca cantidad de conexio-
nes, como Access o Base.
Figura 1.5
Arquitectura
monocapa. Usuario Cliente Base de datos
B) Sistema gestor de bases de datos de dos capas

Los SGBD de dos capas emplean una arquitectura cliente/servidor. En el servidor se ejecu-
tará el SGBD y tendrá acceso a las bases de datos (no tienen que estar necesariamente ubicadas
en el propio servidor, pueden estar en discos o cabinas externas de almacenamiento accesibles
a través de la red). El SGBD será el que gestione las conexiones de los clientes y les facilite el
acceso a los datos de las bases de datos.
El servidor puede ser una única máquina o estar compuesto de un clúster de varios servi-
dores actuando conjuntamente como un solo componente lógico.
En un SGBD de dos capas, el SGBD además de guardar la información almacena la lógica
de negocio: todas las aplicaciones acceden directamente al SGBD, por lo que para garantizar
que las operaciones de modificación de datos realizan las modificaciones conforme a las reglas
definidas por la organización, se suelen implementar estas reglas dentro del propio SGBD, en
forma de procedimientos almacenados.
Por ejemplo: si cuando creo un cliente en la tabla de CLIENTES, quiero que se añada un
registro en la tabla de DESCUENTOS para aplicarle un descuento por alta nueva, tendría que
implementar el proceso de inserción del cliente por medio de un procedimiento y las aplica-
ciones tendrían que llamar a este procedimiento para dar de alta un cliente (no podrían hacer
un insert en la tabla de clientes directamente). Así garantizo que todas las aplicaciones respeten
la lógica de negocio.
Usuario Cliente Servidor

Figura 1.6
Arquitectura cliente/servidor.
Capítulo 1
C) Sistema gestor de bases de datos de tres o más capas

La incorporación de la lógica del negocio en un cliente/servidor en dos capas descrita an-
teriormente tiene un problema: todo el procesamiento de las operaciones que se deben llevar a
cabo en el sistema gestor corre a cargo del propio sistema gestor, que acaba destinando gran parte
de sus recursos a procesar este tipo de peticiones, en lugar de dedicarlos única y exclusivamente a
garantizar el acceso óptimo a los datos, por lo que se acaba convirtiendo en un cuello de botella.
La solución a este problema pasa por incorporar un servidor web intermedio entre el
cliente y el servidor, en una arquitectura en tres capas, de forma que todo el procesamiento de
la lógica de negocio se delega en el servidor web, liberando de esta forma al SGBD que única-
mente se tendrá que ocupar del acceso a las bases de datos.
Para implementar el ejemplo anterior con esta arquitectura, tendría que definir un servicio
web en mi servidor que se encargue de llevar a cabo el alta de clientes. Cuando un usuario qui-
siese dar de alta un cliente, tendría que emplear una aplicación que invocase dicho servicio web,
que serían el encargado de solicitar las operaciones de inserción necesarias (tanto del cliente
como de su descuento) al sistema gestor de base de datos.
El servidor web recibe las peticiones de los clientes, se comunica con el SGBD y devuelve
los resultados al cliente.
Usuario Cliente Servidor Servidor de

web base de datos
Figura 1.7
Arquitectura cliente/servidor en tres capas.
1.4.3. Tipos de licencias

Los sistemas gestores son componentes software, por lo que pueden ser clasificados en función
del tipo de licenciamiento que emplean para su distribución o comercialización.
A) Sistema gestor de bases de datos relacionales propietarios

El software comercial o propietario es aquel cuyo uso se permite mediante una licencia
comercial, la mayoría de las veces pagada, bajo la que se adquiere el derecho de uso, pero no se
adquiere el software propiamente dicho. Con estas licencias, de tipo CLUF o EULA (acrónimo
en inglés de contrato de licencia de usuario final), el usuario firma unas condiciones de uso, en-
tre las que suelen figurar que no se puede distribuir libremente el mismo y que está restringido
a unas condiciones determinadas).
Los SGBD comerciales son muy utilizados debido a su contrastada potencia y fiabilidad,
características muy importantes en un sistema gestor ya que en él reside uno de los activos más
importantes de una empresa: su información. No suelen cumplir completamente los estándares,
ya que todos intentar aportar novedades en forma de lenguajes propios, nuevas funcionalidades
o distintas formas de trabajar.
Capítulo 1
Los sistemas gestores de bases de datos propietarios más empleados son:
● Oracle: fue uno de los primeros sistemas gestores de bases de datos relacionales, y lleva
siendo durante muchos años el líder en el mercado (posición consolidada tras la com-
pra de Sun en 2009, propietaria de Java pero también del SGBD MySQL, que era hasta
entonces el gran rival de Oracle). Muchas de las funciones que se han ido añadiendo a
los distintos estándares de SQL fueron desarrolladas inicialmente por Oracle (procedi-
mientos almacenados, objetos, etc.). Es el sistema relacional más potente (permite varios
PB de almacenamiento), más robusto y también el más caro. A pesar de ser relacional,
dispone también de soporte a otros tipos de paradigmas, como el orientado a objetos
(permite crear y almacenar objetos) o NoSQL (permite almacenar documentos pero
también estructuras de grafos y espaciales).
● Microsoft SQL Server: es el sistema de base de datos relacional de Microsoft, disponible
únicamente para sistemas Windows, aunque su gran apuesta es derivar estos servicios a
la nube, para lo cual han desarrollado Microsoft Azure SQL Database, que es la versión
en la nube del SQL Server. En consonancia con otros productos de Microsoft, ofrece
un interfaz gráfico muy potente que permite llevar a cabo gran parte de las tareas de
administración del sistema por medio de asistentes o interfaces muy intuitivos.
● Db2: es un SGBD relacional propiedad de IBM que integra de manera nativa el manejo
de documentos XML, que se pueden cargar en la base de datos, navegar a través de ellos
e incluso integrarlo con búsquedas relacionales. Las últimas versiones incorporan compa-
tibilidad con Oracle e incluso permiten utilizar procedimientos PL/SQL (el lenguaje de
programación de Oracle). Dispone de una versión gratuita (Db2-Express-C) con algunas
limitaciones de funcionalidades avanzadas de las que sí dispone la versión comercial.
● Microsoft Access: la base de datos ofimática de Microsoft es la más utilizada entre este
tipo de bases de datos debido a que es uno de los componentes básicos del paquete
Microsoft Office y permite a usuarios con pocos conocimientos de bases de datos la
posibilidad de crear bases de datos y explotar su información por medio del uso de
asistentes que facilitan la creación de formularios, consultas e informes.
¿Sabías que...?
Oracle es el SGBD más completo y caro del mercado, pero ofrece la posibilidad de utilizar de forma
gratuita una versión de su sistema gestor limitado para trabajar solamente en un host local pero con
todas las funcionalidades.
Por el contrario, la versión community de MySQL, que tradicionalmente se identifica como el
SGBD gratuito por excelencia, tiene muchas limitaciones en cuanto a la funcionalidad que ofrece
de manera gratuita, por lo que a la hora de elegir un sistema gestor para llevar a cabo las tareas pro-
puestas en este libro, Oracle ofrece una solución gratuita más completa que la de MySQL.
B) Sistema gestor de bases de datos de software libre

El software libre es aquel que está bajo una licencia libre y, por tanto, su uso, modificación
y distribución están permitidos para todo el mundo. Los sistemas gestores de datos de código
abierto se distribuyen generalmente bajo las siguientes licencias:
Capítulo 1
Cuadro 1.2
Licencias más habituales
Licencia GPL El desarrollador conserva los derechos de autor del software desarrollado
(GNU General pero permite su libre distribución, modificación y uso, si bien cualquier
Public License) modificación del mismo debe publicarse obligatoriamente bajo la misma
licencia y ser también de libre distribución.
Licencia BSD Es la más permisiva con respecto a lo que el usuario puede hacer
(Berkeley Software con el software, ya que permite que cualquier modificación realizada
Distribution) pueda ser distribuida bajo cualquier otro tipo de licencia, incluso
licencias propietarias.
Licencia Apache También permite la redistribución del software bajo cualquier tipo
de licencia, pero requiere la conservación del aviso de derecho de autor
y el descargo de responsabilidad.
Entre los sistemas gestores de bases de datos de código abierto, podemos citar:
● MySQL: es el SGBD de código abierto más empleado, especialmente para el desarrollo

de aplicaciones web, ya que es muy apropiada en entornos donde se realizan muchas
lecturas pero las escrituras no son tan numerosas. Creado inicialmente por la empresa
MySQL AB bajo una licencia GPL, la compra de la empresa por parte de Sun, que a
su vez fue comprada por Oracle, hace que actualmente se distribuya bajo una licencia
dual: mantiene una versión Community (con licencia GPL), y ha creado también varias
versiones Enterprise que se distribuyen bajo una licencia comercial de Oracle.
● MariaDB: cuando Oracle adquirió MySQL, la comunidad que mantenía el SGBD de-
cidió desvincularse del mismo y crear un nuevo SGBD que siguiese manteniendo la fi-
losofía y función que tenía MySQL hasta ese momento, al que llamaron MariaDB (algo
similar a lo que sucedió con OpenOffice y LibreOffice). MariaDB era en su origen
exactamente igual a MySQL, aunque desde entonces ambos sistemas han evolucionado
por separado. Se distribuye por medio de una licencia GPL.
● PostgreSQL: es un SGBD relacional de código abierto publicado bajo su propia licencia
PostgreSQL, similar a la licencia BSD. Está desarrollado y soportado por una comunidad
de desarrolladores. Es el SGBD más fidedigno con los estándares, y sus principales carac-
terísticas son la alta concurrencia, el soporte de gran variedad de tipos de datos nativos
(arrays, figuras geométricas, direcciones IP, etc.), gran estabilidad y escalabilidad y dispone
de su propio lenguaje procedimental. En los últimos años su uso está cada vez más exten-
dido, consolidándose como la principal alternativa de software libre a MySQL.
● SQLite: es un sistema de gestión de bases de datos relacional de dominio público con-
tenido en una pequeña biblioteca escrita en C.
– A diferencia de los sistemas de gestión de bases de datos cliente-servidor, el motor

de SQLite no es un proceso independiente con el que el programa principal se
comunica, sino que la biblioteca SQLite se incluye en el programa pasando a ser
parte del mismo, de modo que el programa utiliza la funcionalidad de SQLite a
través de llamadas simples a subrutinas y funciones, lo que hace que los accesos
a la base de datos sean más rápidos. El conjunto de la base de datos (definiciones,
tablas, índices, y los propios datos) es guardado como un solo fichero estándar en
Capítulo 1
la máquina host. Este diseño simple se logra bloqueando todo el fichero de base de
datos al principio de cada transacción.
– A pesar de su sencillez, permite bases de datos de hasta 2 TB, la inclusión de cam-
pos tipo BLOB, compresión, cifrado y asegura las propiedades ACID, y es el SGBD
relacional que más está creciendo en los últimos años, debido a que su modo de
funcionamiento lo hace muy adecuado para su utilización por parte de aplicacio-
nes que se ejecuten en dispositivos móviles: este tipo de aplicaciones normalmente
utilizan una base de datos local a la que solamente accede la aplicación y por tanto
no requieren ni múltiples usuarios ni complejas arquitecturas cliente servidor: toda
la información se almacena en un fichero al que se accede de forma muy rápida y
eficiente por medio de consultas SQL.
● MongoDB: es un sistema de bases de datos NoSQL documental y de código abierto dis-

tribuido bajo una licencia GPL, si bien los drives para su uso desde aplicaciones tienen
una licencia Apache, y ofrece también una versión con funcionalidades adicionales que
se distribuye bajo una licencia comercial. Es el sistema NoSQL más empleado a nivel
mundial, y su crecimiento es continuo en los últimos años.
Toma nota
La gran mayoría de los SGBD NoSQL más empleados se distribuyen bajo licencias de
código abierto: Apache (muchas de estas soluciones fueron desarrolladas por la Fun-
dación Apache o están basadas en productos de esta, como Cassandra, Elasticsearch
o Hive), BSD (Redis, un sistema NoSQL de tipo clave/valor) o GPL (como el caso de
MongoDB).
1.4.4. Tipos de bases de datos
Otra de las cuestiones relevantes a tener en cuenta a la hora de escoger el SGBD más adecuado
es el tipo de base de datos que vamos a necesitar en función de la utilización que vamos a hacer
de ella (es decir, del tipo de transacciones que ejecutaremos).
Existen dos tipos de bases de datos en función del tipo de transacciones que ejecutan:
A) Transaccionales
Se emplean para almacenar la información de las aplicaciones necesarias para la operación
diaria de la empresa (por lo que también se llaman sistemas operacionales): las bases de datos de
ventas, de nóminas, de administración, de gestión de almacén, etc.
Este tipo de sistemas:
– Deben gestionar la conexión de múltiples usuarios y soportar un gran número de tran-

sacciones simultáneas.
– Las transacciones que se ejecutan son transacciones simples sobre una o unas pocas ta-
blas (inserción de una venta, consulta de los datos de un cliente, consultar la ubicación
de un producto, borrar una venta junto con sus líneas de venta, etc.).
Capítulo 1
– Pueden almacenar volúmenes elevados de información, pero nunca se accede a ella

de forma simultánea, y el 90 % de la información no se suele consultar (toda la infor-
mación histórica de ventas, compras, nóminas, etc., que son los datos que más suelen
ocupar), ya que los datos que se manipulan habitualmente son los datos actuales.
B) Data warehouse

Las organizaciones utilizan todos los datos que almacenan para obtener información que les
ayude a tomar decisiones que les permitan mejorar la eficiencia de sus procesos y empleados,
obtener ventajas competitivas o realizar un seguimiento de las decisiones tomadas.
Si en una gran empresa lanzásemos una consulta sobre su base de datos transaccional para
comprobar la evolución de las ventas de un determinado tipo de productos a clientes de una
ubicación geográfica concreta a lo largo de los últimos 10 años (una consulta que accede a
muchas filas de muchas tablas distintas), lo más probable es que colapsásemos la base de datos
durante unas horas y no se podrían realizar ventas ni ninguna otra operación durante ese
tiempo.
Los sistemas business intelligence (inteligencia de negocio) son sistemas pensados para realizar
este tipo de consultas analíticas: por medio de unos procesos de carga, leen periódicamente los
datos procedente de los distintos sistemas transaccionales de la organización, los transforman para
homogeneizarlos y los vuelcan en su propia base de datos data warehouse (DW; de almacén de datos).
Las bases de datos DW están especialmente diseñadas y configuradas para almacenar vo-
lúmenes de información muy grandes de forma que puedan ser consultados rápidamente. Su
función es permitir la realización de análisis complejos del funcionamiento de la organización
y su evolución.
– Almacenan grandes volúmenes de información (los datos de los últimos 5 o 10 años,

por ejemplo), por lo que la velocidad de acceso es un requisito fundamental.
– La información generalmente procede de distintas fuentes, pero se modifica antes de in-
sertarla en la base de datos para que toda la información tenga un formato homogéneo
(de forma que puedan ser comparados los datos de distintas fuentes). Si por ejemplo leyese
datos de productos textiles de distintas tiendas donde se vende el mismo pantalón, sería
necesario integrarlos para que todos apunten al mismo registro de la tabla maestra de pro-
ductos (para poder contar por ejemplo las ventas totales de ese pantalón en todas las tien-
das) independientemente del código interno que cada tienda emplee para dicho pantalón.
– Los datos son accedidos por pocos usuarios cualificados que realizan pocas consultas
pero que son muy pesadas, tanto en número de indicadores consultados (columnas)
como en cantidad de datos (filas) que se han de consultar.
Recurso digital 1.1
En el anexo Base de datos transaccional vs data warehouse, disponible en la sección de

recursos digitales, se detalla un ejemplo de cómo sería un sistema operacional y un siste-
ma DW de una cadena de supermercados.
Capítulo 1
1.4.5. Requisitos necesarios
El sistema gestor suele ser un software muy potente y que consume muchos recursos, por
lo que muchas veces para su instalación es necesario cumplir con unos requisitos mínimos
para que pueda ejecutarse de manera fluida. Los principales requisitos que pueden limitar la
capacidad de elección del sistema gestor son:
1. Sistema operativo: será necesario fijarse, por un lado, en si el sistema gestor es multiplata-
forma (los de Microsoft, por ejemplo, solamente disponen de versiones para Windows),
y, por otro lado, en la versión del sistema operativo a partir de la cual es posible llevar a
cabo la instalación (normalmente lo que se exige en estos casos es que sean versiones
con soporte activo).
2. Disco duro: los SGBD suelen ocupar bastante espacio en disco (para almacenar tanto
el software como las bases de datos), por lo que suelen exigir una cantidad mínima de
espacio libre para poder proceder a la instalación.
3. Memoria: es el otro requisito fundamental del que va a depender el rendimiento del
sistema. En muchos casos la cantidad mínima de memoria que establecen es una canti-
dad sin la cual no sería posible ejecutar el sistema, en lugar de la memoria mínima para
poder ejecutarlo correctamente.
Recuerda
3 El hecho de que el SGBD pueda ejecutarse con una cantidad limitada de memoria no
implica que vaya a ejecutarse correctamente. Si por ejemplo tuviésemos una limitación
de 4GB de RAM, aunque podríamos instalar un servidor Oracle o SQL Server, probable-
mente fuese preferible instalar un gestor más liviano, ya que su rendimiento será mejor.
4. Procesador: desde la aparición de los procesadores multinúcleo es complicado establecer

requisitos mínimos referentes a la velocidad de procesamiento, pero sí se suelen estable-
cer mínimos relativos al fabricante o al número de bits del procesador.
5. Conectividad: en ocasiones se exige conectividad del equipo a internet o que tenga una
IP fija asignada.
6. Librerías adicionales: tanto en sistemas Linux como en Windows, es habitual que la insta-
lación del SGBD exija tener instaladas previamente librerías o paquetes concretos que
son necesarios para ejecutar alguna funcionalidad del sistema (paquetes de Visual Studio
en Windows, algún compilador o librería específica en Linux, etc.).
1.5. Contextos de utilización de cada sistema gestor

de bases de datos
Atendiendo a los factores de decisión indicados anteriormente, podríamos establecer la si-
guiente relación entre tipos de SGBD y contextos de utilización más habituales de un SGBD,
ordenados en base al volumen de información que requeriría cada tipo de sistema:
Capítulo 1
a) Aplicación para móvil: almacena muy pocos datos, que pueden ser accedidos únicamente
por medio de la aplicación (un usuario y sin conexiones concurrentes). En estos casos
lo más adecuado es o bien utilizar directamente un fichero, o bien usar una base de
datos relacional como SQLite, pensada específicamente para escenarios como este.
b) Pequeña pyme: almacena pocos datos, únicamente necesita unos formularios e informes
para manipular y consultar la información, no requiere conectividad a internet y tiene
uno o muy pocos usuarios. En este caso lo más adecuado sería utilizar un SGBD ofi-
mático como Access o Libre Office (dependerá de los recursos disponibles) con cuatro
tablas y cuatro formularios, ya que sería la mejor solución en cuanto a necesidades de
la empresa y coste para implementarla.
c) Mediana pyme: volumen medio de datos, requiere de una aplicación para acceder a
los datos (que será usada por unas decenas de usuarios que pueden acceder de forma
simultánea), y normalmente sin conectividad a internet. En este caso tendríamos que
usar un SGBD relacional, que dependerá en gran medida de los recursos y la política de
empresa: si los costes de licencia no fuesen un problema, podría optar por emplear un
servidor Oracle, pero como no suele ser así, podría optar por una solución más barata
(SQL Server o un MySQL Enterprise), o directamente una de código abierto (My
SQL, MariaDB, PostgreSQL, etc.).
d) Tienda web: volúmenes de información medios-altos y muchos accesos simultáneos por
parte de múltiples usuarios. Para este tipo de sistemas (aplicaciones web en general),
se suelen usar bases de datos open source como MySQL o MariaDB, ya que su punto
fuerte es precisamente que gestionan muy bien situaciones de alta concurrencia, y las
bases de datos suelen ser bastante sencillas (pocas tablas) y no requieren una gran com-
plejidad de almacenamiento.
e) Sistema operacional de gran organización: volúmenes de información medio-altos, datos com-
partidos entre múltiples aplicaciones y usuarios, acceso concurrente de múltiples usuarios,
con conectividad a internet y normalmente con disponibilidad de recursos económicos.
En estos casos lo más habitual es utilizar un SGBD relacional que provea de un soporte
oficial al que recurrir en caso de cualquier problema (Oracle, SQL Server, etc.).
f) Datawarehouse de gran organización: volúmenes de información muy altos, pocos usuarios
con pocos accesos simultáneos, gran complejidad de almacenamiento (el almacena-
miento debe estar muy optimizado para que las consultas se ejecuten en un tiempo
razonable). Estos sistemas requieren grandes cantidades de memoria, y suelen llevar al
límite las capacidades de sistema gestor, por lo que se debería usar uno muy potente (y
costoso), como Teradata, Oracle, o incluso SQL Server, o ya pasar a un sistema NoSQL.
Ten en cuenta
En términos generales, podemos afirmar que los sistemas relacionales son los más adecuados
para sistemas tradicionales (con volúmenes de información pequeños o medios), pero a me-
dida que avanza el tamaño o la complejidad de la información a almacenar (sistemas de big
data), los sistemas NoSQL se hacen más aconsejables.
g) Sistemas big-data: los sistemas NoSQL son los más apropiados para sistemas que requieren
procesar gran cantidad de información (a un sistema relacional ya le cuesta mucho mover
cientos de TB), o que requieren almacenar información que no tiene un esquema fijo
(si, por ejemplo, guardamos documentos, los atributos que nos puede interesar guardar
Capítulo 1
serán muy diferentes en función de si queremos guardar un fichero de texto, de vídeo, de

audio, etc. Si empleásemos un sistema relacional y almacenásemos la información en una
tabla “documentos”, la mayor parte de los campos irían a nulo, mientras que un sistema
NoSQL nos permitiría guardar para cada documento solo los atributos que necesitemos).
Con respecto al tipo de sistema NoSQL que deberíamos utilizar, la decisión dependerá espe-
cialmente del tipo de información que vayamos a utilizar, la complejidad de los datos y su tamaño:
Clave/valor
Columnar
Tamaño
Documental
Grafos
Relacional
Figura 1.8
Contexto de utilización
de sistemas NoSQL. Complejidad de los datos
Accede al recurso digital Elección del SGBD donde se detallan diversos tipos de empresas,
con distintas características y necesidades, y determina qué tipo de sistema gestor de base de
datos sería más adecuado para cada casuística.
1.6. Instalación
Realmente en una organización grande con un equipo de DBA y un equipo independiente de
administradores de sistemas, el equipo responsable de realizar la instalación del SGBD sería el
equipo de sistemas, asesorado, eso sí, por el equipo de administración de bases de datos.
El administrador de base de datos sería el responsable de escoger el sistema gestor a instalar,
seleccionar los componentes que deben ser instalados y establecer los parámetros necesarios
para realizar la configuración inicial que se lleva a cabo durante la instalación.
Prácticamente todos los sistemas gestores actuales disponen de asistentes para facilitar su
instalación y para realizar una configuración básica del sistema durante el proceso de instalación.
1.6.1 Componentes de la instalación

El proceso de instalación dependerá en gran medida el producto de que se trate y del sistema
operativo sobre el que se realizará la instalación. La práctica totalidad de sistemas de bases de
Capítulo 1
datos actuales tienen una arquitectura de cliente-servidor y proveen de sus propias herramientas
y asistentes para realizar la instalación tanto del servidor como del cliente, y establecer la cone-
xión entre ellos.
Cuadro 1.3
Componentes básicos de la instalación de un SGBD tradicional
Motor del SGBD El software del servidor.
Interfaces externas Aplicaciones de comunicación (drivers o conectores)
necesarias para establecer la conexión entre los distintos
clientes y el servidor.
Herramientas de Aplicaciones cliente por medio de consola interactiva o
administración interfaces gráficos para la administración y explotación
del SGBD.
1.6.2. Configuración inicial
Durante el proceso de instalación del SGBD normalmente es posible establecer los valores de-
seados para diversos parámetros de configuración. Estos parámetros dependerán del SGBD en
cuestión que se esté instalando, pero hay varios tipos de parámetros comunes:
a) Idioma: idioma de los datos, el mapa de caracteres utilizado.

b) Gestión de memoria: permite reservar un tamaño específico de memoria que se asignará
al SGBD.
c) Gestión de ficheros: donde se ubicarán los ficheros de logs, los de control o configuración
del sistema, los de datos, los temporales, los del cuaderno de bitácora, etc.
d) Tipo de bases de datos que se van a crear: hay varios parámetros que dependerán del uso
que se vaya a hacer de las base de datos: si serán bases de datos transaccionales (OLTP)
o de almacén de datos (en inglés, data warehouse, OLAP). Las arquitecturas de ambos
sistemas son completamente diferentes, por lo que hay diversos parámetros que será
necesario adaptar en función de la arquitectura utilizada: el tamaño por defecto del
bloque de datos, el tamaño del segmento temporal, el tipo de optimizador (existe
un optimizador específico para la arquitectura en estrella de los entornos OLAP), el
modo del optimizador (para que priorice la minimización de E/S al disco o el coste
de CPU), etc.
e) Parámetros de restricción: destinados a aplicar límites o cuotas para evitar la acaparación
de recursos por parte de un usuario o limitar el número de procesos simultáneos que se
ejecutan sobre el sistema gestor de bases de datos.
La creación de las bases de datos y todos sus objetos asociados (esquemas, tablas, vistas, sinó-
nimos, restricciones, enlaces de bases de datos…) pueden llevarse a cabo por medio del DDL,
pero habitualmente los sistemas gestores ya proveen de sus propias herramientas con interfaz
gráfica para facilitar esta labor.
Capítulo 1
Descarga el sistema gestor Oracle19c de la página oficial de Oracle (https://www.oracle.com/

es/database/technologies/oracle-database-software-downloads.html) e instálalo en tu equipo o en
una máquina virtual.
Recoge todos los pasos realizados en un manual de instalación donde se deberán explicar las
distintas opciones disponibles y justificar las escogidas en cada caso.
La instalación debe realizarse teniendo en cuenta las siguientes consideraciones:
– Debe incluir la creación de una base de datos transaccional.

– Debe seleccionarse la clase de “Servidor”.
– El tipo de instalación será avanzada.
– Se deberá crear un usuario del sistema operativo "oracle".
1.6.3. Registro de instalación

Todos los instaladores de sistemas gestores de bases de datos guardan registro de las operaciones
llevadas a cabo durante la instalación y son de utilidad en caso de que se produzca algún pro-
blema, para diagnosticar el motivo del mismo.
La estructura y localización del registro de instalación dependerá también obviamente del
SGBD.
1.7. Instalación de Oracle

Antes de proceder a la instalación del SGBD Oracle es importante comprender su arquitectura
(revisa el recurso digital) ya que durante la instalación será necesario tomar decisiones que re-
quieren conocer la arquitectura y aspectos generales del sistema.
Recurso digital 1.2
En el anexo Arquitectura de Oracle, disponible en la sección de recursos digitales,

se detallan los distintos componentes de la arquitectura tradicional de Oracle y de
la nueva arquitectura Multinant.
Oracle solo se puede instalar en sistemas Windows, Linux/Unix y Solaris, pero la instala-
ción es muy similar en todos los sistemas operativos ya que se realiza por medio de un asistente
(el Oracle Universal Installer, OUI) y utiliza siempre una estructura de carpetas común inde-
pendientemente de la plataforma.
Todo el proceso de instalación está perfectamente documentado en el sitio web de Oracle
(eso sí: en inglés).
Capítulo 1
Ten en cuenta
El proceso de instalación es más sencillo en sistemas operativos de la familia Windows, ya

que el propio asistente de instalación realiza automáticamente varias de las configuraciones
iniciales necesarias. El principal inconveniente de estos sistemas operativos es que hacen un
consumo bastante elevado de recursos muy preciados para el sistema gestor, como son el es-
pacio en disco y, sobre todo, la memoria.
1.7.1. Requisitos
En general, los requisitos para la instalación son los mismos independientemente del sistema
operativo, ya que hacen referencia a los recursos disponibles no a los recursos totales. Si tene-
mos poca memoria o poco espacio en disco, por ejemplo, será mejor utilizar un sistema Linux,
ya que el sistema operativo ocupa menos espacio y consume menos memoria, con lo cual los
recursos disponibles podrían ser suficientes para instalar el sistema gestor.
Los requisitos mínimos indicados por el fabricante son los siguientes:
● 1 GB de memoria RAM para el sistema gestor (aunque se recomienda disponer al me-

nos de 2 GB).
● Conectividad a internet.
● En caso de instalaciones con el sistema operativo Linux, la distribución empleada debe
ser Red Hat Enterprise, CentOS u Oracle Linux, y debe tener un kernel instalado
compatible con el sistema gestor. La memoria de intercambio (swap) debe tener al me-
nos el mismo tamaño que la memoria RAM.
● Al menos 1 GB de espacio libre en el directorio temporal.
● 8 GB de espacio libre en disco para el sistema gestor, más el espacio libre adicional ne-
cesario para crear las bases de datos.
● La tarjeta gráfica debe ser capaz de mostrar 1024 * 768 píxeles como mínimo y
256 colores.
Cuando se lanza la instalación, lo primero que se ejecuta es una comprobación de requisitos

para asegurar que se cumplan todos los requisitos anteriores. Al crear la base de datos, necesita
espacio adicional para crearla, por lo que volverá a ejecutar otra comprobación de requisitos
para asegurar que dispongamos del espacio necesario (lo que comprueba básicamente es que
haya espacio en disco).
1.7.2. Componentes de la instalación

Cuando ejecutamos la instalación de Oracle, no solamente se instala el sistema gestor, sino que la
instalación incorpora varias herramientas adicionales para facilitar la administración del sistema:
● DBCA: es un asistente que facilita la creación, modificación o eliminación de bases de

datos. Si queremos crear una nueva PDB, la forma más sencilla de hacerlo sería ejecu-
tando este asistente.
● Netc.A: asistente que permite crear, modificar o eliminar el Listener. El Listener es el
servicio encargado de escuchar peticiones de los usuarios y lanzar el proceso de servidor.
Capítulo 1
● Netmgr: gestor de red, permite configurar la conectividad de las aplicaciones y bases de

datos.
● Aplicaciones cliente de gestión y administración: generalmente en la instalación se in-
cluyen tres aplicaciones cliente que permiten la gestión y administración del servidor:
el EM, el SQL Plus y el SQL Developer.
● RMAN: software para la realización de copias de seguridad.
A) SQL Plus

Es una aplicación cliente para la conexión al sistema gestor por medio de un interfaz de
comandos que permite ejecutar comandos y sentencias SQL. La aplicación se almacena en la
carpeta ORACLE_HOME/bin, por lo que para utilizarla bastaría con abrir una consola de
comandos del sistema y escribir sqlplus.
Para conectarse al servidor por medio del SQL Plus se utiliza la siguiente cadena de co-
nexión:
C:\>sqlplus usuario/pass@servicio [AS {SYSOPER | SYSDBA}]
Donde:
– Usuario y pass serían las credenciales del usuario que se va a conectar.

– Servicio sería la entrada del fichero tnsnames.ora correspondiente a la base de datos o
instancia a la que se va a conectar.
– SYSOPER y SYSDBA son roles que podría asumir el usuario cuando se conecta (so-
lamente puede conectarse as SYSOPER o as SYSDBA si tiene esos roles concedidos).
El rol SYSOPER capacita al usuario para realizar operaciones de inicio (STARTUP) y
parada (SHUTDOWN) de la instancia, además de permitirle realizar modificaciones en
las bases de datos y los tablespaces, mientras que el rol SYSDBA, además de lo anterior,
permite crear bases de datos o usuarios.
SQL Plus es una herramienta de cliente, por lo que, para conectarse a una instancia de
Oracle, necesitará que exista un fichero tnsnames.ora correctamente configurado en ORA-
CLE_HOME/network/admin, y que en ese fichero exista una entrada para el servicio al que
nos queremos conectar.
Ejemplo
sqlplus usuario/abc123.@orcl; -- accedemos por medio del SQL Plus a la instancia (orcl) con
el usuario “usuario” y el password “abd123.”.
SQL>conn usuario/abc123.@pdborcl AS SYSOPER; -- desde el propio SQL Plus cerramos
la conexión anterior y establecemos una nueva a una PDB concreta (pdborcl) con el usuario
“usuario” con rol de SYSOPER.
Capítulo 1
En instalaciones en sistemas Windows, es posible establecer conexiones sin indicar el usua-

rio ni el servicio al que nos queremos conectar:
sqlplus / as sysdba
En este caso, se utilizará el propio usuario de Windows, siempre que ese usuario sea propie-
tario o miembro del grupo de usuarios creado durante la instalación del sistema gestor (si es el
administrador, se le asigna el usuario SYS).
El comando para desconectar es “disconnect”, y para salir de SQL Plus, “exit”.
B) Enterprise Manager

El Enterprise Manager (EM) es una herramienta gráfica de administración de sistemas ges-
tores de bases de datos Oracle, que por medio de una interfaz web permite gestionar de forma
centralizada todas las instancias de una organización.
Prácticamente toda la administración de la base de datos se puede gestionar desde el EM,
que permite registrar todas las instancias instaladas, conectarse a cada una de ellas y monitorizar
la instancia y sus bases de datos, gestionar los parámetros de configuración, gestionar usuarios y
el almacenamiento, definir alertas y umbrales, etc. Lo que no permite es gestionar el contenido
de las bases de datos (los esquemas de usuario).
Existen varias versiones de EM, de las cuales, las más importantes son:
● Enterprise Manager Cloud Control: herramienta muy potente que permite registrar y ges-
tionar todos los sistemas gestores Oracle de una organización desde la misma interfaz web.
● Enterprise Manager Express: versión muy simplificada y reducida que se instala por defecto
con el sistema gestor cuando no está disponible la versión anterior. Solamente permite
trabajar con un sistema gestor y únicamente permite realizar la monitorización del sistema.
El EM se lanza como una aplicación web que normalmente es accesible en la dirección

h ttps://servidor:puerto/em. En el último paso de la instalación, se nos indicará la dirección con-
creta en nuestra máquina para esta aplicación.
En las versiones de Oracle anteriores a la versión 12c, se pueden consultar los puertos que
usa Oracle para el EM en ORACLE_HOME/install/portlist.ini. A partir de la versión 12c, esto
se podrá hacer directamente con SQL:
a) Para configurar el puerto de escucha:
SQL> exec dbms_xdb_config.sethttpsport(5500); /*Para HTTPS*/

SQL> exec dbms_xdb_config.sethttpport(8080); /*Para HTTP*/
b) Para consultar el puerto que está utilizando:
SQL> select dbms_xdb.getHttpPort() from dual; /*Para HTTP*/

SQL> select dbms_xdb_config.getHttpsPort() from dual; /*Para HTTPS*/
Capítulo 1
Cada servicio (es decir, tanto la instancia como cada PDB) posee su propio EM, que se
ejecutará en su puerto correspondiente.
C) SQL Developer

Hasta la versión 18c, la instalación de Oracle incluía un potente cliente con interfaz grá-
fico, el SQL Developer, para realizar labores tanto de desarrollo como de administración del
sistema gestor. A partir de Oracle 18c, esta aplicación debe descargarse e instalarse por separado
(es altamente recomendable su instalación). Esta aplicación se almacena en la carpeta ORA-
CLE_HOME/sqldeveloper.
Las opciones que provee son muy similares a las de SQL Plus, pero tiene la ventaja de su
interfaz gráfica, que hace el trabajo mucho más sencillo.
Al igual que SQL Plus, es una herramienta de cliente, pero permite más opciones de cone-
xión que el SQL Plus:
a) Básico: establece una conexión utilizando una cadena de conexión (compuesta por el
servidor, puerto e instancia a la que nos vamos a conectar).
b) TNS: utiliza una de las entradas existentes en el fichero “tnsnames.ora”, por lo que no
es necesario indicar información de conexión.
c) LDAP: en caso de disponer de autenticación por medio de LDAP configurada en
el servidor, permitiría realizar conexiones contra el SGBD utilizando los usuarios de
LDAP.
d) Avanzado: permite establecer una conexión JDBC indicando una cadena de conexión
personalizada.
e) Local: permite establecer conexiones contra el servidor local.
Una vez establecida la conexión, es posible realizar todo tipo de operaciones con la base
de datos a la que nos hemos conectado: crear tablas, usuarios, vistas, sinónimos, etc., y todo por
medio de una interfaz gráfica.
1.7.3. El asistente de instalación OUI

La instalación de Oracle se hace por medio del asistente OUI. Este asistente realiza numerosos
cambios en el equipo y necesita ciertos permisos de administración para poder modificar varia-
bles de entorno o crear determinadas carpetas.
Ten en cuenta
Para poder ejecutarlo es necesario disponer de un usuario con suficientes permisos

para permitirle realizar estas tareas (no se recomienda realizar la instalación con el
usuario root), por lo que habitualmente se crea un usuario “oracle” con permisos ad-
ministrativos y se utiliza ese usuario para instalar el software.
Capítulo 1
En las versiones de Oracle anteriores a la versión 19c, era necesario descargar un instalador
que se encargaba de crear todas las carpetas necesarias en ORACLE_HOME y copiar cada
archivo a su ubicación. Esto tenía dos problemas: incrementaba considerablemente el tiempo
de instalación (tenía que copiar gran cantidad de ficheros), y desperdiciaba espacio innecesa-
riamente: el fichero de instalación ocupaba en torno a 3 GB, y la instalación unos 6 GB, por lo
que, aun disponiendo del espacio libre necesario para la instalación, muchas veces no era posible
llevarla a cabo ya que el propio instalador ya estaba ocupando gran parte de ese espacio libre ne-
cesario. A partir de la versión 19c, la carpeta que se descarga para realizar la instalación ya con-
tiene todos los ficheros necesarios organizados según la arquitectura OFA, por lo que solamente
habrá que moverla a la ruta ORACLE_HOME y cambiarle el nombre por “db_home1” y, de
ese modo, ya se convertirá en la carpeta de instalación del servidor, solucionando los problemas
de espacio y simplificando el proceso de copia de archivos.
Una vez lanzado el instalador, este va pasando por varios pasos en los que se solicita que se
indique algún dato o que se escoja entre varias opciones (cada una de las cuales estará siempre
precedida de un icono de ayuda sobre el que se puede pulsar para obtener más información
acerca de en qué consiste dicha opción).
El proceso de instalación apenas ha cambiado en las últimas versiones, y los pasos más rele-
vantes son los siguientes:
1. El primer paso será seleccionar si se quiere instalar únicamente la instancia de Oracle

(solo software), o si se desea crear y configurar también una base de datos. Si se opta por
crear la base de datos, dentro del propio asistente de instalación ejecutará el DBCA, el
asistente de creación de bases de datos.
2. Seleccionar el tipo de instalación que se realizará: de escritorio (para desarrollo) o de
servidor (para entornos de producción).
3. Escoger entre realizar una instalación típica, con la configuración predeterminada, o
una instalación avanzada en la que dará opción de personalizar varios de los parámetros
de la instalación.
4. Seleccionar la edición de base de datos a instalar: la versión Enterprise (la versión comer-
cial, más completa), o la versión estándar (más limitada, adecuada para empresas medianas).
5. En las instalaciones en Windows, a continuación se daría la opción de crear el usuario
de instalación del sistema operativo (el usuario “oracle”), y de indicar la ubicación de
la instalación, es decir, definir el valor de la variable ORACLE_BASE (ORACLE_
HOME se construiría automáticamente a partir de la ruta base). Por defecto empleará
como ruta de instalación la que corresponda según la arquitectura OFA, aunque per-
mite modificarla.
En función de si en el primer paso se ha seleccionado crear únicamente la instancia o crear

también la base de datos, se pasaría directamente a la comprobación de requisitos o se iniciaría
el asistente para crear la base de datos, que incluiría los siguientes pasos:
1. Seleccionar el tipo de base de datos a instalar: una base de datos transaccional para las
operaciones habituales del día a día con muchas transacciones pequeñas, o una base de
datos de almacén de datos (data warehouse: DW) optimizada para trabajar con pocas
transacciones pero muy pesadas.
2. Especificar los identificadores de la base de datos del contenedor (por defecto orcl) y
de la PDB que se va a crear (orclpdb). Estos nombres serán los que se usarán en toda la
red para identificar al contenedor y a la PDB.
Capítulo 1
3. Especificar opciones de configuración por defecto: Oracle permite reservar un espacio

específico de memoria para la SGA y para la PGA, pero recomienda no hacerlo y em-
plear en su lugar el gestor automático de memoria, que divide la memoria disponible
entre la SGA y la PGA según las necesidades. En este paso de configuración es posible
seleccionar también el juego de caracteres (el esquema de codificación del texto) que
empleará la base de datos.
4. Registrar el sistema en el EM Cloud Control, una herramienta web de administración de
bases de datos Oracle. Si tenemos un servidor en el que tengamos instalado el EM Cloud
Control, podemos indicarlo para registrar la nueva base de datos. Si no es así, la dejamos
sin registrar e instalará una versión reducida del EM en nuestro servidor que nos permitirá
realizar algunas operaciones básicas.
5. A continuación podremos activas las opciones de recuperación de la base de datos. Esto
nos permitirá volver hacia atrás en los datos en caso de desastre, lo cual es muy útil pero
consume gran cantidad de espacio en disco (Oracle recomienda al menos el doble del
tamaño original de la base de datos).
6. Especificar las contraseñas de los usuarios de administración. Como medida de seguri-
dad, Oracle recomienda especificar distintas contraseñas para cada uno de los usuarios
de administración.
7. Una vez finalizada la instalación, se mostrará una pantalla con la dirección de la versión
reducida del EM que se ha instalado en el equipo, de la que será conveniente tomar
nota.
Práctica guiada 1.1
Accede al recurso digital Instalación SGBD Oracle y realiza los pasos necesa-
rios para llevar a cabo la instalación de una instancia del servidor Oracle 19c con
la nueva arquitectura Multitenant de Oracle.
1.7.4. Instalación Windows vs instalación Linux

A pesar de que la instalación se lleva a cabo por medio del OUI tanto en Windows como en
Linux, hay algunas pequeñas diferencias en la instalación debido principalmente a operaciones
que en Windows puede realizar el asistente automáticamente pero en Linux no:
– Si se realiza la instalación del sistema gestor en el sistema operativo Windows, el propio

proceso de instalación permite llevar a cabo la creación del usuario “oracle” y de un
grupo ORA_DBA que se usará para incluir en él a los administradores de base de
datos para que puedan llevar a cabo la explotación del sistema gestor. En Linux es ne-
cesario crear tanto el usuario como el grupo manualmente. En sistemas RAC, sería
necesario crear este usuario de instalación en cada uno de los nodos del sistema.
– En los sistemas Windows se crean o actualizan automáticamente todas las variables de
entorno necesarias (ORACLE_BASE, ORACLE_HOME y el PATH del sistema), por
lo que no es necesario configurarlas previamente a la instalación. En Linux es necesario
asignar valor a varias variables de entorno para que la arquitectura OFA funcione co-
rrectamente:
Capítulo 1
Variable Valor
ORACLE_BASE /u01/app/oracle
ORACLE_HOME $ORACLE_BASE/product/19.0.0/dbhome_1
PATH $ORACLE_HOME/bin:$PATH
LD_LIBRARY_PATH $ORACLE_HOME/lib:$LD_LIBRARY_PATH
– El inicio y parada del sistema gestor (así como de otros procesos como el planificador
o el listener) se realiza por medio de servicios. En Windows estos servicios se crean y
se inician automáticamente, mientras que en Linux debe crearlos de forma específica el
administrador.
– Para facilitar desplegar el sistema gestor de base de datos en sistemas Linux, Oracle dis-
pone de su propia distribución de Linux (Oracle Linux), basada en la distribución de
Red Hat que recomienda utilizar, ya que facilita la instalación y, lo que es más impor-
tante, facilitará posteriormente la administración y explotación del sistema.
– Para poder ejecutar el asistente de instalación en Windows es necesario instalar previa-
mente “Visual C++ Redistributable para Visual Studio 2015”. La instalación en Linux
también requiere la instalación de algunas librerías, pero no obliga a hacerlo antes de
ejecutar el asistente de instalación, sino que el propio instalador en la pantalla de com-
probación de requisitos chequea si falta alguna librería necesaria e indica de cuál se
trata.
Resumen
n El administrador de bases de datos (DBA) es el responsable de salvaguardar la infor-

mación de una organización, para lo cual tendrá que escoger el repositorio de in
formación adecuado para cada uno de los datos a almacenar y deberá garantizar que
dichos repositorios están disponibles y son accesibles de manera óptima.
n Los principales repositorios de información son los sistemas gestores de bases de datos
(SGBD), aplicaciones que deben proveer al DBA de las herramientas necesarias para
garantizar que este pueda llevar a cabo sus funciones de manera adecuada y así ga-
rantizar la confidencialidad, integridad, consistencia y óptimo acceso y manipulación
de los datos.
n Para ello el SGBD cuenta con diversos componentes que se encargarán de permitir el
acceso de los usuarios a la información (interfaces externas), posibilitar la consulta y
manipulación de la información por parte de los usuarios y aplicaciones (procesador
de consultas, preprocesador del DML y compilador del DDL), llevar a cabo las tareas
solicitadas por los usuarios garantizando la integridad y consistencia de la informa-
ción (gestor de la base de datos), gestionar los accesos al disco para recuperar la
información necesaria y hacer persistentes en disco todas las modificaciones (gestor
de ficheros), y mantener un registro actualizado y accesible de todos los objetos exis-
tentes en el sistema y sus relaciones (gestor del diccionario de datos).
Capítulo 1
n El DBA es el responsable de todo el proceso de selección, instalación, configuración,

explotación, administración, monitorización y optimización de cada uno de los siste-
mas gestores de la organización.
n Para determinar el sistema más adecuado para cada contexto es necesario tener en
cuenta el tipo de sistema gestor que se requiere (por el número de usuarios, por la lo-
calización de la información y por su estructura), la arquitectura más adecuada para la
función que debe desempeñar, el coste de su licencia y si esta se adapta a las políticas
de la empresa, el tipo de base de datos que se va a crear (transaccional, de almacén de
datos o no relacional), y los requisitos hardware y software que requiere su instalación.
Ejercicios propuestos
1. La empresa en la que trabajas ha decidido sustituir el actual sistema de ficheros que
estaban utilizando por un SGBD y una aplicación moderna que sea accesible vía web
y permita explotar la información.
El sistema actual trabaja con los siguientes ficheros:
– CLIENTES: en este fichero se guarda la información de los clientes de tu empresa:

nombre, apellidos, dirección, localidad, número de teléfono, fecha de alta del
cliente, % de descuento que se le aplica.
– VENTAS: fichero donde se registran las ventas realizadas: cliente, fecha de venta,
fecha y hora de pago, tipo de pago (efectivo, tarjeta, etc.), empleado que la registra.
– LINVENTAS: guarda los productos incluidos en cada venta, junto con el número
de unidades de cada producto que se han pedido.
– PRODUCTO: código, descripción, precio, IVA y fecha de modificación del pro
ducto.
– EMPLEADO: nombre, apellidos, salario, puesto, fecha contratación, dirección y
número de teléfono.
El nuevo sistema informático que se va a implantar en la empresa es un sistema de

planificación de recursos empresariales (ERP) que dispone de varios módulos:
● Una aplicación de escritorio que emplearán los empleados para registrar las ven-
tas realizadas por los clientes.
● Una aplicación web a través de la que los propios clientes podrán realizar sus
pedidos.
● Una aplicación para móvil que los usuarios podrán descargarse para realizar sus
pedidos.
● Un módulo de análisis que lee la información registrada en tu base de datos por
parte de los tres sistemas anteriores y la guarda en su propia base de datos de forma
que facilite la elaboración de informes por parte de los gerentes de la organización.
Capítulo 1
Indica qué tipo de sistema gestor y de base de datos necesitarías para:
a) El módulo de análisis.
b) La aplicación de escritorio, aplicación web y aplicación móvil.
2. Un pequeño supermercado está desarrollando una aplicación web para gestionar su
almacén (para controlar el stock), y te contrata como administrador de bases de datos.
Tu primera labor será seleccionar el instalar el software que usará dicha aplicación
para almacenar la información.
En el almacén realizan varias tareas: compras a los proveedores, recepción de
las mercancías y ubicación de cada una en su lugar, revisión de caducidades, etc.
El supermercado tiene en total 10 empleados, y el presupuesto para informática es
bastante reducido.
a) ¿Qué tipo de arquitectura debería tener el SGBD?

b) ¿Qué tipo de SGBD emplearías en función de su ubicación, del número de usua-
rios y de su estructura?
● Un SGBD distribuido, multiusuario y relacional.

● Un SGBD distribuido, multiusuario y NoSQL.
● Un SGBD centralizado, monousuario y relacional.
● Un SGBD centralizado, multiusuario y NoSQL.
● Un SGBD centralizado, multiusuario y relacional.
3. El pequeño supermercado ha crecido considerablemente hasta convertirse en una ca-

dena con gran implantación a nivel comarcal, por lo que deciden crear una aplicación
de venta online para que los clientes puedan hacer sus pedidos por internet. Para sacar
todo el partido posible a esta aplicación, deciden también crear una aplicación paralela
que a partir de la información obtenida a partir de la venta online realice estudios de los
clientes (no solo para optimizar la aplicación de venta online sino también para optimi-
zar la distribución de productos en los supermercados): horas más habituales de compra,
productos comprados habitualmente de forma conjunta, respuesta de los usuarios ante
las ofertas, clasificación de grupos de clientes para realizar estudios de mercado, etc.
a) ¿Qué tipo de sistema gestor emplearías en el caso de la aplicación de venta

online?
● Orientada a objetos.
● Navegacional.
● Relacional.
● NoSQL.
b) ¿Qué tipo de sistema gestor usarías para la aplicación de análisis de ventas?
● Relacional.
● NoSQL.
● Orientada a objetos.
● Navegacional.
Capítulo 1
Actividades de autoevaluación
1. Un SGBD es:
a) Un conjunto de datos almacenados.
b) Un conjunto de programas para almacenar, gestionar y recuperar datos.
c) Un almacén donde se pueden guardar datos.
d) Un sistema de control de acceso a los datos.
2. No es una ventaja de NoSQL:

a) Estructuras de datos más flexibles.
b) Mayor tolerancia a fallos.
c) Mayor facilidad de mantenimiento.
d) Mayor capacidad de procesamiento.
3. ¿En qué modelo de base de datos se representa la información con nodos relacionados
en forma de red?
a) Relacional.
b) Jerárquico.
c) Orientado a objetos.
d) NoSQL.
4. ¿Qué tipo de sistema requerirá mayor cantidad de memoria?

a) Una base de datos transaccional.
b) Una base de datos de almacén de datos.
c) Una base de datos columnar.
d) Una base de datos documental.
5. ¿En qué consiste la independencia lógica del SGBD?

a) La forma en que se muestra la información a los usuarios y aplicaciones es
independiente de cómo se organiza internamente.
b) Las aplicaciones que acceden a los datos son independientes entre sí.
c) El almacenamiento de los datos es transparente para los usuarios y aplicaciones.
d) La forma de almacenar los datos es independiente de cómo se organizan in-
ternamente.
6. ¿Qué es una transacción?

a) Una operación de manipulación de datos.
b) Un conjunto de instrucciones que se deben ejecutar como una sola.
c) Un intercambio de información.
d) Un conjunto de operaciones que se realizan conjuntamente.
7. ¿Qué se almacena en el diccionario de datos?

a) Datos.
b) Estructuras.
c) Metadatos.
d) Tablas.
Capítulo 1
8. ¿Cuál de estos objetos no pertenece al esquema interno?

a) Índices.
b) Particiones.
c) Archivos de datos.
d) Vistas.
9. Una empresa quiere una aplicación de análisis corporativo. ¿Qué tipo de base de
datos necesitará?
a) Transaccional.
b) Orientada a objetos.
c) NoSQL.
d) De almacén de datos (DW).
10. No es un componente necesario en un SGBD centralizado:

a) El componente de comunicación.
b) El catálogo global del sistema.
c) El decodificador del diccionario de datos.
d) Todas las respuestas anteriores son correctas.
SOLUCIONES:
a b c
1. a b c d
d 5.
a b c
2. a b c d 9.
d 6. a b c d
3.
a b c d 7.
a b c d 10.
a b c d
a b c
4. a b c d
d 8.
Capítulo 1
2
Configuración
del sistema gestor
de bases de datos
Objetivos
3 Conocer los primeros pasos que se deben llevar a cabo tras la instalación del
sistema: qué elementos es necesario configurar y cómo realizar la puesta en
marcha del sistema.
3 Comprender la importancia y el funcionamiento de dos elementos básicos
del sistema gestor de base de datos como son el diccionario de datos y el
cuaderno de bitácora.
3 Considerar la importancia de documentar adecuadamente toda la informa-
ción referente a la instalación y configuración del sistema gestor.
Mapa conceptual
Diccionario de datos
Cuaderno de bitácora
realiza Funciones
Puesta en marcha
Configuración Entorno
Conexiones
Servidor
Almacenamiento
Cuentas del sistema
Seguridad
Explotación Arranque y parada del sistema
Administración
Glosario
Cuaderno de bitácora. Es un fichero (o más habitualmente un conjunto de ficheros) del

sistema gestor donde este registra todas las operaciones de manipulación de datos
ejecutadas, así como información de gestión como las copias de seguridad realizadas
o marcas de inicio y fin de transacción.
Datafile. Archivo de datos, estructura física donde se almacenan realmente los datos. Un
tablespace puede tener uno o varios datafiles.
Capítulo 2
Configuración del sistema gestor de bases de datos 55
Esquema. El esquema de una base de datos define la estructura de la base de datos, y

se almacena en el diccionario de datos. Está compuesto de un conjunto de objetos
de bases de datos (tablas, índices, procedimientos, vistas, etc.) relacionados entre sí.
Todas las tablas se deben crear dentro de un esquema, y para acceder a una tabla de-
bemos indicar el esquema al que pertenece (por ejemplo: ventas.clientes sería la tabla
“clientes” del esquema “ventas”).
Log. Grabación secuencial en un archivo o en una base de datos de todos los aconteci-
mientos (eventos o acciones) que afectan a un proceso particular.
PATH. Variable de entorno en la que se especifican las rutas en las cuales el intérprete de
comandos debe buscar los programas a ejecutar. Si a esa variable de entorno se le
añade una carpeta nueva, los programas que estén en esa carpeta se podrían ejecutar
en el interfaz de comandos desde cualquier ruta, ya que aunque el programa no esté en
la carpeta actual, el sistema operativo irá a buscarlo en todas las carpetas incluidas en la
variable PATH.
Pluggable Database (PDB). Es uno de los componentes de la arquitectura de Oracle: la
estructura física donde se almacenan los esquemas y datos de los usuarios. De deno-
mina “pluggable” (podría traducirse por “intercambiable”) ya que están especialmen-
te diseñadas para que sea muy sencillo moverlas a otro servidor en caso de que fuese
necesario.
Oracle System Identifier (SID). Es el identificador único de cada instancia del sistema ges-
tor. En una organización con múltiples instancias instaladas, cada una de ellas tendrá
un nombre único (su SID) que permitirá identificarla.
Tablespace. Estructura lógica de almacenamiento que engloba un conjunto de archivos
donde se almacenan los datos de las tablas de las bases de datos. Permite abstraer los
objetos lógicos del sistema gestor (tablas, índices, etc.) de sus detalles de almacena-
miento.
Variables de entorno. Son variables dinámicas del sistema operativo que pueden afectar
al comportamiento de los procesos en ejecución en un ordenador (un proceso en
ejecución puede consultar el valor de una variable de entorno para conocer la ubica-
ción de los archivos ejecutables del sistema operativo, o la ruta donde almacenar los
ficheros temporales).
2.1. Introducción
Tras seleccionar el SGBD y realizar la instalación, tanto del sistema gestor como de las aplica-
ciones clientes que sean necesarias para poder gestionarlo, es necesario configurarlo.
Los pasos a llevar a cabo para configurar adecuadamente el servidor serán muy dependien-
tes tanto del sistema gestor de que se trate como sobre todo de su arquitectura, pero por lo
general hay varios aspectos que es necesario configurar en todos ellos. En este capítulo veremos
estos aspectos generales que es necesario configurar y comprobaremos su aplicación práctica en
un SGBD concreto: Oracle.
Capítulo 2
2.2. Configuración del sistema gestor de bases de datos
La mayoría de sistemas gestores existentes en entornos de producción son sistemas con ar-
quitectura cliente/servidor, por lo que las tareas iniciales de configuración se centrarán en
identificar al servidor en la red, permitir las conexiones desde los clientes y habilitar las cuentas
necesarias para permitir dichas conexiones.
2.2.1. Configuración del entorno

La configuración del entorno se centra básicamente en dos aspectos:
– Asignar un nombre y dirección IP al servidor donde se alojará el sistema (que debería

ser preferiblemente una dirección estática)
– Crear o modificar las variables de entorno que sean necesarias para su correcto fun-
cionamiento. En ocasiones la actualización de las variables de entorno se realiza auto-
máticamente durante el propio proceso de instalación, pero en otros casos es necesario
hacerlo a mano. La modificación más habitual consiste en añadir al PATH del equipo
(la lista de rutas o carpetas donde el sistema operativo buscará las aplicaciones que eje-
cutemos) la ruta donde ese encuentren tanto los ejecutables del servidor como los del
cliente. Algunos sistemas gestores pueden requerir también la definición de variables
propias adicionales donde almacenarán rutas a librerías que necesitan para su ejecución,
la ruta base de instalación del servidor, etc.
2.2.2. Configuración de las conexiones

La arquitectura más común entre los sistemas gestores de bases de datos multiusuario es la ar-
quitectura cliente/servidor en 2 o 3 capas, por lo que lo primero que será necesario configurar
será la conexión entre el cliente y el servidor, para poder emplear el cliente posteriormente para
realizar las modificaciones necesarias en el servidor.
Los parámetros básicos que suele ser necesario especificar para establecer la conexión son
los siguientes:
a) En el servidor:
● El puerto donde escuchará en espera de conexiones de los clientes.

● El protocolo de comunicación que se utilizará para gestionar la comunicación.
● Aspectos de configuración adicionales que afecten a la conexión (que dependerán
mucho del SGBD utilizado): el modo en que se autenticará a los usuarios (si la
realizará el propio SGBD, con LDAP, con radius, etc.), parámetros necesarios para
establecer una conexión cifrada…
b) En el cliente:
● El nombre o dirección IP del servidor.

● El puerto del servidor al que deberá conectarse el cliente.
● El protocolo de comunicación que se utilizará.
Capítulo 2
● Las credenciales (usuario y password) que empleará para identificarse una vez esta-
blecida la conexión.
2.2.3. Configuración del servidor

Normalmente el servidor dispone de un fichero de configuración donde se guardan todos los
parámetros de configuración del mismo. Cuando se arranca el servidor, este lee dicho fichero
y asigna a cada parámetro el valor que le corresponda. Los parámetros que se almacenan en el
fichero de configuración dependerán especialmente de la complejidad del SGBD (cuanto más
complejo sea, más parámetros tendrá y más específicos serán).
Hay, sin embargo, algunos parámetros que suelen ser comunes en todos los sistemas:
● Ruta de los ficheros de control.

● Ruta de los ficheros de datos (donde se almacenan los datos de las tablas).
● Ruta de los ficheros de LOG del sistema.
● Aspectos relativos al control de las conexiones de los clientes: tiempo de timeout, nú-
mero máximo de conexiones soportadas, máximo número de conexiones por usua-
rio, etc.
Ten en cuenta
Existen parámetros cuya modificación puede tener efecto inmediato, pero hay otros que re-
quieren el reinicio del sistema gestor para pasar a ser efectivos, ya que al reiniciar el gestor este
cargaría de nuevo el fichero de parámetros con los nuevos valores que se hayan especificado.
2.2.4. Configuración del almacenamiento

Para abstraer los detalles físicos de almacenamiento de los objetos del SGBD y así facilitar el
mantenimiento de las tablas y controlar el espacio ocupado por cada esquema, los SGBD suelen
incorporar algún tipo de elemento lógico que facilite la gestión de los distintos ficheros de
cada esquema. Estas estructuras lógicas se suelen denominar espacios de tablas o tablespaces
(es así en Oracle, PostgreSql o MySQL), pero pueden tener otros nombres (como los Filegroup
de SQL Server).
Lo habitual es dedicar un tablespace a cada esquema, pero esto no tiene por qué ser así
(pueden incluirse datos de múltiples esquemas en un mismo tablespace). El uso de tablespaces
tiene varias ventajas:
● Si el almacenamiento trabajase a nivel físico y tuviésemos toda la información en un

mismo fichero, en caso de quedarnos sin espacio y tener que ampliar su capacidad nos
obligaría a detener el sistema mientras se realiza la ampliación o copia del fichero a otro
disco, dejando la base de datos inaccesible durante el tiempo que durase esa operación.
Utilizando tablespaces, para incrementar el espacio del tablespace solo habrá que crear
Capítulo 2
un fichero nuevo (puede estar en otro disco) con el tamaño que queramos ampliar y
añadirlo al tablespace, sin afectar en absoluto a la disponibilidad del sistema.
● Permiten gestionar conjuntamente todos los ficheros físicos de un esquema, lo que es
muy útil para hacer copias de seguridad, copiar datos, controlar el espacio ocupado por
cada esquema, etc.
Ejemplo
La funcionalidad que aporta el incorporar un elemento lógico que permita abstraer los deta-
lles de almacenamiento para una tabla podría equipararse a la funcionalidad de un call center
de atención al cliente, donde cada operador del call center sería el equivalente a un archivo de
datos y el propio call center sería la estructura lógica equivalente al tablespace:
– Si los clientes llamasen directamente a operadores concretos, esto implicaría que ten-
drían que conocer con qué operador quieren hablar y en caso de que este estuviese
ocupado o de vacaciones no podrían acceder al servicio. Del mismo modo, si los
datos de una tabla se guardasen directamente en un fichero, en caso de que este estu-
viese lleno o no estuviese disponible, no sería posible acceder a los datos de la tabla.
– El uso del call center permite introducir una estructura “abstracta” para la gestión de
llamadas de los clientes: si hubiese muchas llamadas y se saturase el servicio, sola-
mente habría que contratar a más operadores para poder seguir dando el servicio co-
rrectamente. De la misma forma, si los archivos de datos de un tablespace estuviesen
en un disco lleno, solamente habría que añadir un nuevo archivo de datos ubicado en
otro disco al tablespace y podrían insertarse nuevos datos sin problema en la tabla.
– De cara a la organización interna de la empresa, también sería más sencillo gestionar
a nivel de call center que hacerlo individualmente operador a operador: si queremos
derivar los clientes a los que atiende un call center a otro situado en otro país, sola-
mente sería necesario redirigir las llamadas dirigidas al call center, en lugar de tener
que desviar teléfono a teléfono. Del mismo modo, si queremos hacer una copia de
seguridad de varias tablas incluidas en un tablespace, es más sencillo copiar el ta-
blespace que tener que buscar todos los archivos de datos en lo que están las tablas y
copiarlas uno a uno.
Existen varios tipos de tablespaces:
a) De sistema: todos los SGBD tienen al menos un tablespace SYS o SYSTEM para alma-
cenar toda la información del sistema (el diccionario de datos).
b) Temporal: cuando realizamos consultas pesadas sobre el SGBD, cuando se queda sin
espacio en memoria para almacenar los resultados parciales de la consulta necesita guar-
dar esta información en disco, para lo que usará el tablespace temporal. Es importante
dimensionar adecuadamente este tablespace, ya que si los resultados de una consulta no
caben en el tablespace temporal, la consulta no se podrá resolver. Cuando finaliza la
consulta, el espacio que ocupaba se libera, por lo que en las tareas de revisión de espacio
no se debe tener en cuenta este tablespace.
c) De registro o de UNDO (de “deshacer”): algunos SGBD disponen de un tablespace de
UNDO para facilitar las operaciones de rollback. Cuando iniciamos una transacción,
Capítulo 2
al modificar los datos se almacenan en el tablespace de UNDO los datos previos a la

modificación, de forma que si en algún momento se realiza un rollback, solamente es
necesario recuperar dicha información para deshacer todas las operaciones que haya
llevado a cabo la transacción (lo cual es inmediato).
d) De usuario: son los tablespaces que se crean para almacenar la información de los es-
quemas. Cada SGBD maneja estos tablespace a su manera: MySQL crea por defecto un
tablespace para cada base de datos, Oracle y SQL Server guardan por defecto la infor-
mación de todos los usuarios en un tablespace de usuario o principal, etc.
2.2.5. Configuración de las cuentas del sistema

Cuando se instala el SGBD, se crea automáticamente un usuario con permisos de (llámese)
root, system, etc. Este usuario podrá realizar cualquier operación sobre el sistema gestor, por
lo que será el usuario que tendremos que utilizar para conectarnos por primera vez al sistema
gestor de bases de datos, configurarlo y crear el resto de usuarios que podrán trabajar con el
sistema (algunos sistemas ya permiten crear usuarios durante el propio proceso de instalación).
Una peculiaridad relevante de algunos sistemas gestores es que permiten establecer co-
nexiones con el usuario administrador desde el propio servidor sin necesidad de contraseña,
de forma que si perdieses la contraseña del administrador podrías conectarte al servidor para
recuperarla (siempre y cuando lo hagas desde el propio servidor).
2.3. Arranque y parada del sistema

Actualmente la mayoría de sistemas gestores permiten realizar su instalación como servicios, de
modo que no es necesario realizar ninguna configuración adicional para que estos se arranquen
automáticamente.
Para parar o arrancar normalmente el sistema gestor solamente será necesario reiniciar el
servicio, aunque en ocasiones será necesario arrancarlo a mano para poder realizar algunas tareas
de administración específicas que necesitan que el sistema esté activo para poder hacer los cam-
bios necesarios, pero que no esté abierto y aceptando conexiones de los usuarios ya que eso im-
pediría realizar dichos cambios. Esto sucede por ejemplo si queremos mover los ficheros donde
se almacenan los datos de una tabla: si el sistema está abierto estará usando el fichero, por lo
que el sistema operativo no nos permitirá moverlo. Para poder mover el fichero tendríamos que
detener el sistema gestor, arrancarlo en un estado intermedio en que no acceda a los ficheros de
datos, mover el fichero en el sistema operativo y actualizar la configuración del sistema gestor
para indicarle la nueva ruta donde tendrá que buscar el archivo cuando arranque normalmente.
¿Sabías que...?
Antiguamente la instalación del sistema gestor se llevaba a cabo como una aplicación
particular, de modo que era necesario configurar explícitamente el inicio del servidor
cuando se arrancase el equipo.
Capítulo 2
2.4. El diccionario de datos
El diccionario de datos es el repositorio de información donde se almacenan los metadatos

del SGBD (toda la información referente a los objetos que contienen las bases de datos y su
estructura).
El diccionario de datos suele implementarse por medio de una base de datos del sistema
propiedad de un usuario con rol de DBA, de modo que únicamente ese usuario o aquellos a
los que asigna permisos explícitamente puedan acceder a la información del sistema. En esta
base de datos interna se guardarán todas las tablas, columnas, vistas, usuarios, permisos, índices,
restricciones, procedimientos, etc. que hayamos creado en nuestras bases de datos.
El diccionario de datos es una de las herramientas más importantes del DBA a la hora de
administrar el SGBD, ya que el hecho de disponer de toda la información del sistema gestor
en una base de datos interna permite realizar consultas que monitoricen el funcionamiento
del sistema, que busquen objetos del sistema que puedan estar en mal estado para repararlos,
ficheros de almacenamiento con poco espacio libre para reservar más espacio, etc. Prácticamen-
te todas las herramientas utilizadas para la gestión, monitorización y administración del SGBD
internamente lo que hacen es realizar consultas sobre el diccionario de datos para obtener la
información necesaria para cada tarea.
Es importante resaltar que la información del diccionario de datos no debe modificarse
directamente en ningún caso, ya que ello podría provocar inconsistencias en la base de datos.
Si por ejemplo quiero borrar una columna de una tabla, no puedo borrarla directamente de la
tabla de COLUMNAS, ya que esa columna puede estar en otras tablas del diccionario de
datos (en la tabla de CLAVES_FORANEAS, la de VISTAS, etc.) que quedarían inconsistentes.
Ejemplo
Cuando creamos una tabla como la siguiente en la base de datos:
CREATE TABLE ventas.clientes(

idcliente number primary key,
nombre varchar(100) not null,
apellidos varchar(200) not null,
telefono char(9) unique
);
Internamente, el sistema gestor creará un nuevo registro en cada una de las tablas del dic-
cionario de datos donde se almacena la información referente a todos los objetos que estamos
creando:
● En la tabla TABLAS se insertará un registro correspondiente a la tabla nueva.
Figura 2.1
Ejemplo tabla “TABLAS” del diccionario de datos.
Capítulo 2
● En la tabla COLUMNAS se insertará un registro por cada una de las columnas de la tabla.
Figura 2.2
Ejemplo tabla
“COLUMNAS”
del diccionario
de datos.
● Se insertará en la tabla de RESTRICCIONES un registro por cada una de las restriccio-

nes existentes en la tabla.
Figura 2.3
Ejemplo tabla “RESTRICCIONES”
del diccionario de datos.
● Si el sistema gestor crea automáticamente índices en las claves primarias, por ejemplo,
creara el índice y guardará un registro en la tabla INDICES correspondiente a ese índice.
Figura 2.4
Ejemplo tabla “INDICES” del diccionario de datos.
2.5. El cuaderno de bitácora

El cuaderno de bitácora es un log donde se registran todas las operaciones de modificación de
datos ejecutadas sobre la base de datos. Recibe su nombre de los antiguos cuadernos de bitá-
cora donde los capitanes del barco registraban todos los acontecimientos relevantes sucedidos
durante una travesía.
Cuando se ejecuta una transacción sobre el sistema gestor, este inserta en el cuaderno de
bitácora:
– un registro de inicio de transacción;

– una entrada por cada operación de la transacción que modifique los datos existentes;
– una señal de fin de transacción si esta finalizó correctamente.
Se registran también en el cuaderno de bitácora todas las copias de seguridad y restauracio-

nes de datos ejecutadas.
Capítulo 2
Este fichero de log es especialmente importante porque se utiliza en algunas tareas muy
importantes, como:
● Gestión de transacciones: todas las operaciones realizadas por una transacción se registran
en este fichero, de modo que si ejecutamos un rollback y el sistema gestor tiene que
deshacer los cambios realizados hasta ese momento, consultará en el cuaderno de bitá-
cora las operaciones que tiene que deshacer.
● Recuperación del sistema ante caídas: si se cae el sistema y tenemos que recuperar la última
copia de seguridad, tendremos que volver a realizar todas las operaciones ejecutadas
desde el momento en que se hizo la copia de seguridad para volver al estado anterior a
la caída del sistema.
● Replicación del SGBD: para replicar una base de datos, normalmente lo que hace el siste-
ma gestor es trasladar al sistema gestor de la réplica todas las operaciones que se registren
en el cuaderno de bitácora, de forma que cada operación que se ejecute en el servidor
principal, se ejecutará también en la réplica. Si una réplica está temporalmente fuera de
servicio, cuando estuviese de nuevo online se le enviarían todas las instrucciones del log
que tiene pendiente de ejecutar y de ese modo se actualizaría automáticamente.
Ejemplo
Figura 2.5
Ejemplo cuaderno
de bitácora.
2.6. Documentación
Un administrador de sistemas debe almacenar información detallada y actualizada de todos los
servidores de la organización y de los servicios que proporcionan.
En el caso de un servidor de bases de datos, además de guardar los datos correspondientes
al hardware (capacidad de disco, memoria principal y extendida, placa base, etc.) y al software
de este (sistema operativo y programas en ejecución), se debe guardar también información de:
1. Versión y todas las actualizaciones realizadas de todos los programas del servidor (in-
cluido el SGBD). Es muy importante mantener esta información actualizada porque
será imprescindible tenerla a mano en caso de que sea necesario contactar con el sopor-
te del sistema gestor.
2. Información de las bases de datos que estén instaladas en el servidor: modelo Entidad-
Relación, esquema relacional y descripción de los objetos de la base de datos (tablas,
columnas de cada tabla, restricciones, funciones, disparadores).
3. Usuarios de la base de datos y permisos de cada uno de ellos.
Capítulo 2
Toma nota
Hay programas específicos que ayudan a realizar la documentación de las bases
de datos (como Mogwai, ERWIN o el propio MySQL Workbench), ya que permiten
generar automáticamente los modelos lógico y relacional de las bases de datos, así
como documentar la información de todos los objetos de la base de datos.
Aparte de la documentación propia para el mantenimiento del sistema gestor, es responsa-

bilidad del DBA definir o al menos participar en la definición de una serie de procedimientos
que garanticen que se cumplen las políticas de la organización y faciliten la administración de
los sistemas (especialmente en organizaciones grandes):
a) Procedimientos de copia de seguridad y restauración: es muy importante que existan

estos documentos porque un fallo del sistema gestor suele generar situaciones de mu-
cho estrés en las que es mucho más adecuado seguir una guía de pasos a ejecutar para
la restauración de los datos que tener que pensar en cada momento qué paso debo
ejecutar a continuación y cómo debo hacerlo.
b) Procedimientos de registro de datos: para garantizar el cumplimiento de la Ley Orgá-
nica de Protección de Datos (LOPD) es necesario llevar a cabo una serie de tareas cada
vez que se vayan a registrar datos de carácter personal. El procedimiento para llevar a
cabo estas tareas debería estar documentado para agilizarlo.
c) Definición y organización de simulacros: cuando existen sistemas de réplica y respaldo
es necesario planificar y realizar periódicamente simulacros para garantizar que en caso
de desastre la recuperación sea lo más rápida posible. Esta tarea suele ser responsabilidad
del administrador de sistemas, pero el DBA tendrá también un rol importante.
d) Procedimiento de alta de usuarios y permisos: para facilitar el mantenimiento del siste-
ma de usuarios y permisos, el alta de usuarios y la asignación de permisos deberían estar
procedimentados para facilitar su mantenimiento.
e) Guía de estilo para la creación de bases de datos: en una organización que disponga
de múltiples esquemas de bases de datos, si estos son muy heterogéneos (cada cual con
su diseño y nomenclatura particular), complica mucho su mantenimiento, por lo que
debería definirse un procedimiento para que todos los esquemas, tablas, tablespaces,
usuarios, etc., se ajusten a una nomenclatura común que sea significativa.
2.7. Configuración de Oracle

El servidor Oracle tiene una arquitectura cliente/servidor, por lo que, tal como se comentó
anteriormente, será necesario realizar una configuración inicial del servidor y permitir la cone-
xión desde las aplicaciones clientes.
2.7.1. Configuración del entorno

El asistente de instalación de Oracle para entornos Windows ya incluye, como un paso más
del proceso de instalación, la configuración del entorno, por lo que no sería necesario realizar
ninguna intervención adicional en este sentido.
En entornos Linux/Unix, tendríamos que configurar manualmente el entorno de ejecu-
ción del servidor Oracle, lo que implica:
Capítulo 2
– Definir las variables de entorno: es necesario definir tres nuevas variables (ORACLE_
HOME, LD_LIBRARY_PATH y ORACLE_SID) y modificar el PATH del sistema:
export ORACLE_HOME=(ruta hasta la carpeta dbhome)

export LD_LIBRARY_PATH=”$ORACLE_HOME/lib:$ORACLE_HOME”
export ORACLE_SID=(nombre de la instancia, por defecto orcl)
export PATH=”$ORACLE_HOME/bin:$PATH”
– Tendremos que dar permisos de lectura y ejecución a todos los usuarios (o al grupo
de usuarios de instalación) en los directorios $ORACLE_HOME/lib, $ORACLE_
HOME/bin, $ORACLE_HOME/oracore y $ORACLE_HOME/sqlplus.
2.7.2. Configuración de las conexiones

Oracle utiliza una arquitectura cliente/servidor en 2 capas, por lo que, para poder establecer
conexiones, tendremos que configurar tanto el cliente como el servidor.
Oracle dispone de una aplicación que permite realizar la configuración de red por medio
de un interfaz gráfico: el asistente de configuración de red de Oracle. Esta aplicación está escrita
en Java, por lo que se puede utilizar tanto en un entorno Windows como Linux, y consisten en
un asistente que facilita la modificación del contenido de los ficheros de configuración de red
de Oracle: el tnsnames.ora, el sqlnet.ora y el listener.ora. Todos estos ficheros de configura-
ción de red se almacenan en la carpeta “ORACLE_HOME/network/admin”.
Ten en cuenta
El formato de las entradas de los ficheros de configuración de red de Oracle es MUY delicado:
es muy habitual tener problemas de conexión debidos a la presencia de espacios o tabuladores
donde no corresponde, que son muy difíciles de detectar. Para añadir nuevas entradas en estos
ficheros, se recomienda para evitar problemas partir siempre una entrada existente y copiarla
y pegarla modificando únicamente los valores necesarios para la nueva conexión (o usar el
asistente de configuración de red, que ya nos garantiza que no habrá errores de este tipo en las
entradas que defina automáticamente).
A) Configuración del servidor

Para que los clientes puedan conectarse al servidor de Oracle, será necesario configurar dos
aspectos en el servidor:
1. Dónde se deben conectar los clientes
El listener es el programa que se ejecuta en el servidor y se encarga de escuchar en un puer-

to concreto para atender las peticiones de los clientes que llegan a ese puerto. Este programa se
Capítulo 2
e jecuta como un servicio del sistema operativo (por lo que es posible arrancarlo, pararlo o reini-
ciarlo como un servicio más), aunque realmente gestiona varios procesos, uno por cada base de
datos o instancia a la que nos podamos conectar. Oracle denomina a estos procesos con el nombre
de “servicios”, lo que es bastante confuso ya que un servicio del sistema operativo (el listener) ges-
tiona varios servicios de Oracle (los procesos que atienden las peticiones realizadas sobre cada base
de datos). Los parámetros del listener (el nombre o dirección del servidor y el puerto en el que
escucha, principalmente) se configuran por medio del fichero de configuración “listener.ora”:
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = ORCL)
(PROGRAM = extproc)
(ENVS = “EXTPROC_DLLS=ONLY:C:\app\oracle\product\12.1.0\dbhome_1\
bin\oraclr12.dll”)
(SID_NAME = ORCL)
(ORACLE_HOME = C:\app\oracle\product\12.1.0\dbhome_1)
)
)
LISTENER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = ORASERV)(PORT = 1521))
)
El servicio realmente está ejecutando una aplicación del servidor Oracle, el programa “lsn-
rctl” (disponible en el directorio “bin” del Oracle Home). Con este programa podemos lanzar,
parar o comprobar el estado del listener para saber qué servicios están activos:
lsnrctl start [nombreListener]

lsnrctl stop [nombreListener]
lsnrctl status
El nombre del listener solamente será necesario indicarlo si tenemos instalados varios liste-
ners en la misma máquina.
Una última opción que tenemos para controlar el funcionamiento del listener es a través
del EM.
2. Cómo se va a establecer la conexión
Los parámetros específicos acerca de cómo se va a establecer la conexión se especifican en

el fichero “sqlnet.ora”. En este fichero se podrá indicar qué tipo de autenticación de usuario
podemos emplear (solo usuarios del SGBD, usuarios del SO, kerberos, RADIUS, etc.), qué
equipos pueden acceder al sistema y cuáles no pueden hacerlo, si queremos establecer conexio-
nes cifradas, y otros parámetros propios de la conexión de Oracle.
Capítulo 2
B) Configuración de los clientes

Los parámetros de conexión de los clientes para acceder al servidor de base de datos se con-
figuran por medio del archivo “tnsnames.ora”. En este archivo tendremos una entrada por cada
servicio (PDB o contenedor del PDB) al que nos queramos conectar, en la que se especificará
básicamente la dirección del servidor (HOST), el puerto donde escucha el listener (PORT) y
el nombre del servicio al que conectarse (SERVICE_NAME).
ORCL =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = ORASERV)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl)
)
)
Existe un comando en la carpeta /bin de ORACLE_HOME llamado TNSping que permite

probar las conexiones existentes en el tnsnames. Si ejecutamos por ejemplo el siguiente comando:
tnsping orcl;
Haría un ping a la máquina y puerto indicados en la entrada “orcl” del tnsnames.

Si queremos establecer una conexión cifrada, por ejemplo, en el cliente también tiene que
tenerlo en cuenta, por lo que en el cliente también será necesario configurar el archivo “sqlnet.
ora” (para que toda la información acerca de cómo establecer la comunicación sea conocida
tanto por el servidor como por el cliente).
Accede al recurso digital Configuración de las conexiones y configura los distintos ficheros de
gestión de red de Oracle para poder establecer una conexión entre el cliente y el servidor.
2.7.3. Configuración de la instancia de Oracle

Existen gran cantidad de parámetros de configuración de la instancia de Oracle, que permiten
realizar una configuración muy detallada de la misma. Cuando se arranca la instancia, se lee un
fichero llamado SPFILE (Server Parameter File, archivo de parámetros del servidor), donde se
guardan los valores de todos estos parámetros. Este fichero solo se puede editar usando las he-
rramientas que provee el sistema gestor de base de datos a tal efecto (a través del EM o usando
la sentencia ALTER SYSTEM en un intérprete SQL), y no se puede modificar su contenido
accediendo a él directamente desde el sistema operativo.
Capítulo 2
En Oracle 19c el archivo de parámetros SPFile está en:
● Linux/Unix: ORACLE_HOME/dbs/spfileSID.ora.
● Windows: ORACLE_HOME/database/spfileSID.ora.
Donde el SID es el identificador de la base de datos (por defecto “orcl”).

Existen dos tipos de parámetros de configuración en Oracle: parámetros estáticos y pará-
metros dinámicos.
a) Los parámetros dinámicos pueden modificarse por medio de una sentencia SQL con
la base de datos en funcionamiento, y se pueden modificar a nivel de sesión (ALTER
SESSION, modificaría el valor del parámetro inmediatamente pero solo para la sesión
en la que se ejecuta esa sentencia de modificación del parámetro) o a nivel de sistema
(ALTER SYSTEM, modifica el valor del parámetro de manera inmediata para todas las
sesiones).
b) Los parámetros estáticos se pueden modificar por medio de una sentencia SQL o direc-
tamente modificando su valor en el fichero de configuración SPFILE, pero el cambio
no será efectivo inmediatamente, sino que se realizará cuando se reinicie la instancia.
Para modificar el valor de los parámetros por medio de comandos SQL, usaremos:
ALTER [SYSTEM | SESSION] SET parámetro=valor [COMMENTS = comentarios]

[SCOPE={SPFILE | MEMORY | BOTH }]
Donde:
– ALTER SYSTEM realiza la modificación a nivel de sistema.

– ALTER SESSION realiza la modificación a nivel de sesión.
– SCOPE determina cuándo se produce el efecto del parámetro. Puede tomar los va-
lores: “SPFILE” (modifica el valor en el archivo de parámetros SPFILE y sus efectos
se verán en el siguiente arranque), “MEMORY” (el cambio se graba en memoria
y se produce inmediatamente, pero no modifica el SPFILE, por lo que al reiniciar la
instancia el parámetro recuperará el valor que tenía anteriormente, que será el que
figure en el SPFILE) o “BOTH” (realiza la modificación tanto en memoria como en
el SPFILE). Tan solo los parámetros dinámicos pueden tener SCOPE=MEMORY
o SCOPE=SPFILE, ya que los estáticos solamente se pueden modificar a partir del
próximo reinicio.
Los valores de los parámetros de configuración (tanto el actual como el que figura en el
SPFILE) se pueden consultar usando el interfaz gráfico del EM o el Developer, pero también
por medio de:
● El comando SHOW PARAMETERS y la vista V$SYSTEM_PARAMETER, que

muestran los valores de los parámetros en la sesión actual.
● El comando SHOW SPPARAMETERS y la vista V$SPPARAMETER, que muestran
los valores de los parámetros del archivo SPFILE.
● La vista V$PARAMETER, que contiene el valor de los parámetros de la sesión actual.
Capítulo 2
Accede al recurso digital Parámetros de configuración y comprueba cómo consultar

los valores de los parámetros del fichero de configuración SPFILE y practica la modifica-
ción de valores de los parámetros de la instancia, tanto a nivel de sesión como de sistema.
2.7.4. Configuración del almacenamiento

Cada instancia de Oracle dispone por defecto de los siguientes tablespaces:
● SYSTEM: tablespace del sistema donde se almacena el diccionario de datos.

● SYSAUX: tablespace adicional donde se almacenan determinados metadatos. Es tam-
bién un tablespace del sistema, por lo que no es posible eliminarlo ni cambiarle el
nombre.
● TEMP: tablespace temporal, donde se guardan los resultados parciales de las consultas.
● UNDO: tablespace de deshacer, usado en las operaciones de rollback para restaurar más
rápidamente la base de datos a su estado anterior a una transacción.
● USERS: tablespace que se asigna por defecto a todos los usuarios que se creen en el
sistema gestor para que almacenen su información.
¿Sabías que...?
Cuando se inicia una transacción que realiza modificaciones sobre los datos, en el ta-
blespace de UNDO se van almacenando las “vistas” de los datos tras cada cambio, lo
que permite no solo recuperar el estado anterior a la transacción en caso de que sea ne-
cesario realizar un rollback (si falla la transacción hay que deshacer todos sus cambios),
sino que permite que los demás usuarios puedan seguir viendo el estado consistente de
los datos anterior a la transacción hasta que esta se confirme (se ejecuté un COMMIT),
momento en que pasarían a ver todos los datos actualizados por la transacción.
La sentencia básica para crear un tablespace es la siguiente:
CREATE [TEMP | UNDO] TABLESPACE nb_tablespace

DATAFILE ‘C:/APP/ORACLE/ORADATA/ORCL/PDBORCL/nb_tablespace01.DBF’ SIZE 5M,
‘C:/APP/ORACLE/ORADATA/ORCL/PDBORCL/nb_tablespace02.DBF’ SIZE 10M
AUTOEXTEND ON NEXT 200K MAXSIZE 50M;
Donde:
– Añadiendo UNDO o TEMP crearíamos un tablespace de deshacer o temporal respec-

tivamente. Si no indicamos nada, será un tablespace de usuario.
Capítulo 2
– Un tablespace puede tener varios datafiles, que se indicarán separados por comas. Es
obligatorio indicar el tamaño inicial de cada uno de ellos.
– AUTOEXTEND indica si los datafiles incrementarán su tamaño automáticamente
cuando se queden sin espacio. Si se pone a ON, habrá que indicar cuánto espacio se
reservará en cada incremento (ON NEXT), y se podrá indicar un tamaño máximo
(MAXSIZE) a partir del cual no se reservará más espacio.
Podemos añadir o eliminar datafiles del tablespace usando la sentencia ALTER.
Ejemplo
ALTER tablespace users ADD datafile ‘C:/app/oracle/oradata/orcl/pdborcl/users02.dbf’ size 100M;

ALTER tablespace users DROP datafile ‘C:/app/oracle/oradata/orcl/pdborcl/users02.dbf’;
2.7.5. Cuentas de administración

Durante la instalación de Oracle, se crean tres cuentas especiales con permisos de administración:
a) SYS: el esquema SYS almacena todas las tablas del diccionario de datos. Estas tablas no
pueden modificarse, ni se pueden crear nuevas tablas en este esquema. No es posible
tampoco acceder directamente a los datos de las tablas del esquema SYS, sino que se
accederá empleando las numerosas vistas existentes en el esquema, y normalmente
usando el zSYSTEM en lugar de SYS. Tanto SYS como SYSTEM tienen por defecto
asignado el rol DBA.
b) SYSTEM: el usuario SYSTEM se utiliza para operaciones de administración sobre la
base de datos. Contiene un esquema externo del esquema SYS (de forma que puede
acceder a todas sus tablas empleando las vistas creadas al efecto), y puede crear tablas y
vistas adicionales que muestran información administrativa, tablas internas y vistas utili-
zadas por varias opciones y herramientas de la base de datos Oracle. No se debe utilizar
el esquema SYSTEM para almacenar tablas de usuarios no administradores. El usuario
system puede llevar a cabo todas las tareas del usuario SYS excepto operaciones de
backup y recuperación, y actualizaciones del SGBD.
c) PDBADMIN: en una instancia de Oracle 19c existen dos tipos de usuarios: locales (locales
a cada PDB), y comunes (comunes a la instancia, y por tanto a todos los PDB del mismo
contenedor). La información del diccionario de datos relativa a los usuarios locales se al-
macena en el esquema SYS de cada PDB, mientras que la información común se guardará
en el esquema PDBADMIN, que será administrador de todo el contenedor (CDB).
Toma nota
Para establecer una conexión con el usuario SYS, siempre hay que hacerlo asignándole
el rol de dba, independientemente de la herramienta utilizada. Con el SQL Plus:
SQL> conn sys@orcl as sysdba
Capítulo 2
Aparte de estas cuentas de usuario, sería posible crear cuentas de administración adicionales
asignando el rol DBA (database administrator) a los usuarios que corresponda.
2.7.6. Creación y borrado de bases de datos

Oracle dispone de un asistente, el dbca (database configuration assistant) para facilitar tanto la
creación de instancias y PDB como su eliminación y modificación. Usar este asistente no solo
es la forma más sencilla de realizar estas tareas, sino que también es la más segura.
Recuerda
3 Es importante tener en cuenta que el concepto de base de datos (o PDB) no

hace referencia a un esquema de bases de datos, sino a la estructura física de
almacenamiento de datos del sistema gestor de base de datos.
3 Para crear un esquema de base de datos solamente será necesario crear un
usuario, ya que cada usuario tiene asociado su propio esquema.
2.7.7. Ficheros de LOG

Existen varios archivos de log para monitorizar los distintos aspectos de Oracle. Entre ellos:
● alert LOG. Registra sucesos de la gestión general de la base de datos: errores internos,
operaciones de modificación de la base de datos, modificaciones en los parámetros de
configuración, etc.
● LOG de procesos en background. Registra los sucesos provocados por los procesos en
ejecución de Oracle.
● LOG de usuarios. Monitoriza la actividad de los usuarios.
Estos ficheros se gestionan normalmente a través del EM, pero es posible hacerlo con las
vistas del diccionario de datos, como V$DIAG_INFO para el alert log.
Además, los principales servicios del servidor tienen sus propios logs:
– $ORACLE_HOME/startup.log: almacena los mensajes de error producidos al arrancar

el servidor.
– $ORACLE_HOME/listener.log: guarda mensajes de error al arrancar el listener.
2.7.8. Arranque y parada del sistema gestor de bases de datos

El servidor Oracle se puede iniciar o detener a través de servicios del sistema operativo, pero
también podemos modificar su estado ejecutando sentencias a través del interfaz de comandos.
A) Procesos y servicios del sistema gestor de bases de datos

Cuando se instala Oracle en Windows se crean automáticamente los servicios:
Capítulo 2
● OracleJobScheduler<INSTANCIA>: es el servicio utilizado por el planificador de ta-

reas de Oracle (scheduler). Por defecto este servicio estará desactivado.
● OracleOraDB19Home1MTSRecoveryService: servicio encargado de la gestión de
transacciones distribuidas. En un sistema distribuido pueden coexistir diversos sistemas

gestores, por lo que implementar la gestión de transacciones en este tipo de sistemas es
más complejo. Este servicio es parte del sistema encargado de realizar este control de
transacciones.
● OracleOraDB19Home1TNSListener: servicio que ejecuta el listener para atender las
peticiones de los clientes. Permite iniciar o detener el listener fácilmente.
● OracleService<INSTANCIA>: es el servicio más importante, ya que es el que ejecuta
la instancia de base de datos. Por medio de este servicio se podrá arrancar y parar la
instancia. Cada instancia tendrá un servicio como este.
● OracleVssWriter<INSTANCIA>: VSS es una tecnología de Windows para realizar
“copias en la sombra” (shadow copys), una especie de instantáneas de los datos en un

momento concreto. Este servicio se utiliza para llevar a cabo tareas de backup y recu-
peración de la instancia.
Durante el proceso de instalación se crea adicionalmente un servicio adicional llamado

“OracleRemExecService”. Este servicio es usado por el asistente de instalación (OUI) y el
asistente de creación de bases de datos (DBCA) cuando se instala el sistema gestor, y tras la
instalación se deshabilita y se elimina automáticamente al reiniciar el equipo.
La instalación en sistemas UNIX/Linux no incorpora la creación de servicios, por lo que
para arrancar automáticamente el servidor y el listener cuando se inicia el equipo es necesa-
rio crear manualmente los servicios que se encarguen de hacerlo (añadiendo un script en “/
etc./init.d” que se encargue de definir las variables de entorno ORACLE_BASE, ORACLE_
HOME y ORACLE_SID), actualizar el PATH del sistema para incorporar la carpeta “ORA-
CLE_HOME/bin” y ejecutar tanto la aplicación que inicia la instancia (“ORACLE_HOME/
bin/dbstart”) como el listener (“ORACLE_HOME/bin/lsnrctl”).
B) Estados del servidor

Para arrancar y parar el SGBD Oracle se puede hacer directamente por medio del servi-
cio OracleService<INSTANCIA>, pero esto tiene algunas limitaciones, ya que únicamente
permite dejar la base de datos o completamente parada (en estado shutdown) o completa-
mente iniciada (en estado open), y en esos estados no es posible realizar algunas tareas de
administración, por lo que para llevar a cabo esas tareas tendríamos que utilizar la consola
de Oracle (SQL Plus) y abrir la instancia en un estado intermedio. La instancia puede estar
en cuatro estados:
1. Shutdown
En este estado la base de datos está cerrada, y todos sus procesos parados. No es muy fre-
cuente parar una base de datos, aunque nos puede interesar hacerlo para realizar operaciones
para las cuales necesitemos que no haya ningún proceso ejecutándose en la base de datos
(instalar un parche o actualización, realizar determinadas operaciones de mantenimiento…).
Capítulo 2
Cuando se para la base de datos, no se acepta ninguna solicitud de conexión contra la misma, y
es necesario especificar cómo se tratarán las conexiones en curso:
SQL> SHUTDOWN {NORMAL | TRANSACTIONAL | IMMEDIATE | ABORT};
Donde:
– NORMAL: no se aceptan conexiones nuevas, pero el sistema no finaliza hasta que no

finalicen las conexiones en ejecución.
– TRANSACTIONAL: no acepta conexiones nuevas y cierra las que estén en ejecución
excepto aquellas que hayan iniciado alguna transacción que este en ejecución.
– IMMEDIATE: no acepta nuevas conexiones, cierra las que no tengan transacciones
activas y ejecuta un rollback en todas las trasnsacciones en ejecución.
– ABORT: realiza un apagado inmediato, sin grabar nada en disco.
2. Nomount
Cuando se inicia la instancia en estado nomount, se leen algunos parámetros del archivo
de inicialización (SPFILE) y se configura la instancia: se reserva todo el espacio necesario
en memoria (SGA, PGA, etc.) pero solo se ejecutarán los procesos básicos, por lo que no es
posible conectar con la base de datos. Hay algunas operaciones de recuperación que requie-
ren que la base de datos esté en estado nomount (por ejemplo, si la base de datos ha fallado
y es necesario recuperar los archivos de redo log habría que hacerlo iniciando la instancia en
modo nomount). También queda normalmente en este estado cuando hay algún error en los
parámetros de inicialización y no es capaz de iniciar la instancia. Para arrancar una base de
datos parada en estado nomount:
SQL> STARTUP NOMOUNT;
3. Mount
Al estado anterior se añade la lectura de los archivos de control para optimizar el funciona-
miento de la instancia. En este estado, Oracle localiza donde están ubicados los datafiles, pero no
los abre todavía, por lo que los usuarios seguirán sin poder conectarse a la base de datos pero
permitirá realizar tareas administrativas relacionadas con los datafiles. Para arrancar una base de
datos parada en estado mount usaríamos el comando:
SQL> STARTUP MOUNT;
Para montar una base de datos ya iniciada en estado nomount:
SQL> ALTER DATABASE MOUNT;
Capítulo 2
4. Open
En este estado, la base de datos está abierta, con todos sus procesos en ejecución y disponible
para los usuarios. Para iniciar una base de datos parada:
SQL> STARTUP OPEN;
Para abrir una base de datos en estado mount o nomount:
SQL> ALTER DATABASE OPEN;
C) Arranque y parada de las Pluggable Database

En las versiones de Oracle anteriores a Oracle 12c, cada instancia estaba compuesta de una
base de datos, y al arrancar la instancia, automáticamente se monta la instancia y se abre la base
de datos, por lo que ya se puede comenzar a trabajar con ella directamente.
A partir de la versión 12c, esto no es así: una base de datos puede estar compuesta de varias
PDB (Pluggable Databases), y el servidor no almacena el estado de las mismas, de forma que
cuando se arranca la instancia, Oracle monta todas las PDB (es decir, las prepara para poder ac-
ceder a ellas) pero únicamente abre el contenedor principal (CDB$ROOT), y el resto de PDB
permanecerán cerradas y no aceptarán conexiones.
SQL> select * from v$pdbs

NAME OPEN_MODE
------------------------------ ----------
PDB$SEED READ ONLY
PDBORCL MOUNTED
Cuando nos conectamos a la instancia, nos estaremos conectando al contenedor principal

(CDB$ROOT), donde únicamente podremos llevar a cabo tareas de administración de la ins-
tancia. Para trabajar con una PDB concreta (para poder crear esquemas, tablas, etc.), tendremos
que modificar la conexión para trabajar con la PDB que queramos:
SQL> select PDB from v$services;

PDB
------------------------------
PDBORCL
CDB$ROOT
SQL> alter session set container=pdborcl;
Si habitualmente trabajamos con una o varias PDB concretas y queremos que estas se ini-
cien automáticamente al arrancar la instancia, podemos guardar el estado de la PDB, de forma
que al arrancarlo lo deje en el estado que hemos guardado.
Capítulo 2
SQL> alter pluggable database pdborcl open;

Pluggable database altered.
SQL> alter pluggable database pdborcl save state;
Pluggable database altered.
Accede al recurso digital Arranque y parada y configuración del almacenamiento en el

que se propone la creación de un tablespace con dos archivos de datos y se indican los pasos ne-
cesarios para poder cambiar la ubicación de dichos archivos, lo que requiere detener la instancia
y abrirla en un estado intermedio que permita mover físicamente los archivos a la nueva ubicación.
2.7.9. El diccionario de datos en Oracle

La información del diccionario de datos en Oracle se almacena en el esquema del usuario SYS.
Este usuario es un usuario común a todas las PDB de la instancia, por lo que está creado en la
base de datos del contenedor (CDB$ROOT), y existe en todas las PDB. En el esquema aso-
ciado a este usuario en el CDB$ROOT, se almacena toda la información común a la instancia:
PDB existentes, usuarios globales, tablespaces del sistema, sistemas de encriptación, etc.; mien-
tras que, en el esquema del usuario SYS existente en cada PDB, se almacenará la información
propia de esa base de datos:
● Todos los objetos existentes (tablas, secuencias, índices, tablespaces, etc.).

● Todos los usuarios y esquemas locales, así como sus roles y permisos.
● Todos los procedimientos del sistema. Normalmente todos los procedimientos relacio-
nados con una misma funcionalidad se agrupan en un mismo paquete (por ejemplo el
paquete DBMS_CRYPTO contiene todos los procedimientos existentes para encrip-
tar y desencriptar información en Oracle).
La información del diccionario de datos se puede consultar por medio de vistas dinámicas
(cada vista generalmente muestra información de algún tipo de objeto: tablas, columnas, vistas,
sinónimos, enlaces, procedimientos, etc.).
Para cada objeto de la base de datos existen tres vistas en el diccionario de datos, cada una
de ellas con un prefijo diferente:
a) USER_: muestra los objetos que pertenecen al usuario que hace la consulta.
b) ALL_: muestra todos los objetos a los que el usuario tiene acceso (sean o no de su propie-
dad): si el usuario A da permiso de consulta sobre sus tablas al usuario B, cuando el usuario
B consulte la vista ALL_TABLES le aparecerán sus propias tablas y las del usuario A.
c) DBA_: muestra todos los objetos de la base de datos. Existen objetos del sistema de los
cuales solamente existe la vista DBA_, ya que los usuarios no pueden poseer dichos
objetos y por tanto no podrían consultar únicamente los objetos de ese tipo que le
pertenezcan (por ejemplo DBA_TABLESPACES).
Capítulo 2
Todos los usuarios tienen acceso a las vistas USER_ y ALL_, pero únicamente los que
tengan permisos de DBA (o se les haya asignado expresamente el permiso de acceso) pueden
acceder a las vistas DBA_.
Recuerda
3 En el diccionario de datos de Oracle la información se guarda siempre en mayúsculas, y

distingue mayúsculas de minúsculas, por lo que si queremos buscar la tabla “VENTAS”,
debemos poner el nombre de la tabla en mayúsculas:
Select * from user_tables where table_name=’VENTAS’;
Existen además vistas que permiten consultar información de la instancia, que suelen co-
menzar por el prefijo V$.
Figura 2.6
Ejemplo de vistas del
diccionario de datos
de Oracle.
Resumen
n Una vez finalizada la instalación de la base de datos, es necesario realizar una configura-
ción básica para poder establecer conexión con el servidor, lo que implicará configurar:
– El entorno (nombre y dirección del equipo y variables de entorno).

– Las conexiones (tanto en cliente como en servidor), los parámetros de configura-
ción del servidor (en el fichero de configuración del servidor o en caliente).
– El almacenamiento (creación de tablespaces para disponer de estructuras lógicas
para gestionar el almacenamiento).
– Las cuentas de usuario administrador (para poder emplearlas para conectarnos).
n Lo más sencillo para arrancar y parar el SGBD es emplear servicios que se encarguen
de arrancar automáticamente el sistema gestor cuando se inicie el servidor, aunque
en ocasiones es necesario iniciar el SGBD a mano para poder realizar determinadas
tareas de administración.
Capítulo 2
n La mayoría de las principales funcionalidades del sistema gestor hacen uso de dos he-
rramientas fundamentales: el diccionario de datos (donde se almacenan todos los me-
tadatos, la información acerca de todos los objetos de la base de datos) y el cuaderno
de bitácora (donde se registran todas las modificaciones realizadas sobre los datos).
n Es muy importante para el administrador de base de datos mantener correctamente
definida y actualizada la documentación del sistema gestor, para disponer en todo
momento de la información necesaria para poder contactar con el soporte de la he-
rramienta, tener catalogados perfectamente todos los servidores y bases de datos exis-
tentes en la organización, conocer qué usuarios tienen acceso y qué permisos o roles
tiene cada uno de ellos, y especialmente tener definidos los procedimientos necesa-
rios para garantizar una correcta administración del sistema.
1. Hemos cambiado la IP del servidor en el que tenemos instalado el SGBD Oracle.
¿Qué archivo deberíamos revisar para garantizar que el SGBD siga escuchando co-
rrectamente en espera de conexiones de los clientes?
2. Has definido una nueva entrada en tu TNSNAMES. ¿Qué comando podrías utilizar
para comprobar si la conexión funciona correctamente?
3. ¿Qué comando tendrías que ejecutar para comprobar el estado del listener de Oracle
y saber qué servicios están activos y escuchando por conexiones?
4. Crea un tablespace “rrhh” con dos datafiles (rrhh01 y rrhh02), ambos de 10M, que no
serán autoextensibles. Los datafiles se guardarán en el directorio donde se almacenan
el resto de datafiles de la PDB “pdborcl”. El resto de parámetros se mantendrán los
que asigne Oracle por defecto.
5. Tenemos la instancia en estado NOMOUNT y queremos mover los datafiles “rrhh01” y
“rrhh02” a una subcarpeta llamada “recursos_humanos”. ¿Qué sentencia tendremos que
ejecutar para poner la instancia en el estado adecuado para poder mover los datafiles?
6. Indica la sentencia que tendrías que ejecutar para desactivar la papelera de reciclaje
de Oracle a nivel de sesión.
7. Indica las sentencias que podrías ejecutar en Oracle para asegurar que cuando se
reinicie la instancia el parámetro “optimizer_mode” tome el valor “FIRST_ROWS”.
8. Emplea el SQL Developer para comprobar cuántos datafiles tiene por defecto el ta-
blespace del sistema.
9. El valor que tiene asignado el parámetro “nls_language”, ¿es el valor que tenía por
defecto?, ¿por qué?
10. ¿En qué ruta se almacena el primer fichero de control de la instancia?
Resumen
Capítulo 2
1. Contiene información permanente de los cambios realizados en la base de datos:
a) Tablespace del sistema.
b) Tablespace de UNDO.
c) Archivo de control.
d) Cuaderno de bitácora.
2. ¿En qué nivel de diseño de la base de datos se determina el contenido de los archivos
de configuración?
a) Interno.
b) Conceptual.
c) Lógico.
d) Externo.
3. ¿Cuál de las siguientes afirmaciones referentes al diccionario de datos es incorrecta?

a) El sistema gestor de base de datos lo consulta antes de realizar cualquier ope-
ración de manipulación de datos.
b) Debe ser actualizado periódicamente por parte de los usuarios.
c) Almacena metadatos.
d) Es una base de datos del sistema.
4. La documentación de un sistema gestor de base de datos debe de guardar, entre otros,

los siguientes datos (señala la incorrecta):
a) Capacidad de almacenamiento del servidor.
b) Programa empleado para redactar la documentación.
c) Versión del sistema operativo instalada en el servidor.
d) Actualizaciones de las versiones del sistema gestor de base de datos insta-
ladas.
5. ¿Cuál de los siguientes parámetros no es necesario configurar en el servidor para per-

mitir el establecimiento de conexiones por parte de los usuarios?
a) Las credenciales que se usarán para identificar al usuario.
b) El método de encriptación que se empleará en las conexiones encriptadas.
c) El puerto donde escuchará las conexiones.
d) El protocolo de comunicación.
6. ¿Para qué se utiliza el tablespace temporal?

a) Para almacenar tablas del sistema.
b) Para almacenar la información necesaria para deshacer las transacciones en
curso.
c) Para almacenar resultados parciales de las consultas de usuario.
d) Para gestionar el envío de información a los usuarios.
Capítulo 2
7. ¿En cuál de los siguientes tablespace es más crítico mantener controlado su porcentaje
de ocupación?
a) De sistema.
b) Temporal.
c) De UNDO.
d) Todas son correctas.
8. ¿Cuál de las siguientes operaciones requerirá un inicio del SGBD a un estado interme-
dio, en el que no acepte peticiones de los usuarios?
a) La eliminación de un usuario.
b) La eliminación de un archivo de datos.
c) La eliminación de un esquema.
d) La eliminación de un tablespace.
9. Queremos ejecutar un script que compruebe qué tablas no tienen definido un índice
en su clave primaria y lo cree automáticamente. ¿Qué herramienta tendría que em-
plear dicho script?
a) El cuaderno de bitácora.
b) El tablespace del sistema.
c) El diccionario de datos.
d) El registro de transacciones.
10. ¿Qué se registra en el cuaderno de bitácora?

a) Las manipulaciones realizadas sobre los datos.
b) Modificaciones realizadas en la estructura de los objetos.
c) Las consultas realizadas contra el sistema gestor.
SOLUCIONES:
a b c
1. d 5.
a b c d
a b c
2. a b c d 9.
d 6. a b c d
a b c
3. a b c d 10.
d 7. a b c d
a b c
4. a b c d
d 8.
Capítulo 2
3
Gestión de usuarios
y permisos
Objetivos
3 Conocer los mecanismos existentes en el sistema gestor para garantizar la
confidencialidad de los datos por medio de un sistema de autenticación de
usuarios y la asignación de permisos y restricciones.
3 Comprender el concepto de esquema externo y su funcionamiento.
3 Analizar las posibilidades existentes en cuanto a los usuarios, roles, permi-
sos, perfiles, vistas y sinónimos que es necesario crear en distintos contextos.
3 Adquirir el hábito de emplear el diccionario de datos para realizar tareas
masivas relacionadas con la gestión de usuarios y permisos.
Mapa conceptual
Usuarios y permisos Usuarios
Permisos
Roles
Perfiles
Esquemas externos Vistas
Sinónimos
realiza Funciones
Puesta en marcha
Seguridad Usuarios y permisos
Esquemas externos
Explotación
Administración
Glosario
Lenguaje de control de datos (DCL: Data Control Language). Es uno de los sublenguajes
de SQL, responsable de la gestión de permisos: permite asignar o quitar permisos a
usuarios o roles, y asignar o quitar roles a usuarios.
Esquema conceptual. El esquema conceptual de una base de datos establece los datos
que forman parte de la base de datos y las relaciones que se establecen entre ellos.
Una base de datos tendrá un único esquema conceptual.
Capítulo 3
Gestión de usuarios y permisos 81
Esquema externo. El esquema externo de un usuario es la parte de la base de datos que se

mostrará al usuario. Una base de datos tendrá tantos esquemas externos como visio-
nes distintas de los datos tengan los usuarios.
Perfil. Conjunto de limitaciones. Los perfiles permiten gestionar de manera conjunta res-
tricciones sobre los recursos que pueden usar los usuarios y condiciones que tienen
que cumplir las cuentas de usuario (especialmente en lo referente a las políticas de
contraseñas).
Rol. Conjunto de privilegios. Los roles permiten gestionar varios privilegios de manera
conjunta, facilitando la asignación de permisos a los usuarios.
Sinónimo. Objeto de base de datos que permite establecer una referencia a otro objeto,
de manera análoga a cómo funciona un acceso directo a un fichero. Simplifican los
accesos a objetos de otros esquemas y permiten denominar de manera homogénea a
los objetos de bases de datos a los que pueden acceder los usuarios.
Usuario externo. Es una credencial de acceso a la base de datos cuya autenticación no
la lleva a cabo el sistema gestor, sino que la delega en algún sistema externo (nor-
malmente el sistema operativo o sistemas de autenticación de usuarios en red como
Radius, LDAP o Kerberos).
Vista. Consulta que se almacena como un objeto lógico de base de datos. Las vistas tienen
la misma estructura que una tabla: filas y columnas, pero de ellas solamente se alma-
cena la definición, no los datos (no ocupan espacio).
3.1. Introducción
Una vez instalado y configurado el sistema gestor para poder comenzar a trabajar con él, será
necesario habilitar el acceso a los usuarios para que puedan acceder al sistema. Normalmente
los sistemas gestores de bases de datos instalados en entornos de producción son sistemas mul
tiusuario, por lo que es necesario gestionar adecuadamente qué usuarios serán los que podrán
acceder al sistema y qué información podrá ver o qué operaciones podrá realizar cada usuario,
para garantizar la confidencialidad de los datos almacenados en las bases de datos.
La sintaxis necesaria para crear usuarios o asignar permisos en cualquier sistema gestor de base
de datos es muy sencilla de encontrar por medio de una búsqueda en internet. Lo que no es tan
sencillo es saber qué usuarios, roles o perfiles es necesario crear para ajustarse a los requisitos de
acceso a la información definidos por los clientes, y esa será la otra labor que deberá llevar a cabo el
DBA: analizar qué usuarios será necesario crear y definir el esquema externo de cada uno de ellos.
3.2. Gestión de usuarios y permisos

La gestión de usuarios y permisos es la función responsable de controlar los usuarios que acce
den a la base de datos y los tipos de operaciones que están autorizados a realizar.
Capítulo 3
Los sistemas gestores permiten implementar esta función por medio de varios meca
nismos:
● Autenticación de usuarios: para acceder a la información de las bases de datos los usuarios
tendrán que identificarse, lo que garantiza que solamente tengan acceso a la base de datos
los usuarios con permiso. Cada usuario tendrá acceso a su esquema externo de la base
de datos. El registro de los usuarios que acceden a la base de datos permitirá también
implementar funciones de monitorización y auditoría.
● Permisos y roles: la asignación de permisos a los usuarios garantizará que los usuarios
únicamente puedan acceder a aquellos objetos o funciones para las que tengan permiso.
Los permisos pueden hacer referencia al uso que el usuario hará del sistema gestor de
base de datos (permisos del sistema) o a las operaciones que podrá ejecutar sobre los
objetos de las bases de datos (permisos de objetos). Los roles permiten definir grupos
de usuarios con permisos comunes.
● Cuotas y perfiles: permiten delimitar la disposición de recursos a determinados usuarios.
Toma nota
Para poder llevar a cabo la creación de usuarios y roles y la asig-

nación de permisos, el sistema gestor provee del DDL, para crear
los usuarios y roles, y un DCL, que será el que permitirá asignar o
quitar permisos a los usuarios y roles y asignar roles a los usuarios.
De nada sirve en cualquier caso controlar los privilegios de los usuarios dentro del servidor
de bases de datos si fuera del servidor, en el entorno del sistema operativo, estos usuarios tienen
libre acceso al sistema de ficheros. Para evitarlo, el responsable de sistemas deberá mantener bajo
control los permisos de acceso de los siguientes archivos:
– Los archivos de datos, donde se guardan las bases de datos y sus tablas. Los usuarios no
autorizados no pueden acceder a estos archivos directamente.
– Ficheros de logs y de estado. Los usuarios no autorizados no deberían tener acceso a
esta información ya que podrían detectar vulnerabilidades en el sistema.
– Ficheros de configuración, para que usuarios no autorizados no puedan reemplazarlos
o modificarlos.
– Programas y scripts que manejan y acceden a bases de datos, para que los usuarios no
puedan reemplazarlos o modificarlos.
Ten en cuenta
Todos los usuarios, roles, permisos, cuotas, vistas, etc., que creemos serán objetos
del sistema gestor, por lo que se almacenarán en el diccionario de datos. Esto es muy
importante de cara a la automatización de tareas de gestión de usuarios y permisos,
ya que podremos consultar en el diccionario de datos si hay alguna anomalía ante la
que debamos responder, comprobar los usuarios que tengamos para realizar alguna
operación sobre ellos, etc.
Capítulo 3
3.2.1. Usuarios
La autenticación de usuarios en el sistema gestor está muy ligada al sistema de asignación de

permisos, ya que para poder establecer una conexión contra el SGBD es necesario disponer
de un usuario que tenga permisos para poder establecer esa conexión.
Todos los sistemas gestores implementan mecanismos internos de autenticación de sus
propios usuarios, es decir, permiten crear usuarios internos en el propio sistema que se
pueden utilizar para establecer conexiones. Dado que habitualmente los sistemas gestores
de bases de datos están basados en una arquitectura cliente/servidor y son servidores englo
bados en una arquitectura corporativa que dispone de otros sistemas de autenticación de
usuarios (LDAP, radius, Kerberos, etc.), es habitual que los sistemas gestores permitan la
integración con estos sistemas delegando en ellos el proceso de autenticación de usuarios
externos al sistema gestor, pero gestionando internamente los permisos que tiene asociada
cada cuenta de usuario.
La forma de gestionar el acceso de los usuarios a los esquemas depende mucho del sistema
gestor que empleemos:
● En Oracle se denomina esquema al conjunto de objetos que es propiedad de un usua

rio concreto. Dichos objetos pueden ser tablas, vistas, índices, procedimientos, funcio
nes, triggers, etc. Cuando se crea un usuario en Oracle, se crea automáticamente un
esquema para ese usuario, por lo que el usuario podrá crear sus propios objetos de base
de datos en su esquema.
● En MySQL un esquema es, a grandes rasgos, una base de datos tal y como se entiende
en un SGBD de escritorio (como Access o Base), y los usuarios solamente pueden co
nectarse y ver objetos de las bases de datos, pero no pueden tener sus propios objetos
(sinónimos, procedimientos, vistas o incluso índices).
● SQL Server emplea el esquema como una estructura de almacenamiento, y, en el es
quema, se crean bases de datos a las que pueden acceder los usuarios (de forma similar
a MySQL).
La sintaxis empleada para crear usuarios es también dependiente del sistema gestor, ya que
cada sistema dispone de distintas variantes a la hora de gestionar los usuarios, aunque en todos
ellos suele ser bastante similar, basada en el estándar de SQL:
CREATE USER <nb_usuario> IDENTIFIED BY “<contraseña>”;
Para modificar un usuario se utiliza ALTER USER. Las modificaciones que se puedan
realizar sobre un usuario dependerán del sistema gestor:
– Cambiar la contraseña.
– Bloquear o desbloquear un usuario (impidiéndole el acceso al sistema gestor).
– Establecer limitaciones o asignar perfiles.
– Etc.
ALTER USER <nb_usuario> IDENTIFIED BY “<nueva_contraseña>”;
Capítulo 3
Para borrar un usuario se utiliza DROP:
DROP USER <nb_usuario> [CASCADE];
La opción CASCADE permite eliminar no solo el usuario sino también todos sus objetos
de su esquema (solo es válida por tanto en los sistemas gestores que asocian un esquema a cada
usuario). La sentencia DROP USER es una sentencia del DDL, por lo que si se borra un usua
rio y todo su contenido no es posible recuperarlo posteriormente por medio de un rollback.
3.2.2. Permisos
Los permisos determinan las operaciones que pueden llevar a cabo los usuarios en el sistema
gestor. En un SGBD se pueden asignar dos tipos de permisos:
a) Permisos del sistema: permisos relacionados con las operaciones que el usuario podrá
realizar en el SGBD (conectarse, crear tablas o cualquier otro objeto, consultar infor
mación o llevar a cabo tareas de administración, acceder al EM, etc.). La sintaxis para
conceder un permiso de sistema a un usuario, a un rol o a todo el mundo (PUBLIC,
no muy aconsejable) es:
GRANT privilegio TO [usuario | rol | PUBLIC]

[WITH ADMIN OPTION]; -- permite reasignar el permiso a otros usuarios
b) Permisos sobre objetos: determinan las operaciones que un usuario podrá realizar sobre un
objeto de base de datos. Los permisos que se pueden conceder sobre los objetos son:
SELECT, INSERT, UPDATE, DELETE (para consultar, insertar, modificar o borrar
datos de tablas o vistas), ALTER (modificar la estructura), EXECUTE (ejecutar pro
cedimientos o funciones), INDEX (crear índices), REFERENCES (para definir una
clave foránea a una tabla que no es de su esquema) y ALL (todos los permisos). Al igual
que los permisos del sistema, pueden concederse con la posibilidad de que el receptor
los reasigne a otros usuarios. La sintaxis es:
GRANT privilegio ON propietario.objeto TO [usuario | rol | PUBLIC]

[WITH GRANT OPTION]; -- para permitir reasignarlo
Para quitar privilegios, tanto de sistema como sobre objetos, se utiliza REVOKE:
REVOKE privilegio FROM [usuario | rol];
3.2.3. Roles
Los roles son conjuntos de privilegios que facilitan la asignación de permisos a los usuarios. Si
varios usuarios de base de datos tienen un comportamiento similar en cuanto a las operaciones
que pueden llevar a cabo sobre el sistema gestor, o sobre los objetos que pueden ver, en lugar
Capítulo 3
de asignar los permisos a los usuarios directamente, se crearía un rol, se asignarían los permisos
al rol, y luego se asignaría el rol a los usuarios. De esta manera, si más tarde es necesario crear
un usuario al que se asignarán los mismos permisos, solo haría falta asignarle el rol a ese usuario
y ya podría hacer exactamente lo mismo que los otros usuarios que tienen ese rol. Si hubiese
que añadir un nuevo permiso a esos usuarios, con asignárselo al rol ya se les asignaría automá
ticamente a todos ellos.
Para facilitar la administración, los sistemas gestores suelen disponer de algunos roles prede
finidos que se pueden asignar directamente a los usuarios:
– DBA: administradores del sistema gestor, con todos los permisos.

– Mantenimiento: operadores del sistema gestor (para realizar el mantenimiento del
servidor).
– Gestor de bases de datos: disponen de privilegios para gestionar las bases de datos.
– Backup: con permisos para realizar copias de seguridad de las bases de datos.
– Etc.
En cualquier caso, no se recomienda mucho usar estos roles predefinidos (especialmente

DBA) porque otorgan más permisos de los estrictamente necesarios, y lo más correcto sería
crear roles personalizados con los permisos específicos que correspondan a cada grupo de
usuarios.
Sobre los roles se pueden llevar a cabo operaciones similares a los usuarios:
a) Crear un rol:
CREATE ROLE nombre_rol;
b) Añadir privilegios a un rol:
GRANT privilegio [ON obj] TO nombre_rol;
c) Quitar privilegios a un rol:
REVOKE priv FROM nombre_rol;
d) Asignar un rol a un usuario o a otro rol:
GRANT nombre_rol TO [usuario | rol];
e) Quitarle un rol a un usuario:
REVOKE nombre_rol FROM [usuario | rol];
Capítulo 3
f) Borrar un rol:
DROP ROLE nombre_rol;
En algunos sistemas gestores es posible asignar más de un rol a un usuario.
3.2.4. Perfiles (profile)

Un perfil permite especificar dos tipos de restricciones que deben cumplir los usuarios:
● Una serie de limitaciones de uso de los recursos del sistema a disposición de los usua
rios para impedir un uso abusivo (voluntario o no) de los mismos: sesiones por usuario,
tiempo de espera, tiempo máximo de conexión, límites de uso de CPU, límites de ac
cesos a disco, etc.
● Un conjunto de características que deben cumplir las contraseñas para garantizar su
seguridad: número máximo de intentos de conexión erróneos para bloquear a un usua

rio, tiempo de “vida” de las contraseñas, número de veces que se debe cambiar una
contraseña antes de reutilizarla, etc.
Casi todos los sistemas gestores disponen del concepto de perfil, aunque la forma de imple
mentarlos es diferente. Suele haber dos alternativas:
1. Crear el perfil de forma similar a cómo se crean los roles y luego asignar el perfil a los
usuarios.
2. No crear el perfil como tal, sino que las limitaciones se asignan directamente a los usua
rios. Esta segunda opción permite asignar a cada usuario unas limitaciones diferentes (con
la opción anterior tendríamos que crear un perfil para cada usuario para poder aplicarle
distintas restricciones), pero es más complejo gestionar un número de usuarios elevado.
3.3. Gestión de usuarios y permisos en Oracle

Oracle permite crear usuarios propios, cuyas credenciales estarán almacenadas en el propio sis
tema gestor (que se encargará de autenticarlos), pero también permite delegar la autenticación
de los usuarios. Los usuarios cuya autenticación se puede delegar se conocen como usuarios
externos, y pueden ser usuarios del sistema operativo o usuarios que se autentiquen empleando
algún sistema adicional como LDAP, Kerberos o Radius (sistemas de autenticación en red cuyas
credenciales se validan contra un servidor remoto).
Para cada usuario externo es necesario crear un usuario del sistema gestor que esté asociado
a él. Todos los permisos se asignarán al usuario propio del sistema gestor, y cuando el usuario
externo inicia sesión, internamente lo que hace es mapear ese usuario a su usuario del sistema
gestor asociado y aplicarle todos los permisos que este tenga otorgados.
Para cada usuario del sistema gestor se crea automáticamente su propio esquema de base de
datos (conjunto de objetos) con el nombre del usuario, donde se guardarán todos los objetos
que cree ese usuario. Cuando el usuario crea cualquier objeto en su propio esquema, tendrá
Capítulo 3
todos los permisos sobre él; pero, si los objetos se crean en otro esquem,a habrá que darle per
misos específicos al usuario para que pueda acceder a ellos.
Comprueba cómo se pueden crear usuarios externos identificados por medio del sistema operativo
siguiendo los pasos descritos en el recurso digital Usuarios externos.
3.3.1. Usuarios
En la arquitectura Multitenant de Oracle, cuando se instala la instancia de base de datos se crea
un contenedor principal (al que denomina CDB, container database) que contiene una base de
datos del sistema (CDB$ROOT) y una o varias bases de datos intercambiables (PDB, pluggable
database) donde los usuarios pueden crear sus esquemas y tablas.
CDB
CDB&ROOT PDB1 PDB2 PDB3
Figura 3.1
Composición del contenedor principal (CDB).
Recuerda
3 Cuando instalamos Oracle, en el listener se crea siempre un servicio para conectarse a

la instancia (ORCL) y otro servicio para cada PDB existente en la instancia (para poder
conectarnos directamente a cada una de las PDB). Cuando nos conectamos usando el
servicio para acceder a la instancia (system@ORCL, por ejempo), realmente a donde
nos estaremos conectando es al CDB$ROOT, donde tendremos el diccionario de datos
de todo el contenedor y, por tanto, podremos realizar todas las operaciones que serán
comunes para todas las PDB de la instancia.
Esta arquitectura está pensada para grandes organizaciones que necesitan disponer de dis
tintas bases de datos independientes entre sí, y su objetivo es evitar tener que crear varias
instancias de bases de datos independientes, lo que implicaría tener que repartir entre ellas
los recursos disponibles en el servidor. De esta manera, todas las PDB comparten toda la me
moria disponible y los programas de la instancia, pero cada una de ellas se puede gestionar de
manera independiente. Cada PDB tiene su propio diccionario de datos (que se guardará en el
esquema del usuario SYS existente en el PDB), y habrá un diccionario de datos global que se
guardará en el esquema del usuario SYS del CDB$ROOT.
Capítulo 3
Para otorgar mayor flexibilidad al sistema de gestión de usuarios y permisos, y facilitar el

mantenimiento de la instancia, Oracle permite definir la seguridad a dos niveles: local o global.
A) Usuarios locales

Cada PDB se puede gestionar de manera independiente, por lo que dentro de cada una de
las bases de datos se pueden definir los usuarios, roles y permisos que se necesiten para imple
mentar sus políticas de acceso. Los usuarios locales solo pueden crearse dentro de una PDB y
no podrá acceder a ninguna otra PDB de la instancia ni a la propia instancia.
Es posible crear usuarios locales con el mismo nombre en diferentes PDB (ambos usuarios
serán completamente diferentes):
SQL> connect sys@PDB1 as sysdba

SQL> create user usuario1 identified by “12345”;
SQL> connect sys@PDB2 as sysdba

SQL> create user usuario1 identified by “12345”;
SQL> select CON_ID,USER_ID, USERNAME from CDB_USERS where USERNAME=’USUA-

RIO1’;
CON_ID USER_ID USERNAME
---------- ---------- --------------------
3 105 USUARIO1
4 103 USUARIO1
La sintaxis básica para crear usuarios locales en un PDB es la misma que en el estándar SQL,
si bien ofrece la posibilidad de especificar numerosos parámetros adicionales de configuración
de usuarios propios de Oracle:
CREATE USER nb_usuario IDENTIFIED BY “password”

[DEFAULT TABLESPACE nb_tablespace]
[TEMPORARY TABLESPACE nb_tablespace_temp]
[QUOTA espacio ON nb_tablespace]
[PROFILE perfil];
Donde:
– DEFAULT TABLESPACE: los objetos que cree el usuario en su esquema se tendrán

que guardar en algún tablespace, por lo que al crear el usuario podemos indicar en qué
tablespace queremos que se almacenen sus objetos (si no indicamos nada, por defecto
se guardarán en el tablespace USERS).
– TEMPORARY TABLESPACE: las consultas que lance el usuario harán uso del ta
blespace temporal. Si queremos que use uno concreto, lo podemos indicar aquí. Si no
indicamos nada, usará por defecto el tablespace TEMP.
Capítulo 3
– QUOTA: para que el usuario pueda escribir en un tablespace debemos asignarle una
cuota explícitamente (el hecho de que se lo asignemos por defecto no le da permiso
para escribir en él). La cuota puede ser limitada (100K, 50M…) o ilimitada UNLIMI
TED). Si no asignamos permisos al usuario en los tablespaces para que pueda escribir
al crearlo, debemos hacerlo posteriormente con un alter user:
ALTER USER <usuario> QUOTA 100M ON <tablespace>;

ALTER USER <usuario> QUOTA UNLIMITED ON <tablespace>;
– PROFILE: al crear el usuario podemos asignarle directamente un perfil con las restric
ciones que este tenga.
B) Usuarios comunes

Son usuarios que existirán en todas las PDB. Los usuarios comunes solo pueden crearse en
el CDB$ROOT y tienen la misma autenticación en todas las PDB. Son los únicos usuarios que se
pueden crear en esa base de datos del sistema, ya que en ella no se pueden crear usuarios locales.
Dentro de cada PDB se pueden asignar permisos diferentes a los usuarios comunes, por lo
que la gestión de permisos para los usuarios comunes puede ser común o local.
Para poder diferenciar un usuario común de un usuario local, es obligatorio añadir el pre
fijo “C##” al nombre de todos los usuarios comunes (este prefijo se puede modificar en el
fichero de parámetros de configuración SPFILE) e indicar que el usuario se cree en todos los
contenedores (CONTAINER=ALL).
Ejemplo
Conectados a la instancia (ORCL), comprobamos el prefijo utilizado para denominar a los
usuarios comunes:
sqlplus system@ORCL
SQL> show parameter common
NAME TYPE VALUE
------------------------------ --------- -----------------------------
common_user_prefix string C##
Para crear el usuario común, será necesario añadirle ese prefijo al nombre del usuario:
SQL> CREATE USER C##comun identified by “12345” CONTAINER=ALL;
Probamos a conectarnos a una PDB con el usuario común:
SQL> conn C##comun/12345@PDBORCL
¿Sabías que...?
Los únicos usuarios comunes que no tienen C## delante son SYS y SYSTEM.
Capítulo 3
3.3.2. Permisos
Existen dos tipos de permisos en Oracle: permisos de sistema y permisos sobre objetos.
A) Permisos del sistema

Permisos relacionados con las operaciones que el usuario podrá realizar en el sistema ges
tor: conectarse, crear tablas o cualquier otro objeto, consultar información o llevar a cabo tareas
de administración, acceder al EM, etc. Hay muchos permisos del sistema, algunos de los más
relevantes son:
● CREATE SESSION: para iniciar sesión (un usuario sin este permiso no podrá conec
tarse al SGBD).
● UNLIMITED TABLESPACE: uso de espacio ilimitado de espacio en cualquier ta
blespace.
● CREATE, ALTER y DROP de cada tipo de objeto (cluster, context, database, link,
dimension, directory, index, materialized view, operator, outline, procedure, profile,
role, rollback segment, sequence, session, synonym, table, tablespace, trigger, type,
user, view).
● CREATE ANY, ALTER ANY y DROP ANY para cada tipo de objeto. La diferencia
con el anterior es que permiten crear, modificar o eliminar no solo los objetos de su
propio esquema sino que también podrían hacerlo en los esquemas de otros usuarios.
● SELECT ANY TABLE, UPDATE ANY TABLE, INSERT ANY TABLE: permiten
consultar, actualizar o insertar datos en cualquier tabla o vista de cualquier esquema.
La sintaxis para conceder un permiso de sistema a un usuario o rol es:
GRANT <permiso> TO [<usuario> | <rol> | PUBLIC]

[WITH ADMIN OPTION]; -- permite reasignar el permiso a otros usuarios
Asignando el permiso a PUBLIC lo estaríamos concediendo a todos los usuarios, lo cual

no es muy aconsejable.
Lo primero que se debe hacer al crear un usuario es darle permiso de CREATE SESSION,
para que se pueda conectar, y luego asignarle los permisos del sistema que le correspondan.
B) Permisos sobre objetos

Determinan las operaciones que un usuario podrá realizar sobre un objeto de base de datos.
Los permisos que se pueden conceder sobre los objetos son:
● SELECT, INSERT, UPDATE, DELETE: consultar, insertar, modificar o borrar datos

de una tabla o vista.
● ALTER: modificar la estructura de un objeto.
Capítulo 3
● EXECUTE: ejecutar procedimientos o funciones.

● INDEX: crear índices. Este permiso solo se puede asignar sobre una tabla.
● REFERENCES: permite definir una foreign key sobre una tabla de otro esquema.
● ALL: todos los permisos.
Al igual que los permisos del sistema, pueden concederse con la posibilidad de que el re
ceptor lo asigne a otros usuarios. La sintaxis es:
GRANT <permiso> ON <propietario>.<objeto> TO [<usuario> | <rol> | PUBLIC]

[WITH GRANT OPTION]; -- para permitir reasignarlo
Para quitar permisos, tanto de sistema como sobre objetos, se utiliza REVOKE:
REVOKE permiso [ON objeto] FROM [usuario | rol];
Al igual que los usuarios se pueden crear de manera local en una PDB o de forma común
en toda la instancia, los permisos también pueden ser locales o comunes.
A los usuarios locales solamente se les pueden asignar permisos locales. A un usuario común
se le pueden asignar permisos comunes y permisos locales.
– Los permisos comunes deben asignarse o revocarse en el CDB$ROOT indicando la

opción CONTAINER=ALL, y serán válidos en todos los contenedores.
– Los permisos locales se pueden asignar o revocar solamente desde la propia PDB, y se
puede especificar la opción CONTAINER=CURRENT o no poner nada, ya que por
defecto solo aplicarán a esa PDB.
Ejemplo
– Conectándose a la instancia se asignan los permisos comunes en todas las PDB

SQL> conn system@ORCL
SQL> grant select table to C##USUARIO1 CONTAINER=ALL;
– Conectándose a una PDB concreta se pueden asignar otros permisos al usuario
SQL> conn system@PDB1
SQL> grant select any table to C##USUARIO1 CONTAINER=CURRENT;
– Revocar un permiso local
SQL> conn system@PDB2
SQL> revoke alter user from C##USUARIO1 CONTAINER=CURRENT;
SQL> revoke alter user from C##USUARIO1;
– Revocar un permiso común
SQL> conn system@ORCL
SQL> revoke create user from C##USUARIO1 CONTAINER=ALL;
Capítulo 3
Si se ha concedido un permiso común a un usuario, este no se puede revocar de manera

local, es decir, en una PDB podemos asignar a los usuarios comunes permisos adicionales, pero
no podemos quitarles los permisos comunes que tienen asignados.
3.3.3. Roles
Los roles también pueden ser locales o comunes. El funcionamiento de los roles es similar al de
los usuarios, al igual que su definición. Con un rol se pueden realizar las siguientes operaciones:
a) Crearlo: los roles comunes se crean en el contenedor CDB$ROOT y con el prefijo

C##, igual que los usuarios, y los roles locales se crean en una PDB concreta y no es
necesario indicar la cláusula CONTAINER.
-- Para crear un rol común, en @ORCL

CREATE ROLE C##<rol> CONTAINER=ALL;
-- Para crear un rol local, en @PDB
CREATE ROLE <rol> [CONTAINER=CURRENT];
b) Asignarle permisos: la asignación de permisos sigue el mismo esquema que con los usua
rios: a un rol local se le puede asignar únicamente permisos locales, y a un rol común
se le puede asignar permisos comunes y locales. Un rol común puede tener diferentes
permisos en las diferentes PDB.
-- Asignar un permiso común a un rol común, en @ORCL

GRANT <permiso> TO C##<rol> CONTAINER=ALL;
-- Asignar un permiso local a un rol común, en @PDB
GRANT <permiso> [ON <objeto>] to C##<rol> CONTAINER=CURRENT;
-- Asignar un permiso local a un rol local, en @PDB
GRANT <permiso> [ON <objeto>] TO <rol> [CONTAINER=CURRENT];
c) Quitarle permisos:
REVOKE <permiso> [ON <objeto>] FROM <rol> [CONTAINER=CURRENT|ALL];
d) Asignar el rol a un usuario o a otro rol: Oracle permite asignar roles a roles y permite tam
bién que a un usuario se le pueda asignar más de un rol.
GRANT <rol> TO [<usuario> | <rol>];
e) Quitarle un rol a un usuario o rol:
REVOKE <rol> FROM [<usuario> | <rol>];
Capítulo 3
f) Borrarlo:
DROP ROLE <rol>;
Al asignar roles a un usuario, los permisos que se otorguen dependerán de la PDB en que
se encuentre el usuario. Es decir:
a) A un usuario local se le puede asignar un rol común, pero únicamente “heredará” los
permisos que tenga el rol común en la PDB donde se ha definido ese usuario local.
b) A un usuario común se le puede asignar un rol local, pero únicamente “heredará” los
permisos del rol local en la PDB donde se encuentre ese rol local.
3.3.4. Perfiles
Cuando se crea un usuario, se le asigna un perfil por defecto llamado precisamente “DE
FAULT”, que no establece ningún límite al uso de los recursos.
Para aplicar restricciones sobre los recursos, es necesario habilitar previamente los perfiles
de usuario, que, por defecto, vienen deshabilitados al instalar Oracle:
ALTER SYSTEM SET RESOURCE_LIMIT=TRUE;
La sintaxis para crear un perfil es la siguiente:
CREATE PROFILE <perfil> LIMIT

{ parámetro_recurso | parámetro_contraseña } [<valor> [K|M] | UNLIMITED]
{ parámetro_recurso | parámetro_contraseña } [<valor> [K|M] | UNLIMITED]
… ;
Al igual que los usuarios y los roles, los perfiles pueden ser locales o comunes a toda la
instancia. Los perfiles comunes también se deben definir en el CDB$ROOT especificando
“CONTAINER=ALL” y su nombre debe estar precedido por el prefijo C##.
Los parámetros que se pueden bloquear pueden hacer referencia a recursos del sistema o a
restricciones a aplicar en la definición de contraseñas.
A) Parámetros de limitación de recursos

● SESSIONS_PER_USER: máximo número de sesiones concurrentes.
● CONNECT_TIME: duración máxima de una sesión.
● IDLE_TIME: máximo tiempo de inactividad del usuario.
● CPU_PER_SESSION: tiempo máximo de uso de la CPU por sesión, en centésimas de
segundo.
● CPU_PER_CALL: tiempo máximo de uso de la CPU por llamada, en centésimas de
segundo.
● LOGICAL_READS_PER_SESSION: máximo número de bloques de datos leídos en
una sesión.
Capítulo 3
● LOGICAL_READS_PER_CALL: tiempo máximo de uso de la CPU por sesión. En

centésimas de segundo.
● PRIVATE_SGA: cantidad de memoria SGA disponible para la sesión (cuando la instan
cia hace uso de procesos de servidor compartidos). Se puede especificar en k ilobytes (k)
o megabytes (m).
● COMPOSITE_LIMIT: número adimensional basado en los límites anteriores.
B) Parámetros de restricción de contraseñas

Estos parámetros solamente tienen efecto sobre los usuarios autenticados por medio del
sistema gestor (los usuarios que se conecten por medio de LDAP, por ejemplo, no estarán su
peditados a estas restricciones).
● FAILED_LOGIN_ATTEMPTS: número máximo de intentos fallidos antes de blo

quear la cuenta.
● PASSWORD_LIFE_TIME: número de días de vida de la contraseña.
● PASSWORD_REUSE_TIME: número de días que deben transcurrir para reutilizar
una contraseña.
● PASSWORD_REUSE_MAX: número de veces que se debe cambiar una contraseña
antes de reutilizarla.
● PASSWORD_LOCK_TIME: número de días que queda bloqueada la cuenta: si un
usuario introduce erróneamente la contraseña más veces de las especificadas por medio
del parámetro “FAILED_LOGIN_ATTEMPTS”, su cuenta se bloquea y no podrá
desbloquearla hasta pasados los días que se indique en este parámetro.
● PASSWORD_GRACE_TIME: periodo de gracia de las contraseñas caducadas. Du
rante este periodo el usuario podrá conectarse y cambiar su contraseña, pero una vez
finalizado tendría que solicitar al responsable que le cambie la contraseña para poder
acceder de nuevo al sistema gestor.
● PASSWORD_VERIFY_FUNCTION: función PL/SQL que dará el visto bueno a la
complejidad de la contraseña. Esto permite definir funciones de verificación perso
nalizadas.
Para asignar un perfil a un usuario, será necesario hacer un ALTER del usuario:
ALTER USER <usuario> PROFILE <perfil>;
Para modificar un perfil:
ALTER PROFILE <perfil> LIMIT

{ parámetro_recurso | parámetro_contraseña } [valor [K|M] | UNLIMITED];
Para borrar un perfil:
DROP PROFILE <perfil>;
Capítulo 3
Ejemplo
– Creamos el perfil
SQL> CREATE PROFILE administrador LIMIT

SESSIONS_PER_USER 5
CONNECT_TIME 120
IDLE_TIME 30
FAILED_LOGIN_ATTEMPTS 4
PASSWORD_LIFE_TIME 165;
– Lo asignamos a un usuario
SQL> ALTER USER admin PROFILE administrador;
– Añadimos una nueva restricción
SQL> ALTER PROFILE administrador LIMIT PASSWORD_REUSE_TIME 3;
– Se lo quitamos, asignándole de nuevo el perfil por defecto
SQL> ALTER USER admin PROFILE DEFAULT;
– Borramos el perfil
SQL> DROP PROFILE administrador;
3.3.5. Diccionario de datos

El diccionario de datos local de cada PDB se guarda en el esquema SYS local del PDB. Cada
una de las vistas que contiene información de usuarios, permisos, roles, etc., tendrá tres vistas
diferentes:
● USER_[tabla]: muestra la información propia del usuario.

● ALL_[tabla]: muestra la información de los objetos a los que tiene acceso el usuario.
● DBA_[tabla]: para poder consultar esta vista el usuario debe tener concedido el permi
so para poder hacerlo. En ella se incluye la información de todos los objetos del PDB
(DBA_USERS mostrará la información de todos los usuarios).
Ejemplo
– Muestra la información del usuario system en PDB1:
conn system@pdb1
SQL> SELECT * FROM USER_USERS;
Capítulo 3
– Muestra la información de todos los usuarios existentes en PDB1:
SQL> SELECT * FROM DBA_USERS;
– Muestra el mismo resultado que la consulta anterior, porque como el usuario system
tiene acceso a todos los esquemas de todos los usuarios, en esta vista mostrará a todos
los usuarios existentes en PDB1:
SQL> SELECT * FROM ALL_USERS;
Las principales vistas del diccionario de datos de Oracle relacionadas con la gestión de
usuarios y permisos son las siguientes (se indican con el prefijo DBA pero cada una tendrá su
correspondiente USER_ y ALL_):
● DBA_USERS: perfiles de los usuarios.

● DBA_SYS_PRIVS: permisos de sistema concedidos a usuarios.
● DBA_TAB_PRIVS: permisos sobre objetos concedidos a usuarios.
● DBA_COL_PRIVS: permisos sobre columnas.
● DBA_ROLES: todos los roles de la base de datos.
● DBA_ROLE_PRIVS: roles concedidos a usuarios.
● ROLE_ROLE_PRIVS: roles concedidos a otros roles.
● ROLE_SYS_PRIVS: privilegios de sistema concedidos a los roles.
● ROLE_TAB_PRIVS: privilegios sobre objetos concedidos a los roles.
● DBA_PROFILES: perfiles existentes con sus límites.
El diccionario de datos común se almacena en el usuario SYS del CDB$ROOT.

Las vistas donde se almacenan los objetos comunes son las mismas que con los locales pero
precedidas del prefijo CDB_:
● CDB_USERS: muestra todos los usuarios del CDB, tanto los locales como los comunes.
● CDB_SYS_PRIVS y CDB_TAB_PRIVS: muestran los permisos del sistema (CDB_
SYS_PRIVS) y de objetos (CDB_TAB_PRIVS), tanto comunes como locales, defini
dos en el CDB.
● CDB_ROLES, CDB_ROLE_PRIVS: roles y permisos de roles comunes.
● CDB_PROFILES: información de los perfiles comunes.
Ejemplo
SQL> select CON_ID,USER_ID,USERNAME,COMMON from CDB_USERS where USERNA-

ME=’C##USUARIO1’;
CON_ID USER_ID USERNAME COMMON

---------- -------------- ----------------------- ------
1 111 C##USUARIO1 YES
Capítulo 3
– el usuario común C##USUARIO1 ha sido creado en todas las PDB de la base de

datos.
SQL> select CON_ID, GRANTEE, PRIVILEGE, COMMON from cdb_sys_privs
where GRANTEE=’C##USUARIO1’ AND CON_ID=4;
CON_ID GRANTEE PRIVILEGE COMMON

---------- ---------------------- ------------------------------ ------
4 C##USUARIO1 ALTER USER NO
4 C##USUARIO1 CREATE USER YES
4 C##USUARIO1 SELECT ANY TABLE YES
– el usuario C##USUARIO1 tiene 2 permisos comunes y uno local en el contenedor 4.
Accede al recurso digital Gestión de usuarios y permisos, donde se proponen varios ejerci-
cios para practicar la creación de usuarios, permisos, roles y perfiles en Oracle.
3.4. Esquemas externos

Para asignar permisos a los usuarios sobre los objetos de la base de datos, existen dos opciones:
1. Asignar los permisos directamente sobre las tablas de la base de datos, de forma que los
usuarios podrían acceder directamente a las tablas a las que tengan permiso. Esta opción
es poco segura y muy poco flexible, ya que damos a conocer la estructura de nuestras
tablas y cualquier cambio en dicha estructura afectaría a los usuarios (si los aplicaciones
lanzan consultas del tipo “SELECT * FROM tabla”, si añadimos o quitamos un campo
de la tabla lo más probable es que las aplicaciones fallen, ya que el conjunto de resulta
dos devuelto no se ajustará a lo esperado).
2. Crear una serie de vistas específicas para cada usuario o rol y asignar permisos sobre las
vistas. Esta es la opción propuesta en la arquitectura ANSI-SPARC de base de datos,
de forma que para cada usuario o rol se crearía un esquema externo y los permisos se
asignarían a las vistas del esquema externo de cada usuario o rol. Esta opción es más
potente que la anterior ya que no solamente permite gestionar a qué tablas accede cada
usuario sino que la propia definición de la vista puede incluir restricciones por filas y
por columnas. Sin embargo, si los usuarios realmente tienen que poder acceder a todo
el contenido de las tablas, estaríamos creando un nivel de abstracción intermedio que
aporta poco y complica considerablemente el mantenimiento de la base de datos (si
cada usuario tiene sus vistas, si hay muchos usuarios será muy complicado gestionar
todas esas vistas).
La mejor solución, por tanto, suele ser buscar un equilibrio entre ambas opciones: si los
usuarios tienen acceso a las tablas completas se le suele dar permiso directamente sobre la tabla,
Capítulo 3
pero si es necesario limitar las filas o columnas que puede ver un usuario es necesario emplear
las vistas. Cada usuario tendrá, por tanto, un esquema externo que determinará a qué campos
de qué tablas del nivel conceptual podrá acceder:
Usuarios
vista vista vista vista vista vista vista vista Esquemas

externos
vista vista vista vista vista
Esquema
conceptual
tabla tabla tabla tabla
Esquema
interno
disco disco disco disco disco
Figura 3.2
Esquemas externos.
Ten en cuenta
No se deben confundir usuarios de bases de datos con usuarios de aplicación. Si una orga-
nización tiene una aplicación de gestión que usan 100 empleados, no es necesario crear
100 usuarios de bases de datos, sino un usuario que usará la aplicación para conectarse a la
base de datos y lanzar sus consultas. Los usuarios no acceden directamente al sistema gestor
para ejecutar consultas, sino que acceden a la aplicación con sus usuarios de aplicación, y
esta será quien loguee a los usuarios, gestione sus permisos, y ejecute las sentencias de bases
de datos necesarias para mostrar a cada usuario lo que necesite.
Los usuarios de bases de datos permiten establecer una conexión contra el sistema gestor,
por lo que normalmente solo es necesario un usuario de base de datos por aplicación, y usua-
rios propios para los administradores del sistema o desarrolladores que necesiten acceder al
sistema gestor para lanzar sus propias consultas.
Cuando necesitamos crear una base de datos, lo más habitual es crear al menos los siguientes
usuarios:
a) Un usuario que será el propietario de la base de datos o esquema. Este usuario tendrá
permisos para manipular toda la información de la base de datos e incluso puede tener
permisos para crear objetos de la base de datos (tablas, procedimientos, índices, etc.).
En este esquema se crearán también una serie de vistas por medio de las que se dará
posteriormente acceso al resto de usuarios (concediéndoles permisos de consulta, mo
dificación, etc., sobre las vistas).
b) Para cada usuario o aplicación que quiera acceder a los datos, se creará un nuevo usua
rio de bases de datos. El usuario propietario creará las vistas que sean necesarias para
Capítulo 3
que cada uno de estos usuarios “invitados” vea solo lo que debe ver, y les dará permisos
sobre esas vistas. En el usuario “invitado” se podrán crear sinónimos para cambiar el
nombre a las vistas si es necesario.
Aún en caso de que tengamos varios usuarios que puedan ver exactamente las mis
mas tablas, es conveniente crear un usuario para cada uno de ellos en lugar del mismo
usuario para todos ellos (para gestionar los permisos crearíamos un rol que asignaríamos
a todos los usuarios), ya que de esta manera las funciones de auditoría nos permitirían
diferenciar qué hace cada uno de los usuarios, y si todos usasen el mismo usuario no
habría forma de obtener esta información.
Ejemplo
Una empresa se dedica al mantenimiento del sistema informático de 2 clientes. La base de datos
tendrá una tabla INCIDENCIAS compuesta de los campos: "idincidencia", "idcliente", "fechaincid",
"idemp", "solucion" y "fecresol" para guardar la información de todas las incidencias registradas.
● Para gestionar sus incidencias, instala a cada uno de los clientes una aplicación por
medio de la cual pueden registrar incidencias y consultar sus propias incidencias, pero
no ver las de los demás clientes.
● En la oficina de la empresa tendrán otra aplicación en la que no podrán registrar inci-
dencias pero podrán ver y modificar las incidencias registradas por todos los clientes.
● El gerente de la empresa tendrá una aplicación de reporting que le mostrará el número
de incidencias resueltas y sin resolver al final del día, y le permitirá desglosarlas por usua-
rio, pero no le permitirá consultar los detalles de las incidencias (solución, clientes, etc.).
Tendríamos por tanto varios esquemas externos de acceso distintos:
● Cada una de las aplicaciones de los clientes podrán crear y ver sus propias incidencias.
● La aplicación central podrá ver y modificar todas las incidencias, pero no crear nada.
● La aplicación de reporting podrá ver todas las filas de la tabla INCIDENCIAS pero no
podrá ver las columnas “SOLUCION”, “IDCLIENTE” o “FECINCID”.
Figura 3.3
Ejemplo de esquemas
externos.
Capítulo 3
Para el cliente 1 crearíamos la vista V_INCIDENCIAS1, y para el cliente 2 crearía-

mos la vista V_INCIDENCIAS2. Ambas aplicaciones utilizarán la misma aplicación, y esa
aplicación cuando quiere consultar la información de las incidencias lo que lanzará será
una consulta del estilo “SELECT * FROM INCIDENCIAS”. Para que esto funcione correc-
tamente, lo que tendremos que hacer será crear un sinónimo para el usuario del cliente1
llamado INCIDENCIAS que apunte a su vista definida en el esquema “incidencias” (inci-
dencias.V_INCIDENCIAS1), y otro para el usuario del cliente2 llamado también INCIDEN-
CIAS que apunte a su vista (indicendias.V_INCIDENCIAS2). De esta manera, la aplicación
es exactamente la misma y conseguimos que cada uno de ellos vea únicamente lo que le
corresponde.
Lo mismo ocurre con la aplicación de reporting y la aplicación central: ambas consulta-
rán un sinónimo llamado INCIDENCIAS que mostrará a cada una de ellas únicamente lo que
puedan ver (la información que conste en sus vistas respectivas).
3.4.1. Vistas
Una vista no es más que una consulta almacenada a la que se le asigna un nombre, por lo que
las vistas no ocupan espacio de almacenamiento (no guardan ningún dato: los datos ya están
almacenados en las tablas y únicamente se consultan).
Para restringir las filas o columnas de una o varias tablas que puede ver un usuario habrá
que definir la consulta que devuelva los datos que se quieren mostrar, y asignarle un nombre
a esa consulta (que será el nombre de la vista). Cuando un usuario ejecute una consulta sobre
la vista, lo que hará el sistema será ejecutar la consulta que corresponde a la vista, guardar los
resultados en una tabla temporal en memoria, y sobre esa tabla temporal resolverá la consulta
que se ha ejecutado sobre la vista.
Las vistas se definen siempre en el esquema propietario de los datos, y el usuario propietario
será el único que podrá redefinirlas (no tendría sentido crear una vista para limitar los datos a los
que puede acceder un usuario “invitado” y que este pueda modificar dicha vista).
Para el sistema gestor las vistas son desde un punto de vista lógico como si fueran ta
blas, y por tanto permite realizar sobre las vistas prácticamente todas las operaciones que se
pueden realizar sobre las tablas: definir consultas, asignar permisos, modificar datos (no todas
las vistas lo permiten), e incluso crear nuevas vistas por medio de consultas sobre vistas ya
existentes.
Existen tres tipos de vistas:
a) Vistas horizontales: permiten restringir las filas de la tabla a las que tendrán acceso los
usuarios (por ejemplo, que un usuario solamente pueda ver las ventas de su departa
mento).
b) Vistas verticales: permiten restringir las columnas de la tabla a las que tendrán acceso los
usuarios (por ejemplo, que un usuario tenga acceso a los datos de los empleados pero
no a su sueldo).
c) Vistas mixtas: permiten limitar el acceso horizontal y verticalmente (por ejemplo, que
un usuario tenga acceso a todos los datos de los empleados de su departamento excepto
su sueldo).
Capítulo 3
Ejemplo
– Vista horizontal:
SELECT codemp, empleado, salario, coddepto FROM empleados WHERE coddepto=2;
Figura 3.4
Ejemplo vista
horizontal.
– Vista vertical:
SELECT codemp, empleado FROM empleados;
Figura 3.5
Ejemplo vista
vertical.
– Vista mixta:
SELECT codemp, empleado FROM empleados WHERE coddepto=2;
Figura 3.6
Ejemplo vista
mixta.
La sentencia SQL para crear una vista:
CREATE [OR REPLACE] VIEW <vista> AS SELECT …;
Las vistas no pueden modificarse por medio de una sentencia ALTER. Para modificar una
vista, habrá que sobrescribir la consulta que tenía asociada, de ahí la cláusula [OR REPLACE]
que se puede indicar en la sentencia de creación de una vista.
Capítulo 3
¿Sabías que...?
Las vistas deberían crearse indicando siempre explícitamente los campos que debe devolver
las consultas, evitando usar el “*” en el select de las consultas. Si una aplicación consulta los
4 campos de una tabla por medio de una vista definida por medio de un “SELECT *” de esa
tabla y por cualquier motivo se añade un campo nuevo a la tabla, lo más probable es que las
aplicaciones que consulten esa vista fallen ya que cuando consultan la vista esperan que
esta devuelva únicamente 4 campos, pero se encontrarían con que devuelve 5 campos y eso
podría provocar un fallo en las aplicaciones pues las estructuras de datos donde almacenan la
información consultada se verían desbordadas.
Para eliminar una vista, se usará DROP como con cualquier otro objeto de base de datos:
DROP VIEW <vista>;
3.4.2. Sinónimos
Los sinónimos son como accesos directos que permiten hacer referencia a un objeto de base de
datos (una tabla, vista o procedimiento generalmente) por medio de otro nombre.
La sentencia SQL para crear un sinónimo es la siguiente:
CREATE [OR REPLACE] SYNONYM <sinónimo> FOR <esquema>.<vista>;
Al igual que sucedía con las vistas, no es posible ejecutar un ALTER sobre un sinónimo,
para modificarlo lo único que habrá que hacer es redefinirlo usando “OR REPLACE”.
Por medio de los sinónimos es posible hacer que varios usuarios usen un mismo nombre de
objeto aunque realmente estén accediendo a objetos diferentes, lo que nos proporciona varias
ventajas:
a) Seguridad: los usuarios no saben en qué esquema están los datos a los que están acce
diendo, cómo se llaman las tablas ni que campos contienen realmente.
b) Facilidad de uso: los sinónimos se crean en el esquema propio del usuario, lo que evita
hacer referencia constantemente al esquema propietario de las tablas o vistas para ac
ceder a ellas: se crea el sinónimo que apunte a la tabla o vista y el usuario lo usará para
hacer referencia a ella cuando lo necesite.
c) Homogeneidad: todos los usuarios pueden emplear un mismo nombre de objeto para
acceder a los datos, independientemente de a qué datos acceda cada uno. De esta forma,
es posible por ejemplo emplear la misma aplicación en distintas sedes de una empresa
de manera que la aplicación siempre consulte los clientes ejecutando la misma consulta:
“SELECT * FROM CLIENTE;”, pero el objeto “CLIENTE” no será una tabla, sino
que internamente será un sinónimo que en función de qué usuario lo invoque estará
Capítulo 3
haciendo referencia a distintas vistas, consiguiendo así que cada sede vea únicamente sus
clientes.
En algunos SGBD no es posible crear sinónimos, pero puede “emularse” su comportamien

to por medio de vistas: habría que crear un esquema para cada usuario, y en ese esquema crear
las vistas que se usarán como sinónimos:
CREATE VIEW gestion_sede1.cliente AS SELECT * FROM gestion.cliente_sede1;
3.5. Esquemas externos en Oracle

Tal como vimos anteriormente, para Oracle cada usuario (credencial de acceso al sistema) tie
ne su propio esquema (conjunto de objetos de base de datos), lo que facilita enormemente la
definición de esquemas externos.
La metodología empleada normalmente para crear los esquemas conceptual y externos en
Oracle es la siguiente:
1. Se crea un usuario propietario, en cuyo esquema se definirá el esquema conceptual de

la base de datos (todas las tablas del sistema), así como todas las vistas que necesite para
filtrar la información que se vaya a filtrar al resto de usuarios.
2. Para cada aplicación o usuario que quiera acceder a la base de datos, se creará un usua
rio “invitado” en cuyo esquema se definirán los sinónimos que necesite para “apuntar”
a las tablas y vistas del usuario propietario.
La sintaxis para la creación tanto de vistas como de sinónimos es muy similar al estándar:
CREATE [OR REPLACE] VIEW <vista> [(lista_de_columnas)]

AS <consulta_select>;
CREATE [OR REPLACE] SYNONYM <sinónimo> FOR esquema_propietario.<vista>;
Ejemplo
Supongamos una empresa con una base de datos centralizada que da servicio a varias sedes,
de forma que en cada sede podrán gestionar únicamente la información de la propia sede.
Para almacenar la información se creará un usuario propietario llamado “gestion” en cuyo
esquema se crearán todas las tablas necesarias. Todos los clientes, por ejemplo, estarán en la
tabla “gestion.CLIENTE”, y, para limitar los datos a los que pueden acceder desde cada sede,
se creará una vista para cada una de las sedes:
create view gestion.cliente_sede1 as select * from gestion.cliente where codsede=1;

Capítulo 3
Cada sede tendrá su propio usuario de base de datos “invitado” (gestion_sedeX) con su
propio esquema. A cada usuario se le dará permiso de acceso a la vista que se le ha creado, y
tendrá en su esquema un sinónimo “cliente” que apuntará a la vista:
Grant select,update,delete,insert on gestion.cliente_sede1 to gestión_sede1;

create synonym gestion_sede1.cliente for gestion.cliente_sede1;
Todas las sedes usarán la misma aplicación de gestión, y la aplicación cuando consulta los
clientes lo que hace es ejecutar la consulta: “SELECT * FROM CLIENTE” independientemente
de la sede desde la que se acceda.
Para que todo funcione correctamente y desde cada sede solamente se pueda acceder a su
propia información, lo único que habrá que configurar será el usuario con el que se conecta
la aplicación desde cada sede: en la sede 1 se usará el usuario gestion_sede1, y cuando este
acceda a su objeto “cliente”, que es un sinónimo, realmente estará accediendo a la vista clien-
te_sede1 definida en el esquema “gestion”. Lo mismo sucedería para los usuarios de la sede 2
y la sede 3, y así se puede usar siempre la misma consulta para recuperar la información, pero
en función del usuario que la ejecute, la consulta devolverá una cosa u otra.
Para consultar las vistas y sinónimos en el diccionario de datos, existen tres vistas (USER_,
ALL_ y DBA_) para cada uno de ellos:
● DBA_VIEWS: permiten consultar toda la información de la vista, incluso la consulta

empleada para crear la vista.
● DBA_SYNONYMS: muestra la información de los sinónimos existentes: su nombre, a
qué objeto hacen referencia y en qué esquema se encuentra dicho objeto.
Las actividades propuestas en el recurso digital Esquemas externos permiten practicar la crea-
ción de esquemas externos en diferentes casuísticas, así como repasar la creación de usuarios, ro-
les, perfiles y asignación de los permisos necesarios para dar respuesta a las casuísticas propuestas.
Resumen
n La función de gestión de usuarios y permisos engloba la autenticación de usuarios,

la asignación de permisos y roles y la restricción de recursos por medio de perfiles y
cuotas.
Capítulo 3
n La autenticación de usuarios permite identificar cada cuenta de usuario que establece

conexión con el sistema gestor para asociarle los permisos que le correspondan. Los
usuarios pueden ser internos o externos al sistema gestor, pero los permisos siempre
se gestionan internamente.
n Existen dos tipos de permisos: de sistema (operaciones que el usuario puede llevar a
cabo en el sistema gestor) o de objetos (operaciones que puede realizar sobre objetos
concretos de la base de datos).
n Los roles permiten gestionar de manera conjunta un grupo de permisos que compar-
tirán varios usuarios.
n Existe la posibilidad de definir restricciones sobre el uso de recursos por parte de
los usuarios o sobre las condiciones que deben cumplir las contraseñas. Algunos
sistemas gestionan estas restricciones individualmente para cada usuario, mientras
que otros permiten la creación de perfiles que permiten gestionarlas de manera con-
junta.
n Los esquemas externos permiten garantizar la independencia lógica en una base de
datos (es decir, que la forma de mostrar los datos a los usuarios sea independiente
de cómo se organiza la información internamente en las tablas).
n El sistema gestor permite crear vistas y sinónimos para definir esquemas externos: las
vistas permiten restringir la información que se mostrará a los usuarios, mientras que
los sinónimos aportan seguridad, facilidad de uso y homogeneidad en la nomenclatu-
ra de los objetos.
n Tanto la gestión de usuarios y permisos como la definición de esquemas externos son
mecanismos que provee el SGBD para garantizar la confidencialidad de la informa-
ción, permitiendo garantizar que únicamente puedan acceder a esta los usuarios que
tienen permiso para hacerlo.
1. Asocia cada una de las siguientes vistas con su contenido:
a) Usuarios de la base de datos. 1. dba_roles

b) Perfiles de usuario. 2. dba_role_privs
c) Permisos asignados sobre los objetos de la base de datos. 3. dba_tab_privs
d) Roles de usuario. 4. dba_sys_privs
e) Permisos del sistema asignados a los usuarios. 5. dba_profiles
f) Permisos de los roles. 6. dba_users
Capítulo 3
2. ¿Qué hace la siguiente sentencia?
create tablespace temp_tab datafile ‘c:/app/oracle/oradata/orcl/pd-

borcl/tab01.dbf’
size 1M autoextend on next 200k maxsize 1400K
default storage (initial 16k next 16k minextents 1 maxextents 3);
a) Crea un tablespace temporal.

b) Crea un datafile.
c) No hace nada porque da un error.
d) Crea un tablespace normal.
3. ¿Puedo asignar un rol a otro rol?
4. ¿Qué devuelve la siguiente consulta?
select ‘revoke ‘||privilege||’ from administrador;’ from dba_sys_

privs where lower(grantee)=’administrador’;
a) Los privilegios de sistema que hayan sido concedidos al usuario “administrador”.

b) Los privilegios de sistema que le hayan sido quitados al usuario “administrador”.
c) Los privilegios de sistema que hayan sido otorgados por el usuario “administrador”.
d) Los privilegios de sistema que haya quitado explícitamente el usuario “adminis
trador”.
e) No devuelve nada, dará un error.
5. Has creado un nuevo usuario pero no puede conectarse al sistema gestor. ¿Cuál de las
siguientes opciones le permitiría hacerlo?
a) Otorgarle el permiso sobre objetos “CREATE SESSION”.

b) La única opción para arreglar el problema sería darle el rol de DBA.
c) Otorgarle el permiso de sistema “CONNECT”.
d) Asignarle un rol que tenga concedido el permiso de sistema “CREATE SESSION”.
e) Otorgarle el permiso de sistema “CREATE SESSION WITH GRANT OPTION”.
6. ¿Qué ocurre si intento eliminar un usuario que tiene una sesión iniciada?
a) Tengo que usar la opción CASCADE: DROP USER nbusuario CASCADE;.

b) No puedo hacerlo.
c) Puedo hacerlo sin problema con DROP USER nbusuario;.
d) Solo puedo hacerlo si soy DBA.
7. La empresa en la que trabajas ha decidido sustituir el actual sistema de ficheros que

estaban utilizando para gestionar las nóminas de los trabajadores por un SGBD y una
aplicación moderna que sea accesible vía web y permita explotar la información.
Capítulo 3
El sistema actual trabaja con los siguientes ficheros:
●
SEDE: en este fichero se guarda la información de las sedes de tu empresa: código
de sede, nombre, dirección y el código del empleado que es jefe de la sede.
● CARGO: fichero donde se registran los distintos cargos existentes: código de car-
go, su descripción y la bonificación que implica para el empleado el desempeño
de dicho cargo.
● PERSONAL: almacena la información del personal de la empresa: código de em-
pleado, nombre, apellidos, dirección, DNI, código postal, sueldo base, código de
sede a la que está asociado, código del cargo que ocupa y fecha de contratación.
● NOMINAS: fichero donde se almacenan las nóminas pagadas a los empleados.
Contiene los campos: "código de empleado", "código de sede", "mes", "importe" y
"retención".
El nuevo sistema informático que se va a implantar en la empresa es un ERP que

dispone de varios módulos:
– Una aplicación de escritorio que emplearán los responsables de gestionar las nó-
minas para realizar los pagos de cada mes.
– Una aplicación web a través de la que los propios empleados pueden acceder y
consultar sus nóminas.
– Una aplicación para móvil que los empleados podrán usar del mismo modo que
la página web.
– Un módulo de análisis que lee la información registrada en la base de datos por
parte de los tres sistemas anteriores y la guarda en su propia base de datos de forma
que facilite la elaboración de informes por parte de los gerentes de la organización.
La empresa dispone de un equipo de soporte formado por 4 personas. Es impor-

tante que quede reflejado quien realiza cada operación sobre el SGBD, por lo que nos
interesa poder identificar a cada uno de los usuarios de soporte.
Se pide:
a) Crea los usuarios y roles que consideres necesarios, y asígnales a todos ellos el
tablespace TBS_NOMINAS.
b) Asigna los permisos del sistema y cuotas que garanticen que:
● Únicamente el usuario propietario del esquema podrá crear nuevos objetos

de bases de datos y modificar o eliminar los existentes: tablas, secuencias,
procedimientos, triggers y vistas. Además, si lo considera necesario, podrá
reasignar los permisos que tiene concedidos.
● Tanto el usuario propietario como desde las aplicaciones de escritorio, web y
móvil se podrá insertar nueva información en la base de datos.
● Las aplicaciones necesitarán conectarse al sistema gestor y crear los sinóni-
mos y procedimientos que necesiten.
Capítulo 3
● Los miembros del equipo de soporte podrán conectarse a la base de datos

y realizar cualquier operación sobre la base de datos (crear tablas, índices,
sinónimos, vistas, secuencias o procedimientos).
c) Crea las vistas y asigna los permisos necesarios para asegurar que:
●
Los empleados que utilicen la aplicación de escritorio puedan ver y modificar
todo, excepto el sueldo base de los empleados y las bonificaciones que co-
rresponden a cada cargo.
● Desde la aplicación web y la aplicación móvil se tenga acceso y se pueda
modificar la información personal de los empleados: nombre, apellidos, di-
rección, DNI y código postal, pero que no se pueda eliminar ninguna infor-
mación de la base de datos.
● La aplicación de análisis pueda acceder a toda la información de todas las
tablas pero solo para lectura.
● Los miembros del equipo de soporte puedan consultar y manipular la infor-
mación de cualquier tabla de la base de datos.
d) Crea los sinónimos que sean necesarios en cada esquema para que puedan hacer
referencia de forma homogénea a las tablas de la base de datos.
e) Habilita los perfiles de usuario y crea un perfil que garantice las siguientes restric-
ciones:
● El número máximo de sesiones concurrentes para las aplicaciones será de 50,

y para el módulo de análisis de 10.
● Las conexiones de las aplicaciones no podrán exceder los 30 minutos.
● Cuando el módulo de análisis esté inactivo durante más de 1 hora, se desco-
nectará su sesión.
● A todos los usuarios se les debe bloquear la sesión en caso de realizar 4 inten-
tos de conexión fallidos.
● Los usuarios deben cambiar la contraseña cada 180 días, pero se les concede-
rá un periodo de gracia de 10 días desde que la contraseña caduque.
● Los usuarios no podrán reutilizar una contraseña hasta pasados 180 días.
● Para verificar las contraseñas de los usuarios, emplearemos la función fn_
comprueba_pass que crearemos nosotros mismos.
Capítulo 3
1. Para que los usuarios de una sede de la empresa no puedan ver todos los campos
de la tabla empleados y solo vean los empleados de la propia sede, tendré que
usar:
a) Revoke.
b) Perfiles.
c) Una vista vertical.
d) Una vista mixta.
2. Grant y revoke son sentencias del:

a) DDL.
b) DML.
c) DCL.
d) TCL.
3. Permiten restringir el uso de recursos a los usuarios:

a) Roles.
b) Permisos.
c) Perfiles.
4. Para desbloquear la cuenta de un usuario que estaba bloqueada, usaré:

a) UNLOCK USER usuario1;.
b) ALTER USER usuario1 ACCOUNT UNLOCK.
c) ALTER USER usuario1 ENABLE.
d) ALTER USER usuario1 UNLOCK.
5. Para cambiar el password de un usuario en Oracle, usaré:

a) alter user usuario1 identified by “12345”.
b) alter user usuario1 password “12345”.
c) alter user usuario1 set password “12345”.
d) update dba_users set passwd=”12345” where user=’USUARIO1’.
6. Para conceder un permiso, usaré la sentencia:

a) GRANT <privilegio> TO <usuario>.
b) GRANT <privilegio> ON <objeto> TO <usuario>.
c) GRANT <privilegio> TO <usuario> WITH ADMIN OPTION.
7. ¿Cuál de las siguientes operaciones no está permitida en Oracle?

a) Añadir un permiso a un rol.
b) Quitar un rol a un usuario.
c) Asignar un rol a otro rol.
d) Copiar los permisos de un usuario en otro usuario.
Capítulo 3
8. ¿Qué devuelve la siguiente consulta?

SELECT ‘drop user ‘||username||’ cascade;’ from all_users;
a) Elimina todos los usuarios existentes en el sistema gestor.
b) Las sentencias necesarias para eliminar todos los usuarios del sistema gestor.
c) Las sentencias necesarias para eliminar los usuarios a cuyo esquema tenga
acceso el usuario actual.
d) La sentencia necesaria para eliminar el usuario actual.
9. ¿Cuál de las siguientes no es una ventaja de los sinónimos?

a) Seguridad.
b) Facilitan el acceso a los usuarios.
c) Mayor rapidez de acceso.
d) Homogeneidad.
10. Necesito crear un esquema con varias tablas y darle acceso a cuatro aplicaciones que
tendrán exactamente los mismos permisos. ¿Qué tendré que crear?
a) Cuatro perfiles.
b) Dos roles.
c) Cinco usuarios.
a b c
1. d 5.
a b c d
a b c
2. a b c d 9.
d 6. a b c d
a b c
3. a b c d 10.
d 7. a b c d
a b c
4. a b c d
d 8.
Capítulo 3
4
Seguridad
Objetivos
3 Establecer los mecanismos básicos de seguridad que permitan garantizar la
integridad y confidencialidad del sistema gestor.
3 Conocer el funcionamiento de las herramientas existentes para garantizar la
seguridad del sistema.
3 Tomar conciencia de la importancia de establecer políticas y procedimien-
tos de copia de seguridad y restauración.
3 Comprender el papel que desempeñan las distintas herramientas del sistema
gestor de base de datos para garantizar las medidas impuestas por la norma-
tiva de protección de datos.
Mapa conceptual
Auditoría
Encriptación Funciones
Encriptación transparente
Restricciones
Recuperación Backup
Restauración
Recuperación
Control de concurrencia
realiza Funciones
Puesta en marcha
Seguridad Encriptación
Auditoría
Recuperación
Protección de datos
Explotación
Administración
Capítulo 4
Seguridad 113
Glosario
Aislamiento. Propiedad que garantiza que la ejecución concurrente de transacciones pro-

duce el mismo resultado que si se ejecutasen de manera secuencial.
Concurrencia. Ejecución de múltiples transacciones de manera simultánea.
Dato de carácter personal. Cualquier información que permite identificar a una persona
o hacerla fácilmente identificable.
Interbloqueo. Situación que se produce cuando dos transacciones que se ejecutan simultá-
neamente están bloqueando un recurso que necesita la otra transacción, quedando por
tanto ambas bloqueadas indefinidamente en espera de que la otra transacción finalice.
LOPD. Ley Orgánica de Protección de Datos.
Niveles de aislamiento. Los niveles de aislamiento determinan el grado en que se debe
aislar una transacción de las modificaciones de datos o recursos producidas por otras
transacciones El nivel de aislamiento determina qué se bloquea y cuándo se producen
los bloqueos.
Propiedades ACID. Propiedades que garantizan que las transacciones se ejecutan de manera
confiable: atomicidad (A), consistencia (C), aislamiento (I, de isolation) y durabilidad (D).
Restricciones. Reglas que determinan cuándo son válidos los valores que se insertan en
la base de datos. Las restricciones tienen como objetivo garantizar la integridad de la
información.
Encriptación transparente (Transparent Data Encryption: TDE). Mecanismo de encrip-
tación por medio del cual el sistema gestor se encarga de encriptar y desencriptar la
información automáticamente al guardarla y recuperarla.
4.1. Introducción
En cualquier sistema de base de datos, será necesario asegurar tanto la confidencialidad de la
información como la integridad de la información almacenada, para evitar la corrupción de
la información o la aparición de inconsistencias.
En los sistemas multiusuario, además de asegurar que cada usuario acceda únicamente a la
información a la que tiene permiso, será necesario garantizar que no se produzcan errores de-
bido al acceso simultáneo de varios usuarios.
Existen dos tipos de políticas que debe llevar a cabo el administrador de base de datos para
garantizar la seguridad:
● Políticas activas: tareas que se implementan de manera proactiva para evitar fallos en el
funcionamiento del SGBD.
● Políticas pasivas: se aplican de manera reactiva en ocasiones en que las políticas activas no
han alcanzado su propósito, y tratan de detectar la causa de los fallos, una vez que estos
son irremediables.
Capítulo 4
Las principales áreas de trabajo para garantizar la seguridad de los datos son la confidencia-
lidad y la integridad.
a) La confidencialidad trata de garantizar que los usuarios no accedan a información no

autorizada. Esto se consigue por medio de las siguientes funciones:
– Políticas activas: gestión de usuarios y permisos, definición de esquemas externos y

encriptación de la información.
– Políticas pasivas: auditoría.
b) Garantizar la integridad consiste en asegurar que los datos reflejen la realidad de manera
correcta y completa, cumpliendo las reglas y restricciones definidas en el diseño de la
base de datos. Para garantizar la integridad de los datos, es fundamental partir de un
diseño adecuado (normalizado), ya que eso evitará posibles anomalías en la inserción,
modificación o borrado de información. Por su parte, el sistema gestor dispone de va-
rias herramientas que permiten mantener la integridad de la información:
– Políticas activas: restricciones, control de concurrencia, gestión de transacciones.

– Políticas pasivas: respaldo y recuperación.
4.2. Confidencialidad
Además de la gestión de usuarios y permisos y la definición de esquemas externos, existen otras
medidas que se pueden llevar a cabo para garantizar la confidencialidad de la información: la
encriptación y la auditoría.
4.2.1. Encriptación
Por medio de los sistemas de gestión de usuarios y permisos y la definición de vistas, se garantiza
que los usuarios no accedan incorrectamente a la información a través del sistema gestor de base
de datos, pero esto no garantiza que no puedan acceder a las estructuras de almacenamiento del
sistema operativo donde se almacenan los datos.
Hay casos también en que es necesario restringir el acceso a datos concretos de una tabla
para determinados usuarios, aunque estos tengan acceso a la tabla.
Para proteger estos accesos, los sistemas gestores de bases de datos implementan herramien-
tas de encriptación que permiten que la información se guarde de forma cifrada (por medio de
algoritmos como RSA o AES) y solamente se pueda desencriptar accediendo a ella a través
de las herramientas que proporciona el sistema gestor.
Existen dos maneras de cifrar la información:
a) Por medio de funciones: la información se encripta y desencripta aplicando funciones

que proporciona el sistema gestor, de forma que para insertar datos encriptados habrá que
hacerlo usando la función de encriptar, y para recuperarlos habrá que hacerlo usando la
función de desencriptar. Existen dos tipos de funciones: las que guardan la información
encriptada y no permiten desencriptarla y las que permiten guardar la información en-
criptándola usando una clave de cifrado y desencriptarla de nuevo usando la misma clave.
Capítulo 4
Seguridad 115
b) Cifrado transparente: el cifrado transparente permite almacenar la información de forma

encriptada en los dispositivos físicos sin necesidad de que el usuario tenga que encrip-
tar explícitamente la información cuando la almacena ni que tenga que desencriptarla
cuando la consulta: esta funcionalidad la realiza automáticamente el sistema gestor de
forma transparente para el usuario, sin que este tenga que saber siquiera si la informa-
ción se está almacenando encriptada o no.
La mayoría de sistemas gestores están desarrollados por medio de una arquitectura cliente/
servidor, de modo que los clientes acceden a los datos alojados en el servidor a través de una
red. Para garantizar la confidencialidad de estas comunicaciones, la mayoría de sistemas gestores
multiusuario permite también asegurar las comunicaciones a través de la red estableciendo co-
municaciones por medio de protocolos seguros como SSL.
A) Encriptación por medio de funciones

La encriptación por medio de funciones es una encriptación manual: el programador que
acceda o almacene los datos será el encargado de encriptar y desencriptar la información res-
pectivamente utilizando tres tipos de funciones:
1. Encriptar y desencriptar: permiten encriptar un texto que podrá ser desencriptado. Se

suele utilizar para ocultar datos a los que no se quiere que tengan acceso usuarios que
sí tienen acceso a la tabla (salarios de empleados, datos protegidos por la LOPD, etc.).
2. Hash: se utiliza para calcular una clave (hash) que no podrá ser desencriptada. Se suele
utilizar este tipo de encriptación para guardar contraseñas de usuarios (que nunca de-
berían poder recuperarse tal cual están almacenadas: para comprobar si una contraseña
es correcta se encriptará esta y se comparará con el valor encriptado almacenado).
3. MAC: es similar a la función hash pero funciona pasándole una clave de encriptación
(es decir, para aplicar la encriptación es necesario pasarle una contraseña). Esto impedi-
ría por ejemplo que una aplicación pueda validar una contraseña de usuario si no tiene
la clave de encriptación necesaria para aplicarle la función MAC. Son más seguras que
las funciones hash ya que permitirían impedir determinados ataques (de fuerza bruta o
de diccionario) encaminados a obtener contraseñas de usuario; si el atacante no conoce
la clave de encriptación no podrá obtener el valor hash almacenado.
B) Cifrado transparente

La encriptación por medio de funciones es bastante tediosa para el usuario, ya que obliga
a estar constantemente, y de manera explícita, encriptando y desencriptando los datos. Es útil
cuando queremos que determinados usuarios no puedan consultar determinados datos aunque
accedan a través del sistema gestor y tengan permisos suficientes para ver la tabla en la que se
almacenan, pero si lo único que queremos realmente en proteger nuestros sistemas de alma-
cenamiento de forma que toda la información se guarde encriptada para que en caso de robo
no la puedan extraer, podemos emplear la encriptación transparente (TDE, Transparent Data
Encryption).
Capítulo 4
La encriptación transparente lo que nos garantiza es que la información se almacene en-

criptada en los dispositivos físicos, pero siempre que se consulte o se inserte se hará con los datos
descifrados.
Ten en cuenta
La encriptación transparente no permite cifrar la información para unos usuarios pero no para
otros: siempre que accedan a través del sistema gestor, los usuarios podrán consultar los datos,
pero si intentan acceder directamente a través del sistema operativo o con cualquier otra
herramienta, no los podrán ver ya que estarán cifrados.
Para encriptar y desencriptar los datos se utiliza una clave de encriptación y un algorit-
mo (normalmente AES, pero pueden ser otros) que utilizará el sistema gestor para encriptar y
desencriptar los datos de forma transparente para el usuario. En caso de que fuese necesario
migrar la base de datos a otro servidor, sería imprescindible copiar también la clave de encrip-
tación para poder acceder a los datos en el nuevo servidor.
Todos estos mecanismos de encriptación se complementan entre ellos, ya que cada uno
de ellos tiene una funcionalidad. Accede al recuso digital Tipos de encriptación,
donde se plantean distintos casos prácticos, en los que habrá que elegir el tipo de encrip-
tación más adecuado para cada uno de ellos.
4.2.2. Auditoría
La auditoría de la base de datos consiste en guardar registro de las operaciones llevadas a cabo
por los usuarios en el sistema gestor, lo que permite al administrador de la base de datos conocer
detalles acerca del uso que se hace de la base de datos por parte de los usuarios.
Es una medida de seguridad pasiva ya que normalmente se recurre a ella en casos en que
se ha registrado un acceso o una operación inadecuada y es necesario comprobar quién fue el
responsable de dicho acceso o cual fue la operación que generó el error. La funcionalidad de
la auditoría no es evitar ese acceso u operación inadecuados, sino diagnosticar lo sucedido para
poder tomar las medidas oportunas.
Por medio de la auditoría es posible detectar varios tipos de anomalías, como por ejemplo:
– Accesos no autorizados al sistema, realizados por usuarios que no deberían tener acceso
o en horas anómalas.
– Ataques de desbordamiento de memoria (buffer overflow), basados en pasar como en-
trada a un programa más datos de los que espera recibir, lo que podría permitir al ata-
cante escribir en una zona de memoria más allá de la reservada.
– Inyección de Código SQL, ataque que consiste en incorporar en el código ejecutado
por las aplicaciones que acceden a la base de datos comandos no autorizados.
Capítulo 4
Seguridad 117
Existen dos niveles de auditoría:

a) A nivel de sesión: permitirá conocer detalles propios de la sesión, como los usuarios conecta-
dos a las bases de datos, las tablas a las que acceden, o el puesto desde el que se ha accedido.
b) A nivel de objetos: nivel más fino de auditoría que permite conocer los accesos y ope-
raciones que se han realizado sobre objetos de la base de datos (normalmente tablas
o columnas). Por medio de este tipo de auditoría, será posible conocer qué usuarios
acceden en qué momento a esos objetos y las operaciones que realizan sobre ellos, lo
cual es muy útil, por ejemplo, para implementar políticas de control de acceso a datos
sensibles como los protegidos por la LOPD.
La información de auditoría se puede guardar tanto en ficheros como en tablas del dic-
cionario de datos del propio sistema gestor. Si se almacena la información en el diccionario de
datos, cualquier acceso a un objeto auditado se guardaría como una fila en una tabla, lo que
facilita considerablemente la consulta y revisión de la información auditada pero implica mayor
carga para el sistema gestor y un consumo de espacio considerable si la política de auditoría es
muy restrictiva, por lo que se deberían limitar los objetos auditados para no comprometer los
recursos del sistema.
Toma nota
La información de auditoría no se debe almacenar nunca en el mismo disco donde se

almacenan el sistema operativo del servidor o el SGBD. Si el sistema gestor sufriese un
ataque y registrase todos los intentos de acceso, podría llegar a consumir todo el espacio
disponible en disco, con lo cual no sería posible ni siquiera iniciar sesión en el servidor
para realizar las acciones correctivas necesarias.
Lo más recomendable es almacenar esta información en discos externos o sistemas
de almacenamiento en red.
4.3. Confidencialidad en Oracle

Oracle dispone tanto de mecanismos para la encriptación de la información como para auditar
los accesos a la misma. En el siguiente apartado se indican los distintos mecanismos existentes
para llevar a cabo estas funcionalidades.
4.3.1. Encriptación
Los datos almacenados en el servidor Oracle pueden ser encriptados utilizando explícitamente
funciones para cifrarlos y descifrarlos, o puede delegarse esta tarea en el servidor, que dispone de
una herramienta cuya función es encriptar y desencriptar la información almacenada de forma
transparente al usuario: TDE: (Transparent Data Encryption).
A) Encriptación por medio de funciones

Oracle dispone de un paquete, llamado DBMS_CRYPTO, donde se almacenan todas las fun-
ciones existentes para encriptar y desencriptar la información. Los paquetes en Oracle permiten
Capítulo 4
almacenar de manera conjunta una serie de funciones, procedimientos y constantes que tienen una
funcionalidad común.Todos los paquetes del sistema se almacenan en el diccionario de datos, por
lo que se puede acceder a ellos consultando los paquetes definidos en el esquema del usuario SYS.
Figura 4.1
Paquetes del diccionario
de datos.
Las funciones incluidas en el paquete DBMS_CRYPTO permiten hacer uso de algoritmos

como DES (Data Encryption Standard), AES (Advanced Encryption Standard) o SHA-2 (Se-
cure Hash Algorithm, versión 2) para encriptar la información.
Las funciones más empleadas para cifrar la información en Oracle son las siguientes:
1. Encrypt: permite encriptar un texto (de tipo CLOB) que podrá ser desencriptado por me-
dio de la función decrypt. La encriptación se puede llevar a cabo empleando varios modos
de cifrado (ECB, CBC, CFB o OFB), que básicamente difieren en el modo en que aplican
la clave de cifrado y el vector de inicialización (si lo hay) sobre el mensaje original.
DBMS_CRYPTO.ENCRYPT(
dst IN OUT NOCOPY BLOB, -- destino
src IN CLOB CHARACTER SET ANY_CS, -- texto a encriptar
typ IN PLS_INTEGER, -- modo de encriptación
key IN RAW, -- clave de cifrado
iv IN RAW DEFAULT NULL); -- vector de inicialización
2. Decrypt: usado para desencriptar un texto encriptado con la función encrypt.
DBMS_CRYPTO.DECRYPT(
dst IN OUT NOCOPY BLOB, -- destino
src IN BLOB, -- texto a desencriptar
typ IN PLS_INTEGER, -- modo de encriptación
key IN RAW, -- clave de cifrado
iv IN RAW DEFAULT NULL); -- vector de inicialización
3. Hash: se utiliza para calcular un hash que no podrá ser desencriptado. Se puede aplicar
sobre variables de tipo RAW (tipo binario de longitud fija), BLOB (un objeto binario)
o CLOB (un objeto expresado en forma de caracteres de 1 byte).
Capítulo 4
Seguridad 119
DBMS_CRYPTO.Hash (
src IN RAW, -- texto a encriptar
typ IN PLS_INTEGER) -- tipo de algoritmo utilizado
RETURN RAW;
4. MAC: se utiliza para calcular un hash pero pasándole una clave de encriptación. Al igual
que en el caso anterior, se puede aplicar sobre variables de tipo BLOB, RAW o CLOB.
DBMS_CRYPTO.MAC (
src IN RAW, -- texto a encriptar
typ IN PLS_INTEGER, -- tipo de algoritmo usado
key IN RAW) -- clave de encriptación
RETURN RAW;
B) Cifrado transparente

El cifrado transparente de Oracle (TDE, Transparent Data Encryption) permite que la in-
formación de una columna o tablespace se guarde siempre encriptada, siendo el sistema gestor
quien se encarga de cifrar la información automáticamente al guardarla y descrifrarla al consul-
tarla. Esto incrementa la seguridad de nuestro sistema pero empeora los tiempos de acceso, por
lo que no se debe abusar de esta capacidad.
Sistema gestor de base de datos
encripta
desencripta
Master
Listener key
Cliente Keystore
Base de datos
Figura 4.2
Encriptación transparente.
TDE permite utilizar diferentes algoritmos para cifrar la información. Para ello emplea una
clave de cifrado maestra (Master Encryption Key) formada por un par de claves publica/privada
o certificados digitales, que se guardan en un almacén de claves al que denomina Wallet (en las
versiones 11g y anteriores) o Keystore (a partir de la 12c), que no es más que un fichero para
almacenar claves.
El keystore puede abrirse o cerrarse, por lo que si en algún momento queremos denegar el
acceso a la información a los usuarios, no tenemos más que cerrar el keystore (si está cerrado
no se puede acceder a las claves y, por tanto, no se puede descifrar la información).
Capítulo 4
Para habilitar la encriptación transparente, habrá que realizar 3 pasos:
1. Crear un keystore para almacenar las credenciales: Los almacenes de claves se gestionan
siempre desde la instancia (ORCL), y es necesario hacerlo siempre con un usuario co-
nectado con rol de DBA. Hay dos tipos de keystores:
● Basados en password: se crean usando un password y para realizar cualquier ope-

ración con ellos (abrirlos y cerrarlos, principalmente) será necesario utilizar ese
password. Son los más fáciles de crear, pero cada vez que se reinicia la instancia es
necesario volver a abrirlos manualmente, lo cual puede ser poco operativo.
● De auto_login: se crean a partir de un keystore basado en password y lo que hacen es
abrir este keystore basado en password automáticamente cada vez que este se cierra.
2. Incluir en el fichero de configuración de las conexiones (sqlnet.ora) la ruta donde está

el almacén de claves (keystore).
3. Habilitar o deshabilitar el uso del almacén de claves para permitir o impedir el acceso
a los datos encriptados. Si queremos emplear el keystore desde todas las PDB, al abrirlo
debemos hacerlo usando la opción CONTAINER=ALL.
Para crear un keystore basado en password, debemos realizar las siguientes operaciones:
a) Crear el keystore:
SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE ‘c:\app\oracle\admin\

orcl\wallet\’ IDENTIFIED BY password;
b) Abrir el keystore:
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY password

CONTAINER=ALL;
De esta manera se crea el keystore y se abre en todas las PDB, pero todavía no tiene
una master key para cifrar y descifrar la información, por lo que al consultar su estado
a través de la vista V$ENCRYPTION_WALLET veremos que su estado es “OPEN_
NO_MASTER_KEY”:
SQL> select * from V$ENCRYPTION_WALLET;
c) Crear la master key: Al igual que sucede con el keystore, la master key se debe crear
en la instancia (ORCL) usando un usuario con rol DBA, y, para que pueda utilizarse en
todas las PDB, será necesario indicar “CONTAINER=ALL”:
SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY password WITH BAC-
KUP CONTAINER=ALL;
Capítulo 4
Seguridad 121
d) El problema de estos almacenes de claves basados en password es que cada vez que se
reinicia la instancia es necesario abrirlos explícitamente. Para evitarlo es posible crear
un keystore de auto login, que lo único que hace es abrir automáticamente el keystore
basado en password cuando este se cierra. Para crear un keystore de auto login, habría
que ejecutar, también en la instancia ORCL, las siguientes operaciones:
-- Cerramos en primer lugar el keystore basado en password.

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY password;
-- Creamos el keystore de auto login.
SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE
‘C:\app\oracle\admin\mis_wallets’ IDENTIFIED BY password;
-- Al ser de auto login ya no necesitamos abrirlo, se abre solo.
SQL> SELECT WRL_PARAMETER,STATUS,WALLET_TYPE FROM V$ENCRYPTION_WALLET;
Aparecerá en la carpeta del keystore un fichero llamado “cwallet.sso”. Es necesario mante-

ner también el fichero ewallet.p12 (el basado en password) ya que será donde buscará la clave
cuando tenga que abrir el keystore.
Realiza las actividades propuestas en el recurso digital Encriptación para comprender

mejor el funcionamiento de los distintos métodos de encriptación de Oracle, y cono-
cer mejor la forma de aplicar cada uno de ellos.
4.3.2. Auditoría
La activación de la auditoría en Oracle viene definida por el valor del parámetro: “audit_trail”.
Consultando la vista que muestra los parámetros de la instancia se puede comprobar si la audi-
toría de la base de datos está activada:
SQL> select name, value from v$parameter where name like ‘audit_trail’;
Este parámetro puede tomar varios valores, pero los más usuales son:
● none: la auditoría de la base de datos está desactivada.

● os: activa la auditoría de la base de datos, pero los sucesos auditados serán redirigidos al
sistema operativo, que será el responsable de registrarlos.
● db: activa la auditoría y los datos se almacenarán en el diccionario de datos, en la tabla
SYS.AUD$.
● xml: habilita la auditoría y registrar todos los eventos en ficheros xml que se almacena-
rán en la ruta indicada en el parámetro “audit_file_dest”.
Capítulo 4
Para activar o desactivar la auditoría, solamente habrá que cambiar el valor del parámetro:
ALTER SYSTEM SET audit_trail = ‘DB’|’none’ SCOPE=SPFILE;
En Oracle existen tres herramientas para gestionar la auditoría:
1. El comando audit: permite auditar accesos al sistema, acciones de la base de datos y

accesos a objetos. Permite diferenciar entre acciones correctas e incorrectas, es decir,
permitiría registrar por ejemplo únicamente los intentos de inicio de sesión fallidos.
2. El paquete de auditoría fina dbms_fga: permite auditar accesos a objetos pero con un
nivel de detalle mucho más fino que con el comando audit. Con audit podríamos re-
gistrar si un usuario consulta una tabla, pero con la auditoría fina podríamos registrar
únicamente las consultas que consulten simultáneamente determinados campos de una
tabla, o las modificaciones que se realicen sobre un campo especificando un valor con-
creto, por ejemplo.
3. La auditoría unificada: al igual que sucede con los permisos y los roles, en ocasiones
también es necesario auditar un grupo de acciones para varios usuarios. Con audit y
noaudit esta gestión era necesario realizarla manualmente, y dado que la información
de auditoría se almacena en varias tablas diferentes, cuando se auditan varias acciones
para muchos usuarios es bastante complejo saber qué se está auditando a quién. Para
simplificar esta gestión de la auditoría, a partir de la versión 12c de Oracle se creó la
auditoría unificada, que permite crear reglas de auditoría similares a las de la auditoría
fina que permiten agrupar un conjunto de acciones de auditoría para asignárselas a los
usuarios.
A) Los comandos audit y noaudit

Para que funcionen correctamente estos comandos, es necesario que la auditoría (audit_
trail) esté activada. Para poder activar la auditoría con el comando audit, se necesita el privilegio
AUDIT SYSTEM. Además, para activar la auditoría de un objeto el usuario tiene que ser el
propietario del objeto o disponer del privilegio de sistema AUDIT ANY.
Con el comando audit se pueden auditar tres tipos de acciones:
1. Auditorías de inicio de sesión: audita los intentos de conexión con la base de datos. Las
acciones auditadas pueden limitarse a un usuario concreto o a un resultado concreto (si
el acceso ha sido correcto o incorrecto).
AUDIT SESSION [BY <usuario>] [WHENEVER SUCCESSFUL | NOT SUCCESSFUL];
2. Auditorías de acción: permiten auditar cualquier acción que afecte a un tipo de objeto
de la base de datos (tablas, enlaces de base de datos, tablespaces, sinónimos, usuarios,
índices, etc.). Las posibles acciones que pueden auditarse (create, alter, drop) sobre estos
tipos de objetos pueden agruparse para simplificar la cantidad de esfuerzo administrati-
vo necesario para determinar y mantener las opciones de configuración de la auditoría.
Capítulo 4
Seguridad 123
Cuando se habilita esta auditoría también es posible limitar las operaciones que se
registrarán o el usuario sobre el que se actuará
AUDIT [<operación>] <tipo de objeto> [BY <usuario>];
¿Sabías que...?
Hasta la versión 11g de Oracle, el comando audit permitía registrar las operacio-
nes por sesión o por acceso. A partir de esa versión, sigue permitiendo indicar
“BY ACCESS” o “BY SESSION” al ejecutar el comando pero independientemente
de la opción que se indique siempre registra las acciones por acceso.
3. Auditorías de objeto: audita las acciones de manipulación de datos sobre objetos concre-
tos. Se pueden auditar operaciones de select, insert, update y delete sobre tablas o vistas
y las ejecuciones (execute) de procedimientos y funciones. Este tipo de auditoría no se
puede restringir a usuarios determinados como las dos anteriores.
AUDIT {insert | update | delete | select | all}

ON <objeto> [WHENEVER [NOT] SUCCESSFUL];
El comando noaudit se utiliza para detener el registro de la auditoría que se había activado
previamente con la instrucción audit. Tiene exactamente la misma sintaxis que audit, con las
mismas opciones en función del tipo de auditoría que se quiera detener.
Ten en cuenta
El comando noaudit solo desactiva la auditoría de su comando audit análogo: si se habilita

la auditoría de sesión para un usuario con la opción “whenever not successful”, habrá que
deshabilitarla para ese usuario específico y también con la opción “whenever not successful”.
Con la auditoría de objetos sí es posible deshabilitar la auditoría de una acción directamente
sobre una tabla, lo que deshabilitará dicha acción, sea cual sea el resultado de la operación (es
decir, cuando la auditoría se define sobre objetos concretos el comando noaudit no obliga a
indicar explícitamente las opciones “whenever successful” o “whenever not successful”).
B) Auditoría de grano fino

En la versión Oracle 9i se incorporó un método de auditoría más refinado, la Fine Grained
Auditing (FGA), que es una auditoria basada en reglas. A diferencia de la funcionalidad estándar
de auditoría con el comando AUDIT, FGA permite especificar las condiciones necesarias para
que un registro de auditoría se genere.
Las reglas se gestionan por medio del paquete de Oracle ‘DBMS_FGA’, que contiene los pro-
cedimientos necesarios para crear, deshabilitar, habilitar o eliminar las reglas. Para poder crear una
regla de auditoría es necesario disponer de permisos de ejecución en el paquete DBMS_FGA.
Capítulo 4
Cuando se crea una regla, es necesario indicar a qué objeto estará asociada (una tabla o vista)
y qué condición disparará los eventos de auditoría (por ejemplo, auditar los accesos a una tabla
que se realicen entre las 6 PM y 6 AM de los sábados y domingos, que utilicen una dirección
IP desde fuera de la red corporativa, que actualicen una columna concreta, o que usen un valor
concreto para esa columna).
FGA admite todas las combinaciones de ‘select’,‘insert’,‘update’,‘delete’, condiciones ‘whe-
re’ o selección de una o varias columnas en particular. Solo se generarán registros de auditoria
cuando se cumplan estas condiciones, todas o alguna de ellas, según se desee.
Para guardar un registro cada vez que un usuario acceda simultáneamente a las columnas
SALARIO y DNI de los empleados de un departamento concreto que tienen comisión, ten-
dríamos que crear una regla como la siguiente:
execute dbms_fga.add_policy(
object_schema=>’RRHH’,
object_name=> ‘EMPLEADOS’,
policy_name=> ‘chk_rrhh_empleados’,
audit_condition => ‘ID_DEPTO = 50 and COMISION > 0’,
audit_column => ‘DNI,SALARIO’,
enable => TRUE,
statement_types => ‘INSERT, UPDATE, SELECT, DELETE’,
audit_trail => DBMS_FGA.DB,
audit_column_opts => dbms_fga.all_columns);
Donde:
– Object_schema: indica el esquema al que pertenece el objeto auditado.

– Object_name: es el objeto que se audita.
– Policy_name: es el nombre que pondremos a la regla (será necesario para poder desha-
bilitar o habilitar la regla posteriormente).
– Audit_condition: condiciones que deben cumplir las filas para ser auditadas (es opcional)
– Audit_column: columnas que se auditan (pueden ser una o varias). Si no se especifica
ninguna columna, la auditoría se aplica a todas las columnas.
– Audit_trail: indica dónde se almacenará la información de auditoría.
– Audit_column_opts: si hay varias columnas auditadas, indica cuando se aplica la au-
ditoría: si se aplica cada vez que se accede a una cualquiera de las columnas indicadas
(DBMS_FGA.ANY_COLUMNS) o si se aplica cuando se accede a todas las columnas
simultáneamente (DBMS_FGA.ALL_COLUMNS).
Para dejar de aplicar una regla de auditoría, se puede borrar la regla directamente (DBMS.
FGA.DROP_POLICY), o bien deshabilitarla (DBMS_FGA.DISABLE_POLICY), lo que
permitiría volver a habilitarla posteriormente (DBMS_FGA.ENABLE_POLICY):
execute DBMS_FGA.DROP_POLICY(
object_schema => ‘HR’,
object_name => ‘EMPLOYEES’,
policy_name => ‘ck_au_employees’);
Capítulo 4
Seguridad 125
C) Auditoría unificada

La auditoría unificada permite crear reglas de auditoría que incluyen varias acciones, y ha-
bilitar o deshabilitar dichas reglas o asignarlas a usuarios concretos, facilitando la gestión de la
auditoría para múltiples acciones y múltiples usuarios.
Las reglas de auditoría se crean con el comando “CREATE AUDIT POLICY”.
CREATE AUDIT POLICY <regla> ACTIONS

CREATE TABLE,DROP TABLE,ALTER TABLE,GRANT,REVOKE,…;
Una vez creada la regla, se podría habilitar o deshabilitar utilizando audit y noaudit.
AUDIT POLICY <regla> [BY <usuario>] [WHENEVER [NOT] SUCCESSFUL];

NOAUDIT POLICY <regla> [BY <usuario>] [WHENEVER [NOT] SUCCESSFUL];
Para borrar una regla de auditoría, usaríamos drop.
drop audit policy <regla>;
D) Registro de auditoría en el diccionario de datos

Cuando se activa el registro de auditoría a nivel de base de datos, toda la información se
almacena en el diccionario de datos, pero en diferentes tablas en función del tipo de auditoría
empleada:
– La información de los inicios de sesión y acciones que se han registrado se almacena en

la vista DBA_AUDIT_SESSION.
– La información de los objetos auditados a los que se ha accedido se almacena en la vista
DBA_AUDIT_OBJECT.
– La información de auditoría FGA se guarda en la tabla FGA_LOG$, pero también
existe una vista para consultar de forma más sencilla la información auditada: DBA_
FGA_AUDIT_TRAIL.
– La configuración de la auditoría también se almacena en el diccionario de datos.
– En la vista DBA_STMT_AUDIT se almacenan las acciones e inicios de sesión que está
auditando el sistema.
– La vista DBA_OBJ_AUDIT_OPTS guarda registro de las operaciones que se están
auditando sobre objetos.
– Las reglas que se han definido por medio de la auditoría FGA se pueden consultar en
la vista DBA_AUDIT_POLICIES.
Para consultar las reglas de auditoría unificada existentes, se pueden utilizas las vistas:
● AUDIT_UNIFIED_POLICIES: contiene las reglas de auditoría existentes.
Capítulo 4
● AUDIT_UNIFIED_ENABLED_POLICIES: contiene únicamente las que están habi-

litadas.
● DBA_COMMON_AUDIT_TRAIL: incluye todos los eventos auditados por cual-
quiera de los tres mecanismos de auditoría.
Figura 4.3
Resumen
auditoría de
Oracle.
Para comprobar el funcionamiento de todas las opciones de auditoría que provee

Oracle, accede al recurso digital Auditoría, donde se proponen varios ejerci-
cios con los que se trabajará la auditoría a todos los niveles: sobre acciones e
inicios de sesión, sobre objetos, de grano fino y la auditoría unificada.
4.4. Integridad
Tal y como se indicó anteriormente, fundamentalmente existen cuatro funcionalidades que
permiten garantizar la integridad de la información almacenada en el sistema gestor: la defini-
ción de restricciones, los mecanismos de control de concurrencia y de control de transacciones
y la realización de copias de seguridad.
4.4.1. Restricciones
Los sistemas gestores proporcionan herramientas para definir restricciones sobre las tablas o las
columnas, para garantizar la integridad de los datos almacenados.
En los sistemas relacionales, hay varias restricciones que son inherentes al modelo:
● No pueden existir dos tuplas iguales en una tabla.

● El orden de las filas y columnas es irrelevante.
● Cada atributo puede tomar únicamente un valor.
● Un atributo solamente podrá tomar valores en el dominio que tenga definido.
Normalmente, los sistemas gestores permiten definir restricciones adicionales, que pueden
aplicarse sobre uno o varios campos de una tabla, e incluso existen restricciones que permiten
realizar verificaciones sobre los datos de más de una tabla. Los principales tipos de restricciones
existentes son los siguientes.
Capítulo 4
Seguridad 127
Cuadro 4.1
Principales restricciones
De nulidad Asegura que los valores insertados en un atributo o conjunto de atributos no toman
valores nulos.
De unicidad Asegura que los valores insertados en un atributo o conjunto de atributos no se
repiten.
Valor por Aplicable a una columna, permite asignar un valor por defecto que se asignará a la
defecto columna en caso de que no se indique el valor del campo en una inserción.
De clave Aplicable a una o varias columnas de una tabla, asegura que los valores insertados
primaria en esa combinación de atributos cumplen las restricciones de unicidad y de nulidad.
De clave Un atributo o conjunto de atributos definidos como clave foránea hacen referencia a
foránea la clave primaria en otra tabla, y esta restricción garantiza que solamente se puedan
asignar valores a los atributos de la clave foránea que existan en la clave primaria. La
restricción de clave foránea también permite indicar la operación a llevar a cabo en la
clave foránea en caso de modificación o borrado de su clave principal asociada: trasla-
dar el cambio o eliminación a la clave foránea, impedir el cambio o eliminación de la
clave principal, asignar un valor nulo a la clave foránea o ponerle un valor por defecto.
De Permite establecer una condición que se comprobará cada vez que se modifique
comprobación una columna o conjunto de columnas de una tabla, impidiendo realizar la modifi-
cación si no se cumple la condición.
Disparadores Los disparadores permiten definir acciones que se ejecutarán antes o después de
hacer modificaciones en una tabla.
En ocasiones es necesario deshabilitar las restricciones en el sistema gestor para realizar deter-
minadas tareas, por lo que los sistemas gestores proporcionan mecanismos que permiten desha
bilitar las restricciones: algunos permiten deshabilitar solo restricciones concretas y otros obligan
a deshabilitar todas las restricciones existentes (no permiten deshabilitar unas sí y otras no).
Ejemplo
Pongamos por ejemplo el caso de los empleados de un departamento:
Figura 4.4
Ejemplo de restricciones.
En el campo “coddepto” de la tabla empleado definimos una foreign key “FK_EMP_DEP-

TO” que valide que el departamento que asigno a un empleado exista y asigno una restricción
“NOT NULL” para que no pueda haber empleados sin departamento.
Capítulo 4
En el campo “codjefe” de la tabla departamento definimos también una foreign key “FK_
DEPTO_JEFE” que valide que el jefe que asigne a un departamento exista en la tabla de em-
pleados, y asigno una restricción “NOT NULL” para que no pueda haber departamentos sin
jefe asignado.
Si acabamos de crear la base de datos y las tablas están vacías, y queremos comenzar a
insertar datos en ambas tablas:
– si intentamos insertar en primer lugar un empleado fallará porque no le podemos

asignar un departamento (no hay ninguno creado en la tabla de departamentos), y no
podemos tampoco dejar el campo a NULL.
– si intentamos insertar primero un departamento, fallará también porque no hay em-
pleados que asignarle como jefe, y tampoco podemos dejar el campo a NULL.
La solución en este caso pasaría por deshabilitar las restricciones que generan los proble-
mas, hacer la inserción, y luego habilitarlas de nuevo:
ALTER TABLE empleado DISABLE CONSTRAINT FK_EMP_DEPTO; -- deshabilita la

clave foránea.
ALTER TABLE empleado ENABLE CONSTRAINT FK_EMP_DEPTO; -- la habilita de
nuevo.
Ten en cuenta
Si se deshabilitan las restricciones y se quieren volver a habilitar, el sistema verificará que se

cumplan las condiciones necesarias en todos los registros de la tabla para volver a habilitar-
las (si encuentra alguna fila que no cumpla las condiciones de la restricción dará un error y
no permitirá habilitarla hasta que se solucione el problema), lo que puede llevar un tiempo
considerable. En los sistemas gestores que no permiten deshabilitar restricciones concretas y
obligan a deshabilitar y habilitarlas todas, esto puede ser muy costoso.
4.4.2. Control de concurrencia
Una transacción se define como una unidad lógica de tratamiento (conjunto de órdenes) que
aplicada a un estado consistente de la base de datos la deja, de nuevo, en un estado consistente,
después de hacer las modificaciones. La gestión de transacciones debe asegurar que una transac-
ción solo se pueda ejecutar completamente o ser anulada.
Para implementar el control de transacciones, los sistemas gestores proveen de un lenguaje
de control de transacciones (TCL). Este lenguaje es muy sencillo, ya que solamente permite dos
operaciones: commit y rollback. Cada operación de inserción, modificación o borrado que se
realiza en la base de datos da origen a una transacción, y su final vendrá marcado por una de
esas dos sentencias:
● commit es la confirmación de que la transacción ha finalizado correctamente, por lo

que los cambios deberán trasladarse a la base de datos y hacerse persistentes.
Capítulo 4
Seguridad 129
● rollback se ejecuta cuando se ha producido algún error, y deshace los cambios realizados
desde que dio comienzo la transacción.
Una transacción puede estar compuesta por varias operaciones y tardar un tiempo con-
siderable en completarse, por lo que los sistemas gestores requieren de un sistema de control
de concurrencia que permita el acceso simultáneo a los datos por parte de los usuarios y ase-
gure que las operaciones que se ejecutan concurrentemente produzcan el mismo resultado
final que si estos accediesen secuencialmente (uno a continuación de otro). El objetivo del
sistema de control de concurrencia es garantizar la consistencia de los datos almacenados
en la base de datos.
Cuando varias transacciones se ejecutan de forma concurrente (simultáneamente) y acce-
den a los mismos datos, pueden producirse tres tipos de problemas:
1. Lectura sucia (dirty read): se produce cuando una transacción lee datos modificados por
otra transacción que todavía no ha sido comitada.
Figura 4.5
Ejemplo de lectura sucia.
2. Lectura no repetible (nonrepeateable read): se produce cuando una transacción vuelve a

leer datos que había leído previamente y encuentra que han sido modificados por otra
transacción.
Figura 4.6
Ejemplo de lectura no repetible.
3. Lectura fantasma (phantom read): se produce cuando una transacción lee unos datos que
no existían cuando se inició la transacción.
Capítulo 4
Figura 4.7
Ejemplo de lectura fantasma.
La forma más habitual de solucionar estos problemas es empleando bloqueos. Los bloqueos
se producen cuando una transacción realiza una lectura o escritura en una tabla, y su función es
impedir el acceso a esa tabla para el resto de transacciones hasta que no finalice la transacción
que generó el bloqueo.
Hay sistemas gestores que permiten definir distintas granularidades de bloqueo: pueden
bloquear una tabla completa, un datafile, una partición o solamente las filas concretas que se va-
yan a actualizar. Con esto se consigue que el número de transacciones afectadas por los bloqueos
sea mucho menor, con lo cual pueden optimizar la ejecución en paralelo de las transacciones.
¿Sabías que...?
La granularidad del bloqueo en MySQL se realiza a nivel de tabla. Esto impide que se puedan
realizar operaciones como modificar los datos de una tabla que a su vez tienes que consultar
para obtener los datos a asignar. Por ejemplo, si queremos asignar a todos los empleados el
mismo salario, y el salario que se ha de asignar es la media de todos los salarios de la tabla,
tendríamos que ejecutar la sentencia:
UPDATE empleados SET salario=(SELECT avg(salario) FROM empleados);
En este caso, si hemos definido un nivel de aislamiento muy restrictivo, la subconsulta

bloquearía la tabla de empleados y el bloqueo impediría que la consulta principal modificase
los salarios de esa misma tabla, por lo que la sentencia daría un error y no se podría realizar
la modificación de los datos.
Uno de los problemas de los bloqueos es que pueden dar lugar a interbloqueos (deadlock).
Un interbloqueo se produce cuando una transacción bloquea un elemento que requiere otra
transacción que a su vez está bloqueando otro elemento que necesita la transacción inicial. Am-
bas transacciones quedarían a la espera de que la otra transacción finalice y libere su bloqueo,
pero como ambas están bloqueadas nunca finalizarán. Esto supone un gran problema ya que
las transacciones quedarían en espera indefinida y además estarían bloqueando cualquier otra
transacción que quisiese hacer uso de los mismos recursos.
Existen dos mecanismos para evitar el interbloqueo:
● Prevenirlo: obligando a que las transacciones bloqueen todos los elementos que necesitan
por adelantado, antes de empezar a ejecutarse.
Capítulo 4
Seguridad 131
● Detectarlo: el sistema gestor controla periódicamente si se ha producido algún interblo-

queo y, si se produce, mata la sesión que lo ha producido.
Figura 4.8
Ejemplo de interbloqueo.
El sistema gestor se encarga de gestionar automáticamente los bloqueos, y permite definir

diferentes niveles de aislamiento en función de los cuales los bloqueos serán más o menos res-
trictivos en cuanto a las operaciones (lecturas o escrituras) que generan los bloqueos. El nivel
de aislamiento determina de qué forma son visibles los cambios realizados por una transacción
para el resto de transacciones. El instituto de estándares estadounidense, ANSI, incluyó una
definición de los niveles de aislamiento en el estándar SQL-92, que en orden de menos a más
restrictivos, son los siguientes:
a) Lectura no confirmada (read uncommited): es el nivel menos restrictivo, ya que no

genera bloqueos y por tanto permite que los cambios realizados por una transac-
ción sean vistos por las otras transacciones. Este nivel de aislamiento permite que se
produzcan los tres problemas de la concurrencia: lectura sucia, lectura no repetible y
lectura fantasma.
b) Lectura confirmada (read commited): no bloquea las operaciones de lectura pero sí las de
escritura. Esto implica que los datos leídos por una transacción pueden ser modificados
por otras transacciones, lo que puede dar lugar a los problemas de lectura fantasma y
lectura no repetible.
c) Lectura repetible (repeatable read): tanto las operaciones de lectura como las de escritura
dan lugar a bloqueos, por lo que una vez que una transacción lee un registro, ninguna
otra transacción puede cambiar ese registro hasta que no finalice esa transacción. Este
nivel de aislamiento solo permite el problema de la lectura fantasma.
d) Serializable: es el nivel más restrictivo. Los bloqueos se realizan antes de iniciar la tran-
sacción, por lo que si hay varias transacciones que hacen uso de los mismos recursos,
estas transacciones se ejecutarán siempre en serie, una detrás de otra y de forma total-
mente asilada, sin posibilidad de concurrencia. Este nivel de aislamiento no permite
ninguno de los problemas anteriores, ni siquiera el interbloqueo.
Capítulo 4
Figura 4.9
Niveles de
aislamiento.
Toda la gestión de la concurrencia la realiza automáticamente el sistema gestor, por lo que

la labor del DBA en relación con el control de concurrencia se centrará en las siguientes tareas:
1. Establecer el nivel de aislamiento que sea más adecuado al uso que se realizará de la base
de datos.
2. Optimizar la distribución de los datos de las tablas para evitar los bloqueos en la medida
de lo posible. La forma en que se distribuyen los datos de una tabla afecta a los bloqueos
que se realizan sobre esa tabla: supongamos que tenemos una tabla de ventas donde se
guardan las ventas realizadas por internet, por aplicación móvil y en tienda física de for-
ma conjunta. Cuando es necesario realizar una modificación que afecte a varias ventas
realizadas en tienda, se bloqueará toda la tabla, impidiendo realizar ventas tanto presen-
ciales como remotas. Si modifico la forma de almacenar la información (particionar la
tabla en función del tipo de venta y guardar cada partición en un tablespace diferente,
por ejemplo), podría limitar el bloqueo de la tabla únicamente a la partición o el fichero
de las ventas en tienda, pudiendo trabajar normalmente el resto de aplicaciones.
3. Monitorizar que no se produzcan interbloqueos y eliminar las sesiones que lo hayan
producido. Hay sistemas que ya se encargan de realizar estas tareas, pero si no es así se
puede establecer una alerta que avise cuando se produzcan este tipo de situaciones para
tomar las medidas adecuadas.
4.4.3. Recuperación
Uno de los requisitos fundamentales de los sistemas gestores de bases de datos es garantizar la
disponibilidad de la información y la recuperación ante fallos, por lo que casi todos ellos in-
corporan herramientas que permiten efectuar copias de los contenidos de una base de datos.
Existen dos mecanismos básicos de restauración para garantizar la posibilidad de recuperar
la información en caso de fallo:
a) Copias de seguridad: herramientas que permiten exportar e importar la información al-

macenada en la base de datos en un soporte de almacenamiento externo al SGBD, de
forma que en caso de error se podría recuperar una copia previamente exportada.
b) El diario de transacciones o cuaderno de bitácora: guarda registro de todas las operaciones
de modificación de datos realizadas contra la base de datos. A medida que se van eje-
cutando sentencias que modifican el contenido de la base de datos, se guarda registro
en el diario de transacciones, y cuando se ejecuta una sentencia commit, se marcan
como confirmadas todas las sentencias de esa transacción. En caso de que se ejecute un
rollback, se eliminan las sentencias del diario. Regularmente se insertan en el diario
unos puntos de control, de forma que en caso de que se produjese un fallo en el sistema
gestor que provocase una pérdida de información, esta se podría recuperar partiendo
Capítulo 4
Seguridad 133
del último punto de control registrado en nuestra copia de seguridad y ejecutando

todas las operaciones confirmadas en el diario de transacciones a partir de ese punto.
La gestión de las copias de seguridad englobará, por tanto, tres tareas:
1. Backup: guardar una copia de los ficheros de la base de datos en un medio de almace-
namiento externo.
2. Restore: recuperación de los datos de la base de datos a partir de los ficheros del sistema
de almacenamiento externo.
3. Recovery: para recuperar el estado anterior a un fallo no solo es necesario recuperar
la última copia disponible sino que también será necesario recuperar la información
almacenada en los ficheros del cuaderno de bitácora y ejecutar de nuevo todas las ins-
trucciones que hicieron modificaciones en los datos tras la última copia de seguridad.
En caso de un fallo general del sistema gestor que provocase una pérdida de información, el
procedimiento que se habría de seguir para recuperarla consistiría en restaurar en primer lugar la
última copia de seguridad disponible, y utilizar el diario de transacciones para recuperar y volver
a ejecutar todas las operaciones llevadas a cabo desde la realización de esa copia de seguridad.
Las tareas del administrador de la base de datos en relación con la recuperación de infor-
mación serán:
● Definir las políticas de copia de seguridad, que normalmente combinan la realización de

copias completas y parciales y la configuración de los archivos del cuaderno de bitácora.
● Definir el procedimiento de recuperación de los datos de la base de datos en caso de
fallo. Es necesario que exista un procedimiento que permita recuperar los datos rápida-
mente, pues de lo contrario el impacto del fallo sería considerable.
● Planificar y gestionar la realización de simulacros de recuperación.
4.4.4. Tipos de copias de seguridad

Existen varias formas de clasificar las copias de seguridad en base a distintos aspectos:
a) Totales o parciales: una copia total de la base de datos incluye todos sus objetos, archivos
de datos, de control, cuaderno de bitácora, ficheros de configuración, etc. Una copia
parcial permite especificar los objetos o ficheros concretos que se quieren incluir en la
copia, y no está sincronizada con la base de datos (es una copia puntual de una parte de
la base de datos, que se suele usar para trasladar datos a otro sistema gestor).
b) Lógicas o físicas: una copia de seguridad lógica permite guardar objetos de la base de
datos (tablas, índices, etc.), mientras que una copia física almacena componentes físicos:
tablespaces, archivos de datos o bloques. Tanto una como otra permiten guardar copias
de la base de datos completa, solo que uno guardará objetos lógicos y otro guardará los
bloques físicos de esa base de datos.
c) Completos o incrementales: un backup completo de una base de datos contiene una copia
de la base de datos o de una parte de esta en un momento concreto. El backup incre-
mental permite almacenar únicamente los cambios que se han producido o que se han
añadido después de un backup completo. Este tipo de copias ocupan mucho menos
Capítulo 4
tamaño y son significativamente más rápidas, pero, para restaurar una base de datos de la
que se hayan realizado copias incrementales, es necesario restaurar en primer lugar
la última copia completa que se haya realizado, y a continuación todas las copias incre-
mentales realizadas desde entonces, por lo que el proceso de restauración es más lento.
Normalmente las copias incrementales solo se pueden realizar cuando se trabaja
con copias físicas.
d) Online u offline: una copia offline es la que se hace cuando la base de datos está cerrada,
mientras que la copia online se puede realizar mientras la base de datos está trabajando.
Las copias offline permiten realizar copias consistentes de la base de datos (que incluyen
todos los cambios que se han realizado hasta ese momento en la base de datos). Aunque el
proceso de recuperación es más sencillo cuando la copia de seguridad es consistente, tiene
la desventaja de que hay que parar y cerrar la base de datos para realizarla, lo que no es
posible en sistemas 24 x 7, por lo que en estos casos es necesario implementar algún pro-
ceso de copia más complejo que permita realizar los backups en caliente (online), como
la copia en espejo (mirroring) o los BCV (que permiten realizar una copia de la base
de datos que puede ser actualizada sencuencialmente por medio de la replicación de las
operaciones registradas en el cuaderno de bitácora), o realizar copias de seguridad incon-
sistentes que incluyan toda la información registrada en el cuaderno de bitácora.
4.5. Integridad en Oracle

Veremos, a continuación, las opciones que provee el sistema gestor Oracle para llevar a cabo
estas funcionalidades.
4.5.1. Restricciones
Las restricciones en Oracle se definen cuando se crea la tabla, y se pueden modificar por medio
de un alter table. Pueden ser de varios tipos:
Cuadro 4.2
Restricciones habituales en Oracle
NOT NULL La columna no permitirá valores nulos.
DEFAULT [valor] La columna tendrá un valor por defecto. El SBGD utiliza este valor cuando no se
especifica un valor para dicha columna al insertar una fila nueva.
PRIMARY KEY Permite indicar que esta columna o columnas constituyen la clave primaria.
FOREIGN KEY Es la manera de indicar que este campo es una clave foránea (foreign key)
y hace referencia a la clave primaria de otra tabla.
UNIQUE Obliga a que los valores de una o varias columnas tomen valores únicos (no puede
haber dos filas con igual valor en esos campos). Internamente se implementa
creando un índice para dicha(s) columna(s) que no puede tomar valores repetidos.
CHECK Permite indicar una condición que debe de cumplir esa columna. Se suele
(condición) utilizar para restringir los posibles valores que se pueden asignar a una variable.
Capítulo 4
Seguridad 135
Oracle permite habilitar y deshabilitar las restricciones (constraints) de manera individual

haciendo un alter de la tabla:
ALTER TABLE <tabla> {ENABLE | DISABLE} <constraint>;
Las restricciones definidas sobre cada tabla se pueden consultar por medio de la vista DBA_
CONSTRAINTS (o sus vistas user_ y all_ correspondientes).
4.5.2. Control de concurrencia

El sistema de control de concurrencia de Oracle utiliza un bloqueo en dos fases: comienza blo-
queando siempre lo mínimo posible (una fila, por ejemplo), y si es necesario modificar más filas
de la misma tabla, extiende el bloqueo a nivel de bloque, de datafile, de tabla, etc. De esta manera
se consigue minimizar las esperas que se producen al ejecutar las transacciones y se optimiza al
máximo el paralelismo del sistema.
Oracle provee automáticamente de una consistencia de lectura que impide que se produz-
can lecturas sucias. En lugar de los cuatro niveles de aislamiento que propone ANSI, Oracle
solamente implementa tres:
● Read committed (lectura confirmada), que es el nivel de aislamiento por defecto.

● Serializable.
● Read only: con este nivel de aislamiento las transacciones solo ven los datos confirma-
dos antes de empezar la transacción y no pueden realizar modificaciones sobre los datos.
El nivel de aislamiento se puede modificar para una transacción concreta o para una sesión,
modificando el parámetro de configuración “isolation_level”:
SET TRANSACTION ISOLATION LEVEL {SERIALIZABLE | READ COMMITTED | READ ONLY};

ALTER SESSION SET ISOLATION_LEVEL {SERIALIZABLE | READ COMMITTED | READ ONLY};
¿Sabías que...?
Oracle utiliza grafos de esperas para detectar interbloqueos entre transacciones y cuando de-
tecta un interbloqueo aborta la transacción que más tarde se inició.
4.5.3. Copias de seguridad

Oracle dispone de tres herramientas para realizar copias de seguridad:
– Export/import (exp/imp): permite hacer copias lógicas que se guardarán en el equipo

cliente desde el que se ejecuta la copia.
Capítulo 4
– Datapump (expdp/impdp): permite hacer copias lógicas que solamente se pueden

guardar en el servidor.
– RMAN: permite hacer copias físicas e incrementales, que solo se pueden guardar en el
servidor.
Tanto el EM como el SQL Developer permiten también hacer copias de seguridad em-
pleando una interfaz gráfica, pero lo que hacen internamente es emplear una de las herra-
mientas anteriores para realizar la copia.
Figura 4.10
Herramientas de copia de seguridad en Oracle.
A) Export/import
Los comandos exp e imp son las herramientas proporcionadas por Oracle desde sus prime-
ras versiones para la realización de backups lógicos de la base de datos. Permiten realizar copias
totales o parciales, completas y offline u online, aunque si se hace de manera online la tabla se
bloquea mientras dura la exportación.
Para crear el fichero de backup se utiliza el comando exp y para importar el contenido y
restaurar la base de datos se utiliza el comando imp.
Este tipo de backup se utiliza habitualmente en los siguientes casos:
● Para hacer copias en un equipo local (si un usuario no tiene acceso al servidor, esta será
la única opción que podrá emplear para hacer una copia de sus datos).
● Para realizar copias de bases de datos pequeñas.
● Para corregir problemas de fragmentación como “Row Migration” y “Row Chaining”
(veremos en el capítulo 6 en qué consisten).
● Para “migrar” una base de datos a otro servidor.
Estos comandos se utilizan desde el interfaz de comandos del sistema operativo, y aceptan
varios parámetros: las tablas a importar/exportar, el esquema origen, el esquema destino, las
condiciones que deben cumplir las filas exportadas… Con la opción “-help” se pueden consul-
tar todos los parámetros existentes tanto para exportar como para importar:
exp -help
imp -help
Capítulo 4
Seguridad 137
Ejemplo
exp ventas/12345@pdborcl file=c:\temp\ventas.dmp tables=ventas,clientes,productos

exp ventas/12345@pdborcl file= c:\temp\ventas.dmp tables=ventas query=\”where idcliente=10\”
exp ventas/12345@pdborcl file=c:\temp\ventas.dmp full=yes log=c:\temp\ventas.log
buffer=1000000
imp ventas2/12345@pdborcl file=c:\temp\ventas.dmp tables=productos fromuser=ventas
touser=ventas2
imp ventas/12345@pdborcl file=ventas.dmp full=yes ignore=yes log= c:\temp\ventas.log
buffer=1000000
Accede al recurso digital Copias de seguridad exp, con el que podrás practicar la realización
y restauración de diversas copias de seguridad empleando las herramientas exp e imp.
B) Data Pump

Oracle Data Pump es una herramienta incorporada a partir de la versión 10g de Oracle, que
permite una transferencia más rápida de datos y metadatos entre bases de datos Oracle. Provee
dos herramientas de exportación e importación en paralelo: expdp e impdp, e incorpora además
de una interface web a través del EM para realizar estas operaciones.
Al igual que imp y exp, permite crear copias de la base de datos totales o parciales, comple-
tas, lógicas y online u offline.
La principal ventaja de datapump es el incremento de rendimiento que supone con respec-
to al export/import tradicional. Export e import se lanzan como procesos que van exportando
o importando las tablas una a una, lo que en bases de datos con gran cantidad de información
puede tardar mucho tiempo. Dado que las tablas pueden estar almacenadas en distintos ficheros
e incluso en distintos discos, ¿por qué no paralelizar el backup? Eso es precisamente lo que
permite hacer datapump: lanzar varios hilos (tantos como se le indiquen) para hacer el backup
en paralelo.
Además, los jobs de Data Pump se pueden reiniciar sin pérdida de datos, permiten un grano
más fino de selección de objetos (virtualmente, cualquier tipo de objeto puede ser incluido o
excluido de un job Data Pump), permiten filtrar los metadatos incluidos en la copia en función
del tipo de objeto que se copia y permiten generar backups encriptados de los datos.
Su principal desventaja es que mientras export e import permiten copiar los datos en el
equipo del cliente, los datos exportados con Data Pump deben almacenarse siempre en un di-
rectorio del servidor. Esto limita la posibilidad de uso de Data Pump por parte de los usuarios,
ya que no todos los usuarios tendrán acceso a carpetas del servidor donde poder realizar el
volcado de los datos.
Data Pump puede ser invocado desde la línea de comandos con los programas expdp e im-
pdp, o a través del paquete PL/SQL DBMS_DATAPUMP. También se pueden hacer exports
Data Pump a través del EM.
Capítulo 4
Ejemplo
– Registramos en primer lugar el directorio del servidor en Oracle

SQL> create or replace directory dumpdir as ‘g:\oracle\dumpdir’;
– Concedemos permisos para leer (impdp) y escribir (expdp) en dicho directorio
SQL>grant read,write on directory dumpdir to administrador;
– Desde el interfaz de comandos, ejecutamos las copias
expdp administrador/12345@pdborcl directory=dumpdir dumpfile=fichero.dmp
– Con un archivo de parámetros
expdp parfile=dumpdir:parametros.txt
– Copia encriptada con password
expdp administrador/12345@pdborcl directory=dumpdir dumpfile=fichero.dmp log-
file=fichero.log encryption=all encryption_mode=password encryption_password=”clave
segura” encryption_algorithm=aes256
– Copia encriptada con encriptación transparente
expdp administrador/12345@pdborcl directory=dumpdir dumpfile= fichero.dmp
logfile= fichero.log encryption=all encryption_mode=transparent encryption_algori-
thm=aes256
– Para importar el archivo generado
impdp administrador/12345@pdborcl directory=dumpdir dumpfile=fichero.dmp
– Con archivo de parámetros
impdp parfile=dumpdir:parametros.txt
– Encriptación con password (se debe indicar el password para poder realizar la importación)
impdp administrador/12345@pdborcl directory=dumpdir dumpfile=fichero.dmp log-
file=fichero.log encryption_password=”clave segura”
– Encriptación transparente
impdp administrador/12345@pdborcl directory=dumpdir dumpfile=fichero.dmp log-
file=fichero.log
– Usando el paquete DBMS_DATAPUMP
declare
handle number;
begin
handle:= dbms_datapump.open(‘EXPORT’,’SCHEMA’);
dbms_datapump.add_file(handle,’VENTAS.DMP’,’DUMPDIR’);
dbms_datapump.metadata_filter(handle,’SCHEMA_EXPR’,’=’’VENTAS’’);
dbms_datapump.set_parallel(handle,4);
dbms_datapump.start_job(handle);
dbms_datapump.detach(handle);
end;
/
Capítulo 4
Seguridad 139
Accede al recurso digital Copias de seguridad datapump. En él se muestran diversos ejemplos

de uso de datapump tanto para realizar paso a paso copias de seguridad como para recuperarlas.
C) RMAN
RMAN (Oracle Recovey Manager) es una herramienta de copia de seguridad a nivel físi-
co que permite realizar backups incrementales solo de los bloques de datos que han cambiado
desde la última copia realizada. RMAN permite realizar copias incrementales de bases de datos
completas, tablespaces o datafiles.
Lo que distingue a RMAN de cualquier otro método es que los respaldos son a nivel de
bloque de datos, a diferencia de los respaldos gestionados por el usuario, y esto trae grandes
ventajas, ya que no requiere respaldar bloques vacíos, elimina la corrupción en los respaldos y
permite maximizar la compresión al hacerlo.
Además, esta copia se puede hacer de forma online, por lo que permite mantener un servi-
dor de backup que se actualiza periódicamente a partir del servidor principal y en caso de fallo
podría restablecerse rápidamente el servicio pasando a trabajar sobre el servidor de respaldo
(recuperando previamente todas las operaciones de los archivos de redo del servidor principal
que se hubiesen realizado desde la última sincronización).
Cuando se utiliza RMAN para realizar réplicas, lo que hace es leer todas las operaciones
almacenadas en los ficheros de REDO LOG (el cuaderno de bitácora) y enviarlas a la copia de
respaldo para ejecutarlas allí. Los archivos de redo log tienen el problema de que son cíclicos, y
cuando se llenan los tres se borra el contenido del primero y se reescribe sobre él. Para evitar este
problema, RMAN obliga a tener la base de datos en modo ARCHIVE LOG, de modo que antes
de reescribir un fichero de redo log, se hace una copia del mismo y se almacena, lo que garanti-
za que no se pierda la información que RMAN necesita para recuperar una copia incremental.
Existen dos paquetes en el diccionario de datos (en el esquema SYS) que permiten trabajar
directamente con RMAN desde el intérprete de SQL:
● DBMS_RCVMAN, mantiene un registro de los componentes de la base de datos: co-
pias de la base de datos, la lista de los respaldos, etc.
● DBMS_BACKUP_RESTORE, el que se encarga de realizar las operaciones de res-
paldo y recuperación (crear el snapshot del archivo de control, respaldar los datafiles,
backups del spfile, etc.).
Pero lo más habitual es utilizar la herramienta RMAN que se instala junto con el sistema
gestor y ejecutar en ella los comandos que sean necesarios.
Así como exp y datapump son bastante similares a la hora de realizar las copias de seguridad,
RMAN es completamente diferente. Accede al recurso digital Copias de seguridad RMAN,
en él se plantean varias de las distintas opciones existentes para realizar paso a paso copias de
seguridad y restauraciones de datos empleando RMAN.
Capítulo 4
4.6. La normativa de protección de datos
El DBA es el responsable de gestionar los datos almacenados, lo que además de realizar las co-
pias de seguridad para garantizar la recuperación del sistema, incluye asegurar que los accesos
a dichos datos cumplen los requisitos especificados en la normativa vigente, que viene dada
principalmente por:
1. Reglamento (UE) 2016/679 del Parlamento Europeo, de 27 de abril de 2016, relativo

al tratamiento de datos personales y a la libre circulación de estos datos.
2. Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía
de los derechos digitales.
4.6.1. La LOPD
La LOPD (Ley Orgánica de Protección de Datos de Carácter Personal) regula el proceso de
recopilación, tratamiento y almacenamiento de la los datos de carácter personal por parte de las
organizaciones. Un dato de carácter personal es cualquier información que permite identificar
a una persona o hacerla fácilmente identificable.
La ley determina que los datos personales están sometidos a cuatro derechos por parte de
sus propietarios (los derechos ARCO):
● Acceso: permite al ciudadano conocer y obtener gratuitamente información sobre sus

datos de carácter personal sometidos a tratamiento.
● Rectificación: permite corregir errores, modificar los datos que resulten ser inexactos o
incompletos y garantizar la certeza de la información objeto de tratamiento.
● Cancelación: permite que se supriman los datos que resulten ser inadecuados o excesivos
sin perjuicio del deber de bloqueo recogido en la LOPD.
● Oposición: es el derecho del afectado a que no se lleve a cabo el tratamiento de sus datos
de carácter personal o se cese en el mismo.
Antes de proceder a la recolección de ningún tipo de información de carácter personal, es

necesario catalogar todos los datos personales que se tratarán y clasificarlos en función de su
contenido en tres niveles de seguridad. Las medidas de seguridad que se han de aplicar sobre el
fichero dependerán del nivel del fichero:
a) Nivel básico: todos los ficheros que traten datos de carácter personal deberán adoptar
las medidas de nivel básico. Las medidas a aplicar incluyen: gestión de los accesos por
parte de los usuarios, realizar copias de seguridad y custodiar los soportes de almace-
namiento.
b) Nivel medio: deberá aplicarse en ficheros que contengan datos referentes a infracciones
cometidas, tributos, seguridad social o que contengan características de los ciudadanos
que permitan evaluar aspectos de su personalidad. A estos ficheros se le deben aplicar las
medidas del nivel básico y además: identificar responsables de seguridad, registro físico
de acceso a los sistemas de información, registrar entrada y salida de soportes, elaborar
auditorías periódicamente y asegurar la destrucción de los soportes de información
cuando sean desechados.
Capítulo 4
Seguridad 141
c) Nivel alto: deberá aplicarse a los ficheros con información referente a ideología, afilia-
ción sindical, religión, creencias, origen racial, salud o vida sexual, o los que contengan
datos policiales recabados sin consentimiento de las personas afectadas. Estos datos de-
ben almacenarse en soportes cifrados y protegidos con llave, se deben conservar copias
en emplazamientos físicos diferentes al del servidor donde se alojan, se deben auditar
todos los accesos a los datos, y cualquier transferencia de información debe ser por me-
dio de una conexión cifrada. El no cumplimiento de las normas especificadas para los
ficheros de seguridad alta conllevan multas de entre 300 y 600 000 euros.
Recuerda
3 Cada organización que trate con datos de carácter personal debe disponer obligato-
riamente de un documento de seguridad, que debe mantenerse siempre actualizado. El
contenido mínimo que debe tener el Documento de Seguridad es el siguiente:
– ámbito de aplicación: con especificación detallada de los recursos protegidos;

– medidas, normas, procedimientos, reglas y estándares de seguridad, funciones y
obligaciones del personal;
– estructura y descripción de los ficheros y sistemas de información;
– procedimiento de notificación, gestión y respuesta ante incidencias;
– procedimiento de copias de respaldo y recuperación de datos;
– medidas adoptadas en el transporte, destrucción y/o reutilización de soportes y
documentos.
3 Además de este documento de seguridad, cada organización debe notificar a la Agen-

cia Española de Protección de Datos la información referente a los ficheros de carácter
personal que maneja y su contenido para su inscripción en el Registro General de Protec-
ción de Datos (RGPD).
4.6.2. El papel del sistema gestor en la LOPD

Existen varias funciones del sistema gestor que serán básicas a la hora de cumplir con la LOPD:
● La gestión de usuarios y permisos garantizará que los usuarios únicamente accedan a los
datos sobre los que tienen permiso, y que únicamente puedan realizar las operaciones
que les están permitidas sobre esos datos.
● Los sistemas de recuperación permitirán realizar copias periódicas de la información
para mantenerla a salvo.
● Las restricciones de integridad de la base de datos garantizan la corrección de los datos
almacenados.
● La encriptación de los datos y de las comunicaciones garantizará que los usuarios no
puedan acceder a información no autorizada.
● La auditoría permite registrar todos los accesos realizados a los datos, con lo que se
podrá almacenar tanto los accesos realizados (con información detallada de fecha y
Capítulo 4
hora de acceso, equipo desde el que se accede, IP, sistema operativo, etc.), como las ope-
raciones realizadas sobre esos datos. Esta información se almacena en un esquema del
sistema, por lo que es necesario tener controlados los campos sobre los que se aplican y
pasar a histórico esta información periódicamente.
Resumen
n Las primeras tareas que debe llevar a cabo el DBA tras la instalación y configu-
ración del sistema gestor están destinadas a garantizar la seguridad del sistema:
asegurar la confidencialidad de la información y la integridad de la información
almacenada.
n Las medidas que se pueden llevar a cabo para garantizar la seguridad del sistema
gestor pueden ser activas (medidas proactivas que tratan de evitar que se produzcan
accesos inadecuados o inconsistencias en la información) o pasivas (medidas reacti-
vas cuyo objetivo es detectar los errores producidos para solucionarlos).
n La confidencialidad se garantizará por medio de la gestión de usuarios y permi-
sos, la definición de esquemas externos, la encriptación de los datos almacenados
y la auditoría de los accesos y operaciones realizadas en el sistema por parte de los
usuarios.
n El objetivo de la encriptación es cifrar la información almacenada, y se puede llevar
a cabo por medio de funciones (encriptar y desencriptar para poder recuperar la
información o hash y mac para impedir que la información pueda ser descifrada) o
por medio de la encriptación transparente (el sistema gestor se encarga automática-
mente de cifrar la información al insertarla y de descifrarla al recuperarla).
n La auditoría tiene por objetivo detectar accesos u operaciones inadecuadas. Se pue-
den auditar tanto las operaciones realizadas en el sistema gestor como las operaciones
realizadas sobre objetos concretos de las bases de datos.
n El sistema gestor dispone de herramientas cuyo objetivo es garantizar la integridad de
la información, como la definición de restricciones que evitan la aparición de datos
incongruentes, el control de concurrencia para evitar el solapamiento de las operacio-
nes realizadas por diversas transacciones y la realización de copias de seguridad que
permitan restaurar la información en caso de fallo del sistema.
n Las restricciones se definen al crear las tablas (claves primarias y foráneas, nulidad,
check y unicidad). El DBA podrá habilitarlas o deshabilitarlas para realizar tareas con-
cretas.
n El control de concurrencia garantizará que las transacciones se ejecuten en el orden
correcto y sin interferir entre ellas. El gestor de concurrencia utiliza bloqueos para
aislar las transacciones. Para buscar un equilibrio entre capacidad de paralelismo del
sistema y posibles errores que se puedan asumir debidos a la interacción entre tran-
sacciones se pueden definir distintos niveles de aislamiento, que se diferenciarán en
el modo en que apliquen los bloqueos sobre los recursos. El DBA deberá definir el
nivel de aislamiento, optimizar la distribución de datos en los discos y monitorizar
interbloqueos.
Capítulo 4
Seguridad 143
n La función de respaldo y recuperación engloba las operaciones de backup (hacer las

copias de seguridad), restore (restaurar las copias) y recovery (recuperar las últimas
modificaciones realizadas tras la copia a partir del cuaderno de bitácora). Las copias
pueden ser totales o parciales, físicas o lógicas, completas o incrementales y online u
offline. El DBA deberá definir las políticas de copia, los procedimientos de respaldo y
recuperación y planificar la realización de simulacros.
n La LOPD establece las medidas de seguridad que se deben garantizar a la hora tratar
y almacenar datos personales. El sistema gestor de base de datos provee de diversas
herramientas que permiten implementar estas medidas de seguridad.
Crea un usuario “nominas” y asígnale los permisos necesarios para iniciar sesión, crear
tablas y usar las funciones de encriptación y la auditoría:
SQL> CREATE USER nominas IDENTIFIED BY “12345”;

SQL> GRANT create session, create table, audit system, audit any TO
nominas;
-- Estos permisos se deben asignar con el usuario SYS en la PDB
SQL> CONN sys@pdborcl as sysdba
SQL> GRANT execute ON DBMS_CRYPTO TO nominas;
SQL> GRANT execute ON DBMS_FGA TO nominas;
SQL> CONN nominas/12345@pdborcl;
1. Habilita la encriptación transparente y crea un tablespace llamado “tb_cifrado” que

almacene la información encriptada por medio del algoritmo AES de 256 bits. Asigna
dicho tablespace como tablespace por defecto para el usuario “nominas” y asígnale
una cuota ilimitada para que pueda escribir en él. Comprueba en la vista dba_tablespa-
ces cuales de los siguientes campos serán diferentes entre un tablespace sin encriptar
y uno encriptado: "DEF_INMEMORY_COMPRESSION", "ENCRYPTED", "PREDICATE_
EVALUATION", "SEGMENT_SPACE_MANAGEMENT", "TABLESPACE_NAME".
2. Conéctate al sqlplus con el usuario “nominas” y ejecuta el script Esquema_nominas.

sql (disponible en la sección de recursos digitales), para crear en el esquema “no-
minas” todas sus tablas. Para ejecutar un script con el sqlplus, indicamos la ruta del
fichero precedida por una arroba (@):
SQL> @”c:\temp\REC04.01-Esquema_nominas.sql”
Capítulo 4
Una vez creadas las tablas, modifica por medio de un UPDATE el campo “sala-
rio_base” de la tabla personal para almacenar en él el resultado de encriptar el campo
“sueldo_base” usando el algoritmo AES 128 con la clave: ‘12345’. Ten en cuenta
que el algoritmo AES 128 emplea una clave de longitud 16 en lugar de los 32 bytes que
usa AES 256.
Una vez ejecutado el update, el campo "sueldo_base" ya no sería necesario, por
lo que habría que eliminarlo de la tabla.
3. Para que los empleados puedan acceder a las aplicaciones de la empresa, asignare-
mos a cada empleado una clave personal que permita verificar su identidad. Dicha
clave se calculará aplicando al DNI del empleado una función hash con el algoritmo
SHA2 de 512 bits y la clave “12345”. El resultado lo almacenaremos en el campo
“clave” de la tabla PERSONAL.
4. Si auditamos las operaciones de select e insert sobre una tabla llamada TEMP y ejecu-
tamos un inserta as select en esa tabla (insert into TEMP select * from TEMP;), ¿cuántas
entradas se registrarán en el log de auditoría?
5. ¿Sucede lo mismo si habilitamos la auditoría de grado fino sobre un campo de esa
tabla para las operaciones de select e insert y ejecutamos de nuevo un insert as select?
6. Realiza las siguientes operaciones:
a) Audita todos los inicios de sesión del usuario “nominas”.

b) Audita todos los inicios de sesión de todos los usuarios.
c) Elimina la auditoría de inicio de sesión de todos los usuarios.
¿Se seguirán registrando los inicios de sesión del usuario “nominas”?
7. Revisa los parámetros que permite usar “exp” e indica el comando que ejecutarías para
exportar las tablas PERSONAL y SEDE del usuario “nominas” sin datos (solo la estructu-
ra) en el fichero c:/app/oracle/salida.dmp. ¿Qué ocurre al ejecutar el comando?
8. Revisa los parámetros que permite usar “expdp” e cuales tendrías que indicar en
un fichero de configuración de datapump para realizar el mismo export anterior
pero usando la encriptación transparente, guardando la información en el fichero
“nominas_dpump.dmp” ubicado en el directorio “dumpdir” y usando 4 hilos de
ejecución.
9. ¿Qué sentencia tendrías que ejecutar con RMAN para exportar el tablespace “TB_CI-
FRADO “?
10. ¿Qué sentencias tendrías que ejecutar para recuperar ese mismo tablespace y dejarlo
accesible si se hubiese eliminado por error?
Capítulo 4
Seguridad 145
1. ¿Cuál de las siguientes no es una política activa de seguridad?
a) Gestión de usuarios y permisos.
b) La definición de restricciones.
c) La gestión de transacciones.
d) La auditoría de los inicios de sesión.
2. ¿Cuál de las siguientes tareas no está encaminada a garantizar la integridad de las

bases de datos?
a) La definición de restricciones.
b) La encriptación de datos
c) La realización de copias de seguridad.
d) El control de concurrencia.
3. ¿Qué tipo de encriptación utilizarías para guardar el salario de tu tabla de empleados?

a) Cifrado transparente.
b) Por medio de las funciones de encriptar/desencriptar.
c) Por medio de una función hash.
4. ¿Qué función permite encriptar los datos pasando una clave, sin que se puedan desen
criptar?
a) ENCRYPT.
b) DECRYPT.
c) HASH.
d) MAC.
5. ¿Qué sucede si se produce un interbloqueo entre dos sesiones?

a) La primera sesión que cogió el bloqueo se queda bloqueada.
b) La segunda sesión que cogió el bloqueo se queda bloqueada.
c) Las dos sesiones quedan bloqueadas pero no afectan al resto.
d) Las dos sesiones quedan bloqueadas y afectan al resto.
6. ¿Cómo podemos disminuir el número de bloqueos que se producen en el sistema gestor?

a) Matando sesiones de usuario aleatoriamente.
b) Optimizando la forma de almacenar los datos en las tablas.
c) Limitando los recursos disponibles para el sistema gestor.
d) Desfragmentando el disco frecuentemente.
7. En caso de fallo en el sistema gestor, ¿qué debo restaurar primero, la copia de seguri-
dad o el cuaderno de bitácora?
a) La copia de seguridad.
b) El cuaderno de bitácora.
c) Ambas simultáneamente.
d) Depende de en qué momento falle.
Capítulo 4
8. ¿Cuál de las siguientes no es una tarea relacionada con la gestión de copias de segu-
ridad?
a) Backup.
b) Restore.
c) Recovery.
d) Refresh.
9. ¿Con qué tipo de copia de seguridad puedo copiar una sola tabla?
a) Totales.
b) Lógicas.
c) Físicas.
d) Incrementales.
10. ¿Qué no me aporta un SGBD con respecto a la LOPD?

a) Registra los accesos a los datos.
b) Garantiza la corrección de los datos almacenados.
c) Restringe el acceso a los datos solo a usuarios autorizados.
SOLUCIONES:
a b c
1. d 5.
a b c d
a b c
2. a b c d 9.
d 6. a b c d
a b c
3. a b c d 10.
d 7. a b c d
4.
a b c d 8.
a b c d
Capítulo 4
5
Monitorización
y optimización
Objetivos
3 Comprender los beneficios de monitorizar el funcionamiento del sistema
gestor.
3 Conocer los mecanismos existentes para detectar posibles errores o inefi-
ciencias que puedan provocar un deterioro en el rendimiento del sistema
gestor.
3 Interpretar adecuadamente los planes de ejecución de las consulta.
3 Disponer de herramientas que permitan detectar ineficiencias en una con-
sulta y llevar a cabo las acciones necesarias para optimizarla.
3 Adquirir soltura en la utilización del diccionario de datos para realizar todo
tipo de tareas de monitorización y optimización del sistema gestor.
Mapa conceptual
Monitorización Monitor de rendimiento
Registro de errores
Optimización Diccionario de datos
Plan de ejecución
Herramientas específicas
realiza Funciones
Puesta en marcha
Seguridad
Explotación Monitorización
Optimización
Entorno
Sistema gestor
Base de datos
Consultas
Administración
Capítulo 5
Monitorización y optimización 149
Glosario
Caché de consultas. Almacén temporal de los planes de ejecución óptimos de cada una
de las consultas más ejecutadas en el sistema gestor.
Data warehouse. Almacén de datos, repositorio de información corporativa destinado a
tareas de inteligencia de negocio como la elaboración de informes y la realización de
análisis de datos.
Fragmentación. Aparición de espacios no utilizados en los soportes de almacenamiento
de la información debidos a la operativa diaria de inserción, modificación y elimi-
nación de datos, que provocan una ocupación de espacio innecesaria y hacen más
ineficientes las búsquedas de información.
Índice balanceado. Un índice con estructura de árbol se dice que está balanceado si en
todos los niveles del árbol sus nodos tienen un número de hijos similar.
Log. Grabación secuencial en un fichero o base de datos de los eventos registrados en un
sistema.
Optimizador. Componente del sistema gestor encargado de calcular el coste de ejecución
estimado de cada posible plan de ejecución existente para una consulta y seleccionar
el de menor coste (plan de ejecución óptimo).
Plan de ejecución. Camino que seguirá el sistema gestor para acceder a los datos resulta-
do de una consulta.
Tabla particionada. Una tabla particionada está dividida en segmentos que el sistema ges-
tor trata lógicamente como objetos de base de datos individuales, por lo que permite
operar con cada uno de ellos por separado.
5.1. Introducción
Una vez que se ha instalado y configurado el SGBD, y se ha garantizado el acceso a los usuarios ga-
rantizando todas las medidas de seguridad necesarias, comenzaría la fase de explotación del sistema.
En esta fase, las tareas más habituales del administrador de base de datos serán:
● Arrancar y parar el sistema gestor.

● Monitorizar el sistema para asegurar la disponibilidad de los datos.
● Hacer copias de seguridad periódicas de los datos y mantenerlas a salvo de la destruc-
ción accidental o intencional
● Optimizar el SGBD, los objetos de base de datos y las consultas más habituales.
Este capítulo se centrará en las tareas destinadas a garantizar el acceso óptimo a la informa-
ción por parte de los usuarios: la monitorización y la optimización.
5.2. Monitorización
Aunque no es posible ni recomendable monitorizar el uso del sistema gestor constantemente,
sí es preciso hacerlo regularmente y de la forma más automatizada posible. Los sistemas gestores
de bases de datos cuentan con herramientas que ayudan en la tarea de monitorizar el sistema.
Capítulo 5
Toma nota
En general, se debe tratar de que las tareas de monitorización y diagnóstico

del sistema sean lo menos intrusivas posible para que no penalicen el rendi-
miento del sistema gestor, y relegar las tareas que requieran un consumo de
recursos medio o elevado para realizarlas en momentos de baja carga.
Normalmente las tareas de monitorización se llevan a cabo por medio de tres herramientas:
a) El monitor de rendimiento: el monitor del rendimiento del servidor permite consultar el

uso que el sistema hace de los recursos (CPU, memoria, red, disco…), y prevenir posi-
bles problemas en el sistema.
b) El log de ejecución: el log del sistema (no confundir con el cuaderno de bitácora) registra
las trazas, logs y alertas que se producen en el sistema gestor.
c) El diccionario de datos: normalmente en el diccionario de datos se guarda también in-
formación de la actividad del sistema, por lo que es posible consultar determinada
información por medio de consultas realizadas sobre las tablas del diccionario de datos.
El monitor de rendimiento realmente lo que hace es leer la información del diccio-
nario de datos y mostrarla de forma gráfica de modo que sea fácilmente interpretable.
5.2.1. Monitor de rendimiento

Algunas de las posibilidades que ofrece el monitor de rendimiento son:
a) Seguimiento de métricas: para evaluar el correcto funcionamiento del sistema es conve-

niente definir una serie de métricas que puedan ser utilizadas para realizar un segui-
miento de su rendimiento. Entre las métricas que se pueden utilizar:
● Transacciones por unidad de tiempo: especialmente útil para aplicaciones interactivas de

múltiples usuarios.
● Tiempo de respuesta: tiempo mínimo y promedio requerido por una tarea o conjun-
to de tareas.
● Escalabilidad: respuesta del sistema ante situaciones de carga variable (para compro-
bar si se degrada mucho el rendimiento en los picos de carga)

● Concurrencia: número de solicitudes por segundo que generan en el servidor los
usuarios en el momento de máxima actividad.
b) Detección de bloqueos: de forma general podríamos decir que cuando un usuario co-
mienza una operación de modificación de datos sobre una tabla, esta se bloquea, y
cualquier petición de modificación de otro usuario quedaría bloqueada en espera de la
finalización de esta modificación, pudiendo dar lugar a interbloqueos u otras situacio-
nes indeseadas. Por medio de la monitorización del SGBD es posible comprobar si se
están produciendo bloqueos en un momento dado o incluso consultar si se producen
habitualmente para tratar de evitarlos (algunos bloqueos pueden evitarse particionando
la tabla, dividiendo su contenido en varios ficheros, modificando el espacio libre en los
bloques de índices o modificando parámetros del sistema gestor).
Capítulo 5
c) Detección de procesos que acaparen recursos: en caso de que un proceso acapare recursos (de
disco, CPU, etc.) penalizando el rendimiento general del sistema, es posible detectar esta
situación y en caso de que pueda comprometer el correcto funcionamiento del sistema
incluso se puede finalizar ese proceso.
d) Consumo de recursos: otra de las posibilidades que ofrece el monitor de rendimiento es
comprobar el consumo de recursos producido al lanzar una consulta, por lo que de cara
a la optimización de consultas es muy útil para comprobar el impacto de una reescritura
de la consulta, un cambio en el optimizador, el impacto de la creación de un índice, etc.
e) Definición de alertas o umbrales: las alertas o umbrales permiten activar avisos cuando se
cumpla una condición (si nos quedemos sin espacio en disco, por ejemplo).
5.2.2. Registro de errores

Hasta ahora, cuando hablábamos de logs del sistema gestor lo hacíamos en relación con el cua-
derno de bitácora (log binario o redo log), un fichero donde se guardan todas las sentencias que
alteran el contenido de las bases de datos.
Sin embargo, el sistema gestor guarda también otro tipo de ficheros de log o trazas del
sistema donde se registra toda la actividad relevante relacionada con el propio funcionamiento
del servidor:
● Inicios y paradas del servidor.
● Operaciones relevantes llevadas a cabo.
● Errores o warnings (avisos) generados por el servidor.
● Registro de consultas que tardan mucho en resolverse.
En caso de que se produzca algún error durante la ejecución del sistema, podemos revisar el
fichero de log para comprobar qué componente ha sido el que ha generado el error y en qué
consiste dicho error.
Normalmente, al igual que muchas aplicaciones, podemos escoger el nivel de detalle de los
mensajes que queremos que se almacenen en el log, que puede ser uno de los siguientes:
Cuadro 5.1
Nivel de los mensajes que se almacenan en el log
Debug Guarda en el log información de mucho detalle de las operaciones que realiza
el sistema gestor. Se suele usar durante el desarrollo de la propia aplicación
para comprobar su funcionamiento.
Warning Guarda solamente mensajes relevantes producidos durante la ejecución.
Error Únicamente se almacenan los errores producidos en la aplicación.
5.2.3. Diccionario de datos

Toda la información del sistema se guarda en el diccionario de datos, por lo que por medio de
consultas sobre las vistas del diccionario de datos es posible comprobar las consultas que se están
ejecutando, quien las ejecuta, si se están produciendo bloqueos y qué sentencias producen y se
ven afectadas por ellos, etc.
Tal como se indicó anteriormente, las tareas de monitorización y diagnóstico deben tratar
de ser lo menos intrusivas posible para no afectar al rendimiento del sistema.
Capítulo 5
Recuerda
3 Las herramientas gráficas en general consumirán más recursos del sistema y de la
base de datos, por lo que determinadas tareas puede ser conveniente realizarlas por
medio de consultas al diccionario de datos en lugar de recurrir al monitor de rendimiento
(que internamente lo que está haciendo para mostrar la información es lanzar consultas
sobre el diccionario de datos y mostrar los resultados de manera gráfica).
Comprobar esta información directamente con consultas sobre la base de datos no es muy
intuitivo, pero es posible elaborar informes que ejecuten estas sentencias y muestren de modo
gráfico y personalizado toda la información que nos interese conocer en cada momento.
Otra ventaja de esta opción es que el acceso al monitor de rendimiento habitualmente
está limitado a usuarios con permisos de administración, mientras que a cualquier usuario se le
podría dar permiso para ejecutar consultas sobre determinadas tablas del diccionario de datos y
que pudiese comprobar información puntual acerca del estado de la instancia.
En caso de detectar una sentencia SQL que está consumiendo muchos recursos (penalizan-
do el rendimiento del sistema) o que se ha quedado colgada por cualquier motivo, es posible
forzar la finalización de dicha sentencia por medio de instrucciones SQL.
5.3. Monitorización en Oracle

Oracle dispone de una herramienta específica para monitorizar la actividad del sistema gestor
(un monitor de rendimiento), aunque esta no forma parte del paquete por defecto que se instala
con el sistema gestor, por lo que existen alternativas que pasan fundamentalmente por acceder
a la información de forma directa a través del diccionario de datos.
5.3.1. Monitor de rendimiento

La principal herramienta existente para monitorizar la actividad de la instancia en Oracle será el
EM, pero también es posible utilizar directamente el diccionario de datos (incluso a través del
SQL Developer) para realizar diversas tareas de monitorización.
A) Enterprise Manager

La principal herramienta que empleará el DBA para monitorizar una instancia de Oracle
será el EM.
En su versión “cloud control”, el EM permite realizar un seguimiento muy detallado de
todo lo que sucede en el sistema gestor. Entre sus principales funciones con respecto a la mo-
nitorización del sistema destacan:
1. Monitor de rendimiento: permite hacer un seguimiento del uso que se está haciendo
de los recursos del sistema.
2. Gestión de incidencias, eventos y problemas: desde la utilidad de gestión de inciden-
cias se podrán revisar picos de uso de recursos o errores que se hayan producido en la
Capítulo 5
instancia. Es posible también crear reglas que capturen y registren excepciones concre-
tas que se produzcan en la base de datos y las muestren en el gestor de incidencias.
3. Gestionar las tareas programadas: permite programar nuevas tareas y realizar un segui-
miento de las ejecuciones de las tareas ya programadas.
4. Definir acciones correctivas, que se ejecutarán en respuesta a alertas o eventos concretos.
5. Definir notificaciones, que se enviarán ante determinados sucesos.
6. Consultar informes predefinidos con información acerca del estado de la instancia.
En su versión “express”, la única funcionalidad que contempla es la monitorización de las
consultas ejecutadas en el sistema gestor y el uso de los recursos de la instancia.
B) Diccionario de datos

Toda la información del estado del sistema gestor se almacena en el diccionario de datos de
Oracle. Las vistas donde se guarda esta información no almacenan objetos de bases de datos, por
lo que no usan los prefijos “user_”, “all_” o “dba_” como las vistas que hemos empleado hasta
ahora, sino que se utilizan vistas dinámicas de rendimiento que comienzan por el prefijo “v$”.
En la SGA se guardan las consultas más ejecutadas durante la sesión, por lo que si queremos
saber cuáles son las consultas más usadas durante un periodo de tiempo, podemos hacerlo con
una consulta sobre la vista V$SQLAREA.
La instalación del sistema gestor Oracle incluye la instalación del EM Database Express. Accede al
recurso digital Monitorización con EM, en el que se proponen algunas tareas que se pueden
llevar a cabo por medio de dicha herramienta, así como del diccionario de datos, para realizar
una monitorización básica de la actividad del sistema.
C) SQL Developer

El SQL Developer (al igual que otras aplicaciones de desarrollo como TOAD) permite
consultar también cierta información de monitorización del uso del sistema gestor, como las úl-
timas consultas que se han lanzado (Historial SQL), y dispone de numerosos informes (consul-
tas predefinidas), tanto de administración del sistema gestor como de desarrollo, seguridad, etc.
5.3.2. Registro de errores

Desde la versión 11 de Oracle, existe un repositorio automático de diagnóstico (ARD, Auto-
matic Diagnostic Repository) donde se guarda la información de las trazas (errores, warnings y
mensajes informativos) generadas por el sistema. Este repositorio es un estructura de directorios
almacenada fuera de la base de datos (por defecto en ORACLE_BASE\diag), para permitir el
diagnóstico de errores incluso cuando la base de datos esté parada.
Dentro de la estructura de directorios de ADR existen varios subdirectorios donde se va
almacenando la información, cuya localización se puede consultar por medio de la vista V$-
DIAG_INFO, que muestra la ubicación de:
Capítulo 5
● alert.log: log del sistema en formato XML. Registra cronológicamente los errores pro-
cedentes de la operación diaria del sistema gestor. Cada instancia tendrá su propio
registro de log (alertORCL.log), pero todos los PDB comparten el mismo alert.log.
● cdump: archivos core, donde se registran las trazas producidas por el núcleo del sistema.
● incident: contiene múltiples subdirectorios, cada uno con el nombre de un incidente en
concreto y en cada uno de ellos se guardarán los dumps producidos por ese indicente.
● trace: directorio donde se guardan las trazas de los procesos de background, de los pro-
cesos de servidor, del listener y de otros programas de usuario.
● others: otros subdirectorios donde se almacenan incidencias, reportes de monitorización
y otro tipo de información.
Figura 5.1
Ubicación de los ficheros de log.
El SQL Developer también permite realizar determinadas tareas de monitorización. Accede al re-
curso digital Monitorización con Developer, donde se muestra cómo revisar distintos aspectos
del sistema gestor por medio de los informes del Developer, y cómo emplear la herramienta para
acceder al contenido del alert.log de forma más legible y más fácilmente manipulable.
5.4. Optimización
Al igual que existían varios niveles en los que era necesario realizar tareas de configuración
inicial del sistema gestor (a nivel del entorno del servidor, a nivel de red, etc.), las tareas de op-
timización del sistema deben realizarse también a varios niveles, ya que será necesario tener en
cuenta tanto los aspectos internos del sistema gestor y sus bases de datos como aspectos externos
del equipo donde se encuentra instalado y de las comunicaciones a través de las que se accede
al sistema gestor.
5.4.1. Optimización del entorno

Antes de centrarse en la optimización del servidor de bases de datos, es conveniente comprobar
que el entorno donde está instalado ese servidor es el más adecuado.
Capítulo 5
La optimización del servidor se centrará especialmente en el sistema operativo y la cone-

xión de red:
a) A nivel de sistema operativo, existen comandos de sistema operativo (como prfmon de

Windows o systat de Linux) que contienen numerosas métricas (accesos a disco, uso
de CPU, etc.) que permiten monitorizar el rendimiento del sistema operativo, y permi-
ten definir nuevas métricas, tanto del propio sistema operativo como de las aplicaciones
instaladas, por lo que pueden utilizarse para monitorizar el rendimiento del SGBD.
b) A nivel de red, en un servidor con varios procesadores y varias tarjetas de red, es posible
definir afinidades entre una tarjeta de red y un procesador, de forma que las peticiones
que lleguen por cada tarjeta se asignarían a un procesador concreto, minimizando de esa
manera los bloqueos que se podrían producir entre CPU por compartición de recursos.
5.4.2. Optimización del sistema gestor

Las operaciones de optimización que podemos llevar a cabo en el sistema gestor están enca-
minadas básicamente a dimensionar adecuadamente los componentes físicos del mismo (las
estructuras de almacenamiento que se utilizan para almacenar los objetos de las bases de datos):
a) Tamaño de los bloques de datos: la información de las tablas se almacena lógicamente fila
a fila, y físicamente en bloques de datos. Si el tamaño de una fila es muy grande y el
tamaño de los bloques es muy pequeño, sucederá habitualmente que una fila haya que
guardarla en dos bloques de datos, con lo cual para leer la información de esa fila serían
necesarios dos accesos a disco, lo que implica una penalización del rendimiento. Es ne-
cesario por tanto asignar un tamaño adecuado a los bloques de datos que empleen las
tablas (las tablas con muchas columnas tendrán que tener un tamaño de bloque mayor
que las tablas con pocas columnas, para evitar su fragmentación).
b) Tamaño y ubicación de los ficheros de datos: el acceso al almacenamiento físico (el disco) su-
pone habitualmente un cuello de botella: si todos los datos están almacenados en el mis-
mo disco físico, todos los accesos a disco se realizarán en el mismo dispositivo y no se
pueden paralelizar. Para solucionar este problema, se recomendaba separar, si es posible,
los datos de las tablas grandes en varios discos (especialmente si están particionadas), y
separar en distintos discos también los datos y los índices de una misma tabla, de forma
que los accesos a ambos pudiesen realizarse en paralelo. Los sistemas gestores de bases
de datos instalados en entornos de producción suelen utilizar almacenamiento RAID
o almacenamiento NAS o SAN (en red), de forma que estas consideraciones ya no son
necesarias, aunque sí se recomienda utilizar tantos discos como CPU tenga el servidor,
para optimizar el procesamiento paralelo.
c) Deshabilitar procesos “ocultos”: muchos sistemas gestores permiten configurar los archivos
de datos para que incrementen su tamaño (auto-grow) o se compacten (auto-shrink) au-
tomáticamente si se quedan sin espacio libre. El problema de estos procesos es que escapan
a nuestro control y se pueden ejecutar en cualquier momento, y son procesos bastante
costosos en cuanto a uso de disco. En general, se recomienda deshabilitar este tipo de
procesos y monitorizarlos y ejecutarlos manualmente fuera del horario de producción,
minimizando de ese modo el impacto que puedan tener los cambios.
Capítulo 5
d) Tamaño del almacenamiento temporal: todas las transacciones que se ejecutan en el sistema
gestor almacenan los datos que van generando hasta que finaliza la transacción en un
espacio de almacenamiento temporal. Si este espacio se llena, el sistema no admitirá más
transacciones, por lo que debemos asegurar que tenga espacio suficiente pero sin des-
perdiciar espacio en disco. El espacio dedicado al almacenamiento temporal dependerá
principalmente del tipo de tablas que tengamos y del tipo de transacciones que se rea-
licen: en entornos operacionales (con tablas pequeñas y muchas transacciones simples),
no será necesario un tablespace temporal muy grande, únicamente habrá que asegurar
que se puedan ejecutar todas las transacciones. En entornos data warehouse, con ta-
blas muy grandes y pocas transacciones pero muy complejas, necesitaremos un espacio
temporal muy grande para almacenar los resultados parciales de las consultas que se
ejecuten. El almacenamiento temporal nunca debería tener activado el incremento de
espacio automático (auto-grow).
5.4.3. Optimización de la base de datos

La optimización de la base de datos se centrará principalmente en asegurar que el diseño físico
sea adecuado y en eliminar en la medida de lo posible los espacios vacíos innecesarios existentes
en los objetos de base de datos (tanto tablas como índices).
Hay varios aspectos que nos pueden ayudar a optimizar la forma de almacenar nuestros
datos:
a) Diseño de las tablas y elección de tipos: es importante que el tipo de datos que utilicemos
se ajuste lo más posible al rango de valores a almacenar. También es importante ajustar
los tipos de datos a lo que necesitemos, para evitar conversiones de tipos de datos inne-
cesarias, lo cual también afectará al rendimiento.
Ejemplo
Una base de datos de ventas contiene una tabla maestra de “tipos de pago” en la que se alma-
cenan los diferentes tipos de pago que actualmente permite la empresa. La tabla tiene un código
identificador de “tipos de pago” al que se ha asignado un tipo entero de 10 dígitos, cuando sola-
mente se permiten 5 tipos de pago (que se podrían representar con un solo dígito). Si el sistema
gestor representa cada dígito por medio de 2 bytes, esto supondría que se estarían desperdician-
do 2 bytes * 9 dígitos=18 bytes en cada fila. Si se han realizado 10 millones de ventas, cada
una con su código de tipo de pago, se estarían desperdiciando al menos 180 MB de espacio de
almacenamiento (réplicas y RAID aparte), pero además el hecho de tener que leer más bytes en
disco al lanzar las consultas implica también un menor rendimiento de las consultas.
b) Campos calculados: los campos calculados obligan al sistema a realizar numerosas opera-
ciones durante su consulta, lo que puede afectar al rendimiento del sistema. Si los campos
a partir de los que se calculan no sufren variaciones, puede ser conveniente incorporar
los campos calculados a la base de datos, calculando su valor en el m omento que se in-
sertan, y evitando de esta forma recalcularlos continuamente al realizar las consultas.
Capítulo 5
c) Desnormalización: hay datos que se consultan siempre en combinación con datos de

otras tablas que los complementan (especialmente en entornos data warehouse). Para
evitar JOIN innecesarios, una opción es desnormalizar, que consiste en romper la for-
ma normal de Boyce Codd (FNBC) al insertar atributos de una tabla en otra tabla o
crear una tabla como el resultado de la unión de otras tablas. En ambos casos, esto impli-
ca incorporar información redundante, aparte de hacer que la implementación sea más
compleja y reducir la flexibilidad, por lo que estas redundancias deben estar controladas.
Ejemplo
Las desnormalización es muy habitual en entornos data warehouse. En este tipo de sistemas se
utilizan tablas muy grandes, por lo que es fundamental minimizar las operaciones de JOIN al
realizar las consultas. Al desnormalizar lo que hacemos es reducir los JOIN a costa de incre-
mentar la redundancia en el sistema.
Supongamos una base de datos con información de productos, que contiene las siguientes
tablas:
Figura 5.2
Tablas operacional.
Para consultar la información de los productos en un data warehou-

se que explotase la información de esta base de datos, usaríamos una
única dimensión producto que contendría todos los campos de todas
las tablas:
Figura 5.3
Dimensión producto.
d) Particionamiento: el particionamiento de una tabla o índice consiste en dividir esta en

varios segmentos (llamados particiones) que pueden ser accedidos de forma individual.
Esto tiene varias ventajas:
● Cuando se accede a datos de una sola partición, se accede únicamente a esa parti-
ción, evitando procesar toda la tabla.
● Permite guardar en una sola tabla más datos que los que podrían ser alojados física-
mente en un disco (guardando cada partición en un disco diferente).

● Si tenemos las particiones en distintos discos, los datos de las distintas particiones
pueden ser accedidos en paralelo optimizando el acceso.
Capítulo 5
● Facilita operaciones como el purgado de datos. Si se quisiesen eliminar los datos de

las ventas de hace 10 años, solamente habría que eliminar las particiones de la tabla
ventas correspondientes a ese año, en lugar de ejecutar un delete que bloquearía la
tabla y además sería mucho más lento.
e) Desfragmentación: internamente, las tablas se organizan en bloques o páginas, que cons-

tituyen la unidad de acceso a disco (cuando se accede a disco no se lee una fila sola,
sino que se recupera todo el bloque donde está esa fila). Cuando se inserta una fila en
una tabla, se busca un bloque con espacio libre y se inserta ahí la información. Si no
quedan bloques libres, se crea uno nuevo. Esto puede dar lugar a varios problemas, pero
el mayor de ellos es la fragmentación, que se produce al eliminar registros de una tabla
de forma masiva, provocando que queden “huecos” en los bloques que están desperdi-
ciando espacio. Se soluciona compactando la tabla o moviéndola.
f) Balanceo de índices: el desbalanceo de los índices se produce en índices con estructura de
árbol, cuando las ramas del árbol quedan desniveladas debido a la realización de modifi-
caciones sobre las columnas del índice y borrados de filas. Si un índice está desnivelado,
el acceso a un dato del índice requiere muchos más accesos a disco que en un índice
balanceado.
Índice no balanceado 20
16 21
Índice balanceado
15 17
15
10
7 20
8
4 8 16 21 7
2 5 10 17 2
4
Figura 5.4 5
Índices balanceados y no balanceados.
Si queremos recuperar el valor 5 (el peor caso), con el índice balanceado solamente
necesitaríamos 4 accesos mientras que con el índice no balanceado necesitaríamos 9.
Para balancear de nuevo el índice habrá que reconstruir el índice o reorganizarlo.
La ventaja de reconstruirlo es que además de nivelarlo elimina los espacios vacíos que
queden en los bloques del índice, por lo que también se desfragmentaría el índice.
g) Crear, modificar o eliminar índices.
5.4.4. Creación de índices

La creación de índices es la forma más rápida y sencilla de mejorar el rendimiento de nuestras
consultas. Los índices son especialmente adecuados para optimizar consultas que seleccionan un
pequeño porcentaje de los registros de una tabla.
Capítulo 5
Sin embargo, crear índices tiene también sus desventajas: crear un índice implica la nece-
sidad de mayor espacio de almacenamiento (para guardar el índice), y un consumo extra de
recursos, ya que cada vez que se manipulan los datos de la tabla es necesario actualizar también
el índice. Es necesario, por tanto, buscar un equilibrio a la hora de crear índices entre el rendi-
miento que aportan y el coste de su implementación (tan importante como la creación de los
índices es la eliminación de índices innecesarios).
A la hora de crear un índice, debemos tener en cuenta dos cuestiones:
A) Sobre qué columnas crear el índice

En general, se deben crear índices en:
– Las claves primarias y foráneas (estos índices normalmente ya los crea automáticamente).
– En las columnas que habitualmente aparecen en el SELECT o el WHERE de las consultas.
– Columnas con buena selectividad. La selectividad de un índice es buena si pocas filas
del índice tienen el mismo valor.
Y no se deben crear índices en:
– Tablas con muy pocos datos: si la tabla se puede cargar entera en memoria al consultarla
es más rápido recorrerla entera en memoria que acceder a través de un índice.
– Columnas que tienen muchos nulos.
– Columnas cuyos valores se modifiquen muy frecuentemente, ya que implicaría un cos-
te extra de actualización del índice muy elevado.
– Índices sobre muchas columnas (su coste de mantenimiento y espacio son muy altos).
– Si se crean muchos índices en una tabla, esto penaliza considerablemente las insercio-
nes, modificaciones y eliminaciones en la tabla, e incluso en las consultas a veces al
haber tantos índices directamente los omite.
¿Sabías que...?
Cuando creamos un índice sobre varias columnas, el orden es importante ya que el primer cam-
po que se indique será el que se use para ordenar las entradas del índice, por lo que el índice
sería muy eficiente para hacer búsquedas por el primer campo (recorrería solo las entradas del
índice necesarias para encontrar el valor buscado), mientras que las búsquedas por el segundo
campo tendrán que recorrer siempre todo el índice, ya que ese campo no está ordenado.
B) Qué tipo de índice crear

En este caso, la decisión dependerá especialmente del sistema gestor utilizado, ya que cada
sistema implementa sus propios tipos de índices. La filosofía detrás de cada tipo de índice par
ticular, sin embargo, suele ser común a todos los sistemas gestores. Los índices se pueden clasi-
ficar en base a dos aspectos:
Capítulo 5
1. Por su organización
● Agrupados: los campos sobre los que se define el índice determinan la organización
de la tabla, ya que las filas de la tabla se guardarán ordenadas en base al valor de las
columnas indexadas. No ocupan espacio adicional, pero solo se puede definir un
índice de este tipo por tabla. En general, se recomiendan para campos cuyo valor no
cambia (lo que obligaría a una reordenación del contenido de la tabla) y se utilizan
habitualmente en las consultas para filtrar los datos a recuperar, por lo que los sistemas
gestores los suelen emplear para implementar los índices para las claves primarias de
las tablas.
● No agrupados: se construyen como una estructura aparte de la tabla con punteros a los
datos de la tabla. Requieren espacio adicional pero se pueden definir tantos índices de
este tipo por tabla como se quiera. Se recomiendan para consultas que accedan solo a
parte de una tabla, consultas con JOIN o GROUP BY, consultas que devuelven pocos
datos, consultas que usen coincidencias exactas en el WHERE o consultas sobre co-
lumnas que no tengan muchos valores únicos.
2. Por su estructura
Existen varios tipos (dependen mucho del sistema gestor):
● Índices agrupados: el índice se implementa en la propia tabla, sin una estructura adicional.
Ejemplo
Supongamos una tabla de empleados en la que guardamos el código del empleado, su nom-
bre, su salario, su código de departamento y su género. Se podría crear un índice agrupado
para la clave primaria de la tabla. Las filas de la tabla se almacenarían ordenadas por dicho
campo, sin estructuras adicionales:
Figura 5.5
Ejemplo de índice agrupado.
● Índices B-tree (árbol binario): el índice se implementa como un conjunto de nodos en-
lazados entre sí formando un árbol. Cada nodo almacena los valores inferiores al suyo
propio en su subárbol izquierdo, y los valores superiores en su subárbol derecho.
Capítulo 5
Ejemplo
En la tabla del ejemplo anterior, se podría crear un índice de tipo b-tree para optimizar las
consultas que acceden al campo “empleado”. Para crear su árbol correspondiente, se partiría
de un nodo raíz al que se asignaría un valor intermedio, en este caso "Darío", y se irá constru-
yendo el árbol almacenando a su izquierda los valores inferiores a ese valor, y a su derecha
los valores superiores.
Índice empleado
Darío
Beatriz Esperanza
Armando Carla Javier
Figura 5.6
Ejemplo índice b-tree.
Si se ejecutase la consulta:
SELECT * FROM personal WHERE empleado=’Armando’;
Accedería en primer lugar al nodo central, cuyo valor es "Darío". Como el valor buscado
es inferior (en orden alfabético), se continuaría la búsqueda en su subárbol izquierdo, con lo
cual se accedería al nodo con valor "Beatriz". Como el valor buscado sigue siendo inferior, se
accedería de nuevo a su subárbol izquierdo, y se encontraría el valor buscado.
● Índices bitmap: se implementan en forma de vectores de valores binarios. Para cada po-
sible valor del campo, se crea un vector con tantos elementos como filas tenga la tabla:
si en la fila X de la tabla el valor del campo coincide con el del vector, entonces en la
posición X del vector se almacena un 1, y si no se almacena un 0. Son adecuados para
columnas con pocas modificaciones que toman pocos valores diferentes (especialmente
en entornos data warehouse).
Ejemplo
Utilizando el mismo caso del ejemplo anterior, supongamos que en la empresa solamente hay
3 departamentos, y son muy raros los cambios de departamento entre los empleados. Podría-
mos crear un índice de tipo bitmap para el código de departamento y otro para el género (que
solo puede tomar dos valores y tampoco suele cambiar).
En el índice del campo género se crearía un vector binario para el valor “Hombre” (que
tomará el valor 1 en las filas que correspondan a hombres y 0 en las filas que correspondan a
mujeres) y otro vector para el valor “Mujer” que almacenará unos para las mujeres y ceros para
Capítulo 5
los hombres. Para el índice del código de departamento, se crearía un vector para cada uno
de los posibles valores del campo “coddepto” que tomaría valores de manera análoga:
Figura 5.7
Ejemplo de índices bitmap.
Si se realizase una consulta como la siguiente:
SELECT * FROM personal WHERE genero=’Mujer’ AND coddepto=2;
El sistema gestor la resolvería haciendo una operación “AND” entre los vectores corres-
pondientes de los dos índices y la tabla:
Figura 5.8
Resultado de consulta con índices bitmap.
● Índices hash: este tipo de índices utilizan una función (la función hash), que, aplicada a
un valor del campo, determina en qué posición del índice se almacena dicho valor, y en
esa posición se almacenará un puntero a la fila concreta de la tabla. Son muy útiles para
consultas en las que se busque siempre un valor concreto de un campo, pero son malos
para buscar rangos de valores (tendrían que aplicar la función a cada valor y no podrían
recuperar los datos en bloque) o en casos en que el resultado de aplicar la función hash
es el mismo para muchos valores del campo, ya que en esos casos obliga a implementar
medidas de gestión de duplicados (como crear una zona de desbordamiento al final del
índice donde se buscarían secuencialmente los valores repetidos).
Capítulo 5
Ejemplo
Para completar el caso propuesto en los ejemplos anteriores, crearemos un índice hash sobre
el campo “salario”. Pongamos que la función hash que emplearemos será f(X)=X mod 9, es
decir, tendremos un índice con 9 posiciones y para saber qué posición corresponde a cada
valor lo dividiríamos entre 9. El resto de esa división será la posición en la que tendremos que
buscar ese valor:
Figura 5.9
Ejemplo de índice hash.
Si se ejecutase la consulta:
SELECT * FROM personal WHERE salario=1500;
El sistema gestor aplicaría la función hash al valor 1500:
Accedería a la posición 6 del índice y ahí encontraría el valor almacenado junto con un
puntero a la fila de la tabla donde se almacena ese valor.
Accede al recurso digital Creación de índices donde se plantean ejemplos de bases de datos
sobre las que se realizan diferentes consultas de información, y determina qué índices sería más
adecuado emplear en cada caso.
5.4.5. Optimización de consultas
Antes de proceder a optimizar las consultas de nuestro sistema, es importante identificar las con-
sultas que se ejecutan más a menudo y consumen más recursos, para centrar en ellas las tareas
de optimización.
Los lenguajes de consulta basados en el álgebra relacional como SQL son no procedimen-
tales, ya que el usuario dice el resultado que quiere obtener, pero no cómo conseguirlo. Esto
Capítulo 5
presenta una gran ventaja para el usuario, pero delega en el sistema la toma de estas decisiones,
lo que limita notablemente la capacidad del usuario para asegurar que los datos se recuperen de
forma óptima (aunque sí existen varias tareas que se pueden llevar a cabo para ayudar al sistema
a tomar las decisiones correctas).
Cuando se ejecuta una consulta se siguen las siguientes fases:
1. Análisis sintáctico: se comprueba que la sintaxis de la sentencia SQL es correcta.

2. Binding: se comprueba que los cruces entre las tablas son correctos.
3. Búsqueda del plan de ejecución óptimo: el optimizador buscará todas las formas posi-
bles de resolver la consulta y calculará un plan de ejecución con un coste asociado para
cada una de ellas. Para calcular ese coste usará principalmente información de las esta-
dísticas de las tablas, pero también información referente a índices, restricciones, etc. El
que tenga menor estimación de coste será el que se ejecute, y se almacenará en la caché
de consultas para evitar tener que recalcularlo la próxima vez que se ejecute la consulta.
4. Ejecución del plan de ejecución de menor coste.
A) Estadísticas
Las estadísticas de las tablas se guardan en el diccionario de datos. Cuando creamos una tabla
en la base de datos, se inserta una fila en el diccionario de datos con el nombre y características
de la tabla definidas en el DDL de creación de la tabla, pero toda la información referente a la
distribución de los datos en dicha tabla (bloques vacíos, longitud promedio de sus filas, distribu-
ción de los datos, etc.) estará vacía hasta que se ejecuten las estadísticas de la tabla, proceso que
calculará todos estos parámetros y los actualizará en el diccionario de datos. Si las estadísticas no
están actualizadas el optimizador partirá de supuestos acerca de la distribución de los datos en
la tabla erróneos, por lo que generará planes incorrectos.
Recuerda
3 El primer paso por tanto para optimizar una consulta cuyo rendimiento se ha degradado
con el tiempo será actualizar las estadísticas de las tablas que participan en la consulta,
ya que es el proceso menos invasivo y ofrecerá mejorías considerables e inmediatas.
B) Reescritura de consultas

Realizar modificaciones en los parámetros del optimizador o en el diseño físico de las tablas
puede afectar a otras consultas, por lo que antes de proceder a realizar ese tipo de cambios es
preferible evaluar primero si es posible obtener un mejor resultado reescribiendo la consulta
(de este modo, los cambios no afectarían en absoluto al resto de consultas). Antes de proceder
a optimizar las consultas de nuestro sistema, es importante identificar las consultas que se eje-
cutan más a menudo y consumen más recursos, para centrar en ellas las tareas de optimización.
Existen varias modificaciones que se pueden realizar sobre las consultas para que sus re-
sultados sean mejores. En algunos sistemas gestores, el propio optimizador es capaz de realizar
varios tipos de reescrituras automáticamente, pero esto no siempre es así. Para comprobar si
Capítulo 5
efectivamente la reescritura de una consulta nos va a dar mejores resultados, lo único que ten-
dremos que hacer es comparar el coste estimado de los planes de ejecución de cada una de las
versiones de la consulta.
Las transformaciones que se realicen a las consultas deben buscar dos objetivos:
● Evitar recorrer toda la tabla siempre que sea posible.

● Simplificar y reducir el tamaño de las tablas que intervienen en la consulta antes de
realizar las combinaciones (JOIN), de forma que se obtenga el mismo resultado con
menos operaciones de lectura/escritura de tuplas. Las primeras fases que se resuelven
son las encaminadas a cruzar los datos de las tablas, por ello se recomienda crear índices
en las columnas que habitualmente se incluyen en los join de las tablas.
Algunas de las reescrituras que se pueden aplicar a las consultas para mejorar su rendimiento son:
1. Sustituir los OR por UNION
Si tenemos una consulta sobre dos tablas que devuelve las filas que cumplen una condición
en una de las tablas u otra condición en la otra tabla (con un OR), lo que hace el optimizador es
obtener primero todos los resultados del JOIN cruzando todas las filas de las dos tablas, guardar
los resultados en una tabla temporal y sobre ella aplicar los filtros. Si hubiese índices definidos
sobre las columnas “filtradas” no los utilizaría ya que el filtrado no lo hace sobre cada tabla,
sino sobre la tabla temporal que construye en memoria. Si en lugar del OR realizamos una
unión de las filas que cumplan una condición más las filas que cumplan la otra condición, pri-
mero recuperaría los datos que cumpliesen las condiciones en cada una de las tablas usando los
índices y luego haría el join solo de las filas que cumplan una u otra condición.
Ejemplo
La consulta:
SELECT emp.nombre, depto.nomdep

FROM emp, depto
WHERE emp.iddepto=depto.iddepto
and (emp.nombre=’PEPE’ or depto.nomdep=’CONTABILIDAD’)
Si hubiese un índice por nombre del empleado y otro por nombre del departamento, se
podría sustituir por:

FROM emp, depto
and emp.nombre=’PEPE’
UNION
FROM emp, depto
and depto.nomdep=’CONTABILIDAD’
Capítulo 5
2. IN vs EXISTS
Si tenemos una consulta que para cada valor de la consulta principal comprueba si se cum-
ple una condición en una subconsulta, si utilizamos los operadores IN, ALL o ANY, la subcon-
sulta siempre se ejecutaría completamente para cada registro de la consulta principal, mientras
que si utilizamos un exists(select 1 from …), en cuanto la subconsulta obtenga un resultado ya
no continuaría evaluando el resto de filas.
Por el contrario, si la subconsulta siempre devuelve los mismos valores y no es necesario
evaluarla para cada valor de la consulta principal, si utilizamos IN, la primera vez que ejecute
la subconsulta almacenará sus resultados en memoria y no tendrá que volver a ejecutar la sub-
consulta, mientras que con exists tendría que evaluarla para cada fila de la consulta principal.
Ejemplo
La consulta:
SELECT * FROM personal

WHERE iddepto IN (SELECT iddepto FROM depto WHERE nomdepto=’VENTAS’)
Se podría sustituir por:
SELECT * FROM personal

WHERE exists(SELECT 1 FROM depto WHERE emp.iddepto=depot.iddepto
and nomdepto=’VENTAS’)
3. IN vs BETWEEN
Si una sentencia consulta si el valor de un campo se encuentra en un rango de valores con-

secutivos, es recomendable emplear between en lugar de IN, ya que es más eficiente.
Ejemplo
La consulta:
SELECT * FROM personal WHERE codemp IN (1, 2, 3, 4);
SELECT * FROM personal WHERE codemp BETWEEN 1 AND 4;
4. Comparaciones
Cuando se comprueba si un valor sobre el que se ha creado un índice IS NULL o IS NOT

NULL, no se utiliza el índice para resolver la consulta. En algunos gestores sucede lo mismo
con el operador “distinto” (!= o <>). En estos casos, puede ser conveniente tratar de reescribir
la consulta de otra forma que ofrezca los mismos resultados.
Capítulo 5
Ejemplo
La consulta:
SELECT * FROM personal WHERE comision IS NOT NULL and salario!=1000;
SELECT * FROM personal WHERE comision>-1 AND (salario<1000 or salario>1000);
5. Uso de tablas derivadas, subconsultas y joins
Una subconsulta es una sentencia SELECT dentro de otra sentencia. Una tabla derivada

es una subconsulta que está dentro del FROM de la consulta principal. El tratamiento de am-
bas es diferente: en una subconsulta se ejecuta una búsqueda en la base de datos por cada regis-
tro de la consulta principal, mientras que en una tabla derivada se realiza una sola consulta a
la base de datos, almacenándose los resultados en una tabla temporal en memoria, que se con-
sultará mediante un JOIN con las tablas de la consulta principal. Sin embargo, en las tablas que
se crean en memoria con las tablas derivadas no se crean índices, por lo que en ocasiones puede
ser más conveniente usar subconsultas con índices en lugar de tablas derivadas, ya que aunque
hacen muchos más accesos, si los hacen a un índice pueden ser más eficientes.
En cualquiera de los casos, si es posible eliminar la subconsulta e incorporar los datos
en la propia consulta (agregando las tablas directamente en el join), esto siempre será más
eficiente.
Ejemplo
Queremos hacer una consulta que nos devuelva, para cada empleado, su información y además
el número de empleados que han nacido el mismo día. La podríamos escribir de las tres formas:
– Con una tabla derivada:
SELECT e.nombre, e.apellidos, e.fecnacimiento, e2.cuenta as mismo_dia
FROM personal e,
(SELECT fecnacimiento, count(*) as cuenta FROM personal GROUP BY fecnacimien-
to) e2
WHERE e2.fecnacimiento = e.fecnacimiento
– Con una subconsulta dentro de la sección SELECT:
SELECT e.nombre, e.apellidos, e.fecnacimiento,

(SELECT count(e2.fecnacimiento) as mismo_dia
FROM personal as e2
WHERE e2.fecnacimiento = e.fecnacimiento
GROUP BY e2.fecnacimiento) as mismo_dia
FROM personal e;
Capítulo 5
– Eliminando la subconsulta:
SELECT e1.nombre, e1.apellidos, e1.fecnacimiento, count(e2.*) as mismo_dia

FROM personal e1, personal e2
WHERE e1.fecnacimiento=e2.fecnacimiento
GROUP BY e1.nombre, e1.apellidos, e1.fecnacimiento
6. Group by
Cuando incluimos varias tablas en un join, es el optimizador quien decide a qué tablas
accede primero, y por lo general lo hace bien. Puede fallar sin embargo en casos en que la
consulta tiene un group by, ya que normalmente el criterio seguido por el optimizador es tratar
de minimizar los accesos a disco, pero no tiene en cuenta el esfuerzo que supondrá reordenar o
agrupar todos los resultados en memoria una vez obtenidos. Algunos sistemas gestores proveen
de herramientas para forzar al optimizador a utilizar las tablas del join en un orden concreto.
Por otra parte, el uso de GROUP BY en vistas puede empeorar el rendimiento de las consultas.
Ejemplo
Tenemos una vista que obtiene la suma de salarios de cada departamento:
CREATE VIEW v_salarios AS

SELECT coddepto, SUM(salario) as salarios
FROM personal GROUP BY coddepto;
Supongamos que se utiliza la vista mediante la sentencia:
SELECT * FROM v_salarios WHERE coddepto=5;
En primer lugar se ejecutaría la consulta que corresponde a la vista, y sobre sus resultados
se ejecutaría el segundo select, lo que equivaldría a ejecutar la siguiente consulta:
SELECT coddepto, SUM(salario) FROM personal

GROUP BY coddepto HAVING coddepto=5;
7. Cursores y funciones
Los cursores son una herramienta muy potente y muy eficaz en Oracle, pero no sucede lo
mismo en otros sistemas gestores que permiten definir cursores pero estos son muy ineficientes.
Usar funciones dentro de una SELECT es muy útil, pero también tenemos que tener cuidado
con ellas cuando las consultas son muy complejas.
Cuando ejecutamos una consulta, lo primero que hace el optimizador es comprobar si ya
tiene creado un plan en caché para esa consulta, y si lo tiene, lo utiliza. Si no lo tiene, lo cons-
truye y una vez que sabe cómo obtener los resultados de la mejor manera ejecuta la consulta.
Cuando usamos cursores o funciones, el sistema gestor entiende que es una consulta variable
Capítulo 5
por lo que no reutiliza los planes sino que los crea cada vez, lo que introduce carga adicional
innecesariamente. Además, algunos sistemas gestores ni siquiera utilizan los índices cuando hay
funciones o variables de por medio (si en la cláusula WHERE se utilizan campos indexados
como argumentos de funciones, el índice quedará desactivado), por lo que los resultados pue-
den ser francamente malos. Si se puede modificar la consulta para aplicar la condición sobre el
campo directamente, se podría usar el índice y así mejorar su rendimiento.
Ejemplo
La consulta:
SELECT * FROM personal WHERE length(nombre)>5;
SELECT * FROM personal WHERE nombre like ‘_____%’;
5.4.6. Herramientas de optimización

Las herramientas que se usarán principalmente para optimizar el sistema gestor serán las herra-
mientas de monitorización:
● El monitor de rendimiento: para saber si una consulta acapara excesivos recursos, si

realiza demasiados accesos a disco, etc.
● El registro de errores: para saber qué consultas se ejecutan más habitualmente y cuáles
son las que tardan más o consumen más recursos.
● El diccionario de datos: la herramienta para todo.
Es fundamental también para la optimización de consultas el plan de ejecución. Gracias al plan

de ejecución podemos saber qué es lo que está haciendo el optimizador para resolver nuestras
consultas y detectar posibles ineficiencias.
Existen también herramientas específicas de optimización propias de cada SGBD que lle-
van a cabo todos los pasos anteriores de manera automática: recopilan las consultas más ejecuta-
das y las que más tardan, analizan sus planes de ejecución y su consumo de recursos, analizan la
estructura interna de las tablas e índices que intervienen en la consulta y proponen actuaciones
para mejorar el rendimiento de las consultas.
A) Plan de ejecución

El primer paso para optimizar una consulta es revisar su plan de ejecución. El plan de eje-
cución de una consulta es una descripción del camino que seguirá el sistema para acceder a los
datos solicitados: en qué orden se accederá a las tablas, cómo se accederá a ellas (uso de índices,
etc.), cómo se irán filtrando los datos, cuando se ordenan, cuando se agrupan, etc.
Capítulo 5
Ten en cuenta
Al elaborar el plan de ejecución, el sistema gestor realiza también un cálculo del
coste estimado de ejecución de la consulta, que se mostrará conjuntamente con
su plan. Para cada paso del plan, muestra el coste de ejecución de dicho paso, lo
que nos puede orientar acerca de en qué paso podría ser más conveniente actuar.
Cada sistema gestor tiene sus propias herramientas para consultar los planes de ejecución,
algunas más sencillas que otras (en modo texto, en XML, en modo gráfico, etc.). En general,
todas ellas muestran la siguiente información:
● El orden en que se consultan las tablas.

● Los índices que se están empleando para acceder a cada tabla concreta (si los hubiera).
● El tipo de acceso a cada tabla. Los valores más habituales, de mejor a peor, son:
– Range: consulta un rango de valores de la tabla.

– Index: recorre el índice completo y luego accede a la tabla.
– ALL: hace un full scan: recorre toda la tabla.
Si algún acceso de la consulta es del tipo index o ALL, deberíamos revisar esa parte

de la consulta, a menos que queramos expresamente listar o calcular todos los regis-
tros de la tabla.
● La forma en que se cruzan las tablas. Existen tres tipos de JOIN:
– Nested loop: se buscan los resultados de la primera tabla, y se recorre la segunda

tabla registro a registro buscando coincidencias. Esto puede ser adecuado si la se-
gunda tabla es muy pequeña (tiene pocas filas).
– Merge join: se ordenan ambas tablas por el valor buscado y “mezcla” (merge) am-
bas. Funciona muy bien cuando las relaciones son 1:1.
– Hash map join: aplica una función hash sobre los datos para reducir el espacio de
búsqueda. El funcionamiento es algo parecido a la búsqueda en una guía de teléfo-
nos: primero buscar la inicial del apellido, y una vez encontrada se recorren todos
los teléfonos de esa inicial hasta buscar el que necesitas. Es bueno en conjuntos de
datos muy grandes con los datos desordenados.
B) Diccionario de datos

El diccionario de datos no solamente almacena información acerca del contenido de la base
de datos sino que también guarda información de detalle de cómo se almacena cada uno de los
objetos y cómo se distribuye internamente su información.
Es una herramienta muy útil para comprobar:
1. Las consultas que tardan más tiempo en ejecutarse.

2. Información acerca de la ejecución de las consultas, como los recursos que emplean, los
bloqueos que se producen, cantidad de accesos a disco, etc.
3. Si la organización interna de los objetos es adecuada (si existe fragmentación).
4. Si los índices se están usando correctamente.
5. Propuestas realizadas por los asesores o herramientas de optimización.
Capítulo 5
6. Y en general, toda la información que el sistema gestor recopile, se puede consultar a

través del diccionario de datos.
C) Herramientas específicas

Si tenemos un sistema gestor que en general ofrece malas prestaciones, existen herramientas
específicas que podemos emplear para optimizarlo. Estas herramientas analizan la actividad del
sistema y proponen mejoras que se pueden realizar para mejorar el rendimiento:
● Ejecución de las estadísticas de las tablas.

● Creación de índices.
● Reescritura de consultas.
● Desfragmentar la tabla.
● Creación de perfiles de usuario (para limitar el consumo de recursos de determinados
usuarios).
● Etc.
5.5. Optimización en Oracle
Las tareas de optimización externas al sistema gestor serán independientes del sistema gestor de
bases de datos específicos que se utilice, por lo que en el siguiente apartado veremos algunas
de las operaciones de optimización que se pueden llevar a cabo internamente en el sistema
gestor de bases de datos Oracle.
5.5.1. Optimización del sistema gestor

Veremos a continuación cómo llevar a cabo en Oracle las medidas de optimización del sistema
gestor comentadas anteriormente de manera genérica.
a) Tamaño de los bloques de datos: el parámetro del spfile “db_block_size” determina el

tamaño que tendrán los bloques de la base de datos. Por lo general, en entornos ope-
racionales es adecuado el valor que tiene por defecto (8 kB), mientras que en sistemas
data warehouse podría ser conveniente incrementarlo a 16 kB.
¿Sabías que...?
Este parámetro es común a la instancia, no se pueden especificar valores diferentes para dis-
tintos esquemas, ni siquiera para distintas PDB.
b) Tamaño y ubicación de los ficheros de datos: la ubicación de los ficheros de datos se indica
en el momento de crear los tablespaces, y se puede modificar, tal como se indicó en el
capítulo 2.
Capítulo 5
c) Deshabilitar procesos “ocultos”: cuando se crea un tablespace, es posible indicar cual debe
ser el comportamiento de cada uno de sus datafiles con respecto al incremento auto-
mático. Esta información se puede consultar también en el diccionario de datos:
select file_name,autoextensible,increment_by from dba_data_files;
Para cambiar el comportamiento de un tablespace:
alter database datafile ‘<datafile>’ AUTOEXTEND OFF;
d) Tamaño del almacenamiento temporal: para incrementar el tamaño del tablespace temporal
sería suficiente con añadirle un nuevo datafile con el tamaño deseado.
Ten en cuenta
Si se deshabilita el incremento automático del tamaño de los datafiles, podría suceder que un ta-
blespace se quedase sin espacio y esto implicaría que no se podrían insertar datos en las tablas. Esta
medida por tanto debería ir acompañada de la creación de una alerta o una tarea programada que
revise periódicamente si algún tablespace se está quedando sin espacio libre y envíe una notificación
para solucionarlo. En el próximo capítulo veremos cómo crear este tipo de tareas automáticas.
5.5.2. Optimización de los objetos de base de datos

Los problemas de optimización de los objetos de la base de datos suelen estar provocados por
algún error o ineficiencia en la forma de almacenar los objetos en la base de datos.
A) Fragmentación de las tablas

La operación rutinaria con las bases de datos (especialmente cuando hay muchas modifica-
ciones y borrados) provoca que queden espacios vacíos en medio de los bloques de datos donde
se guardan las filas de las tablas. Si borro la mitad de los datos de una tabla, no se reduce el nú-
mero de bloques que ocupa la tabla, sino que se crean espacios vacíos en medio de los bloques.
Esta fragmentación implica dos problemas:
– que se desperdicia mucho espacio;

– si una consulta tiene que recorrer toda la tabla, recorre muchos más bloques de disco
que los que serían realmente necesarios, con lo cual tarda mucho más.
Las modificaciones pueden provocar problemas similares: si tengo un campo de tipo var-
char2 en una tabla, por ejemplo, cuando inserto los datos solamente se ocupa el espacio que
realmente ocupe el varchar2. Si modifico todas esas filas incrementando la longitud del campo,
ya no me cabría en el espacio que tenía reservado en la fila, con lo cual lo que hace es añadir
el nuevo valor al final del bloque de datos en una zona especial para ello, con lo cual la fila se
parte en dos y para acceder a ella tendría que acceder dos veces al disco para recuperar sus datos.
Capítulo 5
La solución para ambos problemas es compactar las tablas, lo que haremos “moviendo” las ta-
blas al mismo sitio donde están (el comando MOVE se utiliza para mover las tablas a un tablespace
diferente, pero si lo ejecutamos sin indicar ningún tablespace lo que hace es compactar la tabla):
ALTER TABLE <tabla> MOVE [COMPRESS];
Si usamos la opción COMPRESS, además de compactar la tabla la comprime, con lo cual ocu-
pará menos espacio y las consultas serán más rápidas, pero en caso de que se modificasen los datos
de la tabla las operaciones de modificación serían más costosas y provocarían mayor fragmentación
en la tabla, con lo cual no se aconseja comprimir una tabla si sus datos se modifican frecuentemente.
B) Índices
Los índices se crean en Oracle usando la instrucción “CREATE INDEX”, indicando en
qué tabla y sobre qué campo o campos se va a definir el índice.
CREATE [BITMAP] INDEX <indice> ON <tabla>(campo1, campo2, …);
En Oracle se pueden crear índices de tipo b-tree (en forma de árbol) o índices bitmap, que
se suelen utilizar únicamente en bases de datos data warehouse.
Los índices b-tree guardan los valores del campo de forma ordenada. Si se realizan muchas
modificaciones sobre el índice, esto puede provocar que las ramas del árbol queden muy desba-
lanceadas, provocando que el índice sea mucho más ineficiente.
Cuando un índice está desnivelado, fragmentado o inutilizado, podemos arreglarlo recons-
truyéndolo con REBUILD, con lo que el índice quedaría nivelado y compactado:
ALTER INDEX <indice> REBUILD;
C) Actualización de estadísticas

Cuando el optimizador calcula los costes de cada consulta, lo hace en base a los datos de
las tablas que tiene almacenados en el diccionario de datos (las estadísticas). Si las estadísticas no
están actualizadas, los costes calculados no serán correctos, y puede que los planes elegidos
no sean los más adecuados.
En el paquete DBMS_STATS se almacenan todos los procedimientos de que dispone Oracle
para calcular estadísticas (existen distintas versiones para calcular estadísticas de una tabla, de una
base de datos completa, de una partición, etc.). Se pueden recalcular las estadísticas para una tabla
concreta (con el procedimiento gather_table_stats) o de todo un esquema (gather_schema_stats):
Execute dbms_stats.gather_table_stats(‘<esquema>’, ‘<tabla>’);

Execute dbms_stats.gather_schema_stats(‘<esquema>’);
Capítulo 5
D) Particionamiento
Cuando particionamos una tabla la dividimos en segmentos lógicos (particiones), que pue-
den ser tratadas como tablas individuales. Esto implica que podemos acceder simultáneamente a
varias particiones de la misma tabla, y que si consultamos datos de una partición, no se realizaría
un FULL SCAN de la tabla completa, sino solamente de la partición.
En Oracle no podemos particionar una tabla ya existente, sino que tenemos que crear una
nueva tabla particionada e insertar los datos en la nueva tabla. Tampoco se puede “desparticio-
nar” una tabla particionada.
Ejemplo
La siguiente tabla de pedidos estaría particionada mensualmente por fecha de pedido, de

forma que cada pedido se almacenará en la partición que corresponda al mes en que se ha
realizado el pedido. El campo escogido para particionar la tabla debe ser un campo cuyo valor
no varíe, porque un cambio en el valor de ese campo podría implicar un cambio de partición
del registro, lo cual (aunque se puede hacer) no es muy recomendable.
CREATE TABLE pedido(

codpedido number(12) primary key,
codprov number(8) not null,
codemp number(5) not null,
fecpedido timestamp,
fecentrega timestamp,
estado varchar2(20),
constraint fk_pedido_prov foreign key (codprov) references proveedor(codprov),
constraint fk_pedido_emp foreign key (codemp) references empleado(codemp)
) partition by range (fecpedido) (
partition P_202007 values less than (to_date(‘01-08-2020’,’dd-mm-yyyy’)),
partition P_FINAL values less than (MAXVALUE)
);
Accede al recurso digital Optimización de la base de datos. En él se propone una actividad

guiada por medio de la cual se podrá comprobar el impacto de realizar este tipo de modificaciones
(creación de índices, fragmentación de tablas, actualización de estadísticas y particionamiento de
las tablas) en una base de datos.
Capítulo 5
5.5.3. Optimización de consultas
Cuando ejecutamos una consulta, el optimizador de Oracle realiza varias comprobaciones y

reescribe la consulta automáticamente si lo considera necesario. Las operaciones que realiza son
las siguientes:
a) Evalúa las expresiones y las condiciones:
● Realiza los cálculos que pueda resolver antes de ejecutar la consulta: si encuen-
tra una expresión “WHERE precio>2000/5” la transformaría en “WHERE pre-
cio>400”.
● Sustituye determinadas instrucciones para hacerlas más eficientes: sustituye los LIKE
por “=” si no se usan las wilcards, si es posible sustituye los IN, ANY y SOME por
ORs, los ALL por ANDs y los OR por UNION, y transforma los BETWEEN en
comprobaciones “<= AND >=”.
● Puede inferir condiciones transitivas que le permitan usar mejor los índices. Por
ejemplo, podría sustituir la condición “WHERE dep.coddepto=3 and emp.cod-
depto=depto.coddepto” por “WHERE dep.coddepto=3 and emp.coddepto=3”.
b) Transforma sentencias complejas en otras más sencillas: si detecta subconsultas que pue-
den ser transformadas en un JOIN, realiza la transformación automáticamente.
c) Transforma las vistas en su correspondiente consulta.
d) En caso de que la consulta implique un JOIN de varias tablas, evalúa el orden en el que
accederá a ellas y de qué forma accederá a cada tabla.
¿Sabías que...?
En versiones antiguas de Oracle, era más eficiente hacer un join que cruzar las tablas en el
where, es decir, escribir una consulta de esta forma:
SELECT emp.nombre, dep.departamento

FROM personal emp JOIN departamento dep ON (emp.coddepto=dep.coddepto);
Era más eficiente que escribirla así:
SELECT emp.nombre, dep.departamento

FROM personal emp, departamento dep WHERE emp.coddepto=dep.coddepto;
En las versiones actuales, el sistema gestor ya detecta automáticamente los cruces de ta-
blas y realiza los accesos en el orden que considere más conveniente, independientemente de
cómo se escriba la consulta.
Accede al recurso digital Optimización de consultas que contiene varios ejemplos por medio
de los cuales podrás comprobar cómo la reescritura de una consulta puede afectar a su rendimiento.
Capítulo 5
5.5.4. Herramientas de optimización

A) Plan de ejecución
Para que un usuario pueda revisar los planes de ejecución de las consultas se le deben asig-
nar los permisos SELECT_CATALOG_ROLE y SELECT ANY DICCIONARY:
Grant select_catalog_role to <usuario>;

Grant select any dictionary to <usuario>;
El SQL Plus permite consultar el plan de ejecución de las consultas en modo texto, ejecu-
tando la siguiente instrucción:
Set autotrace traceonly explain
Tras su ejecución, cualquier consulta que se ejecute solamente mostrará su plan de ejecu-
ción y no devolverá datos. El resultado del plan será una tabla donde se muestran, en orden
descendente de ejecución, todos los pasos que se llevan a cabo para resolver la consulta. En cada
paso se mostrará la siguiente información:
– Id: identificador de la fila.

– Operación: operación llevada a cabo en el paso en cuestión.
– Name: si se accede a un índice o una tabla, indica el nombre del objeto al que se
accede.
– Rows: número de filas a las que se accede en el paso indicado (si en pasos anteriores se
habían leído 1 millón de filas y en el paso actual hacemos un join por índice con una tabla
de 2 filas, no se accede solo a dos filas, sino que se accede 1 millón de veces a una fila).
– Bytes: número de bytes leídos en el paso indicado. Con los bytes sucede lo mismo que
con las filas: se arrastran todos los datos leídos en pasos anteriores.
– Cost: coste estimado del paso actual.
– Time: tiempo estimado que le llevará llevar a cabo este paso.
Más sencillo es emplear el SQL Developer, ya que permite consultar el plan de ejecución
de forma gráfica y es más fácilmente interpretable. Para ello, basta con situar el cursor sobre la
consulta cuyo plan de ejecución se quiere comprobar y pulsar el botón “Explicación del plan”
o la tecla F10:
Figura 5.10
Consulta del plan de ejecución en SQL Developer.
Capítulo 5
Figura 5.11
Plan de ejecución en SQL Developer.
B) SQL Tunning Advisor

El SQL Tunning Advisor es una herramienta específica de Oracle para la optimización del
SGBD.
Su funcionamiento consiste en recopilar las consultas que se ejecutan durante un periodo,
comprobar cuáles de ellas se ejecutan más a menudo y consumen más recursos, y proponer
mejoras que se pueden llevar a cabo en el sistema para optimizar dichas consultas. Mientras
está activo, se ejecuta en segundo plano analizando todas las consultas que se ejecutan contra el
servidor buscando y registrando las ineficiencias o aspectos mejorables que encuentre, propo-
niendo la forma de corregirlas siempre que sea posible.
El SQL Tunning Advisor se puede activar desde el EM o haciendo uso del paquete DBMS_
AUTO_TASK_ADMIN, con las funciones “enable” y “disable” para activarlo o desactivarlo:
DBMS_AUTO_TASK_ADMIN.ENABLE (client_name => ‘sql tuning advisor’,

operation => NULL, window_name => NULL);
Las conclusiones o propuestas de mejora detectadas por el SQL Tunning Advisor se pueden
consultar por medio de la vista DBA_ADVISOR_ACTIONS:
SELECT * FROM DBA_ADVISOR_ACTIONS;
C) El monitor de operaciones

Oracle monitoriza automáticamente todas las consultas realizadas contra el sistema gestor.
Esta información puede consultarse utilizando el paquete DBMS_SQL_MONITOR o direc-
tamente a través del EM: en la sección “SQL Monitor” se pueden consultar las consultas de
mayor duración, las que se ejecutan más a menudo, las que realizan un mayor consumo de disco
o procesador, etc.
Capítulo 5
Figura 5.12
Monitor SQL.
El paquete DBMS_SQL_MONITOR permite monitorizar todas las operaciones que se

realicen durante un periodo sobre la base de datos. Los resultados se pueden consultar em-
pleando el procedimiento report_sql_monitor del propio paquete o con la vista V$SQL_MO-
NITOR:
variable exec_id number;

begin
:exec_id := dbms_sql_monitor.begin_operation ( dbop_name => ‘TEST1’,
forced_tracking => dbms_sql_monitor.force_tracking );
end;
/
/* Ejecución de las consultas a monitorizar */
begin
dbms_sql_monitor.end_operation ( dbop_name => ‘TEST1’, dbop_eid =>
:exec_id);
end;
/
/* Para consultar la información con la vista: */
SELECT status, sql_id, dbop_name, dbop_exec_id, con_name, elapsed_time
FROM v$sql_monitor;
/* Para consultar la información con el procedimiento del paquete */
SELECT DBMS_SQL_MONITOR.report_sql_monitor( dbop_name => ‘TEST1’, type
=> ‘TEXT’, report_level => ‘ALL’) AS report
FROM dual;
D) Operaciones particulares de Oracle

Oracle provee de numerosas herramientas específicas para optimizar determinadas tareas
habituales (no solamente las consultas). Algunas de las más relevantes son las siguientes:
● Inserciones masivas: las inserciones masivas permiten insertar datos en bloques en lugar
de hacerlo fila a fila, con lo que se incrementa notablemente la velocidad. En Oracle las
inserciones masivas se realizan por medio del SQL Loader.
● Insert append: al insertar datos en una tabla se van completando en primer lugar los
espacios libres que queden en los bloques de la tabla. Al hacer un append los datos se
Capítulo 5
insertan siempre por el final de la tabla, por lo que se evita recorrer la tabla y la inserción
es más rápida. Tiene el problema de que si se hace habitualmente puede dejar la tabla
muy fragmentada.
● Nologging: se emplea cuando se realiza una inserción de un gran número de filas en una
tabla, para evitar guardar registro de cada inserción en el fichero de redo. Esto implica
que la operación no se podrá deshacer, pero ahorra mucho tiempo debido a que no está
registrando todas las transacciones que está ejecutando.
● Intercambio de particiones: el intercambio de particiones permite intercambiar una tabla
por una partición de otra tabla. Las operaciones de inserción son mucho más rápidas
que las de modificación, por lo que en lugar de modificar los datos de una partición
de una tabla, se pueden insertar los datos en una tabla temporal y luego intercambiar
la tabla temporal por la partición (que es inmediato), con lo que además de ganar en
velocidad se actualizaría la información de la tabla sin afectar a su rendimiento.
Ejemplo
Tenemos una tabla de ventas particionada por año de venta:
Figura 5.13
Tabla particionada.
Cuando queremos actualizar la información correspondiente al año 2020, encontramos

que hay nuevos registros que insertar, pero hay registros anteriores que es necesario modifi-
car ya que sus datos han cambiado:
Figura 5.14
Modificaciones en la partición.
Capítulo 5
En lugar de ejecutar un update de las filas que han cambiado y un insert de las filas nuevas,
lo que podemos hacer es crear una tabla nueva donde insertaríamos todas las filas de 2020, y
luego intercambiar la tabla por la partición:
Figura 5.15
Intercambio de particiones.
● Vistas materializadas: las vistas materializadas almacenan no solo la consulta que define
la vista sino también sus datos. Se utilizan con consultas que acceden a datos que se
actualizan puntualmente y contienen cálculos y agrupaciones, ya que tener los datos
precalculados supone una reducción considerable en el tiempo necesario para acceder a
ellos. Se utilizan mucho en entornos data warehouse ya que la información únicamente
se actualiza cuando se lanza el proceso de carga (ETL) que vuelca la información en la
base de datos, y por tanto es sencillo controlar cuando se debe actualizar la vista mate-
rializada.
● Merge: la operación “merge” combina la inserción y modificación en una sola instruc-
ción. Al hacer el merge de una fila se comprueba si la clave de la fila existe en la tabla:
si no existe inserta esa fila, y si existe actualiza todas las columnas de la fila existente por
los de la fila nueva. Es muy apropiada para procesos ETL en entornos data warehouse.
● Hints: Oracle dispone de un mecanismo que permite al usuario guiar al optimizador a
la hora de resolver una consulta concreta, denominado hints. Los hints se indican entre
/*+ */, y permiten sugerir al optimizador que use un índice concreto, a que haga un
join de varias tablas en un orden concreto, a que inserte los datos de un modo determi-
nado, etc. Existen gran variedad de hints que podemos utilizar, pero hay que tener en
cuenta que un hint no obliga al optimizador a comportarse de una manera determina-
da: lo hará como le digamos si puede y quiere.
¿Sabías que...?
Muchas de las herramientas de optimización indicadas anteriormente son ade-

cuadas para entornos data warehouse. Esto es debido a que este tipo de bases
de datos manejan grandes cantidades de información, y por tanto la optimiza-
ción de las consultas tiene un impacto mucho mayor que el que tendría en un
entorno operacional donde se realizan consultas mucho más sencillas y rápidas.
Capítulo 5
Resumen
n Las principales tareas que tendrá que llevar a cabo el DBA en la etapa de explotación
del sistema gestor son la monitorización y optimización.
n La monitorización se realizará por medio del monitor de rendimiento (que permite detec
tar anomalías en el funcionamiento del sistema gestor en tiempo real), el registro de erro-
res (ayuda a detectar y diagnosticar errores una vez producidos) y el diccionario de datos
(que almacena y permite consultar toda la información disponible del sistema).
n Por medio del monitor de rendimiento se puede realizar un seguimiento de métricas,
detectar bloqueos o procesos que acaparen recursos, monitorizar el uso de los recur-
sos y definir alertas y umbrales.
n El registro de errores almacena todos los eventos producidos en el sistema gestor, los
errores, las consultas pesadas que se han lanzado y puede guardar también un registro
de todas las consultas ejecutadas.
n El diccionario de datos permite conceder acceso a información del monitor de ren-
dimiento a usuarios que no tienen permiso para emplear esa herramienta, facilita
la automatización de tareas y permite la elaboración de informes personalizados.
n La optimización del sistema debe buscar un equilibrio entre la mejoría que aporta frente
al impacto que puede tener en el resto de operaciones del sistema, y se aplicará a todos
los niveles: servidor (hardware, sistema operativo y red), SGBD, objetos de bases de
datos y consultas. Para optimizar el sistema disponemos de las herramientas de monitori-
zación, el plan de ejecución y herramientas de optimización específicas de cada SGBD.
n La optimización del entorno buscará ajustar la asignación de recursos al sistema gestor.
n Los ajustes en el sistema gestor buscarán optimizar las características de almacena-
miento del sistema (tamaño de los bloques, tamaño y ubicación de los ficheros de
datos, funcionamiento del optimizador y deshabilitar procesos ocultos).
n La optimización de los objetos de base de datos buscará adecuar su diseño físico a
las necesidades y mejorar la forma de almacenarlos para que sean más eficientes.
n Para optimizar las consultas se buscará reescribirlas de forma que el optimizador
construya planes de ejecución más eficientes, que empleen los índices siempre que
sea posible, eviten recorrer tablas completas si no es necesario y eviten en la medida
de lo posible los accesos a disco.
Tenemos una aplicación de gestión de nóminas cuya base de datos contiene las siguientes
tablas:
SEDE(codsede,nombre,direccion,codcoordinador)
CARGO(codcargo,cargo,bonificacion)
PERSONAL(codemp,codsede,nombre,apellidos,dni,direccion,cp,sueldo_base,
codcargo,feccontratacion,coddepto)
NOMINA(codnomina,codemp,codsede,mes,importe,retencion)
DEPARTAMENTO(coddepto, departamento, codresponsable)
Capítulo 5
1. Sabiendo que para consultar las nóminas de un empleado la aplicación permite
buscar por nombre del empleado o por sus apellidos, ¿qué índices crearías para las
tablas?
2. Una de las consultas que se ejecutarán más frecuentemente será el importe de las
nónimas de cada mes en cada departamento, que involucrará a las tablas de nóminas,
personal y departamento. Tras crear la base de datos comprobamos cual es el plan de
ejecución de la consulta, y posteriormente procedemos a insertar los datos en las tablas.
¿El plan de ejecución será el mismo antes y después de insertar datos en las tablas o
puede cambiar? Justifica tu respuesta.
3. Comprueba con el SQL Developer qué consultas habría que ejecutar para obtener la
siguiente información:
a) Eventos producidos en la última media hora.

b) Número de argumentos de la función ENABLE_POLICY en el paquete DBMS_
FGA.
c) Tablas almacenadas en tablespaces encriptados y algoritmo de encriptación de
cada una de ellas.
d) Objetos en estado inválido.
e) Tablespace con mayor % de espacio libre disponible.
4. Indica qué modificaciones se pueden llevar a cabo en la base de datos para optimizar
cada una de las siguientes consultas:
a) SELECT emp.nombre, emp.apellidos, nom.importe, nom.retencion, round(nom.

importe * (1-retencion/100),2) as importe_sin_retencion
FROM PERSONAL emp, NOMINA nom
WHERE emp.codemp=nom.codemp and emp.codsede=nom.codsede and emp.
codemp=122;
b) SELECT emp.nombre, emp.apellidos, sum(nom.importe)
WHERE emp.codemp=nom.codemp and emp.codsede=nom.codsede
AND (nom.mes < '2019-08' or nom.mes='2020-02')
GROUP BY emp.nombre, emp.apellidos;
5. Indica qué cambios se podrían aplicar a las siguientes consultas para reescribirlas de
forma que sean más eficientes.
a) SELECT emp.nombre,emp.apellidos
FROM PERSONAL emp, CARGO cr
WHERE emp.codcargo=cr.codcargo
AND (emp.codemp,emp.codsede) IN (SELECT nom.codemp,nom.codsede FROM
NOMINA nom WHERE nom.importe*nom.retencion/100 > cr.bonificacion);
b) SELECT nombre, apellidos
FROM PERSONAL emp
Capítulo 5
WHERE exists (SELECT 1 FROM NOMINA nom

WHERE nom.codemp=emp.codemp and nom.codsede=emp.codsede);
c) SELECT nombre, apellidos FROM PERSONAL WHERE codsede=3 and codemp in
(3,4,2,1,5);
d) SELECT nombre, apellidos
WHERE emp.codemp=nom.codemp and emp.codsede=nom.codsede
GROUP BY nombre, apellidos;
6. ¿Qué sentencia tendrías que ejecutar para actualizar las estadísticas de todas las tablas
del esquema USR_NOMINAS?
7. ¿Qué sentencia ejecutarías para desfragmentar la tabla personal?
8. ¿Qué sentencia tendrías que ejecutar para reconstruir el índice PK_NOMINA definido
sobre la clave principal de la tabla NOMINA del esquema usr_nominas?
9. Indica cuál de las siguientes consultas sobre la base de datos “bd_nominas” da lugar
a un plan de ejecución con mayor coste:
a) SELECT distinct nom.codemp,nom.codsede

FROM NOMINA nom
WHERE importe=(SELECT max(importe) FROM NOMINA nom2 WHERE nom.
codsede=nom2.codsede);
b) SELECT distinct nom.codemp,nom.codsede
FROM NOMINA nom
WHERE not exists (SELECT 1 FROM NOMINA nom2 WHERE nom.codsede=-
nom2.codsede and nom2.importe>nom.importe);
c) SELECT distinct nom.codemp,nom.codsede
FROM NOMINA nom
WHERE importe >= ALL (SELECT importe FROM NOMINA nom2 WHERE nom.
codsede=nom2.codsede);
d) SELECT distinct nom.codemp,nom.codsede
FROM NOMINA nom, NOMINA nom2
GROUP BY nom.codemp,nom.codsede,nom.importe
HAVING nom.importe=max(nom2.importe);
Capítulo 5
1. ¿Para qué sirve la caché de consultas?
a) Almacena los resultados de las consultas más recientes.
b) Almacena los últimos datos accedidos en la consulta a disco.
c) Almacena los planes de ejecución de las consultas ejecutadas.
d) Analiza los planes de ejecución posibles de cada consulta.
2. ¿Por qué es necesario actualizar las estadísticas?

a) Se usan para comprimir las tablas.
b) Se usan para optimizar las consultas.
c) Se usan para optimizar el espacio de almacenamiento.
d) Se usan para crear el plan de ejecución de las consultas.
3. Un plan de ejecución:
a) Determina cómo se puede resolver una consulta.
b) Se crea para ejecutar las consultas en el orden que queramos.
c) Establece la mejor forma de ejecutar una consulta.
d) Determina el orden en que se procesarán FROM, WHERE, ORDER...
4. ¿Qué operación no es conveniente delegar en el sistema gestor?

a) Compactación automática cuando se fragmentan los datafiles.
b) La ejecución de las estadísticas cuando lo considere el sistema gestor.
c) El incremento automático del tamaño de un tablespace cuando se queda sin
espacio.
5. ¿Qué diferencia existe entre usar JOIN o cruzar las tablas en el WHERE?
a) Con JOIN es más rápido.
b) Ninguna.
c) Depende del orden en que se realicen los cruces en el JOIN.
d) Cruzando las tablas en el WHERE es más rápido.
6. ¿Para qué sirven las estadísticas de una tabla?

a) Para hacer análisis detallados de las consultas ejecutadas.
b) Para generar el plan de ejecución más eficiente.
c) Para comprobar si hay muchos bloqueos entre transacciones.
d) Para distribuir los datos en los discos más eficientemente.
7. ¿Dónde puedo consultar las estadísticas de una tabla en Oracle?

a) En user_statistics.
b) En information_schema.statistics.
c) En user_tables.
d) En v$sql.
Capítulo 5
8. ¿Cuál de las siguientes no es una herramienta de monitorización?

a) El diccionario de datos.
b) El plan de ejecución.
c) El log de ejecución.
d) El monitor de rendimiento.
9. Si ejecuto una consulta sobre una tabla particionada que lee datos de todas las parti-
ciones de la tabla:
a) Será más rápida que si la tabla no estuviese particionada.
b) Será más lenta que si la tabla no estuviese particionada.
c) Depende de qué campo se haya usado para particionar la tabla.
d) El resultado sería el mismo.
10. ¿Por qué es necesario reconstruir los índices en Oracle?

a) Porque se utilizan para crear el plan de ejecución.
b) Porque si están en estado inválido no se estarán usando.
c) Porque optimizan la ejecución de las consultas.
SOLUCIONES:
a b c
1. a b c d
d 5.
2.
a b c d 6.
a b c d 9.
a b c d
a b c
3. a b c d 10.
d 7. a b c d
4.
a b c d 8.
a b c d
Capítulo 5
6
Automatización de tareas
Objetivos
3 Comprender las ventajas de automatizar tareas de administración del siste-
ma gestor de bases de datos.
3 Entender los tipos de tareas cuya automatización suele ser más habitual.
3 Conocer los mecanismos existentes para automatizar tareas de administra-
ción en el sistema gestor.
3 Diseñar programas sencillos que lleven a cabo tareas de administración del
sistema.
3 Manejar con soltura el diccionario de datos para recuperar cualquier tipo de
objeto que pueda ser necesario manipular por medio de una tarea de admi-
nistración.
Mapa conceptual
Rutinas internas Procedimientos
Funciones
Triggers
Programador de tareas
realiza Funciones
Puesta en marcha
Seguridad
Explotación
Administración Tareas de administración
Particionamiento
Reconstrucción de índices
Estadísticas
Compactación de tablas
Otras tareas
Capítulo 6
Automatización de tareas 189
Glosario
Agente. Servicio encargado de ejecutar las tareas programadas en el SGBD.

Función. Rutina interna que se ejecuta a petición del usuario y devuelve como resultado
un valor.
Procedimiento. Rutina interna que se ejecuta a petición del usuario y no devuelve ningún
resultado.
Rutinas externas. Las rutinas externas son programas que se ejecutan desde el sistema ges-
tor pero que se definen externamente, por medio de algún lenguaje de programación.
Rutinas internas. Las rutinas internas son programas que se definen y se ejecutan en el
propio sistema gestor de base de datos.
Script. Conjunto de instrucciones que se ejecutan conjuntamente, una a continuación de
otra.
Tareas de administración. Rutinas que manipulan los objetos de la base de datos para
garantizar que su estado sea el adecuado para funcionar correctamente.
Tareas de base de datos. Rutinas que manipulan los datos de la base de datos para garan-
tizar el cumplimiento de las reglas de negocio definidas por la organización.
Trigger. Disparador. Es una rutina interna que se ejecuta cuando se produce un evento.
Los eventos que disparan los triggers son las manipulaciones de datos sobre una tabla
(insert, update o delete).
6.1. Introducción
El principio básico de la automatización consiste en realizar tareas de forma sistemática y repe-

titiva sin que esté involucrado un usuario en su ejecución.
La automatización de tareas tiene varias ventajas:
● Ahorra tiempo.
● Reduce costes de administración.
● Reduce los errores en la ejecución (elimina el error humano).
Una tarea automatizada habitualmente está compuesta de varias subtareas o sentencias que
se deben ejecutar de manera conjunta. En estos casos será necesario crear previamente un pro-
grama, que será el que se automatice, que contendrá todas las tareas que sea necesario ejecutar.
Para crear y programar estos programas existen básicamente dos opciones:
1. Definir un script o programa externo al sistema gestor que se programará por medio del
programador de tareas del sistema operativo. Este script se conectará al sistema g estor y
Capítulo 6
ejecutará las sentencias que necesite. Esta solución no suele ser muy conveniente para
implementar tareas de administración ya que este tipo de tareas normalmente requieren
disponer de credenciales de administrador del sistema gestor, y delegar esta tarea en un
programa externo podría suponer una vulnerabilidad.
2. Definir y programar la rutina en el propio SGBD.
Los sistemas gestores por tanto deben proporcionar al DBA las herramientas necesarias
para crear rutinas que puedan ser programadas, y para programar estas rutinas de forma que se
ejecuten de manera automática.
6.2. Rutinas de base de datos

Las rutinas están formadas por una secuencia de comandos que permiten llevar a cabo el proce-
samiento de ciertas acciones desde dentro de la propia base de datos. Cuando se crea una rutina
se le asigna un nombre, que permite que esta pueda ser invocada y reutilizada tantas veces como
sea necesario. Las rutinas no forman parte del estándar SQL2, sino que se publicaron en una
extensión publicada en el año 1996 denominada SQL/PSM (Persistent Stored Modules), y más
adelante pasaron a formar parte de SQL:1999 (SQL3).
El estándar SQL:1999 admite rutinas externas o internas al sistema gestor.
– Las rutinas externas son programas definidos externamente al sistema gestor, pero que pue-
den ser invocados por este. Se puede especificar el lenguaje en que están escritas, cómo
deben ser llamadas, y si pueden o no modificar los datos o solamente consultarlos. En el
caso de Oracle, por ejemplo, permite la ejecución de aplicaciones y métodos en java (que
ejecuta haciendo uso de su propia máquina virtual de java) y en otros lenguajes (en este
caso cede el control al sistema operativo, que será el encargado de ejecutar esos programas).
– Las rutinas internas son programas definidos en el propio sistema gestor. Existen tres
tipos de rutinas internas: procedimientos, funciones y disparadores (triggers).
La utilización de rutinas internas aporta varias ventajas sobre la ejecución de las mismas
acciones por parte de código externo al sistema gestor:
● Rendimiento: cuando ejecutamos una rutina interna, el optimizador almacena en su

caché la mejor forma de ejecutar cada una de sus consultas, por lo que ejecutar varias
veces la rutina sería ligeramente más rápido que ejecutar las sentencias individualmente,
ya que no tiene que recalcular los planes de ejecución de sus sentencias.
● Reutilización: evita tener que desarrollar varias veces una tarea que se ejecuta periódi-
camente. Además, una vez desarrollada y probada la rutina, se elimina el error humano
en las sucesivas ejecuciones.
● Encapsulan las reglas del negocio: centralizan en un solo lugar las reglas de negocio (la
lógica concerniente a cada tarea concreta), en lugar de dispersarlas entre las distintas
aplicaciones que acceden a la base de datos. Delegando el control de la lógica funcional
en la base de datos, para realizar cualquier cambio bastaría con hacerlo en la base de
datos, y no afectaría a todas las aplicaciones.
● Mayor seguridad: si para cada operación de manipulación de datos se crea una rutina
interna que lleve a cabo la operación, los usuarios no tendrían que tener permisos de
Capítulo 6
manipulación sobre las tablas: en lugar de asignarles permiso de “INSERT” en una ta-
bla se les podría dar permiso de “EXECUTE” en una rutina que realice la inserción,
incorporando un nuevo nivel de abstracción entre los usuarios y las tablas.
Ejemplo
Supongamos que una empresa tiene varias aplicaciones que pueden dar de alta usuarios, y
por política de empresa se desea que los logins de todos los usuarios se creen a partir del
nombre del usuario y las iniciales de sus apellidos, con un formato “NOMBRE-A1-A2”. Para
asegurar que siempre se creen los usuarios correctamente se puede implementar en un pro-
cedimiento almacenado esta funcionalidad, de manera que cuando una aplicación quiera dar
de alta un usuario nuevo solo tiene que llamar a ese procedimiento pasándole el nombre y
apellidos del usuario, y el procedimiento sería quien insertase los datos en la base de datos.
De esta manera nos aseguramos que todos los usuarios se creen conforme a las reglas defini-
das por la empresa, garantizando que se cumplen las políticas de la empresa en ese sentido,
y para los usuarios sería completamente irrelevante cómo se almacene esa información (no
tendrían que saber ni donde se almacena esa información ni qué campos tiene la tabla donde
se almacene).
Por otra parte, la ejecución de este tipo de tareas en el sistema gestor de base de datos su-
pone un consumo considerable de recursos por parte del servidor, que estará destinando un
tiempo de procesamiento y memoria muy valiosos a realizar tareas que realmente no competen
al sistema gestor, cuya principal misión es gestionar el acceso a los datos.
Toma nota
Al igual que sucede con los procedimientos y funciones creadas por medio de un len-
guaje de programación, las rutinas internas que se definen en el sistema gestor deben
estar correctamente documentadas.
Esto implica que se deben recoger en un documento todos los procedimientos y ru-
tinas definidos en las bases de datos, pero también incluir como comentario en la propia
definición de cada rutina, al menos:
– Tarea o función de la rutina

– Descripción de los parámetros de entrada y salida
– Autor
– Versión
– Fecha de última modificación
Es conveniente también comentar de manera explícita en el código las operaciones

especialmente complejas que se realicen dentro de la rutina.
En sistemas grandes en los que el rendimiento del sistema se pudiese ver comprometido por
la incorporación de la lógica de negocio en las rutinas internas del sistema gestor, la opción más
eficiente pasaría por implementar una arquitectura cliente/servidor en tres capas, con una capa
intermedia compuesta de servicios web: los clientes no acceden al sistema gestor directamente,
Capítulo 6
sino que ejecutan servicios web alojados en un servidor web independiente, y este servidor web
sería el encargado de asumir esa tarea de procesamiento de la lógica de negocio (programada en
los servicios web), y ejecutar en el sistema gestor de base de datos únicamente las sentencias de
manipulación de datos que sean necesarias.
Usuario Cliente Servidor Servidor de

web base de datos
Figura 6.1
Arquitectura cliente/servidor en tres capas.
6.3. Rutinas internas en Oracle

Oracle fue el primer sistema gestor que incluyó un lenguaje de programación para crear rutinas
internas: el PL/SQL.
Por medio de este lenguaje de programación se pueden crear tanto procedimientos como
funciones y triggers.
Para comprobar el funcionamiento de cada una de las estructuras de programación que

se muestran a continuación, se incluyen ejemplos de uso de todas ellas en el recurso di-
gital Ejemplos PLSQL. En este documento se plantea la construcción incremental de un
procedimiento al que se van añadiendo funcionalidades paso a paso para comprobar la
utilidad y el funcionamiento de los componentes del lenguaje.
6.3.1. Permisos
Para poder crear procedimientos y funciones, el usuario debe tener el permiso “CREATE PRO-
CEDURE”. Para crear disparadores hay que asignarle al usuario el permiso “CREATE TRI-
GGER”. Si un usuario tiene concedidos permisos para crear procedimientos, podrá también
ejecutar sus propios procedimientos.
Para dar permisos de ejecución en los procedimientos, funciones o triggers de un usuario,
se conceden con el permiso “GRANT EXECUTE”:
GRANT CREATE PROCEDURE, CREATE TRIGGER TO <usuario>;

GRANT EXECUTE ON <esquema>.<procedimiento> TO <usuario> [WITH GRANT OPTION];
Capítulo 6
6.3.2. Procedimientos
Los procedimientos se ejecutan como una instrucción y no devuelven ningún valor. Su sintaxis
es la siguiente:
CREATE [OR REPLACE] PROCEDURE <procedimiento>(

<param1> [IN|OUT|IN OUT] <tipo_datos>,
<param2> [IN|OUT|IN OUT] <tipo_datos>, ...)
[AUTHID INVOKER|DEFINER]
IS
<variables>
BEGIN
<CÓDIGO PL/SQL>
[EXCEPTION]
<CÓDIGO PL/SQL de control de excepción>
END;
/
Donde:
– <procedimiento> será el nombre del procedimiento, que se utilizará para poder ejecu-
tarlo.
– AUTHID determina con qué permisos se ejecutará el procedimiento. Por defecto será
siempre INVOKER: cuando un usuario ejecuta el procedimiento utiliza sus permi-
sos, y si el procedimiento accediese a una tabla a la que el usuario no tuviese acceso
provocaría un error por falta de permisos. Si se utiliza la autenticación DEFINER, los
usuarios ejecutarían el procedimiento con los permisos del usuario que creó el proce-
dimiento.
Toma nota
La posibilidad de utilizar la autenticación DEFINER es muy útil para crear procedimien-

tos de administración, ya que nos permite crear los procedimientos con un usuario
administrador (de forma que puede acceder a cualquier tabla del diccionario de datos
y ejecutar prácticamente cualquier sentencia sobre cualquier objeto), dar permisos de
ejecución del procedimiento al resto de usuarios, y los usuarios podrían realizar las
tareas que se llevan a cabo en el procedimiento sin tener que darles acceso a tablas
restringidas del diccionario de datos o permisos para realizar operaciones que no les
corresponden.
– <param1>, <param2>, …: son los parámetros del procedimiento. Los parámetros con-
tienen valores que se pueden especificar en el momento de llamar al procedimiento, lo
que permite ejecutar el mismo código empleando valores diferentes de cada vez. Si se
quieren ejecutar tareas muy similares sobre distintos objetos, o con ciertas condiciones
cambiantes, en lugar de crear varios procedimientos es conveniente crear un solo pro-
cedimiento y parametrizarlo, de forma que en función de los parámetros que se pasen
al procedimiento se realicen las tareas de un modo u otro. Los parámetros pueden ser de
Capítulo 6
entrada (se utilizan para pasar valores al procedimiento. Serán de este tipo por defecto,
si no se indica otra cosa), de salida (se utilizan para devolver valores desde el procedi-
miento, como mensajes de error) o de entrada/salida (permiten pasar un valor al pro-
cedimiento y modificar su valor dentro del procedimiento para generar un valor diferente
de salida).
– <variables>: en los procedimientos se pueden crear variables para almacenar valores
temporales, pero estas variables solo pueden ser usadas en el código interno del proce-
dimiento.
– <CÓDIGO PL/SQL>: es el código que se ejecutará cuando se invoque el procedi-
miento. En este código será donde se hará uso de las variables declaradas así como de
los parámetros.
Los procedimientos se ejecutan por medio de las sentencias: exec, execute o call:

execute <procedimiento>(<param1>, <param2>,…);
Ejemplo
Podríamos crear un procedimiento que actualice el sueldo de un empleado de la siguiente

manera:
CREATE PROCEDURE pr_actualiza_sueldo (IN p_numemp number, IN p_sueldo number) IS

v_coddepto number(6);
BEGIN
– actualizamos el salario del empleado
UPDATE personal SET salario=p_sueldo WHERE numemp=p_numemp;
– guardamos en una variable el departamento al que pertenece el empleado
SELECT coddepto INTO v_coddepto FROM personal WHERE numemp=p_numemp;

/* si el salario que asignamos al empleado supera al máximo del departamento,
actualizamos el salario máximo del departamento, y usamos la variable para saber
cuál es el departamento al que pertenece el empleado */
UPDATE departamento SET salario_max=p_sueldo WHERE coddepto=v_coddep-
to and p_sueldo>salario_max;
END;
/
El uso de parámetros nos permite ejecutar el mismo código con distintos empleados y
distintos salarios. Para asignar el salario 3000 al empleado 6, invocaríamos al procedimiento
asignando esos valores a los parámetros de entrada:
execute pr_actualiza_sueldo(6, 3000);
Para asignar el salario 2800 al empleado 12:
execute pr_actualiza_sueldo(12,2800);
Capítulo 6
6.3.3. Funciones
Las funciones solo pueden recibir parámetros de entrada, y siempre devuelven un único valor.
Las funciones se pueden utilizar en cualquier contexto igual que los valores que devuelven:
si una función devuelve un varchar2, se podrá usar la función en cualquier lugar en que se
pueda usar un varchar2: para asignar valores a una variable, para devolver valores en una se-
lect, etc.
La sintaxis para la declaración de funciones en Oracle es la siguiente:
FUNCTION <función> (<parámetros>)

RETURN <tipo de datos>
[AUTHID INVOKER|DEFINER]
IS
<variables>
BEGIN
<CODIGO PL/SQL>
RETURN <valor devuelto>;
END;
Donde:
– <función>: Es el nombre con el que se podrá identificar a la función.

– <parámetros>: Los parámetros que usará la función como datos de entrada.
– <tipo de datos>: Es el tipo de datos que devolverá la función.
– <variables>: Variables que necesitemos para realizar operaciones en la función. Estas
variables serán de uso exclusivo de la función.
– <CODIGO PL/SQL>: Código PL/SQL que ejecutará la función cada vez que sea
llamada.
– RETURN <valor devuelto>: La función siempre tiene que devolver un valor. Para
devolver un valor concreto usamos la cláusula RETURN, que se puede utilizar en
cualquier lugar del bloque de código PL/SQL.
El valor devuelto por una función se puede consultar incluyendo la función en el select de
una consulta cualquiera.
¿Sabías que...?
En Oracle existe una tabla de sistema llamada “dual” que permite ejecutar consultas
que no accedan a ninguna tabla de la base de datos, lo que es muy útil para compro-
bar el resultado de invocar una función:
Select sysdate from dual;

Select funcion(parámetro) from dual;
Capítulo 6
Ejemplo
Podríamos crear una función para consultar cuantas asignaturas aprobó un alumno concreto
que se pase como parámetro:
CREATE OR REPLACE FUNCTION aprobadas(p_dni varchar2(9)) RETURN number IS

v_aprobadas number;
BEGIN
SELECT COUNT(*) INTO v_aprobadas
FROM cualificaciones
WHERE dni_alumno = p_dni AND nota >= 5;
RETURN v_aprobadas;
END;
/
Podríamos usar la función en una consulta sobre la tabla alumnos para que en el propio
resultado nos indique cuántas asignaturas aprobó cada alumno:
SELECT al.*, aprobadas(al.dni) AS ‘Aprobadas’ FROM Alumno al;
6.3.4. Disparadores
Los disparadores o triggers son rutinas que se ejecutan automáticamente cuando se produce un
evento sobre una tabla. Este evento puede ser una inserción, una eliminación o una actualiza-
ción de los datos de la tabla. La sintaxis para definir un trigger en Oracle es la siguiente:
CREATE OR REPLACE TRIGGER <disparador>

(BEFORE | AFTER | INSTEAD OF)
(INSERT | DELETE | UPDATE | UPDATE OF columna1[, columna2, …] )
ON nombreTabla
[REFERENCING
[OLD [AS] aliasFila ]
[NEW [AS] aliasFila ]
]
[FOR EACH ROW | STATEMENT ]
[WHEN condición]
[BEGIN]
sentenciasSQL
[END];
Donde:
– <disparador> será el nombre que asignemos al trigger.
Capítulo 6
– BEFORE | AFTER | INSTEAD OF indican cuándo se ejecutará el disparador, antes

o después de que se realicen los cambios sobre los datos o INSTEAD OF, que hará que
el disparador se ejecute en lugar de la acción que lo desencadena.
– OLD y NEW permiten hacer referencia a los valores anteriores (OLD) y nuevos
(NEW) de la fila que se modifica. OLD se podrá usar en los disparadores cuya acción
desencadenante sea un delete o un update (para acceder a los valores de la fila antes de
ejecutar el delete o el update), y NEW se podrá utilizar cuando la acción desencade-
nante sea un insert o un update (para acceder a los valores nuevos que se están asignan-
do a la fila).
– FOR EACH ROW y FOR EACH STATEMENT permiten especificar si el código
del disparador se ejecutará una única vez por cada sentencia INSERT, UPDATE o
DELETE que tenga lugar sobre la tabla (FOR EACH STATEMENT, que es el valor
por defecto si no se especifica), o una vez por cada fila que sea insertada, actualizada o
eliminada (FOR EACH ROW).
– La cláusula WHEN, que es opcional, permite especificar condiciones que deben cum-
plir los datos para que se ejecute el disparador.
Ejemplo
El siguiente ejemplo muestra un disparador que se ejecutará cada vez que se modifique el
campo salario de la tabla personal, para registrar en una tabla de log todos los cambios de
salario que se hayan producido.
CREATE TRIGGER log_sueldo BEFORE UPDATE OF salario ON empleado

FOR EACH ROW
BEGIN
INSERT INTO cambios_sueldo (usuario, codemp,salario_anterior, salario_nuevo)
VALUES (CURRENT_USER, :new.codemp,:old.salario, :new.salario);
END;
/
Aunque en este libro nos centraremos especialmente en la definición de procedimientos orientados

a realizar tareas de administración del sistema gestor, en el recurso digital Procedimientos de
base de datos se proponen varios ejercicios de creación de funciones, procedimientos y triggers
que podrás emplear para repasar la creación de rutinas internas en el sistema gestor.
6.3.5. Estructuras de programación

Todas las rutinas internas (tanto procedimientos como funciones y triggers) permiten utilizar
distintas estructuras y componentes para realizar distintas operaciones.
Capítulo 6
A) Comentarios
Existen dos tipos de comentarios en Oracle:
● Comentarios en una línea: se indican precedidos por un guión doble (--) y solo pueden
ocupar una línea.
● Comentarios de varias líneas: se indican entre /* y */ y pueden ocupar tantas líneas
como sea necesario.
B) Variables
Las variables permiten almacenar valores temporalmente dentro de un procedimiento. Si
queremos consultar un dato para usarlo posteriormente, tendremos que usar una variable para
guardar el valor que devuelve la consulta, y esa variable podrá ser usada en cualquier lugar del
procedimiento para consultar su valor.
Los procedimientos, funciones y disparadores contienen una zona específica para la decla-
ración de variables en su sintaxis: justo tras el create y antes del begin.
Para asignar valor a una variable se puede utilizar el operador “:=” (no confundir con el
“=”, que se utiliza solo para comparaciones) o se puede asignar el valor devuelto por una con-
sulta, utilizando la palabra clave into.
v_nombre:= ' ';

Select nombre into v_nombre from empleados where id=5;
En la propia declaración de la variable, se le puede asignar un valor inicial:
v_numero number(12) := 0;
Una variable puede ser de cualquier tipo simple de los manejados por Oracle (varchar2,
number, integer…), o de varios tipos complejos (tabla, matriz o cursor). Para facilitar la asig-
nación de tipos a variables, se pueden utilizar las palabras clave “TYPE” y “ROWTYPE”, de
forma que podemos asignar a una variable el tipo que tenga cualquier tabla o columna de la
base de datos de la siguiente manera:
CREATE OR REPLACE PROCEDURE …

v_nomemp personal.nombre%TYPE; /* asigna a la variable v_nomemp el
tipo de la columna nombre de la tabla emp.*/
v_emp personal%ROWTYPE; /* la variable v_emp es una fila, y sus campos
tendrán los mismos tipos de datos que los de la tabla personal */
BEGIN
v_emp.empno := 10;
v_emp.nombre := 'Rebeca';
v_nomen := 'Rodrigo';
END;
/
Capítulo 6
C) Ejecución condicional

En el cuerpo de las rutinas podemos hacer uso de las siguientes estructuras de control
de flujo:
● IF: permite ejecutar una sentencia cuando se cumple una condición y otra diferente
cuando no se cumple.
IF condición THEN sentencia;

[ELSIF condición THEN sentencia; ]
[ELSE sentencia; ]
END IF;
Ejemplo
Select count(*) into var_contador from articulos where idarticulo=3;

If var_contador>0 then
update precios_articulos set pvp=95 where idarticulo=3;
Else
insert into precios_articulos(idarticulo, pvp) values (3,95);
End if;
● CASE: la instrucción CASE tiene dos formas. Una de ellas permite ejecutar distintas
instrucciones para cada valor diferente que pueda tomar una variable o una expre-
sión. La otra permite comprobar distintas condiciones, y si se cumple alguna de ellas
ejecutar un conjunto de instrucciones determinado. Cuando se cumple una de las
condiciones especificadas en el when, no se siguen evaluando el resto de condiciones
del case.
CASE expresion CASE

WHEN valor1 THEN WHEN condicion1 THEN
Instrucciones1 Instrucciones1
[WHEN valor2 THEN [WHEN condicion2 THEN
Instrucciones2] Instrucciones2]
… …
[ELSE [ELSE
Instrucciones3] Instrucciones3]
END CASE; END CASE;
Capítulo 6
Ejemplo
CASE v_forma_pago CASE

WHEN ‘METALICO’ THEN WHEN v_edad<=12 THEN
V_comision:=0; V_rango:=’NIÑO’;
WHEN ‘TARJETA’ THEN WHEN v_edad<=30 THEN
v_comision:=0.03; v_rango:=’JOVEN’;
WHEN ‘TRANSFERENCIA’ THEN WHEN v_edad<=66 THEN
v_comision:=0.01; v_rango:=’ADULTO’;
ELSE ELSE
v_comision:=0.05; v_rango:=’PENSIONISTA’;
END CASE; END CASE;
D) Bucles
Existen varios tipos de bucles en Oracle, pero el más utilizado por su sencillez, especialmen-
te para recorrer cursores, es el bucle FOR.
● LOOP: las sentencias de dentro del bucle se ejecutarán durante un número indefinido
de vueltas, hasta que aparezca la instrucción EXIT, que finalizará el bucle. Este tipo de
bucle se denomina bucle incondicional.
LOOP
Sentencias
IF (expresion) THEN
Sentencias
EXIT;
END IF;
END LOOP;
● WHILE: el bucle while evalúa la condición de permanencia en el bucle antes de entrar

en él, de forma que si no se cumple la condición ya no se llegaría a entrar en el bucle.
También permite utilizar las instrucciones EXIT o EXIT WHEN para forzar la salida
del bucle sin esperar a que deje de cumplirse la condición de permanencia.
WHILE condicion LOOP

Sentencias
END LOOP;
● FOR: se ejecuta mientras una variable tome valores entre dos límites.
Capítulo 6
FOR <contador> IN [REVERSE] limite_inferior..limite_superior LOOP

sentencias
END LOOP;
La variable <contador> deberá ser una variable numérica que sea capaz de contener los
valores comprendidos entre limite_inferior y limite_superior, los cuales deberán ser expresiones
numéricas (pueden ser funciones que devuelvan números). La variable contador no es necesario
definirla previamente: Oracle definirá una variable de tipo INTEGER al iniciar el bucle, y la
liberará al finalizar el bucle.
Ejemplo
El siguiente código mostrará por pantalla los números entre 1 y 10:
SET SERVEROUTPUT ON; -- habilitamos la salida por pantalla

BEGIN
FOR v_contador IN 1..10 LOOP
DBMS_OUTPUT.PUT_LINE(‘Número: ‘ || TO_CHAR(v_contador));
END LOOP;
END;
El bucle FOR se suele utilizar también con cursores para ejecutar el bucle tantas veces
como filas contenta el cursor. En este caso la variable “contador” será del tipo que devuelva la
sentencia del cursor, y sus límites inferior y superior serán la primera y última fila del cursor.
Ejemplo
Cursor c_articulos is select idarticulo from articulos where iva=16;
…
FOR datos in c_articulos LOOP
Update articulos set iva=21, pvp=pvp/1.16*1.21 where idarticulo=datos.idarticulo;
END LOOP;
E) Bloques de instrucciones

Las palabras clave BEGIN y END permiten crear bloques de instrucciones, de forma que
todo lo que esté incluido en un bloque se tratará como una sola instrucción.
Esto es especialmente útil en las sentencias condicionales y bucles, ya que permiten ejecutar
varias sentencias cuando se cumple una condición:
Capítulo 6
Ejemplo
IF (v_fecha>sysdate) THEN
BEGIN
Update salidas set fecha=sysdate where fecha=v_fecha;
Delete from salidas where fecha>sysdate;
END;
END IF;
F) Cursores
Los cursores son un tipo especial de variables que permite almacenar los valores devueltos
por una consulta, para poder utilizarlos en otra operación.
Los cursores existen en varios sistemas gestores, pero Oracle es el que mejor rendimiento
obtiene de ellos, ya que su forma de gestionar la memoria es óptima para tratar este tipo de es-
tructuras (en SQL Server por ejemplo dan muchos problemas y en muchos casos recomiendan
directamente no usarlos).
Los cursores se definen en la zona de definición de variables, por medio de la siguiente
sintaxis:
CURSOR nombre_cursor(par1 tipo1, par2 tipo2, …) IS SELECT …;
Permiten indicar parámetros que se utilizarán en la consulta, de forma que se puede ejecu-
tar varias veces un mismo cursor desde el código PL/SQL pasándole distintos parámetros en
cada ocasión.
Si el cursor devuelve un solo valor, se puede asignar este valor a una variable directamente
con la sintaxis:
OPEN nombre_cursor(par1,par2);
FETCH nombre_cursor INTO v_aux;
CLOSE nombre_cursor;
Ten en cuenta
Es importante recordar cerrar siempre los cursores, ya que cuando se abre un cursor,
se ejecuta la consulta que lleva asociada y guarda en una tabla temporal en memoria
el resultado de dicha consulta. Esa memoria no se libera hasta que se cierra el cursor
o finaliza el procedimiento, por lo que si un procedimiento tiene muchos cursores y
estos no se cierran podría generarse un error por desbordamiento de memoria.
Si el cursor devuelve muchos valores no podemos volcar el resultado en una variable sim-
ple, sino que tendremos que utilizar un bucle que procese cada una de las filas devueltas:
Capítulo 6
FOR datos IN nombre_cursor(par1,par2) LOOP

BEGIN
UPDATE personal SET nombre= datos.nombre, coddepto=datos.coddepto
where codemp=datos.codemp;
END LOOP;
La ventaja de esta solución es que no tenemos que preocuparnos de cerrar los cursores: el
cursor se cierra solo al salir del bucle FOR.
G) Gestión de transacciones

La ejecución de cualquier sentencia que no sea una consulta da lugar al inicio de una tran-
sacción en Oracle. Lo mismo ocurre cuando ejecutamos una rutina: al iniciar el código se inicia
la transacción. Dentro de la rutina se pueden utilizar las funciones commit y rollback si quere-
mos ir haciendo persistentes algunas de las operaciones que vamos realizando o si encontramos
un error y queremos deshacer las operaciones realizadas respectivamente.
¿Sabías que...?
Si se ejecuta un update sobre todos los registros de una tabla que tenga muchos millo-
nes de registros, es fácil que la operación falle debido a que saturará el tablespace de
UNDO (no será capaz de registrar todas las operaciones que tendría que realizar para
deshacer el cambio de tantos millones de registros). En su lugar, se podría crear un
procedimiento que vaya actualizando registro a registro (o mejor, partición a partición,
si es posible) y que vaya haciendo commit cada cierto tiempo para evitar saturar el
tablespace de UNDO.
Los procedimientos no incluyen por defecto un “commit”, por lo que es importante acor-
darse de ejecutar un commit tras la ejecución de un procedimiento si queremos que los cam-
bios realizados por este pasen a ser persistentes sobre la base de datos.
H) Captura de excepciones

Una excepción es un error producido durante la ejecución de una rutina (una división
entre cero, una consulta que no devuelve datos, una operación con un valor null…). Los mane-
jadores de excepciones permiten dar respuesta a este tipo de errores indicando el código que se
debe ejecutar cuando se produzca un error determinado.
Los manejadores de excepciones se pueden incluir en cualquier bloque de instrucciones.
Al definir un manejador se debe indicar qué error es el que lo activa, y si se produce ese error
dentro del bloque de instrucciones en el que se ha definido el manejador, se ejecutaría el código
incluido en este.
Capítulo 6
La sintaxis para definir un manejador de excepciones en un bloque de instrucciones es:
BEGIN
EXCEPTION WHEN <error> THEN
END;
Los manejadores de excepciones pueden definirse de forma que capturen un solo tipo de
incidencia…
EXCEPTION WHEN DIVISION BY ZERO THEN …
… o para que capturen cualquier incidencia que se produzca:
EXCEPTION WHEN OTHERS THEN …
Dentro de un bloque de captura de excepciones se puede acceder al número de excepción

producida y al mensaje que se lanzará, utilizando las palabras claves SQLCODE y SQLERRM.
Podemos generar también nuestras propias excepciones dentro de una rutina de Oracle
utilizando la función “RAISE_APLICATION_ERROR”, que abortaría la rutina en cuestión
y generaría el error que le indiquemos:
BEGIN
SELECT 1/0 FROM DUAL;
EXCEPTION WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE(‘Se ha producido el error ‘||SQLERRM);
RAISE_APPLICATION_ERROR(SQLCODE, SQLERRM);
END;
6.3.6. Llamadas a funciones y procedimientos
Desde cualquier rutina interna de Oracle (incluso desde un bloque de instrucciones) se puede
llamar a cualquier otra función o procedimiento invocándolo directamente como una instruc-
ción más (sin necesidad de incluir call, exec o execute).
Del mismo modo, se pueden utilizar las funciones o procedimientos incluidos en paquetes
del diccionario de datos, precediendo el nombre del procedimiento o función del nombre del
paquete al que pertenece.
Ten en cuenta
Oracle por defecto deshabilita la salida por pantalla, por lo que si quieres invocar el procedimiento
“dbms_output.put_line” desde un programa tendrás que habilitarla previamente para poder ver los
mensajes mostrados en la pantalla, ejecutando la sentencia: SET SERVEROUTPUT ON.
Capítulo 6
Ejemplo
create or replace procedure muestra_fecha() is

v_fecha varchar2(10);
begin
select to_char(sysdate,’dd-mm-yyyy’) into v_fecha from dual;
dbms_output.put_line(‘La fecha actual es ‘||v_fecha);
end;
/
Para practicar la creación de rutinas internas de administración en Oracle, accede al

recurso digital Procedimientos de administración. En esta relación de ejercicios
se proponen distintas tareas de administración del sistema gestor que pueden ser eje-
cutadas por medio de procedimientos almacenados.
6.4. Automatización de tareas
La automatización de tareas nos permite llevar a cabo tareas repetitivas con poco esfuerzo y
de forma sencilla. En un sistema gestor existen dos tipos de tareas que suele ser conveniente
automatizar:
a) Tareas de base de datos: orientadas a realizar tareas que afectan a los datos de un esquema.
Este tipo de tareas las programa el diseñador de la base de datos por medio de triggers,
funciones o procedimientos, y normalmente implementan reglas de negocio (un pro-
cedimiento para dar de alta empleados que automáticamente los inserte también como
usuarios del sistema, un trigger que se ejecute al borrar un producto que lo guarde en
una tabla de histórico, etc.).
b) Tareas de administración: orientadas al mantenimiento del sistema gestor y de las bases
de datos. Son tareas definidas por el DBA por medio de un procedimiento, que tienen
como objetivo facilitar el mantenimiento de los objetos de las bases de datos y de las
propias bases de datos, y normalmente se automatiza su ejecución (es decir, no hay un
evento que las dispare, sino que se programan para ejecutarse en determinado momen-
to). Para ofrecer esta funcionalidad, los sistemas gestores necesitarán un mecanismo que
permita programar las tareas (registrar en algún lugar, normalmente en el diccionario
de datos, las tareas pendientes de ejecutar y en qué momento se debe ejecutar cada
una de ellas), y un agente que se encarga de conectarse al sistema gestor, consultar si hay
tareas pendientes de ejecución, y si es así se encarga de lanzarlas. Estos agentes se suelen
implementar por medio de un servicio del sistema operativo independiente del sistema
gestor, aunque no siempre es así.
Capítulo 6
6.4.1. Tareas de administración automatizables
A la hora de llevar a cabo la explotación de un sistema gestor, se darán muchas problemáticas

que pueden ser resueltas programando procedimientos de administración que se encarguen de
buscar estos objetos problemáticos y ejecutar las sentencias necesarias para solucionarlos.
Tal como se comentó en el capítulo referente a la monitorización y optimización del
sistema gestor, muchas veces el propio sistema gestor ya dispone de mecanismos que lleven a
cabo este tipo de tareas (como la actualización de estadísticas o el incremento automático de
espacio en los tablespaces), pero el problema de estos mecanismos es que no son controlables,
y se pueden ejecutar en cualquier momento, lo cual puede ser contraproducente. En caso de
deshabilitarlos, habría que implementar manualmente esa funcionalidad, programándola de for-
ma que estas comprobaciones y correcciones se realicen en horario de baja carga del sistema.
Habitualmente, los procedimientos de administración suelen tener la siguiente estructura:
1. Un cursor busca por medio de una consulta sobre el diccionario de datos los objetos
que puedan presentar una problemática concreta.
Ten en cuenta
Oracle almacena toda la información del diccionario de datos en mayúsculas (nombres de

tablas, de columnas, de esquemas, índices, etc.). Si un procedimiento recibe como parámetro
el nombre de un objeto de base de datos y tiene que buscar información acerca de él en el
diccionario de datos, es conveniente usar siempre la función “upper” para pasar el nombre
del objeto a mayúsculas, ya que cuando se invoque el procedimiento puede suceder que el
parámetro se indique en minúsculas.
Por ejemplo, para buscar las tablas de un esquema que se pase como parámetro, se podría
utilizar el siguiente cursor:
Cursor c_tablas is select table_name from all_tables where owner=upper(par_esquema);
2. Por medio de un bucle se recorre el cursor, y para cada objeto devuelto por el mismo
se ejecuta una sentencia que solucione el problema.
Recuerda
3 Por lo general, las sentencias necesarias para solucionar estos problemas serán senten-
cias del DDL, que no se pueden ejecutar directamente dentro de un procedimiento, sino
que habrá que ejecutarlas dentro de una sentencia “execute immediate”.
Por ejemplo, para desfragmentar una tabla que se pase como parámetro dentro de
un procedimiento tendríamos que usar:
execute immediate (‘alter table ‘||par_tabla||’ move’);
Algunas de las principales tareas de administración de la base de datos (habrá muchas más
tareas que se puedan automatizar a nivel de sistema operativo: comprobación de espacio, purgado
de logs, etc.) que se pueden automatizar por parte del DBA son las que se indican a continuación.
Capítulo 6
6.4.2. Copias de seguridad
Las copias de seguridad de la base de datos son seguramente las tareas más susceptibles de ser
automatizadas, aunque normalmente esta tarea se suele delegar en el sistema operativo, ya que
aunque hay sistemas gestores que permiten realizar las copias de seguridad empleando proce-
dimientos del propio sistema gestor de base de datos, lo más habitual es que esta tarea se lleve a
cabo por medio de aplicaciones que deben ser invocadas desde el sistema operativo.
6.4.3. Particionamiento
El particionamiento permite dividir una tabla grande en “subtablas” que pueden ser tratadas
por separado.
Esto implica varias ventajas:
● Optimiza el acceso a la tabla: si tenemos una tabla con varios millones de filas de datos
históricos de ventas, lo habitual es que se consulten o modifiquen los datos del último
mes o año, pero cada vez que se lance una consulta, esta recorrerá los datos de toda
la tabla, con lo que ello implica. Si se particiona la tabla por mes o año, la mayoría de
consultas se ejecutarán sobre la partición actual, por lo que el número de registros que
debe recorrer decrece considerablemente.
● Optimiza las tareas de administración: lo habitual es que los cambios en una tabla muy
grande se concentren en un conjunto concreto de datos (los correspondientes al últi-
mo mes, año, etc.). Si tenemos que realizar cualquier operación de administración que
afecte solamente a esos datos (mover a un disco más lento, comprimirla, reconstruir los
índices, lanzar las estadísticas, etc.), es mucho más rápido hacerlo solo sobre la partición
que los contiene que no sobre la tabla completa.
● Facilita el purgado de datos: si una organización tiene una política que establece que
únicamente se mantendrán en la tabla los datos de los últimos X años y se particiona la
tabla por mes o año, para realizar las tareas de purgado únicamente será necesario pasar
a disco las particiones del año a purgar y borrar la partición correspondiente en la tabla.
● Facilita el mantenimiento: si hago un update sobre todos los registros de una tabla, lo
que hace internamente el sistema es crear una tabla nueva en el tablespace temporal con
los cambios que estoy realizando, y cuando acaba de crear la tabla temporal, la reemplaza
por la tabla en la que estoy haciendo los cambios. Si queremos hacer una modificación
sobre todos los datos de una tabla muy grande, probablemente sature el temporal, por
lo que no nos dejará realizar la modificación. Si lo hago partición a partición, es más
rápido y no colapsa el temporal.
● Permite la realización de operaciones de optimización avanzadas como el intercambio
de particiones.
¿Sabías que...?
Una tabla se particiona siempre por un campo de la tabla, definiendo los rangos de valores que
pertenecen a cada partición, por lo que el campo de particionamiento debe ser numérico (ente-
ro) o de tipo fecha (date o timestamp), y deben emplearse campos con restricción NOT NULL.
Capítulo 6
Particionamiento por Particionamiento por

fecha (feccompra) número (idalmacen)
COMPRAS STOCK_ARTICULOS
idcompra feccompra idproveedor … fecrecepcion idalmacen idarticulo Stock
1 01/01/20 1 04/01/20 1 1 4
2 01/01/20 2 04/01/20 2 1 5
3 01/01/20 3 05/01/20 4 1 6
… 1 2 4
5000 02/01/20 1 04/01/20 3 2 4
5001 02/01/20 1 06/01/20 3 3 5
… 4 2 6
12101 03/01/20 2 null 4 3 12
12102 03/01/20 3 07/01/20 1 2 0
… 2 5 9
En términos generales, podemos hablar de dos formas de particionar una tabla:
– Con particiones fijas: las particiones existentes se especifican cuando se crea la tabla y
estas no varían: si en una empresa con varias sedes se quiere particionar la tabla de ventas
por código de sede, siempre que no se añadan sedes nuevas las particiones en que se
dividirá la tabla serán fijas y no será necesario crear particiones regularmente.
– Con particiones variables: este tipo de particionamiento se suele dar cuando la par-
tición es por fechas. A medida que transcurre el tiempo y se van añadiendo nuevos
registros a la tabla, será necesario crear nuevas particiones para almacenar los registros
que corresponden a nuevos días, meses, años, etc. En este tipo de particiones es
en las que resulta más adecuado crear las particiones de forma automática al entrar en
la nueva fecha (con un procedimiento que se ejecute diariamente a las 00:00, por
ejemplo).
Las nuevas versiones de Oracle disponen de mecanismos para gestionar el particionado de

forma automática, pero lo habitual es que la creación de una nueva partición venga acompañada
de acciones adicionales sobre la partición anterior: comprimirla, moverla a un tablespace que
esté en un disco más lento (ya que se va a acceder menos), purgar particiones antiguas, etc.
Por este motivo puede ser interesante gestionar el particionamiento de forma personalizada por
medio de procedimientos almacenados que se programarán para que realicen las operaciones
que sean necesarias.
Hay varias operaciones relacionadas con el particionamiento que puede ser conveniente
automatizar:
1. Creación de particiones: cuando se crea una tabla con particiones variables, en la sentencia
de creación de la tabla se especifican las particiones que contendrá inicialmente, y todas
Capítulo 6
las que no encajen en ninguno de los rangos definidos inicialmente se almacenarán en

una partición “final”.
Fecha Partición
01/2021 P_202101
02/2021 P_202102
03/2021 P_202103
04/2021 P_FINAL
…
Para que el particionamiento sea realmente efectivo, cada mes se debería crear una
nueva partición para almacenar los registros correspondientes a ese mes. Esto se hace
dividiendo la partición final en una partición correspondiente al nuevo mes y otra
partición final:
alter table [nb_tabla] split partition P_FINAL at (to_date(‘01/05/2021’,’dd/

mm/yyyy’)) into (PARTITION P_202104 TABLESPACE [nb_tablespace], PARTITION
P_FINAL TABLESPACE [nb_tablespace]);
Fecha Partición
01/2021 P_202101
02/2021 P_202102
03/2021 P_202103
04/2021 P_202104
05/2021 P_FINAL
…
2. Compresión de particiones: en tablas muy grandes puede ser adecuado comprimir las par-
ticiones antiguas, ya que no solo se reduce el espacio que ocupan sino que además me-
jora su rendimiento. La compresión es una herramienta que debe usarse con cuidado,
ya que si bien se optimizan las consultas sobre la tabla, se penalizan las modificaciones
y borrados, por lo que conviene utilizarla únicamente cuando sabemos que los datos ya
insertados no van a cambiar. Además, hay que tener cuidado con los índices, ya que al
comprimir una tabla o partición, los índices quedan en estado “unusable”. Si una tabla
se particiona cada día o cada mes, cada vez que se crea una partición nueva se podría
automatizar también la compresión de la última partición existente.
3. Reconstrucción de índices: si se comprimen particiones, los índices de esas particiones
quedan en un estado no válido y es necesario reconstruirlos, por lo que se puede auto-
matizar también esta tarea como parte del proceso de particionamiento.
Capítulo 6
4. Cambio de ubicación de particiones: si por cuestiones de optimización de recursos se decide

mantener la partición en curso en un sistema de almacenamiento muy caro y mover las
particiones antiguas a un almacenamiento más barato.
6.4.4. Ejecución de estadísticas

En las tablas cuyo contenido varía a menudo, es importante mantener actualizadas las estadís-
ticas, ya que de esta manera nos aseguramos de que el optimizador elija siempre el mejor plan
posible para ejecutar las consultas. Cuando actualizamos las estadísticas, los planes almacenados
en la caché de planes dejan de ser válidos, por lo que creará planes nuevos cuando ejecutemos
consultas sobre la tabla.
Por defecto, lo habitual es que los sistemas gestores se encarguen de actualizar las estadísticas
automáticamente. Esto libera de trabajo al administrador, pero no siempre es una buena idea: la
ejecución de las estadísticas bloquea la tabla, y si las tablas son muy grandes (en las que actualizar
las estadísticas puede llevar mucho tiempo) y se delega esta tarea en el sistema gestor, puede
provocar un bloqueo de la tabla en un momento inoportuno.
Toma nota
Para evitar el bloqueo es conveniente programar la actualización de estadísticas para que se eje-
cute en un horario de mínima carga, de modo que se garantiza que se mantengan actualizadas
y esto no provoque problemas a la hora de explotar la información por parte de los usuarios.
6.4.5. Desfragmentación
La operación diaria con las tablas de la base de datos (modificaciones y borrados, especialmente)
produce en muchas ocasiones fragmentación en las tablas. Que una tabla esté fragmentada im-
plica no solo que esté ocupando más espacio del necesario, sino que cuando se lanza una con-
sulta que tiene que recorrer dicha tabla, la consulta tendrá que leer de disco todos los registros
de la tabla, estén vacíos o no, lo que supone una degradación del rendimiento de las consultas.
Es posible automatizar la compactación de las tablas para evitar que se produzcan estas situa-
ciones por medio de un procedimiento que busque en el diccionario de datos tablas o índices
que tengan espacios internos inutilizados y los compacten.
Existen dos problemas fundamentalmente relacionados con estos espacios internos que se
pueden solucionar con una compactación:
● La fragmentación de las tablas: se produce debido a la operación cotidiana de eliminación

de registros de las tablas, que hace que aparezcan espacios no utilizados en los blo-
ques de datos.
● Filas segmentadas en varios bloques: este problema se produce cuando se modifica una fila
de una tabla, y debido a la modificación realizada esta no cabe en el espacio que tenía
reservado (por ejemplo si a un valor de tipo varchar2 le asignamos un valor más grande
del que tenía inicialmente). En este caso las filas se dividen y se guardan en distintas
zonas de disco, de modo en su ubicación inicial quedan espacios libres y cada acceso a
esa fila implica dos lecturas en disco.
Capítulo 6
La solución para ambos problemas es la compactación de la tabla:
alter table <tabla> move;
6.4.6. Reconstrucción de índices

Hay ciertas operaciones (al comprimir una tabla, al cambiarla de tablespace, etc.) que dejan los
índices en un estado inválido, lo que hace que el planificador no los tenga en cuenta a la hora
de resolver las consultas que se lanzan contra el sistema gestor. Además, un índice en estado
inválido puede provocar errores imprevistos en la base de datos (errores al lanzar las estadísticas,
pueden fallar también operaciones de inserción o modificación de datos en las tablas, etc.), por
lo que es conveniente mantenerlos en buen estado no solo por el rendimiento de las consultas
sino también para prevenir errores incontrolados.
Los índices son objetos que se almacenan en el diccionario de datos, con lo cual se puede
implementar un procedimiento que busque en el diccionario de datos los índices que estén en
estado “invalido”, los almacene en un cursor y recorra dicho cursor ejecutando las sentencias
necesarias para reconstruir los índices uno a uno.
alter index <índice> rebuild;
6.4.7. Purgado y paso a histórico

Cuando una tabla contiene muchas filas supone un gran problema para la base de datos, ya que
muchas operaciones accederán a toda la tabla, lo que no solo ralentiza el acceso a esa tabla, sino
que además la pueden bloquear de modo que afectaría a todas las consultas que se lanzasen
contra esa tabla.
Además, normalmente las tablas que incrementan mucho su tamaño son las tablas de ope-
raciones (ventas, compras, etc.), que son críticas para el sistema y normalmente se almacenan en
los mejores discos, y con sistemas de redundancia (tipo RAID) para asegurar que no se pierda
la información. Estos discos son muy caros, por lo que puede no ser aconsejable mantener en
estas unidades tanta información.
Una solución a este problema era el particionamiento de la tabla, de modo que en lugar de
trabajar con la tabla completa trabajábamos con partes de la misma.
Otra opción es utilizar un histórico, de modo que periódicamente se pasaría la información
antigua a otra tabla y otro disco de menor rendimiento, de forma que solucionamos el proble-
ma del coste de disco y del número muy elevado de registros en la tabla: si se consultan datos
actuales (lo más habitual) el acceso será rápido, porque en nuestra tabla de movimientos queda
un número de filas asumible, y si consultamos información histórica (menos habitual y menos
crítico) entonces habría que acceder al histórico y tardaría más.
Habitualmente, en las organizaciones, la información se guarda en el histórico unos años,
pero, pasado un tiempo, esa información pierde valor, por lo que se suele incluso pasar a disco y
borrar del histórico. Si se quiere recuperar bastaría con importarla desde el disco, y de esta ma-
nera se evita guardar en la base de datos información innecesaria y se optimiza la base de datos.
Capítulo 6
Recuerda
3 Tanto las operaciones de purgado como de paso a histórico pueden ser automatizadas
por medio de un procedimiento programado para que se ejecute regularmente (a princi-
pios de año normalmente) que se encargue de volcar al histórico la información del año
anterior y de purgar la que tenga una antigüedad determinada.
6.5. Automatización de tareas en Oracle

Para ejecutar tareas programadas en Oracle, disponemos de la opción de delegar la planificación
en el sistema operativo (de forma que, desde el planificador de tareas del sistema operativo, se
lanzarían procedimientos que se ejecutarían en el sistema gestor), pero también provee de su
propio programador de tareas, que permite gestionar todo el proceso internamente desde el
sistema gestor.
6.5.1. Herramientas del SO

El interfaz de comandos SQL Plus permite ejecutar scripts almacenados en archivos del sistema
operativo que contengan sentencias de bases de datos. Para ejecutar un script desde el SQL Plus,
habrá que indicar el nombre del archivo a ejecutar precedido por una “@”:
sqlplus usuario/password@servicio @script.sql > log.txt
La opción más sencilla para crear una tarea programada es crear un script, guardarlo en un
fichero y programarlo por medio del programador de tareas del sistema operativo.
El problema de esta opción es que para ejecutar el script es necesario indicar las credencia-
les del usuario que lo ejecutará, lo cual podría suponer un problema de seguridad, y que tiene
ciertas limitaciones en cuanto a las sentencias que se pueden ejecutar.
6.5.2. DBMS Scheduler

Oracle siempre incluyó un planificador de tareas (implementado a través del paquete DBMS_
JOB), pero a partir de la versión 10g incorporó un nuevo paquete más potente: DBMS_SCHE-
DULER. Por razones de compatibilidad con versiones anteriores, ambos planificadores con-
viven en las versiones posteriores a la 10g, pero se aconseja utilizar la implementación nueva
(DBMS_SCHEDULER).
Este paquete contiene los procedimientos necesarios para programar tareas individuales, a las
que denomina “jobs” o trabajos, o grupos de tareas, a las que denomina “chains” o cadenas. Un
job puede ser una simple sentencia SQL, un bloque PL/SQL, un procedimiento almacenado
(ya sea PL/SQL o Java) o incluso un programa ejecutable externo a la base de datos. Las tareas
se crean mediante el procedimiento CREATE_JOB, y las cadenas con CREATE_CHAIN.
Capítulo 6
Para crear un job que programe la ejecución de un procedimiento, cuando el procedimien-

to no tiene parámetros la programación es muy sencilla, pero si tiene parámetros es un poco
más compleja, ya que no se puede indicar el valor de los parámetros en la propia sentencia de
creación del job, sino que será necesario seguir tres pasos:
1. Ejecutar el procedimiento “create_job” del paquete “DBMS_SCHEDULER” para

programar la tarea, indicando el número de argumentos que tendrá (por medio del pa-
rámetor “number_of_arguments”) y asignándole un estado “disabled” o deshabilitado.
2. Para cada parámetro, será necesario ejecutar el procedimiento “set_job_argument_va-
lue” incluido también en el paquete “DBMS_SCHEDULER” indicando en qué orden
irá el parámetro y cuál será su valor.
3. Una vez que ya están especificados los valores de todos los parámetros, habrá que ha-
bilitar la programación de la tarea usando el procedimiento “enable”, incluido también
en el mismo paquete, para cambiar su estado.
Ejemplo
BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name => ‹estadisticas’,
job_type => ‹STORED_PROCEDURE’,
job_action => ‹pr_actualiza_estadisticas’,
number_of_arguments => 2,
start_date => to_date(‘18-12-20 00.30.00’,’dd-mm-yy hh24.mi.ss’),
repeat_interval => ‘FREQ=DAILY’,
enabled => FALSE
);
DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE(‘estadisticas’,1,’ nominas’);
DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE(‘estadisticas’,2,’personal’);
DBMS_SCHEDULER.ENABLE(‘estadisticas’);
END;
/
En el caso de Oracle, la ejecución de las tareas programadas no se lleva a cabo por medio
de un servicio externo al sistema gestor, sino que uno de los grupos de procesos que contiene
la instancia de base de datos, el llamado “procesos de colas de trabajo” (job queue processes),
corresponde al planificador de tareas. Uno de los procesos de este grupo es el encargado de
coordinar la ejecución de las tareas programadas: consulta la tabla DBA_SCHEDULER_JOBS
y para cada tarea que deba ejecutar activa un proceso esclavo al que encarga ejecutar la tarea.
Accede al recurso digital Automatización de tareas, donde se proponen varios ejercicios con
los que se podrá practicar la programación de tareas sencillas en Oracle por medio de jobs.
Capítulo 6
Para que un usuario pueda programar tareas, debe tener dos permisos:
grant create job to <usuario>;

grant execute on dbms_scheduler to <usuario>;
Las cadenas son muy útiles para crear planes de mantenimiento: una secuencia de tareas de
mantenimiento que se ejecutan secuencialmente y siempre con la misma periodicidad. Un
plan de mantenimiento puede incluir tareas como la revisión de los índices, la actualización de
estadísticas, la ejecución de copias de seguridad, etc.
La forma más sencilla de crear una cadena en Oracle es por medio del SQL Developer,
que incluye una interfaz gráfica que permite crear de forma sencilla cada uno de los pasos de
la cadena y las reglas que determinan en qué condiciones se ejecutará cada uno de los pasos.
El recurso digital Automatización de tareas con SQL Developer contiene un tutorial donde
se muestra la forma de crear jobs (para programar tareas individuales) y cadenas (para crear pla-
nes de mantenimiento) empleando el interfaz gráfico del SQL Developer.
Resumen
n La automatización de tareas tiene por objetivo automatizar tareas que se ejecutan

de forma repetitiva y sistemática, de forma que se libera al DBA de estas tareas, se
ahorra tiempo, se reducen costes de administración y se reducen los errores en la
ejecución.
n Existen dos tipos de tareas automatizables: tareas de base de datos (manipulan la in-
formación en base a unas reglas de negocio definidas) y tareas de administración (rea-
lizan tareas de mantenimiento de los objetos de base de datos, sin afectar a los propios
datos). Estas tareas pueden automatizarse por medio de aplicaciones externas, scripts
del sistema operativo o rutinas internas del sistema gestor (procedimientos, triggers y
funciones).
n Las rutinas internas ofrecen un mayor rendimiento y seguridad, facilitan su reutiliza-
ción (es importante que estén correctamente documentadas) y permiten encapsular en
la propia base de datos las reglas de negocio, si bien suponen un consumo de recursos
extra del sistema gestor.
n Las tareas de administración automatizables suelen tener una estructura común: un
cursor obtiene por medio de una consulta en el diccionario de datos los objetos que
se van a manipular, y por medio de un bucle se recorre el cursor para solucionar los
problemas de dichos objetos.
Capítulo 6
n Las rutinas internas permiten llevar a cabo todo tipo de tareas de mantenimiento de
forma automática: gestionar el particionamiento de las tablas, realizar copias de segu-
ridad, mantener las estadísticas actualizadas, eliminar la fragmentación de los objetos
de base de datos, asegurar la corrección de los índices, llevar a cabo los procesos de
purgado y pase a histórico, etc.
1. Dado el siguiente trigger:
Create or replace trigger tg_personal before update of salario on personal

referencing old as ant
new as act
for each row
when (ant.comision > 0)
begin
rollback;
end;
a) ¿Cuándo se ejecuta?
b) ¿Qué es lo que hace?
c) Explica cómo podrías hacer para que se ejecute esta noche a las 23:30.
2. Define una función que reciba como parámetro el nombre de una tabla y devuelva el
nombre del esquema al que pertenece esa tabla. Ten en cuenta que:
a) Si hay varios esquemas que contienen una tabla con dicho nombre, la función
puede devolver cualquiera de ellos.
b) Si no existe la tabla, devolverá ‘tabla no encontrada’.
c) Cualquier usuario puede ejecutar la función, aunque no tenga permisos de acceso
a la tabla buscada.
d) La función se debe ejecutar siempre con los permisos del usuario administrador
que define la función.
3. Crea un procedimiento de administración de tu sistema gestor (llámalo PR_ADMIN)

que reciba dos parámetros: un nombre de esquema o base de datos, y la operación que
se ha de realizar sobre él, que podrá ser:
Capítulo 6
a) Si la operación es “INDICES” o “indices”, debe reconstruir todos los índices del

esquema indicado como parámetro.
b) Si la operación es “ESTADISTICAS” o “estadisticas”, debe actualizar las estadísti-
cas del esquema indicado como parámetro.
c) Si la operación es “COMPACTAR” o “compactar”, debe compactar las tablas del
esquema indicado como parámetro.
d) Si el parámetro tiene cualquier otro valor, mostrará un mensaje por pantalla indi-
cando cómo debe realizarse una llamada correcta al procedimiento.
Si no se ha indicado el parámetro correspondiente al nombre del esquema sobre

el que llevar a cabo la operación, el procedimiento debe finalizar con el mensaje de
error: “Es necesario indicar un esquema”.
En caso de que se produzca cualquier otro error durante la ejecución del procedi-
miento, este debe mostrar por pantalla el mensaje de error producido.
4. Programa el procedimiento anterior de la siguiente manera:
a) Todos los domingos a las 00:30 debe compactar las tablas del esquema “PROCE-
DIMIENTOS”.
b) Todos los domingos entre el 9 de junio y el 28 de julio, a las 01:30, debe recons-
truir los índices del esquema “PROCEDIMIENTOS”.
c) Todos los primeros de mes de 2020, a las 02:00, hasta el 31 de diciembre de
2030, debe actualizar las estadísticas del esquema “PROCEDIMIENTOS”.
5. Debido a una intervención planificada para el fin de semana, necesitamos deshabili-

tar todas las tareas programadas. Indica las sentencias necesarias para deshabilitar las
tres programaciones anteriores sin eliminarlas, ya que tras la intervención será nece-
sario activarlas de nuevo.
1. Si particionamos una tabla (señala la incorrecta):
a) Es más sencillo gestionar sus índices.
b) Facilita el purgado de datos y optimiza su administración.
c) Optimiza su acceso y su administración.
d) Permite realizar tareas de optimización avanzadas.
Capítulo 6
2. Una tabla no se puede particionar:

a) Por un campo de tipo number.
b) Por un campo de tipo date.
c) Por un campo de tipo timestamp.
d) Por un campo de tipo varchar2.
3. ¿Qué ocurre si inicio una transacción y no comito nunca?

a) Falla porque queda sin espacio en el redo log.
b) Falla porque queda sin espacio en el tablespace de UNDO.
c) El tablespace UNDO crecerá hasta quedar sin espacio.
d) No sucede nada.
4. Para dar permisos de ejecución en un procedimiento usamos:

a) grant execute.
b) grant call.
c) grant run.
d) grant exec.
5. No es una ventaja de los procedimientos almacenados:

a) Centralización de las reglas de negocio.
b) Reutilización.
c) Mejor gestión de los recursos del sistema.
d) Encapsulación.
6. ¿Cuál será el salario de los empleados tras la ejecución de este bloque de código?
begin
update empleados set salario=1000;
commit;
select 1/0 from dual; -- excepción
commit;
exception when others then
update empleados set salario=salario*1.5;
commit;
end;
a) 1000.
b) 1500.
c) 2000.
d) Se produce un error de ejecución.
7. Desde el sistema gestor Oracle pueden ejecutarse:

a) Procedimientos almacenados.
b) Programas en Java.
c) Triggers.
Capítulo 6
8. Si quiero ejecutar un “create table” dentro de un procedimiento en Oracle:

a) Lo ejecuto directamente.
b) Tengo que incluirlo dentro de begin ... end.
c) Tengo que añadir obligatoriamente un bloque exception.
d) Lo ejecuto con “execute immediate”.
9. ¿Cuál será el salario de los empleados tras la ejecución de este bloque de código?
begin
commit;
rollback;
end;
a) 1000.
b) 2000.
c) 3000.
d) Se produce un error de ejecución.
10. ¿Cuándo se ejecuta este código?

CREATE TRIGGER log_sueldo BEFORE UPDATE OF sueldo ON empleado
REFERENCING OLD as oldrow
NEW as newrow
FOR EACH ROW
WHEN sueldo<2000
INSERT INTO log_table
VALUES (CURRENT_USER, :oldrow.sueldo,:newrow.sueldo);
END;
/
a) Cuando se modifica el campo empleado de la tabla sueldo.
b) Cuando se insertan sueldos menores de 2000 euros.
c) Cuando se modifica un sueldo en la tabla empleado.
d) Ninguna de las respuestas anteriores es correcta.
SOLUCIONES:
a b c
1. a b c d
d 5.
2.
a b c d 6.
a b c d 9.
a b c d
a b c
3. a b c d 10.
d 7. a b c d
a b c
4. a b c d
d 8.
Capítulo 6
7
Alta disponibilidad
Objetivos
3 Comprender los beneficios que puede aportar la implementación de medi
das que incrementen la disponibilidad de los datos.
3 Conocer las alternativas existentes para incrementar la disponibilidad de la
información.
3 Evaluar las ventajas y desventajas de cada una de las opciones en base a sus
características.
Mapa conceptual
Tecnologías SGBDD
Clúster
Cloud
realiza Funciones
Puesta en marcha
Seguridad
Explotación
Administración Alta disponibilidad
Glosario
Base de datos distribuida (BDD). Conjunto de bases de datos lógicamente relacionadas

que están repartidas entre diferentes espacios lógicos y físicos conectados por una red.
Cloud computing. Computación en la nube. Consiste en el acceso a un sistema de infor
mación a través de una red, que suele ser internet.
Clúster de servidores. Conjunto de equipos unidos por medio de una conexión de alta
velocidad que operan conjuntamente como si fuesen un único equipo.
Dblink. Enlace de base de datos. Conectores que permiten acceder desde un sistema ges
tor de bases de datos a información almacenada en otro sistema gestor.
Capítulo 7
Alta disponibilidad 221
Fragmentación. Reparto de la información entre los distintos nodos que forman un siste
ma gestor de bases de datos distribuido, de forma que cada nodo dispondrá única
mente de una parte de los datos.
Nodo. Sistema de procesamiento autónomo que dispondrá de un repositorio de datos lo
cal y estará conectado a través de una red con otros nodos del sistema, de modo que
podrá gestionar su propia información y cooperar con el resto de nodos para manejar
información global.
Replicación. Consiste en duplicar la información entre los distintos nodos de un sistema
distribuido, de forma que cada nodo almacenará localmente toda la información re
plicada.
Sistema gestor de base de datos distribuidas (SGBDD). Software que gestiona una base
de datos distribuida, haciendo que la distribución de los datos sea transparente al
usuario.
Software as a service (SaaS). Modelo de negocio mediante el cual empresas del sector TIC
ofrecen servicios de computación en la nube (tanto almacenamiento como procesa
miento de la información).
7.1. Introducción
El SGBD es uno de los recursos más críticos de las organizaciones, ya que una caída del sistema
que impida el acceso a la información puede suponer serias dificultades para continuar con la
actividad productiva de la organización. Es por ello que la alta disponibilidad se convierte en
una característica clave del sistema gestor, por lo que será fundamental implementar medidas
orientadas a garantizar que los datos estén siempre accesibles, y en caso de fallo del sistema, que
sea posible recuperar su normal funcionamiento lo más rápidamente posible.
Existen diversas tecnologías o arquitecturas orientadas a garantizar la rápida recuperación
del sistema en caso de fallo. Las más habituales son las siguientes:
● Emplear un sistema gestor de bases de datos distribuidas (SGBDD).

● Implementar un clúster de servidores.
● Trabajar con un SGBD en la nube.
7.2. Sistemas gestores de bases de datos en la nube

Esta solución pasa por contratar el almacenamiento de datos como un servicio ofrecido por una
empresa especializada externa a la organización, que será la encargada de garantizar la seguridad,
disponibilidad, rendimiento y escalabilidad del sistema gestor.
Capítulo 7
A la hora de contratar el servicio de bases de datos en la nube existen dos soluciones

posibles:
1. Por medio de hardware dedicado: el cliente contrata un servidor dedicado (que será una
máquina virtual dedicada) con las características que se deseen. En caso de necesitar
mayor capacidad de procesamiento, memoria o cualquier otro recurso, sería muy sen-
cillo realizar el cambio.
2. Por medio de la contratación de servicios: en este caso lo que se contrata es un paquete que
garantiza una capacidad de almacenamiento, un número máximo de conexiones men-
suales o de transferencia de información, y estos servicios se ofrecen desde la infraes-
tructura del proveedor.
7.2.1. Características Proveedor
externo
La contratación del sistema gestor en la nube es
muy sencilla, ya que normalmente se realiza a tra-
vés de un formulario en el que se van seleccio-
nando las características que se desean: número de
réplicas, memoria disponible, capacidad de alma- Internet
cenamiento, posibilidad de disponer de réplicas
en ubicaciones remotas para prevención de desas-
tres, configuración de las copias de seguridad, etc.
A medida que se van seleccionando las distintas
características, se va recalculando el importe que
supondría mensualmente disponer de ese servicio. Clientes
Estos sistemas son muy flexibles y pueden Figura 7.1
modificarse de forma prácticamente instantánea Esquema de SGBD en la nube.
las opciones contratadas, por lo que si en cual-
quier momento se produjese un pico importante de peticiones que saturasen el sistema, se po-
dría contratar una réplica, duplicar la cantidad de memoria disponible o modificar los recursos
contratados y prácticamente de forma inmediata tendríamos disponible la réplica, la memoria
o el recurso solicitados.
7.2.2. Ventajas e inconvenientes

Las principales ventajas del trabajo en la nube son las siguientes:
● Coste: normalmente por un importe considerablemente menor al necesario para insta-

lar, explotar y mantener un SGBDD se podría disponer de un sistema gestor en la nube
de similares o mayores características.
● Alto rendimiento y escalabilidad: la capacidad de procesamiento es mucho mayor que en
un sistema gestor tradicional o distribuido (en estos sistemas no solo se distribuye la infor-
mación, sino también el procesamiento de la misma), y la capacidad de almacenamiento es
casi ilimitada. La escalabilidad sería inmediata en caso de que fuese necesario: si n
ecesitamos
Capítulo 7
repentinamente mucho más espacio de almacenamiento, solo habría que indicarlo por
medio de una web de configuración e inmediatamente se dispondría de dicho espacio.
● Alta disponibilidad y durabilidad: el proveedor garantiza el servicio 24 x 7, y además
este estará disponible desde cualquier parte del mundo.
● Alto nivel de seguridad.
● Completamente administrado, con los ahorros de personal que ello supone. Garantiza-
ría además la actualización de versiones y la instalación de parches de seguridad.
● Compatibilidad con los sistemas gestores centralizados existentes actualmente: la ma-
yoría de empresas que ofrecen servicios de almacenamiento en la nube trabajan con
los principales servidores de bases de datos, con lo cual sería posible seguir trabajando
con el mismo entorno conocido (Oracle, SQL Server, Postgree, MySQL…) pero en
la nube, además de disponer de servicios adicionales como sistemas gestores NoSQL,
que podrían ser más adecuados para determinadas tareas de la organización y por su
características pueden sacar mayor rentabilidad al trabajo en la nube.
● Es la solución que mejor se adapta a entornos de teletrabajo.
Las principales desventajas de este tipo de sistemas son las habituales del trabajo en la nube:
● Dependencia de un tercero, que es quien guarda la información.

● Una caída de la conexión a internet impediría el acceso a los datos.
● La seguridad de la información puede verse comprometida.
● Se pierde capacidad de “personalización”: la capacidad de decisión y personalización en
cuanto a la administración del sistema y permisos sobre el mismo se verán condicionados
por lo que permita hacer el proveedor (no se dispone de control total sobre los sistemas).
7.3. Oracle en la nube

Oracle Cloud es el servicio de computación en la nube provisto por Oracle. Inicialmente, Oracle
ofrecía su servicio en la nube por medio de la contratación de hardware dedicado, pero actual-
mente permite contratar no solamente el hardware sino también gran cantidad de aplicaciones y
servicios adicionales (que en general emplean únicamente tecnología propia de Oracle).
Amazon y Microsoft (los líderes del sector de la computación en la nube, con sus plata-
formas AWS y Azure respectivamente) ofrecen servicios basados en el pago por uso, y entre
los sistemas gestores con los que permiten trabajar se encuentra Oracle, por lo que es posible
contratar directamente un servidor de Oracle en la nube a través de estos proveedores, si bien
el licenciamiento del software corre a cargo del cliente.
Accede al recurso digital Base de datos en la nube, donde se indican los pasos que es nece-
sario seguir para registrarse en el servicio de AWS Education como formador, crear una clase y
matricular a un grupo de alumnos para que puedan acceder al aula y crear su propio servidor en
la nube, crear un sistema gestor y realizar una configuración básica para poder acceder a él por
medio de una aplicación cliente.
Capítulo 7
7.4. Sistema de gestión de base de datos distribuidos
Los primeros sistemas gestores de bases de datos existentes eran sistemas centralizados, instalados
normalmente en un mainframe con gran capacidad de procesamiento. El incremento de pres-
taciones de las redes de computadoras, junto a la necesidad cada vez mayor de compartir infor-
mación, y la tendencia de las grandes empresas a la descentralización, dieron lugar a la aparición
de sistemas en los que la información ya no reside en un nodo central, sino que se distribuye a
través de todo el sistema: los sistemas gestores de bases de datos distribuidos.
Podemos definir una base de datos distribuida (BDD) como un conjunto de bases de
datos lógicamente relacionadas que están repartidas entre diferentes espacios lógicos y físicos
conectados por una red, y un sistema de gestión de bases de datos distribuidas (SGBDD)
como el software que gestiona una base de datos distribuida, haciendo que la distribución de
los datos sea transparente al usuario (que tendrá la percepción de estar trabajando con una
base de datos centralizada).
En general, un sistema de computación distribuida consiste en un conjunto de compu-
tadores interconectados entre sí a través de una red, que cooperan para realizar una determi-
nada tarea. Los SGBDD están formados por sistemas de procesamiento autónomos (llamados
nodos) que dispondrán de repositorios de datos locales, conectados a través de una red con
el resto de nodos, de modo que podrán gestionar su propia información y cooperar con el
resto de nodos para manejar información global del sistema, dando lugar a dos tipos de tran-
sacciones:
● Transacciones locales. Procesan información ubicada en el propio nodo.

● Transacciones globales. Procesan información situada en nodos diferentes.
Al igual que los SGBDD, presentan numerosas diferencias con respecto a los sistemas ges-
tores centralizados, también las bases de datos creadas con estos sistemas (bases de datos distri-
buidas) presentarán diferencias con respecto a las bases de datos centralizadas, especialmente en
lo que respecta a su diseño y arquitectura.
Figura 7.2
Esquema de un SGBDD.
Capítulo 7
7.4.1. Características
Para que un sistema gestor sea considerado como SGBDD, debe presentar una serie de carac-
terísticas:
a) Los datos estarán distribuidos en distintas ubicaciones, pero debe existir una relación
lógica entre ellos.
b) Cada uno de los nodos del sistema debe ser autónomo, y ser capaz de realizar proce-
samiento local. Esta característica los diferencia de los sistemas centralizados en clúster
(disponen de varios nodos pero estos forman parte de un sistema indivisible).
c) Debe haber un uso global del sistema. Las operaciones que requieran acceder a informa-
ción almacenada en varios nodos diferentes se realizarán de forma transparente al usuario.
d) Control del sistema: en los sistemas centralizados el control del sistema recae completa-
mente en el nodo central, que será un cuello de botella, mientras que en los distribuidos
deben coordinarse todos los nodos.
e) Datos replicados: en los sistemas centralizados no se suelen almacenar datos replicados,
ya que pueden dar lugar a inconsistencias, mientras que en los distribuidos sí es habitual
replicar la misma información en distintos nodos (penalizan las operaciones de modi-
ficación pero aportan mayor disponibilidad y mejoran notablemente las consultas y la
disponibilidad de la información).
f) Diferentes mecanismos de optimización: en los sistemas centralizados la optimización
está basada en minimizar el coste en recursos y tiempo de las consultas, mientras que en
los distribuidos la base de la optimización es tratar de maximizar el procesamiento local.
g) En los sistemas centralizados hay una política común de seguridad y privacidad, mien-
tras que en los distribuidos es posible realizar una gestión de seguridad local y otra
global, lo que aporta mayor potencia y flexibilidad.
h) En un sistema centralizado, una caída del nodo principal afectaría a todo el sistema. En
un sistema distribuido, en caso de caída de un nodo afectaría a la localización donde se
ubica ese nodo, pero el resto del sistema podría seguir trabajando.

La utilización de sistemas de bases de datos distribuidos presenta varias ventajas con respecto a
las bases de datos en red centralizadas:
● Su instalación es más económica: es más barato adquirir varios equipos de gama media
para instalar los nodos que adquirir un gran sistema de procesamiento central de una
potencia equivalente.
● Son más flexibles, y se ajustan mejor a una estructura organizativa descentralizada: si
hubiese que añadir una nueva sede al sistema, bastaría con instalar en ella su nodo co-
rrespondiente y vincularlo al sistema distribuido.
● Permite el crecimiento incremental de la base de datos: pueden implementarse a partir de la
interconexión de bases de datos ya existentes, y pueden implementarse inicialmente sobre
un número reducido de nodos e ir incrementando el número de nodos paulatinamente.
● Reduce la sobrecarga de comunicación con respecto a un sistema en red centralizado,
ya que la mayoría del procesamiento es local.
Capítulo 7
● Suelen ofrecer un mayor rendimiento, ya que el procesamiento local en los distintos

nodos se realiza en paralelo.
● Existe mayor disponibilidad de los datos, debido a la replicación (la información está
disponible en otros nodos), y debido a la distribución (si cae un nodo, pueden seguir
trabajando los demás).
● Son más modulares: se pueden modificar, agregar o quitar sistemas de la base de datos
distribuida sin afectar a los demás nodos.
Presenta también, sin embargo, algunos inconvenientes:
● El coste de administración y mantenimiento de un SGBDD es mucho mayor que el de

un sistema centralizado.
● Las transacciones distribuidas incrementan considerablemente la complejidad del sis-
tema. En los sistemas distribuidos es mucho más complejo gestionar aspectos como la
integridad, la recuperación o el control de concurrencia (por el acceso simultáneo de
varios nodos a un mismo dato).
● Existe duplicidad de información, lo que implica mayor coste de almacenamiento y
mayor complejidad a la hora de manipular la información, que debe mantenerse actua-

lizada en todo el sistema.
● Las transacciones globales requieren de un tiempo extra de procesamiento para realizar
la unión de los resultados de cada nodo.
● El diseño de las bases de datos se vuelve más complejo.
● En los sistemas distribuidos heterogéneos puede ser necesario realizar conversiones
entre los datos, por lo que la comunicación es más compleja y problemática.
7.4.3. Tipos de sistemas gestores distribuidos

Los sistemas gestores de bases de datos distribuidos se pueden clasificar en función del tipo de
software que emplean los sistemas gestores que forman parte del sistema o en base al modo en
que se distribuye la información.
A) Según el tipo de software

1. Homogéneos: todos los nodos emplean el mismo SGBD local, lo que simplifica las inte-
racciones entre los nodos. Son más fáciles de diseñar y gestionar. Cuando el sistema se
diseña desde un principio como sistema distribuido, lo más habitual es que sea homo-
géneo, ya que facilita el mantenimiento y la integración entre los distintos nodos.
2. Heterogéneos: cada nodo puede utilizar un sistema gestor diferente, que no tiene por
qué basarse en el mismo modelo de datos subyacente, por lo que el sistema puede estar
compuesto de sistemas gestores relacionales, en red, jerárquicos, orientados a objetos,
etc. Esta es la opción más habitual cuando el sistema surge de la integración de sistemas
gestores de bases de datos ya existentes, lo que permite reducir los cambios en el siste-
ma y minimizar el impacto del cambio.
Capítulo 7
B) Según la distribución de la información

1. Centralizada: no existe distribución, toda la información se almacena en uno de los no-
dos (el nodo central), constituido por un equipo con gran potencia de procesamiento,
ya que debe atender todas las peticiones del resto de los nodos.
2. Distribuida con nodo principal: cada nodo tiene una parte de la base de datos y un nodo
central contiene la base de datos completa. Esta opción no es muy utilizada ya que
supone un alto coste y presenta los inconvenientes de las bases de datos centralizadas
(el nodo central se convierte en un cuello de botella de la red, aunque incrementa la
disponibilidad de los datos) y de las distribuidas (problemas derivados de la replicación
y la fragmentación de la información).
3. Replicada: la información se duplica en los diferentes nodos. La replicación reduce la co-
municación entre los nodos a la hora de realizar consultas e incrementa la disponibilidad
de los datos, además de facilitar la recuperación de la información en caso de fallo en un
nodo, pero complica considerablemente las actualizaciones y la gestión de transacciones.
4. Fragmentada: la información se divide entre los distintos nodos.
5. Híbrida: combina fragmentación y replicación. Es la opción más habitual, ya que permi-
te buscar un equilibrio entre complejidad y coste de almacenamiento y disponibilidad
de los datos.
7.4.4. Fragmentación y replicación

La optimización de consultas en un SGBDD pasa por maximizar el procesamiento local, por lo
que habrá que tratar de tener en cada nodo la mayor cantidad posible de información que se vaya
a usar en ese nodo. En función de la información que se consulte, pueden darse dos casuísticas:
1. Cuando la información que se consulta es común entre los distintos nodos, la solución
pasa por replicar la información (copiarla en todos los nodos que la necesiten). La re-
plicación es la mejor forma de ofrecer alta disponibilidad y tolerancia a fallos: al tener
la información duplicada, si uno de ellos cae o su seguridad se ve comprometida, se
puede recuperar la información a partir de otros nodos de la red, que seguirán estando
disponibles. Esto conlleva sin embargo un enorme coste tanto en espacio de almacena-
miento como en procesamiento, para mantener actualizadas todas las réplicas (si cambio
un dato en un nodo, debo trasladar ese cambio al resto de los nodos asegundando que
ese cambio no se solape con otros cambios que se hayan realizado en el resto de nodos).
Cuando la información está replicada, en cada nodo se dispone de toda la información
existente, y por tanto se consulta únicamente la información local. Mientras el nodo
local no falle, no se consultarán nunca el resto de nodos.
2. Cuando cada nodo utiliza información propia que apenas es consultada por el resto
de nodos, la mejor solución es fragmentar la información: dividirla entre los distintos
nodos, de forma que cada uno acceda únicamente a su información local.
La fragmentación de los datos puede ser:
● Horizontal: las tablas se dividen en conjuntos de tuplas completas.

● Vertical: las tablas se dividen en función de sus campos.
● Mixta: las tablas están fragmentadas horizontal y verticalmente.
Capítulo 7
Cuando la información está fragmentada, para poder acceder a toda la informa-

ción de la organización, es necesario consultar la información existente en todos los
nodos, de forma que el total de información disponible será una UNION de la
información de cada uno de los nodos. Para poder consultar la información existente
en otros nodos, se utilizan los dblinks o enlaces de base de datos.
Ejemplo
Una empresa dispone de una base de datos para gestionar su personal con una tabla con la
siguiente estructura:
PERSONAL (codemp, nombre, apellidos, coddepto, salario, feccontratacion, codesp)

DEPARTAMENTO (coddepto, departamento, ciudad)
ESPECIALIDAD (codesp, especialidad)
Tras la adquisición de una nueva sede, la empresa quiere redistribuir a sus empleados en
tre las dos sedes y crear una base de datos distribuida para poder acceder a toda la información
desde cualquiera de las sedes.
La empresa podría organizarse internamente de distintas formas, y la estructura de su base
de datos distribuida tendría que adaptarse a la organización que escogiese:
● Si decidiesen dedicar una sede a oficinas y otra a logística, podrían dividir la tabla
de personal de forma que en la oficina únicamente tengan acceso a la información
necesaria para elaborar las nóminas del personal, y en la de logística a la informa
ción necesaria para organizar los equipos de trabajo. Tendríamos de esta forma una
fragmentación vertical para la tabla de personal, y las tablas de departamento y espe
cialidad solamente serían necesarias en la sede de logística, por lo que los esquemas
locales de las sedes serían:
SEDE 1:
NOMINAS(codemp, nombre, apellidos, salario, feccontratacion)
SEDE 2:
PERSONAL(codemp, coddepto, proyecto)
● Si cada sede estuviese en una ciudad, y decidiesen dividir los departamentos y sus
empleados entre las dos sedes en función de la ciudad en la que está el departamento,
en cada sede guardarían únicamente la información del personal de los departamen
tos que pertenezcan a esa sede, realizando por tanto una fragmentación horizontal:
la estructura de la tabla de personal es exactamente igual en ambas sedes pero cada
sede guardaría únicamente su información. Las especialidades serán exactamente las
mismas en ambas sedes, por lo que lo ideal sería replicar dicha tabla. La información
de los departamentos podría fragmentarse o replicarse. Al ser una tabla pequeña, y
dado que puede ser de interés disponer en ambas sedes de la información de todos
los departamentos, en este caso se replicará la tabla, por lo que los esquemas locales
de las dos sedes serían los siguientes:
Capítulo 7
SEDE 1:
PERSONAL1(codemp, nombre, apellidos, p.coddepto, salario, feccontratacion,
proyecto)
from PERSONAL p join DEPARTAMENTO d on (p.coddepto=d.coddepto)
where ciudad=’XXX’;
SEDE 2:
PERSONAL2(codemp, nombre, apellidos, p.coddepto, salario, feccontratacion,
proyecto)
from PERSONAL p join DEPARTAMENTO d on (p.coddepto=d.coddepto)
where ciudad=’YYY’;
Toma nota
Generalmente los esquemas de fragmentación se definen empleando expre

siones del álgebra relacional. En este libro, para simplificar y facilitar la com
prensión, en lugar de este tipo de expresiones se utilizarán expresiones SQL
equivalentes para indicar la información que incluirá cada fragmento.
A) Diseño de una base de datos distribuida

La información de una base de datos distribuida estará fragmentada y replicada a través de
los distintos nodos del sistema, por lo que su diseño implica la definición de varios esquemas
que permitan reflejar en qué modo se ha realizado la fragmentación y la replicación de los datos:
● Esquema global: donde se define el conjunto de la información que forma parte del
sistema y su organización.
● Esquema de fragmentación: determina el modo en que se fragmentará la información
de cada tabla.
● Esquema de localización: establece la ubicación de los fragmentos en los nodos del
sistema.
● Esquema local: cada esquema local sería el equivalente al esquema relacional de cada
nodo, e incluirá los objetos propios cada SGBD.
Accede al recurso didáctico Fragmentación y replicación en el que se incluyen varias pro-

puestas de bases de datos sencillas en las que pide definir el modo en que se debería fragmentar
y replicar la información para crear una base de datos distribuida.
Capítulo 7
B) Dblinks
Un enlace de base de datos (en inglés database link o dblink) permite establecer una co-
nexión entre dos sistemas gestores de bases de datos de modo que desde uno de los sistemas se
pueda acceder directamente a las tablas del otro sistema gestor.
¿Sabías que...?
Los dblinks son especialmente útiles en entornos distribuidos, ya que serán los que permiti
rán acceder a la información almacenada en los nodos remotos. Por medio de los dblinks se
podrán realizar consultas globales cuando la información se encuentre fragmentada entre los
distintos nodos.
Ejemplo
Supongamos una empresa con tres sedes que quiere distribuir la información de sus clientes
entre todas sus sedes, de forma que desde cada sede se trabaje normalmente solo con los
clientes locales pero también puedan consultar el resto de clientes de la empresa.
La empresa guarda la siguiente información de sus clientes:
CLIENTES(codcliente, codsede, nombre, apellido1, apellido2, direccion, codpostal, ciudad)
Dado que la empresa tiene tres sedes, crearíamos tres tablas, una para cada sede:
Sede 1: Create table clientes_1 as select * from clientes where codsede=1;

La tabla clientes_1 se guardaría en el sistema gestor de la sede 1, clientes_2 en el sistema

gestor de la sede 2 y clientes_3 en el sistema gestor de la sede 3.
Para poder acceder desde cada una de las sedes a las tablas de las otras sedes, sería nece
sario crear dos dblinks en cada sede. En la sede 1 crearíamos los dblinks:
@sede2: permitiría acceder a las tablas almacenadas en el sistema gestor de la sede 2.

@sede3: permitiría acceder a las tablas almacenadas en el sistema gestor de la sede 3.
Para consultar la información de todos los clientes desde la sede 1, podríamos crear una
vista de la siguiente manera:
CREATE VIEW clientes AS

Select codcliente, codsede, nombre, apellido1, apellido2, direccion, codpostal, ciudad
from clientes_1
UNION
from clientes_2@sede2
UNION
from clientes_3@sede3;
Capítulo 7
Para crear un enlace de base de datos será necesario indicar la cadena de conexión al SGBD
remoto y las credenciales de usuario que se emplearán para establecer la conexión.
C) Replicación
La replicación consiste en duplicar información en distintos nodos, de forma que todos
ellos puedan acceder rápidamente a la información (la tienen disponible en local), pero a cam-
bio de un mayor coste de almacenamiento y sobre todo una mayor complejidad a la hora de
administrar la manipulación de los datos replicados.
La replicación puede llevar a cabo de tres formas diferentes:
1. Unidireccional
Existe un nodo maestro, donde se realizan los cambios, y un nodo esclavo, donde se re-
plican los cambios realizados en el maestro. Los cambios solamente se podrán llevar a cabo en
el maestro, porque si se realizasen en el esclavo no se replicarían en el maestro. Se usa nor-
malmente para copias de seguridad en caliente, de modo que si fallase el SGBD maestro se
podría seguir trabajando con el esclavo cambiando únicamente las cadenas de conexión de las
aplicaciones.
Maestro Esclavo Maestro/esclavo Maestro/esclavo

Figura 7.3 Figura 7.4
Replicación unidireccional. Replicación bidireccional.
2. Bidireccional
Se establece también entre dos nodos, pero ambos nodos funcionan simultáneamente como
maestros y esclavos, por lo que todos los cambios se replicarán independientemente de donde
se realicen.
3. Multidireccional
Se establece entre varios nodos, actuando uno de ellos como maestro y el resto como escla-
vos, y los cambios realizados en el maestro se trasladan a todos los esclavos. Esta opción se utiliza
mucho en grandes organizaciones que además de disponer de un nodo de réplica disponen de
un data warehouse o sistemas de big data en tiempo real, de forma que cualquier cambio rea-
lizado en el SGBD operacional se traslada inmediatamente tanto a su réplica como a todos los
demás sistemas que sea necesario.
Capítulo 7
Ten en cuenta
La replicación puede ser multidireccional y bidireccional simultáneamente, ya que cada nodo

puede actuar como maestro en una replicación multidireccional que traslade sus cambios al resto
de nodos y como esclavo en otras replicaciones multidireccionales creadas en los demás nodos.
Normalmente los sistemas gestores de ba-

ses de datos implementan la replicación par-
tiendo de la información registrada en el cua-
derno de bitácora (el log donde se registran Maestro Esclavo 1
todas las operaciones de definición y manipula-
ción de datos que se llevan a cabo en el sistema).
Cada vez que se realiza una operación de escri-
tura en el nodo principal (maestro), esta opera-
ción se registra en su cuaderno de bitácora y se
traslada a todos los nodos secundarios (esclavos),
bien por medio de procesos que se ejecutan de Esclavo 3 Esclavo 2
forma asíncrona o bien por medio de eventos, y Figura 7.5
los esclavos replican las operaciones en su pro- Replicación multidireccional.
pio cuaderno de bitácora, de forma que todas
las escrituras se trasladan a todas las réplicas.
La replicación se utiliza tanto en sistemas distribuidos como en sistemas centralizados
en clúster y en la nube, aunque existe una pequeña diferencia a la hora de llevarla a cabo. En un
clúster suele ser multidireccional: habrá un nodo principal (maestro) donde se realizan todas
las operaciones y estas se replican en el resto de nodos del clúster, mientras que en los sistemas
distribuidos todos los nodos pueden funcionar como nodos principales, por lo que la replica-
ción será bidireccional (cada nodo gestionará su propio cuaderno de bitácora y se encargará de
notificar al resto de nodos las modificaciones realizadas). En los sistemas gestores de bases de da-
tos en la nube, depende de cómo esté configurado el sistema (si los usuarios acceden a un solo
nodo será unidireccional, y si pueden acceder también a la réplica será bidireccional).
Con respecto a la lectura de la información, el proceso es completamente diferente: en un
clúster la información se lee siempre del nodo principal (a no ser que este caiga, con lo cual
pasará a considerarse como principal la réplica), mientras que en los sistemas distribuidos se lee
la información siempre del nodo local.
7.5. Distribución de información en Oracle

A continuación veremos los mecanismos existentes para fragmentar y replicar la información
almacenada en sistemas gestores Oracle.
7.5.1. Fragmentación
Para fragmentar la información en Oracle será necesario crear enlaces de bases de datos (Da-
tabase Links o dblinks) que permitan interconectar los distintos nodos. Los dblinks permiten
Capítulo 7
establecer conexiones directas entre dos instancias Oracle, de forma que desde una de ellas se
puede hacer referencia directamente a las tablas de la otra instancia.
La sintaxis para la creación de un dblink es la siguiente:
CREATE [SHARED][PUBLIC] DATABASE LINK <dblink>

CONNECT TO <usuario_remoto> IDENTIFIED BY <password_usuario_remoto>
USING <cadena_de_conexion>;
Donde:
– SHARED permite crear el enlace de forma que sea compartido entre varios usuarios.
– PUBLIC permite definirlo de forma que sea público y cualquier usuario de la instancia
local pueda utilizarlo.
– Cadena_de_conexion: será la entrada del TNSNAMES del servidor que se utilizará
para establecer la conexión con el servidor remoto (puede indicarse la cadena de cone-
xión directamente, sin incluirla en el TNSNAMES).
Generalmente los dblinks se establecen entre dos instancias Oracle, pero esto no tiene por
qué ser así: se pueden crear enlaces con cualquier sistema gestor, pero en ese caso la conexión
se establece a través de un conector ODBC, por lo que es necesario crear un driver ODBC
previamente en el servidor local que se conecte al servidor remoto. El problema de este tipo de
conexiones es que limita considerablemente las operaciones que se pueden llevar a cabo en el
sistema remoto (dará problema con campos que tengan tipos de datos incompatibles o al reali-
zar operaciones propias del sistema gestor).
Ten en cuenta
Los dbinks pueden comprometer la seguridad del sistema, ya que para crear un dblink,
es necesario indicar en la sentencia de creación del enlace el usuario y contraseña que
se utilizará para acceder a la instancia remota, de modo que cualquier usuario que se co
necte usando ese dblink tendrá acceso a esas credenciales y las empleará para establecer
el enlace.
Lo más adecuado para solucionar estos problemas es crear en el sistema gestor remoto
un usuario personalizado para cada usuario que haga uso de un dblink, de forma que cada
usuario usará sus propias credenciales también en el equipo remoto.
Accede al recurso digital Distribución de datos en Oracle donde se plantea un caso práctico
de fragmentación de información entre distintos nodos de un SGBD heterogéneo. Durante la acti-
vidad se crearán distintas bases de datos y se establecerán conexiones entre ellas por medio de
dblinks, lo que permitirá comprobar y comprender su funcionamiento y su utilidad en un SGBDD.
Capítulo 7
7.5.2. Replicación
Hasta la versión 12c de Oracle, la replicación se podía realizar de dos maneras, ambas con so-
porte para replicación multidireccional:
● Asíncrona, por medio de streams: es la forma más simple de replicación. Todas las sen-
tencias ejecutadas sobre el sistema gestor origen se almacenan en una cola, y se van
enviando al destino, que las irá aplicando a medida que las vaya recibiendo. En este caso
habrá un proceso que se encargará de leer el redo log para guardar todos los cambios en
la cola, y otro proceso que regularmente se encargará de enviar los cambios registrados
en la cola al o a los destinos.
● Síncrona, por medio de eventos: en este caso también hay un proceso que se encargará
de leer los cambios registrados en el redo log, pero en este caso lo que hace es generar
eventos que serán capturados en los destinos para replicarlos. Esta replicación tiene una
configuración más compleja, pero permite registrar eventos producidos en cualquier
sistema gestor, no tiene por qué ser solamente Oracle, y puede llevarse a cabo por
medio de conectores externos, aunque Oracle dispone de su propio conector, Oracle
Golden Gate, para realizar esta tarea. Este conector no se instala con el propio sistema
gestor, sino que es un software independiente.
¿Sabías que...?
Para volcar la información de los sistemas operacionales a los sistemas data wa
rehouse se utilizan procesos de carga que se ejecutan en horario de baja carga
para no afectar al rendimiento del sistema. Esta operativa no es factible para los
sistemas de big data que procesan información en tiempo real, lo que motivó la
aparición de este tipo de replicación basada en eventos, capaz de trasladar in
mediatamente cualquier cambio que se produzca en el sistema operacional para
que sea replicado en cualquier otro sistema de la organización, de forma que
estos siempre mantengan su información actualizada.
El uso de streams no se llegó a adaptar a la nueva arquitectura Multitenant de Oracle, y

de hecho en la versión 19c de Oracle se descontinuó su uso, por lo que la única alternativa en
entornos en los que se empleen PDB es utilizar Golden Gate para implementar la replicación.
Un sistema de replicación de Golden Gate cuenta con varios componentes:
1. Proceso manager: es el proceso maestro que controla la actividad de golden gate (el que
inicia el resto de procesos). Este proceso debe estar en ejecución en todos los servidores
involucrados en la replicación.
2. Proceso de extracción: lee el redo log y extrae todos los cambios que hayan sido comi-
tados.
3. Cola de salida: fichero donde se almacenan los cambios extraídos encolándolos para su
envío.
4. Proceso de data pump: este proceso es opcional. Su función es trasladar los cambios
registrados en la cola de salida a la cola de entrada de todos los nodos esclavos para su
Capítulo 7
replicación. Es opcional ya que esta funcionalidad la puede llevar a cabo el propio pro-
ceso extractor.
5. Proceso colector: se ejecuta en el servidor destino. Es el encargado de recibir todos los
cambios enviados por todos los servidores origen que deban ser replicados en el servi-
dor destino y registrarlos en la cola de entrada.
6. Cola de entrada: fichero donde se almacenan los cambios pendientes de aplicar en el
servidor destino.
7. Proceso de entrega: encargado de aplicar los cambios en el servidor destino.
Manager
Proceso de Cola de salida Data pump Colector Cola de entrada Proceso

SGBD origen extracción LAN / WAN / internet de entrega SGBD Destino
Figura 7.6
Arquitectura de la replicación
con Golden Gate.
El proceso podría implementarse en ambas direcciones, lo que permite establecer si-

multáneamente una replicación multidireccional y bidireccional, y con sistemas distribuidos
heterogéneos, ya que dispone de drivers para los distintos sistemas gestores comerciales que
permiten implementar los procesos de extracción y de entrega en otros sistemas gestores de
bases de datos.
Para profundizar en el funcionamiento de un sistema de replicación con Oracle Golden Gate, ac-
cede al recurso digital Replicación con Oracle Golden Gate donde se propone una actividad
que incluye la instalación del software y la configuración de una replicación unidireccional.
7.6. Clúster de servidores

Los sistemas gestores de bases de datos distribuidos se han contemplado habitualmente como
una solución muy apropiada para organizaciones que disponen de múltiples sedes. Sin embargo,
el hecho de implementar un SGBDD en una organización de este tipo implicaría disponer de
un sistema gestor en cada sede, disponer de una conexión fiable entre las sedes, disponer de los
mecanismos necesarios para garantizar la seguridad de las conexiones y de la información, y
disponer del personal necesario para administrar todo el entorno.
Tradicionalmente los sistemas distribuidos tenían la gran ventaja de que la mayor parte
del procesamiento era local, evitando así el acceso al resto de nodos, que con las redes existen-
tes era muy lento. Con la mejoría experimentada en los últimos años por las redes de teleco-
municaciones (tanto en velocidad como en estabilidad), el retardo en acceder a datos remotos
en comparación con el tiempo de procesamiento de la información es apenas p erceptible,
Capítulo 7
por lo que la mayoría de organizaciones optan por otras soluciones como los clústers o el
trabajo en la nube, ya que facilitan considerablemente la administración del sistema, garanti-
zan totalmente el cumplimiento de las propiedades ACID y son en general más robustas que
un SGBDD.
7.6.1. Características
Un clúster es un conjunto de equipos (nodos), unidos normalmente por medio de una cone-
xión de alta velocidad, que operan conjuntamente como si fuesen un único equipo. Mientras
que en un SGBDD todos los nodos son sistemas gestores de bases de datos, en un clúster esto
no es así: habrá nodos que gestionarán las bases de datos, otros serán nodos de datos (solamente
almacenan información), y normalmente hay también nodos de administración (que se encar-
gan de coordinar el funcionamiento del clúster).
Nodo admin
Nodo SQL Nodo SQL

Clúster
Nodos de datos Figura 7.7

Esquema de un SGBD
en clúster.
Tanto la funcionalidad como la información almacenada dentro de los nodos están habi-
tualmente fragmentadas y replicadas dentro del clúster, de forma que en caso de fallo de uno de
los nodos el sistema podría seguir funcionando normalmente: si cae un nodo SQL (que trabaje
como sistema gestor) o un nodo de administración, el sistema puede seguir trabajando normal-
mente si hay otros nodos SQL y de administración, y si cae un nodo de datos, la información
que almacenaba se buscará en los otros nodos donde esté replicada.
Toma nota
La principal diferencia entre un clúster y un SGBDD es que el clúster opera lógicamente

como un solo servidor, mientras que en un SGBDD cada nodo dispone de su propio
servidor y almacena su propia información, aunque puede comunicarse con el resto de
nodos si es necesario para acceder al resto de información del sistema.
Capítulo 7
Un clúster está orientado a proporcionar cuatro funcionalidades:
● Alto rendimiento: no solo se distribuye la información entre los distintos nodos sino
también el procesamiento de la misma, por lo que podrán ejecutarse tareas en paralelo
incrementando el rendimiento del sistema.
● Alta disponibilidad: el sistema podrá seguir trabajando aunque caigan uno o incluso más
nodos.
● Balanceo de carga: la carga se distribuye entre los nodos, evitando cuellos de botella.
● Escalabilidad: para dotar de mayor capacidad al sistema bastaría con incorporar nuevos
nodos (eso sí, esta capacidad de escalabilidad tiene un límite, ya que la gestión de la
información en un clúster es centralizada).
Además, el uso de un clúster permite emplear servidores que, sin ser punteros, trabajando
conjuntamente ofrezcan mejor rendimiento que un único servidor central muy potente, lo que
ahorra costes y facilita la reutilización de los servidores.
La principal desventaja de instalar un clúster de servidores es su coste, no en compara-
ción con un SGBDD, sino en comparación con el coste que implicaría el almacenamiento en
la nube.
7.7. El clúster de Oracle

Oracle RAC
Oracle dispone de la tecnología RAC (Real Appli-
Servidor
cation Clusters) para implementar clústers de servi- de aplicaciones
dores, proporcionando alta disponibilidad y balan-
ceo de carga.
La arquitectura de Oracle RAC está compuesta
fundamentalmente por 3 capas: Balanceador
1. Un servidor de aplicaciones (WebSphere),

que se encarga de recibir las peticiones de
los usuarios y redireccionarlas a los nodos
de bases de datos, balanceando la carga en-
tre ellos. SGBD 1 SGBD 2 SGBD 3
2. Nodos de bases de datos: cada nodo será
una instancia de Oracle.
3. Un sistema de almacenamiento compar-
tido, que normalmente tiene redundancia Switch SAN
para asegurar la disponibilidad de los datos.
Al ser un sistema compartido, los cambios
en los datos se deben coordinar entre las
instancias para que todos los nodos tengan Disco 1 ASM Disco 2
vistas consistentes de los datos en todo mo-
mento. Figura 7.8
Estructura de un clúster Oracle.
Capítulo 7
Todos los elementos estarán conectados entre sí por medio de redes de alta capacidad.
La información se almacena en un sistema de archivos compartido, y todos los sistemas ges-
tores tienen acceso al mismo a través de una caché de alta capacidad que facilita la coordinación
a la hora de aplicar los cambios llevados a cabo por cada sistema gestor: el sistema de archivos
retiene en caché los datos a escribir hasta que tiene varios cambios a realizar, y entonces los
vuelca todos juntos. Si todos los cambios afectan a los mismos datos, se realizan directamente en
la caché, no es necesario acceder continuamente al disco.
Para almacenar los datos compartidos de esta manera es necesario un sistema de archivos
especial (no es posible utilizar directamente los provistos por sistemas operativos como Linux,
Unix o Windows). Es posible utilizar cualquier sistema de archivos de clúster, pero Oracle
recomienda su propio sistema de archivos: ASM (Automatic Storage Manager), que permite
almacenar tanto la información de la base de datos como datos no estructurados (imágenes,
documentos, etc.) de forma compartida.
Una de las ventajas de Oracle RAC es que comprueba automáticamente errores en el al-
macenamiento. La información se almacena empleando tecnologías RAID que permiten tanto
replicar la información como comprobar la presencia de errores, de forma que si detecta un
error en algún disco, automáticamente redirigirá las peticiones a un disco que tenga esos mis-
mos datos y no presente sectores defectuosos.
Resumen
n La información es uno de los principales activos de una organización, por lo que es

fundamental facilitar y garantizar el acceso a la misma. Algunas tecnologías que bus
can este objetivo con los sistemas gestores de datos distribuidos (SGBDD), el almace
namiento en la nube o los clústers.
n Los SGBDD gestionan bases de datos ubicadas en distintas localizaciones pero rela
cionadas lógicamente. Cada nodo es autónomo y comparten el control del sistema.
La información está fragmentada y replicada entre los nodos, y disponen de políticas
de seguridad locales y globales. Si cae un nodo, solo afecta a su localización.
n Tienen menor coste de implementación, son más flexibles, modulares y adaptables,
permiten el crecimiento incremental de la base de datos, reducen la sobrecarga de
comunicación y ofrecen un mayor rendimiento y disponibilidad de los datos, pero el
coste de administración y mantenimiento es muy elevado, las transacciones distribui
da son complejas (especialmente en sistemas heterogéneos), y la replicación implica
mayor coste de almacenamiento y manipulación.
n Los SGBDD pueden ser homogéneos (todos los sistemas gestores son iguales) o
heterogéneos (usan sistemas gestores con distintas tecnologías), y la información
puede estar centralizada, distribuida con un nodo principal, replicada, fragmentada
o puede tener una estructura híbrida (lo más habitual, con información fragmen
tada y replicada).
Capítulo 7
n La fragmentación se implementa por medio de dblinks. La replicación se basa en el

uso del cuaderno de bitácora y puede ser unidireccional, bidireccional o multidirec
cional.
n Un clúster es un conjunto de servidores unidos por una conexión de alta velocidad
que operan conjuntamente como uno solo. Cada nodo desempeña una función:
SGBD, de administración o de almacenamiento. La información se fragmenta y re
plica entre los nodos, lo que lo hace muy tolerante a fallos. Todas las transacciones
son locales.
n Ofrecen un alto rendimiento, alta disponibilidad, balanceo de carga, escalabilidad,
menor coste de un gran servidor centralizado y administración centralizada, pero
suelen tener mayor coste que un sistema gestor en la nube.
n Los sistemas gestores de bases de datos en la nube permiten contratar el almacena
miento de datos como un servicio (SaaS) prestado por una empresa externa: se delega
la administración y mantenimiento y permite configurar fácilmente replicación y dis
tribución en múltiples sedes. Se puede contratar únicamente hardware dedicado o el
servicio completo (pago por uso del sistema).
n Son las más flexibles y adaptables a picos de uso del sistema, están completamente
administrados, ofrecen un alto rendimiento, accesibilidad, escalabilidad, seguridad y
disponibilidad, tienen una gran relación calidad/precio y son compatibles con prác
ticamente todos los sistemas gestores existentes, pero se pierde el control sobre los
datos y sobre los propios sistemas, además de los problemas de seguridad derivados
de la computación en la nube.
Una clínica dental cuenta con cuatro consultas ubicadas en distintas ciudades. Para ges
tionar las citas de sus clientes, cuentan con una base de datos centralizada en la sede
principal compuesta de las siguientes tablas:
Figura 7.9
Estructura de la base de datos de la clínica dental.
Capítulo 7
Tras sufrir varios cortes en la conexión a internet de varias de las consultas, han decidi
do instalar un SGBD en cada consulta y distribuir la información entre todos ellos, de for
ma que la facturación de los servicios prestados a los clientes se seguirá realizando de
forma centralizada desde la sede principal pero cada sede gestionará de forma autónoma
sus citas y sus clientes.
Para poder realizar la facturación, desde la sede principal deberán poder consultar las
citas realizadas por cada cliente en el resto de sedes.
1. Determina cómo se fragmentará y replicará la información entre los distintos nodos, e

indica cual será el esquema local de cada una de las sedes.
2. Indica qué enlaces de bases de datos tendrías que crear y las sentencias necesarias
para crearlos suponiendo que todas las sedes usasen servidores Oracle y en el tnsna
mes.ora ya existiese una entrada de conexión para cada sede.
3. Es habitual que en la sede principal hagan recuentos de citas mensuales realizadas

en todas las sedes, por lo que necesitarían poder consultar conjuntamente toda la
información, en lugar de consultarla sede a sede y hacer los recuentos manualmente.
¿Cómo podrías solucionar este problema?
4. ¿Qué tipo de replicación implementarías para garantizar que todas las sedes accedan
siempre a información actualizada, teniendo en cuenta que desde cualquier sede se
podría modificar la información de las clínicas?
1. ¿A qué tipo de sistemas le afectaría más una caída en la conexión a internet en todas
las sedes de la organización?
a) Un SGBDD.
b) Un SGBD centralizado.
c) Un servidor en la nube.
d) Un clúster de servidores.
2. ¿Cuál de los siguientes tipos de SGBDD es más ineficiente?

a) Replicado.
b) Fragmentado.
c) Centralizado.
d) Distribuido con nodo principal.
Capítulo 7
3. ¿Cuál de los siguientes tipos de nodo no pertenecen a un clúster de servidores?

a) Nodos de datos.
b) Nodos de comunicación.
c) Nodos de administración.
d) Nodos de gestión de bases de datos.
4. No incrementa la disponibilidad de los SGBD:

a) Replicación.
b) Fragmentación.
c) Cloud computing.
d) Clúster de servidores.
5. Permiten establecer políticas de seguridad más flexibles:

a) SGBDD.
b) Servidor en la nube.
c) SGBD Centralizado.
d) Servidores en clúster.
6. Señala la afirmación incorrecta con respecto a los SGBDD:

a) La mayoría de transacciones son locales.
b) El usuario es consciente de estar trabajando en un nodo local.
c) La optimización de las transacciones locales y globales es diferente.
d) No tiene por qué haber una relación lógica entre los nodos del SGBDD.
7. Tengo una base de datos operacional a partir de la que quiero alimentar en tiempo
real un sistema de big data y un data warehouse. ¿Qué tipo de replicación necesi
taré?
a) Todas ellas.
b) Bidireccional.
c) Unidireccional.
d) Multidireccional.
8. Tiene mayor coste de administración y mantenimiento:

a) SGBDD.
b) SGBD centralizados.
c) Servidores en la nube.
9. Un SGBDD cuyos nodos tienen instalados distintos sistemas gestores de bases de da
tos es un SGBDD:
a) Equitativo.
b) Homogéneo.
c) Centralizado.
d) Heterogéneo.
Capítulo 7
10. Una red interna de alta velocidad será más necesaria en:
a) SGBDD.
b) SGBD centralizados.
c) Servidores en la nube.
SOLUCIONES:
a b c
1. a b c d
d 5.
2.
a b c d 6.
a b c d 9.
a b c d
a b c
3. a b c d 10.
d 7. a b c d
a b c
4. a b c d
d 8.
Capítulo 7

Administración de Sistemas Gestores de Bases de Datos

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Administración de Sistemas Gestores de Bases de Datos

Cargado por

Copyright:

Formatos disponibles

A ddeministración

Impreso en España - Printed in Spain

Reservados todos los derechos. Está prohibido, bajo las sanciones

1.. INSTALACIÓN DEL SISTEMA GESTOR DE BASES DE DATOS .................................................... 13

1.7.3.. El asistente de instalación OUI ........................................................................................... 45

2.. CONFIGURACIÓN DEL SISTEMA GESTOR DE BASES DE DATOS ............................................ 53

3.. GESTIÓN DE USUARIOS Y PERMISOS ..................................................................................................... 79

3.3.3.. Roles .............................................................................................................................................. 92

4..SEGURIDAD .............................................................................................................................................................. 111

5.. MONITORIZACIÓN Y OPTIMIZACIÓN ..................................................................................................... 147

5.3.. Monitorización en Oracle ................................................................................................................ 152

6.. AUTOMATIZACIÓN DE TAREAS ................................................................................................................... 187

7.. ALTA DISPONIBILIDAD ...................................................................................................................................... 219

Glosario ....................................................................................................................................................................... 220

1.1.. Instalación SGBD Oracle

1.1.. Base de datos transaccional vs data warehouse

1.2.. Elección del SGBD

● La automatización de tareas de administración.

Instalación del sistema

ADMINISTRADOR DE BASES DE DATOS

emplea Sistema gestor de bases de datos

Elección del SGBD Factores elección

Administrador de bases de datos (DBA: Database Administrator). Persona o equipo de

1.2. El administrador de bases de datos

a) Poner en marcha del sistema:

– Diseñar la arquitectura, desplegar y configurar los sistemas gestores de bases de datos.

b) Establecer mecanismos de seguridad:

– Crear y mantener las cuentas de usuarios y sus permisos.

– Arrancar y parar el SGBD.

– Colaborar con el administrador del sistema operativo en la gestión de los archivos

1.3. El sistema gestor de bases de datos

En estos sistemas de gestión de archivos, la definición de los datos se encuentra codificada

1.3.1. Funciones del sistema gestor de bases de datos

a) Definición de datos: mediante el lenguaje de definición de datos (DDL) el SGBD per-

b) Manipulación de datos: la función de manipulación de datos se encarga de todas las ope-

ejecución secuencial de las misas. Esto se consigue habitualmente por medio de la

vista vista vista vista vista vista vista vista Esquemas

vista vista vista vista vista

– el nivel interno (indica cómo se almacenará la información, y se define por medio

La estructuración de la arquitectura de las bases de datos en estos tres niveles per-

1.3.2. Componentes de un sistema gestor de bases de datos

A) Procesador de consultas

● DDL (lenguaje de definición de datos: create table, alter table…).

B) Gestor de la base de datos

C) Gestor de ficheros

D) Interfaces externas

E) Preprocesador del lenguaje de manipulación de datos

F) Compilador del lenguaje de definición de datos

G) Gestor del diccionario

1.4. Factores de elección del sistema gestor de bases de datos

1.4.1. Tipos de sistemas gestores de bases de datos

Existen diversas clasificaciones de los sistemas gestores atendiendo a diferentes características:

A) Por el número de usuarios

Actividad propuesta 1.1

B) Por la localización de la información

C) Por su estructura

La estrategia de CODASYL estaba basada en la navegación manual por un conjunto de datos

3. Sistemas orientados a objetos

Con el auge de la programación orientada a objetos aparece el modelo orientado a objetos.

El sistema de almacenamiento de la configuración de usuario de Google podría implementarse

Favoritos: {‘usuario1’:[’www.as.com’,’www.marca.com’], ’usuario2’:[‘www.elpais.com’,

Si el usuario1 iniciase sesión en un equipo cualquiera, consultaría en su base de datos

Las bases de datos de este tipo más usadas son:

2. Columnares: las bases de datos columnares almacenan la información en columnas en

A ddeministración

1.. INSTALACIÓN DEL SISTEMA GESTOR DE BASES DE DATOS .................................................... 13

1.7.3.. El asistente de instalación OUI ........................................................................................... 45

2.. CONFIGURACIÓN DEL SISTEMA GESTOR DE BASES DE DATOS ............................................ 53

3.. GESTIÓN DE USUARIOS Y PERMISOS ..................................................................................................... 79

3.3.3.. Roles .............................................................................................................................................. 92

4..SEGURIDAD .............................................................................................................................................................. 111

5.. MONITORIZACIÓN Y OPTIMIZACIÓN ..................................................................................................... 147

5.3.. Monitorización en Oracle ................................................................................................................ 152

6.. AUTOMATIZACIÓN DE TAREAS ................................................................................................................... 187

7.. ALTA DISPONIBILIDAD ...................................................................................................................................... 219

Glosario ....................................................................................................................................................................... 220

SQL> exec dbms_xdb_config.sethttpsport(5500); /Para HTTPS/

SQL> select dbms_xdb.getHttpPort() from dual; /Para HTTP/