1.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
En 20 minutos te cuento lo que sé de ...
ARQUITECTURA ORACLE
ÁTICA – 30/05/2013
Juan Luis Serradilla

2.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
Componentes de un
Servidor Oracle y su
Funcionamiento al
Ejecutar Código SQL

3.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
Contenido
1.- Base de Datos: estructura física y lógica
2.- Instancia: SGA y Procesos
3.- Servidor Oracle. Sesiones.
4.- Ejecución de una operación de Consulta
5.- Ejecución de una operación de Actualización
6.- Compilación del código SQL
7.- Resumen. Consumo y Optimización de Recursos

4.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
BASE DE DATOS
Ficheros de datos, control y redo
● Apartado Primero
– Subapartado Primero
● Bla bla bla bla

5.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
BASE DE DATOS
Estructura Lógica
● Una BD está compuesta por varios tablespaces
● Cada tablespace lo forman uno o más ficheros de datos
● Una tabla es un
segmento formado por una
o más extensiones dentro del
mismo tablespace
● Un segmento tiene al
menos una extensión
(unidad de asignación)
● La unidad mínima
de E/S es el bloque
Oracle (db_block_size) de
2/4/8/16/32Kb
TABLA

6.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
BASE DE DATOS
Segmento, Extensión y Bloque
● Tipos de segmento: Table, Index, etc
● Extensión: conjunto contiguo de bloques
● Los índices de una tabla deben estar en otro tablespace
TABLA
TABLA

7.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
INSTANCIA = SGA + PROCESOS
Memoria (SGA) y CPU (Procesos background)
● Apartado Primero
– Subapartado Primero
● Bla bla bla bla

8.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
SGA (Shared Global Area)
Memoria Compartida en RAM
● Es una “gran caché” donde Oracle cachea el código (SQL,
PL/SQL) y los datos (bloques que contienen las filas de las
tablas). Es finita (normalmente LRU).
● Los datos se cachean en la Data Buffer Caché (bloques)
● El código en la Shared Pool (SQL y PL/SQL)

9.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
INSTANCIA Y BASE DE DATOS
Independientes y Complementarias
● Apartado Primero
– Subapartado Primero
● Bla bla bla bla

10.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
SERVIDOR ORACLE = INSTANCIA + BD
Una BD se abre mediante una Instancia
● Apartado Primero
– Subapartado Primero
● Bla bla bla bla

11.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
SERVIDOR ORACLE
Cada sesión de BD arranca un proceso servidor
● Cada sesión consume
RAM (PGA) y CPU (proceso)

12.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
CONSULTAR DATOS
El código se envía al servidor (RAM en PGA)
● Apartado Primero
– Subapartado Primero
● Bla bla bla bla

13.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
CONSULTAR DATOS
El proceso servidor lo compila (CPU y RAM) y
accede a los datos del DD si es necesario (E/S)
● Apartado Primero
– Subapartado Primero
● Bla bla bla bla

14.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
CONSULTAR DATOS
El proceso servidor busca los bloques en Buffer
Caché, trayéndolos de disco si hace falta (E/S)
● Apartado Primero
– Subapartado Primero
● Bla bla bla bla

15.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
ACTUALIZAR DATOS
El proceso servidor hace los cambios SOLO en la
SGA (Data Buffer Cache y Buffer de Redo)
● Apartado Primero
– Subapartado Primero
● Bla bla bla bla

16.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
ACTUALIZAR DATOS - COMMIT
LGWR vuelca a disco Buffer de Redo,
protegiendo los cambios en disco
● Apartado Primero
– Subapartado Primero
● Bla bla bla bla

17.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
ACTUALIZAR DATOS
Asíncronamente, el DBWR volcará a disco los
bloques modificados en Data Buffer Cache
● Apartado Primero
– Subapartado Primero
● Bla bla bla bla

18.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
Compilación Código SQL
Consume CPU y RAM. Reutilizar código
●
Análisis sintáctico y semántico (acceso al DD E/S), y cálculo del plan de
ejecución (consumo CPU). Sentencia compilada se guarda en SGA
(Shared Pool, consumo RAM).
●
Al compilar una sentencia SQL, hay que distinguir entre “hard” y “soft”
parse:
– Hard Parse: la sentencia SQL no existe en la Shared Pool
(Library Cache). Es costoso en términos de CPU y latches.
– Soft Parse: la sentencia SQL ya existe en la Shared Pool y
puede usar una versión de la misma.
●
Dos sentencias SQL son iguales si tienen el mismo texto (incluyendo
espacios en blanco y mayúsculas/minúsculas); y además:
– Los nombres de objetos deben apuntar a los mismo objetos
reales: SCOTT.EMP <> JUANLU.EMP
– El modo del optimizador debe ser el mismo: FIRST_ROWS <>
ALL_ROWS
– Los nombres, tipos y longitudes de las variables bind deben ser
los mismos: VARCHAR2(8) <> VARCHAR2(10)
– El entorno NLS (idioma y país) debe ser el mismo.

19.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
RESUMEN
Consumo y Optimización de
Recursos
●
Tabla en un tablespace y sus índices en otro tablespace distinto.
●
Cada sesión de BD consume RAM y CPU: minimizar sesiones del pool.
●
La ejecución de código consume RAM y CPU al compilar, por lo que
debe reutilizarse para minimizar dichas compilaciones (PAQUETES):
escribirlo una vez y utilizarlo muchas y desde muchos sitios.
●
La ejecución de código genera E/S la primera vez que se accede a los
datos, y posteriormente, cada vez que hayan “salido” de caché:
optimizar el código para que recupere solo las filas necesrias y lo
haga rápidamente (optimizar modo de acceso, el más rápido es
ROWID).
●
Las lecturas masivas de datos (muchas filas), “estropean” la caché
de datos, provocando posteriormente acceso a disco para recuperar los
bloques que más se usan (posible mejora DB_KEEP_CACHE_SIZE). Ojo
con las pruebas en explotación y tb los informes con muchos datos.
●
Las escrituras masivas de datos tb “estropean” la caché, pero más
aún pues por cada bloque modificado se necesita uno de
rollback/undo, y además generan E/S posterior al volcar los cambios
a disco (FAST_START_MTTR_TARGET). Actualizar solo cuando sea
necesario.

20.
© 2013. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas.
Fin
Gracias por vuestra atención
¿Alguna pregunta?
Juan Luis Serradilla (juanluNOSPAM@um.es)Juan Luis Serradilla (juanluNOSPAM@um.es)