INVESTIGACIÓN BIBLIOGRÁFICA SOBRE ORACLE(1)

Arquitectura de Base de Datos Oracle

0

INVESTIGACIÓN BIBLIOGRÁFICA SOBRE ORACLE

CATEDRÁTICO

ING. WILLIAM CASTELLANOS

GRUPO DE TRABAJO: 5

INTEGRANTES

FLORES PEÑATE, MARVIN OMAR FP05028

TOBAR LOPEZ, ERICK DOUGLAS TL07001

VÁSQUEZ MARTÍNEZ, OSCAR ORLANDO VM07003

CIUDAD UNIVERSITARIA, 17 DE NOVIEMBRE DE 2011

UNIVERSIDAD DE EL SALVADOR

FACULTAD DE INGENIERÍA Y ARQUITECTURA

ESCUELA DE INGENIERÍA DE SISTEMAS INFORMÁTICOS

IMPLEMENTACIÓN DE BASES DE DATOS

CICLO II-2011


INTRODUCCIÓN _______________________________________________________ 1

OBJETIVOS ___________________________________________________________ 2

Objetivo General ___________________________________________________________ 2

Objetivos Específicos ________________________________________________________ 2

ALCANCES ____________________________________________________________ 3

LIMITACIONES ________________________________________________________ 3

ARQUITECTURA INTERNA _______________________________________________ 4

Estructuras Lógicas de Almacenamiento ________________________________________ 4

Jerarquía de almacenamiento lógico _________________________________________________ 4

Administración del Espacio Lógico ___________________________________________________ 5

Data Blocks _____________________________________________________________________ 7

Extents _______________________________________________________________________ 13

Segments _____________________________________________________________________ 16

Tablespaces____________________________________________________________________ 19

Estructuras Físicas de Almacenamiento ________________________________________ 23

Mecanismos para almacenamiento de Bases de datos __________________________________ 23

Data File (Archivo de datos) _______________________________________________________ 24

ARQUITECTURA DEL LOG DE TRANSACCIONES (REDO LOG) ___________________ 26

Como está formado el redo log ______________________________________________ 26

Archivos redo log activos e inactivos __________________________________________ 26

Escritura en los archivos redo log (LGWR) ______________________________________ 26

Cambios de Log y números de secuencia _______________________________________ 28

Archivos redo log Archivados ________________________________________________ 28

Multiplexación de Archivos Redo Log ________________________________________________ 29

Respuesta a un fallo de Redo Log _____________________________________________ 30

Configuraciones legales e ilegales _____________________________________________ 30

Colocación de miembros redo log en discos diferentes ____________________________ 31

Planificación del tamaño del archivo redo log ___________________________________ 32

Planificación del tamaño de bloque de los archivo redo log ________________________ 32

Selección del número de archivos redo log _____________________________________ 32

ARQUITECTURA DE OBJETOS ____________________________________________ 33

Esquemas ________________________________________________________________ 33

Tablas ___________________________________________________________________ 33


Orden de las columnas ___________________________________________________________ 35

Tabla de Compresión ____________________________________________________________ 35

Valores nulos __________________________________________________________________ 36

Valores por defecto _____________________________________________________________ 36

Tablas con particiones ___________________________________________________________ 36

Tablas anidadas ________________________________________________________________ 36

Tablas Temporales ______________________________________________________________ 37

Tablas externas _________________________________________________________________ 37

Vistas ___________________________________________________________________ 39

Dependencias y vistas ____________________________________________________________ 39

Vista actualizable de unión (Updatable Join Views) _____________________________________ 40

Vistas de objetos ________________________________________________________________ 40

Vistas en línea __________________________________________________________________ 40

Vistas materializadas ____________________________________________________________ 40

Índices __________________________________________________________________ 41

Índices únicos y no único _________________________________________________________ 43

Índices compuestos _____________________________________________________________ 43

Índices y claves _________________________________________________________________ 43

Índices y valores nulos ___________________________________________________________ 44

Índices basados en funciones ________________________________________________ 44

Formato de los bloques de índice (Index Blocks) _______________________________________ 45

Estructura interna de los índices ___________________________________________________ 45

Propiedades del índice ___________________________________________________________ 46

Índice único de escaneo __________________________________________________________ 47

Índice de Rango de escaneo _______________________________________________________ 47

Key Compression _______________________________________________________________ 48

Índice de clave inversa (Reverse key index) ___________________________________________ 48

Índices Bitmap (Bitmap indexes) ___________________________________________________ 49

Clústers__________________________________________________________________ 50

Hash Clusters _____________________________________________________________ 50

Dimensiones _____________________________________________________________ 51

Sinónimos (Synonyms) _____________________________________________________ 51

ARQUITECTURA DE PROCESAMIENTO DE CONSULTAS _______________________ 53

Uso del Optimizador _______________________________________________________ 53

Componentes del Optimizador _______________________________________________ 54

Transformador de la Consulta _____________________________________________________ 54

Estimador _____________________________________________________________________ 55

Generador del Plan ______________________________________________________________ 55

Caminos de Acceso ________________________________________________________ 55

Estadísticas del Optimizador _________________________________________________ 56

Sugerencias del Optimizador ______________________________________________________ 57

ARQUITECTURA DE SUBPROCESOS Y TAREAS _______________________________ 58


Múltiples procesos de Oracle Database Systems _________________________________ 58

Tipos de procesos _________________________________________________________ 59

Procesos de Usuario _____________________________________________________________ 60

Procesos del Servidor ____________________________________________________________ 61

Procesos en segundo plano _______________________________________________________ 62

Procesos esclavos _______________________________________________________________ 65

ARQUITECTURA DE ADMINISTRACIÓN DE MEMORIA ________________________ 66

System Global Area ________________________________________________________ 66

Automatic Shared Memory Management ____________________________________________ 68

Administración de forma manual de los componentes SGA ______________________________ 69

Database Buffer Cache _____________________________________________________ 70

El algoritmo LRU y Análisis Completo ________________________________________________ 71

Redo Log Buffer ___________________________________________________________ 71

Shared Pool ______________________________________________________________ 72

Library Cache _____________________________________________________________ 72

Diccionario de caché _______________________________________________________ 72

Asignación y reutilización de la Memoria en la zona compartida ____________________ 73

Large Pool________________________________________________________________ 73

Java pool ________________________________________________________________ 74

Streams Pool _____________________________________________________________ 74

Control del Uso de la SGA de la Memoria_______________________________________ 74

Diagramas y documentación de las bases de datos del sistema ________________ 76

Esquemas SYS y SYSTEM ____________________________________________________ 78

Catálogo de Datos _________________________________________________________ 78

Listado alfabético de las vistas del sistema de Oracle ___________________________________ 81

CONCLUSIONES ______________________________________________________ 82

RECOMENDACIONES __________________________________________________ 83

REFERENCIAS BIBLIOGRÁFICAS __________________________________________ 84

ANEXOS ____________________________________________________________ 85

Clasificación de los Tipos de Datos ____________________________________________ 85

Diagrama de la Arquitectura Oracle 11g________________________________________ 86

Comparaciones entre Oracle y SQLServer ______________________________________ 87

Address Space __________________________________________________________________ 87

Arquitectura Interna _____________________________________________________________ 87

Database ______________________________________________________________________ 88

GLOSARIO ___________________________________________________________ 89


Página 1

INTRODUCCIÓN

El manejo de datos e información ha tenido una gran importancia a través de los años, debido

a esto hoy en día contamos con un conjunto de herramientas como los RDBMS que han sido

diseñados para cumplir con el objetivo de almacenar los datos de una manera rápida y segura,

pero para darle un uso adecuado y aprovechar cada una de las ventajas que nos ofrecen, no

basta solo con saber cómo almacenar nuestros datos si no que debemos de saber con

exactitud el funcionamiento que estos tienen y como administran la información, uno de los

RDBMS más potentes que existe en el mercado en la actualidad es ORACLE y en el presente

documento se presenta una investigación profunda acerca del funcionamiento y de cada una

de las características que este posee, abarcando aspectos como la arquitectura interna donde

se presenta en detalle cómo se realiza el almacenamiento de nuestros datos a través de

páginas, extensiones, archivos, grupo de archivos, etc. Además de esto se presenta la forma en

que Oracle controla cada uno de los cambios ocurridos en las distintas bases de datos a través

del log de transacciones.

Otras características de importancia de Oracle que se presentan son la arquitectura de

elementos fundamentales como los objetos que Oracle maneja, la arquitectura del

procesamiento de consultas, la arquitectura de la administración de memoria, y la arquitectura

de sub procesos y tareas, así también se presentan diagramas y documentación de las bases de

datos master, model y tempdb que son las bases de datos del sistema de Oracle.


Página 2

OBJETIVOS

Objetivo General

Realizar una investigación bibliográfica sobre la arquitectura interna, log de transacciones, objetos, procesamiento de consultas, memoria, procesos y sub procesos y bases de datos del sistema del Gestor de Base de Datos Oracle.

Objetivos Específicos

Investigar el funcionamiento de la Base de Datos de Oracle.

Conocer y comprender de mejor manera la arquitectura interna de la Base de Datos de

Oracle.

Comprender el funcionamiento de los elementos internos de la base de datos, como el

uso de memoria y los procesos propios de la base de datos.

Conocer las bases de datos propias del sistema, sus características y funcionamiento básico.

Comprender todos estos elementos y conceptos, para que de esta manera nos permita

mejorar nuestras habilidades en la administración de bases de datos Oracle.

Reconocer cuales son los procesos más importantes realizados por este gestor de

bases de datos.

Identificar los objetos con los cuales trabaja Oracle Database


Página 3

ALCANCES

El desarrollo de este proyecto bibliográfico abarcará una investigación sobre arquitectura interna, arquitectura del log de transacciones, arquitectura de objetos, arquitectura de procesamiento de consultas, arquitectura de procesos y subprocesos, diagramas y documentación de las bases de datos del sistema del gestor de bases de datos Oracle.

LIMITACIONES

Información de diversas fuentes, puede atrasar la investigación, o los cambios entre versiones de la base de datos.

Recelo de algún tipo de información por parte de los creadores de la base de datos de Oracle, como lo son los esquemas del sistema.

La información se encuentra en idioma inglés, la cual pudiera presentar inconsistencia al traducirla a nuestro lenguaje nativo.


Página 4

ARQUITECTURA INTERNA

Estructuras Lógicas de Almacenamiento

Oracle Database asigna un espacio lógico de todos los datos en la base de datos. Las unidades lógicas de espacio de asignación de bases de datos:

Data Blocks

Extents

Segments

Tablaspaces

A nivel físico, los datos se almacenan en el disco en data files. Los datos en los data files se almacenan en bloques del sistema operativo.

Diagrama entidad-relación para el almacenamiento físico y lógico.

Jerarquía de almacenamiento lógico

La figura muestra las relaciones ente los bloques de datos, extensiones y segmento en un tablespace. En este ejemplo, un segmento tiene dos extensiones almacenadas en diferentes archivos de datos.


Página 5

En el nivel más bajo, Oracle Database almacena los datos en bloques de datos. Un bloque de datos lógico corresponde a un específico número de bytes en el espacio físico del disco, por ejemplo, 2 KB. Los bloques de datos son las unidades más pequeñas de almacenamiento que la base de datos de Oracle pues utilizar o gestionar.

Una extensión es un conjunto de bloques de datos lógicamente contiguos localizados para el almacenamiento un tipo de información específica. En la figura, la extensión de 24 KB tiene 12 bloque de datos, mientras que la extensión de 72 KB tiene 36 bloques de datos.

Un segmento es un conjunto de extensiones utilizadas para un específico objeto de base de datos, tal como una tabla. Por ejemplo, los datos para la tabla employees es almacenada en su propio segmento de datos, y cada índice de dicha tabla es almacenado en su propio segmento de índice.

Cada segmento pertenece a uno y solo un tablespace. Por ejemplo, una extensión para un segmento podría estar en users01.dbf, mientas que otro es almacenado en users02.dbf.

Administración del Espacio Lógico

Oracle Database debe utilizar administración del espacio Lógico para rastrear y ubicar las extensiones en un tablespace. Cuando algún objeto de la base de datos necesita una extensión, la base de datos debe tener un método que le permita buscarlo y asignarlo. De la misma manera, cuando un objeto de la base de datos ya no necesita una extensión, la base de datos debe tener un método que le permita liberar la extensión.

Oracle Database gestiona el espacio con dentro de un tablespace basado en el tipo con el que

se ha creado. Se puede crear cualquiera de los siguientes tipos de tablespace

Tablespaces gestionado localmente (por defecto)

La base de datos utiliza mapa de bits en los tablespaces para administrar las

extensiones. Dentro de un tablespace, la base de datos puede gestionar segmentos


Página 6

con automatic segment space management (ASSM) o manual segment space

management (MSSM).

Tablespaces gestionados con diccionario

La base de datos gestionar el tablespace utilizando el diccionario de datos


Página 7

Data Blocks

Oracle Database gestiona el almacenamiento lógico del espacio en los archivos de dato de una base de datos en unidades llamadas data blocks, también llamadas Oracle blocks o pages. Un data block es la unidad mínima de I/O de la base de datos.

Data Blocks y Operating System Blocks

En el nivel físico, los datos de base de datos se almacenan en los archivos del disco compuesto por bloques de sistema operativo. Un bloque del sistema operativo es la unidad mínima de datos que el sistema operativo puede leer o escribir. En contraste, un bloque de datos es una estructura lógica de almacenamiento cuyo tamaño y estructura no son conocidos para el sistema operativo.

La figura muestra que el funcionamiento de los bloques de sistema puede variar en tamaño de los bloques de datos.

Cuando la base de datos solicita un bloque de datos, el sistema operativo convierte esta operación en una solicitud de datos en el almacenamiento permanente. La separación lógica de los bloques de datos a partir de bloques del sistema operativo tiene las siguientes implicaciones:

Las aplicaciones no necesitan determinar las direcciones físicas de los datos en el

disco.

Los datos de base de datos pueden ser particionados o reflejados en varios discos

físicos.

Tamaño del Data Block

Cada base de datos tiene un tamaño de bloque de datos. El parámetro de inicialización DB_BLOCK_SIZE, establece el tamaño de bloque de datos para una base de datos cuando se crea. El tamaño se establece para los tablespaces SYSTEM y SYSAUX y es el valor por defecto


Página 8

para los demás tablespaces. El tamaño del bloque de datos no puede ser cambiado excepto si se vuelve a crear la base de datos.

Si DB_BLOCK_SIZE no está definido, entonces el tamaño por defecto del bloque de datos es específico del sistema operativo. El tamaño de los datos estándar de bloque para una base de datos es de 4 KB o 8 KB. Si el tamaño es diferente para los bloques de datos y los bloques del sistema operativo, entonces el tamaño de bloque de datos debe ser un múltiplo del tamaño de bloque del sistema operativo.

Tamaño de Tablespace Block

Se puede crear tablespaces que tenga diferente tamaño al especificado en DB_BLOCK_SIZE. Un data block de tamaño no estándar puede ser útil cuando se mueve un tablespace a una plataforma diferente.

Formato del Data Block

Cada bloque de datos tiene un formato o estructura interna que permite a la base de datos dar seguimiento de los datos y el espacio libre en el bloque. Este formato es similar si el bloque de datos contiene tablas, índices o tablas clúster. La figura muestra el formato de un bloque de datos descomprimido.

Cabecera del Data Block

Oracle Database usa la cabecera del bloque para gestionar el bloque. La cabecera del bloque no está disponible para almacenar datos. La cabecera del bloque incluye las siguientes partes:

Encabezado del bloque:

Esta parte contiene información general sobre el bloque de datos, incluida la dirección

del disco y el tipo de segmento. Para los bloques que gestionan las transacciones, el

encabezado del bloque contiene información de la transacción activa e histórica.

Una entrada de transacción es requerida para cada transacción que actualice el

bloque. Oracle Database inicialmente reserva espacio en el encabezado del bloque

para entradas de transacción. En los bloques de datos asignados a los segmentos que


Página 9

soportan cambios transaccionales, el espacio libre también puede mantener entradas

de transacción cuando el espacio del encabezado se ha agotado. El espacio necesario

para una entrada de transacción depende del Sistema Operativo. Sin embargo las

entradas de transacción de la mayoría de los sistemas operativos necesitan

aproximadamente 23 bytes.

Directorio de Tabla.

Para una tabla de montón organizada, este directorio contiene meta datos de las

tablas cuyos registros se guardan en este bloque. Varias tablas pueden almacenar las

filas en el mismo bloque.

Directorio de la fila.

Para una tabla de montón organizada, este directorio describe la ubicación de las filas

de la parte de datos del bloque. Después de que el espacio ha sido asignado en el

directorio de la fila, la base de datos no recupera este espacio después de la

eliminación de una fila. Por lo tanto, un bloque que está actualmente vacío, pero antes

tenía hasta 50 filas sigue teniendo100 bytes asignados para el directorio de la fila. La

base de datos vuelve a utilizar este espacio sólo cuando se agregan nuevas filas en el

bloque.

Algunas partes del encabezado del bloque tienen un tamaño fijo, pero el tamaño total

es variable. En promedio, el tamaño del encabezado de bloque varía entre 84 a 107

bytes.

Formato de Fila

La parte de datos de la fila del bloque contiene los datos reales, tales como una tabla o las entradas de índice de clave. Así como cada bloque de datos tiene un formato interno, cada fila tiene un formato de registro que permite a la base de datos rastrear los datos de la fila.

Oracle almacena en la base de datos las filas como registros de longitud variable. Una fila se encuentra en una o más piezas seguidas. Cada pieza tiene una fila de encabezado de fila y columna de datos.


Página 10

Row Header

Oracle Database usa el encabezado de la fila para gestionar la fila almacenada en el bloque. El encabezado de li fila contiene la siguiente información:

Columnas en la fila

Piezas de la fila localizadas en otros bloques de datos

Si la fila entera puede ser insertada dentro de un solo bloque de datos, entonces

Oracle Database almacena la fila como una sola fila. Sin embargo, si toda la fila de

datos no puede ser insertada en un solo bloque o una actualización hace que una fila

existente supere el tamaño del bloque, entonces la base de datos almacena la fila en

múltiples piezas de la fila. Un bloque de datos usualmente contiene solo una pieza de

fila por fila

Llaves Clúster para tablas clúster

Una fila completa contenida en un bloque contiene al menos 3 bytes de encabezado de fila.

Column Data

Después del encabezado de fila, la sección de columna de datos almacena los datos actuales de la fila. La pieza de la fila usualmente almacena las columnas en el orden listado en la sentencia CREATE TABLE, pero este orden no es garantizado. Por ejemplo, columnas del tipo LONG so creados al final.

Como se muestra en la figura anterior, para cada columna en una pieza de fila, Oracle Database almacena el tamaño y el dato separadamente. El espacio necesario depende del tipo de dato. Si el tipo de datos de una columna es de tamaño variable, entonces el espacio necesario para mantener los valores puede crecer y disminuir con cada actualización de los datos.


Página 11

Cada fila tiene un espacio en el directorio de la fila del encabezado del bloque. Este espacio indica el inicio de la fila.

Formato del Rowid

Oracle Database utiliza un rowid para identificar de forma única una fila. Internamente, el rowid es una estructura que tiene información que la base de datos necesita para acceder a una fila. Un rowid no es físicamente almacenado en la base de datos, pero se infiere de los archivos y bloques en los que se almacenan los datos.

Gestión de espacio en los data blocks

Como la base de datos llena un bloque de datos desde abajo hacia arriba, la cantidad de espacio libre entre las filas de datos y el encabezado del bloque disminuyen. Este espacio libre también se puede reducir durante las actualizaciones, como cuando se cambia un valor nulo final a un valor no nulo. La base de datos gestiona el espacio libre en el bloque de datos para optimizar el rendimiento y evitar el desperdicio de espacio.

Porcentaje de espacio libre en data blocks

El parámetro PCTFREE es esencial en la forma en que la base de datos gestiona el espacio libre. Este parámetro SQL establece el porcentaje mínimo de un bloque de datos reservados como espacio libre de cambios a las filas existentes. Por lo tanto, PCTFREE es importante para prevenir la migración de filas y evitar desperdicio de espacio.


Página 12

Optimization of Free Space in Data Blocks

Mientras que el porcentaje de espacio disponible no puede ser menor que el especificado en PCTFREE, la cantidad de espacio disponible puede ser mayor. Las siguientes sentencias SQL pueden incrementar el espacio libre:

Sentencias DELETE

Sentencias UPDATE que, o bien actualice valores a valores más pequeños o incremente

los valores existentes y obligue una a la fila a migrar

Sentencias INSERT en una tabla que utiliza compresión OLTP

Chained and Migrated Rows

Oracle Database debe administrar filas que son demasiado grandes para caber en un solo bloque de datos:

La fila es demasiado grande para caber en un solo bloque de datos cuando es

insertada por primera vez.

En el encadenamiento de fila, Oracle Database almacena los datos de la fila en una

cadena de una o más bloque de datos reservados para el segmento. El

encadenamiento ocurre más frecuentemente con columnas largas.

Una fila que originalmente cabe en un bloque de datos es actualizada tal que la

