1 Arquitectura de Base de Datos

Deber de Base de Datos 2

Nombres: Geovanny Duchitanga, Liliana Cajas, Ricardo Chuqui,

Christian Hernández

CARRERA: Ingeniería de Sistemas ASIGNATURA: Base de Datos 2

NRO. PRÁCTICA: 1 TÍTULO PRÁCTICA: Arquitectura de Base de Datos y Explain Plan

OBJETIVO:

Conocer y saber sobre la arquitectura de la base de datos Oracle 12c.

Conocer las características del Oracle Explain Plan.

ARQUITECTURA DE LA BASE DE DATOS ORACLE 12C

Oracle 12c introduce una nueva arquitectura llamada Oracle MULTITENANT en la que se provee, a la

base de datos, la capacidad de convertirse en un gran contenedor de bases de datos.

El contenedor es definido con el nombre de Multitenant Container Database (CDB) donde podemos

incluir desde 0 a mas bases de datos llamadas Pluggable Databases (PDB).

El siguiente grafico muestra cómo está compuesto el Multitenant Container Database (CDB)
 2 Arquitectura de Base de Datos

Como se puede observar el CDB está formado por una Instancia (SGA + PGA), un grupo de procesos

background, un contenedor Root y muchas bases de datos Pluggable (PDB).

Si un cliente quiere consolidar varias bases de datos en un solo servidor puede hacer uso de esta

arquitectura y tener una sola instancia con muchas bases de datos de tipo Pluggable database.

Esto ayuda a optimizar el uso de la memoria debido a que se utiliza una gran instancia y un solo grupo

de procesos background para todas las bases de datos Pluggable (PDB).

La versión 12c ha introducido principalmente dos nuevos conceptos:

Base de Datos de tipo Contenedor (CDB): Es una base de datos que tiene la capacidad de almacenar

lógicamente varias bases de datos, a estas bases de datos internas se les llama “Pluggable Database

(PDB)”.

Base de Datos de tipo “Pluggable” (PDB): Una PDB es un conjunto de esquemas de base de datos que

son presentados a los usuarios y aplicaciones como una representación de una base de datos separada o

independiente.

De una manera mas detallada describiremos los contenedores que forman parte del CDB

1. Contenedor ROOT

Cuando se crea una base de datos CDB, automáticamente se crea un contenedor ROOT.

El contenedor ROOT, conocido también como CDB$ROOT, es utilizado para almacenar la metadata

que soporta la arquitectura CDB. Además, almacena las estructuras globales de una base de datos.
 3 Arquitectura de Base de Datos

Dentro del contenedor ROOT podemos encontrar:

a) Control Files: Se define como una estructura global en el CDB por lo que existe solo un grupo de

controlfiles que soportan al CDB y todos los PDBs definidos.

b) Redolog Files: Como los redologs se relacionan directamente con el Redolog Buffer se define

también como una estructura global dentro del CDB, es decir, se tiene un solo grupo de redologs que

soportan la actividad del CDB y los PDBs.

c) Undo Tablespace: Como sabemos las transacciones son manejadas a nivel de Instancia. El Undo

tablespace está relacionado directamente con las transacciones (posee la información necesaria para que

una transacción puede hacer rollback). Al tener una sola instancia es necesario tener un solo UNDO

tablespace que soporte la transaccionalidad del CDB y todos los PDBs.

d) Temp Tablespace: El tablespace Temporal dentro del Contenedor ROOT es obligatorio. Soporta la

actividad temporal de todos los PDBs, incluyendo el contenedor Root.

Sin embargo, si un PDB no tiene definido su propio tablespace temporal, utilizará el tablespace

temporal del contenedor ROOT.

e) System y Sysaux Tablespace: El contenedor Root almacena toda la metadata necesaria para

soportar la arquitectura CDB. Toda la metada es almacenada en los tablespaces System y Sysaux del

contenedor Root.

