Arquitectura Oracle.pdf

Detalles de la Arquitectura
Parte I
Material recopilado para ABD-631 1

Base de Datos ORACLE

Base de Datos ORACLE
• Su objetivo es almacenar y recuperar
información relacionada.
• Tiene una estructura lógica y otra física.
BD Oracle
Estructura Lógica
Estructura Física

• Una BD Oracle consta de 3 tipos de archivos:
– Los archivos de DATOS, que contienen los datos
reales de la BD.
– Los archivos REDO LOG, que mantienen un
registro de los cambios efectuados en la BD, para
activar la recuperación de datos en caso de fallo.
– Los archivos de CONTROL, que contienen
información para mantener y verificar la
integridad de la BD.

Otras estructuras de Archivos
• Otros archivos que no forman parte de la BD:
– Archivo de PARÁMETROS, define las características
de la instancia Oracle.
– Archivo de CONTRASEÑAS, que autentica a los
usuarios para iniciar o cerrar la instancia.
– Archivo REDO LOG ARCHIVADOS, son copias
offline de los archivos REDO LOG online que son
necesarios en caso de fallo.

Estructura Física de la BD
• La estructura física incluye 3 tipos de archivos:
– Archivos de Datos (Data Files)
– Archivos de Control (Control Files)
– Archivos Redo Log (Redo log Files online)
DATA FILES
(incluye los
Metadatos)
CONTROL
FILES
REDO LOG
FILES (online)
ESTRUCTURA FÍSICA DE LA BD ORACLE

Estructura de la Memoria
• En Oracle, la estructura de la memoria está
formada por 2 áreas:
– SGA (Área Global del Sistema, o Área Global
Compartida) que se asigna al iniciar una instancia
Oracle.
– PGA (Área Global de Programas) que se asigna al
iniciar el proceso de servidor.

SGA (ÁREA Global de Systema)
• Se usa para almacenar información de BD y de
control para Oracle Server y se asigna
memoria virtual donde reside Oracle.
Caché de Buffers
de la BD
Buffer de REDO
LOG
Java Pool
(Conjunto Grande)
Large Pool
(Conjunto Grande)
Caché de
Biblioteca
Caché del DD
S G A
Conjunto
Compartido

• Existen 2 estructuras de la memoria
adicionales que se pueden configurar desde el
SGA:
– El Conjunto Grande (LARGE POOL).
– El Conjunto Java (JAVA POOL).
• Para ver el SGA desde el SQL:
SQL>Show SGA;

• Está formada por varias estructuras de
memoria:
– Conjunto compartido (SHARED POOL).
– Caché de buffers de la BD.
– Buffer de Redo Log
– Otras estructuras como: Gestión de bloqueo,
Datos Estadísticos, etc.

A partir de la versión de Oracle 9i, el área de
SGA implementa la posibilidad de modificar su
configuración sin cerrar la instancia, el tamaño
de la SGA se especifica con el parámetro:
SGA_MAX_SIZE

Otros parámetros que determinan el tamaño de
los componentes de la SGA son:
DB_CACHE_SIZE, LOG_BUFFER,
SHARED_POOL_SIZE, LARGE_POOL_SIZE,
JAVA_POOL_SIZE, cuyo tamaño sumado no
puede exceder al primer parámetro
mencionado (SGA_MAX_SIZE).

• La unidad de asignación asociada al SGA es el
GRÁNULO, que especifica memoria virtual
contigua, el tamaño de éstas unidades
depende del tamaño del SGA.
NOTA: Gránulo = 4 MB si SGA < 128 MB
En otro caso: Gránulo = 16 MB
La configuración mínima de SGA es de 3
Gránulos.

Conjunto Compartido (Shared Pool)
• Se utiliza para almacenar:
– Las últimas sentencias SQL ejecutadas.
– Metacódigo, compilación de las sentencias SQL
ejecutadas.
• Está formado por 2 estructuras
clave:
– Caché de Biblioteca (Library Caché)
– Caché del Diccionario de Datos
Caché de
Biblioteca
Caché del DD
Conjunto
Compartido

• El Tamaño del Conjunto Compartido está
definido por el parámetro:
SHARED_POOL_SIZE
• Su tamaño se debe ajustar a las necesidades
tanto de las áreas fijas (que mantienen su
tamaño) como las variables (que aumentan o
disminuyen en función a requisitos del usuario
o del programa)

• El tamaño del Conjunto compartido se puede
modificar en forma dinámica con la sentencia
SQL:
SQL>ALTER SYSTEM SET SHARED_POOL_SIZE = 64M;

Caché de Biblioteca
• Almacena información acerca de las
sentencias SQL utilizadas recientemente.
• Permite compartir las sentencias utilizadas
con mayor frecuencia.
• Lo gestiona el algoritmo LRU.
• Su tamaño lo determina el Conjunto
Compartido.