sumatoria del tamaño de las filas incrementa, pero el espacio libre disponible es

insuficiente para mantener la fila actualizada.

En la migración de filas, Oracle Database mueve la fila entera a un nuevo bloque de

datos, asumiendo que la fila cabe en el nuevo bloque de datos. La pieza de la fila

original de una fila migrada contiene un puntero al nuevo bloque. El rowid de una fila

migrada no cambia con la migración.

Una fila puede contener más de 255 columnas

Oracle Database solo puede almacenar 255 columnas en una pieza de fila. Así, si se

inserta una fila dentro una tabla que tiene más de 1000 columnas, entonces la base de

datos crea 4 piezas de fila, típicamente encadenada sobre múltiples bloques.


Página 13

Row Chaining

Row Migration

Extents

Una extensión es una unidad lógica de asignación de espacio de almacenamiento de base de datos compuesta de bloque de datos contiguos. Los bloques de datos en un punto son lógicamente contiguos, pero pueden ser físicamente hacia separados en el disco debido a la creación de RAID y las implementaciones de sistemas de archivos.


Página 14

La asignación de extensiones

De manera predeterminada, la base de datos asigna una extensión inicial de un segmento de datos cuando el segmento se crea. Una extensión es siempre contenida en un archivo de datos.

Aunque no hay datos añadidos al segmento, los bloques de datos en la medida inicial se reservan exclusivamente para este segmento. El primer bloque de datos de cada segmento contiene un directorio de las extensiones en el segmento. La figura muestra el grado inicial de un segmento de un archivo de datos que antes de contener datos.

Si la extensión inicial se completa, y necesita más espacio, entonces la base de datos asigna automáticamente un punto incremental para este segmento. Una extensión incremental es una medida posterior creada para el segmento.

El algoritmo de asignación depende de si el tablespace está gestionado localmente o administrado por diccionario. En el caso de gestión local, la base de datos busca en el mapa de bits de un archivo de datos de bloques adyacentes libres. Si el archivo de datos no tiene espacio suficiente, entonces la base de datos se ve en otro archivo de datos. Las extensiones de un segmento siempre están en el mismo tablespace, pero pueden estar en diferentes archivos de datos.

La figura muestra que la base de datos puede asignar extensiones de un segmento en cualquier archivo de datos en el espacio de tablas. Por ejemplo, el segmento puede asignar la extensión inicial en users01.dbf, asignar el primer incremento en users02.dbf, y asignar el siguiente en users01.dbf.


Página 15

Cancelación de la asignación de Extents

En general, las extensiones de un segmento de usuario no regresan al tablespace a menos que se liberen utilizando un comando DROP. En Oracle Database 11g Release 2 (11.2.0.2), también se pueden liberar segmentos usando el paquete DBMS_SPACE_ADMIN. Por ejemplo, Si se eliminan todas las filas en una tabla, entonces la base de datos no pide el bloque de datos para que otros objetos en el tablespace lo utilicen.

Parámetros de Almacenamiento para los Extents

Cada segmento es definido por parámetros de almacenamiento expresados en términos de extensiones. Estos parámetros controlan como Oracle Database asigna el espacio disponible a un segmento

La configuración del almacenamiento está determinada en la siguiente lista:

1. Cláusula de almacenamiento del segmento

2. Cláusula de almacenamiento del tablespace

3. Valor predeterminado de Oracle Database

Un tablespace gestionado localmente puede tener extensiones con tamaños uniformes os

extensiones de tamaños variables determinados automáticamente por el sistema:

Para extensiones uniformes, se puede especificar el tamaño de la extensión o utilizar

el tamaño por defecto de 1 MB. Todas las extensiones en el tablespace serán del

mismo tamaño.

Para asignación de extensiones automáticas, Oracle Database determina el tamaño

óptimo de las extensiones adicionales.


Página 16

Segments

Un segmento es un conjunto de extensiones que contiene todos los datos de una estructura lógica de almacenamiento dentro de un tablespace. Por ejemplo, la base de datos Oracle asigna uno o más extensiones para formar el segmento de datos de una tabla. La base de datos también asigna una o más extensiones para formar el segmento de índice para una tabla.

Un segmento, puede ser reservado de una sola vez (10 Mb de golpe), o de varias veces (5 Mb hoy y 5 Mb mañana). Cada una de las veces que se reserva espacio se denomina “extensión”.

Segmentos de Usuarios

Un segmento de datos individual en una base de datos almacena los datos de un objeto de usuario. Hay diferentes tipos de segmentos. Algunos ejemplos de segmentos de usuarios son:

Table, table partition, or table cluster LOB or LOB partition Index or index partition

Cada objeto de particiones y partición de objeto se almacena en su propio segmento. Por ejemplo, si un índice tiene cinco particiones, entonces cinco segmentos contienen los datos del índice.

Creación de Segmentos de Usuario

De manera predeterminada, la base de datos utiliza la creación del segmento diferido para actualizar los metadatos de la base de datos sólo cuando hay creación de tablas e índices. A partir de Oracle Database 11g Release 2 (11.2.0.2), la base de datos también difiere la creación de segmento al crear particiones. Cuando un usuario inserta la primera fila en una tabla o una partición, la base de datos crea los segmentos de la tabla o partición, sus columnas LOB, y sus índices.

La creación del segmento diferido le permite evitar el uso de los recursos de base de datos innecesariamente. Por ejemplo, la instalación de una aplicación puede crear miles de objetos, consumiendo mucho espacio en disco. Muchos de estos objetos no se pueden utilizar.

Usted puede utilizar el paquete DBMS_SPACE_ADMIN para manejar segmentos de objetos vacíos. A partir de Oracle Database 11g Release 2 (11.2.0.2), puede utilizar este paquete de PL / SQL para hacer lo siguiente:

Materializar de forma manual los segmentos de tablas vacías o particiones que no

tienen segmentos creados

Eliminar los segmentos de las tablas de particiones vacía o que actualmente tienen

asignado un segmento vacío

La figura muestra cómo se crea un nuevo segmento al crear una nueva tabla asumiendo que la

creación de segmentos diferidos esta deshabilitada.


Página 17

Cuando se crea una tabla con una clave de la clave principal o única, la base de datos Oracle crea automáticamente un índice para esta clave. Asumiendo que la creación de segmentos diferidos está desactivado. Se crea una tabla de la siguiente manera:

Existen cuatro tipos de segmentos (principalmente):

Segmentos de TABLE: aquellos que contienen tablas

Segmentos de INDEX: aquellos que contienen índices

Segmentos de ROLLBACK: aquellos se usan para almacenar información de la

transacción activa.

Segmentos TEMPORALES: aquellos que se usan para realizar operaciones temporales

que no pueden realizarse en memoria, tales como ordenaciones o agrupaciones de

conjuntos grandes de datos.


Página 18

Segmentos Temporales

Cuando se procesa una consulta, Oracle Database con frecuencia requiere espacio de trabajo

temporal para etapas intermedias de la ejecución de la sentencia SQL. Las operaciones que

típicamente podría requerir el uso de segmentos temporales son: ordenamiento, hashing, y

fusión de bitmaps. Mientras se crea un índice, Oracle Database también coloca segmentos del

índice dentro de segmentos temporales y después convierte estos en segmentos permanentes

cuando el índice se completa.

Oracle Database no crea segmentos temporales si una operación puede ser realizada en

memoria. Sin Embargo, si el uso de la memoria no es posible, entonces la base de datos

automáticamente destina un segmento temporal en el disco.

Segmentos de Deshacer

Oracle Database mantiene registros de las todas las acciones de transacciones, colectivamente conocida como datos de deshacer. Oracle Database utiliza deshacer para hacer lo siguiente:

● Roll back en una transacción activa

● Recuperar una transacción terminada

● Proveer Consistencia de Lectura

● Realizar algunas operaciones lógicas de flashback

Oracle Database almacena datos de deshacer dentro la base de datos stores undo data inside

the database en lugar de en los registros externos. Los datos de deshacer son almacenados en

bloques que so actualizados al igual que los bloques de datos. En cambio, Oracle Database

puede acceder eficientemente a datos de deshacer sin necesidad de leer los registros

externos.

Los datos de deshacer son almacenados en tablespace de deshacer. El Oracle Database provee

un completo automatizado mecanismo, conocido como automatic undo management mode,

para gestionar los segmentos de deshacer y el espacio en los tablespace de deshacer.

Rollback de Transacciones

Cuando una sentencia ROLLBACK se emite, la base de datos utiliza registros de deshacer para realizar los cambios hechos en la base de datos por transacciones no confirmadas. Durante la recuperación, la base de datos regresa cualquier cambio aplicado del redo log en línea a los archivos de datos. Los registros de deshacer proveen consistencia en la lectura manteniendo la imagen anterior de los datos para los usuarios que acceden a los datos al mismo tiempo que otro usuario los está cambiando.


Página 19

High Water Mark

Para administrar el espacio, Oracle Database marca el estado de los bloques en el segmento. La high water mark (HWM) es el punto en un segmento más allá donde se encuentran los bloques de datos sin formato y que nunca han sido usados.

MSSM utiliza listas para administrar el espacio de los segmentos. En la creación de una tabla,

ningún bloque en el segmento está formateado. Cuando una sesión realiza la primera inserción

dentro de una tabla, la base de datos busca la lista de bloques utilizables. Si la base de datos

encuentra bloques no utilizados, entonces preformatea un grupo de bloques, los localiza en la

lista, e inicia la inserción de los datos dentro de los bloques. En MSSM, un escaneo completo

de la tabla lee todos los bloques por debajo de HWM.

ASSM no utiliza una lista y por lo tanto gestiona el espacio de manera diferente. Cunado una

sesión realiza la primera inserción dentro de una tabla, la base de datos formatea un solo

bloque de mapa de bits en vez de preformatear un grupo de bloques como en MSSM. El mapa

de bits marca el estado de los bloques en el segmento, tomando el lugar de la lista. La base de

datos utiliza un mapa de bits para encontrar bloques libres y entonces formatea cada bloque

antes de llenarlos con datos.

Tablespaces

Un tablespace es un contenedor de almacenamiento lógico de los segmentos. Los segmentos son los objetos de base de datos, como tablas e índices, que consumen espacio de almacenamiento. En el nivel físico, un tablespace de datos almacena en uno o más archivos de datos o archivos temporales.

Un objeto en base de datos debe estar almacenado obligatoriamente dentro de un tablespace.

Las propiedades que se asocian a un tablespace son:

Localización de los ficheros de datos.

Especificación de máximas cuotas de consumo de disco.

Control de la disponibilidad de los datos (en línea o fuera de línea).

Backup de datos.

Cuando un objeto se crea dentro de un cierto tablespace, este objeto adquiere todas las propiedades antes descritas del tablespace utilizado.

Una base de datos que tiene el sistema de tablas y SYSAUX. La figura muestra los espacios de tabla en una base de datos típico. En las secciones siguientes se describen los tipos de tablas.


Página 20

Tablespaces permanentes

Los segmentos de los objetos en el tablespace se almacenan físicamente en los archivos de datos.

A cada usuario de base de datos se le asigna un tablespace por defecto permanente. A una base de datos muy pequeña solo necesitaría los tablespace SYSTEM y SYSAUX. Sin embargo, Oracle recomienda que se cree al menos un espacio de tablas para almacenar datos de usuario y aplicación. Puede utilizar los tablespace para lograr los siguientes objetivos:

Control de asignación de espacio en el disco para los datos de la base de datos.

Asignar una cuota (asignación de espacio o límite) a un usuario de base de datos

Toma de tablas individuales en línea o fuera de línea sin afectar a la disponibilidad de

la base de datos completa

Realizar copias de seguridad y recuperación de espacios de tabla individuales

Importar o exportar datos de las aplicaciones mediante la utilidad de Oracle Data

Pump

Crear un tablespace transportable que se puede copiar o mover a partir de una base

de datos a otro, incluso a través de plataformas

Cuando un objeto se crea dentro de un cierto tablespace, este objeto adquiere todas las propiedades antes descritas del tablespace utilizado.


Página 21

SYSTEM Tablespace

El tablespace SYSTEM es un tablespace administrativo necesario incluido en la base de datos cuando se crea. Oracle Database utiliza SYSTEM para gestionar la base de datos.

El tablespace SYSTEM incluye los siguientes datos, todos de propiedad del usuario SYS:

El diccionario de datos Tablas y vistas que contienen la información administrativa sobre la base de datos objetos almacenados compilados como triggers, procedimientos, y paquetes

El tablespace SYSTEM se maneja como cualquier otro tablespace, pero requiere un mayor nivel de privilegio y se restringe de alguna manera. Por ejemplo, usted no puede cambiar el nombre o eliminar el tablespace SYSTEM.

SYSAUX Tablespace

SYSAUX es un tablespace auxiliar para SYSTEM. SYSAUX proporciona una ubicación centralizada para los metadatos de la base de datos que no residen en SYSTEM. Se reduce el número de espacios de tabla crea de forma predeterminada, tanto en la base de datos de central y en las bases de datos definidas por el usuario.

Varios componentes de base de datos, incluyendo Oracle Enterprise Manager y Oracle Streams, utilizan SYSAUX como su ubicación de almacenamiento predeterminada. Por lo tanto, el espacio de tablas SYSAUX se crea automáticamente durante la creación de bases de datos o actualización.

Durante la operación de base de datos normal, la base de datos no permite al tablespace SYSAUX, detenerse o cambiar de nombre. Si SYSAUX no está disponible, entonces la funcionalidad de base de datos central sigue en funcionamiento. Las características de base de datos que utilicen el SYSAUX podrían fallar, o funcionar con una capacidad limitada.

Tablespace de deshacer

Un tablespace de deshacer es un tablespace gestionado localmente reservado para el sistema administrado de datos de deshacer. Al igual que otros tablespaces permanentes, estos contienen los archivos de datos. Los bloques de deshacer en estos archivos se agrupan en extensiones.

Se utiliza para almacenar segmentos de deshacer, no puede contener ningún otro objeto, las

extensiones se gestionan de forma local y sólo puede utilizar las cláusulas DATAFILE y EXTENT

MANAGEMENT

Tablespaces Temporales

Un espacio de tablas temporal contiene los datos transitorios que persiste sólo durante la duración de la sesión. No hay objetos de esquema permanente que puedan residir en un espacio de tablas temporal. La base de datos almacena datos temporales de tablas en los archivos temporales.


Página 22

Lo tablespaces temporales pueden mejorar la concurrencia de múltiples operaciones de ordenación que no caben en la memoria. Estos tablespaces que también mejoran la eficiencia de las operaciones de gestión del espacio durante las clases.

Cuando el tablespace SYSTEM es administrado localmente, un tablespace temporal por defecto está incluido en la base de datos por defecto durante la creación de bases de datos. Un tablespace SYSTEM de gestión local no puede servir de almacenamiento temporal por defecto.

Modos del Tablespace

El modo del Tablespace determina la accesibilidad de las tablas.

Lectura / escritura y de tablespace de sólo lectura

Cada tablespace se encuentra en un modo de escritura que especifica si se puede

escribir. Los modos excluyentes son los siguientes:

Modo lectura / escritura

Los usuarios pueden leer y escribir en el tablespace. Todos los espacios de tablas que

se crean inicialmente como lectura / escritura. Los tablespaces SYSTEM y SYSAUX y

tablespaces temporales de forma permanente de lectura / escritura, lo que significa

que no puede ser de sólo lectura.

Modo de sólo lectura

Operaciones de escritura en los archivos de datos en el tablespace se les impide. Un

tablespace de sólo lectura puede residir en medio de sólo lectura, como DVD o discos

WORM.

Online y Offline Tablespaces

Un tablespace puede estar online (accesible) u offline (inaccesible) siempre que la base de datos esté abierta. Un tablespace esta usualmente online y sus datos son accesibles para los usuarios. SYSTEM tablespace y los tablespaces temporales no pueden estar offline.

Tamaño de Archivo de Tablespaces

Un tablespace puede ser bigfile tablespace o un smallfile tablespace. Estos tablespaces no distinguen en términos de ejecución de instrucciones SQL que no hacen referencia explícita a los archivos de datos o archivos temporales. La diferencia es la siguiente:

Un tablespace pequeño puede contener varios archivos de datos o archivos temporales, pero los archivos no pueden ser tan grandes como en un tablespace grande. Este es el tipo de tablespace predeterminado.


Página 23

Estructuras Físicas de Almacenamiento

Una de las características de un RDBMS es la independencia delas estructuras de datos lógicos, como tablas, vistas e índices de las estructuras de almacenamiento físico. Debido a que las estructuras físicas y lógicas son independientes, se puede administrar el almacenamiento físico de datos sin afectar el acceso a las estructuras lógicas. Por ejemplo, cambiar el nombre de un archivo de base de datos no cambia el nombre de las tablas almacenadas en ella.

Archivos de datos generados cuando se emite la instrucción CREATE DATABASE:

Los datafile (archivos de datos) y archivos temporales

Un archivo de datos es un archivo físico en disco que fue creado por la base de datos Oracle y contiene las estructuras de datos tales como tablas e índices. Un archivo temporal es un archivo de datos que pertenece a una tabla temporal. Los datos se escriben en estos archivos en un formato propiedad de Oracle de que no puede ser leído por otros programas.

Los control file (archivos de control)

Un archivo es un archivo de control de la raíz que hace un seguimiento de los componentes físicos de la base de datos.

Los archivos de online redo log

El registro de rehacer en línea es un conjunto de archivos que contienen los registros de los cambios realizados a los datos.

Una instancia de base de datos es un conjunto de estructuras de memoria que manejan los archivos de base de datos. La muestra la relación entre la instancia y los archivos que gestiona.

Mecanismos para almacenamiento de Bases de datos

Varios mecanismos están disponibles para la asignación y gestión del almacenamiento de estos archivos. Los mecanismos más comunes incluyen:


Página 24

Oracle Automatic Storage Management (ASM Oracle)

Sistema de Archivos del Sistema Operativo

Dispositivos Raw

Sistema de Archivos Clúster

Data File (Archivo de datos)

Un datafile es la representación física de un tablespace. Son los "ficheros de datos" donde se almacena la información físicamente. Un datafile puede tener cualquier nombre y extensión (siempre dentro de las limitaciones del sistema operativo), y puede estar localizado en cualquier directorio del disco duro, aunque su localización típica suele ser $ORACLE_HOME/Database. Un datafile tiene un tamaño predefinido en su creación (por ejemplo 100Mb) y este puede ser alterado en cualquier momento. Cuando creemos un datafile, este ocupará tanto espacio en disco como hayamos indicado en su creación, aunque internamente esté vacío. Oracle hace esto para reservar espacio continuo en disco y evitar así la fragmentación. Conforme se vayan creando objetos en ese tablespace, se irá ocupando el espacio que creó inicialmente.

Un datafile está asociado a un solo tablespace y, a su vez, un tablespace está asociado a uno o varios datafiles. Es decir, la relación lógica entre tablespaces y datafiles es de 1-N, maestro-detalle.

En la figura podemos ver como el “Tablespace A” está compuesto (físicamente) por tres datafiles (DATOS_1.ORA, DATOS_2.ORA y DATOS_3.ORA). Estos tres datafiles son los ficheros físicos que soportan los objetos contenidos dentro del tablespace A. Aunque siempre se dice que los objetos están dentro del tablespace, en realidad las tablas están dentro del datafile, pero tienen las propiedades asociadas al tablespace.


Página 25

Cada uno de los datafiles utilizados está ocupando su tamaño en disco (50 Mb los dos primeros y 25 Mb el último) aunque en realidad sólo contengan dos objetos y estos objetos no llenen el espacio que está asignado para los datafiles.

Los datafiles tienen una propiedad llamada AUTOEXTEND, que se si está activa, se encarga de que el datafile crezca automáticamente (según un tamaño indicado) cada vez que se necesite espacio y no exista. Al igual que los tablespaces, los datafiles también pueden estar en línea o fuera de ella.

Estructura Data File

Oracle Database crea un data file para cada tablespace mediante la asignación de la cantidad de espacio de disco más la sobrecarga del encabezado del archivo de datos. El sistema operativo bajo el cual Oracle Database se ejecuta es el responsable de eliminar la información sobre información antigua y las autorizaciones de un archivo antes de asignar a la base de datos.

La figura muestra los diferentes tipos de espacio que se dan en un data file


Página 26

ARQUITECTURA DEL LOG DE TRANSACCIONES (REDO LOG)

Es un buffer circular en la SGA que mantiene la información de los últimos cambios realizados

a la BD como resultado de transacciones o acciones internas, los cambios el buffer se

almacenan secuencialmente. Esta información es almacenada en las entradas Redo

conteniendo la información necesaria para reconstrucción (rehacer cambios hechos) a la base

de datos por instrucciones DML y DDL. Cada instancia de una base de datos Oracle tiene un

redo log asociados para proteger la base de datos en caso de fallo de instancia.

El redo log de una base de datos consiste en grupos de archivos de redo log y cada grupo está

integrado por un archivo de redo log y sus copias multiplexadas. Se dice que cada copia

idéntica es miembro de un grupo, y cada grupo es identificado por un número.