f) Users Tablespace: Descripciones de todos los espacios de tabla (o accesibles por el usuario).

Lo mas interesante de la versión 12c es observar como la nueva arquitectura separa los objetos propios

de Oracle (paquetes como DBMS_OUTPUT, DBMS_STATS, DBMS_SCHEDULER, etc) de la metadata

propia de las bases de datos Pluggable.

 4 Arquitectura de Base de Datos

Gracias a esta separación, la base de datos Pluggable es independiente del Contenedor. De esa manera,

una base de datos Pluggable puede ser desconectada (Unplug) de un contenedor y conectada (PlugIn) en

otro de manera sencilla y rápida. Debido a esta característica es que se le denomina base de datos

Pluggable. Por la acción en ingles de PlugIn y Un-Plug la base de datos de un contenedor a otro.

2. PBD SEED

Es una base de datos Pluggable que se crea junto con la creación del CDB. Su función principal es la

de ayudar a crear nuevas bases de datos Pluggable de forma rápida y sencilla.

Es importante señalar que esta base de datos siempre está en estado READ ONLY.
 5 Arquitectura de Base de Datos

3. PBD DATABASES

Son Bases de datos que almacenan la información de las aplicaciones, se componen de usuarios,

esquemas y objetos propios de la aplicación que interactúa con la base de datos.

Posee su propio conjunto de tablespaces que no son compartidos por otro PDB o por el contenedor

ROOT.

Una características principal de los PDBs es que son bases de datos independientes y aisladas. Los

objetos en un PDB no pueden ser visualizados por otro PDB. Existen reglas de seguridad que aseguran el

aislamiento total de cada PDB dentro de un CDB,

Las aplicaciones siguen pensando que las bases de datos con las que interactúan son independientes una

de otra.

Los tablespace SYSTEM y SYSAUX solo almacenan la metadata propia del PDB para poder facilitar

el conectado y desconectado del PDB de un Contenedor.

Ventajas de la nueva Arquitectura

- Evita redundancia de información en el diccionario de datos.

- Seguridad: Separación de información entre cada pluggable database. Un usuarios que se

conecta a un PDB no puede ver la información de otro PDB.

 6 Arquitectura de Base de Datos

- Se puede tener una administración independiente (DBA) por cada PDB.

- Después de un upgrade a Oracle 12c una base de datos puede ser conectada a un CDB.

- Manejo de recursos por cada PDB mediante Resource Manager.

- Administración de backups Centralizado.

- Los upgrade se realizan a nivel del Contenedor (CDB), de esa manera, solo es necesario un

upgrade para todas las bases de datos Pluggable.

Los componentes de una base de datos:

Podemos nombrar algunos componentes comunes:

Tablas: Comprende definición de tablas, campos, relaciones e índices. Es el componente principal de

las Bases de Datos Relacionales.

Formularios: se utilizan principalmente para actualizar datos.

Consultas: se utilizan para ver, modificar y analizar datos.

Informes: se utilizan para presentar los datos en formato impreso.

Datos: Un dato es una representación simbólica (numérica, alfabética, algorítmica, espacial, etc.)

Macros: conjunto de instrucciones para realizar una operación determinada.

Archivo: En informática, o concretamente en el contexto de una base de datos relacional, un registro

(también llamado fila o tupla) representa un objeto único de datos implícitamente estructurados en una

tabla.

 SMA (Oracle Security Monitoring and Analytics ): Es el servicio en la nube de Oracle es una

solución integrada para la detección, investigación y reparación rápida de una amplia gama de

amenazas y ataques de seguridad, SMA se entrega como un servicio de Oracle Cloud para

proporcionar tiempo rápido para valorar a mayor escala y confiabilidad, y también la

administración reducida en gastos generales.

 7 Arquitectura de Base de Datos

 Componentes del SGA

- Database Buffer Cache: es una parte integral de Oracle y proporciona el almacenamiento para

