Curso Admin Oracle

PROYECTO FORMACIÓN

Administración de Oracle

Cliente: Dirigido a:

Preparado por: Fecha:

Aubay Alumnos del curso de Administración de Oracle

Área de formación Emisión: Categoría:

Julio 2004 Documentación del curso

Aubay España - Formación

HOJA DE INFORMACIÓN GENERAL CONTROL DOCUMENTAL PROYECTO: ENTIDAD DE DESTINO: TITULO: CÓDIGO DE REFERENCIA: VERSIÓN: FECHA EDICIÓN: FICHERO: HERRAMIENTA/S DE EDICIÓN: AUTOR: RESUMEN: Nemo SC SR

Formación Área de Formación Administración de Oracle 1.01 20/07/2004 Curso de Administración de Oracle Word 2003 Ricardo Domingo Manual del curso de Administración de Oracle

DERECHOS DE USO: La presente documentación es propiedad de Aubay España, S.A., tiene carácter de confidencial y no podrá ser objeto de reproducción total o parcial, tratamiento informático ni transmisión de ninguna forma o por cualquier medio, ya sea electrónico, mecánico, por fotocopia, registro o cualquiera otro. Asimismo tampoco podrá ser objeto de préstamo, alquiler o cualquier forma de cesión de uso sin el permiso previo y escrito de Aubay España, S.A., titular del copyright. El incumplimiento de las limitaciones señaladas por cualquier persona que tenga acceso a la documentación será perseguida conforme a ley.

ESTADO FORMAL: Preparado por:

Revisado por:

Aprobado por:

Nombre: Ricardo Domingo

Nombre:

Nombre:

Fecha:

Fecha:

Fecha:

20/07/2004

5107-F03.V02

Administración de Oracle (V1.01)

Pág. 2


CONTROL DE VERSIONES VERSIÓN

PARTES QUE CAMBIAN

1.00

N/A

1.01

DESCRIPCIÓN DEL CAMBIO

FECHA DE CAMBIO

Documento original

16/06/2004

Corrección de diversos errores

20/07/2004


Pág. 3


ÍNDICE 1

INTRODUCCIÓN AL DOCUMENTO ...........................................................................8 1.1 1.2 1.3 1.4 1.5

2

OBJETO ............................................................................................................. ALCANCE ......................................................................................................... DESTINATARIOS ............................................................................................... DOCUMENTACIÓN DE REFERENCIA ...................................................................... CONVENCIONES NOTACIONALES.........................................................................

COMPONENTES DE LA ARQUITECTURA ORACLE ...................................................10 2.1 2.2 2.3

ESTRUCTURA DE LA BASE DE DATOS ...........................................................................10 FICHEROS DE LA BASE DE DATOS ORACLE ....................................................................11 INSTANCIA ORACLE...............................................................................................12

2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18

CONEXIÓN A UNA BASE DE DATOS .............................................................................14 PROCESAMIENTO DE UNA CONSULTA ...........................................................................15 EL CONJUNTO COMPARTIDO (SHARED POOL)..................................................................15 CACHE DE BUFFERS DE DATOS..................................................................................16 ÁREA GLOBAL DE PROGRAMAS (PGA) .........................................................................16 PROCESAMIENTO DE UNA SENTENCIA DML (INSERT, DELETE,UPDATE)..............................17 BUFFER DE REDO LOG .........................................................................................18 SEGMENTO DE ROLLBACK .....................................................................................18 PROCESAMIENTO COMMIT...................................................................................19 DATABASE WRITE (DBW)....................................................................................20 LOG WITER (LGWR) .........................................................................................20 SYSTEM MONITOR (SMON)..................................................................................21 PROCESS MONITOR (PMON) ................................................................................21 CHECKPOINT PROCESS (CKPT)..............................................................................21 ARCHIVER PROCESS (ARC) ..................................................................................21

2.3.1 2.3.2

3

4

8 8 8 8 8

Area Global del Sistema (SGA).................................................................................. 13 Procesos en Background .......................................................................................... 13

GESTIÓN DE UNA INSTANCIA DE BASE DE DATOS ORACLE..................................24 3.1

ARRANQUE DE UNA INSTANCIA DE BASE DE DATOS ...........................................................24

3.2

PARADA DE UNA INSTANCIA DE BASE DE DATOS ...............................................................26

3.3

FICHERO DE PARÁMETROS .......................................................................................28

3.4 3.5

VISTAS DINÁMICAS DE RENDIMIENTO ...........................................................................32

3.1.1

Comando de Arranque de una instancia de BD ............................................................ 26

3.2.1

Comando de Parada de una instancia de BD................................................................ 27

3.3.1

Parámetros Dinámicos ............................................................................................. 30

FICHERO ALERT Y DE RASTREO ..................................................................................33

CREACIÓN BASE DE DATOS ORACLE ....................................................................34 4.1

CONCEPTOS .......................................................................................................34

4.2

CREACIÓN DE UNA BASE DE DATOS MANUALMENTE ............................................................35

4.1.1 4.1.2 4.1.3

Consideraciones previas a la creación de la Base de Datos ............................................ 34 Planificación de la ubicación de los ficheros ................................................................. 34 Métodos para crear una Base de Datos....................................................................... 35


Pág. 4


4.2.1 4.2.2 4.2.3 4.2.4

4.3 5

6

EJEMPLO REAL .....................................................................................................38

CREACIÓN Y USO DEL DICCIONARIO DE DATOS Y PAQUETES ESTÁNDAR............40 5.1

VISIÓN GENERAL DEL DICCIONARIO DE DATOS ................................................................40

5.2

UNIDADES DE PROGRAMA ALMACENADAS .......................................................................42

5.3

CREACIÓN DEL DICCIONARIO DE DATOS .......................................................................44

5.4

EJEMPLO REAL .....................................................................................................48

5.1.1 5.1.2 5.1.3

Contenido del Diccionario de Datos ............................................................................ 40 Tablas Base y Vistas del Diccionario de Datos.............................................................. 41 Categorías del Diccionario de Datos ........................................................................... 41

5.2.1

Ejecución de una Unidad de Programa PL/SQL............................................................. 43

5.3.1 5.3.2

Ficheros de Comandos creación del Diccionario de datos requeridos ............................... 44 Ficheros de Comandos creación del Diccionario de datos opcionales................................ 47

GESTIÓN DE TABLESPACES Y FICHEROS DE DATOS .............................................50 6.1

JERARQUÍA DE ALMACENAMIENTO DE LA BASE DE DATOS .....................................................50

6.2 6.3 6.4 6.5 6.6

CREACIÓN DE TABLESPACES.....................................................................................52 MODIFICACIÓN DE TABLESPACES ...............................................................................57 BORRADO DE TABLESPACES......................................................................................60 VISTAS DEL DICCIONARIO DE DATOS SOBRE TABLESPACES...................................................61 EJEMPLO REAL .....................................................................................................61

6.1.1

7

7.1 7.2

CONCEPTO .........................................................................................................64 BLOQUES DE DATOS ..............................................................................................65

7.3

EXTENSIONES

7.4

SEGMENTOS .......................................................................................................70

Formato del bloque de datos..................................................................................... 65 Parámetros de Utilización de Espacio de Bloque ........................................................... 66 Parámetros que controlan la Simultaneidad................................................................. 68

.....................................................................................................69

7.3.1 7.3.2

Número y Tamaño de una Extensión .......................................................................... 69 Extensiones en Segmentos Temporales ...................................................................... 70

7.4.1 7.4.2 7.4.3 7.4.4 7.4.5 7.4.6

Segmentos de Datos ............................................................................................... 70 Segmentos de Índices.............................................................................................. 70 Segmentos Temporales............................................................................................ 71 Segmentos Rollback ................................................................................................ 71 Vistas del diccionario de datos sobre Estructuras de Almacenamiento ............................. 72 Fragmentación de Segmentos ................................................................................... 72

GESTIÓN DE SEGMENTOS DE ROLLBACK ..............................................................74 8.1

CONCEPTO .........................................................................................................74

8.2 8.3

TIPOS DE SEGMENTOS DE ROLLBACK ............................................................................75

8.4

VISTAS DEL DICCIONARIO DE DATOS SOBRE SEGMENTOS DE ROLLBACK....................................79

8.1.1

Uso y Asignación de Extensiones en Segmentos de Rollback .......................................... 74

CREACIÓN DE SEGMENTOS DE ROLLBACK .......................................................................76

8.3.1

9

Tablespaces ........................................................................................................... 51

SEGMENTOS, EXTENSIONES Y BLOQUES DE DATOS .............................................64

7.2.1 7.2.2 7.2.3

8

Configuración del Entorno del Sistema Operativo ......................................................... 35 Preparación del Fichero de Parámetros ....................................................................... 35 Inicio de la Instancia ............................................................................................... 36 Creación de la Base de Datos.................................................................................... 36

Activar/Desactivar/Borrar Segmentos de Rollback ........................................................ 78

GESTIÓN DE TABLAS............................................................................................81


Pág. 5


9.1 9.2

FORMATO Y TAMAÑO DE LAS FILAS ..............................................................................81

9.3

CREACIÓN DE TABLAS ............................................................................................86

9.4

MODIFICACIÓN DE TABLAS .......................................................................................90

9.5 9.6

TABLAS TEMPORALES

TIPOS DE DATOS ORACLE

........................................................................................82

9.2.1 9.2.2 9.2.3

Tipos de Datos Escalares .......................................................................................... 82 Recopilaciones ........................................................................................................ 85 Tipos de Datos de Relación ....................................................................................... 85

9.3.1 9.3.2 9.3.3 9.3.4

Instrucciones para la Creación de Tablas .................................................................... 88 Definición de PCTFREE y PCTUSED............................................................................. 88 Migración y Encadenamiento de Filas ......................................................................... 89 Control del Espacio Utilizado por las Tablas ................................................................. 89

9.4.1 9.4.2 9.4.3 9.4.4

Liberación de Espacio no Utilizado ............................................................................. 90 Truncado de una Tabla ............................................................................................ 91 Borrado de una Tabla .............................................................................................. 91 Borrado de una Columna.......................................................................................... 91

10

.............................................................................................92 VISTAS DEL DICCIONARIO DE DATOS SOBRE TABLAS .........................................................93 GESTIÓN DE ÍNDICES.....................................................................................95

10.1

CLASIFICACIÓN LÓGICA .......................................................................................95

10.2

CLASIFICACIÓN FÍSICA.........................................................................................96

10.3

CREACIÓN DE ÍNDICES ....................................................................................... 100

10.4

MODIFICACIÓN DE ÍNDICES

10.5

VISTAS DEL DICCIONARIO DE DATOS SOBRE ÍNDICES .................................................... 105

10.1.1 10.1.2 10.1.3 10.2.1 10.2.2 10.2.3 10.2.4 10.3.1 10.3.2 10.3.3 10.3.4 10.4.1 10.4.2 10.4.3 10.4.4

11

Índices Concatenados o de Columna Única............................................................... 95 Índices Únicos y No Únicos .................................................................................... 95 Índices basados en Funciones ................................................................................ 95

Estructura de un Índice B-Tree............................................................................... 96 Índice de Clave Invertida ...................................................................................... 97 Índices Bitmap .................................................................................................... 98 Comparación Índices B-Tree y Bitmap ................................................................... 100 Instrucciones en la Creación de Índices ................................................................. Creación de Índices B-Tree Normales .................................................................... Creación de Índices B-Tree de Clave Invertida........................................................ Creación de Índices Bitmap .................................................................................

100 101 102 102

................................................................................. 103

Cambio de los Parámetros de Almacenamiento para Índices ..................................... Asignación y Liberación de Espacio de Índice.......................................................... Reconstrucción de Índices ................................................................................... Borrado de Índices .............................................................................................

103 103 104 105

MANTENIMIENTO DE LA INTEGRIDAD DE LOS DATOS ..................................107

11.1

RESTRICCIONES DE INTEGRIDAD

11.2

IMPLEMENTACIÓN DE RESTRICCIONES

11.3 11.4

MANTENIMIENTO DE RESTRICCIONES....................................................................... 113

11.1.1 11.1.2 11.1.3 11.2.1 11.2.2

12 12.1

........................................................................... 107

Tipos de Restricciones ........................................................................................ 107 Restricciones Diferidas/No Diferidas ...................................................................... 108 Estados de Restricción ........................................................................................ 109

..................................................................... 110

Instrucciones para Definir Restricciones................................................................. 111 Consideraciones sobre la Clave Ajena.................................................................... 112

VISTAS DEL DICCIONARIO DE DATOS SOBRE RESTRICCIONES ........................................... 114

GESTIÓN DE USUARIOS................................................................................116 CREACIÓN DE USUARIOS


.................................................................................... 116

Pág. 6


12.2 12.3 12.4 13

MODIFICACIÓN DE USUARIOS ............................................................................... 118

SUPRESIÓN DE USUARIOS ................................................................................... 119 VISTAS DEL DICCIONARIO DE DATOS SOBRE USUARIOS .................................................. 119 GESTIÓN DE PRIVILEGIOS ...........................................................................121

13.1

PRIVILEGIOS DE SISTEMA

13.2

PRIVILEGIOS DE OBJETO ..................................................................................... 125

13.1.1 13.2.1

14

................................................................................... 121

Vistas Mostrar Privilegios del Sistema.................................................................... 124 Vistas Mostrar Privilegios de Objetos..................................................................... 126

GESTIÓN DE ROLES ......................................................................................127

14.1

CREACIÓN, MODIFICACIÓN, ASIGNACIÓN Y BORRADO DE ROLES ........................................ 127

14.2 14.3

ACTIVACIÓN Y DESACTIVACIÓN DE ROLES ................................................................. 129 VISTAS MOSTRAR INFORMACIÓN DE ROLES ............................................................... 129

14.1.1 14.1.2 14.1.3 14.1.4 14.1.5

15

Creación de Roles .............................................................................................. Modificación de Roles.......................................................................................... Asignación de Roles............................................................................................ Borrado de Roles ............................................................................................... Uso de Roles Predefinidos....................................................................................

127 127 128 128 128

UTILIDADES: IMPORT, EXPORT, SQL*LOADER .............................................132

15.1

EXPORT ........................................................................................................ 132

15.2

IMPORT ........................................................................................................ 135

15.3

SQL*LOADER

15.1.1 15.1.2 15.1.3 15.1.4 15.2.1 15.3.1

16 16.1 16.2 16.3 16.4 16.5

Modo Tabla ....................................................................................................... Modo Usuario .................................................................................................... Modo Base de Datos Completa ............................................................................. Parámetros de la utilidad Export...........................................................................

133 133 133 133

Parámetros de la utilidad Import .......................................................................... 135

................................................................................................. 137

Formato del Fichero de Control ............................................................................ 138

PRÁCTICAS...................................................................................................140 2: COMPONENTES DE LA ARQUITECTURA ORACLE ................................................. 140 3: GESTIÓN DE UNA INSTANCIA ORACLE ............................................................ 141 TEMA 4: CREACIÓN DE UNA BASE DE DATOS ORACLE .................................................... 141 TEMA 5: DICCIONARIO DE DATOS .......................................................................... 142 TEMA 6: GESTIÓN DE TABLESPACES Y FICHEROS DE DATOS ............................................. 142 TEMA TEMA


Pág. 7


1 INTRODUCCIÓN AL DOCUMENTO 1.1 OBJETO

Este documento contiene la información necesaria para iniciarse en la Administración Básica de Oracle de modo que, al finalizar el curso el alumno sea capaz de iniciarse directamente en el mantenimiento y gestión de bases de datos Oracle.

1.2 ALCANCE

Este documento puede utilizarse como guía de estudio autodidacta, o como ayuda a un curso tutelado.

1.3 DESTINATARIOS

Los destinatarios principales de este documento son las personas interesadas en iniciarse en la Administración Básica de Oracle.

1.4 DOCUMENTACIÓN DE REFERENCIA Documento

Referencia Versión

Documentación diversa http://otn.oracle.com Oracle9i DBA Fundamentos (I y II)

Fecha

Internet Internet Guía de Estudio Internet

http://metalink.oracle.com

1.5 CONVENCIONES NOTACIONALES Notación


Descripción

Pág. 8


Notación


Descripción

Pág. 9


2 COMPONENTES DE LA ARQUITECTURA ORACLE 2.1 ESTRUCTURA DE LA BASE DE DATOS Una base de datos ORACLE es un sistema de gestión de base de datos relacionales de objetos que proporciona un enfoque abierto. El objeto habitual de una base de datos es almacenar y recuperar información. Una base de datos puede estar abierta (accesible) o cerrada (inaccesible). En situaciones normales una base de datos está accesible y preparada para su utilización, sin embargo, hay veces que para realizar labores administrativas específicas la base de datos debe estar no accesible para los usuarios. Una base de datos Oracle está compuesta de tres partes básicas: • Memoria. Puede ser memoria asociada a procesos de usuario (PGA) y por lo tanto privada, o también memoria asociada al servidor Oracle, se llama memoria Compartida o SGA. Esta última zona de memoria son buffers que oracle toma del sistema operativo al tiempo de arrancar la BD; su tamaño está determinado por el fichero de inicialización de la base de datos, que se llama habitualmente init.ora (SID es el nombre de la BD). En la SGA se sitúan datos, información del diccionario de datos, gestión de bloqueos, etc… • Procesos. Existen dos tipos de procesos: Procesos de usuario, p.e. sqlplus, sqlforms….Procesos background o procesos de oracle como DBWR, LGWR… • Ficheros de Datos. Existen 3 tipos de ficheros: o REDO LOG: Sirven para mantener la consistencia en caso de fallo. o Fichero de Control: Contienen información para poder arrancar la BD, su nombre, fecha de creación, ficheros asociados a la BD, etc… o Ficheros de Datos: Son los ficheros donde se almacena la información de la BD. Una base de datos contempla 3 aspectos: • Estructuras: Son objetos definidos que almacenan la información de una BD. El acceso a las estructuras y los datos contenidos en ellas se realiza mediante operaciones. • Operaciones: Las operaciones son las acciones que nos permiten acceder y manipular los datos y las estructuras. Las operaciones en una BD suelen ajustarse a una serie de reglas de integridad predefinidas. • Reglas de Integridad: Son las leyes que rigen las operaciones que permiten acceder a los datos y manipularlos. Sirven para proteger los datos y las estructuras que los contienen. El servidor Oracle está formado por una instancia y una base de datos Oracle. • Instancia Oracle: Una instancia Oracle es la combinación de los procesos en background y las estructuras de memoria. Es necesario iniciar la instancia para acceder a los datos de la BD. Cada vez que se inicia una instancia se asigna un área global del sistema (SGA) y se inician los procesos en background Oracle. El SGA es una zona de memoria que se utiliza para almacenar la información de la base de datos que comparten los procesos asociados a la BD. Los procesos en background desempeñan funciones de E/S y supervisan a otros procesos para proporcionar un mayor paralelismo con el fin de conseguir un mejor rendimiento y fiabilidad.


Pág. 10


2.2 FICHEROS DE LA BASE DE DATOS ORACLE

Fig. 2.1 Ficheros BBD Oracle Una base de datos Oracle es una recopilación de datos que se tratan como una unidad. La base de datos tiene una estructura lógica y una física. La estructura física es el conjunto de ficheros del sistema operativo asociados a la BD. Una base de datos Oracle consta de tres tipos de ficheros: • Los ficheros de datos, que contienen los datos reales de la BD. Los datos se almacenan en tablas definidas por el usuario, pero también contienen el diccionario de datos, imágenes anteriores de los datos modificados, índices y otros tipos de estructuras. Las características de los ficheros de datos son las siguientes: o Un fichero de datos sólo puede estar asociado con una BD. o Los ficheros de datos pueden tener características definidas que les permiten extenderse de forma automática cuando el tamaño definido inicialmente se ha completado. o Uno o más ficheros de datos forman una unidad lógica de almacenamiento de base de datos conocida como tablespace. • Los ficheros de Redo Log, contienen registros de los cambios efectuados en la base de datos con el objeto de poder recuperar los datos en caso de fallos. Una base de datos Oracle necesita al menos dos ficheros de redo log. • Los ficheros de Control, contienen la información necesaria para mantener y verificar la integridad de la base de datos. Por ejemplo, un fichero de control se usa para identificar los ficheros de datos y redo log. Una base de datos Oracle necesita al menos un fichero de Control. El servidor Oracle también utiliza otros ficheros que no forman parte de la base de datos pero son necesarios para un correcto funcionamiento de la misma:


Pág. 11


Fig. 2.2 Ficheros Auxiliares BD Oracle • • •

El fichero de parámetros, define las características de una instancia Oracle. Por ejemplo contiene los parámetros que especifican el tamaño de las estructuras de la memoria en el SGA. Los ficheros del protocolo SQLNet, (listener.ora, tnsnames.ora y sqlnet.ora). Permiten el acceso a la base de datos por parte de las aplicaciones. Los ficheros Archive-Log, son copias de los ficheros redo log, que pueden ser necesarios para recuperar la BD en el caso de fallos del medio físico.

2.3 INSTANCIA ORACLE

Estructura de Memoria

Procesos en background

Fig. 2.3 Instancia BD Oracle Una instancia oracle se compone de la estructura de la memoria SGA y de los procesos en background que se utilizan para gestionar una base de datos. La instancia sólo podrá abrir y utilizar una base de datos a la vez.


Pág. 12


2.3.1 Area Global del Sistema (SGA)

Fig.2.4 SGA de una BD Oracle El SGA es una zona de memoria compartida que se utiliza para almacenar la información de la base de datos y que es compartida por los procesos de la BD. Contiene información de datos y de control para el servidor Oracle. El SGA está formada por diversas estructuras: • El conjunto compartido, se utiliza para almacenar las últimas sentencias SQL ejecutadas y los últimos datos utilizados por el diccionario de datos. Las sentencias SQL pueden ser enviadas por procesos de usuario o bien por procedimientos almacenados. • La caché de buffers, se utiliza para almacenar los últimos datos que se hayan utilizado. • El buffer de redo log, se utiliza por los procesos en background para hacer un seguimiento de los cambios realizados en la base de datos. Más adelante se explica en detalle las estructuras de la SGA. También hay otra estructura de memoria opcional en el SGA, el conjunto Java, se utiliza para almacenar código Java.

2.3.2 Procesos en Background

Fig.2.5 Procesos en Bakground de una BD Oracle


Pág. 13


Los procesos en background de una instancia tienen por objeto atender las solicitudes de usuarios simultáneos sin comprometer la integridad ni el rendimiento del sistema. En función de la configuración de la instancia Oracle se pueden incluir diferentes procesos en background, aunque cada instancia incluye siempre estos cinco procesos: • • • • •

Database Write (DBW0): Es el responsable de escribir los datos cambiados desde la caché de buffers de base de datos en los ficheros de datos. Log Writer (LGWR): Escribe los cambios registrados en el buffer de redo log a los ficheros Archive-Log. El Monitor del Sistema (SMON): Comprueba la consistencia de la BD y si es necesario inicia la recuperación de la base de datos cuando se abre. El Monitor de Procesos (PMON): Limpia los recursos si falla uno de los procesos. El Proceso de Punto de Control (CKPT): Es el responsable de actualizar la información de estado de la BD de los ficheros de control y de datos.

2.4 CONEXIÓN A UNA BASE DE DATOS

Fig.2.6 Conexión a una BD Antes que los usuarios puedan enviar sentencias SQL a Oracle se deben conectar a una instancia: • El usuario inicia una aplicación, por ejemplo sqlplus. Esta aplicación se ejecutará en un proceso de usuario. • En la configuración más básica, cuando un usuario se conecta a un servidor Oracle, se crea un proceso en el equipo que ejecuta el servidor Oracle. A este proceso se le llama proceso de servidor y se comunicará con la instancia Oracle en nombre del proceso del usuario que se ejecuta en el cliente. El proceso de servidor ejecutará las sentencias SQL en nombre del usuario. • Una conexión no es más que una ruta de comunicación entre un proceso de usuario y una instancia Oracle.


Pág. 14


En estos casos hay una correspondencia uno a uno entre un proceso de usuario y de servidor, y se denomina conexión de servidor dedicado. Cuando se utiliza una configuración de servidor multithread (MTS), muchos procesos de usuario podrán compartir un proceso de servidor.

2.5 PROCESAMIENTO DE UNA CONSULTA Las consultas son diferentes a otros tipos de sentencias SQL, ya que, si son correctas devuelven los datos como resultados y otras sentencias SQL devuelven éxito o fallo al procesamiento de dicha sentencia. Tres son las etapas principales en el procesamiento de una consulta: 1. Análisis 2. Ejecución 3. Recuperación Análisis de una Sentencia SQL: Durante esta etapa la sentencia SQL se transfiero del proceso de usuario al de servidor y se carga una representación analizada de la sentencia en un área SQL compartida. Durante el análisis el proceso servidor: • • • • • • •

Busca una copia existente de la sentencia en el zona de memoria compartida. Valida la sentencia SQL comprobando su sintaxis. Realiza búsquedas en el diccionario de datos para validar las definiciones de tablas y columnas. Establece bloqueos de análisis en objetos de forma que no cambien sus definiciones durante el análisis de la sentencia. Comprueba los privilegios que el usuario dispone para acceder a los objetos que se referencian en la consulta. Determina el plan de ejecución óptimo de la sentencia. Carga la sentencia y el plan de ejecución en un área SQL compartida.

La etapa de análisis incluye el procesamiento de los requisitos que, normalmente, sólo se deben realizar una vez, independientemente de las veces que se ejecute la sentencia. El análisis sólo identifica los errores que puedan encontrarse antes de ejecutar la sentencia, con lo cual hay ciertos errores que se van a escapar de la fase de análisis y sólo pueden notificarse durante la etapa de ejecución. Ejecución de una Sentencia SELECT: El servidor Oracle dispone de toda la información y recursos necesarios, por lo que se ejecuta la sentencia. Recuperación de las Filas de una Consulta: El servidor selecciona, ordena (si es necesario) y devuelve los registros al usuario.

2.6 EL CONJUNTO COMPARTIDO (SHARED POOL)


Pág. 15


Durante la etapa de análisis de una sentencia SQL, el proceso de servidor utiliza el área del SGA, conocida como conjunto compartido para compilar la sentencia SQL. Este conjunto está formado de dos componentes principales: • Caché de biblioteca. • Caché del diccionario de datos. Caché de Biblioteca: Almacena información acerca de las últimas sentencias SQL que se hayan utilizado, y contiene: • • •

El texto de la sentencia SQL El árbol de análisis: Una versión compilada de la sentencia. El plan de ejecución: Los pasos a seguir cuando se ejecuta la sentencia. El optimizador es la función del servidor Oracle que determina el plan de ejecución óptimo.

Si se vuelve a ejecutar una sentencia SQL y un área SQL compartida ya dispone del plan de ejecución de dicha sentencia, el proceso de servidor no necesitará analizar la sentencia. De esta forma la caché de biblioteca mejora el rendimiento de las aplicaciones que vuelven a utilizar las sentencias SQL, reduciendo el tiempo de análisis y los requisitos de memoria. Si la sentencia SQL no se vuelve a utilizar, al final caducará en dicha caché y será reemplazada aplicando el algoritmo LRU. Caché del Diccionario de Datos: Es una colección de las últimas definiciones utilizadas en la base de datos. Incluye información acerca de los archivos de datos, columnas, usuarios, privilegios y otros objetos de la BD. Durante la fase de análisis, el proceso servidor busca información en dicha caché para validar los privilegios de acceso. Si fuese necesario el proceso servidor inicia la carga de esta información de los archivos de datos. Especificación del Tamaño del Conjunto Compartido: El tamaño del conjunto compartido lo especifica el parámetro de inicialización SHARED_POOL_SIZE.

2.7 CACHÉ DE BUFFERS DE DATOS Cuando se procesa una consulta, el proceso servidor busca en la caché de buffers de datos los bloques que necesita. Si no se encuentra el bloque en la caché de datos, entonces el proceso servidor lee el bloque en el archivo de datos y coloca una copia en dichos buffers. De esta forma las siguientes solicitudes para el mismo bloque encontrarán el bloque en memoria, y dichas solicitudes no necesitarán realizar lecturas físicas. El servidor Oracle utiliza el algoritmo LRU para hacer caducar los buffers a los que se ha accedido recientemente, para dejar sitio a los nuevos bloques en la caché de buffers. Especificación del Tamaño de la Caché de Buffers de la Base de Datos: El tamaño de cada buffer en la caché de buffers equivale al tamaño de un bloque de oracle, y lo especifica el parámetro DB_BLOCK_SIZE. El número de buffers equivale al valor del parámetro DB_BLOCK_BUFFERS.

2.8 ÁREA GLOBAL DE PROGRAMAS (PGA)


Pág. 16