Se puede utilizar para reconstruir todos los cambios realizados en la base de datos, incluyendo

los segmentos de deshacer. Por lo tanto, el redo log también protege los datos de rollback.

Al recuperar la base de datos a partir de datos puesta al día, la base de datos lee los vectores

de cambio en los registros del redo log y aplica los cambios a los bloques correspondientes.

Como está formado el redo log Un registro está formado por un grupo de vectores de cambio, cada una de ellos es una descripción de un cambio realizado en un solo bloque en la base de datos. Por ejemplo, si se cambia un valor en una tabla de salarios de los empleados, se genera un registro de rehacer que contiene vectores de cambio que describen cambios en el bloque del segmento de datos para la tabla, el bloque del segmento de datos de deshacer, y la tabla de transacción de los segmentos de deshacer.

Archivos redo log activos e inactivos Oracle utiliza un solo archivo redo log a la vez para almacenar registros de rehacer. El archivo redo log que LGWR está escribiendo activamente se llama el archivo redo log actual.

Los archivos redo log que se requieren para la recuperación de instancias se llaman archivos

redo log activos y los archivos redo log que no son requeridos para la recuperación de

instancias se llaman archivos redo log inactivos.

Escritura en los archivos redo log (LGWR) El redo log de una base de datos consta de dos o más archivos redo log la base de datos necesita un mínimo de dos archivos para garantizar que se está siempre disponible para la escritura mientras que el otro está siendo archivado (Si la base de dato esta en modo ARCHIVELOG).


Página 27

LGWR escribe en los archivos redo log en forma circular. Cuando el archivo redo log actual se llena, LGWR comienza a escribir en el siguiente archivo redo log disponible. Cuando el último archivo redo log está lleno, LGWR regresa al primer archivo redo log y escribe en él, comenzando el ciclo otra vez.

Se escribe en los archivos online redo log de forma que puedan utilizarse en las operaciones de reconstrucción durante las recuperaciones de la BD. Las entradas redo son copiadas por la instancia de procesos desde el espacio de memoria del usuario al buffer de redo log en la SGA. Las entrada redo toman en forma contigua el espacio en el buffer. Los procesos de background LGWR escriben los redo log buffer en línea o grupos de archivos sobre disco.

Los archivos redo log están disponibles para su reutilización dependiendo si el archivo está activado o no, por defecto la base de datos se crea en modo NOARCHIVELOG.:

Si el archivo está desactivado (la base de datos está en modo de NOARCHIVELOG), un

archivo redo log lleno está disponible después de que los cambios registrados en él se

han escrito en los archivos de datos.

Si el archivo está habilitado (la base de datos está en modo ARCHIVELOG), un archivo

redo log lleno está disponible para LGWR después de que los cambios registrados en él

se han escrito en los archivos de datos y el archivo ha sido archivado.

La Figura ilustra la escritura circular del archivo redo log. Los números junto a cada línea indica la secuencia en la que LGWR escribe a cada archivo de redo log.


Página 28

La inicialización del parámetro LOG_BUFFER determina el tamaño en bytes de los buffers de

redologs. Por lo general, los grandes valores reducen el log de IO, en especial si las

transacciones son numerosas. El default es 4 veces el máximo del bloque de datos para el

Sistema Operativo.

Cambios de Log y números de secuencia Un cambio de Log es el punto en que la base de datos deja de escribir en un archivo redo log y

comienza a escribir a otro. Normalmente, un cambio de Log se produce cuando el archivo redo

log actual está completamente lleno y la escritura debe continuar en el archivo redo log

siguiente. Sin embargo, puede configurar los cambios de registro a ocurrir a intervalos

regulares, sin importar si el archivo redo log actual está completamente lleno. También puede

obligar a los cambios de registro de forma manual.

Oracle asigna a cada archivo redo log un número de secuencia de registro nuevo cada vez que

un cambio de registro se produce y LGWR comienza a escribir a la misma. Un archivo redo log

en que se realiza un ciclo de nuevo para su uso se le da el siguiente número disponible de

secuencia de registro, cada online redo log file se identifica por su número de secuencia de

registro.

Archivos redo log Archivados Los archivos redo log llenos se pueden archivar, la ejecución de la base de datos en modo

ARCHIVELOG y el proceso de archivado de archivos redo log online tiene dos ventajas:

Recuperación: La copia de seguridad de la base de datos y los archivos redo log

archivados y online garantizan la recuperación de todas las transacciones validadas.

Copia de seguridad: Se puede realizar mientras la base de datos está abierta

El proceso ARCn realiza el archivado automáticamente, para realizar el archivado

manualmente se utilizan sentencias SQL.

Si el archivado se realiza correctamente:

Se registra una entrada en el archivo de control.

Registros: Nombre de archive log, numero de secuencia de log y SCN (Numero de

cambio del sistema) inferior y superior.

Los archivos redo log online llenos no se pueden reutilizar hasta que:

Haya tenido lugar un punto de control.

ARCn ha archivado el archivo.


Página 29

Multiplexación de Archivos Redo Log

Para proteger contra un fallo que envuelva al redo log, Oracle Database permite un redo log multiplexados, lo que significa que dos o más copias idénticas de los redo log se puede mantener de forma automática en lugares separados. Para el mayor beneficio, estos lugares deben estar en discos separados. Incluso si todas las copias del redo log están en el mismo disco, sin embargo, la redundancia puede ayudar a proteger contra errores de E / S, corrupción de archivos, y así sucesivamente. Cuando los archivos redo log están multiplexados, al mismo tiempo LGWR escribe la información del redo log a varios archivos redo log idénticos, eliminando así un punto único de fallo del redo log.

La Multiplexación se lleva a cabo mediante la creación de grupos de archivos de redo log. Un grupo se compone de un archivo redo log y sus copias multiplexadas. Cada copia idéntica se dice que es un miembro del grupo. Cada grupo de redo log se define por un número, como por ejemplo el grupo 1, grupo 2, y así sucesivamente.

Multiplexado redo log files:

En la figura, A_LOG1 y B_LOG1 son miembros del Grupo 1, A_LOG2 y B_LOG2 son miembros del Grupo 2, y así sucesivamente. Cada miembro de un grupo debe tener el mismo tamaño.

Cada miembro de un grupo de archivos de registro se activa al mismo tiempo, es decir, al mismo tiempo escrita por LGWR-según lo indicado por los números de secuencia idéntico de registro asignado por LGWR. En la figura LGWR escribe al mismo tiempo a ambos A_LOG1 y B_LOG1, y así sucesivamente. LGWR no escribe al mismo tiempo a los miembros de diferentes grupos (por ejemplo, para A_LOG1 y B_LOG2).

http://translate.googleusercontent.com/translate_c?hl=es&ie=UTF8&prev=_t&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://download.oracle.com/docs/cd/E11882_01/server.112/e25494/onlineredo002.htm&usg=ALkJrhjiIhfFMfcsDWn35dVZpuzgSq87KA#i1006259

http://translate.googleusercontent.com/translate_c?hl=es&ie=UTF8&prev=_t&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://download.oracle.com/docs/cd/E11882_01/server.112/e25494/onlineredo002.htm&usg=ALkJrhjiIhfFMfcsDWn35dVZpuzgSq87KA#i1006259


Página 30

Respuesta a un fallo de Redo Log Cada vez que LGWR no puede escribir en un miembro de un grupo, la base de datos de marca a ese miembro como INVALIDO y escribe un mensaje de error en el archivo de rastreo LGWR y en el registro de alerta de la base de datos para indicar el problema con los archivos inaccesibles. La reacción específica de LGWR cuando un miembro redo log no está disponible depende de la razón de la falta de disponibilidad, que se resumen en la tabla que sigue:

Condición LGWR Acción

LGWR Puede escribir exitosamente en al menos un miembro de un grupo

La escritura procede de forma normal. LGWR escribe a los miembros disponibles del grupo y hace caso omiso de los miembros que no están disponibles.

LGWR no puede acceder al siguiente grupo en un cambio de log debido a que el grupo debe ser archivado

Operación de la base de datos se detiene temporalmente hasta que el grupo esté disponible o hasta que el grupo está archivado.

Todos los miembros del grupo son inaccesibles para los próximos LGWR en un cambio de log debido a la falta de medios

Oracle Database devuelve un error, y la instancia de base de datos se apaga. En este caso, puede que tenga que realizar la recuperación de los medios de comunicación sobre la base de datos de la pérdida de un archivo redo log.

Todos los miembros de un grupo de repente se vuelven inaccesibles para LGWR mientras está escribiendo

Oracle database devuelve un error y la instancia de base de datos se apaga inmediatamente. En este caso, puede que tenga que realizar la recuperación de los medios de comunicación. Si los medios de comunicación que contiene el registro no se pierde realmente - por ejemplo, si la unidad para el registro se convirtió inadvertidamente - la recuperación de los medios de comunicación puede no ser necesaria. En este caso, usted sólo tiene que acudir de nuevo la unidad y deje que la base de datos realizar la recuperación automática de ejemplo.

Configuraciones legales e ilegales En la mayoría de los casos, los redo log multiplexados deben ser simétricos: todos los grupos de redo log deben tener el mismo número de miembros. Sin embargo, la base de datos no


Página 31

requiere que los redo log multiplexados sean simétricos. Por ejemplo, un grupo puede tener un solo miembro, y otros grupos pueden tener dos miembros. Esta configuración protege contra fallas de discos que afectan temporalmente algunos de los miembros de redo log, pero deja a otros intactos.

El único requisito para una instancia redo log es que esta tenga por lo menos dos grupos, las

siguientes son muestras legales e ilegales de configuraciones de redo log multiplexados:

Colocación de miembros redo log en discos diferentes Cuando se crean redo log multiplexados, los miembros de un grupo se graban en diferentes discos físicos. Si un disco falla, sólo un miembro de un grupo no está disponible para LGWR y otros miembros siguen siendo accesibles a LGWR, por lo que la instancia puede seguir funcionando.


Página 32

Planificación del tamaño del archivo redo log Los archivos redo log deben ser de tamaño tal que un grupo lleno pueda ser archivado en una sola unidad de medios de almacenamiento en línea (como una cinta o disco), con la menor cantidad de espacio en el medio que no se utiliza.

Todos los miembros del mismo grupo multiplexado de redo log deben ser del mismo tamaño. Miembros de diferentes grupos pueden tener diferentes tamaños. Sin embargo, no hay ninguna ventaja en mayor o menor tamaño de archivo entre los grupos.

Planificación del tamaño de bloque de los archivo redo log A diferencia del tamaño del bloque de base de datos, que puede estar entre 2K y 32K, los archivos redo log tienen por defecto un tamaño de bloque que es igual al tamaño del sector físico del disco. Históricamente, esto ha sido típicamente 512 bytes (512B).

Algunas nuevas unidades de alta capacidad de disco ofrecen 4K bytes (4K) de tamaños de sector, tanto para aumento de capacidad de ECC y la eficiencia. La mayoría de las plataformas de Oracle database son capaces de detectar este tamaño más grande del sector. La base de datos crea automáticamente archivos redo log con un tamaño de bloque de 4K en dichos discos.

Sin embargo, con un tamaño de bloque de 4k, hay un mayor desperdicio de rehacer. De hecho, la cantidad de desperdicio de rehacer en bloques de 4K en comparación con los bloques 512B es significativo. Usted puede determinar la cantidad de desperdicio de rehacer al ver las

estadísticas almacenadas en el V$SESSTAT y V$SYSSTAT puntos de vista.

Nombre de SQL> SELECT, el valor de v $ sysstat DONDE 'despilfarro rehacer' = nombre;

Selección del número de archivos redo log La mejor manera de determinar el número apropiado de los archivos redo log de una instancia de base de datos es poner a prueba distintas configuraciones. La configuración óptima tiene la menor cantidad de grupos posible, sin obstaculizar al LGWR de escribir la información de redo log.

En algunos casos, una instancia de base de datos puede requerir sólo dos grupos. En otras

situaciones, una instancia de base de datos puede requerir grupos adicionales para garantizar

que un grupo de reciclado está siempre disponible para LGWR.


Página 33

ARQUITECTURA DE OBJETOS

Esquemas Un esquema de base de datos es un contenedor lógico de estructuras de datos, llamados objetos de esquema. Ejemplos de objetos de esquema son las tablas e índices. Los objetos de esquema son creados y manipulados con SQL.

Un usuario de base de datos tiene una contraseña y privilegios diferentes bases de datos. Cada usuario posee un solo esquema, que tiene el mismo nombre que el usuario. El esquema contiene los datos para el usuario propietario del esquema. Por ejemplo el usuario “hr” posee su propio esquema llamado “hr”, el cual contiene distintos objetos de base de datos. Y cada objeto dentro de un esquema posee un nombre en particular, supongamos la tabla “employees” del esquema hr, esta se identifica por “hr.employees”. Un ejemplo gráfico:

Oracle Database almacena un objeto de esquema lógico dentro de un espacio de tablas. No hay ninguna relación entre los esquemas y espacios de tablas: un espacio de tabla puede contener objetos de diferentes esquemas, y los objetos de un esquema puede estar contenida en los espacios de tablas diferentes. Los datos de cada objeto son físicamente contenidos en uno o más archivos de datos.

Tablas Las tablas son la unidad básica de almacenamiento de datos en una base de datos Oracle. Los

datos se almacenan en filas y columnas. Se define una tabla con un nombre (como empleados)

y el conjunto de columnas. Cada columna recibe un nombre que la identifica (como

EMPLOYEE_ID, apellidos, y job_id), un tipo de datos (por ejemplo, VARCHAR2, DATE, o

NUMBER), y una anchura.

El ancho puede ser predeterminado por el tipo de datos, como fecha de entrada. Si las columnas son del tipo de datos NUMBER, definir la precisión y la escala en lugar de ancho. Una fila es una colección de información de la columna que corresponde a un único registro.


Página 34

Puede especificar las reglas para cada columna de una tabla. Estas reglas se denominan

restricciones de integridad. Un ejemplo es la restricción de integridad NOT NULL. Esta

limitación obliga a la columna que contiene un valor en cada fila.

También puede especificar columnas de la tabla para que los datos sean encriptados antes de

ser almacenados en el archivo de datos. La encriptación evita que los usuarios de control de

acceso a bases de eludir mecanismos a través de mirar dentro de archivos de datos

directamente con las herramientas del sistema operativo.

Después de crear una tabla, inserte filas de datos mediante sentencias SQL. Los datos de la

tabla pueden ser consultados, eliminados o actualizados utilizando sentencias SQL.

Cuando se crea una tabla, Oracle asigna automáticamente un segmento de datos en un

espacio de tablas para almacenar los datos futuros de la tabla. Usted puede controlar la

asignación y utilización del espacio para el segmento de datos de una tabla de la siguiente

manera:

Controlando la cantidad de espacio asignado al segmento de datos mediante el

establecimiento de los parámetros de almacenamiento para el segmento de datos.

Controlando el uso del espacio libre en los bloques de datos que constituyen

extensiones del segmento de datos es mediante el establecimiento de los parámetros

PCTFREE y PCTUSED para el segmento de datos.

Oracle almacena los datos de una tabla agrupada en el segmento de datos creada para el

grupo, en lugar de en un segmento de datos en un espacio de tablas.

Los parámetros de almacenamiento no se pueden especificar cuando una tabla agrupada se

crea o se altera. Los parámetros de almacenamiento fijada para el clúster siempre controlar el

almacenamiento de todas las tablas en el clúster.

Segmento de una tabla de datos se crea en cualquier espacio de tabla por defecto el

propietario de la tabla o en un espacio de tablas específicamente en la sentencia CREATE

TABLE.

Cuando una tabla tiene más de 255 columnas, filas que tienen datos después de la columna de

la 255a es probable que se encadenaran en el mismo bloque. Esto se llama intra-bloque de

encadenamiento. Una fila de piezas encadenado se encadenan con el ROWID de las piezas.

Con el encadenamiento intra-bloque, los usuarios reciben todos los datos en el mismo bloque.

Si la fila se ajusta en el bloque, los usuarios no ven un efecto en el rendimiento de E / S, porque

no hay operaciones adicionales de E / S necesarias para recuperar el resto de la fila. Cada pieza

de la fila, encadenados o desencadenados, contiene un encabezado de fila y los datos para

todas o algunas de las columnas de la fila. Columnas individuales también pueden abarcar

piezas de fila y, en consecuencia, los bloques de datos.


Página 35

Orden de las columnas

El orden de las columnas es el mismo para todas las filas de una tabla dada. Las columnas se suelen almacenar en el orden en que fueron incluidas en la sentencia CREATE TABLE, pero esto no está garantizado. Por ejemplo, si una tabla tiene una columna de tipo de datos LONG, Oracle almacena siempre la última columna. Además, si una tabla se altera de modo que una nueva columna se añade, a continuación, la nueva columna se convierte en la última columna almacenada.

En general, trate de colocar las columnas que suelen contener valores nulos pasado, así que las filas ocupan menos espacio. Tenga en cuenta, sin embargo, que si la tabla que se incluye la creación de una columna LONG así, entonces los beneficios de la colocación de columnas con frecuencia nula últimas columnas lost.ll, Oracle se ot incluso almacenar la longitud de la columna.

Tabla de Compresión

Característica de compresión de tablas de Oracle comprime los datos al eliminar los valores duplicados en un bloque de base de datos. Los datos comprimidos almacenados en un bloque de base de datos (también conocida como página de disco) son autosuficientes. Es decir, toda la información necesaria para volver a crear los datos sin comprimir en un bloque está disponible dentro de ese bloque. Los valores duplicados en todas las filas y columnas en un bloque se almacenan una vez al principio del bloque, en lo que se llama una tabla de símbolos para ese bloque. Todas las apariciones de estos valores se sustituyen por una breve referencia a la tabla de símbolos.

Con la excepción de una tabla de símbolos al principio, base de datos de bloques comprimidos se parecen mucho a los bloques de base de datos regular. Todas las funciones de base de datos y funciones que trabajan en los bloques de base de datos de regular también el trabajo en bloques de base de datos comprimida.

Objetos de base de datos que puede ser comprimido incluir tablas y vistas materializadas. Para las tablas de particiones, puede elegir comprimir particiones algunos o todos.

Los atributos de compresión puede ser declarada por un espacio de tabla, una tabla o una partición de una tabla. Si se declara en el nivel de tabla, a continuación, todas las tablas creadas en el espacio de tablas que se comprimen de forma predeterminada. Puede modificar el atributo de compresión de una tabla (o una partición o espacio de tabla), y el cambio sólo se aplica a los nuevos datos van en esa tabla. Como resultado, una sola tabla o partición puede contener algunos bloques comprimidos y algunos bloques de regular. Esto garantiza que el tamaño de los datos no se incrementará como resultado de la compresión, en los casos en que la compresión podría aumentar el tamaño de un bloque, no se aplica a ese bloque.

La compresión se produce mientras los datos se insertan a granel o carga a granel. Estas operaciones incluyen:

Camino directo SQL * Loader Crear tabla y como las instrucciones SELECT Inserte paralelo (o inserte en serie con un toque APPEND) declaraciones Los datos existentes en la base de datos también se pueden comprimir para que pase

en forma comprimida a través de ALTER TABLE y las declaraciones de MOVE. Esta operación tiene un bloqueo exclusivo sobre la mesa, y por lo tanto evita que las actualizaciones y las cargas hasta que se complete. Si esto no es aceptable, entonces la


Página 36

utilidad redefinición en línea de Oracle (DBMS_REDEFINITIONPL / SQL) se puede utilizar.

La compresión de datos funciona para todos los tipos de datos con excepción de todas las variantes de LOB y tipos de datos derivados de LOB, como VARRAYs almacenados fuera de la línea o el tipo de datos XML almacenados en un CLOB.

Compresión de la tabla se realiza como parte de la carga de datos de forma masiva en la base de datos. La sobrecarga asociada con la compresión es más visible en ese momento. Este es el principal compromiso que hay que tener en cuenta al considerar la compresión.

Valores nulos

Un valor nulo es la ausencia de un valor en una columna de una fila. Nulos indican que faltan datos, son desconocidos o inaplicables. Un valor nulo no debe ser usado para implicar cualquier otro valor, tales como cero. Una columna permite nulos a menos que una restricción de integridad o NOT NULL PRIMARY KEY se ha definido para la columna, en cuyo caso no se puede insertar fila sin un valor para esa columna.

Los nulos se almacenan en la base de datos si se caen entre las columnas con valores de datos. En estos casos se requiere 1 byte para almacenar la longitud de la columna (cero).

Valores por defecto

Se puede asignar un valor predeterminado a una columna de una tabla de modo que cuando una nueva fila se inserta y un valor para la columna se omite o palabra clave DEFAULT suministrada es, un valor por defecto se suministra de forma automática. Los valores por defecto de columna trabajar como si de una instrucción INSERT en realidad especifica el valor predeterminado.

El tipo de datos por defecto literal o una expresión debe coincidir o ser convertible al tipo de datos de la columna.

Si el valor predeterminado no está explícitamente definido para una columna, el valor por defecto para la columna de forma implícita a NULL.

Tablas con particiones

