3. INTRODUCCIÓN
Oracle está formado por 2 entidades diferenciadas:
La instancia
La base de datos
La instancia está formada por:
La estructura de memoria
Y los procesos que permiten que Oracle funcione.
La base de datos se refiere a los ficheros en disco que
almacenan los datos.
Cuando iniciamos Oracle,
primero se inicia la instancia
y luego se abre la base de datos.
Una instancia de Oracle siempre se corresponde con una sola
base de datos. Aunque existen muchas posibilidades de crear
entornos distribuidos.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 3
4. ARQUITECTURA DE UNA SOLA INSTANCIA
La situación más común de funcionamiento
de Oracle es de 1 instancia en un servidor
contra 1 base de datos que también está
en los discos locales.
Se debe tener en cuenta que también
existen arquitecturas distribuidas, de
múltiples instancias y de múltiples bases de
datos, pero eso queda fuera del alcance de
la primera certificación de administración.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 4
5. ARQUITECTURA DE UNA SOLA INSTANCIA
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 5
6. ARQUITECTURA DE UNA SOLA INSTANCIA
La instancia está formada por:
Estructuras de memoria
Procesos
Funciona en la RAM del ordenador. Cuando apagamos los
servicios de Oracle, también desaparece de la RAM.
Esta memoria se llama system global area (SGA). El DBA
puede dimensionar cuánto ocupará la SGA.
La SGA es una zona de memoria compartida a la que pueden
acceder todos los procesos.
Los procesos (background processes) están presentes
mientras la instancia está en memoria y controlan el
funcionamiento de Oracle.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 6
7. ARQUITECTURA DE UNA SOLA INSTANCIA
Cliente
Servidor
Procesos de la máquina cliente Procesos de la máquina
Sesiones de usuario conexión servidor (foreground
processes)
Generan la sentencia SQL Oracle NET
protocol Procesan el SQL
Tienen una zona de memoria
reservada: PGA (Program
Global Area)
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 7
8. ARQUITECTURA DE UNA SOLA INSTANCIA
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 8
9. ARQUITECTURA DE UNA SOLA INSTANCIA
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 9
10. ARQUITECTURA DE UNA SOLA INSTANCIA
La estructura física de Oracle está formada
por:
Los ficheros de datos
Los redo log
El fichero de control (controlfile)
Ficheros de datos
No se corresponden con las tablas de nuestro
diseño.
Las tablas son diseño lógico y los ficheros diseño físico.
Los procesos de Oracle se encargan de relacionar
las estructuras físicas y las lógicas.
Cambios sobre los datafiles, como cambiar su
ubicación o su nombre, puede hacer que Oracle
falle.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 10
11. ARQUITECTURA DE UNA SOLA INSTANCIA
Redo Logs
Registro secuencial de los cambios aplicados a los
datos (operaciones DML).
Suelen ser, al menos, 2 ficheros físicos.
Protegen al sistema de pérdidas de datos.
Son útiles, en caso de error, para recuperar el estado
anterior de los datos.
El controlfile
Almacena cuál es la ubicación de las estructuras
físicas de Oracle.
La instancia necesita leer primero el controlfile para
poder iniciarse.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 11
12. ARQUITECTURA DE UNA SOLA INSTANCIA
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 12
13. TALLER 1
Determinar si nuestra base de datos pertenece a
una arquitectura de una sola instancia o distribuida.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 17
14. ESTRUCTURAS DE MEMORIA
La instancia de Oracle tiene un bloque de memoria compartida
que se llama SGA y una serie de background processes.
La SGA, como mínimo, debe contener estas tres estructuras de
memoria:
La Database Buffer Cache
El Redo Log Buffer
El Shared Pool
Los procesos de servidor a los que se conectan los clientes,
también necesitan memoria, pero no es compartida, así que se
almacena en la PGA. Además, cada proceso de servidor tiene su
propia zona de PGA.
Opcionalmente, la SGA puede contener:
Un large pool, un pool de Java, un pool de streams
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 18
16. ESTRUCTURAS DE MEMORIA
DATABASE BUFFER CACHE
Área de trabajo para ejecutar SQL.
Un proceso de usuario no modifica los datos
directamente sobre los datos en disco.
Primero, se copian los datos afectados sobre la Database
Buffer Cache.
Luego, se aplican los cambios sobre esta copia.
Estos datos pueden permanecer el memoria hasta que
otros datos necesiten ese espacio.
Los procesos de usuario tampoco acceden a los
ficheros de datos directamente para consultar.
Cuando un proceso quiere consultar datos también se crea
una copia en la Database Buffer Cache.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 21
17. ESTRUCTURAS DE MEMORIA
DATABASE BUFFER CACHE
Cuando copiamos datos a cache, se copian en
bloques.
Los datafiles están formatados en bloques de
tamaño fijo.
La Database Buffer Cache también está formatada
para dejar huecos para bloques de ese tamaño.
El tamaño de un bloque lo determina el DBA.
Los bloques que contienen datos accedidos con
frecuencia, estarán siempre cargados en memoria,
por lo que su acceso será más rápido y nos
ahorraremos tiempo de I/O de disco.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 22
18. ESTRUCTURAS DE MEMORIA
DATABASE BUFFER CACHE
Supongamos estos dos accesos a la base de datos:
Select last_name, salary, job_id from employees where
employee_id=100;
Update employees set salary=salary*1.1 where employee_id=100;
Commit;
El primer select pone los datos del empleado en
caché.
El update no necesita leer de disco porque ya tiene
los datos disponibles en caché.
En este caso nos ahorramos el 50% de los accesos a
disco.
Una base de datos bien configurada por el DBA debe
ahorrarse el 90% de los accesos a disco.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 23
19. ESTRUCTURAS DE MEMORIA
DATABASE BUFFER CACHE
Los datos que se modifican en la cache, luego tienen que
almacenarse en disco. Existe un background process
dedicado exclusivamente a eso.
Dimensionar bien esta cache es crítico para el rendimiento.
Debe tener un tamaño tal que puedan caber los bloques
accedidos con más frecuencia.
Si no damos suficiente memoria, no caben los bloques más
accedidos y hay que hacer más acceso a disco.
Si se sobredimensiona, a la hora de arrancar la instancia
tarda más, porque debe preparar una zona de memoria
mayor.
La mayoría de bases de datos operativas utilizan una
database buffer cache entre 100 megas y 5 gigas.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 24
20. ESTRUCTURAS DE MEMORIA
LOG BUFFER
Zona de la SGA en la que se almacenan los cambios
que se hacen sobre los datos.
Los procesos de servidor que hacen cambios en los
datos de la database buffer cache también lo apuntan en
el log buffer.
Estos cambios, se acaban almacenando en los redo
logs, en disco.
Existe un background process encargado de escribir a
redo log: el log writer (LGWR).
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 25
22. ESTRUCTURAS DE MEMORIA
SHARED POOL
Es la estructura de memoria más compleja de la
SGA.
Está formada por muchas subestructuras, pero
las más importantes son:
LibraryCache
Data Dictionary Cache
SQL query results.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 27
23. ESTRUCTURAS DE MEMORIA
SHARED POOL Library Cache
Almacena código ejecutado recientemente ya parseado. Esto
quiere decir que Oracle se ahora el tiempo de comprobar si la
sentencia es correcta o no e interpretarla.
Supongamos la siguiente consulta:
Select * from employees where last_name=‘KING’;
Cuando Oracle recibe esta consulta debe mirar cosas cómo:
¿Existe employees?
Si me dan ‘*’, ¿qué columnas debo leer?
El usuario actual, ¿tiene permiso para acceder a esta
tabla?
Y además, se crea un plan de ejecución para recuperar
los datos.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 28
24. ESTRUCTURAS DE MEMORIA
SHARED POOL Data Dictionary Cache
Almacena la definición de objetos que se han accedido
hace poco. Por ejemplo, la descripción de una tabla.
Supongamos que estas dos consultas se hacen
seguidas:
Select sum(salary) from employees;
Select * from employees where last_name = ‘KING’;
Al realizar la primera consulta, se debe parsear e
interpretar y, además, acceder al diccionario de datos en
disco para saber la definición de la tabla de employees.
La segunda consulta también se deberá parsear e
interpretar, dado que es una consulta diferente, pero nos
ahorraremos el acceso al diccionario de datos, dado que
la definición de la tabla de employees ya está cargada en
memoria.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 29
25. ESTRUCTURAS DE MEMORIA
SHARED POOL SQL query results
Es una nueva característica de Oracle 11g.
Una misma consulta puede ser ejecutada varias
veces y obtener los mismos resultados.
En esta zona de memoria, se almacenan los
resultados para una consulta, de manera que no
es necesario volverla a hacer.
El mecanismo es lo suficientemente inteligente
como para invalidar los resultados si los datos
han sufrido cambios.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 30
26. TALLER 2
Investigar las estructuras de memoria de la
instancia.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 31
27. ESTRUCTURAS DE PROCESOS
Los procesos de background se inician con las instancia y están
trabajando hasta que la instancia se apaga.
Existen 5 procesos que siempre han coexistido con Oracle:
System Monitor (SMON)
Process Monitor (PMON)
Database Writer (DBWn)
Log Writer (LGWR)
Checkpoint Process (CKPT)
Otros vienen de versiones más recientes:
Manageability Monitor (MMON)
Memory Manager (MMAN)
Otros, se utilizan a veces:
Archiver (ARCn)
Recoverer (RECO).
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 32
29. ESTRUCTURAS DE PROCESOS
System Monitor (SMON)
Tiene asignada la tarea de abrir la base de datos.
Valida que los datos que se dan en el controlfile
sean correctos
Se encarga de localizar espacio libre en los datafiles
para guardar más datos.
Process Monitor (PMON)
Se encarga de localizar problemas con los procesos
de servidor.
Si alguno de estos procesos falla, el PMON se
encarga de destruir el proceso de servidor y liberar
la memoria que ocupa.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 34
31. ESTRUCTURAS DE PROCESOS
Database Writer (DBWn)
Los procesos de servidor no escriben directamente
sobre los ficheros de datos, sino en la database
buffer cache.
Es el Database Writer el encargado de escribir a
disco estos datos.
Una instancia puede tener más de un DBWn
funcionando. A cada uno se les llama: DBW0,
DBW1, etc.
Con DBWn nos referimos a todos los Database
Writer que hayan.
El número de DBWn que suelen haber es 1 por cada
8 CPUs aproximadamente.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 36
32. ESTRUCTURAS DE PROCESOS
Database Writer (DBWn)
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 37
33. ESTRUCTURAS DE PROCESOS
Log Writer (LGWR)
Este proceso es el encargado de escribir los
cambios que hay en el log buffer a los log files
de disco.
Como los procesos de servidor escriben los
cambios en el log buffer de memoria y, la
memoria puede borrarse, el objetivo es que el
LGWR escriba estos datos en los log files lo
antes posible.
Es uno de los cuellos de botella de la
arquitectura de Oracle.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 38
34. ESTRUCTURAS DE PROCESOS
Log Writer (LGWR)
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 39
35. ESTRUCTURAS DE PROCESOS
Checkpoint process (CKPT)
Va asignando checkpoints dentro de los buffers de
cambio, para poder recuperar la base de datos en caso
de fallo.
Manageability Monitor (MMON)
MMON se dedica a capturar estadísticas del
funcionamiento de la base de datos y las almacena en el
diccionario de datos.
Con esta información, la herramienta ADDM (Automatic
Database Diagnostic Monitor) da recomendaciones
sobre cómo mejorar el rendimiento de Oracle.
Manageability Monitor Light (MMNL)
Es un proceso que sirve de ayuda al MMON.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 40
36. ESTRUCTURAS DE PROCESOS
Memory Manager (MMAN)
Gestiona la memoria de la SGA y la PGA.
Permite que se puedan hacer redimensionamientos
de memoria con la base de datos en marcha.
Archiver (ARCn) y Recoverer Process (RECO)
Son procesos opcionales que veremos más
adelante.
Existen otros muchos más procesos pero los
que hemos visto son los más importantes.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 41
37. TALLER 3
Investigar los procesos que corren en nuestra
instancia.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 42
38. ESTRUCTURAS DE ALMACENAMIENTO
Estructuras físicas de la base de datos
Estructuras lógicas de la base de datos
El diccionario de datos
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 43
39. ESTRUCTURAS DE ALMACENAMIENTO
ESTRUCTURAS FÍSICAS
Controlfile
Una instancia de Oracle tiene un único controlfile.
Sin embargo, un buen DBA hace varias copias de ese fichero por si
se daña.
Online Redo Log Files
Almacenan los cambios que se van haciendo en la base de datos,
por si hubiera que volver a un estado anterior.
Datafiles
Desde la versión 10g, se necesitan 2 datafiles como mínimo.
1 almacena el diccionario de datos y otro, para el resto.
Otros menos importantes:
El fichero de parámetros, el fichero de passwords, los archive redo
log files, etc.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 44
41. ESTRUCTURAS DE ALMACENAMIENTO
ESTRUCTURAS LÓGICAS
Un administrador debe conocer las estructuras físicas y
las lógicas.
El programador trabaja con estructuras lógicas, como
por ejemplo, tablas.
Una tabla tiene asociado:
filas con la información
Índices. Son un mecanismo para acceder más rápidamente a la
información.
Información de undo. Por si queremos que la tabla vuelva a un
estado anterior.
Toda esta información, se dice que se guarda en
segmentos.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 46
44. ESTRUCTURAS DE ALMACENAMIENTO
ESTRUCTURAS LÓGICAS
Un tablespace es
A nivel lógico, un conjunto de segmentos. Por lo que puede
contener varias tablas.
A nivel físico, uno o más datafiles.
Una tabla puede estar distribuida en uno o más datafiles.
En un datafile pueden haber datos de más de una tabla.
Al instalar Oracle, se crean también una serie de
segmentos que forman el diccionario de datos. Estos
segmentos se guardan en 2 tablespaces:
SYSTEM
SYSAUX
Cada uno de estos tablespace tienen un datafile
asignado.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 49
46. ESTRUCTURAS DE ALMACENAMIENTO
ESTRUCTURAS LÓGICAS
Un segmento, a su vez, está formado por una
serie de bloques.
Los datafiles tienen un formato basado en
bloques.
Los segmentos tienen una serie de bloques
asignados.
Como gestionar el espacio de bloque en bloque
puede ser muy costoso, los bloques que van
seguidos se agrupan en extents
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 51
48. ESTRUCTURAS DE ALMACENAMIENTO
DICCIONARIO DE DATOS
Se almacena en el conjunto de segmentos que forman los
tablespaces de SYSTEM y SYSAUX.
Los datos que almacena son una descripción de los
contenidos físicos y lógicos que tiene la base de datos:
Definición de usuarios
Información de seguridad
Restricciones de integridad
Etc.
No podemos acceder al diccionario de datos directamente, a
no ser que nos conectemos como usuario DBA.
Si hacemos modificaciones directamente sobre el diccionario
de datos, podemos dañar de forma irreparable la base de
datos y Oracle no nos daría soporte.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 53
49. ESTRUCTURAS DE ALMACENAMIENTO
DICCIONARIO DE DATOS
Oracle, sin embargo, nos proporciona una serie
de vistas con las que podemos consultar alguna
información.
Estas vistas empiezan por: DBA_, ALL_ o
USER_.
Por ejemplo, si nos conectamos como HR y
hacemos select * from user_tables, tendremos
todas las tablas que son propiedad de este
usuario.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 54