Es una región de la memoria que posee los datos y la información de los controles de un único proceso de servidor o de un único proceso en background. A diferencia del SGA, que comparten varios procesos, el PGA es un área que sólo utiliza un proceso. En una configuración de servidor dedicado, el PGA de servidor incluye los siguientes componentes: Área de ordenación: Se utiliza para cualquier ordenación necesaria para procesar la sentencia SQL. • Información de la sesión: Incluye los privilegios de usuario y las estadísticas del rendimiento de la sesión. • Estado del Cursor: Indica la etapa en el procesamiento de las sentencias que la sesión utiliza en ese momeno. • Espacio de la Pila: Contiene otras variables de la sesión. El PGA se asigna cuan se crea un proceso y se libera cuando dicho proceso termina. Si se utiliza una configuración de servidor Multithread (MTS) entonces algunas de estas estructuras se almacenarán en el SGA. Gracias a una configuración MTS, es posible que muchos procesos de usuario compartan un único proceso de servidor.

2.9 PROCESAMIENTO DELETE,UPDATE)

DE

UNA

SENTENCIA

DML

(INSERT,

Fig.2.7 Procesamiento de una sentencia DML Una sentencia del Lenguaje de Manipulación de Datos (DML) sólo requiere dos fases de procesamiento: • Análisis, es la misma que la utilizada para procesar una consulta. • Ejecución, requieren de un procesamiento adicional para efectuar cambios de datos. Fase de Ejecución DML Para ejecutar una sentencia DML:


Pág. 17


1. Si los bloques de datos y de rollback no están en la caché de buffers, el proceso de servidor los leerá en los ficheros de datos y los llevará a dicha caché. 2. El proceso servidor realiza los bloqueos en las filas que se deben modificar. 3. En el buffer de redo log, el proceso servidor registra los cambios que se deban efectuar en el rollback y en los datos. • Los cambios del bloque de rollback registran los valores de los datos antes que se modifiquen. El bloque de rollback se utiliza para almacenar la imagen anterior de los datos, de forma que se puedan deshacer los cambios de las sentencias DML si fuera necesario. • Los cambios de los bloques de datos registran los nuevos valores de los datos. 4. El proceso de servidor registra la imagen anterior en el bloque de rollback y actualiza el bloque de datos. Estos dos cambios se llevan a cabo en la caché de buffers de datos. Cualquier bloque que se cambie en el caché de buffers ser marcará como buffer sucio, es decir, aquellos buffers que no son los mismos que los bloques correspondientes en el disco.

2.10 BUFFER DE REDO LOG El proceso de servidor registra la mayor parte de los cambios efectuados a los bloques de archivos de datos en el buffer de redo log, que es una parte de la SGA. El buffer de redo log tiene las siguientes características: • Su tamaño en bytes lo define el parámetro LOG_BUFFER. • Registra el bloque que se modifica, la ubicación del cambio y el nuevo valor, en un registro de redo. Un registro redo no distingue el tipo de bloque que se cambia, simplemente registra los bytes que se cambian en el bloque. • El buffer de redo log se usa de forma secuencial, y los cambios que lleve a cabo una transacción se pueden intercalar con los efectuados por otras transacciones. • Se trata de un buffer circular que se vuelve a utilizar después de llenarlo, aunque únicamente cuando los registros de redo se hayan registrado en los ficheros de redo log.

2.11 SEGMENTO DE ROLLBACK Antes de realizar un cambio, el proceso de servidor guarda el valor de datos antiguo en un segmento de rollback. Esta imagen anterior se utiliza para: • Deshacer los cambios en caso de anular la transacción. • Proporciona consistencia de lectura, asegurándose que otras transacciones no vean los cambios no validados realizados por la sentencia DML. • Recuperar la consistencia del estado de la base de datos en caso de fallo. Los segmentos de rollback como las tablas y los índices, existen en los archivos de datos, mientras que los bloques de rollback se introducen en el buffer de base de datos a medida que se necesitan. Los cambios efectuados en los segmentos de rollback se registran en el buffer de redo log.


Pág. 18


2.12 PROCESAMIENTO COMMIT

Fig.2.8 Procesamiento del COMMIT La sentencia SQL “COMMIT” es el mecanismo que utiliza Oracle para confirmar los datos de una transacción en la base de datos, y que dichos cambios puedan ser visualizados por el resto de los usuarios. Siempre que se valida una transacción, el servidor Oracle asigna un número de cambio del sistema de validación (SCN) a la transacción. El SCN se incrementa regularmente y es único en la base de datos. Este número lo utiliza el servidor Oracle como un registro interno para sincronizar los datos y proporcionar consistencia de lectura cuando se recuperan datos de archivos de datos. Pasos para el Procesamiento de COMMIT A continuación se muestran los pasos que a seguir cuando se emite la sentencia COMMIT: 1. El proceso de servidor coloca un registro de validación, junto con el SCN, en el buffer de redo log 2. El proceso LGWR realiza una escritura contigua de todos los registros de buffers de redo log hasta ese momento e incluye el registro de validación en los archivos de redo log. De esta forma el servidor Oracle garantiza que los cambios no se perderán si falla la instancia. 3. Se informa al usuario que el COMMIT ha finalizado 4. El proceso de servidor registra la información para indicar que la transacción está completa y que los bloqueos de recursos se pueden liberar. El proceso DBW0 llevará a cabo el vaciado de los buffers de datos sucios en los ficheros de datos, y dicha acción la podrá realizar antes o después de la validación.


Pág. 19


El hecho de deshacer una transacción (ROLLBACK) no dispara la escritura en disco del proceso LGWR. El servidor Oracle deshace los cambios no validados cuando se recupera de fallos. En caso que aparezca un fallo después de deshacer, antes de registrar los registros de rollback en disco, la ausencia de un registro de validación será suficiente para asegurar que se desharán los cambios realizados por la transacción.

2.13 DATABASE WRITE (DBW) El proceso de servidor registra los cambios en los bloques de rollback y de datos en la caché de buffers. El proceso DBW0 escribe los buffers sucios de la caché de buffers de base de datos en los ficheros de datos. Se asegura que haya un número suficiente de buffers libres, es decir, buffers que se puedan sobrescribir cuando los procesos de servidor necesiten leer bloques de los archivos de datos hacia la caché de buffers de base de datos. El rendimiento de la base de datos es mucho mejor, ya que los procesos de servidor sólo realizan cambios en la caché de buffers, y el proceso DBW0 difiere la escritura a los archivos de datos hasta que se produzca uno de los siguientes eventos: • • • •

El número de buffers sucios alcanza un valor umbral. Un proceso explora un número determinado de bloques cuando explora buffers libres y no puede encontrar ninguno. Se produce un timeout cada tres segundos. Se produce un punto de control. Un punto de control es un medio de sincronizar la caché de buffer de base de datos con el archivo de datos.

El parámetro de inicialización DB_WRITER_PROCESSES determina el número de procesos DBWn. El proceso DBW0 escribe los buffers de datos aplicando el algoritmo LRU.

2.14 LOG WITER (LGWR) El proceso LGWR realiza escrituras secuenciales desde el buffer de redo log al archivo redo log en las siguientes situaciones: • • • •

Cuando se valida una transacción. Cuando el buffer de redo log se encuentra a un tercio de su capacidad. Cuando se registra más de un MB de cambios en el buffer de redo log. Antes que el proceso DBW0 escriba los bloques modificados de la caché de buffers de base de datos en los archivos de datos.

Este proceso escribe de forma síncrona en los grupos de ficheros redo log online que se deben encontrar en configuración mirror. Si uno de los ficheros del grupo está inaccesible, el proceso continúa escribiendo en otros ficheros del grupo, mostrando un error en el fichero de la alerta de la instancia. Si todos los ficheros de un grupo están inaccesibles, entonces este proceso no podrá realizar su función. Si el proceso DBW0 al tiempo de escribir en los ficheros de datos encuentra registros redo que no han sido escritos en los ficheros de redo log, entonces indica al proceso LGWR que debe escribir dichos registros en los ficheros redo, esperando el proceso DBW0 a que se complete dicha operación para que pueda escribir en los ficheros de datos.


Pág. 20


2.15 SYSTEM MONITOR (SMON) Si falla la instancia Oracle se perderá toda la información contenida en el SGA que no se haya escrito en el disco. Una vez que se haya perdido la instancia el proceso SMON realiza automáticamente una recuperación de la información no guardada cuando la base de datos se vuelve a abrir. La recuperación de esta información se hace de la siguiente forma: 1. Se aplican transacciones pendientes para recuperar los datos que no se hayan registrado en los ficheros de redo log. Estos datos no se han escrito en los ficheros de datos debido al fallo de la instancia. Durante el proceso de arranque, SMON lee los ficheros redo log y aplica los cambios registrados en el redo log hacia los bloques de datos. Como todas las transacciones validadas se han escrito en los redo log, este proceso recupera completamente dichas transacciones. 2. Se deshacen las transacciones no validadas. Es SMON o los procesos de servidor individual los que las deshacen a medida que acceden a los datos no bloqueados. Este proceso SMON también realiza funciones de mantenimiento del espacio: • Combina o fusiona las áreas adyacentes de espacio libre en los ficheros de datos. • Libera segmentos temporales para devolverlos como espacio libre en los ficheros de datos. Los segmentos temporales se utilizan para almacenar datos durante el procesamiento de sentencias SQL.

2.16 PROCESS MONITOR (PMON) El proceso PMON hace una limpieza cuando los procesos del usuario han fallado: • Deshace los cambios de las transacciones actuales del usuario • Libera los bloqueos de tablas o filas • Libera otros recursos que el usuario haya reservado hasta ese mometo. Otra de las funciones que realiza el proceso PMON es registrar la instancia con el proceso listener del protocolo SQLNet.

2.17 CHECKPOINT PROCESS (CKPT) En un instante de tiempo dado, todas las modificaciones realizadas en los buffers de datos del SGA van a ser escritos en los ficheros de datos a través del proceso DBW; Este evento se llama checkpoint. el proceso Checkpoint es el responsable de indicar al proceso DBW los eventos checkpoints y actualizar todos los ficheros de datos y de control de la base de datos.

2.18 ARCHIVER PROCESS (ARC) Este proceso es fundamental para la recuperación de una base de datos tras la pérdida de un disco. A medida que se llenan los ficheros de redo log de un grupo, el servidor Oracle comienza a escribir en los ficheros de redo log de otro grupo. A este proceso de cambiar de redo log es lo que se llama cambio de log.


Pág. 21


Una de las decisiones importantes que debe tomar un DBA es si debe configurar la instancia en modo ARCHIVELOG o modo NOARCHIVELOG. Modo NOARCHIVELOG En este modo, los ficheros de redo log se sobrescriben cada vez que se produce un cambio de log. Sin embargo el proceso LGWR no sobrescribirá un grupo de redo log hasta que el punto de control se haya completado para ese grupo. Esto asegura que los datos validados se pueden recuperar si se produce un error de la instancia. Durante el error de la instancia solo se perderá la información almacenada en la SGA y no guardada en los ficheros de redo log. Modo ARCHIVELOG En caso de que la instancia se configure para trabajar en modo ARCHIVELOG, será necesario archivar los grupos de redo log llenos antes que se puedan volver a utilizar de nuevo. Como los cambios efectuados en la base de datos se registran en los ficheros de redo log y si está configurada en este modo dichos registros se guardan en los ficheros ARCHIVELOG, se podrá recuperar una base de datos de forma completa en caso de fallo en disco. Generalmente se suele configurar una base de datos de producción en este modo. Proceso ARC0 Este proceso realiza copias de seguridad de los ficheros de redo log llenos en cada cambio de log. Para llevar a cabo el archivado de forma automática es necesario que el parámetro ARCHIVE_LOG_START esté establecido a true.


Pág. 22


Fig. 2.9Ficheros,SGA y Procesos BD Oracle


Pág. 23


3 GESTIÓN DE UNA INSTANCIA DE BASE DE DATOS ORACLE

Fig. 3.1Arrnque y Parada Instancia Oracle

3.1 ARRANQUE DE UNA INSTANCIA DE BASE DE DATOS Una base de datos Oracle no está disponible a los usuarios hasta que haya sido iniciada la instancia y abierta la base de datos. A continuación se muestran los eventos que se producen durante el inicio de una base de datos. En cada evento la base de datos Oracle atraviesa varias etapas: 1. Inicio de una instancia 2. Montaje de la base de datos 3. Apertura de la base de datos Cada vez que se inicia una instancia, Oracle utiliza un fichero de parámetros, que contiene los parámetros de inicialización para asignar el SGA e iniciar los procesos en background. Si se inicia la instancia y se abre una base de datos, los pasos a seguir para cerrar dicha base de datos, son: 1. Cerrar la base de datos 2. Desmontar la base de datos 3. Cerrar la instancia Inicio de la Instancia El inicio de una instancia incluye las siguientes tareas: • •

Lectura del fichero de parámetros Asignación del SGA


Pág. 24


• •

Inicio de los procesos en background Apertura del fichero de alerta

Montaje de la Base de Datos Este estado está especificado para realizar operaciones de mantenimiento, por ejemplo, durante las siguientes tareas: • • •

Cambio del nombre de los ficheros de datos Activación y desactivación de las opciones de archivado redo log Recuperación completa de una base de datos

El montaje incluye las siguientes tareas: • • •

Asociación de una base de datos con una instancia iniciada previamente Ubicación y apertura de los ficheros de control especificados en el fichero de parámetros Lectura de los ficheros de control para obtener los nombres y el estado de los ficheros de datos y redo log

Apertura de la Base de Datos La operación normal de la base de datos significa que se inicia una instancia y que la base de datos se monta y se abre; lo que permite que cualquier usuario se conecte a la misma y realice operaciones de acceso a los datos. La apertura de la base de datos incluye las siguientes tareas: • •

Apertura de los ficheros de datos Apertura de los ficheros redo log

Si no apareciese alguno de los ficheros de datos o de redo log, el servidor Oracle devolverá un error. Durante esta etapa final el servidor Oracle comprueba que todos los ficheros de datos y de redo log se pueden abrir y comprueba la consistencia de la base de datos. Si fuese necesario, el proceso SMON iniciaría la recuperación de la instancia. Recuperación de la Instancia El proceso en background SMON lleva a cabo automáticamente la recuperación de la instancia en caso de que haya existido un fallo de la misma. Este proceso utiliza los ficheros de redo log para recuperar los datos validados en la caché de buffers de la base de datos que se perdió debido al fallo de la instancia.

La recuperación de la instancia consta de los siguientes pasos: 1. Aplicación de las transacciones pendientes para recuperar los datos que no se hayan registrado en los ficheros de datos, sino en los redo log 2. Apertura de la base de datos, en lugar de esperar que se apliquen todas las transacciones pendientes antes de que la base de datos esté disponible de nuevo.


Pág. 25


3. Aplicación de las transacciones no validadas por los procesos de servidor a medida que acceden a los datos bloqueados.

3.1.1 Comando de Arranque de una instancia de BD El Servidor Oracle utiliza el comando STARTUP para arrancar una instancia de base de datos. STARTUP [FORCE][RESTRICT][PFILE=nombrearchivo] [OPEN [RECOVER] [basededatos]| MOUNT | NOMOUNT] • • • • • • •

OPEN: Permite que los usuarios accedan a la base de datos. MOUNT: Monta la base de datos para ciertas actividades de DBA. NOMOUNT: Crea el SGA e inicia los procesos en segundo plano. PFILE: Permite el uso de un archivo de parámetros no por defecto para configurar la instancia. FORCE:Aborta la instancia en ejecución antes de realizar un inicio normal. RESTRICT: Sólo permite el acceso a los usuarios con el privilegio RESTRICTED SESSION. RECOVER:Comienza la recuperación del medio físico.

3.1.1.1Cambio de la disponibilidad de la Base de Datos Para abrir la base de datos desde una etapa STARTUP NOMOUNT a otra MOUNT o desde MOUNT a OPEN, es necesario utilizar el comando ALTER DATABASE. ALTER DATABASE { MOUNT | OPEN } Para evitar que las transacciones de usuario modifiquen la información contenida en la base de datos, oracle permite abrir las base de datos en modo solo lectura. Para iniciar una instancia en este modo se puede ejecutar el siguiente comando: ALTER DATABASE OPEN [ READ WRITE | READ ONLY ] Donde READ WRITE abre la base de datos en modo lectura escritura, lo que permite que los usuarios generen registros de redo log y en READ ONLY restringe a los usuarios a transacciones de solo lectura, evitando que los usuarios generen información de redo log. La utilización de una base de datos en modo solo lectura está especialmente diseñada para tiempos en los que la base de datos de producción se encuentre realizando operaciones de mantenimiento y no se desea que los usuarios prescindan de consultar la información contenida en la base de datos.

3.2 PARADA DE UNA INSTANCIA DE BASE DE DATOS Cierre de la Base de Datos Cuando se cierra la base de datos el servidor Oracle escribe los cambios de la caché de buffers y los registros de la caché de buffers de redo log en los ficheros de datos y en los ficheros de redo log respectivamente. Después de esta operación, cierra todos los ficheros de datos y de


Pág. 26


redo log. Los ficheros de control permanecen abiertos mientras una base de datos esté cerrada pero todavía montada. Desmontaje de la Base de Datos El segundo paso es desmontar la base de datos de una instancia. Una vez desmontada sólo quedará la instancia, esto es, los procesos en background y la SGA. Cuando se desmonta una base de datos el servidor Oracle cierra los ficheros de control. Cierre de la Instancia El último paso es cerrar la instancia, en el cual, se cerrarán los ficheros de alerta, se libera la memoria ocupada por la SGA y se terminan todos los procesos en background.

3.2.1 Comando de Parada de una instancia de BD El Servidor Oracle utiliza el comando SHUTDOWN para parar una instancia de base de datos. SHUTDOWN [NORMAL | TRANSACTIONAL | IMMEDIATE | ABORT] •

NORMAL: Es el modo de cierre por defecto. Este cierre se lleva a cabo en las siguientes condiciones: o o o o

•

TRANSACTIONAL: Evita que los clientes pierdan trabajo. Un cierre transaccional de la base de datos se lleva a cabo en las siguientes condiciones: o o o o

•

No se permiten nuevas conexiones. El servidor Oracle espera a que se desconecten todos los usuarios antes de completar el cierre. Oracle cierra y desmonta la base de datos antes de cerrar la instancia. El siguiente inicio no requiere una recuperación de la instancia.

Ningún cliente puede iniciar una nueva transacción en la instancia. Un cliente se desconecta cuando finaliza la transacción en curso. Una vez finalizadas todas las transacciones, se produce un cierre inmediato. El siguiente inicio no requiere una recuperación de la instancia.

IMMEDIATE: Este cierre se lleva a cabo en las siguientes condiciones: o o o o o

No se completan las sentencias SQL que está procesando en ese momento el servidor Oracle. El servidor Oracle no espera hasta que se desconecten los usuarios actuales en la base de datos. Oracle deshace las transacciones activas. Oracle cierra y desmonta la base de datos antes de cerrar la instancia. El siguiente inicio no requiere una recuperación de la instancia.


Pág. 27


•

ABORT: Si las opciones de cierre inmediato y normal no funcionan, entonces es necesario abortar la instancia de base datos. La interrupción de una instancia se lleva a cabo en las siguientes condiciones: o o o o o

Se terminan inmediatamente las sentencias SQL que el servidor Oracle está procesando. Oracle no espera hasta que se desconecten los usuarios. Oracle no deshace las transacciones no validadas. La instancia se termina sin cerrar los ficheros. El siguiente inicio requiere la recuperación de la instancia. Modo de cierre Permitir nuevas conexiones Esperar a que finalicen las sesiones actuales Esperar a finalicen las transacciones actuales Forzar un punto de comprobación y cerrar los archivos

A X X X X

I X X X O

T X X O O

N X O O O

3.3 FICHERO DE PARÁMETROS El fichero de parámetros, al que generalmente se le denomina init.ora. Es un fichero de texto que se puede mantener a través de un editor estándar del sistema operativo. Por defecto se ubica en el directorio $ORACLE_HOME/dbs en una máquina UNIX. Este fichero sólo se lee durante el inicio de la instancia. Si se modifica el fichero, se debe reiniciar la instancia para que los valores de los parámetros modificados, tengan efecto. En la versión 9 y posteriores de Oracle se ha mejorado esta deficiencia ya que permite modificar los parámetros online y almacenarlos en el fichero spfile.ora. Este fichero no se puede modificar por un editor estándar del sistema, lo gestiona el propio servidor Oracle. Los parámetros de este fichero pueden tener un efecto trascendente en el rendimiento de la base de datos y es necesario modificar dichos parámetros en función del sistema en producción. Algunos de dichos parámetros determinan: • • • • • •

Especifica el tamaño de los componentes de la SGA para optimizar el rendimiento Define los valores por defecto de la base de datos y de la instancia Define los límites de los usuarios o de los procesos Define los límites de los recursos de la base de datos Define los distintos atributos físicos de la base de datos, como el tamaño del bloque de datos Especifica los ficheros de control, los archive log, el fichero de alerta…

Generalmente el servidor Oracle tiene un valor por defecto para cada parámetro. Este valor depende del sistema operativo. Los parámetros se pueden especificar en cualquier orden. Se pueden incluir ficheros adicionales con la palabra clave IFILE e indicando el nombre y ruta del fichero que se desea incluir. A continuación se muestra un fragmento de un fichero de parámetros real de producción:


Pág. 28


control_files

= (//ctrl1.ctl, //ctrl2.ctl, //ctrl3.ctl)

background_dump_dest

= /admin//bdump

core_dump_dest

= /admin//cdump

user_dump_dest

= /admin//udump

log_archive_dest = /admin//arch/arch.log nls_date_format

= 'yyyymmddhh24miss'

db_name

=

rollback_segments

= (r1_01,r1_02,r1_03,r1_04,r2_01,r2_02,r2_03,r2_04)

db_files = 100 db_block_size = 8192 db_file_multiblock_read_count = 8 db_block_buffers = 3200 shared_pool_size = 10000000 log_checkpoint_interval = 10000 processes = 50 parallel_max_servers = 5 dml_locks = 200 log_buffer =

65536

sort_area_size = 524288 sort_area_retained_size = 262144 optimizer_mode = RULE audit_trail = true #timed_statistics = true max_dump_file_size = 10240 log_archive_start = true


Pág. 29


global_names = FALSE open_cursors = 300 compatible = 8.1.0 utl_file_dir =* Entre los parámetros que se deben especificar y que se modifican frecuentemente están: Parámetro BACKGROUND_DUMP_DES T COMPATIBLE CONTROL_FILES DB_BLOCK_BUFFERS DB_NAME SHARED_POOL_SIZE USER_DUMP_DEST LOG_BUFFER MAX_DUMP_FILE_SIZE PROCESSES SQL_TRACE TIMED_STATISTICS OPEN_CURSORS

Descripción Indica la ubicación donde se escriben los ficheros de rastreo por los procesos en background. También se incluye el fichero de Alerta del servidor Oracle. Versión de Oracle con el que la instancia será compatible. Indica la ruta y los nombres de los ficheros de control. Número de bloques copiados en la memoria caché dentro del SGA Identificador del nombre de la base de datos. Este valor no puede superar los 8 caracteres. Es el único requisito para crear la base de datos. Tamaño en bytes del conjunto compartido. Ubicación donde se crean los ficheros de rastreo de los procesos de usuario. Número de bytes asignados al buffer de redo log dentro del SGA. Tamaño máximo de los ficheros de rastreo. Número máximo de procesos del sistema operativo que se pueden conectar simultáneamente a una instancia. Activa o desactiva la utilidad de rastreo SQL por cada sesión de usuario. Activa o desactiva la temporización en los ficheros de rastreo. Indica el número máximo de cursores que pueden tener abiertos la instancia de la base de datos.

Las definiciones de los valores de los parámetros en una base de datos se pueden consultar en la vista del diccionario de datos V$PARAMETER o bien ejecutando el comando SHOW PARAMETER.

3.3.1 Parámetros Dinámicos Algunos parámetros de inicialización son dinámicos, esto es, se pueden modificar una vez inicializada la base de datos. Los comandos que permiten realizar dichas son modificaciones son: • ALTER SESSION


Pág. 30


• •

ALTER SYSTEM ALTER SYSTEM DEFERRED ALTER SESSION SET nombre_parametro = valor ALTER SYSTEM SET nombre_parametro = valor [DEFERRED]

El comando ALTER SESSION modifica el valor del parámetro sólo en la sesión desde donde se esté ejecutando. El comando ALTER SYSTEM cambia globalmente el valor del parámetro. El nuevo parámetro será eficaz hasta que se cierre la base de datos. Si se desea hacer permanente este cambio será necesario modificar el fichero de parámetros. En la versión 9 y posteriores de oracle esto se puede evitar si el fichero de parámetros que se usa para arrancar la instancia es el spfile.ora. El comando ALTER SYSTEM DEFERRED modifica el valor del parámetro para las futuras sesiones que se conecten a la base de datos. Se puede consultar la vista el diccionario de datos V$SYSTEM_PARAMETER para obtener que parámetros se pueden modificar. SQL> SELECT isses_modifiable,issys_modifiable,ismodified,name V$SYSTEM_PARAMETER WHERE ismodified <> ‘FALSE’;

FROM

Las columnas muestran la siguiente información: • • •

isses_modifiable, indica si el parámetro se puede modificar por el comando ALTER SESSION. issys_modifiable, indica si el parámetro se puede modificar por el comando ALTER SYSTEM. Ismodified, si el valor es MODIFIED ha sido modificado por un comando ALTER SESSION, y si el valor es SYS_MODIFIED indica que ha sido modificado por un comando ALTER SYSTEM.

La vista V$PARAMETER muestra los valores actuales de la sesión y V$SYSTEM_PARAMETER muestra los valores actuales del sistema independientes de la sesion. Los comandos ALTER SYSTEM o ALTER SYSTEM DEFERRED se registran en el fichero de rastreo ALERT. Ejemplos de utilización de estos comandos: ALTER SESSION SET SQL_TRACE = TRUE; ALTER SYSTEM SET TIMED_STATISTICS = TRUE; ALTER SYSTEM SET SORT_AREA_SIZE = 131072 DEFERRED; ALTER SYSTEM SET SHARED_POOL_SIZE = 64M; ALTER SYSTEM SET DB_CACHE_SIZE = 96M;


Pág. 31


3.4 VISTAS DINÁMICAS DE RENDIMIENTO Se llaman vistas dinámicas de rendimiento ya que se actualizan constantemente, (por el servidor Oracle) mientras la base de datos permanece abierta y se utilice. Su contenido está relacionado con el rendimiento. Proporciona datos acerca de las estructuras físicas (ficheros) y lógicas (memoria) de la base de datos. Las vistas dinámicas de rendimiento se identifican con el prefijo V_$ aunque Oracle proporciona sinónimos públicos con el prefijo V$. Una vez iniciada la instancia en la etapa NOMOUNT, se podrá acceder a las vistas dinámicas que se pueden leer desde la memoria. Las vistas que lean datos desde los ficheros de control precisarán que la base de datos esté montada. La vista V$FIXED_TABLE muestra todas las vistas dinámicas de rendimiento. Ejemplo de un conjunto de vistas dinámicas: Nombre V$PARAMETER

Descripcion

V$CONTROLFILE

Contiene información acerca de los parámetros de incialización Contiene información resumida sobre el SGA Enumera las opciones que se instalan en el servidor Contiene información acerca de los procesos activos actualmente Enumera la información de la sesión actual Enumera el número de versión y componentes Muestra el estado de la instancia actual Contiene información del thread, por ejemplo de los grupos de redo log Enumera los nombres de los ficheros de control

V$DATABASE

Contiene información sobre la base de datos

V$DATAFILE

Contiene información de ficheros de datos y de los ficheros de control Contiene información acerca de la cabecera de los ficheros de datos y de los ficheros de control Contiene información acerca los ficheros de redo log

V$SGA V$OPTION V$PROCESS V$SESSION V$VERSION V$INSTANCE V$THREAD

V$DATAFILE_HEADE R V$LOGFILE

Leen Datos SGA SGA SGA SGA SGA SGA SGA Fichero Control Fichero Control Fichero Control Fichero Control Fichero Control Fichero Control

Para obtener una lista completa de estas vistas y de la descripción de las columnas se puede consultar el documento Oracle Reference.


Pág. 32


3.5 FICHERO ALERT Y DE RASTREO Si se produce un error mientras se ejecuta la instancia Oracle, los mensajes se escribirán en el fichero ALERT. Durante el inicio de la base de datos, si no existe dicho fichero, el servidor Oracle creará uno. El fichero ALERT de una base de datos es un log cronológico de mensajes y errores. Si un proceso en background detecta un error, la información del error se volcará en un fichero de log, en el cual el nombre del fichero indicará el número y nombre del proceso que ha creado dicho fichero. Los ficheros de log también pueden ser generados a petición del usuario, es el caso si se desea realizar un rastreo de las sentencias SQL que se procesan en el servidor. Por ejemplo la sentencia ALTER SESSION SET sql_trace=TRUE; habilitará la creación de ficheros de log por cada sentencia SQL que envíe al servidor en dicha sesión. Los siguientes parámetros controlan la ubicación y el tamaño del fichero ALERT y de los ficheros de rastreo: • • •

BACKGROUND_DUMP_DEST: Define la ubicación del fichero de rastreo de los procesos en backgruound como del fichero de ALERT de Oracle. USER_DUMP_DEST: Define la ubicación de los ficheros de rastreo de los usuarios. MAX_DUMP_FILE_SIZE: Se especifica en bloques del sistema operativo. Limita el tamaño de los ficheros de rastreo, no del fichero de ALERT ni de los ficheros de rastreo de los procesos en background.


Pág. 33


4 CREACIÓN BASE DE DATOS ORACLE 4.1 CONCEPTOS La creación de una base de datos es el primer paso en la gestión y organización de un sistema de base de datos. La creación de una base de datos es una tarea que prepara varios archivos del sistema operativo y sólo es necesario realizarla en una ocasión, independientemente de los ficheros de datos que tenga la base de datos. El proceso de creación es muy importante, ya que va a determinar el tamaño del bloque y el juego de caracteres de la base de datos, los cuales no se podrán cambiar una vez la base de datos haya sido creada. El comando CREATE DATABASE inicia la creación de los ficheros de control, redo log y la estructura del diccionario de datos que necesita el servidor Oracle para acceder a la base de datos.

4.1.1 Consideraciones previas a la creación de la Base de Datos Será necesario crear un usuario del sistema operativo que será el encargado de gestionar el servidor Oracle y las bases de datos desde el punto de vista del sistema (SO). En los sistemas UNIX será necesario modificar los parámetros del KERNEL para establecer el número de semáforos y tamaño de la memoria compartida que el servidor Oracle precisa para la gestión de la base de datos. Será necesario calcular el espacio en disco del sistema que la base de datos va a necesitar para ubicar los ficheros de datos, redo log, y de control. Será necesario establecer la variable de entorno ORACLE_SID para el usuario del sistema operativo que va a crear y gestionar dicha base y de datos. El valor de ORACLE_SID deberá ser el nombre de la instancia. Se aconseja consultar las guías de instalación específicas del sistema operativo para determinar el ajuste de los parámetros del Kernel.

4.1.2 Planificación de la ubicación de los ficheros Oracle aconseja realizar dos copias activas de los ficheros de control al menos en dos dispositivos diferentes. De esta forma, si falla uno de los dispositivos, el otro podrá continuar trabajando con la base de datos. Se aconseja multiplexar los grupos de ficheros redo log y en dispositivos diferentes por razones de seguridad. Respecto a los ficheros de datos se aconseja crear diferentes ficheros en función del contenido que se vaya a alojar en ellos. De esta forma se reduce la fragmentación y la contención de disco. Esto es, se debe separar los objetos de la base de datos con vidas útiles diferentes, como los datos de aplicación y los datos temporales, en tablespaces distintos.


Pág. 34


4.1.3 Métodos para crear una Base de Datos Se puede crear una base de datos, bien con el asistente de configuración, o mediante un fichero de comandos SQL diseñado de forma manual. El asistente de configuración está basado en Java y se puede iniciar desde cualquier plataforma desde el motor Java. Durante la instalación del servidor Oracle se permite crear una base de datos con este asistente. En este documento nos vamos a centrar en la creación de una base de datos de modo manual con el objeto de ver todas las opciones disponibles y su significado en la creación de la base de datos.

4.2 CREACIÓN DE UNA BASE DE DATOS MANUALMENTE El proceso de creación de la base de datos se puede dividir en los siguientes pasos:

4.2.1 Configuración del Entorno del Sistema Operativo Habrá que elegir un nombre único para la base de datos, definir y ajustar las siguientes variables del entorno • • • • • •

ORACLE_HOME: Especifica el directorio donde se ha instalado el Software de Oracle. ORACLE_SID: Especifica el nombre de la instancia y debe ser único para las instancias que se ejecuten en la misma máquina, este valor debe tener un máximo de 8 caracteres. ORACLE_BASE: No es una variable necesaria, aunque se recomienda tenerla configurada, generalmente tiene como valor el directorio padre de ORACLE_HOME. ORA_NLS33: Es necesario crear una base de datos con un juego de caracteres diferente al US7ASCII. Como ejemplo ORA_NLS33=$ORACLE_HOME/ocommon/nls/admin/data PATH: Habrá que añadir a esta variable el valor de $ORACLE_HOME/bin LD_LIBRARY_PATH: Habrá que añadir a esta variable el de valor de $ORACLE_HOME/lib

4.2.2 Preparación del Fichero de Parámetros Antes de crear la base de datos será necesario establecer un fichero de parámetros inicial, no tiene que ser el definitivo de la base de datos en producción. Dicho fichero de parámetros inicial debe especificar como mínimo los siguientes parámetros: •

DB_NAME: Indentificador de la base de datos de cómo máximo 8 caracteres. Este es el único parámetro necesario para crear la base de datos. No es necesario que este


Pág. 35


• •

parámetro coincida con ORACLE_SID, aunque debe coincidir con el nombre que se utilice en la sentencia CREATE DATABASE. CONTROL_FILES: Especifica una lista de ficheros de control. No es necesario que existan los ficheros de control en este momento cuando no se ha creado aún la base de datos. DB_BLOCK_SIZE: Determina el tamaño del bloque de la base de datos. El tamaño del bloque no se podrá cambiar una vez creada la base de datos.

El nombre de la base de datos se asocia con una base de datos en el momento en que ésta se crea y se almacena en los ficheros de control. Para cambiar el nombre de una base de datos existente, se puede utilizar el comando CREATE CONTROLFILE para volver a crear el fichero de control. El cambio de nombre de una base de datos no es muy recomendable.

4.2.3 Inicio de la Instancia El paso siguiente es arrancar la instancia y ponerla en estado NOMOUNT, para ello habrá que conectarse al interfaz de comandos de Oracle SQLPLUS como un usuario SYSDBA y ejecutar el comando STARTUP con la opción que corresponda: • •

$ORACLE_HOME/bin/sqlplus ‘/ as sysdba’ startup nomount pfile=init_0.ora

4.2.4 Creación de la Base de Datos Para crear la base de datos será necesario utilizar el comando CREATE DATABASE, el cual tiene la siguiente sintaxis:


Pág. 36


• • • • • • • •

•

DATABASE: Es el nombre de la base de datos que hay que crear, si se omite este nombre, se utilizará el parámetro de inicialización DB_NAME. LOGFILE GROUP: Especifica los nombres de los ficheros de redo log que se deben utilizar y el grupo al que pertenecen. MAXLOGFILES: Especifica el número máximo de grupos de ficheros redo log que se podrán crear en la base de datos. MAXLOGMEMBERS: Especifica el número máximo de ficheros redo log que puede tener un grupo. MAXLOGHISTORY: Especifica el número máximo de redo log archivados para la recuperación automática del medio físico. DATAFILE: Especifica los ficheros de base de datos que se deben utilizar. AUTOEXTEND: Activa o desactiva la extensión automática de ficheros de datos. MAXDATAFILES: Indica el número máximo de ficheros de datos que puede tener una base de datos. Este valor se almacena en la sección inicial de los ficheros de control en tiempo de creación de la base de datos o creación de ficheros de control. Cualquier intento por añadir un nuevo fichero cuyo número sea mayor que este parámetro, aunque menor que el parámetro DB_FILES, provocará que el fichero de control se expanda de forma automática, para que la sección de fichero de datos pueda albergar más ficheros. MAXINSTANCES: Indica el número máximo de instancias que puede abrir simultáneamente la base de datos.


Pág. 37


• • •

ARCHIVELOG: Indica que los ficheros de redo log se deben archivar antes que se puedan volver a utilizar. CHARACTER SET: Es el juego de caracteres que utiliza la base de datos para almacenar datos. NATIONAL CHARACTER SET: Especifica el juego de caracteres nacional que se utiliza para almacenar datos o en columnas definidas. Si no se especifica, el juego de caracteres nacional será el mismo que el juego de caracteres de la base de datos.

Si se utiliza REUSE en una especificación de fichero, entonces el fichero deberá existir, de lo contrario, tendrá que especificar la opción SIZE y el fichero no deberá existir. El servidor Oracle asigna tanto espacio en los ficheros de control como necesiten los valores de los argumentos MAXLOGMEMBERS, MAXLOGFILES, MAXDATAFILES, MAXLOGHISTORY y MAXINSTANCES. No existe ningún comando de DROP DATABASE. Para suprimir una base de datos, se deberá suprimir los ficheros de datos, de control y de redo log del sistema operativo. Se puede utilizar la siguiente consulta para determinar cuáles son dichos ficheros: SELECT name FROM V$DATAFILE UNION SELECT name FROM V$CONTROLFILE UNION SELECT member FROM V$LOGFILE Después de crear la base de datos no es posible cambiar el juego de caracteres ni el juego de caracteres nacional. Después de ejecutar el comando CREATE DATABASE el servidor Oracle ejecuta el fichero sql.bsq y crea los siguientes objetos de la base de datos: • • • • • •

Ficheros de datos que forman el tablespace SYSTEM. Ficheros de control y de redo log. El usuario sys con la contraseña change_on_install El usuario system con la contraseña manager El segmento de rollback SYSTEM Tablas internas pero no vistas por el diccionario de datos

4.3 EJEMPLO REAL A continuación se muestra un ejemplo de la creación de una base de datos real: startup nomount pfile=/admin//init_0.ora create database "" controlfile reuse maxinstances 1


Pág. 38


maxlogfiles

50

maxdatafiles 100 character set "WE8ISO8859P1" datafile '//syst.dbf'

size 50M

autoextend on next 10M maxsize unlimited logfile group 1 ('//redo01A.dbf', '//redo01B.dbf')

size 5M,

group 2 ('//redo02A.dbf', '//redo02B.dbf')

size 5M,

group 3 ('//redo03A.dbf', '//redo03B.dbf')


Pág. 39

size 5M;


5 CREACIÓN Y USO DEL DICCIONARIO DE DATOS Y PAQUETES ESTÁNDAR Además de la creación de los ficheros de la base de datos, el servidor Oracle crea estructuras dentro de ellos: •

El diccionario de datos, contiene descripciones de los objetos de la base de datos. Incluye dos tipos de objetos: o o

Las tablas base, son las tablas subyacentes que almacenan la descripción de la base de datos. Han sido creadas al tiempo de ejecutar el comando CREATE DATABASE por el script sql.bsq. Estas tablas no se encuentran documentadas. Las vistas del diccionario de datos, resumen y muestran la información almacenada en la base de datos.

•

Las tablas de rendimiento dinámico, contienen información que utiliza el DBA para supervisar y ajustar la base de datos y la instancia.

•

Las unidades de programa PL/SQL, agregan funcionalidad a la base de datos.

5.1 VISIÓN GENERAL DEL DICCIONARIO DE DATOS Una de las partes más importantes de una base de datos Oracle es su diccionario de datos, que es un conjunto de tablas de sólo lectura que proporciona información acerca de su base de datos asociada. El diccionario de datos lo actualiza el servidor Oracle siempre que se ejecute una sentencia DDL o bien una sentencia DML. El diccionario de datos es una fuente de información para todos los usuarios. Para tener acceso al diccionario de datos es preciso utilizar sentencias SQL. El diccionario de datos es de sólo lectura, con lo cual sólo se pueden enviar consultas en las vistas del diccionario de datos. El propietario del diccionario de datos es el usuario SYS y se almacena siempre en el tablespace SYSTEM (este tablespace ha sido creado durante la ejecución del comando CREATE DATABASE).

5.1.1 Contenido del Diccionario de Datos Un diccionario de datos contiene: •

Las definiciones de todos los objetos del esquema en la base de datos (tablas, vistas, índices, agrupamientos, secuencias, procedimientos, funciones, paquetes, disparadores, etc.).


Pág. 40


• • • • • • •

El espacio asignado y utilizado por los objetos. Valores por defecto de columnas. Información acerca de la restricción de integridad. Los nombres de los usuarios de la base de datos Oracle. Privilegios y Roles otorgados a cada usuario. Información de auditoría, como por ejemplo quién ha accedido o actualizado objetos de la base de datos. Otra información general de la base de datos.

5.1.2 Tablas Base y Vistas del Diccionario de Datos Las tablas base del diccionario de datos son las primeras que se crean al tiempo de ejecutar el comando CREATE DATABASE. Se crean automáticamente por el fichero sql.bsq. El servidor Oracle es el único que debería escribir en las tablas base. Generalmente los usuarios no acceden a estas tablas, además la mayoría de la información se encuentra cifrada. Se recomienda no utilizar nunca comandos DML para actualizar las tablas base. Un ejemplo de tabla base es IND$, que contiene información acerca de los índices de la base de datos. Generalmente cuando se examina el diccionario de datos, se está explorando las vistas del diccionario las cuales son sinónimos públicos. Estas vistas resumen y muestran la información almacenada en la base de datos. Decodifican los datos de las tablas base en información útil, mediante uniones y claúsulas where para simplificar la información. Por ejemplo en las vistas del diccionario se utilizan los nombres de los objetos en vez de números de objetos. Algunas de las vistas del diccionario de datos están accesibles para todos los usuarios de la base de datos, otras van dirigidas únicamente a los administradores de la base de datos.

5.1.3 Categorías del Diccionario de Datos Las vistas del diccionario de datos se dividen en tres categorías, que se pueden distinguir unas de otras por sus prefijos: • • •

DBA: Vista del Administrador de la base de datos, es decir, lo que hay en todos los esquemas. ALL: Vista del usuario ampliada, es decir, lo que hay en todos los esquemas. USER: Vista del usuario, es decir, lo que hay en el esquema del usuario.

Todas las vistas tienen sinónimos públicos que se crean en ellas. No todas las vistas del diccionario de datos utilizan estas reglas de nomenclatura. VISTAS con el prefijo DBA Muestran información global de toda la base de datos. Su finalidad es que las consulten únicamente los administradores de la base de datos. Cualquier usuario al que se le haya


Pág. 41


otorgado el privilegio de sistema SELECT ANY TABLE podrá consultar las vistas con prefijo DBA del diccionario de datos. Por ejemplo para consultar todos los objetos de la base de datos, el DBA podrá emitir la siguiente sentencia: SELECT OWNER, OBJECT_NAME, OBJECT_TYPE FROM DBA_OBJECTS; Vistas con el prefijo ALL Hacen referencia a la perspectiva global del usuario de la base de datos. Estas vistas devuelven información acerca de los objetos de esquema a los que el usuario tiene acceso en forma de concesiones públicas o explícitas de privilegios y roles, además de los objetos del esquema del propio usuario. Por ejemplo, la siguiente consulta devuelve información acerca de todos los objetos a los que el usuario tiene acceso. SELECT OWNER, OBJECT_NAME, OBJECT_TYPE FROM ALL_OBJECTS; Vistas con el prefijo USER Estas vistas son las más importantes desde el punto de vista del usuario ya que: • • • • •

Hacen referencia al propio entorno privado del usuario en la base de datos. Generalmente hacen referencia a los objetos que posee el usuario actual. Tienen columnas idénticas a las otras categorías de vistas, excepto que la columna OWNER es el usuario actual. Devuelven un subconjunto de la información de las vistas ALL_ Pueden tener sinónimos públicos abreviados por comodidad.

Por ejemplo, la siguiente consulta devuelve todos los objetos del esquema: SELECT OBJECT_NAME, OBJECT_TYPE FROM USER_OBJECTS; Se puede obtener una lista completa de las vistas del diccionario de datos y sus columnas en el documento Oracle Reference.

5.2 UNIDADES DE PROGRAMA ALMACENADAS El servidor Oracle permite acceder y manipular la información de la base de datos mediante objetos procedurales llamados unidades de programa almacenadas. Estas unidades de programa son un conjunto de sentencias SQL y PL/SQL que llevan a cabo una tarea específica. PL/SQL es el lenguaje procedural de Oracle. Este lenguaje permite mezclar sentencias SQL con sentencias procedurales.


Pág. 42


El administrador de la base de datos puede instalar el componente JSERVER del servidor Oracle para ejecutar unidades de programa Java. Para llamar a un método Java desde SQL o PL/SQL, es necesario publicar dicho método escribiendo una especificación de llamada. La especificación de llamada asigna los nombres del método Java, tipos de parámetros y devuelve los tipos homólogos SQL. Las unidades de programa almacenadas ofrecen las siguientes ventajas: • • • • • •

Para reducir los tiempos de ejecución, el código PL/SQL se compila previamente y se almacena en el diccionario de datos compilado y con el código fuente. Los programas en Java se pueden llamar desde SQL y PL/SQL definiendo sus especificaciones de llamada para PL/SQL. Se almacenan en la zona del SGA, conjunto compartido para reducir el tiempo de recuperación del disco. La seguridad de los datos se puede reforzar permitiendo que los usuarios accedan a los datos únicamente a través de los procedimientos y funciones. Durante la ejecución, diferentes usuarios comparten una sola copia de la unidad de programa. Las funciones almacenadas se pueden utilizar en las sentencias SQL de la misma forma que las funciones agregadas de SQL o bien las incorporadas por Oracle.

En este documento se pretende dar una visión general de los procedimientos almacenados. El desarrollo y mantenimiento de unidades de programa almacenadas se describe de forma detallada en el documento de oracle Unidades de Programa PL/SQL.

5.2.1 Ejecución de una Unidad de Programa PL/SQL

El proceso de servidor lee la unidad de programa PL/SQL almacenada en el conjunto compartido y la ejecuta. Como se puede aprecia en la figura, al tiempo de ejecutar cualquier bloque PL/SQL, el servidor Oracle envía cada sentencia a un motor distinto en función del tipo de sentencia. Si la sentencia es SQL el motor que la ejecuta es el ejecutor de sentencias SQL,


Pág. 43


mientras que si la sentencia es PL el motor que la ejecuta es el ejecutor de sentencias procedurales.

5.3 CREACIÓN DEL DICCIONARIO DE DATOS Parte del diccionario de datos ya ha sido creado de forma automática cuando se ejecutó el comando CREATE DATABASE con el script sql.bsq, que son las tablas base; falta por crear todas las vistas, procedimientos y sinónimos que van a poder utilizar los usuarios de la base de datos. Para completar la creación del diccionario de datos es necesario ejecutar una serie de scripts, cada uno de los cuales completan una parte específica del diccionario de datos. No es obligatorio ejecutar todos los scripts que se indican a continuación, todo dependerá de los requisitos de la base de datos en particular. Los ficheros de comandos para la creación del diccionario de datos se pueden separar en cuatro categorías, según sus nombres de ficheros: • • •

Ficheros de Comandos cat*.sql: Crean vistas del diccionario de datos. Ficheros de Comandos dbms*.sql y prvt*.plb: Crean objetos para los paquetes de Oracle predefinidos, que amplían la funcionalidad del servidor Oracle. Estos programas simplifican la gestión de la base de datos. Ficheros de Comandos utl*.sql: Se deben ejecutar cuando la base de datos necesite tablas adicionales.

La mayor parte de estos ficheros se deben ejecutar como usuario sys. El administrador de la base de datos deberá examinar los ficheros de comandos para averiguar la cuenta de usuario que se debe utilizar para ejecutar dichos ficheros de comandos.

5.3.1 Ficheros de Comandos creación del Diccionario de datos requeridos Fichero catalog.sql Este fichero de comandos (catalog.sql) crea las vistas, tanto de las tablas base como de las vistas dinámicas de rendimiento, así como sinónimos. Inicia a su vez otros ficheros de comandos que crean objetos para (cataudit.sql, catexp.sql, catldr.sql),: •

El entorno PL/SQL básico, incluyendo las declaraciones para PL/SQL: o Tipos de datos. o Excepciones predefinidas. o Procedimientos y funciones incorporados. o Operaciones SQL.

• • • •

Auditoría. Importación y Exportación. SQL*Loador Opciones instaladas.


Pág. 44


Fichero catproc.sql Este fichero de comandos (catproc.sql) establece el uso de la funcionalidad PL/SQL. También crea varios paquetes PL/SQL que se utilizan para ampliar la funcionalidad del motor de Oracle (núcleo). Este fichero también crea paquetes y vistas adicionales para: • • • • • • • •

Alertas. Canales. Logminer. Objetos grandes. Objetos. Colas Avanzadas. Opción de replicación. Otros complementos y opciones.

Este script invoca a su vez los siguientes scripts: catprc.sql, casnap.sql, caprpc.sql, Standard.sql, dbmsutil.sql, dbmssnap.sql, dbmslock.sql, dbmspipe.sql, dbmsalrt.sql, dbmsotpt.sql, dbmsdesc.sql Fichero cataudit.sql Este fichero crea vistas y tablas de auditoría. Lo ejecuta catalog.sql. Estas tablas pueden ser borradas ejecutando catnoaud.sql. Fichero catexp.sql Este fichero crea las tablas necesarias para Export e Import incrementales. Lo ejecuta catalog.sql Fichero catldr.sql Crea las tablas y vistas de SQL*Loador. Lo ejecuta catalog.sql Fichero catparr.sql Crea las tablas necesarias para mantener la información de Parallel Server Option Fichero catprc.sql Crea las estructuras del diccionario de datos para almacenar procedimientos, paquetes y disparadores de la base de datos. Ejecutado pro catproc.sql Fichero catsnap.sql Crea las estructuras del diccionario de datos para el mantenimiento de réplicas (snapshots). Lo ejecuta catproc.sql y requiere catprc.sql Fichero catrpc.sql


Pág. 45


Crea las vistas del diccionario de datos necesarias para el mantenimiento de una base de datos distribuida. Lo ejecuta catproc.sql y requiere catprc.sql Fichero Standard.sql Crea los paquetes PL/SQL necesarios para trabajar con PL/SQL suministrado por Oracle. Lo ejecuta catproc.sql y requiere catprc.sql Fichero dbmsstdx.sql Extensión del fichero Standard.sql. Lo ejecuta catproc.sql y requiere standarda.sql Fichero pipidl.sql Crea los paquetes para trabajar con PL/SQL en el núcleo. Lo ejecuta catproc.sql y requiere dbmsstdx.sql. Fichero pidian.sql Crea los paquetes PL/SQL necesarios para trabajar. Lo ejecuta catproc.sql y requiere dbmsstdx.sql. Fichero diutil.sql Crea los paquetes PL/SQL necesarios para trabajar. Lo ejecuta catproc.sql y requiere pidian.sql. Fichero pistub.sql Crea paquetes PL/SQL necesarios para trabajar con PL/SQL en el núcleo. Lo ejecuta catproc.sql y requiere diutil.sql. Fichero dbmsutil.sql Crea las utilidades que se invocan desde los procedimientos. Lo ejecuta catproc.sql y requiere pistub.sql. Fichero dbmssnap.sql Crea los procedimientos para la administración de réplicas (snapshots). Lo ejecuta catproc.sql y requiere catsnap.sql Fichero dbmsalrt.sql Permite a usuarios y aplicaciones manejar alertas. Lo ejecuta catproc.sql y requiere pistub.sql Fichero dbmslock.sql Permite a los usuarios utilizar el procedimiento LOCK. Lo ejecuta catproc.sql y requiere pistub.sql


Pág. 46


Fichero dbmsotpt.sql Permite a los desarrolladores de apliaciones recibir entrada/salida desde procedimientos. Lo ejecuta catproc.sql y requiere pistub.sql Fichero dbmspipe.sql Permite establecer comunicaciones entre sesiones. Lo ejecuta catproc.sql y requiere pistub.sql Fichero dbmsdesc.sql Crea un paquete que permite definir argumentos y devolver valores de un programa. Lo ejecuta catproc.sql y requiere pistub.sql.

5.3.2 Ficheros de Comandos creación del Diccionario de datos opcionales Fichero catblock.sql Crea la vista blocking_locks que muestra los bloqueos existentes en el sistema Fichero Catnoaud.sql Borra de la base de datos las vistas de auditoría generadas por cataudit.sql Fichero Catnoprc.sql Borra de la base de datos las estructuras generadas por catprc.sql Fichero catstat.sql Ejecuta el comando analize sobre el diccionario de datos para permitir la utilización del optimizador de costes en los accesos mediante SQL. Debe ejecutarse periódicamente para actualizar las estadísticas. Si se tiene opción procedural puede utilizarse desde el paquete ANALYZE_SHEMA. Fichero utlbstat.sql Comienza la recogida de estadísticas para realizar un ajuste de la base de datos. Finaliza con utlestat.sql Fichero utlchain.sql Crea la tabla CHAINED_ROWS para almacenar la salida del comando analyze con la opción list chained rows. Fichero utldtree.sql Crea las tablas y vistas que muestran dependencias entre los objetos de un usuario Fichero utlestat.sql


Pág. 47


Finaliza la recogida de estadísticas que comenzón con utlbstat.sql Fichero utlexcpt.sql Crea la tabla exceptions que se utiliza para activar restricciones de integridad Fichero utldidxs.sql Visualiza los resultados de haber ejecutado los ficheros utlidxss.sql y utlidxso.sql Fichero utloidxs.sql Ejecuta utlidxss.sql sobre múltiples columnas Fichero utllockt.sql Muestra un gráfico en formato de árbol de las esperas para adquirir bloqueos. Fichero utlsampl.sql Crea las tablas de ejemplo, como emp y Dep. y el usuario scott. Fichero utlsidxs.ql Calcula la selectividad de una columna, y comprueba si se ha creado un índice sobre dicha columna y si éste índice es apropiado. Fichero utlxplan.sql Crea la tabla plan_table, que permite mostrar la salida del comando EXPLAIN PLAN.

5.4 EJEMPLO REAL Una vez descritos algunos de los ficheros que permiten crear el diccionario de datos, se va especificar que comandos se deben ejecutar para crear un diccionario de datos real. Estos comandos se deben ejecutar después de crear la base de datos, esto es, después de ejecutar el comando CREATE DATABASE. $ORACLE_HOME/bin/sqlplus ‘/ as sysdba’ @/rdbms/admin/catalog.sql @/rdbms/admin/catproc.sql connect system/manager @/rdbms/admin/catdbsyn.sql


Pág. 48


@/sqlplus/admin/pupbld.sql @/rdbms/admin/dbmspipe.sql La ejecución de estos ficheros creará un diccionario de datos completamente funcional.


Pág. 49


6 GESTIÓN DE TABLESPACES Y FICHEROS DE DATOS Como se ha comentado al principio de este documento una base de datos Oracle contiene estructuras físicas y lógicas. Las estructuras físicas están determinadas por el conjunto de ficheros del sistema operativo asociados a una base de datos y la estructura lógica está determinada por uno o varios tablespaces y los objetos dentro de un esquema de usuario (tablas, vistas, índices, procedimientos almacenados). El tablespace system siempre existe y se crea automáticamente al crear la base de datos. Contiene el diccionario de datos y el código de los procedimientos almacenados; aunque también puede contener el resto de las estructuras lógicas del esquema de usuario, sin embargo Oracle recomienda crear tablespaces adicionales para almacenar datos de usuario, índices de usuario, segmentos de rollback, segmentos temporales. De esta forma se proporciona más flexibilidad en diversas operaciones de administración de la base de datos y reduce la contención entre los objetos del diccionario y los objetos de los usuarios. El DBA puede crear nuevos tablespaces, cambiar el tamaño de los ficheros de datos, añadir nuevos ficheros de datos a tablespaces, definir y modificar los valores de almacenamiento de los segmentos creados en un tablespace, hacer que un tablespace sea de sólo lectura, hacer que un tablespace sea temporal, borrar tablespaces, etc…

6.1 JERARQUÍA DE ALMACENAMIENTO DE LA BASE DE DATOS

Base de Archivo de Datos

Tablespac Segmento Extensión

Bloque del

Bloque

Fig. 6.1 Jerarquía de Almacenamiento


Pág. 50


El servidor Oracle permite el control del uso del espacio en disco mediante las estructuras de almacenamiento lógico, a través de tablespaces, incluyendo segmentos, extensiones y bloques de datos.

6.1.1 Tablespaces

Fig 6.2 Tablespace-Datafile Las características principales de los tablespaces son: • • • • • • • •

Un tablespace sólo puede pertenecer a una base de datos a la vez. Cada tablespace está formado por uno o más ficheros del sistema operativo, que reciben el nombre de ficheros de datos. Un tablespace puede estar formado por uno o más segmentos. Los tablespace se pueden alternar entre el estado de sólo lectura a lectura-escritura. Un fichero de datos sólo puede pertenecer a un tablespace. El servidor Oracle crea los ficheros de datos para el tablespace, asignando la cantidad especificada de espacio en disco más una peqeña cantidad de sobrecarga. El administrador de la base de datos puede cambiar el tamaño de un fichero de datos una vez creado, o bien especificar que un fichero debería aumentar dinámicamente a medida que aumentan los objetos en el tablespace. El número máximo de ficheros de datos para un tablespace es de 1023.


Pág. 51


6.1.1.1Tipos de Tablespaces El servidor Oracle reconoce dos tipos de tablespaces: SYSTEM y todos los demás. El tablespace SYSTEM: • • • • •

Se crea con la base de datos. Es necesario en todas las bases de datos Oracle. Contiene el diccionario de datos, incluyendo las unidades de programa almacenadas. Contiene el segmento de rollback SYSTEM. No debería contener datos de usuario.

El tablespace No SYSTEM: • • • •

Permite más flexibilidad en la administración de la base de datos. Separa los segmentos de rollback, lo temporales, los segmentos de datos de la aplicación y de índices de aplicación. Separa los datos por los requisitos de copias de seguridad. Controla la cantidad de espacio asignado a los objetos de usuario.

6.2 CREACIÓN DE TABLESPACES El comando para crear un tablespaces es CREATE TABLESPACE y su sintaxis es la siguiente:


Pág. 52


donde: • • • • • •

Tablespace: Es el nombre del tablespace que se debe crear. DATAFILE: Especifica el fichero o ficheros de datos que conforman el tablespace. MINIMUM EXTENT: Asegura que cada tamaño de extensión utilizado en el tablespace sea un múltiplo de integer. Utilice K o M para especificar este tamaño en kilobytes o megabytes. LOGGING: Especifica que, por defecto, todos los cambios en las tablas, índices y particiones en el tablespace se escribirán en los registros de redo log (este es el valor por defecto NOLOGGIN: Especifica que, por defecto, todos los cambios en las tablas, índices y particiones en el tablespace, no se escribirán en los registros de redo log. Si esta opción está especificada sólo se escribirán en redo las sentencias DML y algunas DDL. DEFAULT storage: Especifica los parámetros de almacenamiento por defecto de todos los objetos creados en el tablespace.


Pág. 53


• • • •

ONLINE|OFFLINE: Hace que el tablespace esté disponible (ONLINE) o no esté disponible (OFFLINE) después de su creación. El valor por defecto es ONLINE. PERMANENT: Especifica que el tablespace se utilizará para albergar objetos permanentes. Este es el valor por defecto. TEMPORARY: Especifica que el tablespace sólo se utilizará para albergar objetos temporales, por ejemplo, segmentos que utilizan ordenaciones implícitas que usen la clausula ORDER BY. Extent_management_clause: Especifica la gestión de las extensiones del tablespace. Esta cláusula se explica más adelante.

NOTA: La cláusula storage se explicará en un capítulo posterior.

6.2.1.1Cláusula Autoextend Esta cláusula activa o desactiva la extensión automática de los ficheros de datos. La sintaxis de esta cláusula es:

donde: • •

AUTOEXTEND OFF: Desactiva la extensión automática del fichero de datos. AUTOEXTEND ON: Activa la extensión automática del fichero de datos. o NEXT: Especifica el espacio en disco que se debe asignar al fichero de datos cuando se necesitan más extensiones. o MAXSIZE: Especifica el espacio de disco máximo que se permite asignar al fichero de datos. o UNLIMITED: No define ningún límite para asignar espacio de disco al fichero de datos.

6.2.1.2Gestión del Espacio en Tablespaces Las extensiones del tablespace se pueden gestionar con las tablas o con los bitmaps del diccionario de datos. Cuando se cree el diccionario de datos habrá que seleccionar uno de estos métodos de gestión del espacio. No se podrá modificar el método posteriormente.


Pág. 54


Tablespace Gestionado por el Diccionario El servidor Oracle actualizará las tablas adecuadamente en el diccionario de datos siempre que se asigne o se libere una extensión. Este es el método por defecto de gestión del espacio en un tablespace. Se trata del único método disponible en la versión 8.0 de Oracle y anteriores. Tablespace Gestionado Localmente En este caso el propio tablespace mantiene un bitmap en cada fichero de datos para hacer un seguimiento de los bloques de estado libres y ocupados en dicho fichero de datos. Cada bit en el bitmap se corresponde con un bloque o grupo de bloques. Cuando un bloque se asigna o se libera para volver a utilizarlo, el servidor Oracle cambiará los valores del bitmap y mostrar el nuevo estado de los bloques. La sintaxis es la siguiente:

donde: • • • •

DICTIONARY: Especifica que el tablespace se gestiona mediante tablas del diccionario de datos (este es el valor por defecto). LOCAL: Especifica que el tablespace se gestiona localmente con un bitmap. AUTOALLOCATE: Especifica que el tablespace lo gestiona el sistema, esto es, los usuarios no podrán modificar el tamaño de una extensión. UNIFORM: Especifica que el tablespace se gestiona con extensiones uniformes de bytes SIZE. Se utiliza K o M para indicar que el tamaño de la extensión está en kilobytes o megabytes. El tamaño SIZE por defecto es de 1 MB. Si se especifica LOCAL, no se podrá especificar la cláusula DEFAULT storage_clausule, ni MINIMUM EXTENT o TEMPORARY.

La cláusula EXTENT MANAGEMENT LOCAL se podrá especificar en varios comandos CREATE: • •

En un tablespace permanente que no sea SYSTEM. En un tablespace temporal CREATE TEMPORARY TABLESPACE.

Ventajas de los tablespaces gestionados localmente •

Reducen la contención en el diccionario de datos ya que no registran el espacio libre en el mismo.


Pág. 55


• • •

Hace un seguimiento de forma automática del espacio libre adyacente, eliminando la necesidad de fusionar las extensiones libres. El tamaño de las extensiones lo puede determinar de forma automática el sistema. Los cambios en los bitmaps de extensión no generan información de rollback, ya que no actualizan las tablas del diccionario de datos.

Ejemplos de creación de tablespaces: CREATE TABLESPACE tabspace_2 DATAFILE 'tabspace_file2.dat' SIZE 20M DEFAULT STORAGE (INITIAL 10K NEXT 50K MINEXTENTS 1 MAXEXTENTS 999) ONLINE; CREATE TABLESPACE tabspace_5 DATAFILE 'tabspace_file3.dat' SIZE 500K REUSE AUTOEXTEND ON NEXT 500K MAXSIZE 10M; CREATE TABLESPACE tabspace_3 DATAFILE 'tabspace_file5.dbf' SIZE 2M MINIMUM EXTENT 64K DEFAULT STORAGE (INITIAL 128K NEXT 128K) LOGGING; CREATE TABLESPACE tbs_1 DATAFILE 'file_1.f' SIZE 10M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K;

6.2.1.3Tablespace Temporal Se puede gestionar el espacio en operaciones de ordenación de forma más eficaz diseñando tablespaces temporales exclusivamente para los segmentos de ordenación. Ningún objeto de esquemas de usuario podrá residir en un tablespace temporal. Los tablespaces temporales proporcionan mejoras de rendimiento cuando se tenga múltiples ordenaciones demasiado grandes como para caber en memoria. Aunque el comando CREATE TABLESPACE…TEMPORARY se puede utilizar para crear un tablespace temporal, se recomienda utilizar el comando CREATE TEMPORARY TABLESPACE. Las características de los tablespaces temporales son: • • • • • •

Siempre se definen en el modo NOLOGGING No se puede hacer un tablespace temporal que sea de sólo lectura. No se permite cambiar el nombre. La recuperación del medio físico no recuperará los ficheros asociados a tablespaces temporales. BACKUP CONTROLFILE no generará información del tablespaces temporal CREATE CONTROLFILE no especificará ninguna información acerca de tablespaces temporales.

Para optimizar el rendimiento de una ordenación en un tablespace temporal, se recomienda definir el parámetro UNIFORM SIZE para que sea múltiplo del parámetro SORT_AREA_SIZE.


Pág. 56


La sintaxis para la creación de un tablespace temporal es:

Un ejemplo de creación de un tablespace temporal: CREATE TEMPORARY TABLESPACE tbs_1 TEMPFILE 'file_1.f' EXTENT MANAGEMENT LOCAL UNIFORM SIZE 16M;

6.3 MODIFICACIÓN DE TABLESPACES Se puede modificar los valores de almacenamiento de un tablespace ejecutando el comando ALTER TABLESPACE, la sintaxis para la modificación de un tablespace es:


Pág. 57


6.3.1.1Conexión y Desconexión de un Tablespace Normalmente un tablespace está conectado para que los datos que contenga se encuentren disponibles a los usuarios de la base de datos. Sin embargo el administrador de la base de datos puede desconectar un tablespace para: • • •

Realizar una copia de seguridad de un tablespace, aunque también se puede hacer una copia de seguridad de un tablespace conectado y en uso. Recuperar un tablespace o un fichero de datos mientras la base de datos está abierta. Mover un fichero de datos mientras la base de datos está abierta.

Cuando se desconecta un tablespace, el servidor Oracle no permitirá realizar ninguna sentencia SQL que haga referencia a objetos almacenados en dicho tablespace. Los eventos de conexión y desconexión de un tablespace se registrarán en el diccionario de datos y en los ficheros de control. Si un tablespace está desconectado cuando se cierre una base de datos, el tablespace permanecerá desconectado la próxima vez que se abra la base de datos. Si el proceso en background DBW0 detectase errores de escritura en un fichero de datos, el tablespace asociado a dicho fichero de datos conmutará automáticamente al estado de desconexión, registrando dicho evento en el fichero de alerta de la instancia.


Pág. 58


El administrador de la base de datos podrá desconectar un tablespace, excepto el tablespace SYSTEM o cualquier tablespace con algún segmento de rollback activo, o bien segmentos temporales. Cuando se desconecta un tablespace, el servidor Oracle también desconectará todos los ficheros de datos asociados a dicho tablespace. Los modos de desconectar un tablespace son: • • • •

NORMAL: Vacía todos los bloques del SGA en el fichero de datos asociados a dicho tablespace. Esta es la opción por defecto. No se precisará de recuperación del medio físico en este tablespace antes de conectarlo de nuevo. TEMPORARY: Realiza un punto de control para todos los ficheros de datos. Puede requerir recuperación cuando el tablespace se conecte de nuevo. IMMEDIATE: No asegura que los ficheros del tablespace se encuentren disponibles y no realiza ningún punto de control. Será necesario realizar recuperación del medio físico en el tablespace antes de volver a conectarlo. FOR RECOVER: Desconecta el tablespace para la recuperación del tablespace en un punto del tiempo.

6.3.1.2Tablespace de Sólo Lectura Al hacer que un tablespace sea de sólo lectura evita operaciones de escritura posteriores en dicho tablespace. Con lo cual los dispositivos físicos asociados podrán residir en medios físicos de sólo lectura (CDROM…) . El comando ALTER TABLESPACE…..READ ONLY coloca el tablespace en un modo de transacción de sólo lectura. Este estado no permite llevar a cabo ninguna operación de escritura posterior sobre el tablespace. Se puede borrar elementos, como las tablas e índices, de un tablespace de sólo lectura, ya que estos comandos sólo afectan al diccionario de datos. Esto se puede hacer ya que el comando DROP sólo actualiza el diccionario de datos, no los ficheros físicos del tablespace. La acción de hacer un tablespace sea de sólo lectura provocará un punto de control en los ficheros de datos de dicho tablespace.

6.3.1.3Agregar/Mover ficheros de datos de un Tablespace Se pueden añadir/mover ficheros de datos a un tablespace para aumentar la cantidad total de espacio asignado al tablespace o bien modificar la ubicación del fichero de datos. La sintaxis de la cláusula datafile/tempfile es:


Pág. 59


Donde: • •

ADD DATAFILE/TEMPFILE: Indica el/los nuevo/s ficheros del tablespace. RENAME DATAFILE: Sólo se aplica a ficheros de datos en un tablespace NO SYSTEM que no contengan segmentos temporales o segmentos de rollback activos. Se puede utilizar el siguiente proceso para mover ficheros de un tablespace: 1. Desconectar el tablespace. 2. Utilizar comandos del sistema operativo para mover o copiar los ficheros de datos. 3. Ejecutar el comando ALTER TABLESPACE RENAME DATAFILE. 4. Conectar el tablespace. 5. Utilizar el comando del sistema operativo para eliminar el fichero si fuera necesario.

El movimiento de los ficheros de datos también se puede realizar con el comando ALTER DATABASE, en este caso la sintaxis de la sentencia es la siguiente: ALTER DATABASE RENAME FILE ‘filename’ TO ‘filename; Este método está pensado para mover el tablespace SYSTEM que no se puede desconectar en el caso de ALTER TABLESPACE.... Se puede utilizar el siguiente proceso para cambiar el nombre de ficheros de datos en los tablespaces que no se puedan desconectar: 1. 2. 3. 4. 5.

Cerrar la base de datos. Utilizar el comando del sistema operativo para mover los ficheros de datos. Montar la base de datos. Ejecutar el comando ALTER DATABASE RENAME FILE. Abrir la base de datos.

6.4 BORRADO DE TABLESPACES Se puede eliminar un tablespace de una base de datos cuando el tablespace y su contenido ya no sean necesarios, para ello es necesario ejecutar el comando DROP TABLESPACE, la sintaxis de ejecución es la siguiente:

Donde: • • •

Tablespace: Indica el nombre del tablespace que se desea borrar. INCLUDING CONTENTS: Borra todos los segmentos del tablespace. CASCADE CONSTRAINTS: Borra las restricciones de integridad referencial de las tablas del tablespace que hagan referencia a las claves primarias y únicas en las tablas del tablespace borrado.


Pág. 60


No se puede borrar un tablespace que todavía contenga datos sin la opción INCLUDING CONTENTS. Esta opción puede generar que se deshagan muchos cambios cuando el tablespace contiene muchos objetos. Una ver que se haya borrado el tablespace, sus datos ya no estarán en la base de datos. Cuando se borra un tablespace, sólo se borran aquellos punteros de archivo en los ficheros de control de la base de datos asociada. Los ficheros del sistema operativo todavía existen y se deben eliminar de forma explícita con el comando adecuado del sistema operativo. Aunque se cambie un tablespace a sólo lectura, todavía se podrá borrar dicho tablespace, así como los segmentos que contenga. Se recomienda que desconecte el tablespace antes de borrarlo para asegurarse que ninguna transacción tenga acceso a ninguno de los segmentos del tablespace.

6.5 VISTAS DEL DICCIONARIO DE DATOS SOBRE TABLESPACES El diccionario de datos posee diferentes vistas que dan información sobre los tablespaces, ficheros de datos y tempfile. •

Información acerca de tablespace: o DBA_TABLESPACES o V$TABLESPACE

•

Información acerca de ficheros de datos: o DBA_DATA_FILES o V$DATAFILE

•

Información acerca de Tempfile: o DBA_TEMP_FILES o V$TEMPFILE

Las vistas dinámicas se crean a partir de la información contenida en los ficheros de control. Se puede unir las vistas dinámicas V$TABLESPACE con V$DATAFILE con V$TEMPFILE a través de la columna TS# (número de tablespace) para obtener información conjunta. Se puede unir las vistas del diccionario de datos en los tablespaces con las vistas de los ficheros de datos, el campo de union será el nombre del tablespace.

6.6 EJEMPLO REAL A continuación se muestra la creación de tablespaces de una base de datos real, siguiendo con la creación completa de la base de datos, iniciada en capitulos anteriores. create rollback segment r0 tablespace system


Pág. 61


storage (initial 16k next 16k minextents 2 maxextents 20); alter rollback segment r0 online; create tablespace rbs_01 datafile '//_rbs_01.dbf' autoextend on next 10M maxsize unlimited default storage ( initial 1M next 1M pctincrease 0 minextents 8 );

size 256M

create tablespace rbs_02 datafile '//_rbs_02.dbf' autoextend on next 10M maxsize unlimited default storage ( initial 1M next 1M pctincrease 0 minextents 8 ); create tablespace temp datafile '//_temp01.dbf' autoextend on next 10M maxsize unlimited default storage ( initial 1M next 1M pctincrease 0 );

size

size 256M

create tablespace spra_data_indx datafile '//_data_indx01.dbf' autoextend on next 10M maxsize unlimited default storage( initial 128k next 128k pctincrease 0); create tablespace spra_data_indx_2 datafile '//_data_indx02.dbf' autoextend on next 10M maxsize unlimited default storage( initial 128k next 128k pctincrease 0); create tablespace spra_data datafile '//_data01.dbf' autoextend on next 10M maxsize unlimited default storage( initial 128k next 128k pctincrease 0); create tablespace spra_msg datafile '//_msg01.dbf' autoextend on next 10M maxsize unlimited default storage(


Pág. 62

256M

size 512M

size 512M

size 1024M

size 128M


initial next pctincrease

128K 128K 0);

create tablespace spra_msg_indx datafile '//_msg_indx01.dbf' autoextend on next 10M maxsize unlimited default storage( initial 128K next 128K pctincrease 0);


Pág. 63

size 64M


7 SEGMENTOS, EXTENSIONES Y BLOQUES DE DATOS 7.1 CONCEPTO Las unidades de asignación de espacio en la base de datos que utiliza Oracle son: Segmentos, Extensiones y Bloques de Datos. La siguiente figura ilustra la relación que existe entre ellas:

Fig. 7.1 Segmento-Extensión-Bloque Al nivel más fino de granulidad, Oracle almacena los datos en bloques de datos, también llamados bloques lógicos, bloques de Oracle, páginas. Cada bloque de datos se corresponde con un número específico de bytes físicos dentro del disco. Oracle recomienda que el tamaño de cada bloque de datos sea múltiplo del tamaño de página del sistema operativo. El siguiente nivel lógico de espacio de la base de datos es la extensión. Una extensión es un número específico de bloques de datos contiguos asignados para almacenar información.


Pág. 64


El siguiente nivel lógico de la base de datos y como nivel más alto es el segmento. Un segmento es un conjunto de extensiones. Cada segmento tiene una estructura de datos específica y cada una de las cuales está almacenada en el mismo tablespace. Por ejemplo cada tabla de datos está almacenado en su propio segmento de datos, mientras que cada índice de datos está almacenado en su propio segmento de índices. Si una tabla o índice está particionado, entonces cada partición está almacenada en su propio segmento. Oracle asigna espacio a los segmentos en unidades de una o varias extensiones. Cuando se llenan las extensiones de un segmento, Oracle asigna otra extensión para ese segmento. Ya que las extensiones son asignadas cuando se necesitan, las extensiones de un segmento pueden o no ser contiguas en el disco. Un segmento y todas sus extensiones están almacenadas dentro de un tablespace. Aunque un segmento puede incluir extensiones de más de un fichero de datos ya que un tablespace puede tener asociados más de un fichero. Con lo cual cada extensión puede contener datos de un único fichero de datos.

7.2 BLOQUES DE DATOS Oracle gestiona el espacio de almacenamiento (storage) dentro de los ficheros de datos de una base de datos, en unidades llamadas bloques de datos. Un bloque de datos es la unidad más pequeña de entrada/salida. Se puede hacer una comparación a este nivel con los sistemas operativos, los cuales la unidad más pequeña de entrada/salida se llama página o también bloque. Oracle gestiona datos en número múltiplo de sus bloques de datos no en bloques del sistema operativo. Al crear la base de datos se establece el tamaño del bloque de datos, el cual no podrá ser cambiado una vez creada la base de datos. Como se ha comentado anteriormente, el tamaño del bloque de datos se recomienda (debe) que sea múltiplo del bloque del sistema operativo, de esta forma se evita realizar I/O innecesaria sobre el disco. El parámetro dentro del fichero de parámetros que determina el tamaño del bloque es DB_BLOCK_SIZE

7.2.1 Formato del bloque de datos El formato del bloque de datos es independiente del segmento que lo contenga (tabla, índice, segmento de rollback..). La figura que se muestra ilustra el formato de un bloque de datos:


Pág. 65


Fig. 7.2 Bloque de Datos A continuación se explica cada una de las partes que componen un bloque de datos: • • •

• • •

HEADER (Common and Variable): Contiene información general del bloque, como la dirección del bloque y el tipo de segmento donde se ubica. Table Directory: Contiene información sobre la dirección del directorio de tablas. ROW Directory: Contiene información sobre las filas actuales en el bloque de datos, incluyendo dirección por cada porción de fila. La sobrecarga de espacio asignado a esta parte de la cabecera del bloque, una vez que la fila de datos haya sido borrada, este espacio adicional no es restaurado como espacio útil. Oracle reusa este espacio sólo cuando nuevas filas se inserten dentro del bloque. SobreCarga: La cabecera del bloque, el directorio de tabla y de fila son referenciados como overhead. Este tamaño es variable y suele tener una media de 84 a 107 bytes. Row Data: Esta es la porción del bloque que contiene los datos. Free Space: Esta zona se utiliza para la inserción de nuevos datos dentro del bloque, o bien para actualizaciones de una fila del bloque. Al principio el espacio libre de un bloque es contiguo. Sin embargo las supresiones y actualizaciones pueden llegar a fragmentar el espacio libre del bloque. Oracle compacta el espacio libre cuando sea necesario.

7.2.2 Parámetros de Utilización de Espacio de Bloque Los parámetros de utilización de espacio de bloque se pueden utilizar para controlar el uso del espacio en los segmentos de datos y de índices. Estos parámetros son PCTREE y PCTUSED, permitiendo un control sobre el uso del espacio en operaciones como inserciones o


Pág. 66


actualizaciones. La especificación de estos parámetros se realiza cuando se crea o se altera la tabla o índice. • PCTFREE: Este parámetro para un segmento de datos (tabla) especifica el porcentaje de espacio en cada bloque de datos reservado para el posible crecimiento resultado de las actualizaciones de filas en dicho bloque. El valor por defecto para este parámetro es 10% • PCTUSED: Este parámetro para un segmento de datos (tabla) indica el mínimo porcentaje utilizado por el servidor Oracle que intenta conservar para cada bloque de datos de dicho segmento. Oracle considera que un bloque está no disponible (lleno) para una nueva inserción cuando dicho porcentaje cae por debajo del valor de este parámetro. El valor por defecto de este parámetro es del 40%.

Fig. 7.3 PCTFREE


Pág. 67


Fig. 7.4 PCTUSED Tanto PCTFREE como PCTUSED se calculan como porcentajes del espacio de datos disponibles, es decir el espacio del bloque que queda disponible después de restar el espacio de cabecera del total del bloque. Estos parámetros de utilización de espacio de bloque sólo se pueden especificar para segmentos, y no se pueden definir a nivel de tablespace. Las instrucciones para definir los parámetros PCTFREE y PCTUSED se explicará en los capítulos de Gestión de Tablas y Gestión de Índices.

7.2.3 Parámetros que controlan la Simultaneidad Los parámetros INITRANS y MAXTRANS especifican el número inicial y máximo de transacciones que se crean en un índice o bloque de datos. Esta información determina el número de transacciones que pueden modificar un bloque de datos de forma simultánea. •

•

INITRANS: Tiene como valor por defecto 1 en el caso de segmento de datos y 2 en el caso de segmento de índice, garantiza un mínimo de simultaneidad. Por ejemplo si se define 3 como INITRANS, asegura que como mínimo tres transacciones pueden efectuar cambios en el bloque. MAXTRANS: Tiene como valor por defecto 255 y determina el número máximo de transacciones concurrentes que pueden modificar un bloque de datos.

Oracle recomienda no modificar los valores por defecto de los parámetros de simultaneidad.


Pág. 68


7.3 EXTENSIONES Una extensión es una unidad lógica de almacenamiento (storage) de la base de datos formada por un número de bloques de datos contiguos. Cuando el espacio de un segmento está completamente usado, Oracle asigna una nueva extensión a ese segmento. Al crear un segmento (tabla), Oracle asigna a dichos segmentos de datos un número específico de extensiones que es lo que se llama initial extensión. Aunque no haya datos dentro del segmento, Oracle reserva ese espacio para futura información. Si las extensiones iniciales dentro del segmento se llenan y se precisa más espacio, Oracle automáticamente incrementa las extensiones para ese segmento. La cabecera de cada segmento contiene un directorio de las extensiones que hay dentro del segmento. Los segmentos de rollback siempre tienen al menos dos extensiones (estos segmentos se explican en detalle en el siguiente capítulo).

7.3.1 Número y Tamaño de una Extensión Los parámetros storage expresados en términos de extensiones definen cada segmento. Estos parámetros controlan cómo Oracle asigna el espacio libre de la base de datos para un segmento dado. Por ejemplo se puede controlar la cantidad de espacio inicial reservado para una tabla y se puede limitar el número de extensiones que una tabla puede contener, para ello se debe especificar los parámetros storage de la tabla en la cláusula STORAGE de la sentencia CREATE TABLE. Si no se especifica dicha cláusula en la definición de la tabla, entonces se asume los parámetros storage default de su tablespace. Un tablespace que es gestionado por el diccionario de datos sus extensiones son de tamaño incremental, los cuales son determinados por los parámetros storage INITIAL, NEXT y PCTINCREASE. Cuando se crea un segmento dentro de un tablespace, la primera extensión tiene el tamaño de INITIAL, cuando se necesita más espacio, el parámetro NEXT y PCTINCREASE determinan el tamaño de las nuevas extensiones. Se puede modificar el valor de NEXT y de PCTINCREASE después de la creación de un segmento. Aquí se muestra un ejemplo de creación de una tabla con los parámetros storages CREATE TABLE mitabla (id_pp NUMBER, aa NUMBER, bb NUMBER ) TABLESPACE MI_TABLESPACE_DATA STORAGE (INITIAL 6144 NEXT 4000 PCTINCREASE 20 MINEXTENTS 1 MAXEXTENTS 5 );

7.3.1.1Desasignación de las Extensiones


Pág. 69


En general, las extensiones libres de un segmento no son devueltas al espacio libre del tablespace hasta que sea borrado dicho segmento, por ejemplo usando las sentencias DROP TABLE. Sin embargo esta regla general tiene sus excepciones: • • •

Cuando se ejecuta la sentencia TRUNCATE…DROP STORAGE. Periódicamente Oracle puede desasignar una o más extensiones de un segmento de rollback si dicho segmento ha sido definido con el parámetro OPTIMAL. De forma manual, ejecutando la sentencia ALTER TABLE table_name DEALLOCATE UNUSED.

7.3.2 Extensiones en Segmentos Temporales Cuando Oracle completa la ejecución de una sentencia que haya requerido el uso de un segmento temporal, de forma automática borra el incremento de los segmentos temporales y devuelve las extensiones usadas al tablespace temporal.

7.4 SEGMENTOS Un segmento es un conjunto de extensiones que contienen todos los datos para una estructura lógica específica dentro de un mismo tablespace. Por ejemplo para cada tabla, Oracle asigna una o más extensiones que van a formar el segmento de datos de la tabla. Una base de datos Oracle usa cuatro tipos de segmentos: 1. 2. 3. 4.

Segmento Segmento Segmento Segmento

de Datos. de Índice. Temporal. de Rollback.

7.4.1 Segmentos de Datos Estos segmentos de datos es lo que comúnmente se llama TABLA. Este segmento de datos se crea cuando se ejecuta una sentencia como CREATE TABLE. Los parámetros storage de una tabla determinan cómo son asignadas las extensiones dentro del segmento de datos. Estos parámetros se pueden modificar una vez creada la tabla con la sentencia ALTER TABLE.

7.4.2 Segmentos de Índices Estos segmentos de índices es lo que comúnmente se llama ÍNDICES. Estos segmentos se crean cuando se ejecuta una sentencia como CREATE INDEX. Se pueden especificar los parámetros storage para la gestión de las extensiones de un índice dentro de un tablespace cuando se crea el índice. Los segmentos de índices que están


Pág. 70


asociados a algún segmento de datos no tienen porque compartir el mismo tablespace, es más, se recomienda crear un tablespace específico para los índices.

7.4.3 Segmentos Temporales Oracle generalmente requiere de un espacio temporal en la ordenación de datos durante el procesamiento de consultas. A este espacio de disco Oracle lo llama Segmento Temporal. Si la operación de ordenación puede hacerse en memoria, o bien Oracle encuentra alguna otra forma de ejecutar la operación mediante el uso de índices, entonces en estos casos Oracle no usará dichos segmentos temporales. Las siguientes operaciones requerirán el uso de segmentos temporales: • • • • • • •

CREATE INDEX. SELECT….ORDER BY. SELECT DISTINCT. SELECT GROUP BY. SELECT…UNION. SELECT…INTERSECT. SELECT..MINUS.

Las sesiones de usuario usarán segmentos temporales durante el uso de algunas de las sentencias SQL mencionadas. Esto implica que se debe crear un tablespace temporal para tal fin. Oracle recomienda que los usuarios deben tener un tablespace temporal. La forma de asignarle a los usuarios dicho tablespace es mediante la cláusula TEMPORARY TABLESPACE, dicha cláusula se ejecutará mediante un complemento a la creación o modificación de un usuario en la base de datos, esto es: • CREATE USER…….TEMPORARY TABLESPACE…. • ALTER USER …….TEMPORARY TABLESPACE…. Si no existe tablespace temporal, o bien los usuarios no tienen asignado dicho tablespace temporal, el tablespace SYSTEM será el tablespace temporal por defecto. Oracle borra los segmentos temporales cuando la sentencia ha sido completada. Ya que la asignación y desasignación de segmentos temporales ocurren con frecuencia, es razonable y muy recomendable crear un tablespace temporal donde se alojarán los segmentos temporales, de esta forma se evitará tener fragmentación en el tablespace system y en otros tablespaces que podrían alojar segmentos temporales.

7.4.4 Segmentos Rollback Un segmento de rollback lo utiliza aquella transacción que efectúe cambios en una base de datos. Antes de cambiar los bloques de datos o de índices, el antiguo valor se almacena en el segmento de rollback. Esto permite que un usuario deshaga los cambios efectuados.


Pág. 71


7.4.5 Vistas del diccionario de datos sobre Estructuras de Almacenamiento Las relaciones entre los tablespaces, los ficheros de datos, los segmentos y las extensiones libres y utilizadas se pueden ver consultando el diccionario de datos. Cuando se crea un tablespace con uno o más ficheros de datos, entonces se agrega una fila a la vista DBA_TABLESPACES. Se agrega una fila a DBA_DATA_FILES por cada nuevo fichero de la base de datos. En este momento el espacio de cada fichero de datos, excluyendo la cabecera del fichero, aparece como una extensión libre en la vista DBA_FREE_SPACE. Cuando se crea un segmento, se agregará una fila en la vista DBA_SEGMENTS. El espacio que se asigna a las extensiones en este momento se puede ver en DBA_EXTENTS, mientras que en DBA_FREE_SPACE se ajusta para mostrar menos espacio libre en aquellos ficheros donde se han creado las extensiones para el segmento. Para controlar en todo momento el espacio en los ficheros de datos se recomienda controlar las vistas DBA_FREE_SPACE y DBA_EXTENTS

7.4.5.1Consultas a DBA_SEGMENTS Consulta de la vista DBA_SEGMENTS para obtener el número de extensiones y bloques asignados a un segmento: SQL> SELECT segment_name, WHERE owner=’’;

tablespace_name,

extents,block

FROM

DBA_SEGMENTS

7.4.5.2Consultas a DBA_EXTENTS Consulta de la vista DBA_EXTENTS para comprobar las extensiones de un segmento determinado: SQL> SELECT extent_id, file_id, block_id, blocks owner=’’ and segment_name=’
FROM

DBA_EXTENTS

WHERE

7.4.5.3Consultas a DBA_FREE_SPACE Consulta de la vista DBA_FREE_SPACE para comprobar las extensiones libres de un segmento determinado: SQL> SELECT tablespace_name, count(*), DBA_FREE_SPACE GROUP BY tablespace_name;

max(blocks),

sum(blocks)

FROM

7.4.6 Fragmentación de Segmentos Hay varios tipos de segmentos con diferentes propensión a la fragmentación. Se recomienda colocar los segmentos de diferente tipo en tablespaces diferentes para reducir el desperdicio de espacio.


Pág. 72


A continuación se muestra una tabla donde se muestra el grado de fragmentación de los diferentes tablespaces: Tablespace SYSTEM DATA INDEX RBS TEMP • • • •

Uso Diccionario de datos Segmentos de datos Segmento de índice Segmentos de rollback Segmentos temporales

Fragmentación Cero Baja Baja Alta Muy Alta

Los objetos del diccionario de datos nunca se borran ni se truncan y por lo tanto es poco probable que fragmenten el tablespace. Es probable que los segmentos de datos y de índices que son utilizadas por las aplicaciones de los usuarios sean más propensos a la fragmentación que el tablespace del diccionario de datos. Como los segmentos de rollback (como se verá en el capítulo posterior) pueden liberar las extensiones automáticamente, es probable que provoquen fragmentación en un sistema con una elevada actividad de modificaciones en los datos. Los segmentos temporales en los tablespace temporal pueden liberar espacio muy a menudo, y por lo tanto se deben ubicar en tablespaces diferentes.


Pág. 73


8 GESTIÓN DE SEGMENTOS DE ROLLBACK 8.1 CONCEPTO Un segmento de rollback se utiliza para guardar una imagen del valor antiguo cuando un proceso cambia los datos de una base de datos. Almacena la ubicación de los datos y lo datos antes de que se comenzasen a ser modificados. Una transacción sólo puede usar un segmento de rollback para almacenar todos sus registros de rollback. En un segmento de rollback pueden escribir muchas transacciones de forma simultánea. Si se deshacen los cambios de una transacción, el servidor Oracle restaurará el valor original escribiendo de nuevo dicho valor en la fila. Si falla la instancia mientras la transacción está en curso, el servidor Oracle deberá deshacer los cambios no validados cuando se vuelva abrir la base de datos. Este rollback forma parte de la recuperación de transacciones. La recuperación sólo es posible porque los cambios efectuados en el segmento de rollback también están protegidos por los ficheros redo log. Mientras las transacciones están en curso, los demás usuarios de la base de datos no verán ninguno de los cambios no validados por las transacciones, por lo tanto los segmentos de rollback proporcionan a los usuarios una imagen consistente de los datos, es lo que se llama consistencia de lectura. Cuando el servidor Oracle comienza una setencia SELECT, éste determina el Número de Cambio de Sistema (SCN) actual, y se asegura que la sentencia no procese ninguno de los cambios que no se hayan validado antes de este SCN. Cuando se inicia una transacción, es necesario asignar un segmento de rollback a esta transacción. Una transacción puede solicitar un segmento de rollback específico mediante el siguiente comando: SET TRANSACTION USE ROLLBACK SEGMENT rollback_segment Sin embargo como norma general esta labor se deja que la haga el propio servidor Oracle de forma automática, el cual seleccionará el segmento de rollback con menos transacciones.

8.1.1 Uso y Asignación de Extensiones en Segmentos de Rollback Las transacciones utilizan las extensiones de un segmento de forma circular y secuencial, moviéndolas de una a la siguiente una vez esté llena la extensión actual. Una transacción escribe un registro en su ubicación actual en el segmento de rollback y mueve hacia delante el puntero actual según el tamaño del registro.


Pág. 74


Fig. 8.1 Segmento de Rollback Más de una transacción puede escribir en la misma extensión de un segmento de rollback; sin embargo, cada segmento de rollback contiene información de una única transacción. El puntero del segmento de rollback se desplaza a la siguiente extensión cuando se utilicen todos los bloques de la extensión actual y se necesite otra extensión para que haya más espacio. Cuando se llene la última extensión, el puntero se moverá al principio de la primera extensión. El puntero sólo se puede mover a la siguiente extensión si esta extensión no tiene transacciones activas, con lo cual el puntero no puede saltar una extensión. Si se está utilizando la siguiente extensión, la transacción asignará una extensión adicional al segmento de rollback. A esto se le denomina una ampliación. Un segmento de rollback puede crecer de esta forma hasta que alcance el número máximo de extensiones especificadas por el parámetro MAXEXTENTS.

8.2 TIPOS DE SEGMENTOS DE ROLLBACK Oracle tiene dos tipos de segmentos de rollback: 1. Segmento de Rollback SYSTEM. 2. Segmento de Rollback No SYSTEM. a. Privados. b. Públicos. Rollback SYSTEM


Pág. 75


Se crea este segmento en el tablespace SYSTEM cuando se crea la base de datos. Este segmento sólo se podrá utilizar en cambios relacionados con objetos del diccionario de datos. Rollback No SYSTEM Una base de datos con múltiples tablespaces necesita como mínimo un segmento de rollback No SYSTEM. Estos segmentos de rollback son creado por los administradores de la base de datos. Privado Los segmentos de rollback privados son segmentos asociados a una instancia ya que aparecen en el fichero de parámetros, a través del parámetros rollback_segments, aún así se pueden conectar a una instancia de forma manual a través de la sentencia ALTER ROLLBACK SEGMENTS. Público Se utilizan normalmente con Oracle Parallel Server para crear un conjunto de segmentos de rollback que podrá ser utilizado por cualquiera de las instancias de Parallel Server.

8.3 CREACIÓN DE SEGMENTOS DE ROLLBACK La sintaxis para la creación de un segmento de rollback es el siguiente:


Pág. 76


En los segmentos de rollback se debe seguir las siguientes instrucciones: • • • •

Se debe utilizar siempre el parámetro INITIAL=NEXT para asegurar que el tamaño de todas las extensiones sea el mismo. Se debe definir el valor OPTIMAL para reducir la asignación y liberación de las extensiones del segmento de rollback. Se debe evitar definir el valor MAXEXTENTS como UNLIMITED. Esto podría provocar la extensión innecesaria de un segmento de rollback. Colocar siempre los segmentos de rollback en un tablespace exclusivo y diferente para reducir la contención y la fragmentación.

Parámetro OPTIMAL El parámetro OPTIMAL especifica el tamaño en bytes al que un segmento de rollback se debe reducir, si es posible. La especificación de OPTIMAL reduce el posible desperdicio de espacio en


Pág. 77


un segmento de rollback. Al especificar este parámetro, un segmento de rollback podrá liberar espacio después de completar las transacciones que produjeron el crecimiento. La liberación de las extensiones no se lleva a cabo de forma inmediata después de completar la transacción. Este proceso de liberar las extensiones sólo se realiza cuando el puntero se mueve de una extensión a la siguiente. Las extensiones se liberan si se produce una de las dos condiciones siguientes: • •

El tamaño actual del segmento de rollback excede al valor del parámetro OPTIMAL. Existen extensiones inactivas contiguas.

El servidor Oracle intenta liberar las extensiones inactivas de un segmento de rollback hasta que el tamaño del segmento equivalga al valor OPTIMAL, aunque deberá parar si la siguiente extensión que se deba liberar se está utilizando. Restricciones de los Segmentos de Rollback • • • •

Un segmento de rollback se puede especificar como PUBLIC o PRIVATE (valor por defecto es private) en el momento de la creación y no se podrá cambiar después de su creación. Para un segmento de rollback el valor de MINEXTENTS debe ser de dos. PCTINCREASE no se puede especificar en la creación de un segmento de rollback y si se especificase su valor siempre debe ser 0. El valor del parámetro OPTIMAL deberá coincidir, como mínimo al tamaño inicial del segmento de rollback, que es el espacio que utiliza el número de extensiones que define MINEXTENTS.

A continuación se muestra un ejemplo de creación de segmentos de rollback: create tablespace rbs_01 datafile '//_rbs_01.dbf' autoextend on next 10M maxsize unlimited default storage ( initial 1M next 1M pctincrease 0 minextents 8 ); create create create create

rollback rollback rollback rollback

segment segment segment segment

r1_01 r1_02 r1_03 r1_04

tablespace tablespace tablespace tablespace

rbs_01 rbs_01 rbs_01 rbs_01

storage storage storage storage

size 256M

(optimal (optimal (optimal (optimal

8M); 8M); 8M); 8M);

8.3.1 Activar/Desactivar/Borrar Segmentos de Rollback Cuando se crea un segmento de rollback se encuentra desconectado y no se puede utilizar. Para hacer que un segmento de rollback esté disponible para que lo utilicen las transacciones, se debe utilizar el comando: ALTER ROLLBACK SEGMENT ONLINE;


Pág. 78


El número de segmentos de rollback que una instancia puede conectar está limitado por el parámetro MAX_ROLLBACK_SEGMENTS. Para asegurarse que una instancia siempre conectará los segmentos de rollback que tenga definidos, se debe especificar el nombre del segmento de rollback en el fichero de parámetros de la instancia, como se muestra en el siguiente ejemplo: rollback_segments= (r1_01,r1_02,r1_03,r1_04) De forma similar a como se activan los segmentos de rollaback de forma manual, también se pueden desactivar manualmente; para ello se debe ejecutar el siguiente comando: ALTER ROLLBACK SEGMENT OFFLINE; Si durante la ejecución de esta sentencia existiera transacciones activas en dicho segmento de rollback, se marcaría como PENDING OFFLINE, como se puede observar en la vista dinámica V$ROLLSTAT. En el momento que se completen las transacciones existentes, se desconectará dicho segmento. Si se desea borrar un segmento de rollback cuando ya no sea necesario o bien hay que volver a crearlo con diferentes valores de almacenamiento para INITIAL, NEXT o MINEXTENTS, se debe ejecutar el siguiente comando: DROP ROLLBACK SEGMENT ;

8.4 VISTAS DEL DICCIONARIO DE DATOS SOBRE SEGMENTOS DE ROLLBACK Para obtener información acerca de todos los segmentos de rollback de la base de datos se debe consultar la vista DBA_ROLLBACK_SEGS. SQL>SELECT segment_name, tablespace_name, owner, status FROM DBA_ROLLBACK_SEGS; La columna owner hace referencia al tipo del segmento de rollback: • Si su valor es SYS indica un segmento de rollback privado. • Si su valor es PUBLIC indica un segmento de rollback público. Las vistas dinámicas para obtener estadísticas de los segmentos de rollback son: • •

V$ROLLNAME V$ROLLSTAT

La vista V$ROLLNAME contiene los campos: • •

NAME: Indica el nombre del segmento de rollback. USN: Indica el número del segmento de rollback.

La vista V$ROLLSTAT contiene los campos:


Pág. 79


• • • • • • • • • •

USN: Indica el número del segmento de rollback, servirá como campo de unión con la vista V$ROLLNAME. EXTENTS: Número de extensiones del segmento. RSSIZE: Tamaño actual del segmento en bytes. XACTS: Número de transacciones que utilizan este segmento. OPTSIZE: Valor OPTIMAL para el segmento de rollback. HWMSIZE: Límite superior (en bytes) que ha alcanzado el segmento desde el inicio. AVEACTIVE: Tamaño actual de las extensiones activas, promediado con el paso del tiempo. STATUS: Estado del segmento de rollback. ONLINE, PENDING OFFLINE, OFFLINE. CUREXT: Ubicación actual de la cabeza (puntero) del segmento de rollback. Número de extensión. CURBLK: Ubicación actual de la cabeza (puntero) del segmento de rollback. Número de bloque.

NOTA: Si un segmento se encuentra en estado PENDING OFFLINE, el estado que se mostrará en la vista DBA_ROLLBACK_SEGS será ONLINE. Se puede realizar la siguiente consulta para mostrar información del estado actual de los segmentos de rollback: SQL> SELECT n.name, s.extents, s.rssize, s.optsize, s.hwmsize, s.status FROM V$ROLLNAME n, V$ROLLSTAT s WHERE n.usn=s.usn;


Pág. 80

s.xacts,


9 GESTIÓN DE TABLAS Las tablas son la forma más habitual de almacenamiento en las base de datos. El administrador de la base de datos tiene un control muy limitado sobre la distribución de las filas en una tabla. Las tablas se pueden almacenar en cualquier orden, dependiendo de la actividad de la tabla.

9.1 FORMATO Y TAMAÑO DE LAS FILAS

Cabecera de fila Longitud de columna Valor de columna

Bloque de la Base de Datos

Fig. 9.1 Estructura de una Fila Las filas se almacenan en bloques de la base de datos como registros de longitud variable. Las columnas de una fila se almacenan normalmente en el orden en que se definieron y cualquier columna NULL final no se almacena. Cada fila de una tabla tiene: • •

Cabecera de la Fila: Se utiliza para almacenar el número de columnas de la fila, la información de encadenamiento y el estado de bloqueo de la fila. Datos de Fila: Para cada columna, el servidor Oracle almacena la longitud de la columna y el valor. El valor de la columna se almacena inmediatamente a continuación de los bytes de longitud de la columna.

Las filas adyacentes no necesitan espacio entre ellas, ya que cada fila tiene una entrada en el directorio de filas que indica la dirección de comienzo de la fila.


Pág. 81


9.2 TIPOS DE DATOS ORACLE El servidor Oracle proporciona varios tipos de datos: 1. Escalares: a. CHAR(N), NCHAR(N) b. VARCHAR2(N) c. NVARCHAR2(N) d. NUMBER(P,S) e. DATE f. RAW(N) g. BLOB, CLOB,NCLOB,BFILE h. LONG, LONG RAW i. ROWID,UROWID 2. Recopilación: a. VARRAY b. TABLAS ANIDADAS 3. Relación: a. REF 4. Tipos de Datos definidos por el usuario.

9.2.1 Tipos de Datos Escalares 9.2.1.1Datos de Carácter Los datos de carácter se pueden almacenar en la base de datos con longitud fija o longitud variable. Los tipos de datos de carácter de longitud fija, como CHAR y NCHAR, se almacenan con espacios. NCHAR es un idioma nacional, que permite almacenar juegos de caracteres tanto de ancho fijo como de ancho variable. El tamaño máximo está determinado por el número de bytes necesarios para almacenar un carácter, con un límite de 2000 bytes por campo. Por defecto 1 carácter es 1 byte. Los tipos de datos de carácter de longitud variable sólo utilizan el número de bytes necesarios para almacenar el valor actual de la columna y puede variar de tamaño para cada columna, hasta 4000 bytes. VARCHAR2 y NVARCHAR2 son ejemplos de tipos de datos de caracteres de longitud variable.

9.2.1.2Datos Numéricos Los números en una base de datos Oracle siempre se almacenan como datos de longitud variable. Pueden almacenar hasta 38 digitos significativos. Los tipos de datos numéricos requieren:


Pág. 82


• • •

Un byte para el exponente Un byte por cada dos dígitos significativos de la mantisa Un byte para números negativos si el número de dígitos significativos es menos de 38 bytes.

9.2.1.3Tipos de Datos DATE El servidor Oracle almacena los datos de tipo fecha en campos de longitud fija de siete bytes.

9.2.1.4Tipos de Datos RAW Este tipo de datos permite almacenar pequeños datos binarios. El servidor Oracle no realiza conversiones de juegos de carácteres cuando se transmiten datos RAW entre máquinas dentro de una red o si los datos RAW se mueven de una base de datos a otra mediante utilidades Oracle. El número de bytes necesarios para almacenar el valor actual de la columna varía de tamaño para cada fila, hasta 2000 bytes.

9.2.1.5Tipos de Datos para Almacenamiento de Large Objects (LOB) Oracle proporciona seis tipos de datos para almacenar LOB: • • • •

CLOB y LONG para datos de caracteres de ancho fijo. NCLOB para grandes datos del juego de caracteres nacional de ancho fijo. BLOB y LONG RAW para almacenamiento de datos no estructurados. BFILE para almacenamiento de datos no estructurados en ficheros del sistema operativo.

Los tipos de datos LONG y LONG RAW se utilizaban anteriormente para datos no estructurados, como imágenes, documentos o información geográfica y se incluyen principalmente por compatibilidad hacia atrás. Estos tipos de datos se han sustituido por los tipos de datos LOB. Comparación de los tipos de datos LONG con los tipos de datos LOB: LONG, LONG RAW Una única columna por tabla Hasta 2 gigabytes SELECT devuelve datos Datos almacenados en línea No existe soporte de tipo objeto Acceso secuencial a partes

de

LOB Múltiples columnas por tabla Hasta 4 gigabytes SELECT devuelve el localizador Datos almacenados en línea o fuera de línea Soporta tipos de objetos Acceso aleatorio a partes

9.2.1.6Tipos de Datos ROWID y UROWID ROWID es una pseudocolumna a la que se puede consultar junto con otras columnas de una tabla. Tiene las siguientes carácterísticas:


Pág. 83


• • • • •

ROWID es un identificador único para cada fila dentro de la base de datos. ROWID no se almacena explícitamente como un valor de columna. Aunque el ROWID no muestra de forma directa la dirección física de una fila, se puede usar para localizarla. ROWID es la forma más rápida de acceder a una fila dentro de una tabla. ROWID se almacena en índices para especificar las filas que tienen un conjunto dado de valores de clave.

A partir de la versión de Oracle 8.1 se proporciona un nuevo tipo de dato único conocido como el rowid universal, o UROWID. Soporta los ROWID de tablas ajenas y puede almacenar todo tipo de rowids. El valor del parámetro compatible debe ser al menos 8.1 para poder usar UROWID. FORMATO ROWID ROWID necesita 10 bytes de espacio en disco y se muestran 18 caracteres. Consta de los siguientes componentes:

• • • •

OOOOOO

FF

Número del objeto de datos

Número relativo de archivo

BBBBB Número de Bloque

RR Número de fila

Número del objeto de datos: Está asignado a cada objeto de datos, como una tabla o índice, cuando se crea y es único dentro de la base de datos. Número relativo del Fichero: Es único para cada fichero dentro del tablespace Número de bloque: Representa la posición del bloque que contiene la fila dentro del fichero. Número de Fila: Identifica la posición de la entrada en el directorio de la fila en la cabecera del bloque.

Internamente, el número de objeto de datos necesita 32 bits, el número de fichero relativo necesita de 10 bits, el número de bloque necesia de 22 bits y el número de fila necesita e 16 bits, siendo un total de 80 bits (10 bytes). ROWID se muestra con un juego base-64 que utiliza seis posiciones para el número de objeto de datos, tres posiciones para el número de fichero relativo, seis posiciones para el número de bloque y tres posiciones para el número de fila. El juego base-64 utiliza los caracteres “A-Z” “az” “0-9” “+” y “-“. Ubicación de una Fila mediante ROWID Como un segmento sólo puede residir en un tablespace, mediante el número de objeto de datos, el servidor Oracle puede determinar el tablespace que contiene una fila.


Pág. 84


El número de fichero relativo dentro del tablespace se usa para encontrar el fichero, el número de bloque se utiliza para encontrar el bloque que contiene la fila y el número de fila se utiliza para encontrar el registro de directorio de fila para cada fila. El registro de directorio de fila s puede utilizar para encontrar el comienzo de la fila. Así ROWID se puede utilizar para encontrar cualquier fila dentro de una base de datos.

9.2.2 Recopilaciones Las recopilaciones son objetos que contienen objetos. Hay disponibles dos tipos de datos de recopilación.

9.2.2.1Matrices Variables (VARRAYS) Son útiles para almacenar listas que contienen un número de elementos pequeño. Los VARRAY tienen las siguiente características: • • • • •

Una matriz es un conjunto ordenado de elementos de datos. Todos los elementos de la matriz dada son del mismo tipo de dato. Cada elemento tiene un índice, que es un número que corresponde a la posición del elemento en la matriz. El número de elementos en una matriz es el tamaño de la matriz. El servidor Oracle permite que las matrices tengan un tamaño variable, razón por la cual se llaman VARRAY, pero el tamaño máximo se debe especificar cuando se declara el tipo de matriz.

9.2.2.2Tablas Anidadas Las tablas anidadas permiten definir una tabla como una columna dentro de una tabla. Se pueden usar para almacenar conjuntos que pueden tener un gran número de registros. Las tablas anidadas suelen tener las siguientes características: • • • • •

Es un conjunto desordenado de registros. Todas las filas de una tabla anidada tienen la misma estructura. Se almacenan de forma independiente de la tabla principal. Las características de almacenamiento para la tabla anidada las puede definir el administrador de la base de datos. No existe un tamaño máximo predeterminado para una tabla anidada.

9.2.3 Tipos de Datos de Relación Los tipos de datos de Relación se utilizan como punteros dentro de la base de datos. El uso de estos tipos requiere la opción Objects.


Pág. 85


9.3 CREACIÓN DE TABLAS La sintaxis más básica para crear una tabla es:

Propiedades Relacionales

Propiedades Físicas

Donde: • Schema: Es el propietario de la tabla. • Table: Es el nombre de la tabla. • Column: Es el nombre de la columna.


Pág. 86


• • • • • • • • • •

•

Datatype: Es el tipo de datos de la columna. Tablespace: Identifica el tablespace donde se creará la tabla. PCTFREE: Es la cantidad de espacio reservado en cada bloque (es un porcentaje equivalente al espacio total meno la cabecera de bloque) para que las filas crezcan en longitud. PCTUSED: Determina el límite inferior de espacio utilizado en un bloque, antes de que esté disponible para más inserciones de fila. INITRANS: Especifica el número de registros de transacción preasignados en cada bloque, el valor por defecto es 1. MAXTRANS: Limita el número de entradas de transacción que se pueden asignar a cada bloque, el valor por defecto es 255. STORAGE: Identifica la cláusula de almacenamiento que determina cómo se almacenarán las extensiones en la tabla. LOGGING: Especifica que la creación de la tabla se registrará en los ficheros redo log y todas las modificaciones posteriores de la misma. Esta es la opción por defecto. NOLOGGIN: Especifica que la creación de la tabla no se registrará en los ficheros de redo log. CACHE: Especifica que los bloques recuperados de esta tabla se colocan en el extremo que se ha utilizado más recientemente de la lista LRU de la caché de buffers, incluso si se ha realizado una exploración completa de la tabla. Esta opción es útil para tablas que son accedidas de forma muy frecuente, y tablas de tamaño pequeño. NOCACHE: Especifica que los bloques recuperados de esta tabla se colocan en el extremo que se ha utilizado más recientemente que está en la caché de buffers cuando se realiza una exploración completa de la tabla. Es útil para tablas que no son accedidas de forma frecuente.

Copia de una Tabla Existente Se puede utilizar el comando CREATE TABLE con una subconsulta para copiar una tabla existente completa o parcialmente. La sintaxis es: CREATE TABLE…….table……… AS Las restricciones, disparadores y privilegios de tabla no se copian en la nueva tabla. Si se definió una columna como NOT NULL en la tabla original, la columna correspondiente en la nueva tabla también se definirá como NOT NULL. Ejemplo de Creación de Tabla CREATE TABLE scott.emp (empno NUMBER ename VARCHAR2(10)

CONSTRAINT pk_emp PRIMARY KEY, CONSTRAINT nn_ename NOT NULL CONSTRAINT upper_ename CHECK (ename = UPPER(ename)), job VARCHAR2(9), mgr NUMBER CONSTRAINT fk_mgr REFERENCES scott.emp(empno), hiredate DATE DEFAULT SYSDATE, sal NUMBER(10,2) CONSTRAINT ck_sal CHECK (sal > 500), comm NUMBER(9,0) DEFAULT NULL,


Pág. 87


deptno

NUMBER(2)

PCTFREE 5 PCTUSED 75;

CONSTRAINT nn_deptno NOT NULL CONSTRAINT fk_deptno REFERENCES scott.dept(deptno) )

9.3.1 Instrucciones para la Creación de Tablas • • • •

Colocar las tablas en un tablespace independiente y no en el tablespace que tiene segmentos de rollaback, segmentos temporales, índices o en el tablespace System. Colocar las tablas en tablespaces gestionados localmente para evitar la fragmentación. Utilizar tamaños de extensión estándar que sean múltiplos de 5*DB_BLOCK_SIZE para minimizar la fragmentación. Utilizar la cláusula CACHE para pequeñas tablas a las que sea probable acceder con mucha frecuencia.

9.3.2 Definición de PCTFREE y PCTUSED PCTFREE Un valor de PCTFREE grande permite más espacio para las actualizaciones dentro del bloque de una base de datos. Definir un valor grande si la tabla contiene: • •

Columnas que son inicialmente NULL y posteriormente se actualizan con algún valor. Columnas que es probable que aumenten de tamaño como resultado de una actualización.

Un mayor valor de PCTFREE conllevará una menor densidad de bloque y que cada bloque pueda albergar un número menos de filas. El cálculo de PCTFREE se hace de la siguiente forma: (Tamaño medio de la Fila – Tamaño inicial de la Fila)*100/Tamaño medio de la fila PCTUSED Al definir PCTUSED de forma correcta se asegura que el bloque se devuelve a la lista de bloques libres sólo cuando hay espacio suficiente para albergar una fila de tamaño medio. Si un bloque de la lista de bloques libres no contiene espacio suficiente para insertar una fila, el servidor Oracle busca en el bloque siguiente en la lista de bloques libres. La exploración lineal continua hasta que se encuentra un bloque con suficiente espacio o se llega al final de la lista. Con la fórmula de PCTUSED se reduce el tiempo necesario de exploración de la lista de bloques libres aumentando la probabilidad de encontrar un bloque con el espacio libre necesario. El cálculo de PCTFREE se hace de la siguiente forma: 100 – PCTFREE – (tamaño medio de la fila*100/espacio de datos disponible)


Pág. 88


Nota: El valor para el tamaño medio de la fila se puede estimar con el comando: ANALIZE TABLE

9.3.3 Migración y Encadenamiento de Filas Migración Si PCTFREE se define con un valor pequeño, puede que no haya espacio suficiente en un bloque para albergar una fila que crece como resultado de una actualización. Cuando ocurre esto, el servidor Oracle moverá toda la fila a un nuevo bloque y dejará un puntero en el bloque original hacia la nueva ubicación. A este proceso se le llama Migración de Filas. Cuando se migra una fila, el rendimiento de E/S asociado con esta fila desciende ya que el servidor Oracle debe explorar dos bloques de datos para recuperar la fila. Encadenamiento El encadenamiento de filas se produce cuando una fila es demasiado grande para caber dentro de cualquier bloque. Esto puede ocurrir si la fila contiene muchas columnas muy largas. En este caso el servidor Oracle divide la fila en trozos más pequeños denominados piezas de fila. Cada pieza de fila se almacena en un bloque junto a los punteros necesarios para recuperar y ensamblar toda la fila. El encadenamiento de filas se puede minimizar seleccionando un tamaño de bloque mayor (cuando se crea la base de datos) o bien dividiendo la tabla en tablas más pequeñas con menos columnas si es posible.

9.3.4 Control del Espacio Utilizado por las Tablas Algunos de los parámetros de almacenamiento y todos los parámetros de utilización de los bloques se pueden modificar con el comando ALTER TABLE, el cual para estos casos tiene la siguiente sintaxis ALTER TABLE [schema].table { [storage-clause] [PCTFREE integer] [PCTUSED integer] [INITRANS integer] [MAXTRANS integer]} Los parámetros que se pueden modificar y sus implicaciones son las siguientes: • •

NEXT: Cuando el servidor Oracle asigna otra extensión, se utilizará el nuevo valor. Los tamaños de extensión posteriores se incrementarán con PCTINCREASE. PCTINCREASE: Un cambio en este parámetro se registrará en el diccionario de datos. Se utilizará para volver a calcular NEXT cuando la siguiente extensión sea asignada por el servidor Oracle. Por ejemplo, se tiene una tabla con dos extensiones que tiene como NEXT=10K y PCTINCREASE=0. Si se pone PCTINCREASE=100, la tercera extensión se asignará a 10K pero al cuarta extensión se asignará a 20K.


Pág. 89


•

MINEXTENTS: Este parámetro puede cambiar a cualquier valor que sea menor o igual que el número actual de extensiones. No tendrá efecto inmediato, pero se utilizará si la tabla se trunca. • MAXEXTENTS: El valor de este parámetro puede tomar cualquier valor igual o mayor que el número actual de extensiones. El valor INITIAL no se puede modificar para una tabla ya creada. El valor NEXT especificado se redondeará a un valor múltiplo de un tamaño de bloque mayor o igual que el valor especificado. Los parámetros de utilización de bloques se pueden cambiar para: • •

Mejorar la utilización del espacio. Minimizar la posibilidad de migración.

Los efectos de cambiar los parámetros de utilización de bloques son: •

• • •

PCTFREE: Un cambio en ese parámetro afectará a futuras inserciones. Los bloques que no se utilizan para inserciones porque ya se han rellenado, no se verán afectados hasta que se vuelvan a la lista de bloques libres. Sólo se pueden colocar se pueden colocar en la lista de bloques libres si su uso desciende por debajo de PCTUSED. PCTUSED: Cualquier cambio en este parámetro afectará a todos los bloques de la tabla. Si una fila actualiza o borra, se comprobará si se puede utilizar el bloque que contiene la fila y se volverá a utilizar para inserciones si el uso está por debajo de PCTUSED. INITRANS: Un cambio en este parámetro sólo afectará a los bloques nuevos. MAXTRANS: Un cambio en este parámetro afectará a todos los bloques de la tabla.

9.4 MODIFICACIÓN DE TABLAS 9.4.1 Liberación de Espacio no Utilizado Si se han asignados grandes extensiones a una tabla y no se están utilizando totalmente, se puede liberar espacio en la tabla ejecutando el siguiente comando de forma manual. De esta forma el espacio liberado queda disponible para otros segmentos del tablespace. ALTER TABLE [schema].table DEALLOCATE UNUSED [KEEP integer [K|M] ] El parámetro KEEP especifica el número de bytes por encima del límite superior que se debería retener. Si el comando utiliza la cláusula KEEP, el servidor Oracle liberará todo el espacio no utilizado por encima del límite superior. Si el límite superior está en una extensión menor que el valor de MINEXTENTS, el servidor Oracle liberará extensiones por encima de MINEXTENTS. Como la liberación de espacio con este comando libera espacio sin utilizar dentro de una extensión, un uso frecuente puede provocar fragmentación del espacio dentro del fichero de datos. Para evitar este problema se puede definir MINIMUM EXTENT en la creación del tablespace.


Pág. 90


Si se quiere liberar todo el espacio por debajo del límite superior, incluso si el límite superior está por debajo de MINEXTENTS, se utilizará KEEP=0.

9.4.2 Truncado de una Tabla Al truncar una tabla se borran todas las filas de una tabla y se libera el espacio sin utilizar. La sintaxis es: TRUNCATE TABLE [schema].table [ {DROP|REUSE} STORAGE ] Los efectos de utilizar este comando son los siguientes: • • • • • •

• •

Se borran todas las filas de la tabla. No se generan datos de rollback y el comando se valida implícitamente ya que el comando TRUNCATE TABLE es un comando DDL. También se truncan los índices correspondientes. Una tabla a la que hace referencia una clave ajena no se puede truncar. Los disparadores de borrado no actúan cuando se usa este comando. Si se usa la cláusula DROP, que es la cláusula por defecto: o Se liberan todas las extensiones excepto aquellas especificadas mediante MINEXTENTS. o El límite superior se restablece para apuntar al primer bloque de la tabla. o El valor de NEXT para la siguiente extensión se restablece. Se debe especificar la cláusula REUSE para retener todo el espacio que utiliza la tabla. El efecto de DROP o REUSE repercute en cascada en los índices de la tabla.

9.4.3 Borrado de una Tabla Una tabla se debe borrar si ya no es necesaria o si se debe reorganizar. La sintaxis es la siguiente: DROP TABLE [schema].table [CASCADE CONSTRAINTS] Cuando se borra una tabla se liberan las extensiones que utiliza la tabla. Si son contiguas, se puede fusionar, ya sea automáticamente o manualmente en una etapa posterior. La opción de CASCADE CONTRAINTS es necesaria si la tabla es la principal en una relación de clave ajena.

9.4.4 Borrado de una Columna Antes de la versión de Oracle 8.1, no era posible borrar una columna de una tabla. A partir de esta versión de Oracle se permite el borrado de columnas en las tablas. Para ello se debe tener establecido el parámetro compatible a un valor igual o superior a 8.1. El borrado de columnas limpia columnas no utilizadas y potenciales demandantes de espacio sin tener que exportar o


Pág. 91


importar datos, ni volver a crear índices y restricciones. Es posible que se tarde mucho tiempo en borrar una columna ya que se suprimen todos los datos de dicha columna. La sintaxis para eliminar columnas de una tabla es: ALTER TABLE [schema].table DROP CONTRAINTS CHEKPOINT integer]

COLUMN

[CASCADE

El borrado de una columna puede requerir mucho tiempo y necesitar una gran cantidad de espacio de rollback. Mientras se borran las columnas de tablas grandes, se pueden especificar puntos de control para minimizar el uso de espacio de rollback. Una forma alternativa de quitar una columna de una tabla y que sea más rápido el borrado posterior, es marcarla como no utilizada (INVALID). Las columnas marcadas como no utilizadas se pueden eliminar de la tabla posteriormente cuando haya menos actividad en el sistema. La sintaxis para marcar una columna como no utilizada es la siguiente: ALTER TABLE [schema].table SET UNUSED COLUMN [CASCADE CONSTRAINTS] Las columnas no utilizadas actúan como si no fueran parte de la tabla. Las consultas no pueden ver los datos de las columnas no utilizadas. Además, los nombres y los tipos de datos de esas columnas no se muestran cuando se ejecuta el comando DESCRIBE. Se puede agregar una nueva columna con el mismo nombre que una columna no usada. Para borrar definitivamente las columnas no usadas de la tabla se debe ejecutar el siguiente comando: ALTER TABLE [schema].table DROP UNUSED COLUMNS [CHEKPOINT integer] Para identificar tablas con columnas no utilizadas, se puede consultar la vista DBA_UNUSED_COL_TABS. Con ello se obtiene los nombres de las tablas que tienen columnas no utilizadas y el número de columnas marcadas como no utilizadas. El borrado de columnas de una tabla tiene las siguientes restricciones: • • • •

Suprimir Suprimir Suprimir Suprimir

una columna de una tabla de tipo de objeto. columnas de tablas anidadas. todas las columnas de una tabla. una columna de clave principal.

9.5 TABLAS TEMPORALES Además de las tablas permanentes que se ha descrito anteriormente, se pueden crear tablas temporales para contener datos privados de sesión que sólo existan mientras dure una transacción o una sesión.


Pág. 92


El comando CREATE GLOBAL TEMPORARY TABLE AS SELECT... crea una tabla temporal que puede ser específica de transacción o de sesión. Para tablas temporales específicas de transacción, los datos permanecen hasta que se acaba la transacción, mientras que en las tablas específicas de sesión, los datos permanecen hasta que acaba la sesión. Los datos de una sesión son privados para la sesión. Cada sesión sólo puede ver y modificar sus propios datos. Las cláusulas que controlan la duración de las filas en una tabla temporal son: • •

ON COMMIT DELETE ROWS para especificar que las filas son visibles dentro de la transacción. ON COMMIT PRESERVE ROWS para especificar que las filas son visibles para toda la sesión.

La definición de una tabla temporal es visible para todas las sesiones.

9.6 VISTAS DEL DICCIONARIO DE DATOS SOBRE TABLAS Las vistas del diccionario de datos que muestran información sobre tablas son: • • • •

DBA_OBJECTS DBA_SEGMENTS DBA_TABLES DBA_EXTENTS

Vista DBA_OBJECTS Esta vista contiene una lista de todos los objetos de la base de datos. Sus campos más representativos son: • • • • • •

OWNER OBJECT_NAME OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE CREATED

Vista DBA_SEGMENTS Esta vista contiene información sobre los parámetros storage de todos los segmentos de la base de datos. Sus campos más representativos son: • • • • • •

OWNER SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME HEADER_FILE HEADER_BLOCK


Pág. 93


Vista DBA_TABLES Esta vista contiene las descripciones de todas las tablas relacionales de la base de datos. Sus campos más reprensentativos son: • • • • • • • • • • • • •

OWNER TABLE_NAME PCT_FREE PCT_USED INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE CACHE BLOCKS EMPTY_BLOCKS TEMPORARY

Vista DBA_EXTENTS Esta vista contiene el número de extensiones, su ubicación y tamaño. Sus campos más reprensentativos son: • • • • • •

OWNER SEGMENT_NAME EXTENT_ID FILE_ID BLOCK_ID BLOCKS

Si se ejecuta la siguiente consulta se obtendrá el número de extensiones y los bloques totales utilizados por una tabla en cada fichero de la base de datos: SQL>SELECT file_id, count(*) Extents, SUM(blocks) Blocks From DBA_EXTENTS WHERE OWNER=’’ and SEGMENT_NAME=’’ GROUP BY file_id;


Pág. 94


10 GESTIÓN DE ÍNDICES Un índice es una estructura de árbol que permite el acceso directo a una fila de una tabla. Los índices se pueden clasificar en función de su diseño lógico o de su implementación física. La clasificación lógica agrupa los índices desde un punto de vista de la aplicación, mientras que la clasificación física se deriva del modo en que se almacenan los índices. •

•

Lógico: o Columna única o concatenada. o Único o No Único. o Basado en funciones. Físico: o Árbol-B. o Clave normal o invertida. o Bitmap.

10.1 CLASIFICACIÓN LÓGICA 10.1.1 Índices Concatenados o de Columna Única Un índice de columna única tiene una única columna en la clave del índice. Un índice concatenado, también conocido como índice compuesto, se crea en múltiples columnas en una tabla. Las columnas de un índice concatenado no necesitan estar en el mismo orden que las columnas de la tabla, y tampoco es necesario que sean adyacentes. El número máximo de columnas en un índice de clave compuesta es de 32. Sin embargo el tamaño combinado de todas las columnas no puede exceder de, aproximadamente un tercio del tamaño del bloque de datos.

10.1.2 Índices Únicos y No Únicos Un índice único garantiza que no haya dos filas de una tabla con valores duplicados en la columna que define el índice. Una clave de índice único sólo puede apuntar a una fila de la tabla. En un índice no único, una clave sencilla puede tener múltiples filas asociadas con ella.

10.1.3 Índices basados en Funciones Un índice basado en funciones se crea cuando se utilizan funciones o expresiones que implican a una o más columnas en la tabla que se está indexando. Un índice basado en funciones calcula previamente el valor de la función o de la expresión y lo almacena en el índice. Estos índices se pueden crear tanto sobre una estructura B-Tree o bien una estructura Bitmap.


Pág. 95


Los índices basado en funciones ofrecen un mecanismo eficaz para evaluar sentencias que contienen funciones en sus claúsulas WHERE. Un índice basado en funciones se puede crear para materializar expresiones de cálculo intensivo en el índice, de forma que el servidor Oracle no tiene que calcular el valor de la expresión a la hora de procesar sentencias SELECT y DELETE. Sin embargo, cuando se procesan sentencias INSERT y UPDATE, el servidor Oracle aún debe evaluar la función para procesar la sentencia y generar el registro índice. A continuación se muestra un ejemplo de creación de un índice basado en funciones y una consulta que utiliza dicho índice: CREATE INDEX emp_i ON emp (UPPER(ename)); SELECT * FROM emp WHERE UPPER(ename) IS NOT NULL;

10.2 CLASIFICACIÓN FÍSICA Aunque las dos estructuras de índices (B-Tree y Bitmaps) usan una estructura de índice de Árbol-B, se suele asociar el término índice B-Tree a los que almacenan una lista de ROWID para cada clave.

10.2.1 Estructura de un Índice B-Tree En la siguiente figura se muestra la estructura de un índice B-Tree Raiz

Derivación

Hoja Cabecera de entrada del índice Longitud de la columna clave Valor de la columna clave ROWID

Fig. 10.1 Índice Árbol-B En la parte superior del índice está la raíz que contiene los registros que apuntan al siguiente nivel del índice. En el siguiente nivel están los bloques de derivación, que a su vez apuntan a los bloques del siguiente nivel del índice. En el nivel inferior están los nodos hojas que


Pág. 96


contienen los registros de índice que apuntan a las filas de la tabla. Los bloques hoja están doblemente enlazados para facilitar la exploración del índice en un orden ascendente, así como en un orden descendente de valores clave. Formato de los Registros de la Hoja Índice Un registro de índice está compuesto de los siguientes componentes: • • •

Una cabecera de registro, que almacena el número de columnas e información de bloqueo. Los pares valor-longitud de la columna clave, que definen el tamaño de una columna en la clave seguida del valor de la columna. ROWID de una fila que contiene los valores clave.

Características de los Registros de la Hoja Índice • •

Los valores clave se repiten si hay múltiples filas que contienen el mismo valor clave. No hay registros de índices que corresponde a una fila que tiene todas las columnas clave a NULL.

Efecto de Operaciones DML en un Índice El servidor Oracle mantiene de forma automática los índices cuando se realizan operaciones DML sobre la tabla que contiene el índice: • • •

Las operaciones de insertar provocan una inserción de un registro índice en el bloque apropiado. La eliminación de una fila sólo provoca la eliminación lógica del registro de índice. El espacio que utiliza la fila suprimida no está disponible para nuevos registros hasta que se eliminen todos los registros del bloque. Las actualizaciones de las columnas clave conducen a una eliminación lógica y una inserción en el índice.

10.2.2 Índice de Clave Invertida Un índice de clave invertida invierte los bytes de cada columna indexada, excepto el ROWID, al mantener el orden de la columna. Al insertar registros en una clave ascendente, se pueden producir cuellos de botella de E/S en el índice ya que todas las actualizaciones del índice se producen en el mismo sitio del árbol del índice. Los índices de clave inversa dividen la distribución de las actualizaciones de índice a través del árbol invirtiendo el valor de los datos de la clave del índice. Por ejemplo en la inserción de un número 7698 en la tabla, se almacena un valor clave en el índice de 8967. Cuando se produce el siguiente número 7782 se genera un registro de índice de valor clave 2877. De esta forma se distribuye la carga entre varios bloques de índices.


Pág. 97


Los índices de clave inversa son útiles en consultas que contienen predicados de igualdad. Como en un índice de clave inversa no se guardan juntas las claves léxicamente adyacentes, no se puede realizar búsquedas de rango con un índice así.

10.2.3 Índices Bitmap Los índices de Bitmap tienen más ventajas que los índices B-Tree en determinadas situaciones: •

• •

Cuando una tabla tiene millones de registros y las columnas clave tienen baja cardinalidad, esto es, hay muy pocos valores distintos para la columna. Por ejemplo los índices Bitmap son preferibles a los índices B-Tree para las columnas género y estado civil de una tabla que contiene registros de pasaporte. Cuando las consultas suelen utilizar una combinación de múltiples condiciones WHERE con relación al operador OR. Cuando las columnas clave son de sólo lectura o tienen baja actividad de actualización.

10.2.3.1 Estructura de un Índice Bitmap Clave Azul Verde Rojo Amarillo

ROWID Inicio 10.0.3 10.0.3 10.0.3 10.0.3

ROWID Final 12.8.3 12.8.3 12.8.3 12.8.3

Bitmap 100010010010100 000100001000010 010010011010001 001000100010010

Un índice Bitmap también se organiza como uno B-Tree, pero el nodo hoja almacena un bitmap por cada valor clave en lugar de una lista de ROWIDS. Cada bit del bitmap corresponde con un posible ROWID, y si está definido el bit, significa que la fila ROWID correspondiente contien el valor clave. Como muestra la tabla anterior, el nodo hoja de un índice bitmap contiene lo siguiente: • • • • •

Una cabecera de registro que contiene el número de columnas y la información de bloqueo. Los valores clave que consta de pares longitud-valor por cada columna clave. En el ejemplo de la tabla, la clave consta de una columna y el primer registro tiene un valor clave Azul. ROWID inicial, que en el ejemplo contiene 3 como número de fichero, 10 como número de bloque y 0 como número de fila. ROWID final, que en el ejemplo anterior contiene 3 como número de fichero, 12 como número de bloque y 8 como número de fila. Un segmento de bitmap, que consta de una cadena de bits. El bit se define cuando la fila correspondiente contiene el valor clave y deja de definirse cuando la fila no contiene el valor clave. El servidor Oracle usa una técnica de compresión patentada para almacenar segmentos de bitmap.


Pág. 98


El ROWID inicial es el ROWID de la primera fila que apunta al segmento de bitmap del bitmap, es decir, el primer bit del bitmap corresponde a ese ROWID, el segundo bit del bitmap corresponde a la fila siguiente del bloque, y el ROWID final es un puntero hacia la última fila de la tabla cubierta por el segmento de bitmap. A continuación se muestra una consulta muy eficiente donde se usa un índice bitmap. SELECT COUNT(*) FROM CUSTOMER WHERE MARITAL_STATUS = 'married' AND REGION IN ('central','west'); Un índice Bitmap puede procesar esta consulta con gran eficiencia, simplemente contando el número de unos en el índice Bitmap

10.2.3.2 Uso de Índice Bitmap El B-Tree se utiliza para encontrar los nodos hoja que contienen segmentos de bitmap para un valor dado de la clave. El ROWID inicial y los segmentos de bitmap se usan para encontrar las filas que contienen el valor clave. Cuando se realizan cambios en la columna clave de la tabla, se deben modificar los bitmaps. Esto provoca un bloqueo de los segmentos de bitmap. Como los bloqueos se adquieren en todo el segmento de bitmap, una fila que no esté cubierta por el bitmap no se puede actualizar por otras transacciones hasta que termina la transacción anterior. Los índices bitmaps incluyen filas que tienen valores nulos en su clave, muy distinto al otro tipo de índices que no los incluyen. Los índices de nulos pueden ser muy útiles para algunos tipos de sentencias SQL, como aquellas que incluyen la función agregada COUNT. Por ejemplo si tenemos la sentencia SELECT COUNT(*) FROM WHERE IS NULL; Si se define un índice Bitmap sobre la columna , el optimizador usará el índice bitmap sobre la columna indexada.


Pág. 99


10.2.4 Comparación Índices B-Tree y Bitmap Árbol-B

Bitmap

Idóneo para las columnas Idóneo en el caso de las de elevada cardinalidad. columnas de baja cardinalidad. Las actualizaciones de las Las actualizaciones de las claves son relativamente columnas clave son muy caras. económicas. Ineficaz en el caso de Eficaces en el caso de consultas que utilizan los consultas que utilizan los predicados OR predicados OR Útiles para OLTP Útiles en el caso de los grandes almacenes de datos. Los índices Bitmap son más compactos que los índices B-Tree cuando se utilizan con columnas de baja cardinalidad. Las actualizaciones en columnas clave en un índice Bitmap son más costosas ya que los bitmaps utilizan bloqueo a nivel de segmento de bitmap, mientras que un índice B-Tree, los bloqueos son en registros correspondientes a filas individuales de la tabla. Los índices Bitmap se pueden utilizar para realizar operaciones tales como OR, esto es, el servidor Oracle puede utilizar dos segmentos de bitmap para realizar un OR de bits y obtener un bitmap como resultado. Esto permite el uso eficaz de los bitmaps en las consultas que usan el predicado OR. Los índices B-Tree pueden ser mejores para un entorno OLTP para el indexado de tablas con muchos movimientos, mientras que los índices Bitmap pueden ser útiles en entornos de almacenamiento de datos en los que se realizan consultas complejas en tablas grandes y estáticas.

10.3 CREACIÓN DE ÍNDICES 10.3.1 Instrucciones en la Creación de Índices • • •

Los índices aceleran el rendimiento de las consultas y ralentizan las operaciones DML. Evitar la creación de índices en tablas volátiles. Colocar índices en tablespace independiente, no en tablespace que tenga segmentos de rollback, segmentos temporales, tablas, system. Minimizar la fragmentación, utilizar algunos tamaños de extensión estándar que sena múltiplos de 5*DB_BLOCK_SIZE.


Pág. 100


• •

Se puede conseguir una ganancia en el rendimiento de índices grandes impidiendo la generación de REDO. Tener en cuenta la cláusula NOLOGGING para la creación de índices grandes. Como los registros de índice son menores en comparación con las filas de la tabla que indexan, los bloques de índice suelen tener más entradas por bloque. Por este motivo, normalmente INITRANS deberá ser mayor en índices que en las tablas correspondientes.

10.3.2 Creación de Índices B-Tree Normales Generalmente los índices se crean en la cuenta de usuario que posee la tabla. La sintaxis de creación de un índice B-Tree normal es: CREATE [ UNIQUE ] INDEX [schema.] ON [schema.] ( [ASC | DESC] [ , [ASC | DESC] ]......) [TABLESPACE ] [PCTFREE integer] [INITRANS integer] [MAXTRANS integer] [storage-clause] [LOGGING|NOLOOGING] [NOSORT|REVERSE] donde: • • • • • • • • • • • • • •

UNIQUE: Se utiliza para especificar un índice único, por defecto no es único. Schema: Es el propietario del índice o tabla. Name_index: Es el nombre del índice. Name_table: Es el nombre de la tabla. Name_column: Es el nombre de la columna. ASC/DES: Se proporciona por compatibilidad sintáctica con otras bases de datos. NAME_TABLESPACE: Identifica el tablespace donde se crea el índice. PCTFREE: Es la cantidad de espacio reservado en cada bloque. INITRANS: Especifica el número de registros de transacción preasignados en cada bloque. 2 es el valor mínimo por defecto. MAXTRANS: Limita el número de bloques de transacción que se pueden asignar a cada bloque. Por defecto es 255. LOGGING: Especifica que la creación del índice y las operaciones posteriores en el índice se registran en el fichero Redo Log. Este es el valor por defecto. NOLOGGING: Especifica que la creación y ciertos tipos de cargas no se registrarán en el fichero Redo Log. NOSORT: Especifica que las filas se almacenan en la base de datos en orden ascendente, y por tanto el servidor Oracle no tiene que ordenarlas al crear el índice. REVERSE: Almacena los bytes del índice en el bloque en orden inverso.

Un ejemplo de creación de un índice B-Tree Normal: CREATE INDEX summit.employee_last_name_idx ON summit.employee(last_name)


Pág. 101


STORAGE (INITIAL 200K NEXT 200K PCTINCREASE 0 MAXEXTENTS TABLESPACE indx;

50)

10.3.3 Creación de Índices B-Tree de Clave Invertida La sintaxis para crear un índice de clave invertida es similar a los índices normales, a excepción que se usa la palabra clave REVERSE. En estos índices no se puede usar la palabra clave NOSORT. CREATE [ UNIQUE ] INDEX [schema.] ON [schema.] ( [ASC | DESC] [ , [ASC | DESC] ]......) [TABLESPACE ] [PCTFREE integer] [INITRANS integer] [MAXTRANS integer] [storage-clause] [LOGGING|NOLOOGING] REVERSE Un ejemplo de creación de un índice B-Tree de clave invertida: CREATE UNIQUE INDEX summit.orders_id_idx ON summit.orders(id) REVERSE STORAGE (INITIAL 200K NEXT 200K PCTINCREASE 0 MAXEXTENTS 50) TABLESPACE indx;

10.3.4 Creación de Índices Bitmap La sintaxis para crear un índice Bitmap es la siguiente: CREATE BITMAP INDEX [schema.] ON [schema.]

( [ASC | DESC] [ , [ASC | DESC] ]......)

[TABLESPACE ] [PCTFREE integer] [INITRANS integer] [MAXTRANS integer] [storage-clause] [LOGGING|NOLOOGING] [NOSORT]

Observar que un índice Bitmap no puede ser único. Un ejemplo de creación de un índice B-Tree de clave invertida:


Pág. 102


CREATE BITMAP INDEX summit.employee_last_name_idx ON summit.employee(last_name) STORAGE (INITIAL 200K NEXT 200K PCTINCREASE 0 MAXEXTENTS 50) TABLESPACE indx; CREATE_BITMAP_AREA_SIZE El parámetro de inicialización CREATE_BITMAP_AREA_SIZE determina la cantidad de espacio que se utilizará para almacenar en memoria segmentos de bitmap. El valor por defecto es de 8 MB. Un valor mayor puede conducir a una creación de índice más rápida. Si la cardinalidad es muy pequeña, este valor se puede definir a un valor pequeño. Por ejemplo si la cardinalidad es de 2 elementos, entonces el valor puede estar en el orden de KB en lubar de MB. Por regla general para una cardinalidad mayor se necesita más memoria para un rendimiento óptimo.

10.4 MODIFICACIÓN DE ÍNDICES 10.4.1 Cambio de los Parámetros de Almacenamiento para Índices Algunos parámetros de almacenamiento y de utilización de bloques se pueden modificar con el comando ALTER INDEX. La sintaxis para modificar los parámetros de almacenamiento es la siguiente: ALTER INDEX [schema.] [storage_clause] [INITRANS integer] [MAXTRANS integer] Las implicaciones de cambiar los parámetros de almacenamiento para un índice son las mismas que las de cambiarlos para una tabla. Un uso común de este cambio es para incrementar MAXEXTENTS para un índice. Se pueden cambiar los parámetros de utilización de bloques para garantizar mayores niveles de simultaneidad en un bloque de índices. Un ejemplo de modificación de los parámetros de almacenamiento en un índice: ALTER INDEX summit.employee_last_name_idx STORAGE (NEXT

400K MAXEXTENTS 100);

10.4.2 Asignación y Liberación de Espacio de Índice


Pág. 103


Puede ser necesario agregar extensiones a un índice antes de un periodo de mucha actividad de inserción en una tabla. De esta forma se evita la extensión dinámica de los índices y una posterior degradación del rendimiento por problemas de fragmentación. Se puede utilizar la cláusula DEALLOCATE del comando ALTER INDEX para liberar espacio no utilizado por encima del límite superior de un índice. La sintaxis para asignar o liberar espacio en los índices es la siguiente: ALTER INDEX [schema.] {ALLOCATE EXTENT (SIZE integer [K|M]) [DATAFILE ‘filename’]) | DEALLOCATE UNUSED [KEEP integer [K|M] ] } La asignación o liberación manual de espacio en un índice sigue las mismas reglas que se utilizan con estos comandos aplicados a una tabla. Nota: El espacio de un índice se libera cuando se trunca la tabla en la que se crea el índice. El truncamiento de una tabla provoca el truncamiento de los índices asociados. Un ejemplo de asignación/liberación de espacio en un índice: ALTER INDEX summit.orders_region_id_idx ALLOCATE EXTENT ‘/DISK6/INDX01.DBF’);

(SIZE 200K DATAFILE

ALTER INDEX summit.orders_id_idx DEALLOCATE UNUSED;

10.4.3 Reconstrucción de Índices La reconstrucción de un índice se debe realizar en las siguientes situaciones: • •

• •

El índice existente se desea mover a un tablespace distinto. Esto puede ser necesario si el índice está en el mismo tablespace que la tabla o si los objetos deben redistribuirse a través de varios discos. El índice existente contiene muchas entradas suprimidas. Se trata de un problema habitual en índices que almacenan el número de pedido de una tabla pedidos, en donde se ha suprimido los pedidos completamente y se han agregado a la tabla nuevos pedidos con números mayores. Se desea convertir un índice normal en un índice de clave inversa. La tabla del índice se ha movido a otro tablespace mediante el comando ALTER TABLE…

La sintaxis para reconstruir un índice es la siguiente: ALTER INDEX [schema.] REBUILD [ONLINE] [TABLESPACE ] [PCTFREE integer] [INITRANS integer] [MAXTRANS integer] [storage-clause]


Pág. 104


[LOGGING|NOLOOGING] [REVERSE|NOREVERSE] Las palabras clave REVERSE o NOREVERSE sólo se pueden utilizar para índices B-Tree. Un ejemplo de reconstrucción de un índice: ALTER INDEX summit.orders_region_id_idx REBUILD TABLESPACE indx02; Regenerar Índices en Línea La construcción o reconstrucción de un índice puede ser una tarea que requiera mucho tiempo, especialmente si la tabla es muy grande. Oracle ofrece un método para contruir un índice mientras se realizan operaciones simultáneas en la tabla base, aunque no se recomienda realizarlas con grandes operaciones DML durante este procedimiento. Un ejemplo de reconstrucción de un índice online: ALTER INDEX summit.orders_id_idx REBUILD ONLINE;

10.4.4 Borrado de Índices Puede ser necesario suprimir índices en las siguientes situaciones: • •

Un índice que ya no es necesario por las aplicaciones. Antes de cargas en bloque. La eliminación de índices antes de la carga de datos grandes y volver a crearlos después de la carga: o Mejora el rendimiento de la carga. o Utiliza el espacio del índice de forma más eficaz.

•

El índice está corrupto

La sintaxis para borrar un índice es la siguiente: DROP INDEX [schema.]

10.5 VISTAS DEL DICCIONARIO DE DATOS SOBRE ÍNDICES Las vistas del diccionario de datos que muestran información sobre índices son: • •

DBA_INDEXES DBA_IND_COLUMNS

Vista DBA_INDEXES Esta vista contiene una lista de todos los índices de la base de datos. Sus campos más representativos son:


Pág. 105


• • • • • • • • •

OWNER INDEX_NAME INDEX_TYPE TABLE_OWNER TABLE_NAME UNIQENESS TABLESPACE_NAME LOGGING STATUS

Vista DBA_IND_COLUMNS Esta vista contiene una lista de columnas indexadas de la base de datos. Sus campos más representativos son: • • • • • • •

INDEX_OWNER INDEX_NAME TABLE_OWNER TABLE_NAME COLUMN_NAME COLUMN_POSITION COLUMN_LENGTH

EJEMPLOS Un ejemplo de consulta para verificar el nombre, tipo y el estado de los índices que posee un usuario puede ser el siguiente: SQL> SELECT index_name, tablespace_name, index_type, uniqueness, status FROM DBA_INDEXES WHERE OWNER=’’; El siguiente ejemplo enumera todos los índices propiedad de un usuario y muestra las tablas y las columnas en las que se ha construido índices: SQL> SELECT index_name, table_owner, table_name, column_name FROM DBA_IND_COLUMNS WHERE INDEX_OWNER=’’ ORDER BY INDEX_NAME, COLUMN_POSITION;


Pág. 106


11 MANTENIMIENTO DE LA INTEGRIDAD DE LOS DATOS La integridad de los datos garantiza que todos los datos de una base de datos siguen las reglas de negocio. Existen tres formas principales con las que se puede mantener la integridad de los datos: • • •

Código de Aplicación. Disparadores de la Base de Datos. Restricciones de Integridad Declarativa.

El código de las aplicaciones se puede implementar mediante procedimientos almacenados dentro de la base de datos, o como aplicaciones que ejecutan en el lado del cliente. Este capítulo se centra en las restricciones de integridad, y se explica conceptualmente lo que es un disparador. Disparadores de Bases de Datos Los disparadores de base de datos son programas PL/SQL que se ejecutan cuando se produce un determinado evento en una tabla, como una inserción, actualización o borrado. Los disparadores pueden estar activados o desactivados. Los disparadores de base de datos se crean normalmente sólo para forzar una regla de negocio compleja que no se pudo definir como una restricción de integridad. Restricciones de Integridad Las restricciones de integridad son un buen mecanismo para forzar reglas de negocio ya que: • • • • •

Mejoran el Rendimiento. Son fáciles de declarar y modificar por que no requieren un código extenso. Centralizan las reglas. Son flexibles (activadas o desactivadas) Están documentadas completamente en el diccionario de datos.

11.1 RESTRICCIONES DE INTEGRIDAD 11.1.1 Tipos de Restricciones Existen cinco tipos de restricciones de integridad declarativas en el servidor Oracle: Restricción NOT NULL UNIQUE PRIMARY KEY FOREIGN KEY

Descripción Especifica que una columna no puede contener valores nulos Designa una columna o combinación de columnas como única Designa una columna o combinación de columnas como la clave primaria de la tabla Designa una columna o combinación de columnas como la clave ajena en una restricción de integridad referencial


Pág. 107


CHECK

Especifica una condición que debe cumplir cada fila de la tabla

11.1.2 Restricciones Diferidas/No Diferidas •

El punto en que una transacción comprueba las restricciones se puede controlar mediante lo que se llama “Restricciones Diferidas”.

Restricciones No Diferidas Las restricciones No Diferidas, también llamadas inmediatas, se fuerzan al final de cada sentencia DML. La violación de una restricción hace que la sentencia se deshaga. Estas son las restricciones por defecto. Una restricción definida como no diferible no se puede modificar para ser forzada al final de una transacción. Restricciones Diferidas Estas restricciones son aquellas que sólo se comprueban cuando se valida una transacción. Si se detecta cualquier violación de restricción, será en el momento de la validación de la transacción cuando se deshaga los cambios realizados. Estas restricciones son útiles cuando se ha introducido al mismo tiempo las filas de la tabla principal y secundaria en una relación de clave ajena, como es el caso de entrada de pedidos, donde se introduce al mismo tiempo el pedido y los elementos del pedido. Para que una restricción se considere como restricción diferible, se debe definir como diferible en el momento de su creación. Una vez definida la restricción como diferible, se puede especificar como:


Pág. 108


• •

Inmediata inicialmente: Especifica que, por defecto, debería funcionar como una restricción inmediata. Diferida inicialmente: Especifica que, por defecto, la restricción sólo se debería forzar al final de la transacción.

11.1.3 Estados de Restricción Una restricción de integridad se puede dar en uno de los siguientes estados: • • • •

Desactivada, no validar Desactivada, validar Activada, no validar o forzada Activada, validar

Desactivada, no validar Una restricción que está desactivada no validada no se comprueba, incluso aunque la restricción continúe guardada en el diccionario de datos. Los datos de una tabla, al igual que los nuevos datos que se introduzcan o actualicen pueden no cumplir las reglas definidas por la restricción. Desactivado Validado Si una restricción se encuentra en este estado, entonces no se permite ninguna modificación de las columnas restringidas, además se suprime el índice en la restricción y la restricción se desactiva.


Pág. 109


Para una restricción única, el estado desactivado validado permite cargar datos de forma eficaz en una tabla. Activada, no validar (Forzada) Si una restricción está activada, no validar, no se pueden introducir nuevos datos que violen la restricción, sin embargo la tabla puede contener datos que sean inválidos, es decir, datos que violen la restricción. Esto suele ser una etapa intermedia que asegura que todos los datos nuevos se verifican antes de ser aceptados en la tabla. Activado Validado Si una restricción está en este estado, entonces se garantiza que todos los datos de la tabla siguen la restricción; este estado impide que se introduzca cualquier dato inválido. Este es el estado normal de operación de una restricción para el procesamiento de transacciones.

11.2 IMPLEMENTACIÓN DE RESTRICCIONES Las restricciones se pueden definir cuando se crea las tablas o bien cuando se modifican las tablas para añadir la restricción. La sintaxis utilizada para crear restricciones mientras se crea las tablas es la siguiente:

column datatype [CONSTRAINT constraint] {[NOT] NULL |UNIQUE [USING INDEX index_clause] |PRIMARY KEY [USING INDEX index_clause] |REFERENCES [schema.]table [(column)] [ON DELETE CASCADE] |CHECK (condition) } [constraint_state] :== [NOT DEFERRABLE|DEFERRABLE [INITIALLY {IMMEDIATE|DEFERRED}] ] [DISABLE|ENABLE [VALIDATE|NOVALIDATE]] Donde: • • • •

Constraint: Identifica el nombre de la restricción almacenada en el diccionario de datos. USING INDEX: Especifica que los parámetros definidos se deberían utilizar para el índice que utiliza el servidor Oracle para forzar una restricción única o de clave primaria. El nombre del índice es el mismo que el de la restricción. DEFERRABLE: Indica que la verificación de la restricción se puede diferir hasta el final de la transacción mediante el comando SET CONSTRAINTS. NOT DEFERRABLE: Indica que esta restricción se comprueba al final de cada sentencia DML. Esta es la opción por defecto.


Pág. 110


• • •

INITIALLY IMMEDIATE: Indica que al inicio de cada transacción se comprueba por defecto esta restricción al final de cada sentencia DML. Esta es la opción por defecto. INITIALLY DEFERRED: Indica que la restricción sólo se verifica al final de cada transacción. DISABLE: Desactiva la restricción de integridad. En este caso el servidor Oracle no la fuerza.

Aquí se muestra un ejemplo:

CREATE TABLE hr.employee( id NUMBER(7) CONSTRAINT employee_id_pk PRIMARY KEY DEFERRABLE USING INDEX STORAGE(INITIAL 100K NEXT 100K) TABLESPACE indx, last_name VARCHAR2(25) CONSTRAINT employee_last_name_nn NOT NULL, dept_id NUMBER(7)) TABLESPACE users; La sintaxis utilizada para crear restricciones después de crear las tablas es la siguiente: ALTER TABLE [ schema. ] ADD

[CONSTRAINT constraint] {PRIMARY KEY (column [, column ]... ) [USING INDEX index_clause] |UNIQUE (column [, column ]... ) [USING INDEX index_clause] |FOREIGN KEY (column [, column ]... ) REFERENCES [schema.]table [(column [, column ]... )] [ON DELETE CASCADE] |CHECK (condition) } [constraint_state] Aquí se muestra un ejemplo:

ALTER TABLE hr.employee ADD(CONSTRAINT employee_dept_id_fk FOREIGN KEY(dept_id) REFERENCES hr.department(id) DEFERRABLE INITIALLY DEFERRED); 11.2.1 Instrucciones para Definir Restricciones


Pág. 111


•

• •

Colocar índices para forzar restricciones de clave primaria y única en un tablespace distinto del que utiliza la tabla. Esto se consigue especificando la cláusula USING INDEX o bien creando la tabla, creando el índice y modificando la tabla para agregar o activar la restricción. Si los datos se suelen cargan en bloque dentro de la tabla es más efectivo desactivar las restricciones, realizar la carga y seguidamente activar las restricciones. Si una tabla contiene una clave ajena de autoreferencia, se puede utilizar uno de los siguientes métodos para cargar los datos: o Definir o activar la clave ajena después de la carga inicial. o Definir la restricción como diferible. (es útil si las cargas son frecuentes)

11.2.2 Consideraciones sobre la Clave Ajena Se debe tener en cuenta varios factores al mantener tablas que están en una relación de clave ajena:

DDL Relacionado con Tablas Principales •

La clave ajena se debe suprimir antes de borrar la tabla principal. Utilizar el siguiente comando para realizar las dos acciones con una sola sentencia: o DROP TABLE CASCADE CONSTRAINTS

• •

La tabla principal no se puede truncar sin suprimir o desactivar la clave ajena. La clave ajena se debe suprimir antes de eliminar el tablespace que contiene la tabla principal. Utilizar el siguiente comando para realizar las dos acciones con una sola sentencia: o DROP TABLESPACE INCLUDING CONTENTS CASCADE CONSTRAINTS

DDL sobre Tablas en una Relación de Clave Ajena Si no se utiliza la opción DELETE CASCADE cuando se eliminan las filas de la tabla principal, el servidor Oracle debe asegurarse que no haya filas en la tabla hija con la correspondiente clave ajena. De igual modo, una actualización de la clave primaria sólo se permite cuando no haya filas hijas con el antiguo valor clave. Si no hay índices de clave ajena en la tabla hija, el servidor Oracle bloquea la tabla hija y no permite cambios para asegurar la integridad referencial. Si hay un índice en la tabla, la


Pág. 112


integridad referencial se mantiene bloqueando los registros de índice y permitiendo bloqueos restrictivos en la tabla hija. Se recomienda la creación de índices para columnas de clave ajena ya que tiene ventajas de rendimiento.

11.3 MANTENIMIENTO DE RESTRICCIONES Una restricción desactivada se puede activar de dos maneras: • •

Active NOVALIDATE Active VALIDATE

Active NOVALIDATE Activar una restricción de no validar es más rápido que activar una restricción de validar, ya que se comprueba la violación de restricciones en los datos existentes si la restricción es diferible. La sintaxis utilizada para activar una restricción de no validar es la siguiente:

ALTER TABLE [ schema. ] table ENABLE NOVALIDATE {CONSTRAINT constraint | PRIMARY KEY | UNIQUE ( column [, column ] ... ) } [ USING INDEX index_clause ] La cláusula USING INDEX sólo es aplicable para restricciones de clave primaria o única creadas como diferibles y se cumple que: • •

Las restricciones se crearon desactivas Las restricciones estaban desactivadas y los índices suprimidos

Activate VALIDATE La sintaxis utilizada para activar una restricción de no validar es la siguiente:

ALTER TABLE [ schema. ] table ENABLE [ VALIDATE ]{CONSTRAINT constraint | PRIMARY KEY | UNIQUE ( column [, column ] ... ) } [ USING INDEX index_clause ] La opción VALIDATE está activada por defecto y no es necesario especificarla cuando se activa una restricción que está desactivada. Si los datos de la tabla violan la restricción, se deshace la sentencia y la restricción continua desactivada.


Pág. 113


11.4 VISTAS DEL RESTRICCIONES

DICCIONARIO

DE

DATOS

SOBRE

vistas del diccionario de datos que muestran información sobre restricciones son: • •

DBA_CONSTRAINTS DBA_CONS_COLUMNS

Vista DBA_CONSTRAINTS Esta vista contiene información de las restricciones en la base de datos. Sus campos más representativos son: • • • • • • • • • • • • • • • •

OWNER CONSTRAINT_NAME CONSTRAINT_TYPE TABLE_NAME SEARCH_CONDITION R_OWNER R_CONSTRAINT_NAME DELETE_RULE STATUS DEFERRABLE DEFERRED VALIDATED GENERATED BAD RELY LAST_CHANGE

Vista DBA_CONS_COLUMNS


Pág. 114


Esta vista contiene información de las columnas con las restricciones en la base de datos. Sus campos más representativos son: • • • • •

OWNER CONSTRAINT_NAME TABLE_NAME COLUMN_NAME POSITION

EJEMPLOS Utilizar la siguiente consulta para obtener los nombres, los tipos y los estados de todas las restricciones de la tabla EMPLOYEE del esquema SUMMIT:

SQL> SELECT constraint_name, constraint_type, deferrable, 2 deferred, validated 3 FROM dba_constraints 4 WHERE owner='SUMMIT' 5 AND table_name='EMPLOYEE'; Utilizar la siguiente consulta para obtener las columnas en las restricciones de la tabla EMPLOYEE del esquema SUMMIT:

SQL> SELECT c.constraint_name, c.constraint_type, 2 cc.column_name 3 FROM dba_constraints c, dba_cons_columns cc 4 WHERE c.owner='SUMMIT' 5 AND c.table_name='EMPLOYEE' 6 AND c.owner = cc.owner 7 AND c.constraint_name = cc.constraint_name 8 ORDER BY cc.position; Utilizar la siguiente consulta para buscar las claves ajenas en la tabla EMPLOYEE del esquema SUMMIT y las restricciones principales:

SQL> SELECT c.constraint_name AS "Foreign Key", 2 p.constraint_name AS "Referenced Key", 3 p.constraint_type, 4 p.owner, 5 p.table_name 6 FROM dba_constraints c, dba_constraints p 7 WHERE c.owner='SUMMIT' 8 AND c.table_name='EMPLOYEE' 9 AND c.constraint_type='R' 10 AND c.r_owner=p.owner 11 AND c.r_constraint_name = p.constraint_name;


Pág. 115


12 GESTIÓN DE USUARIOS El administrador de la base de datos define los nombres de los usuarios a los que se permite acceder a la base de datos. Cuando se crea un usuario de base de datos, se le asocia de forma automática un esquema del mismo nombre, con lo cual nombre de usuario y esquema se utilizan indistintamente con frecuencia. Un esquema es una recopilación específica de los siguientes objetos asociados a un usuario particular: • • • • • • • • • •

Tablas Disparadores Restricciones Índices Vistas Secuencias Unidades de programa almacenadas (PL/SQL) Sinónimos Enlaces de bases de datos Tipos de datos definidos por el usuario

12.1 CREACIÓN DE USUARIOS La sintaxis para crear un usuario de base de datos en Oracle es la siguiente:


Pág. 116


donde: • • • • • • •

User: Es el nombre del usuario. BY password: Especifica que el usuario se autentica mediante la base de datos y debe proporcionar password para conectarse. EXTERNALLY: Especifica que el usuario se autentica mediante el sistema operativo. GLOBALLY AS: Especifica que el usuario se autentica globalmente por el nombre externo especificado. DEFAULT TABLESPACE: Identifica el tablespace por defecto para el usuario. TEMPORARY TABLESPACE: Identifica el tablespace temporal para el usuario. QUOTA: Define el espacio máximo permitido para objetos propiedad del usuario en el tablespace. La palabra clave UNLIMITED se utiliza para especificar que los objetos propiedad del usuario pueden usar tanto espacio como haya disponible en el tablespace. Por defecto no se tienen cuotas en ningún tablespace.


Pág. 117


• • •

PASSWORD EXPIRE: Fuerza al usuario a restablecer la contraseña cuando el usuario se conecta a la base de datos mediante SQL Plus. ACCOUNT LOCK/UNLOCK: Se puede usar para bloquear o desbloquear explícitamente la cuenta de usuario (por defecto es UNLOCK). PROFILE: Se utiliza para controlar el uso de los recursos y especificar el mecanismo de control de contraseña que se utiliza para el usuario.

12.2 MODIFICACIÓN DE USUARIOS La sintaxis para modificar un usuario de base de datos en Oracle es la siguiente:


Pág. 118


Como única novedad de parámetros respecto a la creación de usuarios es la asignación del ROLE que tiene asignado el usuario. Oracle proporciona una gestión de privilegios controlada por lo que llama Roles. Los roles son grupos específicos de privilegios relacionados que se otorgan a los usuarios o a otros roles. Están diseñados para facilitar la gestión de los privilegios en la base de datos.

12.3 SUPRESIÓN DE USUARIOS Para eliminar un usuario de la base de datos se debe ejecutar el siguiente comando: DROP USER [CASCADE] La opción CASCADE suprime todos los objetos del esquema antes de suprimir al usuario. Esta opción se debe especificar si el esquema contiene algún objeto. Un usuario que se encuentre conectado actualmente a la base de datos no se podrá suprimir.

12.4 VISTAS DEL DICCIONARIO DE DATOS SOBRE USUARIOS Las vistas del diccionario de datos que muestran información sobre usuarios son: • •

DBA_USERS DBA_TS_QUOTAS

Vista DBA_USERS Muestra la información de todos los usuarios dados de alta en la base de datos. Sus campos más representativos son: • • • • • • • •

USERNAME USER_ID ACCOUNT_STATUS LOCK_DATE EXPIRY_DATE DEFAULT_TABLESPACE TEMPORARY_TABLESPACE CREATED

Vista DBA_TS_QUOTAS Muestra información de las quotas en los tablespaces para todos los usuarios de la base de datos. Sus campos son: • • • • •

USERNAME TABLESPACE_NAME BYTES MAX_BYTES BLOCKS


Pág. 119


•

MAX_BLOKS

Un valor de -1 en las columnas MAX_BLOCKS o MAX_BYTES indica que el usuario tiene cuota ilimiada en dicho tablespace. EJEMPLOS Un ejemplo de consulta para comprobar las cuotas de tablespace para un usuario concreto: SQL> SELECT tablespace_name, blocks, max_bloks,bytes, max_bytes FROM DBA_TS_QUOTAS WHERE USERNAME=’’; Un ejemplo de consulta que enumera todos los usuarios de la base de datos, el estado de sus cuentas y los tablespaces temporales: SQL>SELECT username, account_status, temporary_tablespace FROM DBA_USERS;


Pág. 120


13 GESTIÓN DE PRIVILEGIOS Un privilegio es el derecho a realizar un tipo de operación sobre la base de datos o sobre objetos contenidos en la misma. Existen dos tipos de privilegios: • •

Privilegios de Sistema: Permite que un usuario realice una operación de base de datos, o un tipo de operaciones de bases de datos. Estas operaciones incluyen crear, borrar y modificar tablas, vistas, segmentos de rollback y procedimientos. Privilegios de Objetos: Permite que un usuario realice una operación en un objeto específico, como por ejemplo una tabla, vista, secuencia, procedimiento, función o paquete.

13.1 PRIVILEGIOS DE SISTEMA Los privilegios de sistema se pueden clasificar de la siguiente forma: • • •

Los privilegios que permiten las operaciones en todo el sistema, por ejemplo CREATE SESSION, CREATE TABLESPACE. Los privilegios que permiten la gestión de objetos en el propio esquema de un usuario, por ejemplo CREATE TABLE. Los privilegios que permiten la gestión de objetos en cualquier esquema, por ejemplo CREATE ANY TABLE.

Los usuarios con privilegios ANY pueden acceder a las tablas del diccionario de datos. La sintaxis utilizada para otorgar privilegios del sistema es la siguiente: GRANT { privilegio | rol } TO { |rol|PUBLIC } [WITH ADMIN OPTION] Donde: • • • • • •

Privilegio: Especifica el privilegio del sistema que se quiere otorgar. Rol: Especifica el nombre del rol que se quiere otorgar. PUBLIC: Otorga el privilegio del sistema a todos los usuarios de la base de datos. WITH ADMIN OPTION: Permite que el usuario al que se otorga el derecho de acceso a que conceda el privilegio o rol a otros usuarios o roles. Para otorgar un privilegio del sistema, se le debe haber otorgado el privilegio WITH ADMIN OPTION. Cualquier usuario con el privilegio del sistema GRANT ANY ROLE, podrá otorgar cualquier role en una base de datos.

A continuación se muestra una tabla con la mayoría de los privilegios de sistema en una base de datos Oracle:


Pág. 121


Privilegio ANALYZE ANALIZE ANY AUDIT AUDIT ANY AUDIT SYSTEM DATABASE ALTER DATABASE DATABASE LINK CREATE DATABASE LINK INDEX CREATE ANY INDEX ALTER ANY INDEX DROP ANY INDEX LIBRARY CREATE LIBRARY CREATE ANY LIBRARY DROP LIBRARY DROP ANY LIBRARY PRIVILEGE GRANT ANY PRIVILEGE PROCEDURE CREATE PROCEDURE CREATE ANY PROCEDURE ALTER ANY PROCEDURE DROP ANY PROCEDURE EXECUTE ANY PROCEDURE PROFILE CREATE PROFILE ALTER PROFILE DROP PROFILE ALTER RESOURCE COST PUBLIC DATABASE LINK CREATE PUBLIC DATABASE LINK DROP PUBLIC DATABASE LINK PUBLIC SYNONYM CREATE PUBLIC SYNONYM DROP PUBLIC

Descripción Analiza cualquier tabla o índice de la base de datos Auditar cualquier objeto de la base de datos Activar y desactivar la auditoría Modificar la base de datos. Añadir ficheros a los tablespaces, siempre que se tenga el privilegio del sistema operativo. Crear enlaces de base de datos privados en el esquema propio

Crear índices sobre cualquier tabla en cualquier esquema Modificar índices sobre cualquier tabla en cualquier esquema Borrar índices sobre cualquier tabla en cualquier esquema Crear librerías externas en el esquema propio Crear librerías externas en cualquier esquema Eliminar librerías externas en el esquema propio Eliminar Crear librerías externas en cualquier esquema Conceder cualquier privilegio del sistema, pero no sobre objetos Crear un procedimiento en el esquema propio Crear procedimientos bajo cualquier esquema Modificar cualquier procedimiento de la base de datos Borrar cualquier procedimiento de la base de datos Ejecutar cualquier procedimiento de la base de datos

Crear perfiles Modificar cualquier perfil de la base de datos Borrar cualquier perfil de la base de datos Calcular los costes de recursos utilizados en todas las sesiones de los usuarios

Crear enlaces de base de datos públicos Borrar enlaces de base de datos públicos

Crear sinónimos públicos Borrar sinónimos públicos


Pág. 122


SYNONYM ROLE CREATE ROLE ALTER ANY ROLE DROP ANY ROLE GRANT ANY ROLE ROLLBACK SEGMENT CREATE ROLLBACK SEGMENT ALTER ROLLBACK SEGMENT DROP ROLLBACK SEGMENT SESSION CREATE SESSION ALTER SESSION RESTRICTED SESSION SEQUENCE CREATE SEQUENCE CREATE ANY SEQUENCE ALTER ANY SEQUENCE DROP ANY SEQUENCE SELECT ANY SEQUENCE SNAPSHOT CREATE SNAPSHOT CREATE ANY SNAPSHOT ALTER ANY SNAPSHOT DROP ANY SNAPSHOT SYNONYM CREATE SYNONYM CREATE ANY SYNONYM DROP ANY SYNONYM SYSTEM ALTER SYSTEM TABLE CREATE TABLE CREATE ANY TABLE ALTER ANY TABLE DROP ANY TABLE EXPORT ANY TABLE LOCK ANY TABLE COMMENT ANY TABLE SELECT ANY TABLE INSERT ANY TABLE

Crear roles Modificar cualquier rol en la base de datos Borrar cualquier rol de la base de datos Conceder cualquier rol de la base de datos Crear un segmento de rollback Modificar un segmento de rollback Borrar un segmento de rollback

Conectarse a la base de datos Ejecutar el comando alter session para cambiar parámetros de entorno Conectarse a la base de datos que haya sido arrancada con el comando STARTUP RESTRICT Crear una secuencia en el propio esquema Crear una secuencia bajo cualquier secuencia Modificar cualquier secuencia de la base de datos Borrar cualquier secuencia de la base de datos Utilizar cualquier secuencia de la base de datos Crear réplicas de tablas remotas en el propio esquema Crear réplicas de tablas remotas bajo cualquier esquema Modificar cualquier réplica de la base de datos Borrar cualquier réplica de la base de datos Crear sinónimos en el esquema propio Crear sinónimos bajo cualquier esquema Borrar cualquier sinónimo de la base de datos Ejecutar el comando ALTER SYSTEM Crear una tabla en el esquema propio Crear tablas bajo cualquier esquema Modificar la estructura de cualquier tabla de la base de datos Borrar cualquier tabla de la base de datos Realizar una exportación de cualquier tabla de la base de datos Bloquear cualquier tabla o vista de la base de datos Comentar cualquier tabla de la base de datos Realizar consultas de cualquier tabla de la base de datos Realizar inserciones en cualquier tabla de la base de datos


Pág. 123


UPDATE ANY TABLE DELETE ANY TABLE TABLESPACE CREATE TABLESPACE ALTER TABLESPACE MANAGE TABLESPACE DROP TABLESPACE UNLIMITED TABLESPACE TRIGGER CREATE TRIGGER CREATE ANY TRIGGER ALTER ANY TRIGGER DROP ANY TRIGGER USER CREATE USER BECOME USER ALTER USER DROP USER VIEW CREATE VIEW CREATE ANY VIEW DROP ANY VIEW

Realizar actualizaciones en cualquier tabla de la base de datos Realizar borrados de filas de cualquier tabla de la base de datos Crear un tablespace en la base de datos Modificar tablespaces Poder poner un tablespace OFF/ON LINE, y ejecutar el comando ALTER TABLESPACE BEGIN/END BACKUP Eliminar tablespaces Utilizar cantidades de espacio ilimitado en cualquier tablespace de la base de datos Crear un disparador en el esquema propio Crear disparadores bajo cualquier esquema de la base de datos Modificar cualquier disparador de la base de datos Borrar cualquier disparador de la base de datos Crear un usuario Convertirse de forma temporal en otro usuario Modificar cualquier usuario de la base de datos Eliminar a un usuario Crear una vista en el esquema propio Crear vistas bajo cualquier esquema Borrar cualquier vista de la base de datos

La sintaxis utilizada para revocar privilegios del sistema es la siguiente: REVOKE { privilegio | rol } FROM { |rol|PUBLIC } Donde: • • •

Privilegio: Especifica el privilegio del sistema que se quiere revocar. Rol: Especifica el nombre del rol que se quiere revocar. PUBLIC: Revoca el privilegio del sistema a todos los usuarios de la base de datos.

13.1.1 Vistas Mostrar Privilegios del Sistema Las vistas que muestran información de los privilegios del sistema son: • •

DBA_SYS_PRIVS SESSION_PRIVS

DBA_SYS_PRIVS Esta vista muestra todos los privilegios del sistema otorgados a los roles y a los usuarios de la base de datos. Los campos de esta vista son:


Pág. 124


• GRANTEE • PRIVILEGE • ADMIN OPTION SESSION_PRIVS Esta vista muestra los privilegios actuales de la sesión, tanto los otorgados directamente como los roles activados al usuario. Esta vista contiene el campo PRIVILEGE.

13.2 PRIVILEGIOS DE OBJETO Cada privilegio de objeto que se otorga autoriza a un usuario al que se otorga, derecho de acceso a que se realice alguna operación en el objeto. La sintaxis utilizada para otorgar privilegios de objeto es la siguiente: GRANT { privilegio [(columna)] | ALL } ON |rol|PUBLIC } [WITH GRANT OPTION]

[esquema.]objeto

TO

{

Donde: • • • • • •

Privilegio: Especifica el privilegio de objeto que se quiere otorgar. Columna: Especifica la columna de una tabla o una vista. ALL: Otorga todos los privilegios al objeto al que se haya otorgado WITH GRANT OPTION Rol: Especifica el nombre del rol que se quiere otorgar. PUBLIC: Otorga el privilegio del sistema a todos los usuarios de la base de datos. WITH ADMIN OPTION: Permite que el usuario al que se otorga el derecho de acceso a que conceda el privilegio o rol a otros usuarios o roles.

A continuación se muestra una tabla con los privilegios de objeto en una base de datos Oracle: PRIVILEGI O ALTER DELETE EXECUTE INDEX INSERT REFERENCES SELECT UPDATE ALL

SENTENCIA SQL PERMITIDA ALTER objeto (tabla o vista) DELETE FROM objeto (tabla o vista) EXECUTE objeto (procedimiento o función) CREATE INDEX ONM objeto (sólo tablas) INSERT INTO objeto (tabla o vista) Sentencia CREATE o ALTER TABLE que tenga una restricción de integridad de clave ajena (FOREIGN KEY) sobre un objeto (sólo tablas) SELECT..FROM objeto (tabla, vista) o sentencias SQL sobre secuencias UPDATE objeto (tabla o vista) Todos los privilegios anteriores

La sintaxis utilizada para revocar privilegios de objeto es la siguiente: REVOKE { privilegio | all } ON [esquema.]objeto FROM { |rol|PUBLIC } [CASCADE CONSTRAINTS]


Pág. 125


Donde: • • • •

Privilegio: Especifica el privilegio de objeto que se quiere revocar. ALL: Revoca todos los privilegios al objeto al que se haya otorgado WITH GRANT OPTION Rol: Especifica el nombre del rol que se quiere revocar. CASCADE CONSTRAINTS: Elimina las restricciones de integridad referencial.

13.2.1 Vistas Mostrar Privilegios de Objetos Las vistas que muestran información de los privilegios de objetos son: • •

DBA_TAB_PRIVS DBA_COL_PRIVS

DBA_TAB_PRIVS Esta vista muestra todos los privilegios de objetos otorgados a los roles y a los usuarios de la base de datos. Los campos de esta vista son: • • • • • •

GRANTEE OWNER TABLE_NAME GRANTOR PRIVILEGE GRANTABLE

DBA_COL_PRIVS Esta vista muestra todos los privilegios de objetos sobre columnas otorgados a los roles y a los usuarios de la base de datos. Los campos de esta vista son: • • • • • • •

GRANTEE OWNER TABLE_NAME COLUMN_NAME GRANTOR PRIVILEGE GRANTABLE


Pág. 126


14 GESTIÓN DE ROLES Los Roles son grupos especificados de privilegios que se otorgan a los usuarios o a otros roles. Su objeto es facilitar la gestión de los privilegios en la base de datos • • • • • • • •

Se otorgan y revocan con los mismos comandos que se utilizan para otorgar y revocar los privilegios del sistema. Se pueden otorgar y revocar a cualquier usuario o rol. Pueden estar formados tanto por privilegios del sistema como privilegios de objetos. Se pueden activar y desactivar a cada usuario al que se haya otorgado el rol. Pueden precisar de una contraseña para su activación. El nombre de cada rol debe ser único entre los nombres de los usuarios y nombres de roles existentes. No los posee nadie, esto es, no están en ningún esquema. Sus descripciones se almacenan en el diccionario de datos.

14.1 CREACIÓN, MODIFICACIÓN, ASIGNACIÓN Y BORRADO DE ROLES 14.1.1 Creación de Roles La sintaxis para crear un rol es la siguiente: CREATE ROLE [NOT IDENTIFIED | IDENTIFIED {BY | EXTERNALLY}] Donde: • • • • •

: Es el nombre del rol. NOT IDENTIFIED: Indica que no es necesario ningún tipo de verificación cuando se activa el rol. IDENTIFIED: Indica que es necesario la verificación cuando se activa la fila. BY : Proporciona la contraseña que el usuario debe especificar cuando se activa el rol. EXTERNALLY: Indica que el usuario debe estar autorizado por un servicio externo como puede ser el sistema operativo.

14.1.2 Modificación de Roles Sólo se puede modificar un rol para cambiar su método de autentificación. La sintaxis para modificar un rol es la siguiente:


Pág. 127


ALTER ROLE [NOT IDENTIFIED | IDENTIFIED {BY | EXTERNALLY}]

14.1.3 Asignación de Roles Para otorgar un rol a un usuario se utiliza la misma sintaxis que se utiliza para otorgar un privilegio del sistema a un usuario: GRANT TO [WITH ADMIN OPTION] Igualmente si se desea revocar un rol de un usuario, se utiliza la misma sintaxis que se usa paras revocar un privilegio del sistema de un usuario: REVOKE FROM

14.1.4 Borrado de Roles Para eliminar un rol de la base de datos se debe utilizar la siguiente sintaxis: DROP ROLE Cuando se borra un rol de la base de datos, el servidor Oracle lo revoca de todos los usuarios y roles a los que se había otorgado y lo elimina de la base de datos. Para borrar un rol es preciso tener el privilegio DROP ANY ROLE.

14.1.5 Uso de Roles Predefinidos Los roles contenidos en la siguiente tabla se definen automáticamente al crear una base de datos Oracle: Nombre de Rol CONNECT

RESOURCE

DBA EXP_FULL_DATABASE IMP_FULL_DATABASE

Descripción Concede al usuario los siguientes privilegios: ALTER SESSION, CREATE DATABASE LINK, CREATE SEQUENCE, CREATE SESSION, CREATE SYNONYM, CREATE TABLE, CREATE VIEW. Este rol se crea con el fichero sql.bsq Concede al usuario los siguientes privilegios: CREATE PROCEDURE,CREATE SEQUENCE, CREATE TABLE, CREATE TRIGGER. Se crea con el fichero sql.bsq y al usuario se le concede el privilegio UNLIMITED TABLESPACE de forma explícita y no como parte del rol Concede al usuario todos los permisos del sistema con la opción WITH ADMIN OPTION y con UNLIMITED TABLESPACE de forma explícita. Se crea con el fichero sql.bsq Concede al usuario los siguientes privilegios: SELECT ANY TABLE, BACKUP ANY TABLE, INSERT, DELETE, UPDATE. Se crea con el fichero catexp.sql Concede al usuario los siguientes privilegios: BECOME USER. Se crea con el fichero catexp.sql


Pág. 128


DELETE_CATALOG_ROLE EXECUTE_CATALOG_ROL E SELECT_CATALOG_ROLE

Este rol permite borrar todos los paquetes del diccionario de datos Este rol permite ejecutar todos los paquetes del diccionario de datos Este rol permite consultar todas las tablas y vistas del diccionario de datos

14.2 ACTIVACIÓN Y DESACTIVACIÓN DE ROLES Se puede a los usuarios activar o desactivar de forma temporal o permanente los privilegios asociados con los roles. Para activar un rol, primero se debe otorgar dicho role al usuario. Cuando se activa un rol, el usuario podrá utilizar los privilegios otorgados a ese rol. Si se desactiva un rol, el usuario no podrá utilizar los privilegios asociados con ese rol a menos que ese privilegio se otorgue directamente al usuario o a otro rol activado para ese usuario. La activación y desactivación de los roles a un usuario se puede realizar de dos formas: • •

De forma explícita con el comando SET ROLE. De forma global en la creación del usuario con el comando ALTER USER…DEFAULT ROLE.

La sintaxis que se utiliza para activar y desactivar los roles de forma explícita es la siguiente: SET ROLE { [ IDENTIFIED BY password ] | ALL [EXCEPT
: Es el nombre del rol. IDENTIFIED BY password: Proporciona la contraseña cuando se activa el rol. ALL: Activa todos los roles otorgados al usuario actual, excepto los que enumere la cláusula EXCEPT. (Esta opción no se podrá usar para activar roles con contraseñas). NONE: Desactiva todos los roles en la sesión actual del usuario.

14.3 VISTAS MOSTRAR INFORMACIÓN DE ROLES Las vistas que muestran información sobre los roles de la base de datos son: • • • • • • •

DBA_ROLES DBA_ROLE_PRIVS ROLE_ROLE_PRIVS DBA_SYS_PRIVS ROLE_SYS_PRIVS ROLE_TAB_PRIVS SESSION_ROLES

DBA_ROLES Muestra todos los roles existentes en la base de datos. Los campos de esta vista son:


Pág. 129


• ROLE • PASSWORD_REQUIRED DBA_ROLE_PRIVS Muestra la lista de roles que se otorgan a los usuarios y a los roles. Los campos de esta vista son: • • • •

GRANTEE GRANTEED_ROLE ADMIN_OPTION DEFAULT_ROLE

ROLE_ROLE_PRIVS Muestra los roles que se otorgan a los roles. Los campos de esta vista son: • • •

ROLE GRANTED_ROLE ADMIN_OPTION

DBA_SYS_PRIVS Muestra los privilegios de sistema que se otorgan tanto a los usuarios como a roles. Los campos de esta vista son: • • • •

GRANTEE USERNAME (usuario actual) PRIVILEGE ADMIN_OPTION

ROLE_SYS_PRIVS Muestra los privilegios del sistema que se otorgan a los roles. Los campos de esta vista son: • • •

ROLE PRIVILEGE ADMIN_OPTION

ROLE_TAB_PRIVS Muestra privilegios de tablas que se otorgan a los roles. Los campos de esta vista son: • • • • • •

ROLE OWNER TABLE_NAME COLUMN_NAME PRIVILEGE GRANTABLE


Pág. 130


SESSION_ROLES Muestra una lista de roles que el usuario tiene activados actualmente. El campo de esta vista es: •

ROLE

EJEMPLOS Un ejemplo de consulta para mostrar los privilegios otorgados a los usuarios y a roles: SQL> SELECT role, password_required FROM dba_roles; Un ejemplo de consulta que enumera los privilegios de tabla asignados a roles: SQL>SELECT * FROM ROLE_TAB_PRIVS WHERE OWNER= AND TABLE_NAME=;


Pág. 131


15 UTILIDADES: IMPORT, EXPORT, SQL*LOADER Las utilidades Export e Import permiten mover datos entre bases de datos Oracle y dentro de una base de datos Oracle a diferentes tablespaces o usuarios, o reorganizar los datos para obtener un rendimiento y almacenamiento más eficaz. La utilidad export se puede utilizar para hacer una copia lógica de definiciones de objetos y datos en un fichero binario del sistema operativo. La utilidad import puede leer ficheros del sistema operativo creados por la utilidad export y copiar las definiciones de los objetos y los datos en una base de datos Oracle. La utilidad import no puede leer ficheros de texto o ficheros creados en cualquier otro formato. La utilidad SQL*Loador es una herramienta de Oracle para pasar datos desde cualquier fuente de datos a una base de datos Oracle, en formato de texto plano. Uso de Export e Import •

Reorganización de tablas: o Una tabla puede contener muchos bloques con una gran cantidad de espacio libre. o Una tabla puede contener muchas filas migradas. o Una tabla puede contener muchos bloques vacíos por debajo del límite superior. o Para minimizar la contención o reducir la fragmentación.

• • • •

Mover datos de un usuario a otro usuario. Mover datos entre bases de datos Oracle. Migrar a una plataforma de sistema operativo distinta. Migrar a una versión de Oracle diferente. Este método puede no ser admitido para mover datos de una versión de Oracle posterior a una versión de Oracle anterior. Realizar copias de seguridad lógica.

•

15.1 EXPORT La sintaxis que se utiliza para realizar la exportación es la siguiente: $ORACLE_HOME/bin/exp [keyword=] {value | (value, value . . .) } Donde keyword son palabras clave que se explican en la siguiente sección y value es el valor asignado a la palabra clave. La utilidad Export proporciona tres modos de exportación: • • •

Tabla Usuario Base de Datos


Pág. 132


15.1.1 Modo Tabla Todos los usuarios pueden usar el modo tabla para exportar sus propias tablas, y los usuarios con privlegios pueden exportar tablas de otros usuarios. El uso de este modo exporta: • • • • •

La definición de la tabla. Los datos de la tabla. Los índices de la tabla. Los disparadores de la tabla. Las restricciones de la tabla.

15.1.2 Modo Usuario La exportación en este modo funciona de forma diferente dependiendo si el usuario que ejecuta la exportación tiene privilegios: •

Un usuario con privilegios puede exportar objetos propiedad de cualquier usuario, en este caso los objetos exportados son: o Todos los objetos propiedad del usuario, excepto los índices y disparadores propiedad del usuario pero que están en tablas propiedad de otros usuarios. o Los disparadores e índices creados por otros usuarios que están en las tablas del usuario.

•

Los usuarios sin privilegios sólo pueden exportar objetos de su propiedad y este modo no incluirá ningún índice o disparador creado por otros usuarios en las tablas propiedad de este usuario.

15.1.3 Modo Base de Datos Completa Todos los objetos de la base de datos, excepto aquellos propiedad del usuario SYS son exportados al usar este método. Este modo requiere que el usuario que realice la exportación tenga asignado el role EXP_FULL_DATABASE.

15.1.4 Parámetros de la utilidad Export En la siguiente tabla se muestran algunos de los parámetros más utilizados al realizar la exportación. Palabra clave USERID BUFFER COMPRESS

Por Defecto Específico del S.O. Y


Significado Nombre y contraseña de usuario. Tamaño del buffer que se utilizará para almacenar las filas recuperadas antes de escribirlas al fichero de exportación. Un valor Y especifica que durante la importación, el tamaño de la extensión inicial se definirá con un valor igual al tamaño actual del segmento. Un valor N hará que se conserven los

Pág. 133


CONSISTENT

N

CONSTRAINTS

Y

DIRECT

N

FEEDBACK

0

FILE FULL

Expdat.dmp N

GRANTS

Y

HELP

N

INDEXES LOG

Y NULL

OWNER PARFILE RECORDLENGT H ROWS STATISCS

Específico del S.O. Y ESTIMATE

TABLES

tamaños de extensiones actuales. Un valor de Y especifica que toda la operación de exportación se realizará en una transacción de sólo lectura. Expor intentará obtener una imagen de lectura consistente de todos los objetos exportados. Un valor de N especificar que sólo hay que mantener la consistencia a nivel de tabla. Un valor de Y especifica que las restricciones se van a exportar con la tabla. Un valor de N hace que las restricciones no se exporten. Un valor de Y especificar una ruta de acceso directa que se utiliza para la exportación. Un valor de N usa la ruta de acceso convencional. Especifica un entero para solicitar que se muestre un punto cuando se importen n filas. El valor por defecto suprime la presentación. Nombre del fichero de exportación. Un valor de Y especifica la exportación de la base de datos completa. Un valor Y especifica que se exporten todas las concesiones de los objetos. Un valor Y muestra una lista de parámetros y su significado. Este parámetro no se combina con otros parámetros. Este parámetro indica si se desea exportar los índices. El nombre del fichero que almacena todos los mensajes de la exportación. Los nombres de los usuarios para la exportación a nivel de usuario. Especifica el nombre del fichero que contiene una lista de parámetros de exportación. El tamaño del registro de salida. Un valor de Y especifica que los datos se van a exportar. Espefica el método de análisis que se utiliza en importación. Schema.table para la exportación en modo tabla.

Sólo uno de los parámetros FULL=Y, TABLES=[schema.] puede ser especificado.

OWNER=

la

o

Si se especifica la ruta de acceso directa (DIRECT=Y), el parámetro CONSISTENT no se puede definir como Y. Para una guía completa de los parámetros se puede consultar el capítulo “Export” del manual de Oracle Utilities.


Pág. 134


15.2 IMPORT La sintaxis que se utiliza para realizar la importación es la siguiente: $ORACLE_HOME/bin/imp [keyword=] {value | (value, value . . .) } Donde keyword son palabras clave que se explican en la siguiente sección y value es el valor asignado a la palabra clave. Los objetos tabla se importan conforme se leen del fichero de exportación. El fichero de exportación contiene objetos con el siguiente orden: 1. 2. 3. 4. 5. 6.

Definiciones de tipo. Definiciones de tabla. Datos de tabla. Índices de tabla. Restricciones de integridad, vistas, procedimientos y disparadores. Índices de bitmap, funcionales y de dominio.

Esta secuencia del fichero de exportación impide que los datos sean rechazados debido al orden en que se importan las tablas. También se impide que se arranquen disparadores redundantes sobre los mismo datos. Algunos objetos como los procedimientos almacenados, pueden invalidarse en la importación por importarse antes de objetos a los que hacen referencia. Se debe comprobar los objetos con STATUS=INVALID y recompilarlos. Si se importan datos sobre tablas existentes, el orden de importación puede provocar fallos de integridad referencial. Por este motivo se recomienda desactivar las restricciones referenciales para importar datos sobre una tabla existente. Dichas restricciones se pueden volver a activar después de completarse la importación. Las tablas se importarán en el mismo tablespace desde el que se exportaron. Sin embargo, si el tablespace ya no existe o si el usuario no tiene la cuota necesaria, la importación creará la tabla sobre el tablespace por defecto del usuario. Si un usuario es incapaz de acceder al tablespace por defecto, la tabla no se importará.

15.2.1 Parámetros de la utilidad Import Palabra clave USERID BUFFER COMMIT

Por Defecto Específico del S.O. N


Significado Nombre y contraseña de usuario. Tamaño en bytes del buffer al que se transfieren las filas de datos. Un valor de Y especifica que import debería validar después de cada inserción. Por defecto, import valida sólo antes de cargar cada tabla. Si ocurriese algún error se deshace todo lo

Pág. 135


FEEDBACK

0

FILE FROMUSER FULL

Expdat.dmp NULL N

GRANTS

Y

HELP

N

IGNORE

N

INDEXES LOG

Y NULL

PARFILE RECORDLENGT H

Específico del S.O.

ROWS SHOW

Y N

TABLES TOUSER

NULL NULL

hecho antes de continuar. Al especificar este parámetro como Y se evita un crecimiento excesivo de los segmentos de rollback. Especifica un entero para solicitar que se muestre un punto cuando se importen n filas. El valor por defecto suprime la presentación. Nombre del fichero de importación. Una lista de usuarios cuyos objetos van a ser importados. Un valor de Y especifica una importación de base de datos completa. Un valor Y especifica que se importen todas las concesiones de los objetos. Un valor Y muestra una lista de parámetros y su significado. Este parámetro no se combina con otros parámetros. Si el valor se define como Y, import pasa por alto los errores de creación de objetos cuando intenta crear objetos de base de datos. En este caso import continúa sin notificar el error. Para tablas el valor Y hace que las filas se importen sobres las tablas existentes y no mostrando mensajes de error. Un valor de N hace que se notifiquen los errores y la tabla se ignora si todavía existe. Errores como los del sistema operativo, de base de datos y de SQL no se ignoran y pueden parar el procesamiento. Un valor de Y hace que se importen los índices El nombre del fichero que almacena todos los mensajes de la importación. Especifica el nombre del fichero que contiene una lista de parámetros de importación. El tamaño del registro de entrada. Este sólo es necesario si los datos se exportaron en un sistema operativo con un tamaño de registro distinto. Un valor de Y especifica que los datos se van a importar. Si el valor es Y, el contenido del fichero de exportación se enumera en pantalla y no se importa. Las sentencias SQL incluidas en la exportación se muestran en el orden en que la importación las ejecutará. Si este valor es Y los únicos parámetros que se pueden definir son FROMUSER, TOUSER FULL y TABLES Designa las tablas que se van a importar. Una lista de nombres de usuario sobre los que se va a importar sus objetos.

Sólo uno de los parámetros FULL=Y, FROMUSER-TOUSER o TABLES=[schema.] puede ser especificado. Para una guía completa de los parámetros se puede consultar el capítulo “Import” del manual de Oracle Utilities.


Pág. 136


15.3 SQL*LOADER La herramienta de Oracle SQL*Loador está diseñada para realizar carga de datos desde ficheros externos sobre tablas de bases de datos Oracle. Presenta las siguientes características: • • • • • • •

Puede cargar datos desde múltiples ficheros de datos. Puede cargar datos dentro de múltiples tablas durante al misma sesión de carga. Puede seleccionar los datos que desea cargar. Puede manipular datos antes de que sean insertados usando funciones SQL. Puede generar secuencias de valores clave sobre columnas específicas. Puede cargar datos Objetos, Colecciones y datos LOBs. Es una utilidad compatible con la utilidad de carga de DB2.

Para acceder a esta herramienta se debe ejecutar el comando $ORACLE_HOME/bin/sqlldr Los componentes básicos de SQL*Loador se muestran en el siguiente gráfico:

Fig. 15.1 Los parámetros con los que se puede invocar la herramienta SQL*Loader se muestran en la siguiente tabla: Parámetro

Descripción

USERID

Usuario propiertario de la tabla que se va a cargar, o que tiene acceso a dicha tabla, es requerido por Oracle. Nombre del fichero que describe el formato del fichero de entrada

CONTROL


Pág. 137

Valor Defecto NULL NULL


LOG BAD DATA DISCARD DISCARDMA X SKIP LOAD ERRORS ROWS SILENT DIRECT PARFILE PARALLEL READSIZE

de datos para la tabla Oracle. Escribe la salida del comando SQL*Loador en un fichero de log. Si no se indica nada tomará el nombre del fichero de control con extensión .log Nombre del fichero donde se escriben las filas del fichero de entrada que han sido rechazadas durante la carga. Si no se indica nada tomará el nombre del fichero de control con extensión .bad Nombre del fichero de datos Si en la carga se utiliza un filtro, los ficheros que no cumplan dicho filtro se guardarán en el fichero indicado en esta opción. Si no se utiliza no crea ningún fichero de descarte. Número máximo de registros a ser descartados. Si se especifica un número positivo Oracle salta a la fila especificada, e inicia la carga a partir del registro que se encuentra inmediatamente después del indicado. Si se especifica un número positivo, Oracle cargará dicho número exacto de filas. Número de errores permitidos Identifica el número de filas a leer desde el fichero de datos antes de salvar los datos en la base de datos Elimina los mensajes durante el arranque de la utilidad SQL*Loador (header, feedback,errors, discards, partitions, all Usa un path directo Nombre del fichero que contiene los parámetros pasados a la utilidad SQL*Loador Cuando se usa esta opción, se ejecutan múltiples sesiones, cargando los datos simultáneamente. Las tablas destino no deben de tener índices. Especifica en bytes el tamaño del buffer de lectura

NULL NULL NULL NULL ALL 0 ALL 50 ALL NULL FALSE NULL FALSE 65536

15.3.1 Formato del Fichero de Control El formato del fichero de control es el siguiente: load data infile ‘’ into table [ insert | append | replace | truncate ] (campo_1 position(:) tipo de dato, (campo_2 position(:) tipo de dato, … (campo_n position(:) tipo de dato) En la línea INTO TABLE se puede indicar la acción a realizar en la tabla según el modificador seleccionado: •

Insert: es el valor por defecto, e indica que la tabla estará vacía cuando comience la carga.


Pág. 138


• • •

Append: Añade nuevas filas a los contenidos existentes de la tabla. Replace: Borra las filas de la tabla y carga las nuevas filas. Truncate: Se comporta igual que Replace.

Ejemplo Supongamos que se quiere realizar la siguiente carga con las opciones: • • • • • •

Nombre de Usuario: frieda Contraseña: frieda Fichero de Control: bruce.ctl Load: Todos los registros Parallel: SI Direct: No

El formato del fichero de control bruce.ctl puede ser el siguiente: Load data Infile ‘person.dat’ Into table personal When clssn <> ‘CR4’ (first_name position(01:14) char, surname position(15:28) char, clssn position(29:36) char, hire_date position(37:42) date ‘YYYYMMDD’) $ORACLE_HOME/bin/sqlldr frieda/frieda control=bruce.ctl parallel=true


Pág. 139


16 PRÁCTICAS 16.1 TEMA 2: COMPONENTES DE LA ARQUITECTURA ORACLE 1. Un usuario intenta conectarse a una base de datos Oracle y recibe el error “ORA-01034 ORACLE not available”. ¿Cuál de las siguientes causas puede ser el error? a. El usuario introdujo una contraseña no válida b. El usuario introdujo un nombre de usuario no válido c. La instancia a la que se conecta el usuario no está ejecutándose d. La versión de Oracle a la que se está conectando no está instalada. 2. Un usuario ejecuta un comando SQL para actualizar una fila de una tabla de la base de datos. ¿Qué proceso ejecuta esta sentencia? a. Proceso de usuario b. Proceso de Servidor c. DBWR d. LGWR 3. Para la pregunta anterior. ¿Dónde está el cambio que realizó el proceso identificado en la pregunta anterior? a. Fichero de Datos b. Caché de Buffers de la base de datos c. Shared Pool d. Fichero de Parámetros 4. ¿Cuál a. b. c. d.

de los siguientes ficheros almacena segmentos de rollback ? Ficheros de redo log Ficheros de control Fichero de Datos Fichero de Parámetros

5. ¿Cuál a. b. c. d.

de las siguientes áreas de memoria no es una parte de la SGA? Caché de buffers de la base de datos PGA Buffer de Redo Log Shared Pool

6. ¿Cuál de las siguientes áreas de memoria se utiliza para almacenar en caché la información del Diccionario de Datos a. Caché de buffers de la base de datos b. PGA c. Buffer de redo log d. Shared Pool


Pág. 140


7. Cuándo un usuario ejecuta la sentencia commit, ¿en cuál de los siguientes ficheros se registran los cambios antes de que el servidor Oracle devuelva un mensaje de “commit completado” al usuario? a. Fichero de Redo Log b. Fichero de Control c. Fichero de Datos d. Fichero de Parámetros 8. Determinar el tamaño de la caché de buffers de una base de datos 9. Determinar el tamaño de la SGA

16.2 TEMA 3: GESTIÓN DE UNA INSTANCIA ORACLE 1. Arrancar y Montar una instancia de base de datos Oracle 2. Arrancar y Abrir una instancia de base de datos Oracle 3. Parar una Instancia de base de datos Oracle en modo Normal 4. Parar una Instancia de base de datos Oracle en modo Inmediato 5. Parar una Instancia de base de datos Oracle en modo Abort 6. Identificar el nombre de la base de datos, el nombre de la instancia y el tamaño de los bloques de la base de datos 7. Enumerar el nombre y tamaño de los ficheros de datos, ficheros redo log y ficheros de control 8. Determinar el número máximo de cursores permitidos en la base de datos 9. Arrancar y Abrir una instancia de base de datos Oracle con un fichero de parámetros diferente al de por defecto

16.3 TEMA 4: CREACIÓN DE UNA BASE DE DATOS ORACLE 1. Escribir uno o varios scripts para crear una base de datos Oracle, con la siguiente configuración: a. Nombre de la Base de Datos BD. b. Un Fichero de control nombrado control01.ctl y ubicado en un path donde el usuario oracle del sistema operativo pueda escribir. c. Dos grupos de ficheros de redo log, cada uno con un miembro de 150K, denominados redo0101.log y redo0201.log y ubicado en un path donde se vayan a ubicar los ficheros de datos. d. Para cada grupo, el número máximo de grupos de ficheros log y de miembros de ficheros log es de cinco.


Pág. 141


e. Un fichero de datos de 20M, denominado system01.dbf y ubicado en un path donde se vayan a ubicar los ficheros de datos. f. Un máximo de 30 ficheros de datos que se pueden crear en la base de datos. g. Un número máximo de 100 ficheros redo log. h. Juego de caracteres WE8ISO8859PI i. Ubicar los ficheros de trazas sobre directorios bdump y cdump y ubicado en un path donde el usuario oracle del sistema operativo pueda escribir.

16.4 TEMA 5: DICCIONARIO DE DATOS 1. Consultar las vistas V$DATABASE, V$THREAD y V$PARAMETER para identificar el nombre de la base de datos, el nombre de la instancia y el tamaño del bloque de la base de datos. 2. Consultar la vista V$DATAFALE para obtener el nombre y tamaño de los ficheros de datos. 3. Consultar la vista DBA_DATA_FILES para obtener el nombre de los ficheros de datos que forman parte del tablespace SYSTEM. 4. Consultar la vista DBA_FREE_SPACE para obtener la cantidad de espacio libre disponible en la base de datos. 5. Consultar la vista DBA_SEGMENTS para obtener la cantidad de espacio real ocupado por la base de datos. 6. Consultar la vista DBA_USERS para obtener una lista de usuarios creados en la base de datos.

16.5 TEMA 6: GESTIÓN DE TABLESPACES Y FICHEROS DE DATOS 1. Cree un tablespace permanente DATA01 y ubiquelo en la ruta donde se encuentran el resto de los ficheros de datos. El tamaño de dicho tablespace que sea de 2MB. 2. Cree un tablespace permanente INDX01 y ubiquelo en la ruta donde se encuentran el resto de los ficheros de datos. El tamaño de dicho tablespace que sea de 2MB. 3. Modifique el nombre del fichero asociado al tablespace INDX01.


Pág. 142


Curso Admin Oracle

Recommend Documents