Tablas con particiones permiten que sus datos sean desglosados en trozos más pequeños y manejables llamadas particiones, o incluso subparticiones. Los índices pueden dividirse de manera similar. Cada partición puede considerarse en forma individual, y puede operar independientemente de las otras particiones, lo que proporciona una estructura que puede ser mejor sintonía para la disponibilidad y el rendimiento.

Tablas anidadas

Puede crear una tabla con una columna cuyo tipo de datos es otra tabla. Es decir, las tablas se pueden anidar dentro de otras tablas como valores de una columna. El servidor de base de datos Oracle almacena los datos de tablas anidadas fuera de la línea de las filas de la tabla principal, utilizando una tabla de tienda que está asociado con la columna de tabla anidada. La


Página 37

fila principal contiene un conjunto de valores identificador único asociado a una instancia de la tabla anidada.

Tablas Temporales

Además de las tablas permanentes, Oracle puede crear tablas temporales para mantener privado de sesión de datos que existe sólo para la duración de una transacción o sesión.

La sentencia CREATE GLOBAL TEMPORARY TABLE crea una tabla temporal que puede ser de transacciones específicas o particulares de la sesión. Para transacciones específicas tablas temporales, existen datos para la duración de la transacción. Para la sesión de tablas específicas temporales, existen datos para la duración de la sesión. Datos en una tabla temporal es privado a la sesión. En cada sesión sólo se puede ver y modificar sus propios datos.

Cerraduras DML no se adquieren en los datos de las tablas temporales. La instrucción de bloqueo no tiene ningún efecto en una tabla temporal, ya que cada sesión tiene sus propios datos privados.

Una declaración TRUNCATE emitida en una sesión específica de la tabla temporal trunca los datos de su propia sesión. No trunca los datos de otras sesiones que están utilizando la misma tabla.

Las tablas temporales utilizar segmentos temporales. A diferencia de las tablas permanentes, las tablas temporales y sus índices no asignar automáticamente un segmento cuando se crean.

En cambio, los segmentos son asignados cuando la primera inserción (o CREATE TABLE AS SELECT) se lleva a cabo. Esto significa que si un SELECT, UPDATE, o DELETE se realiza antes de la primera inserción, a continuación, la mesa parece estar vacío.

Puede llevar a cabo las instrucciones de DDL (ALTER TABLE, DROP TABLE, CREATE INDEX, y así sucesivamente) en una tabla temporal sólo cuando no hay ninguna sesión actualmente ligado a ella. Una sesión se enlaza a una tabla temporal cuando se realiza un INSERT en él. La sesión se desatado por un TRUNCATE, a la terminación del periodo de sesiones, o por hacer una confirmación o retrotracción de una transacción específica de la tabla temporal.

Segmentos temporales son liberados al final de la transacción para transacciones

específicas y al final de la sesión para la sesión específica.

Tablas externas

Las tablas externas acceso a los datos de fuentes externas como si se tratara de una

tabla en la base de datos.

Puede conectarse a la base de datos y crear los metadatos de la tabla externa

utilizando DDL.


Página 38

El DDL para una tabla externa consta de dos partes: una parte que describe los tipos de

columna de Oracle, y otra parte (los parámetros de acceso) que describe la asignación

de los datos externos a las columnas de datos de Oracle.

Una tabla externa no describe todos los datos que se almacena en la base de datos.

Tampoco describen cómo se almacenan los datos en la fuente externa. En su lugar, se

describe cómo la capa de la tabla externa tiene que presentar los datos al servidor. Es

la responsabilidad del controlador de acceso y la capa de tabla externa para hacer las

transformaciones necesarias requeridas en los datos en el archivo de datos para que

coincida con la definición de la tabla externa.

Las tablas externas son de sólo lectura, por lo tanto, no hay operaciones de DML

posibles, y no se pueden crear índices en ellos.

Al crear una tabla externa, debe especificar su tipo. Cada tipo de tabla externa tiene su

propio controlador de acceso que proporciona los parámetros de acceso único a ese

tipo de tabla externa. El controlador de acceso asegura que los datos de la fuente de

los datos se procesan para que coincida con la definición de la tabla externa.

En el contexto de las tablas externas, carga de datos se refiere al acto de leer datos de

una tabla externa y la carga en una tabla en la base de datos. Descarga de datos se

refiere al acto de lectura de los datos de una tabla en la base de datos e insertarlos en

una tabla externa.

El tipo por defecto para las tablas externas es ORACLE_LOADER, que le permite leer

datos de una tabla de una tabla externa y la carga en una base de datos. Oracle

también ofrece el tipo ORACLE_DATAPUMP, que le permite descargar datos (es decir,

leer datos de una tabla en la base de datos y la inserta en una tabla externa) y vuelva a

cargarlo en una base de datos Oracle.

La definición de una tabla externa se mantiene aparte de la descripción de los datos

del origen de datos. Esto significa que:

El archivo de origen puede contener campos más o menos hay columnas de la tabla

externa

Los tipos de datos para los campos del origen de datos puede ser diferente de las

columnas de la tabla externa

El principal uso de las tablas externas es usarlos como origen de la fila para cargar

datos en una tabla real en la base de datos. Después de crear una tabla externa, a

continuación, puede utilizar un CREATE TABLE AS SELECT o INSERT INTO ... AS SELECT,

utilizando la tabla externa como la fuente de la cláusula SELECT.

No se puede insertar datos en tablas externas o actualizar los registros en ellos, las

tablas externas son de sólo lectura.


Página 39

Vistas

Una vista es una estructura de datos de Oracle se define a través de una sentencia SQL.

La sentencia SQL se guarda en la base de datos. Cuando se utiliza una vista en una

consulta, la consulta almacenada se ejecuta y los datos de la tabla base se devuelve al

usuario. Las vistas no contienen datos, sino que representan formas de ver los datos

de la tabla base en la forma en la consulta específica.

Puede utilizar una vista para varios propósitos:

Para simplificar el acceso a los datos almacenados en varias tablas.

Para implementar la seguridad específica para los datos en una tabla.

Ocultar la complejidad de datos

Simplificar las declaraciones para el usuario

Presentar los datos en una perspectiva diferente de la de la tabla base

Aislar las solicitudes de cambios en las definiciones de las tablas de la base

Expresar una consulta que no puede expresarse sin usar una vista

Guardar consultas complejas

Oracle almacena la definición de una vista en el diccionario de datos como el texto de la consulta que define la vista. Al hacer referencia a una vista en una sentencia SQL, Oracle:

1. Combina la declaración que haga referencia a la vista con la consulta que define la vista

2. Analiza la instrucción se fusionaron en un área compartida de SQL

3. Ejecuta la sentencia

Oracle analiza una declaración que hace referencia a una vista en una nueva área de

SQL compartido sólo si no existentes área compartida de SQL contiene una declaración

similar. Por lo tanto, obtener el beneficio del uso reducido de la memoria compartida

asociado con SQL al utilizar vistas.

Dependencias y vistas

Debido a que una vista es definida por una consulta que los objetos de otras referencias (las tablas, vistas materializadas, u otras vistas) una vista depende de los objetos de referencia. Oracle gestiona automáticamente las dependencias de vistas. Por ejemplo, si se elimina una tabla base de una vista y luego se vuelve a crear, Oracle determina si la nueva tabla base es aceptable para la definición actual de la vista.


Página 40

Vista actualizable de unión (Updatable Join Views)

Se define como una vista que tiene más de una tabla o vista en la cláusula FROM (una unión), y que no utiliza ninguna de estas cláusulas: DISTINCT, aggregation, GROUP BY, START WITH, CONNECT BY, ROWNUM, y operaciones de conjuntos (UNION ALL, INTERSECT, y así sucesivamente).

Una vista actualizable de unión es una vista de que involucra a dos o más tablas base o

vistas, donde UPDATE, INSERT y DELETE están permitidas.

ALL_UPDATABLE_COLUMNS, DBA_UPDATABLE_COLUMNS y

USER_UPDATABLE_COLUMNS contienen información que indica cuál de las columnas

de la vista se pueden actualizar. Con el fin de ser intrínsecamente actualizable, un

punto de vista no puede contener cualquiera de las siguientes construcciones:

Un conjunto de operadores

Un operador DISTINCT

Una función de agregado o analítica

Las casuals GROUP BY, ORDER BY, CONNECT BY, o START WITH

Una colección en una lista SELECT

Una subconsulta en una lista SELECT

Join (con algunas excepciones)

Vistas que no son actualizables se pueden modificar mediante INSTEAD OF triggers.

Vistas de objetos

En bases de datos objeto-relacional, una vista de objetos le permite recuperar,

actualizar, insertar y eliminar datos relacionales como si se han almacenado como un

tipo de objeto. También se pueden definir puntos de vista con columnas que son tipos

de datos de objetos, tales como objetos, REFs, y colecciones (tablas anidadas y

VARRAYs).

Vistas en línea

Una vista en línea no es un objeto de esquema. Se trata de una subconsulta con un

alias (nombre de correlación) que puede utilizar como una vista dentro de una

sentencia SQL.

Vistas materializadas

Las vistas materializadas son objetos de esquema que se puede utilizar para resumir,

calcular, reproducir y distribuir los datos. Son adecuados en los entornos informáticos

distintos, tales como almacenamiento de datos, soporte de decisiones, y la

computación distribuida o móvil:


Página 41

En los almacenes de datos, las vistas materializadas se utilizan para calcular y

almacenar datos agregados, como sumas y promedios. Las vistas materializadas en

estos ambientes son por lo general se refiere como resúmenes ya que almacenan los

datos resumidos. También se puede utilizar para calcular une con o sin agregados.

El optimizador puede utilizar vistas materializadas para mejorar el rendimiento de las

consultas que permiten identificar automáticamente cuando una vista materializada

puede y debe ser utilizada para satisfacer una solicitud. El optimizador de

transparencia vuelve a escribir la solicitud de uso de la vista materializada. Las

consultas se dirigen a la vista materializada y no a las tablas de detalle de base o

puntos de vista.

En los entornos distribuidos, vistas materializadas se utiliza para replicar datos en sitios

distribuidos y sincronizar actualizaciones hechas en varios lugares con el conflicto

métodos de resolución. Las vistas materializadas como réplicas de proporcionar acceso

local a los datos que de otra manera tienen que ser accesible desde sitios remotos.

En los entornos de computación móvil, las vistas materializadas se utilizan para

descargar un subconjunto de datos desde los servidores centrales a los clientes

móviles, con actualizaciones periódicas de los servidores centrales y la propagación de

cambios por los clientes a los servidores centrales.

Las vistas materializadas son similares a los índices de varias maneras:

Se consumen espacio de almacenamiento.

Se debe actualizarse cuando los datos en sus tablas maestras cambios.

Mejoran el rendimiento de ejecución de SQL cuando se utilizan para la consulta vuelve

a escribir.

Su existencia es transparente para las aplicaciones SQL y los usuarios.

A diferencia de los índices, las vistas materializadas se pueden acceder directamente a

través de una instrucción SELECT.

Dependiendo del tipo de actualización que se requieren, también se puede acceder

directamente en una instrucción INSERT, UPDATE, o DELETE.

Una vista materializada puede ser dividida. Se puede definir una vista materializada en

una tabla con particiones e índices de una o más de la vista materializada.

Índices

Los índices son estructuras opcionales asociadas con tablas y clúster. Se pueden crear índices en una o más columnas de una tabla para acelerar la ejecución de sentencias SQL sobre la tabla Al igual que el índice de un libro le ayuda a encontrar la información más rápido que si no hay índice.


Página 42

Un índice de Oracle proporciona una ruta de acceso más rápido a datos de la tabla. Los índices son el principal medio de la reducción de E/S de disco cuando se utilizan correctamente.

Puede crear varios índices para una tabla, siempre y cuando la combinación de las columnas es diferente para cada índice. Puede crear más de un índice con las mismas columnas si se especifica claramente diferentes combinaciones de las columnas.

Oracle ofrece varios esquemas de indexación, que proporcionan una funcionalidad complementaria sobre el rendimiento:

Índices árboles B

índices clúster árboles B

índices clúster hash

índices reverse key

índices bitmap

índices bitmap join

Oracle también proporciona soporte para los índices basados en funciones y los índices de dominio específico para una aplicación o un cartucho.

La ausencia o presencia de un índice no requiere un cambio en la redacción de cualquier

SQL. Un índice es simplemente una vía de acceso rápido a los datos. Sólo afecta a la velocidad de ejecución. Dado un valor de datos que ha indexado, el índice apunta directamente a la ubicación de las filas que contiene ese valor.

Los índices son lógica y físicamente independiente de los datos en la tabla asociada.

Puede crear o quitar un índice en cualquier momento sin afectar a las tablas de base u otros índices. Si se coloca un índice, todas las aplicaciones siguen funcionando. Sin embargo, el acceso de los datos previamente indexados puede ser más lento. Índices, como estructuras independientes, requieren espacio de almacenamiento.

Oracle mantiene de forma automática y utiliza los índices después de su creación. Automáticamente refleja los cambios a los datos, tales como la adición de nuevas filas, actualizar filas, o eliminación de filas, en todos los índices relevantes con ninguna acción adicional por los usuarios.

Rendimiento de recuperación de datos indexados se mantiene casi constante, incluso cuando se agregan nuevas filas. Sin embargo, la presencia de muchos índices en una tabla de una disminución del rendimiento de las actualizaciones, eliminaciones e inserciones, ya que Oracle también debe actualizar los índices asociados a la tabla.

El optimizador puede utilizar un índice existente para construir otro índice. Esto se traduce en un índice mucho más rápido de construir.


Página 43

Índices únicos y no único

Los índices pueden ser únicos o no únicos. Índices únicos garantizan que no hay dos filas de una tabla con valores duplicados en la columna de clave (o columnas). Índices no únicos no imponen esta restricción en los valores de columna.

Oracle recomienda que los índices únicos se crean explícitamente mediante CREATE

UNIQUE INDEX. Crear índices únicos a través de una restricción de clave principal o

única no garantiza que cree un nuevo índice, y el índice que crean no se garantiza que

sea un índice único.

Índices compuestos

Un índice compuesto (también llamado índices concatenados) es un índice que se crea

en varias columnas en una tabla. Las columnas de un índice compuesto pueden

aparecer en cualquier orden y no necesita ser adyacentes en la tabla.

Los índices compuestos pueden acelerar la recuperación de datos para las

instrucciones SELECT en la que la cláusula donde las referencias a todos o la parte

principal de las columnas en el índice compuesto. Por lo tanto, el orden de las

columnas utilizadas en la definición es importante. Generalmente, las columnas más

accesible o más selectivas primero.

No más de 32 columnas pueden formar un índice compuesto regular. Para un índice

bitmap, le número máximo de columnas es 30. Un valor clave no puede exceder

aproximadamente la mitad (menos algunos gastos generales) del espacio de los datos

disponibles en un bloque de datos.

Índices y claves

Aunque los términos se usan indistintamente, los índices y las claves son diferentes.

Los índices son estructuras realmente se almacena en la base de datos, que los

usuarios crear, modificar y quitar mediante sentencias SQL. Se crea un índice para

proporcionar una ruta de acceso rápido a datos de la tabla. Las claves son

estrictamente un concepto lógico. Las claves corresponden a otra de las características

de Oracle llamada restricciones de integridad, que aplica las reglas de negocio de una

base de datos.

Debido a que Oracle utiliza índices para imponer algunas restricciones de integridad, la

clave y el índice de términos a menudo se utilizan indistintamente. Sin embargo, no

confundir unos con otros.


Página 44

Índices y valores nulos

Los valores NULL en los índices se consideran distintas, salvo cuando todos los valores

no NULL en dos o más filas de un índice son idénticos, en cuyo caso las filas se

consideran iguales. Por lo tanto, los índices UNIQUE evitar las filas que contienen

valores NULL de ser tratados como iguales. Esto no se aplica si no hay valores no NULL

en otras palabras, si las filas son totalmente nulas.

Oracle no tiene filas de índice de la tabla en la que todas las columnas de clave NULL,

excepto en el caso de los índices bitmap o cuando la clave del clúster valor de la

columna es NULL.

Índices basados en funciones

Se pueden crear índices en las funciones y las expresiones que implican una o más

columnas en la tabla de la indexación. Un índice basado en las funciones calcula el

valor de la función o la expresión y la almacena en el índice. Usted puede crear un

índice basado en las funciones, ya sea como un árbol-B o un índice de mapa de bits.

Proporcionan un mecanismo eficiente para la evaluación de las declaraciones que

contienen las funciones de sus cláusulas WHERE. El valor de la expresión se calcula y se

almacena en el índice. Al procesar las instrucciones INSERT y UPDATE, sin embargo,

Oracle todavía debe evaluar la función de procesar la sentencia.

Usted debe obtener estadísticas sobre los índices basados en funciones para el optimizador. De lo contrario, los índices no se pueden utilizar para procesar sentencias SQL.

El optimizador puede utilizar un índice de exploración de distancia en un índice basado en las funciones para las consultas con expresiones en la cláusula WHERE.

Basado en función de los índices, dependen de la función que se utiliza en la expresión que define el índice. Si la función es una función PL / SQL o una función del paquete, el índice está deshabilitado por cualquier cambio en la especificación de la función.

Para crear un índice basado en las funciones, el usuario debe conceder CREATE INDEX o CREATE ANY INDEX.

Para utilizar un índice basado en las funciones:

La tabla debe ser analizado después de que el índice se crea. La consulta se debe garantizar que no necesita ningún valor NULL de la

expresión de índice, ya que los valores NULL no se almacenan en los índices.

Cómo se almacenan los índices

Cuando se crea un índice, Oracle asigna automáticamente un segmento de índice para almacenar los datos del índice en un tablespace. Usted puede controlar la asignación


Página 45

de espacio para el segmento de un índice y el uso de este espacio reservado de la siguiente manera:

Establezca los parámetros de almacenamiento para el segmento de índice para

controlar la asignación de extensiones del segmento de índice.

Establecer el parámetro PCTFREE para el segmento de índice para controlar el espacio

libre en los bloques de datos que constituyen el segmento de extensión del índice.

El tablespace de segmento de un índice o es el dueño de tablas por defecto o un tablespace específicamente en la instrucción CREATE INDEX. Usted no tiene que poner un índice en el espacio de tablas igual que su tabla asociada. Además, puede mejorar el rendimiento de las consultas que utilizan un índice mediante el almacenamiento de un índice y la tabla en diferentes espacios de tablas se encuentra en las unidades de disco diferente, ya que Oracle puede recuperar los datos de índice y la tabla en paralelo.

Formato de los bloques de índice (Index Blocks)

El espacio disponible para los datos índices el bloque de datos menos el encabezado del bloque, el rowid y un byte de tamaño por cada valor indexado.

Cuando se crea un índice, Oracle recupera y ordena las columnas para que se indexe y almacena la ROWID, junto con el valor del índice para cada fila. A continuación, Oracle carga el índice de abajo hacia arriba.

Estructura interna de los índices

Oracle utiliza los árboles B para almacenar los índices y acelerar el acceso de datos. Sin índices, que tiene que hacer una búsqueda secuencial de los datos para encontrar un valor. Para las n filas, el número medio de filas buscado es n / 2. Esto no se escala muy bien cómo aumentar el volumen de datos.

Considere la posibilidad de una lista ordenada de los valores divididos en bloques de

un amplio rango (los bloques de la hoja). Los criterios de valoración de las gamas, junto

con punteros a los bloques se pueden almacenar en un árbol de búsqueda y un valor

de log (n) para las entradas de n que se puede encontrar. Este es el principio básico

detrás de los índices de Oracle.


Página 46

Los bloques superiores (branch blocks) de un índice B-tree contienen los datos del

índice que apunta a los bloques de índice de nivel inferior. Los bloques de nivel más

bajo índice (leaf blocks) contienen todos los valores de los datos indexados y una

ROWID correspondiente que se utiliza para localizar la fila actual. Los bloques de la

hoja son doblemente enlazadas. Los índices en columnas que contienen datos de

caracteres se basan en los valores binarios de los personajes en el juego de caracteres

de base de datos.

Para un índice único, un ROWID existe para cada valor de datos. Para un índice no

único, el ROWID se incluye en la clave de forma ordenada, de modo que los índices no

únicos se ordenan por la clave del índice y ROWID. Los valores clave que contiene

todos los valores nulos no son indexados, a excepción de los índices clúster. Dos filas

se contienen todos los valores nulos, sin violar un índice único.

Propiedades del índice

Los dos tipos de bloques:

Branch blocks para la búsqueda

Leaf blocks que almacenan los valores


Página 47

Branch blocks. Almacenan lo siguiente:

El prefijo clave mínimo necesario para tomar una decisión entre dos ramas claves

El puntero al bloque infantil que contiene la clave

Si los bloques tienen las llaves n entonces tienen n +1 punteros. El número de claves y

punteros se ve limitada por el tamaño del bloque.

Leaf blocks. Todos los loeaf blocks están a la misma profundidad del bloqueo de la

rama de la raíz, almacenan lo siguiente:

El valor completo de clave para cada fila ROWIDs de las filas de la tabla

Todos los pares de claves y ROWID están vinculados a sus hermanos a la izquierda y la

derecha. Están ordenados por (clave, ROWID).