NOTA: Si el tamaño del Conjunto Compartido es
muy pequeño, las sentencias se recargan
continuamente en el caché de Biblioteca, lo
que afecta el rendimiento.

Caché del Diccionario de Datos
• Almacena:
– Conjunto de definiciones utilizadas más
recientemente en la BD.
– Incluye información de archivos de BD, tablas,
índices, columnas, usuarios, privilegios, etc.
– Si el Servidor necesita esta información, se leen
las tablas del DD y los datos devueltos se
almacenan en esta caché.
– Su tamaño lo determina el Conjunto Compartido.

Caché de Buffers de la BD
• Almacena copias de bloques de datos que se
han recuperado de archivos de datos.
• Permite grandes mejoras de rendimiento al
obtener y actualizar datos.
• Gestionado por el Algoritmo LRU.
• Su tamaño es determinado por el parámetro
del bloque primario:
DB_BLOCK_SIZE

Caché de Buffers de la BD
• Está formado por sub-cachés independientes:
– DB_CACHE_SIZE. Especifica el tamaño de caché de
buffers por defecto (no se define en 0).
– DB_KEEP_CACHE_SIZE. Establece el tamaño de la
caché de buffers KEEP, se usa para retener en
memoria bloques que se van a reutilizar.
– DB_RECYCLE_CACHE_SIZE. Determina el tamaño
de la caché de buffers de reciclado, se usa para
eliminar bloques que no se van a reutilizar.

• Se puede cambiar su tamaño en forma
dinámica con:
SQL>ALTER SYSTEM SET DB_CACHE_SIZE = 96M
• Es útil ver estadísticas del comportamiento de
los distintos CACHÉS, se muestran en la vista
dinámica: v$DB_CACHE_ADVICE.

Buffer de REDO LOG
• Registra TODOS los cambios realizados en los
bloques de datos de la BD.
• Su finalidad principal es la recuperación.
• Los cambios registrados dentro de éste buffer
se llaman registros de REDO.
• Los registros de REDO contienen información
que permite reconstruir o rehacer cambios.
• Tamaño definido por LOG_BUFFER.

Conjunto Grande (Large Pool)
• Área opcional de memoria en el SGA.
• Libera al Conjunto Compartido de su carga.
• Se utiliza para:
– Memoria de Sesión para el Servidor compartido.
– Procesos de Servidor de E/S.
– Operaciones de copia de seguridad y recuperación.
– Buffers de mensajes de ejecución en paralelo.
PARALLEL_AUTOMATIC_TUNING se define en TRUE.

• No utiliza el algoritmo LRU
• Su tamaño lo define el parámetro_
LARGE_POOL_SIZE
• Se puede cambiar de tamaño en forma
dinámica:
SQL>ALTER SYSTEM SET LARGE_POOL_SIZE = 24MB;

Conjunto JAVA (JAVA Pool)
• Es una definición opcional que si se instala y
utiliza JAVA, es fundamental y obligatoria.
• Su tamaño se define en Bytes mediante el
parámetro: JAVA_POOL_SIZE.

Estructura de Procesos
• Los procesos Oracle o de segundo plano
(background process) están disponibles
cuando se arranca una instancia Oracle y son:
– DBWR, PMON,SMON,CKPT y LGWR básicamente.

DBWR
• Escribe bloques de datos (también rollback) de la
SGA a los Archivos de Datos, esto sucede de
manera asíncrona, cuando:
– Sucede un Checkpoint.
– El número de buffers modificados llega al límite.
– No quedan buffers libres.
– Ocurre un timeout.
– Ponemos un TABLESPACE offline o en modo readonly.
– Borramos o truncamos una tabla.

PMON
Se activa periódicamente, recuperando los
recursos después de que un usuario falle:
Hace rollback de las transacciones que el
usuario tenía en curso, libera bloqueos a nivel
tabla/fila y otros recursos reservados por el
usuario y arranca los dead dispatchers.