bloques de datos que se han recuperado de los data files y el impulso de optimización para

operaciones DML.

- Redo Log Buffer: la memoria cache del buffer reduce la contención en sistemas multiprocesador,

en el área del SGA contiene solo los buffers mismos y no sus estructuras de control.

- Shared Pool: el grupo compartido es una área de RAM, es el responsable de recopilar, analizar,

interpretar y ejecutar todas las declaraciones SQL que van en contra de la base de datos Oracle.

- Large Pool: proporciona espacio en la RAM para E/S del proceso del servidor, Buffers de datos

de consulta paralelos, servidor compartido y consulta distribuida

- Java Pool: Esta métrica representa el porcentaje del conjunto de Java que está marcado

actualmente como libre.

- Streams Pool: Almacena mensajes de cola almacenados en buffers para Oracle Streams y

Advanced Queuing (a través del paquete dbms_aqadm).

- Fixed SGA: Es un componente que varía en tamaño de plataforma a plataforma, se compila en la

base de datos, no se tiene control sobre el tamaño del Fixed SGA esta área es utilizada para

secciones de arranque de la SGA.

 Los tipos de datos que existen en Oracle son los siguientes:

 8 Arquitectura de Base de Datos

Cuando se ejecuta el comando CREATE DATABASE, se crean los siguientes tipos de archivos:

- Spfile: El archivo spfile de Oracle es una representación binaria del archivo init.ora basado en

texto.

A partir de la versión 9i, Oracle introdujo el fichero de parámetros de arranque 'spfile' como mejora

a los antiguos arranques con los 'init.ora', no obstante el uso de spfile es opcional.

Con los ‘spfile’ se puede realizar el arranque de una instancia en remoto, mientras que con los

‘init.ora’ el fichero debe estar en el sistema que se realiza el arranque.

- Data files y temp files: Un data files un archivo físico creado por la base de datos y contiene

estructuras de datos como tablas e índices. Un temp file es un archivo que contiene datos que

persisten en el momento que son utilizados. Los datos son escritos en estos archivos en un formato

propio de Oracle y no pueden ser leídos por otros programas.

- Control files: Un control files un repositorio que registra los componentes físicos de la base de

datos.

- Online redo log files: El online redo log file es un conjunto de archivos que registran los cambios

realizados a los datos.

Explain Plan

Esta sentencia guarda el plan de ejecución para una sentencia SQL en una tabla. Cada vez que

ejecutamos una sentencia una de las cosas que hace oracle es crear un plan de ejecución de la sentencia.

Un plan de ejecución define la forma en que oracle busca o graba los datos. Decide, por ejemplo, si va a

usar o no los indices en una sentencia SELECT. Cuando se hace una consulta puede influenciar en el
 9 Arquitectura de Base de Datos

costo, es decir demasiado transaccional, para esto Oracle dispone de los índices, lo que nos permite

optimizar una tabla por su columna, cuando hacemos muchos select y de esta manera reducir su costo.

Esta es la sintaxis general:

EXPLAIN PLAN [SET STATEMENT_ID = 'text'] FOR sentencia;

Podemos usar nuestra propia tabla de explain:

EXPLAIN PLAN [SET STATEMENT_ID = 'text'] INTO

[esquema.]tabla@dblink FOR sentencia;

Si no definimos nuestra propia tabla se usa la tabla PLAN_TABLE.

DELETE PLAN_TABLE;

EXPLAIN PLAN FOR SELECT * FROM T_PEDIDOS WHERE CODPEDIDO = 5;

Para el seguimiento automatico usamos el comando SET AUTOTRACE ON;

- Usamos una consulta en sql para ver el costo que tiene esta consulta:

SELECT J.CFE_JUG_NOMBRE,

J.CFE_JUG_APELLIDO

FROM CFE_JUGADORES J

WHERE J.CFE_JUG_NOMBRE = 'Andres';

 10 Arquitectura de Base de Datos