La estructura de árbol B tiene las siguientes ventajas:

Todos los bloques de las hojas del árbol se encuentran en la misma profundidad, por lo

que la recuperación de cualquier registro de cualquier parte del índice tiene

aproximadamente la misma cantidad de tiempo.

Los índices de árbol B mantienen el equilibrio automáticamente.

Todos los bloques del árbol B son de tres cuartos de su capacidad en promedio.

Árboles B proporcionan un rendimiento excelente para la recuperación de una amplia

gama de consultas, incluyendo coincidencia exacta y búsquedas por rango.

Las inserciones, actualizaciones y eliminaciones son eficientes, mantener el orden

clave para una recuperación rápida.

El rendimiento del árbol B es bueno para las tablas grandes y pequeños y no se

degrada como el tamaño de crecimiento de una tabla.

Índice único de escaneo

Exploración de índice único es una de las maneras más eficientes de acceso a los datos. Este método de acceso se utiliza para devolver los datos de los índices del árbol B. El optimizador elige un escaneo único cuando todas las columnas de un único índice se especifican las condiciones de igualdad.

Índice de Rango de escaneo

Índice de Frecuencia de barrido es una operación común para acceder a datos. Puede ser limitada (limitada a ambos lados) o ilimitada (en uno o ambos lados). Los datos se devuelven en el orden ascendente de las columnas de índice. Varias filas con valores idénticos son ordenados (en orden ascendente) por el ROWIDs.


Página 48

Key Compression

Le permite comprimir partes de los valores de columna de clave principal en un índice o tabla organizada por índices, lo que reduce la sobrecarga de almacenamiento de valores repetidos.

En general, las claves de un índice de dos piezas, una pieza de la agrupación y una

pieza única. Si la clave no está definida para tener una pieza única, Oracle brinda una

en forma de un ROWID añadido a la pieza de la agrupación.

La compresión rompe la clave del índice en una entrada de prefijo (la pieza de

agrupación) y una entrada de sufijo (la pieza única). Se logra mediante el intercambio

de las entradas prefijo entre las entradas de sufijo en un bloque de índice. Claves sólo

en los bloques de la hoja de un índice árbol B se comprimen. En los bloqueos de rama

el sufijo clave se puede truncar, pero la clave es no comprimido.

Compresión de claves se realiza dentro de un bloque de índice, pero no a través de los

bloques de índice múltiple. Entradas sufijo forma la versión comprimida de las filas del

índice. Cada referencia a la entrada de un sufijo prefijo de la entrada, que se almacena

en el bloque índice igual a la entrada de sufijo.

Puede dar lugar a un gran ahorro en el espacio, lo que le permite almacenar más claves

en cada bloque de índices, lo que puede conducir a una menor E/S y mejor

rendimiento.

Aunque la compresión de llaves reduce los requisitos de almacenamiento de un índice,

se puede aumentar el tiempo de CPU que se requiere para reconstruir los valores de

columna clave durante un recorrido de índice. También se incurre en algunos gastos

adicionales de almacenamiento, ya que cada entrada de prefijo tiene una sobrecarga

de 4 bytes asociados a ella.

Índice de clave inversa (Reverse key index)

Creación de un índice de clave inversa, en comparación con un índice estándar,

invierte los bytes de cada columna indexada (excepto el ROWID), manteniendo el

orden de las columnas. Un acuerdo así podría ayudar a evitar la degradación del

rendimiento con Real Application Clusters que las modificaciones en el índice se

concentran en un pequeño conjunto de bloques de la hoja. Mediante la inversión de

las claves del índice, las inserciones se distribuyen a través de todas las claves de la

hoja en el índice.

Utilizando la clave inversa elimina la posibilidad de ejecutar un rango de escaneo de

índice de consultas en el índice. Dado que las claves léxico adyacentes no se

almacenan uno junto al otro en un índice de clave inversa, sólo buscar por clave o un

índice completo (tabla) se puede realizar exploraciones.


Página 49

A veces, con un índice de clave inversa puede hacer un OLTP Real Application Clusters

de aplicaciones más rápido.

Índices Bitmap (Bitmap indexes) El propósito de un índice es proporcionar a los punteros a las filas de una tabla que contiene un valor clave dada. En un índice normal, esto se logra mediante el almacenamiento de una lista de ROWIDs para cada clave que corresponde a las filas con el valor de la clave. Oracle almacena cada valor de la clave varias veces con cada ROWID almacenados. En un índice de mapa de bits, un mapa de bits para cada valor de la clave se utiliza en lugar de una lista de ROWIDs. Cada bit en el bitmap corresponde a un ROWID posible. Si el bit está establecido, entonces significa que la fila con el ROWID correspondiente contiene el valor clave. Una función de mapeo de la posición del bit se convierte en un ROWID real, por lo que el índice de mapa de bits proporciona la misma funcionalidad que un índice normal a pesar de que utiliza una representación de diferentes internamente. Si el número de diferentes valores de las claves es pequeño, entonces los índices de mapa de bits son muy eficientes del espacio. Indexación de mapa de bits de manera eficiente se combina índices que corresponden a varias condiciones en una cláusula WHERE. Las filas que cumplen alguna, pero no todas, las condiciones son filtradas antes de la misma tabla que se accede. Esto mejora el tiempo de respuesta, a menudo dramáticamente.

Beneficios para las aplicaciones de Data Warehousing

Indexación Bitmap ofrece beneficios para las aplicaciones de almacenamiento de grandes cantidades de datos y consultas ad hoc, pero un bajo nivel de transacciones concurrentes. Para estas aplicaciones, la indexación de mapa de bits establece lo siguiente:

Reducción de tiempo de respuesta de las grandes clases de consultas ad hoc Una reducción sustancial del uso del espacio en comparación con otras técnicas de

indexación Mejoras de rendimiento espectacular, incluso en hardware extremo más bajo DML paralelo muy eficiente y cargas

Las ventajas de utilizar índices bitmap son mayores para las columnas de baja cardinalidad, es decir, columnas en las que el número de valores distintos es pequeño en comparación con el número de filas en la tabla. Si el número de valores distintos de una columna es menos del 1% del número de filas de la tabla, o si los valores de una columna se repiten más de 100 veces, la columna es un candidato para un índice de bitmap Incluso las columnas con un menor número de repeticiones y la cardinalidad por tanto, mayor puede ser candidato si tienden a estar involucrados en las complejas condiciones en las cláusulas WHERE de las consultas. Por ejemplo, en una tabla con 1 millón de filas, una columna con 10.000 valores distintos es un candidato para un índice de mapa de bits. Un índice de bitmap en esta columna puede superar el rendimiento de un índice B-tree, sobre todo cuando esta columna a menudo es consultada en relación con las otras columnas.


Página 50

Los índices Bitmap y nulos

Índices Bitmap puede incluir filas que tienen valores NULL, a diferencia de la mayoría de los otros tipos de índices. Indexación de los valores nulos pueden ser útiles para algunos tipos de comandos SQL, tales como consultas con función de agregado (COUNT) Los índices Bitmap en las tablas con particiones Al igual que otros índices, puede crear índices bitmap en las tablas de particiones. La única restricción es que los índices bitmap deben ser locales en la tabla que no puede ser dividido índices globales. Índices globales bitmap sólo se admiten en las tablas sin particiones. Además de un índice de bitmap en una sola tabla, puede crear un bitmap join index, que es un índice de bitmap para la unión de dos o más tablas. Este índice es una manera eficiente con el espacio de la reducción del volumen de datos que se deben unir mediante la realización de las restricciones de antemano. Para cada valor en una columna de una tabla, un bitmap join index almacena el ROWIDs de filas correspondientes en una o más tablas de otros. En un entorno de almacenamiento de datos, la condición de combinación es un inner join entre la columna de clave principal o las columnas de las tablas de dimensiones y de la columna de clave externa o columnas de la tabla de hechos. Los bitmap join index son mucho más eficientes en el almacenamiento.

Clústers

Los clúster son un método opcional de almacenamiento de datos de la tabla. Un clúster es un conjunto de tablas que comparten el mismo bloque de datos porque comparten columnas comunes y a menudo se utilizan juntos. Debido a que el almacenamiento de filas relacionadas de tablas diferentes en los mismos bloques de datos, si los clúster se utilizan adecuadamente ofrece los siguientes beneficios:

E/S de disco se reduce para las uniones de tablas en clúster. El tiempo de acceso mejora para las uniones de tablas en clúster. En un clúster, una clave es el valor de las columnas clúster clave para una fila

determinada. Cada valor de la clave del clúster se almacenan sólo una vez en el clúster y el índice de clúster, sin importar el número de filas de diferentes tablas contienen el valor.

Por lo tanto, una menor capacidad de almacenamiento es necesaria para almacenar la tabla relacionada y datos de índice en un grupo que es necesario en forma de tabla no agrupada.

Hash Clusters

Hash clúster almacena los datos de una forma similar al clúster, se diferencia en que su clave viene dada por una función hash, con la cual se agrupan los datos de la tabla. Sin embargo, un registro se almacena en un clúster hash basado en el resultado de aplicar una función hash al valor de la fila clúster clave.


Página 51

Todas las filas con el mismo valor de clave se almacenan juntas en el disco. Clusters hash son una mejor opción que utilizar una tabla de índice o conjunto de índice cuando una tabla se consulta con frecuencia con las consultas de la igualdad.

El valor resultante clave hash apunta directamente a la zona en el disco que almacena las filas. Hash es una forma opcional de almacenamiento de datos de la tabla para mejorar el rendimiento de recuperación de datos. Para utilizar hash, crear un clúster de hash y las tablas de carga en el clúster. Oracle almacena físicamente las filas de una tabla en un conjunto de hash, y recupera de acuerdo a los resultados de una función hash.

Dimensiones

Una dimensión define jerárquico (padre / hijo) las relaciones entre pares de columnas o conjuntos de columnas. Cada valor en el nivel secundario se asocia con uno y sólo un valor en el nivel primario. Una relación jerárquica es una dependencia funcional de un nivel de jerarquía al siguiente nivel en la jerarquía. Una dimensión es un contenedor de relaciones lógicas entre las columnas, y no tiene ningún tipo de almacenamiento de datos se le asignan.

La sentencia CREATE DIMENSION especifica:

Cláusulas de varios niveles, cada uno de los cuales identifica una columna o conjunto

de columnas en la dimensión

Uno o más cláusulas de jerarquía que especifican las relaciones padre / hijo entre

niveles adyacentes

Cláusulas atributo opcional, cada uno de los cuales identifica una columna adicional o

conjunto de columnas asociadas a nivel individual

Las columnas de una dimensión pueden proceder de la misma tabla (sin normalizar) o de varias tablas (total o parcialmente normalizado). Para definir una dimensión con columnas de varias tablas, conectar las tablas usando la cláusula JOIN con la cláusula HIERARCHY.

Sinónimos (Synonyms) Un sinónimo es un alias para cualquier tabla, vista, vista materializada, secuencia, procedimiento, función, paquete, el tipo de objetos Java esquema de clases, definidas por el usuario tipo de objeto, o un sinónimo otra. Debido a que un sinónimo es simplemente un alias, no requiere de almacenamiento que no sea su definición en el diccionario de datos. Los sinónimos son de uso frecuente para la seguridad y comodidad. Por ejemplo, ellos pueden hacer lo siguiente:

Máscara el nombre y propietario de un objeto

Ofrecer transparencia de ubicación de los objetos a distancia de una base de datos

distribuida

Simplificar las instrucciones SQL para los usuarios de la base de datos

Activar el acceso restringido similares a las vistas especializados en el ejercicio de un

control detallado de acceso


Página 52

Puede crear sinónimos públicos y privados. Un sinónimo público es propiedad del grupo de usuarios especial denominado PUBLIC y cada usuario en una base de datos se puede acceder a él. Un sinónimo privado en el esquema de un usuario específico que tiene control sobre su disponibilidad para otros.

Los sinónimos son muy útiles, tanto en entornos de bases de datos distribuidas y no distribuidas, ya que ocultar la identidad del objeto subyacente, incluyendo su ubicación en un sistema distribuido. Esto es ventajoso porque si el objeto subyacente debe ser renombrado o movido, entonces sólo el sinónimo necesita ser redefinido.

Las aplicaciones basadas en el sinónimo de seguir funcionando sin modificaciones. Sinónimos también puede simplificar las sentencias SQL para los usuarios en un sistema de base de datos distribuida.


Página 53

ARQUITECTURA DE PROCESAMIENTO DE CONSULTAS

Para entender como Oracle Database procesa las sentencias SQL, es necesario comprender

una parte de la base de datos llamada optimizador (también conocido como el optimizador de

consultas u optimizador basado en costos). Todas las sentencias SQL utilizan el optimizador

para determinar el modo más eficiente de acceder a los datos especificados.

Uso del Optimizador Para ejecutar una sentencia DML, Oracle Database podría realizarlo de en muchos pasos. Cada

paso. Cada paso o bien recupera las filas de los datos físicos de la base de datos o los prepara

para el usuario que emite la sentencia. Muchas maneras diferentes de procesar una sentencia

DML son posibles. Por ejemplo, el orden en que las tablas o índices son accedidos puede

variar. Los pasos que la base de datos utiliza para ejecutar una sentencia afecta de gran

manera que tan rápido la sentencia se ejecute. El optimizado genera planes de ejecución que

describen los posibles métodos de ejecución.

El optimizador determina que plan de ejecución es más eficiente considerando varias fuentes de información, incluyendo condiciones de la consulta, caminos de acceso disponibles, estadísticas recopiladas por el sistema, y consejos. Para cualquier sentencia SQL procesada por Oracle, el optimizador realiza las siguientes operaciones:

Evaluación de expresiones y condiciones

Inspección de las restricciones de integridad para aprender más sobre los datos y

optimizar basado en la metadata

Transformación de Sentencias

Elección de los objetivos del optimizador

Elección de los caminos de acceso

Elección de las ordenes join

El optimizador genera la mayoría de los caminos posibles para el procesamiento de una

consulta y asigna un costo a cada paso en el plan de ejecución generado. El plan con el menor

costo es escogido como el plan de consulta para ser ejecutado.

Se puede influir en las elecciones optimizador mediante el establecimiento de la meta del optimizador y mediante la recopilación de estadísticas representativas para este. Por ejemplo, Se puede fijar el objetivo optimizador para cualquiera de los siguientes casos:

el rendimiento total

ALL_ROWS obliga al optimizador a obtener la última fila del resultado de la consulta lo

más rápido posible.

Tiempo de respuesta inicial

FIRST_ROWS indica al optimizador que debe obtener la primera fila del resultado de la

consulta cliente lo más rápido posible.


Página 54

Un típico usuario final, con aplicaciones interactivas se beneficiaría de la optimización de tiempo de respuesta inicial, mientras que un lote en modo no interactivo de aplicaciones se beneficiará más de la optimización del rendimiento total.

Componentes del Optimizador

El optimizador tiene tres componentes principales, que se muestran en la siguiente figura:

La entrada al optimizador es una consulta analizada. El optimizador realiza las siguientes operaciones:

El optimizador recibe las consultas analizas y genera un conjunto de posibles planes de

la sentencia SQL basados en los caminos de acceso disponibles y sugerencias.

El optimizador estima que el costo de cada plan en base a las estadísticas en el

diccionario de datos. El costo es de un valor estimado proporcional a la utilización de

los recursos necesarios para ejecutar la sentencia con un plan en particular.

El optimizador compara los costos de los planes y elige el plan de menor costo,

conocido como el plan de consulta, para pasar al generador de origen de la fila.

Transformador de la Consulta

El transformador de consulta determina si es útil cambiar la forma de la consulta para que el optimizador pueda generar un plan de ejecución mejor. La entrada al transformador de consulta es una consulta analizada, la cual está representada por un conjunto de bloques de consulta.


Página 55

Estimador

El estimador determina el costo total de un plan de ejecución determinado. El estimador genera tres tipos de medidas para lograr este objetivo:

selectividad

Esta medida representa una fracción de las filas de un conjunto de filas. La selectividad

está vinculado a un predicado de la consulta, tales como apellido = 'Smith', o una

combinación de predicados.

cardinalidad

Esta medida representa el número de filas de un conjunto de filas.

costo

Esta medida representa las unidades de trabajo o de recursos utilizados. El

optimizador de consultas utiliza las I/O de disco, el uso de CPU y uso de la memoria

como unidades de trabajo.

Si se dispone de estadísticas, el estimador las utiliza para calcular las medidas. Las estadísticas mejoran el grado de precisión de las medidas.

Generador del Plan

El generador del plan trata con diferentes planes para una consulta enviada y escoge el plan con el menor costo. El optimizador genera subplanes para cada una de las subconsultas anidadas y puntos de vista sin combinar, que es representada por un bloque de consulta independiente. El Generador del Plan explora diversos planes para un bloque de consulta al probar diferentes caminos de acceso, métodos de combinación, y órdenes join.

El optimizador automáticamente administra los planes y asegura que sólo planes verificados se utilizan. SQL Plan de Gestión (SPM) permite controlar la evolución del plan, utilizando únicamente un nuevo plan después de que se ha comprobado que se obtienen mejores resultados que el plan actual.

Herramientas de diagnóstico tales como la declaración EXPLAIN PLAN le permiten ver los planes de ejecución elegido por el optimizador. EXPLAIN PLAN muestra el plan de consulta para la consulta SQL se especifica si fueron ejecutados hoy en la sesión actual.

Caminos de Acceso Un camino de acceso es la forma en que se recuperan los datos de la base de datos. Por ejemplo, una consulta que utiliza un índice tiene una ruta de acceso diferente a una consulta que no. En general, los caminos de acceso con índices son los mejores para las declaraciones que recuperan un pequeño subconjunto de filas de la tabla. Los análisis completos son más eficientes para acceder a una gran parte de la tabla.

La base de datos puede utilizar diferentes caminos de acceso para recuperar datos de una tabla:


Página 56

Análisis completos de la tabla

Este tipo de escáner lee todas las filas de una tabla y filtra aquellos que no cumplen

con los criterios de selección. La base de datos escanea de forma secuencial todos los

bloques de datos en el segmento, incluyendo aquellos bajo la marca de agua que

separa el espacio no utilizado del utilizado.

Análisis del ROWID

El ROWID de una fila especifica el archivo de datos y el bloque de datos que contiene

la fila y la ubicación de la fila en ese bloque. Primero la base de datos obtiene el

ROWID de las filas seleccionadas, ya sea desde la declaración de la cláusula WHERE o

por medio de una exploración de índice, y localiza cada fila seleccionada en función de

su ROWID.

Análisis de los índices

Este análisis busca en un índice de los valores de columna indexados accedidos por la

sentencia SQL. Si la declaración sólo tiene acceso a las columnas del índice, Oracle

Database lee los valores de columna indexados directamente desde el índice.

Análisis de Clúster

Un análisis de clúster es utilizado para recuperar datos de una tabla almacenada en

una tabla clúster indexada, donde todas las filas con la misma llave clúster son

almacenadas en el mismo bloque de datos. La base de datos obtiene primero el rowid

de una fila selecciona mediante el escaneo del índice clúster. Oracle Databsae localiza

las filas basadas en este rowid.

Análisis Hash

Un análisis hash es utilizado para localiza las tilas en un clúster hash, donde todas las

filas con el mismo valor hash están almacenados en el mismo bloque de datos. La base

de datos primero obtiene el valor hash aplicando una función hash al valor de la llave

clúster especificado en la sentencia. Oracle Database entonces analiza los bloques de

datos que contienen filas con este valor hash.

El optimizador elige un camino de acceso basado en los caminos de acceso disponible para la instrucción y el costo estimado de uso de cada ruta de acceso o una combinación de caminos.

Estadísticas del Optimizador Las estadísticas del optimizador son una colección de fatos que describen detalladamente sobre la base de datos y los objetos de la base de datos. Las estadísticas proveen una estadísticamente correcta imagen de los datos almacenados y la distribución de su uso por el optimizador a la hora de evaluar los caminos de acceso.

Las estadísticas del optimizador incluyen lo siguiente:

Estadísticas de tablas

Estas incluyen el número de filas, numero de bloques, y promedio del tamaño de las

filas.

Estadísticas de columnas

Estas incluyen el número de valores distintos y los nulos en una columna y la

distribución de datos.

Estadísticas de índices


Página 57

Estas incluyen el número de bloques de hojas y niveles del índice.

Estadísticas del sistema

Estas incluyen CPU y I/O rendimiento y utilización

Oracle Database recoge las estadísticas del optimizador en todos los objetos de base de datos de forma automática y mantiene estas estadísticas como una tarea de mantenimiento automatizado. También se pueden recoger estadísticas manualmente utilizando el paquete DBMS_STATS. Este paquete PL/SQL permite modificar, ver, exportar , importar y borrar estadísticas.

La estadísticas del optimizador son creadas con el propósito de optimizar la consulta y son almacenadas en el diccionario de datos. Estas estadísticas no deben confundirse con las estadísticas de rendimiento visible a través de vistas de rendimiento dinámico.

Sugerencias del Optimizador