CKPT
• Avisa al DBWR cuando sucede un Checkpoint y
actualiza las cabeceras de los archivos de
Datos y de Control (el DBWR volcará los
buffers actualizados a los ficheros de datos,
hay que tener cuidado de si ocurren con
frecuencia, causarían contención en el disco.
Si tardan mucho alargarán el proceso de
recovery, a lo más debe ocurrir un checkpoint
al llenarse el REDO LOG.

SMON
Recupera la instancia, si es necesario, cuando
ésta arranca: aplica los cambios registrados en
los REDO LOG, abre la BD dejándola accesible
a los usuarios y hace rollback de las
transacciones que no terminaron.
Libera espacio ocupado por los segmentos
temporales durante el procesamiento de
sentencias SQL.

LGWR
• Realiza escrituras secuenciales del contenido
del Caché de buffer de REDO LOG cuando:
– Se hace COMMIT.
– La REDO LOG BUFFER CACHÉ se llena en un tercio.
– Hay 1 MB de cambios en la REDO LOG BUFFER
CACHÉ.
– Como mucho, cada 3 segundos.
– Siempre, antes que se escriba el DBWR.

Algunos tip’s para probar
SQL>show sga;
– Podremos ver alguna información importante al
respecto de la asignación de memoria del SGA.
SQL>show parameter;
– Es una lista muy larga, pero nos muestra cosas
interesantes al respecto de los parámetros que se
manejan en ORACLE.
Intenten ver las vistas dinámicas con:
SQL>select * from v$dbfile; (v$datafile,v$controlfile)

Detalles de la Arquitectura
Parte II

ARCn
• Proceso de segundo plano OPCIONAL
• Archiva automáticamente los archivos REDO
LOG online antes de que se pueda volver a
utilizar el LOG.
• Protege el registro contra los cambios
realizados en la BD.
• Es crucial para recuperar una BD después de la
pérdida física de un disco.
• Este proceso inicia una copia de seguridad.

NOTA
Una de las decisiones más importantes que debe
tomar un DBA es si debe configurar la BD para
que funcione en modo ARCHIVELOG o en
modo NOARCHIVELOG.

Modo NOARCHIVELOG
• En este modo los archivos REDO LOG Online
se sobrescriben cada vez que se produce un
cambio en el LOG, esto causa que el LGWR no
sobrescribirá un grupo de archivos REDO LOG
Online hasta que el checkpoint ocurra cuando
se termine el grupo.
• Si ocurre un error de instancia sólo se pierde
el SGA, no hay pérdida de discos, sólo de
memoria.

Modo ARCHIVELOG
Protege contra la pérdida de datos cuando se
produce un fallo físico.
• Se puede realizar una copia de seguridad
mientras la BD está online.
• Se puede restaurar la BD en un punto
específico en el tiempo.

Estructura Lógica
• Una BD Oracle contiene como mínimo un
TABLESPACE.
• La jerarquía se define de la siguiente manera:
TABLESPACE
Archivos
de
Datos
Segmento Segmento
Extensiones
Bloques

• Un Tablespace contiene uno o más
Segmentos.
• Cada Segmento está compuesto por
Extensiones.
• Una extensión está formada por Bloques
lógicos.
• Un bloque es la unidad más pequeña para las
operaciones de lectura y escritura.

Tablespaces
Los datos de la BD se almacenan en Tablespaces.
• Un Tablespace puede pertenecer a una sola
BD a la vez.
• Cada Tablespace está formado por uno o más
archivos (Data Files).
• Un Tablespace puede tener uno o más
segmentos.
• Un Tablespace puede cambiar de estado
lectura y escritura a sólo lectura.

Segmentos
• Un Segmento es el espacio asignado a una
estructura de almacenamiento lógica dentro
de un Tablespace.
• Varios Segmentos pueden formar parte de un
Tablespace.
• Un Segmento no puede abarcar Tablespaces;
pero si puede abarcar varios archivos de datos
que pertenezcan a un Tablespace.
• Cada Segmento está formado por Extensiones.

Extensiones
• Es el espacio que se asigna mediante Extensiones a un
Segmento.
• Una o más Extensiones componen un Segmento.
• Cuando se crea un Segmento, éste está formado por lo
menos con una Extensión.
• A medida que el Segmento crece, se le agregan
Extensiones.
• El DBA puede agregar extensiones a un segmento
manualmente.
• Una Extensión es un conjunto de bloques contiguos.

Bloques
• Una BD se almacena en Bloques de datos con
el mayor nivel de granularidad posible.
• Los Bloques son la unidad de almacenamiento
más pequeña que Oracle puede asignar, leer o
escribir.

Usuarios DBA
Los usuarios SYS y SYSTEM se crean de forma
automática
• Durante la creación de la BD
• Se les otorga el rol de DBA
El usuario SYS:
• Propietario del DD de la BD (change_on_install)
El usuario SYSTEM:
• Propietario de las vistas y tablas internas
adicionales que utilizan las herramientas de
Oracle (manager)

SQL*Plus
Es la herramienta de línea de comandos de
Oracle que permite:
• Manipular la BD e interactuar con ella.
• Iniciar y cerrar la BD, crear y ejecutar
consultas, agregar filas, modificar datos y
escribir informes personalizados.
Proviene del SQL estándar con algunos
complementos específicos.

Arquitectura Oracle.pdf

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Arquitectura Oracle.pdf

Similar a Arquitectura Oracle.pdf (20)

Último

Último (20)

Arquitectura Oracle.pdf