Ahora usando el explain plan de la siguiente manera:

EXPLAIN PLAN FOR SELECT J.CFE_JUG_NOMBRE,

J.CFE_JUG_APELLIDO

FROM CFE_JUGADORES J

WHERE J.CFE_JUG_NOMBRE = 'Andres';

CFE_JUG_NOMBRE CFE_JUG_APELLIDO

------------------ --------------------

Andres Usiña

Andres Velez

Plan FOR correcto.

--PARA VER EL RESULTADO

SELECT

SUBSTR (LPAD(' ', LEVEL-1) || OPERATION || ' (' || OPTIONS ||

')',1,30 ) "OPERACION",

OBJECT_NAME "OBJETO"

FROM PLAN_TABLE
 11 Arquitectura de Base de Datos

START WITH ID = 0

CONNECT BY PRIOR ID=PARENT_ID;

-------------------------------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

-------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 54 | 12852 | 4 (25)| 00:00:01 |

|* 1 | CONNECT BY NO FILTERING WITH START-WITH| | | | | |

| 2 | TABLE ACCESS FULL | PLAN_TABLE$ | 19 | 4522 | 3 (0)| 00:00:01 |

-------------------------------------------------------------------------------------------------------

Tambien podemos usar índices para reducir el costo de una consulta, los indices se usan para mejorar el

rendimiento de las operaciones sobre una tabla.

En general mejoran el rendimiento las SELECT y empeoran (minimamente) el rendimiento de los

INSERT y los DELETE. Para crear un índice seguimos la siguiente sintaxis:

CREATE INDEX IDX_DATOS_JUGADOR ON CFE_JUGADORES

(CFE_JUG_NOMBRE, CFE_JUG_APELLIDO);

Index IDX_DATOS_JUGADOR creado.

DELETE DE INDEX

DROP INDEX IDX_DATOS_JUGADOR;

- Ahora una consulta:

SELECT CFE_JUG_NOMBRE, CFE_JUG_APELLIDO

FROM CFE_JUGADORES

WHERE CFE_JUG_NOMBRE = 'Andres';

CFE_JUG_NOMBRE CFE_JUG_APELLIDO

----------------- --------------------

Andres Usiña
 12 Arquitectura de Base de Datos

Andres Velez

Ahora usando el explain plan (plan de ejecucion) observamos que el costo se redujo:

RESULTADOS OBTENIDOS:

- Conocimos mas a fondo en que consiste la arquitectura de una base de datos, su funcionamiento, el

conocer nuevos términos y que significan y cual es su funcionamiento dentro de la arquitectura.

- Se abordo el tema del explain plan de Oracle y de esa manera saber usar sentencias o consultas con

una mejor optimización y reducir el costo de una consulta.

CONCLUSIONES:

Ahora que sabemos la arquitectura de base de datos y el tema del explain plan, podemos crear consultar

con un mejor rendimiento.

Bibliografia

César Pérez. (2007). MySQL para Windows y Linux. Madrid: Ra-Ma.

Gabillaud, J. (2015). SQL Server 2014: Administración de una base de datos transaccional con
SQL Server Management Studio. ENI.

Godoc, E. (2014). SQL: los fundamentos del lenguaje. ENI.

Helskyaho, H. (2013). Oracle SQL Developer Data Modeler for Database Design Mastery. New
Delhi: Mc Graw Hill.
 13 Arquitectura de Base de Datos

Heurtel, O. (2015). Oracle 12C Administración. Eni Ediciones.

Ojeda, F. C. (2012). SQL Server 2012. Madrid: Anaya Multimedia.

Rodriguez, J. F. (2015). Lenguajes de definicion y modificacion de datos SQL IFCT0310. IC.

Silberschatz. (2006). Fundamentos de Base de Datos. Madrid: Mc Graw Hill.

Firmas de los integrantes:

Fecha: Cuenca, 06 de Abril de 2018