Una sugerencia es un comentario en una sentencia SQL que actúa como una instrucción para el optimizador. Algunas veces el diseñador de la aplicación, tiene más información sobre los datos particulares de la aplicación entonces está habilitado para optimizar, puede escoger un camino más efectivo para ejecutar la sentencia SQL. El diseñador de la aplicación puede utilizar sugerencias en las sentencias SQL para especificar como la sentencia debería de ser ejecutada.


Página 58

ARQUITECTURA DE SUBPROCESOS Y TAREAS

Un proceso es un mecanismo en un sistema operativo que puede ejecutar una serie de pasos. El mecanismo depende del sistema operativo. Por ejemplo, en Linux un proceso en segundo plano de Oracle es un proceso Linux. En Windows, un proceso en segundo plano de Oracle es un hilo de ejecución dentro de un proceso.

Módulos de código son ejecutados por procesos, Cuando un usuario se conecta a una base de datos de Oracle ejecuta dos módulos de código diferentes, que además el encargado de gestionar estos procesos es el sistema operativo, estos dos módulos diferentes son:

Aplicación o Herramienta Oracle: normalmente son programas clientes que se

conectan a la base de datos y permiten ejecutar sentencias SQL. Ej.: SQL*Plus, SQL

developer

Código del servidor de Oracle: son los diferentes procesos que se han de ejecutar en el

servidor para atender las peticiones del usuario.

Múltiples procesos de Oracle Database Systems La base de datos Oracle es un sistema multiproceso, lo que significa que no toda la base de datos está corriendo en un mismo proceso, si no que varias partes de la base de datos se ejecuta concurrentemente. Permitiendo a múltiples usuarios conectarse a la misma vez, y mayor rapidez en el tiempo de respuesta, puesto que siempre que pueda va a utilizar al máximo al ordenador, por ejemplo si tiene ocho núcleos el servidor, y resulta que una petición se puede paralelizar se ejecutara esa petición por partes en cada núcleo.

Cada proceso en una instancia de base de datos realiza un trabajo específico. Al dividir el trabajo de la base de datos y aplicaciones en varios procesos, múltiples usuarios y las aplicaciones pueden conectarse a una instancia de forma simultánea, mientras que el sistema proporciona un buen rendimiento.

http://translate.googleusercontent.com/translate_c?hl=es&ie=UTF8&prev=_t&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://download.oracle.com/docs/cd/E11882_01/server.112/e25789/glossary.htm&usg=ALkJrhjBheOPtNfKYLnpxzJWSMnlmA8l9g#CBAJIHIJ


Página 59

Procesos de Oracle y la SGA

Tipos de procesos Una instancia de base de datos contiene o interactúa con los siguientes tipos de procesos:

Proceso de usuario

Procesos del servidor

Procesos en segundo plano obligatorios: DBWn, PMON CKPT, LGWR SMON

Procesos en segundo plano opcionales: ARCn LMDn QMNn, CJQ0 LMON RECO, Dnnn

LMS Snnn, LCKn Pnnn

Procesos esclavos


Página 60

Procesos de Usuario

Lanzado por el usuario para pedir interacción con la base de datos, Cuando un usuario ejecuta

una aplicación como un Pro * C programa o SQL * Plus, el sistema operativo crea un proceso

de cliente (a veces llamado un proceso de usuario) para ejecutar la aplicación de usuario. La

aplicación cliente tiene bibliotecas de Oracle de base de datos vinculados a ella que

proporcionan las API necesarias para comunicarse con la base de datos.

Los procesos de usuario difieren en aspectos importantes de los procesos de Oracle. Los

procesos de Oracle servicio del proceso cliente puede leer y escribir en el SGA, mientras que el

proceso del cliente no puede. Un proceso cliente se puede ejecutar en un host distinto al

equipo base de datos, mientras que los procesos de Oracle no pueden.

Conexiones y sesiones

Una conexión es una vía de comunicación física entre un cliente y el proceso de una instancia

de base de datos. Una vía de comunicación se establece mediante los mecanismos disponibles

de comunicación entre procesos o software de red. Por lo general, se produce una conexión

entre un proceso de cliente y un proceso de servidor o distribuidor, pero también puede

ocurrir entre un proceso cliente y el Administrador de conexión de Oracle (CMAN).

Una sesión es una entidad lógica en la memoria de instancia de base de datos que representa

el estado de una sesión de usuario actual a una base de datos. Por ejemplo, cuando un usuario

está autenticado por la base de datos con una contraseña, se establece una sesión para este

usuario. Una sesión dura desde el momento en que el usuario se autentica en la base de datos

hasta el momento en que el usuario se desconecta o sale de la aplicación de base de datos.

Múltiples sesiones pueden existir simultáneamente para un usuario de base de datos única. En

las conexiones de servidor dedicado, la base de datos crea un proceso de servidor en nombre

de cada conexión. En una conexión de servidor compartido, muchos de los procesos de cliente

tienen acceso a un único proceso de servidor compartido.

http://translate.googleusercontent.com/translate_c?hl=es&ie=UTF8&prev=_t&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://download.oracle.com/docs/cd/E11882_01/server.112/e25789/glossary.htm&usg=ALkJrhjBheOPtNfKYLnpxzJWSMnlmA8l9g#CBAFHDAD

http://translate.googleusercontent.com/translate_c?hl=es&ie=UTF8&prev=_t&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://download.oracle.com/docs/cd/E11882_01/server.112/e25789/glossary.htm&usg=ALkJrhjBheOPtNfKYLnpxzJWSMnlmA8l9g#CBAHEBIG


Página 61

Una sesión para cada conexión

Dos sesiones en una conexión

Procesos del Servidor

Oracle Database crea procesos de servidor para manejar las peticiones de los procesos de cliente que se conectan a la instancia. Un proceso cliente siempre se comunica con una base de datos a través de un proceso de servidor independiente.

Se utilizan como manejadores de los procesos de usuario. Los comandos de usuario se envían a

estos procesos que se encargan de solicitar peticiones a la base de datos mediante el interfaz

de programas de Oracle (OPI, Oracle Program Interface).

Los procesos del servidor creados en nombre de una aplicación de base de datos pueden

realizar una o más de las siguientes tareas:

Analizar y ejecutar sentencias SQL emitidas a través de la aplicación, incluyendo la

creación y la ejecución del plan de consulta (ver "Etapas de Procesamiento de SQL" )

Ejecución de PL / SQL

Leer bloques de datos de archivos de datos en la caché del búfer de base de datos (el

proceso de DBW n de fondo tiene la tarea de escribir los bloques modificados al disco)

http://translate.googleusercontent.com/translate_c?hl=es&ie=UTF8&prev=_t&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://download.oracle.com/docs/cd/E11882_01/server.112/e25789/glossary.htm&usg=ALkJrhjBheOPtNfKYLnpxzJWSMnlmA8l9g#CHDICHFA





http://translate.googleusercontent.com/translate_c?hl=es&ie=UTF8&prev=_t&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://download.oracle.com/docs/cd/E11882_01/server.112/e25789/sqllangu.htm&usg=ALkJrhj_Ycu7UuBrgmsF9qqpCBYVOq1DZg#CHDDAGAA












Página 62

Devolver los resultados de tal manera que la aplicación puede procesar la información

En las conexiones de servidor dedicado, la conexión del cliente se asocia con sólo un proceso

de servidor, Cada proceso cliente se comunica directamente con el proceso servidor. Este

proceso del servidor se dedica a su proceso de cliente durante la duración de la sesión.

En las conexiones de servidor compartido, las aplicaciones cliente se conectan a través de una

red a un proceso de despachador, no un proceso de servidor. El proceso despachador recibe

peticiones de clientes vinculados entre sí y las pone en una cola de solicitudes, Como un

proceso de servidor dedicado, un proceso servidor compartido tiene su propia PGA. Sin

embargo, la UGA de una sesión está en el SGA de manera que cualquier servidor compartido

puede tener acceso a datos de la sesión.

Procesos en segundo plano

Una base de datos Oracle multiproceso utiliza algunos procesos adicionales llamados procesos

en segundo plano. Los procesos en segundo pEs el encargado de gestionar adecuadamente los

procesos que fallan. Ante caídas de procesos, PMON se encarga de restaurar los datos

adecuadamente lano realizan tareas de mantenimiento requeridas para operar la base de

datos y para maximizar el rendimiento para múltiples usuarios.

Oracle database crea procesos en segundo plano de forma automática cuando una instancia de base de datos se inicia. Una instancia puede tener muchos de los procesos en segundo plano, no todos los que siempre existen en todas las configuraciones de base de datos.

Procesos en segundo plano obligatorios

DBWn (Escritor de base de datos) : Proceso encargado de escribir en los ficheros de

datos los buffers más antiguos de la memoria, para que la base de datos vaya

almacenando los cambios. Escribe si:

o Se produce un punto de control

o Los buffers sucios alcanzan el umbral

o No hay ningún buffer libre

o Se produce un timeout

o Se realiza un solicitud de sondeo RAC

o Tablespace OFFLINE

o Tablespace READ ONLY

o Tabla DROP o TRUNCATE

o Tablespace BEGINBACKUP


Página 63

LGWR (Escritura de logs): Escribe los datos a los ficheros rehacer (redo) desde la

caché de archivos rehacer. LGWR escribe:

○ En la validación

○ Si se llena a un tercio de su capacidad

○ Si hay 1MB de redo

○ Cada tres segundos

○ Antes de que escriba DBWn

SMON (Monitor del sistema): Permite recuperar la instancia de la base de datos en

caso de caída fatal (cuando el sistema falla por ejemplo).

Responsabilidades:

○ Recuperación de instancias

- Aplica los cambios pendientes en los archivos redo log online

- Abre la base de datos para que acceda el usuario

- Deshace las transacciones no validadas

○ Fusiona el espacio libre

○ Libera los espacios temporales

● PMON (Monitor de procesos): Es el encargado de gestionar adecuadamente los

procesos que fallan. Ante caídas de procesos, PMON se encarga de restaurar los datos

adecuadamente, hace una limpieza cuando los procesos han fallado:

○ Haciendo un rollback en las transacciones

○ Liberando los bloqueos

○ Liberando otros recursos

○ Reiniciando distribuidores interrumpidos

CKPT (Punto de control): Es un evento de sincronización en un punto específico en el tiempo, un punto de control realiza las siguientes tres operaciones:


Página 64

1. Cada bloque sucio en la caché del búfer se escribe en el archivo de datos . Es decir, se sincroniza el datablocks en la caché del búfer con el archivo de datos en el disco. Es el DBWR que escribe todos los databaseblocks modificados a los ficheros de datos.

2. La última SCN está escrito (actualizado) en el encabezado del archivo de datos .

3. La última SCN también se escribe en el ControlFiles .

Actualiza todas las cabeceras de los ficheros de datos para que aparezca la nueva

disposición de datos. Esto ocurre cuando se genera un punto de comprobación.

La fecha y hora del último punto de control puede ser recuperada a través de checkpoint_time en v$datafile_header. El SCN del último punto de control se pueden encontrar en v$database . checkpoint_change #.

Si el tamaño del registro de rehacer es pequeña, el desempeño del puesto de control no será óptima.

Es responsable de:

○ Señalar a DBWn en los puntos de control

○ Actualizar las cabeceras de archivos de datos con información del punto de

control

○ Actualizar los archivos de control con información del punto de control

Eventos que desencadenan un punto de control:

Un cambio de redo log

LOG_CHECKPOINT_TIMEOUT ha expirado

LOG_CHECKPOINT_INTERVAL se ha alcanzado

DBA así lo requiera ( alterar puesto de control del sistema )

Además, si un espacio de tablas es de backups en caliente , un punto de control para el espacio

de tablas en cuestión está llevando a cabo. Mientras que cambia de registro de rehacer causa

un puesto de control, puestos de control no causen un cambio de registro

Tipos de Checkpoint:

Full Checkpoint

Thread Checkpoint

File Checkpoint

Object “Checkpoint”

Parallel Query Checkpoint

Incremental Checkpoint

Log Switch Checkpoint

http://translate.googleusercontent.com/translate_c?hl=es&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://www.adp-gmbh.ch/ora/concepts/cache.html&usg=ALkJrhiUEiYncFAG7pHHcJoxKWgReJfkgA





http://translate.googleusercontent.com/translate_c?hl=es&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://www.adp-gmbh.ch/ora/concepts/datafiles.html&usg=ALkJrhh1900wAXJI8vWW0tVlT12KhXKp7Q















http://translate.googleusercontent.com/translate_c?hl=es&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://www.adp-gmbh.ch/ora/concepts/processes/dbwr.html&usg=ALkJrhho9ilcfdHG4VwA2Rioix7rqau5Qg

http://translate.googleusercontent.com/translate_c?hl=es&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://www.adp-gmbh.ch/ora/concepts/scn.html&usg=ALkJrhig_90bMbp_0zKPCx2m4G-6JUwWPQ

http://translate.googleusercontent.com/translate_c?hl=es&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://www.adp-gmbh.ch/ora/concepts/datafiles.html&usg=ALkJrhh1900wAXJI8vWW0tVlT12KhXKp7Q#datafile_header








http://translate.googleusercontent.com/translate_c?hl=es&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://www.adp-gmbh.ch/ora/concepts/controlfiles.html&usg=ALkJrhiSpGd_rrCKLHAAS7bwDEPAaFn_cQ

http://translate.googleusercontent.com/translate_c?hl=es&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://www.adp-gmbh.ch/ora/misc/dynamic_performance_views.html&usg=ALkJrhjhO25OERNxliSsJS7ElGlJeJ3r5Q#datafile_header





http://translate.googleusercontent.com/translate_c?hl=es&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://www.adp-gmbh.ch/ora/misc/dynamic_performance_views.html&usg=ALkJrhjhO25OERNxliSsJS7ElGlJeJ3r5Q#database



http://translate.googleusercontent.com/translate_c?hl=es&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://www.adp-gmbh.ch/ora/concepts/online_redo_logs.html&usg=ALkJrhgnauVidMwHUvX8x7lxfZUM4c7njw#size









http://translate.googleusercontent.com/translate_c?hl=es&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://www.adp-gmbh.ch/ora/misc/init_params.html&usg=ALkJrhgsRUcrbjtayt2YI6flwfeV2ExbJg#log_checkpoint_timeout





http://translate.googleusercontent.com/translate_c?hl=es&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://www.adp-gmbh.ch/ora/misc/init_params.html&usg=ALkJrhgsRUcrbjtayt2YI6flwfeV2ExbJg#log_checkpoint_interval





http://translate.googleusercontent.com/translate_c?hl=es&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://www.adp-gmbh.ch/ora/sql/alter_system.html&usg=ALkJrhjIeu2LjrTRoWpO5ybJPrrGSB4ATw#checkpoint











http://translate.googleusercontent.com/translate_c?hl=es&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://www.adp-gmbh.ch/ora/concepts/tablespaces.html&usg=ALkJrhgB_oKdE0W58VB89c6JdVfD8g5GNQ





http://translate.googleusercontent.com/translate_c?hl=es&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://www.adp-gmbh.ch/ora/admin/backup_recovery/hot_backup.html&usg=ALkJrhhoH6C2xjQyTM8RyDRnhICbsU1wvA







http://translate.googleusercontent.com/translate_c?hl=es&rurl=translate.google.com.sv&sl=en&tl=es&twu=1&u=http://www.adp-gmbh.ch/ora/concepts/redo_log_switch.html&usg=ALkJrhiSVzt9OyIb-l5w-OeTn8vwgzdIqg#relation_checkpoint


















Página 65

Procesos en segundo plano opcionales

ARCn (Archiver): Copia los archivos de registro en línea para rehacer el

almacenamiento fuera de línea después de que ocurre un cambio de redo log.

o Archiva automáticamente archivos redo log online si está definido el modo

ARCHIVELOG

o Protege el registro contra todos los cambios realizados en la base de datos

RECO (Recoverer): Este proceso solo se observa cuando la base de datos ejecuta la

opción distribuida de Oracle. La transacción distribuida es una en la que dos o más

emplazamientos de datos deben mantenerse sincronizados, Por ejemplo cuando se

tiene una copia de los datos en diferentes ciudades y por fallas en una línea telefónica

se pierde una transacción en la mitad de su actualización. El proceso recuperador

entonces resuelve las transacciones que hayan quedado inconsistentes en las dos

ciudades.

LCKN (Lock): Es un proceso opcional, configurado para manejar los bloqueos entre

bases de datos Oracle cuando estas se encuentran en distintos computadores y

compartiendo el mismo conjunto de discos (es decir en modo servidor en paralelo).

QMNn (Queue Monitor): QMNn es un proceso opcional de background para el

encolamiento avanzado de Oracle, que monitorea las colas de mensajes. El

encolamiento avanzado se usa con comunicación asíncrona. Los procesos envían los

mensajes y en lugar de esperar por la respuesta siguen con su trabajo.

Dnnn (Dispatcher): Es un proceso opcional que permite a los usuarios compartir

procesos de servidor. Permitiendo que se conecten múltiples usuarios al mismo

servidor.

Snnn (Shared Server): Este tipo proceso se encarga de atender a cada uno de los

clientes conectados a la base de datos compartiendo los procesos del servidor.

Además de estos existen otros como: LMDn, CJQ0, LMON, LMS, Pnnn.

Procesos esclavos

Realizan tareas adicionales para un proceso en segundo plano o en el servidor, son los

procesos de fondo que realizan trabajo en nombre de otros procesos. Entre los cuales

tenemos:

I / O Procesos Esclavo

Los esclavos de consultas en paralelo


Página 66

ARQUITECTURA DE ADMINISTRACIÓN DE MEMORIA

Oracle utiliza la memoria para almacenar información como la siguiente:

El código de programa

La información sobre una sesión conectada, incluso si no está activa

La información necesaria durante la ejecución del programa (por ejemplo, el estado

actual de una consulta de las filas que se han recuperado)

La información que se comparte y se comunica entre los procesos de Oracle

Caché de datos que también se almacenan permanentemente en la memoria

periférica

Las estructuras de memoria básicos asociados con Oracle incluyen:

Sistema Global Area (SGA), que es compartida por todos los servidores y el fondo los

procesos.

Áreas de Programa Global (PGA), que es privada para cada servidor y el fondo proceso,

hay un PGA para cada proceso.

System Global Area Es un grupo de estructuras de memoria compartida que contienen datos e información de control para una instancia de base de datos Oracle. Si hay varios usuarios conectados simultáneamente a la misma instancia, los datos en el SGA de la instancia se comparten entre los usuarios. En consecuencia, el SGA se denomina a veces el área global compartida.

Un SGA y los procesos de Oracle constituyen una instancia de Oracle. Oracle automáticamente asigna memoria para un SGA cuando se inicia una instancia, y el sistema operativo reclama la memoria cuando se cierra la instancia. Cada instancia tiene su propio SGA.


Página 67

El SGA es de lectura / escritura. Todos los usuarios conectados a un múltiple proceso de instancia de base de datos pueden leer la información contenida en SGA de la instancia, y varios procesos de escribir en el SGA durante la ejecución de Oracle.

El SGA contiene las estructuras de datos siguientes:

Base de datos caché del búfer

Redo log buffer

Shared pool

Java pool

Large pool

Streams pool

Diccionario de datos de caché

Información miscelánea

Parte de la SGA contiene información general sobre el estado de la base de datos y la ejemplo, que los procesos de fondo necesario para acceder a lo que se llama la SGA fija.

No hay datos de usuario se almacena aquí. El SGA también incluye información transmitida

entre los procesos, como el bloqueo de la información. Si el sistema utiliza una arquitectura de

servidor compartido, la solicitud y las colas de respuesta y algunos de los contenidos de la PGA

se encuentran en el SGA.

El SGA cuenta con un número de componentes de memoria, que son las piscinas de la

memoria utilizados para satisfacer una determinada clase de peticiones de asignación de

memoria. Ejemplos de la memoria componentes incluyen la piscina compartida (se utiliza para

asignar memoria para SQL y PL/SQL ejecución), el grupo de java (para objetos Java y otra

memoria de ejecución de Java), y la caché del búfer (utilizado para la caché de bloques de

disco). Todos los componentes SGA asignar y cancelar la asignación de espacio en unidades de

gránulos. Oracle Database rastrea el uso de memoria SGA en números internos de los gránulos

de cada componente SGA.

Tamaño del grano se determina por el total de tamaño de SGA. En la mayoría de las

plataformas, el tamaño de un gránulo es de 4 MB, si el tamaño total de SGA es menos de 1 GB,

y el tamaño de los gránulos es de 16 MB para las grandes SGA. Algunas dependencias de la

plataforma surgir. Por ejemplo, en Windows de 32 bits, el granulometría es de 8 M de SGA más

de 1 GB.

Oracle Database pueden establecer límites en la cantidad de memoria virtual de la base de

datos utiliza para la SGA. Se puede comenzar con los casos un mínimo de memoria y permitir

que el ejemplo de un uso más la memoria mediante la ampliación de la memoria asignada para

los componentes de SGA, hasta un máximo determinado por el parámetro de inicialización

SGA_MAX_SIZE.

Si el valor de SGA_MAX_SIZE en el archivo de parámetros de inicialización o el archivo de

parámetros del servidor (SPFILE) es menor que la suma de la memoria asignada a todos los

componentes, ya sea de forma explícita en el parámetro archivo o en su defecto, a la vez se

inicializa la instancia, la base de datos no escenario de SGA_MAX_SIZE.


Página 68

Para un rendimiento óptimo en la mayoría de los sistemas, todo el SGA debe caber en la

memoria real. Si no lo hace, y si se utiliza memoria virtual para almacenar partes de ella,

entonces la base de datos global el rendimiento del sistema puede disminuir drásticamente. La

razón de esto es que las porciones del SGA se paginan (escribir y leer desde el disco) por el

sistema operativo. La cantidad de memoria dedicada a todas las áreas comunes en la SGA

también tiene un rendimiento impacto.

Los siguientes parámetros tienen el mayor efecto en el tamaño de SGA:

Parámetro Descripción

DB_CACHE_SIZE El tamaño de la caché de bloques estándar.

LOG_BUFFER El número de bytes asignados para el buffer de redo log.

SHARED_POOL_SIZE El tamaño en bytes de la superficie dedicada a compartir SQL y PL / SQL.

LARGE_POOL_SIZE El tamaño de la piscina grande, el valor predeterminado es 0.

JAVA_POOL_SIZE El tamaño de la piscina de Java.

Automatic Shared Memory Management

En versiones anteriores de bases de datos, un administrador de base de datos (DBA) se deben

especificar manualmente diferentes tamaños de los componentes SGA mediante el

establecimiento de una serie de parámetros de inicialización, incluyendo los parámetros

SHARED_POOL_SIZE, DB_CACHE_SIZE, JAVA_POOL_SIZE, y LARGE_POOL_SIZE.

A partir de Oracle Database 10g incluye Automatic Shared Memory Management característica

que simplifica la gestión de memoria SGA de manera significativa.

El DBA puede simplemente especificar la cantidad total de memoria SGA a disposición de una instancia mediante el parámetro de inicialización SGA_TARGET y la Base de Datos Oracle distribuirá automáticamente esta memoria entre los diversos subcomponentes para asegurar una utilización más eficaz de la memoria.

Cuando la gestión automática de memoria SGA está activada, los tamaños de los diferentes componentes del SGA son flexibles y pueden adaptarse a las necesidades de una carga de trabajo sin necesidad de ninguna configuración adicional. La base de datos de forma automática distribuye la memoria disponible entre los diversos componentes según sea necesario, permitiendo que el sistema para maximizar el uso de todos los disponibles de memoria SGA.


Página 69

Cada vez que un componente de las necesidades de memoria, puede solicitar que se transfiere

de otro componente a través del mecanismo de ajuste automático interno. Esta transferencia

de la memoria ocurre de forma transparente, sin intervención del usuario.

El rendimiento de cada uno de estos componentes por tamaño es supervisada por el

Instancia de Oracle Database. El ejemplo utiliza la información sobre la empresa y las

estadísticas para determinar cómo se distribuye la memoria de manera óptima entre los

componentes. A medida que la carga de trabajo cambios, la memoria se redistribuye para

garantizar un rendimiento óptimo. Para calcular el distribución óptima de la memoria, la base

de datos utiliza un algoritmo que tiene en cuenta tanto a largo como a corto plazo las

tendencias.

Administración de forma manual de los componentes SGA

Hay algunos componentes de SGA cuyo tamaño no se ajusta automáticamente. El

administrador tiene que especificar el tamaño de estos componentes de manera explícita, si es

necesario por la aplicación. Dichos componentes son:

Mantenimiento / reciclaje caché de búfer (controlada por DB_KEEP_CACHE_SIZE and

DB_RECYCLE_CACHE_SIZE)

Depósitos adicionales de amortiguación para los tamaños de bloque no estándar

(controlada por DB_nK_CACHE_SIZE, n = {2, 4, 8, 16, 32})

El tamaño de estos componentes está determinado por el administrador define el valor de sus parámetros correspondientes. Estos valores pueden, por supuesto, puede cambiar en cualquier momento ya sea mediante Enterprise Manager o desde la línea de comandos con un ALTER SYSTEM declaración.

La memoria consumida por los componentes manualmente tamaño reduce la cantidad de memoria disponible para el ajuste automático.

Oracle Database recuerda el tamaño de los componentes ajustados automáticamente a través de paradas ejemplo, si usted está usando un archivo de parámetros del servidor (SPFILE). Como resultado, el sistema es necesario conocer las características de la carga de trabajo de nuevo cada vez que un ejemplo, se ha iniciado. Se puede comenzar con la información de la instancia del pasado y siguen la evaluación de la carga de trabajo donde lo dejó en la última parada.

Un administrador de base de datos se expande el uso de SGA de un componente con un

"ALTER SYSTEM" declaración de modificar los valores de los parámetros de inicialización

asociada con los respectivos componentes. Rondas de Oracle Database hasta el tamaño de las

nuevas especificaciones al múltiplo más cercano de 16 MB y añade o elimina gránulos para

cumplir con el tamaño de destino.

La base de datos debe tener gránulos libre suficiente para satisfacer la solicitud. Siempre y

cuando la cantidad de memoria actual SGA es menor que "SGA_MAX_SIZE", la base de datos

puede asignar más gránulos hasta que el tamaño de SGA alcanza "SGA_MAX_SIZE".


Página 70

El tamaño de los gránulos que se está utilizando actualmente para el SGA para cada

componente se puede ver en la vista V$SGAINFO. El tamaño de cada componente y el tiempo

y el tipo de la operación de redimensionamiento actuó por última vez en cada componente se

puede ver en la vista

V$SGA_DYNAMIC_COMPONENTS. La base de datos mantiene un buffer circular de las

operaciones de cambio de tamaño últimos 400 en los componentes SGA. Puede ver el buffer

circular en la vista V$SGA_RESIZE_OPS.

Database Buffer Cache El caché del búfer de base de datos es la parte de la SGA que mantiene copias de los bloques

de datos leer archivos de datos. Todos los procesos del usuario conectado simultáneamente a

la cuota de ejemplo el acceso a la caché del búfer de base de datos.

El caché del búfer de base de datos y la memoria caché compartida de SQL son lógicamente

segmentada en varios conjuntos. Esta organización en varios conjuntos se reducen los

conflictos en multiprocesador sistemas.

Los buffers en la caché se organizan en dos listas: la lista de escribir y la lista de por lo menos

recientemente usado (LRU). La lista de escribir tiene buffers que contienen datos que se ha

modificado pero aún no ha sido escrito en el disco. La lista LRU tiene buffers libres, buffers

clavado, y buffers que aún no han sido trasladados a la lista de escritura. Buffers libres no

contiene ningún dato útil y están disponibles para su uso. Topes fijos son en la actualidad se

está accediendo.

Cuando un proceso Oracle accede a un buffer, el proceso se mueve al buffer de la utilizada

más recientemente (MRU) al final de la lista LRU.

La primera vez que un proceso de usuario de Oracle requiere un dato concreto, se busca los

datos en la caché del búfer de base de datos. Si el proceso se encuentra ya en los datos de la

caché (un acierto de caché), se puede leer los datos directamente desde la memoria. Si el

proceso no puede encontrar el datos de la caché (un error de caché), se debe copiar el bloque

de datos de un archivo de datos en el disco en un búfer en la memoria caché antes de acceder

a los datos. Acceso a datos a través de una de aciertos de caché es más rápido que el acceso a

datos a través de un fallo de caché.

Antes de leer un bloque de datos en la caché, el proceso debe primero encontrar un buffer

libre. La proceso busca en la lista LRU, comenzando en el extremo menos utilizado de la lista.

La Búsquedas proceso o hasta que encuentra un buffer libre o hasta que se haya buscado el

umbral límite de buffers.

Si el proceso de usuario encuentra un buffer sucio, ya que busca en la lista LRU, que se mueve

el buffer a la lista de escribir y sigue buscando. Cuando el proceso encuentra un buffer libre, se

lee el bloque de datos desde el disco en el buffer MRU y el buffer se mueve hasta el final de la

LRU lista. Si un proceso de usuario de Oracle busca en el límite del umbral de buffers sin


Página 71

encontrar un libre buffer, el proceso deja de buscar la lista LRU y las señales de fondo DBW0

proceso de escribir algunos de los buffers modificados al disco.

El algoritmo LRU y Análisis Completo

Cuando el proceso de usuario está realizando un escaneo completo de tabla, lee los bloques

de la tabla en los buffers y los coloca en el extremo LRU (en lugar de al final MRU) de la lista

LRU.

Esto se debe a una tabla totalmente digitalizadas por lo general se necesita sólo brevemente,

por lo que los bloques debe moverse rápidamente para salir de los bloques utilizados con más

frecuencia en la memoria caché.

Puede controlar este comportamiento por defecto de los bloques que participan en los recorridos de tablas en una base de mesa por mesa. Para especificar que los bloques de la tabla se coloca al final de la lista MRU durante un escaneo completo de tabla, utilice la cláusula CACHÉ al crear o modificar una tabla o clúster. Puede especificar este comportamiento para tablas de búsqueda de pequeños o grandes tablas históricas estática para evitar que E / S en los accesos posteriores de la tabla.

Puede configurar la caché del búfer de base de datos con depósitos reguladores

independientes que, o bien mantener los datos en la caché del búfer o hacer que los búferes

disponibles para los nuevos datos inmediatamente después de usar los bloques de datos.

Objetos particulares esquema (tablas, clusters, índices y particiones) puede ser asignado a la

agrupación de almacenamientos intermedios adecuadas para controlar la forma en que los

bloques de datos de edad fuera de la caché.

El grupo KEEP de búfer conserva los bloques el objeto de esquema de datos en la

memoria.

El grupo RECYCLE de búferes, elimina los bloques de datos de la memoria tan pronto

como se ya no son necesarios.

El grupo de búfer predeterminado contiene bloques de datos de objetos de esquema

que no están asignados a ningún grupo de búfer, así como los objetos de esquema que

se ha asignado explícitamente a la piscina DEFAULT.

Los parámetros de inicialización que configuran el KEEP y RECYCLE agrupaciones de

almacenamientos intermedios se DB_KEEP_CACHE_SIZE and DB_RECYCLE_CACHE_SIZE.

Redo Log Buffer Es un buffer circular en el SGA que contiene información sobre los cambios realizados a la base de datos. Esta información se almacena en las entradas de redo. Entradas de redo contienen la información necesaria para reconstruir o rehacer los cambios realizados en la base de datos de INSERT, UPDATE, DELETE, CREATE, ALTER o DROP operaciones. Entradas de redo se utilizan para la recuperación de la base de datos, si es necesario.

Entradas de redo son copiadas por los procesos de base de datos Oracle desde el espacio de memoria del usuario para el buffer de redo log en la SGA. Las entradas de redo ocupan un


Página 72

espacio continuo y secuencial en el búfer. El proceso en segundo plano LGWR escribe el buffer de redo log en el archivo de redo log activo (o grupo de archivos) en el disco.

El parámetro de inicialización "log_buffer" determina el tamaño (en bytes) del búfer de registro de rehacer. En general, los valores más altos reducen el archivo de registro de E / S, sobre todo si las transacciones son largos o numerosos. La configuración predeterminada es de 512 kilobytes (KB) o 128 veces la KB valor del parámetro CPU_COUNT, el que sea mayor,

Shared Pool Es una parte de la SGA contiene el caché de la biblioteca, la caché de diccionario, buffers para

los mensajes de la ejecución en paralelo, y las estructuras de control. El tamaño total de la

piscina comunitaria está determinado por el parámetro de inicialización SHARED_POOL_SIZE.

El valor predeterminado de este parámetro es de 8MB en plataformas de 32 bits y 64 MB en

plataformas de 64 bits. Aumentar el valor de este parámetro aumenta la cantidad de memoria

reservada para la piscina comunitaria.

Library Cache El caché de biblioteca incluye las zonas comunes de SQL, SQL áreas privadas (en el caso de una

configuración de servidor compartido), los procedimientos PL / SQL y paquetes, y las

estructuras de control tales como cerraduras y caché de biblioteca se ocupa.

Áreas compartidas de SQL sean accesibles a todos los usuarios, por lo que el caché de

biblioteca se encuentra en la zona compartida en el SGA.

Los procesos de PL/SQL unidades de programa (procedimientos, funciones, paquetes, bloques

anónimos y activa base de datos) de la misma manera que los procesos individuales de

sentencias SQL. Oracle asigna un área común para mantener la analizada, en forma compilada

de una unidad de programa. Oracle asigna un área privada para contener los valores

específicos de la sesión que se ejecuta la unidad de programa, incluso a nivel mundial locales, y

las variables de paquetes (también conocido como instanciación del paquete) y buffers para la

ejecución de SQL. Si más de un usuario ejecuta la misma unidad de programa, a continuación,

un espacio único, compartido es utilizado por todos los usuarios, mientras que cada usuario

mantiene una copia separada de su área privada SQL, la celebración de los valores específicos

de su o su sesión.

Instrucciones SQL individuales contenidos en una unidad de programa PL / SQL se procesan

como descritos en los apartados anteriores. A pesar de sus orígenes dentro de un programa PL

/ SQL unidad, las instrucciones SQL utilice un área compartida para mantener sus

representaciones y analizar una área privada para cada sesión que se ejecuta la instrucción.

Diccionario de caché El diccionario de datos es una colección de tablas de bases de datos y puntos de vista que

contiene referencia información sobre la base de datos, sus estructuras, y sus usuarios. Oracle


Página 73

accede al diccionario de datos con frecuencia durante el análisis de instrucciones SQL. Este

acceso es esencial para el funcionamiento continuo de Oracle. El diccionario de datos se

accede con frecuencia por parte de Oracle de que dos lugares especiales en memoria

designada para ocupar el diccionario de datos. Un área que se llama el diccionario de datos

caché, también conocido como el caché de la fila, ya que posee los datos de las filas en lugar

de buffers (que poseen bloques enteros de datos). La otra área en la memoria para mantener

el diccionario de datos es la caché de la biblioteca. Todos los procesos de usuario de Oracle

comparten estas dos caches para el acceso a los datos diccionario de la información.

Asignación y reutilización de la Memoria en la zona compartida En general, cualquier elemento (área compartida de SQL o una fila diccionario) en la zona

compartida permanece hasta que se limpia de acuerdo a un algoritmo modificado LRU. La

memoria de los elementos que no están siendo utilizados regularmente se libera si el espacio

es necesario para los nuevos elementos que se deben asignar un espacio en la zona

compartida. Un algoritmo LRU permite modificar los elementos compartidos de la piscina que

son utilizados por muchas sesiones que permanecen en la memoria, siempre y cuando sean

útiles, incluso si el proceso que creó originalmente el elemento termina. Como resultado, la

sobrecarga y el procesamiento de sentencias SQL asociado a un sistema multiusuario Oracle se

reduce al mínimo.

Cuando una sentencia SQL es enviada a Oracle para su ejecución, Oracle automáticamente

realiza los pasos siguientes de la memoria de la asignación:

1. Oracle comprueba la piscina compartida para ver si un área compartida de SQL ya existe una

declaración idéntica. Si es así, que comparten área de SQL se utiliza para la ejecución de las

instancias posteriores de la nueva declaración. Por otra parte, si no hay un área común para

una declaración SQL, Oracle asigna un área nueva de SQL compartido en la zona compartida.

En ningún caso, la zona privada del usuario de SQL está asociada con el área de SQL

compartida que contiene la instrucción.

2. Oracle asigna un área privada SQL en nombre de la sesión. La ubicación de la zona privada

de SQL depende del tipo de conexión establecida para la sesión.

Large Pool El administrador de la base de datos se puede configurar un área de memoria opcional

llamado a “large pool” para proporcionar grandes asignaciones de memoria para:

Sesión de memoria para el servidor compartido y la interfaz de Oracle XA (utilizado en

las transacciones de interactuar con más de una base de datos)

E / S de los procesos del servidor

Oracle copia de seguridad y las operaciones de restauración


Página 74

Mediante la asignación de memoria de la sesión de la large pool de servidor compartido,

Oracle XA, o puerto paralelo de la consulta, Oracle puede utilizar la shared pool principalmente

para el almacenamiento en caché compartida SQL y evitar la sobrecarga de rendimiento

causada por la disminución de la caché compartida de SQL.

Además, la memoria para copia de seguridad de Oracle y las operaciones de restauración, para

el servidor de E/S procesos, y para puerto paralelo se asigna en los buffers de unos pocos

cientos de kilobytes.

La large pool está en mejores condiciones para satisfacer tales solicitudes de grandes

cantidades de memoria compartida de la piscina. La large pool no tiene una lista LRU. Es

diferente de espacio reservado en el piscina comunitaria, que utiliza la misma lista LRU como la

memoria de otro tipo asignados a la shared pool.

Java pool Se usa en la memoria del servidor para todos los específicos de la sesión el código de Java y los

datos dentro de la JVM. Memoria de Java pool se utiliza de diferentes maneras, dependiendo

de qué modo el servidor de Oracle se ejecuta en Java Pool estadísticas Asesor proporcionar

información sobre la memoria caché de biblioteca utilizados para Java y predecir cómo los

cambios en el tamaño de la piscina de Java pueden afectar la tasa de analizar.

El Asesor de piscina de Java se activa cuando internamente STATISTICS_LEVEL está establecido

en Típico o superior. Estas estadísticas restablece cuando el asesor se apaga.

Streams Pool En una sola base de datos, puede especificar que la memoria de Corrientes harán con cargo a

un fondo de la SGA llamado la streams pool. Para configurar el grupo de los flujos y especificar

el tamaño de la piscina, en bytes, utilizando el parámetro de inicialización

STREAMS_POOL_SIZE. Si un streams pool no se define, entonces se crea automáticamente

cuando las streams se utilizó por primera vez.

Si SGA_TARGET está establecido, la memoria del SGA de la piscina viene de los Arroyos reserva

mundial de SGA. Si SGA_TARGET no está definida, entonces SGA de la piscina es Streams

transferidos desde la caché del búfer. Esta transferencia se lleva a cabo sólo después de que el

primer uso de streams. El importe transferido es de 10% del tamaño del pool compartido.

Control del Uso de la SGA de la Memoria Dinámica SGA proporciona controles externos para aumentar y disminuir el uso de Oracle de la

memoria física. Junto con dynamic buffer cache, shared pool, and large pool, dynamic SGA

permiten lo siguiente:


Página 75

El SGA puede crecer en respuesta a una declaración del administrador de base de

datos, hasta un sistema operativo máximo especificado y la especificación

SGA_MAX_SIZE.

El SGA puede reducir en respuesta a una declaración del administrador de base de

datos, a un mínimo de Oracle prescrito, por lo general un límite del sistema operativo

preferido.

Tanto la caché del búfer y las piscinas SGA puede crecer o reducirse en tiempo de

ejecución de acuerdo con algunos internos, Oracle gestiona la política.


Página 76

Diagramas y documentación de las bases de datos del sistema

Estructuras de almacenamiento de Oracle

Comparación entre las bases de datos del sistema de Oracle y SQLServer


Página 77

Tablespace principales incluidos en la base de datos de Oracle.

Tablespace Descripción

EXAMPLE Este tablespace contiene esquemas de ejemplo incluidos con Oracle Database. Los esquemas de ejemplo proporcionan una plataforma común para ejemplos. La documentación de Oracle y los materiales educativos contienen ejemplos basados en los esquemas de ejemplo.

SYSTEM Este tablespace es automáticamente creado en la creación de la base

de datos. Oracle Database lo utiliza para gestionar la base de datos. Contiene el diccionario de datos, que es el conjunto central de tablas y vistas utilizados como referencias de solo lectura por una base de

datos en particular. También contienen varias tablas y vistas que tienen información administrativa sobre la base de datos. Estos están contenidos en el esquema SYS, y solo puede ser accedido por el

usuario SYS u otro usuario administrativo que tenga los privilegios requeridos.

SYSAUX Este es un tablespace auxiliar para el tablespace SYSTEM.

El tablespace SYSAUX contiene datos de algunos de los componentes y productos, reduciendo la carga en el tablespace SYSTEM. Cada base de datos usando Oracle Database 10g release 1 (10.1) o superior debe de tener un tablespace SYSAUX.

Los componentes que utilizan SYSAUX como su tablespace por defecto durante la instalación incluyen Automatic Workload Repository, Oracle Streams, Oracle Text, y Database Control Repository.

TEMP Este tablespace almacena datos temporales generados en el procesamiento de sentencias SQL. Por ejemplo, este tablespace

podría ser usado por un ordenamiento. Cada base de datos debería de tener un tablespace temporal que sea asignado al usuario como su tablespace temporal. En la base de datos preconfigurada, el


Página 78

tablespace TEMP es especificado como el tablespace temporal por

defecto. Si ningún tablespace temporal es especificado cuando la cuenta de usuario es creada, entonces Oracle Database asigna este tablespace al usuario.

UNDOTBS1 Este es un tablespace deshacer usado por la base de datos para almacenar información de deshacer.

USERS Este tablespace es usado para almacenar objetos y datos permanentes del usuario.. Similar al tablespace TEMP, cada base de

datos debería de tener un tablespace para datos permanentes de usuario que es asignada a los usuarios. De otra manera, objetos del usuario deberán ser creados en el tablespace SYSTEM, lo cual no es

una buena práctica. En la base de datos preconfigurada, USERS es designado como tablespace por defecto para todos los nuevos usuarios.

Esquemas SYS y SYSTEM

Todas las bases de datos de Oracle incluyen cuentas administrativas por defecto. Estas cuentas administrativas son altamente privilegiados y están destinados sólo para los administradores de bases con autorización para realizar tareas tales como iniciar y detener la base de datos, gestión de memoria y almacenamiento, creación y gestión de usuarios de bases de datos, y así sucesivamente.

La cuenta administrativa SYS se crea automáticamente cuando se crea una base. Esta cuenta puede llevar a cabo todas las funciones administrativas de base de datos. El esquema SYS almacena la base de las tablas y vistas para el diccionario de datos. Estas tablas de la base y vistas son fundamentales para el funcionamiento de la base de datos de Oracle. La tablas en el esquema SYS son manipulados sólo por la base de datos y nunca deben de ser modificadas por cualquier usuario.

La cuenta SYSTEM es creada automáticamente también cuando la base de datos es creada. El esquema SYSTEM almacena tablas y vistas adicionales que muestran información administrativa, y tablas y vistas internas usadas por varias opciones y herramientas de Oracle Database. Nunca utilice el esquema SYSTEM para almacenar tablas de interés para usuarios no administrativos.

Catálogo de Datos Oracle cuenta con una serie de tabla y vistas que conforman una estructura denominada catálogo. La principal función del catálogo de Oracle es almacenar toda la información de la estructura lógica y física de la base de datos, desde los objetos existentes, la situación de los //datafiles//, la configuración de los usuarios, etc.


Página 79

El catálogo sigue un estándar de nomenclatura para que su memorización sea más fácil:

Prefijos:

|| Prefijo || Descripción ||

|| DBA_ || Objetos con información de administrador. Sólo accesibles por ||

|| || usuarios con permisos DBA ||

|| USER_ || Objetos con información propia del usuario al que estamos ||

|| || conectado. Accesible desde todos los usuarios. Proporcionan ||

|| || menos información que los objetos DBA_ ||

|| ALL_ || Objetos con información de todos los objetos en base de datos. ||

|| V_$ ó V$ || Vistas dinámicas sobre datos de rendimiento ||

Existe una tabla de catálogo para cada tipo de objeto posible. Su nombre aparecerá en plural TABLES, VIEWS, SEQUENCES, TABLESPACES.

Sabiendo qué objetos existen, y qué prefijos podemos utilizar, ya podemos acceder a los objetos del catálogo de Oracle. Ejemplos:

|| Objeto || Descripción ||

|| DBA_TABLES || Información para administradores de las tablas en base de ||

|| || datos. ||

|| USER_VIEWS || Información de las vistas creadas por el usuario desde el que ||

|| || accedemos. ||

|| ALL_SEQUENCES || Información de todas las secuencias existentes en base de datos. ||

|| DBA_TABLESPACES || Información de administración sobre los //tablespaces//. ||

|| USER_TAB_COLUMNS || Todas las columnas de tabla en el usuario activo. ||

Los objetos de catálogo también guardan relaciones entre ellos. Por ejemplo, el objeto ALL_TABLES guarda una relación 1-N con el objeto ALL_TAB_COLUMNS: Una tabla tiene N columnas.

Existe un pseudo-usuario llamado PUBLIC el cual tiene acceso a todas las tablas del catálogo público. Si se quiere que todos los usuarios tengan algún tipo de acceso a un objeto, debe darse ese privilegio a PUBLIC y todo el mundo dispondrá de los permisos correspondientes.

El catálogo público son aquellas tablas (USER_ y ALL_) que son accesibles por todos los usuarios. Normalmente dan información sobre los objetos creados en la base de datos.


Página 80

El catálogo de sistema (DBA_ y V_$) es accesible sólo desde usuarios DBA y contiene tanto información de objetos en base de datos, como información específica de la base de datos en sí (versión, parámetros, procesos ejecutándose…)

Ciertos datos del catálogo de Oracle están continuamente actualizados, como por ejemplo las columnas de una tabla o las vistas dinámicas (V$). De hecho, en las vistas dinámicas, sus datos no se almacenan en disco, sino que son tablas sobre datos contenidos en la memoria del servidor, por lo que almacenan datos actualizados en tiempo real. Algunas de las principales son:

|| ƒ || V$DB_OBJECT_CACHE: contiene información sobre los objetos que están en el caché ||

|| || del SGA ||

|| ƒ || V$FILESTAT: contiene el total de lecturas y escrituras físicas sobre un //data file// de la ||

|| || base de datos. ||

|| ƒ || V$ROLLSTAT: contienen información acerca de los segmentos de //rollback//. ||

Sin embargo hay otros datos que no pueden actualizarse en tiempo real porque penalizarían mucho el rendimiento general de la base de datos, como por ejemplo el número de registros de una tabla, el tamaño de los objetos, etc. Para actualizar el catálogo de este tipo de datos es necesario ejecutar una sentencia especial que se encarga de volcar la información recopilada al catálogo:

ANALYZE [TABLE|INDEX] nombre [COMPUTE|ESTIMATE|DELETE] STATISTICS;

La cláusula COMPUTE hace un cálculo exacto de la estadísticas (tarda más en realizarse en ANALYZE), la cláusula ESTIMATE hace una estimación partiendo del anterior valor calculado y de un posible factor de variación y la cláusula DELETE borra las anteriores estadísticas.

===== La sentencia COMMENT =====

El catálogo público contiene ciertas tablas encargadas de almacenar información adicional sobre tablas, vistas y columnas. La información que se suele almacenar es información de análisis, valores posibles para las columnas y en general todo aquello que se haya concluido durante la etapa de análisis.

Las tablas existentes son:

|| Tabla || Descripción ||

|| ALL_TAB_COMMENTS || Contiene los comentarios para tablas y vistas. ||

|| ALL_COL_COMMENTS || Contiene los comentarios para las columnas de tablas y vistas. ||

La información se debe almacenar en base de datos según la siguiente sintaxis:


Página 81

COMMENT ON TABLE *tabla|vista+ IS ‘texto’; COMMENT ON COLUMN *tabla|vista+.columna IS ‘texto’;

Una vez que esta información está en base de datos, se puede escribir procedimientos o scripts SQL que muestren la información para sacar informes de documentación de base de datos.

Listado alfabético de las vistas del sistema de Oracle

Listado alfabético de las tablas del sistema de Oracle que se utilizan normalmente.

ALL_ARGUMENTS

ALL_CATALOG

ALL_COL_COMMENTS

ALL_CONSTRAINTS

ALL_CONS_COLUMNS

ALL_DB_LINKS

ALL_ERRORS

ALL_INDEXES

ALL_IND_COLUMNS

ALL_LOBS

ALL_OBJECTS

ALL_OBJECT_TABLES

ALL_SEQUENCES

ALL_SNAPSHOTS

ALL_SOURCE

ALL_SYNONYMS

ALL_TABLES

ALL_TAB_COLUMNS

ALL_TAB_COL_STATISTICS

ALL_TAB_COMMENTS

ALL_TRIGGERS

ALL_TRIGGER_COLS

ALL_TYPES

ALL_UPDATABLE_COLUMNS

ALL_USERS

ALL_VIEWS

DATABASE_COMPATIBLE_LEVEL

DBA_DB_LINKS

DBA_ERRORS

DBA_OBJECTS

DBA_ROLES

DBA_ROLE_PRIVS

DBA_SOURCE

DBA_TABLESPACES

DBA_TAB_PRIVS

DBA_TRIGGERS

DBA_TS_QUOTAS

DBA_USERS

DBA_VIEWS

DICTIONARY

DICT_COLUMNS

GLOBAL_NAME

NLS_DATABASE_PARAMETERS

NLS_INSTANCE_PARAMETERS NLS

NLS_SESSION_PARAMETERS NLS

PRODUCT_COMPONENT_VERSION

ROLE_TAB_PRIVS

SESSION_PRIVS

SESSION_ROLES

SYSTEM_PRIVILEGE_MAP

TABLE_PRIVILEGES

TABLE_PRIVILEGE_MAP


Página 82

CONCLUSIONES

Oracle Database es un potente RDBMS que nos brinda un almacenamiento rápido y sobre todo seguro de nuestros datos.

Oracle nos brinda un eficaz almacenamiento de nuestros datos brindándonos herramientas que nos permiten la recuperación de estos en caso de cualquier tipo de fallo.

Conocer tanto el funcionamiento como la arquitectura interna de cada uno de los elementos de un RDBMS es de vital importancia para poder realizar una correcta administración de los datos almacenados.

Los distintos procesos que realiza Oracle van enfocados a manejar eficazmente cada uno de las peticiones de los usuarios de la base de dato.

El procesamiento de consultas es uno de los aspectos más importantes a tener en cuenta ya que a través de estos se asegura una respuesta rápida y eficiente de parte del RDBMS a las distintos consultas y procedimientos que un usuario ejecute


Página 83

RECOMENDACIONES

La investigación sobre gestores de bases de datos debe realizarse tomando en

consideración las últimas versiones que los fabricantes lanzan al mercado, así como las

versiones que marcaron un cambio en la estructura y funcionamiento de los gestores

de bases de datos.

Consultar la documentación del fabricante así como libros, manuales o sitios web de

expertos en la administración de bases de datos permite tener un mejor panorama

sobre la amplitud de la aplicación que tienen hoy en día los gestores.


Página 84

REFERENCIAS BIBLIOGRÁFICAS

Libros y Manuales: Oracle Database Concepts, 10g Release 2 (10.2) Michele Cyran Oracle Oracle Application Server 10g Administration Handbook John Garmany, Donald K. Burleson McGraw-Hill/Osborne Oracle Essentials Oracle Database 11g Rick Greenwald, Robert Stackowiak, Jonathan Stern O’Reilly Oracle Database 10g DBA Handbook Kevin Loney, Bob Bryla McGraw Hill Administración de la Base de Datos Oracle9i Volumen I y II Marie St. Gelais Oracle Sitios Web:

http://download.oracle.com/docs/cd/E11882_01/server.112/e25789/sqllangu.htm#au

toId13

http://download.oracle.com/docs/cd/E11882_01/timesten.112/e17114/systemtables.

htm

http://www.oracle.com/pls/db112/homepage

http://download.oracle.com/docs/cd/E11882_01/server.112/e25789/logical.htm#CNC

PT250

http://xue.unalmed.edu.co/~mfcabrera/db/arqoracle.pdf

http://www.lcc.uma.es/~bds/adminbd/apuntes/ABD4_Oracle.pdf

http://www.wikilearning.com/curso_gratis/iniciacion_a_oracle-

conceptos_de_almacenamiento_en_oracle/3861-6

http://www.infor.uva.es/~jvegas/cursos/bd/orarq/orarq.html

http://download.oracle.com/docs/cd/E11882_01/server.112/e25789/tablecls.htm#CN

CPT010


Página 85

ANEXOS

Clasificación de los Tipos de Datos


Página 86

Diagrama de la Arquitectura Oracle 11g


Página 87

Comparaciones entre Oracle y SQLServer

Address Space

Arquitectura Interna


Página 88

Database


Página 89

GLOSARIO

Vía de acceso (access path): El medio por el cual se recuperan los datos de una base de datos.

Por ejemplo, una consulta con un índice y una consulta con una tabla puede usar caminos de

acceso diferentes.

Transacción activa: Una transacción que se ha iniciado pero aún no confirma o se deshace.

Modo ARCHIVELOG:Y modo de la base de datos que habilita el archivamiento del online redo

log.

Árbol de Indice B: Los índices están organizados cono mu árbol cabeza abajo. Un árbol de

índice B tiene dos tipos de bloques: bloques de rama para buscar y bloques hoja para

almacenar valores. Los bloques hojas contienen cada valor de los dato indexados y un towid

correspondiente utilizado para localizar la fila actual.

Indice de bitmap: Una índice de base de datos en que la base de datos almacena un mapa de

bits por cada llave índice en vez de una lista de rowids.

Encabezado del Bloque: Una parte del bloques de datos que incluye información sobre el tipo

de bloque, las direcciones del bloque, y a veces información de la transacción.

Cabecera del Bloque: Espacio en un bloque de datos en el que se almacena toda la meta data

necesaria para gestionar el bloque. La cabecera del bloque incluye el encabezado del bloque,

el directorio de las tablas, y el directorio de las filas.

Buffer: Una dirección de memoria principal en el cache del buffer de la base de datos.

cache recovery: La fase de recuperación de instancia donde la Base de Datos de Oracle aplica

todos los cambios confirmados y no confirmados en los archivos redo log en línea a los bloques

de datos cambiados.

columna: Espacio vertical en una tabla que representa un dominio de datos. Una definición de

tablas incluye un nombre de tabla y un conjunto de columnas. Cada columna tiene un nombre

y tipo de datos.

commit: Acción que finaliza una transacción y hace los cambios permanentes realizados en la

transacción.

concurrencia: Acceso simultaneo de los mismos datos por muchos usuarios. Una base de datos

multiusuario debe proveer un control adecuado de la concurrencia para que los datos no

puedan ser actualizados o cambiados de manera inapropiada, comprometiendo la integridad

de los datos.

Condición: La combinación de uno o más expresiones y operadores lógicos en una sentencia

SQL que retorne un valor de TRUE, FALSE or UNKNOW.

control file: Un archivo binario que almacena la estructura física de una base de datos y

contiene los nombres y ubicaciones de los archivos redo log, el tiempo de la creación de la

base de datos, la secuencia de log actual, información sobre los puntos de control, etc.

database: Colección organizada de datos tratados como una unidad. El propósito de la base de

datos es almacenar y recuperar información relacionada.


Página 90

database buffer cache: La porción de system global area (SGA) que contiene las copias de los

bloques de datos. Todos los procesos de los clientes conectados concurrentemente a la

instancia comparten el cache del buffer.

data block: La unidad lógica más pequeña de almacenamiento de datos en Oracle Database.

Un bloque de datos corresponde a un número específico de bytes de espacio físico en disco.

Diccionario de datos: Una colección de tablas y vistas de base de datos de solo lectura que

contienen información sobre la base de datos, su estructura, y sus usuarios.

data dictionary view: Una vista predefinida de tablas u otras vistas en el diccionario de datos,

estas vistas inician con el prefijo DBA_, ALL_, orUSER_.

data file: Un archivo físico en disco creado por la base de datos de Oracle que contiene los

datos de una base de datos. El archivo de dato puede ser localizado o bien en un archivo del

sistema operativo o en un grupo de discos de Oracle ASM.

data segment: los segmentos contienen datos para tablas sin clúster, particiones de tabla, o

tablas clúster.

data type: En SQL, es un conjunto de propiedades asociadas a un valor o constante.

DDL: Definición de Lenguaje de Datos. Incluye sentencias tales como CREATE TABLE o ALTER

INDEX que definen o cambia la estructura.

DML: Data manipulation language. Incluye sentencias como SELECT, INSERT, UPDATE, y

DELETE.

plan de ejecución: La combinación de pasos usados por la base de datos para ejecutar

sentencias SQL. Cada paso recoge los datos de datos físicos de la base de datos o los prepara

para los usuarios que emiten la sentencia.

extent: múltiples bloque de datos contiguos localizados para almacenar un específico tipo de

información. Un segmento es hecho de una o más extensiones.

hashing: Una técnica matemática en que un infinito conjunto de valores de entrada son

mapeados como un finito conjunto de valores de salida, llamados valores hash. Hashing es útil

para rápida búsquedas de datos en una tabla hash.

heap-organized table: Una tabla en que las filas de datos están almacenadas sin un orden

especifico en el disco. Por defecto CREATE TABLE crea una tabla de montón.

high water mark: La frontera entre el espacio utilizado y no utilizado en un segmento.

hint: Una instrucción pasada al optimizador a través de comentarios en una sentencia SQL. El

optimizador utiliza consejos para elegir un plan de ejecución de la sentencia.

index: Esquema de objeto opcional asociado a una nonclustered table, table partition, o table

clúster. En algunos casos los índices agilizan el acceso a los datos.

instance: La combinación de system global area (SGA) y background processes. Una instancia

es asociada a una y solo una base de datos.

key: Columna o conjunto de columnas asociados incluidas en la definición de ciertos tipos de

restricciones de integridad.

large pool: Area opcional en el SGA que provee ubicaciones de memoria para backup y

operaciones de restauración

LOB: Un dato de Oracle designado para mantener tamaños de datos grandes

locally managed tablespace Un tablespace que utiliza un mapa de bits almacenados en cada

fila de datos para gestionar la extensión. En contraste, un tablespace gestionado por


Página 91

diccionario utiliza el diccionario de datos para administrar el espacio.

null Ausencia de un valor en una columna e una fila. Nulls indica un dato perdido, desconocido

o inaplicable

online redo log: El conjunto de dos o más archivos redo log que guardan todos los cambios

hechos en los archivos de datos y archivos de control. Cuando un cambio es hecho en la base

de datos, Oracle Database genera un registro redo.

Optimizer: El software integrado de base de datos que determina la manera más eficiente de

ejecutar una sentencia SQL, teniendo en cuenta los factores relacionados con los objetos de

referencia y las condiciones especificadas en la declaración.

Oracle architecture: Estructuras de memoria y procesos usados por la Base de Datos de Oracle

para administrar la base de datos.

Oracle ASM: Oracle Automatic Storage Management (Oracle ASM). Un gestor de volúmenes y

un sistema de archivos para archivos de base de datos.

Oracle process: Un proceso que corre en código de Oracle Database.

PGA: Un búfer de memoria que contiene datos e información de control para un proceso de

servidor.

Query: Una operación que recupera datos de tablas o vistas. Por ejemplo, SELECT * FROM

empleados es una consulta.

read consistency: Una visión coherente de los datos vistos por el usuario. Por ejemplo, en la

declaración de coherencia de lectura en el conjunto de los datos vistos por una sentencia SQL

se mantiene constante a lo largo de la ejecución de sentencias.

read-only database: Una base de datos que está disponible para consultas y no se puede

modificar.

redo log: Un conjunto de archivos que protegen los datos alterados de base de datos en la

memoria y que no han sido escritos en los archivos de datos. El registro de rehacer puede

constar de dos partes: el registro de rehacer en línea y el registro de rehacer archivados.

redo log buffer: Estructura de memoria en el SGA que almacena entradas de rehacer. La base

de datos escribe en entradas de rehacer almacenadas en el redo log buffers a un archivo

online redo log file, que es usado si la recuperación es necesaria.

rol: Un conjunto de privilegios que son dados a los usuarios de la base de datos o a otros roles.

row: Conjunto de columnas correspondientes a un solo registro en una tabla. La base de datos

almacena las filas en bloques de datos.

row chaining: Situación en la que Oracle Database debe almacenar una serie de cadenas de

bloques porque la fila es demasiado larga para caber dentro de un solo bloque.

rowid: Una dirección globalmente única que identifica a una fila en particular

row migration: Situación en la que Oracle Database mueve una fila de un bloque de datos

hacia otro bloque de datos porque el crecimiento de la fila es demasiado grande para caber en

el bloque original.

Savepoint: Un SCN en una transacción en el cual la transacción puede ser retornada.

schema: Un colección de objetos de base de datos, que incluye estructuras lógicas tales como

tablas e índices. Un esquema tiene el nombre del usuario de la base de datos que lo posee

SCN: System Change Number. Un orden primitivo de la base de datos.


Página 92

segment: Conjunto de extensiones localizados en un base de datos específicos tales como

tablas, índices o tablas clúster.

sesión: Una entidad lógica en la instancia de la base de datos que representa el estado del

usuario actual.

SGA: System global area. Un grupo de memoria compartida que contiene datos e información

de controles para una instancia de Oracle Database.

Table: Unidad básica de almacenamiento de datos en Oracle Database. Datos en las tablas

están almacenados en filas y columnas.

table clúster: Un esquema de objeto que contiene datos de una o más tablas, los cuales tienen

una o más columnas en común.

table compresión: La compresión de segmentos de datos reducen el espacio de disco en una

tabla de montón o partición de tabla.

Tablespace: Unidad de almacenamiento lógicamente relacionada. Los archivos de datos están

almacenados en tablespaces.

Archivos temporales: Un archivo que pertenece a un tablesapce temporal.

temporary segment: Un segmento creado por Oracle Database cuando una sentencia SQL

necesita una base de datos temporal para completar su ejecución.

temporary table: Una tabla que mantiene un conjunto de resultados intermedios de una

transacción o sesión.

Transaction: Unidad lógica de trabajo que contiene una o más sentencias SQL.

Undo data: Registro de las acciones de las transacciones, antes de ser confirmadas.

Undo tablespace: Un table space que contiene segmentos cuando automatic undo

management mode se encuentre habilitado.

View: Una presentación personalizada a la medida de los datos en una o más tablas.

INVESTIGACIÓN BIBLIOGRÁFICA SOBRE ORACLE(1)

Documents

Transcript of INVESTIGACIÓN BIBLIOGRÁFICA SOBRE ORACLE(1)