Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

arquitectura db de oracle 11g

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Nächste SlideShare
Arquitectura de oracle
Arquitectura de oracle
Wird geladen in …3
×

Hier ansehen

1 von 25 Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie arquitectura db de oracle 11g (20)

Anzeige

Aktuellste (20)

arquitectura db de oracle 11g

  1. 1. 1 Diplomado Administración en Base de Datos y Redes Signatura : Administración de Base de Datos Base de Datos I Docente Msc.Ing. Javier Claros UNIVERSIDAD AUTÓNOMA GABRIEL RENÉ MORENO UNIDAD DE POSTGRADO FACULTAD INTEGRAL DEL NORTE
  2. 2. Postgrado ÍNDICE 1. Arquitectura Oracle 11g R2 2
  3. 3. Postgrado 1.1. Antecedentes Generales  Oracle esta formado por la entidad instancia y base de datos  La instancia esta formado por estructura de memoria y procesos  La base de datos se refiere a los ficheros de disco  Al iniciar Oracle primero se sube la instancia luego la base de datos  Una instancia corresponde a una sola bd, arquitecturas distribuidas de múltiples instancias y múltiples bd  Funciona en la RAM, esta memoria se llama System Global Area (SGA), el DBA dimensiona cuánto ocupara la SQA  SQA es una zona de memoria compartida que acceden los procesos  Los procesos Background Processes están presentes mientras la instancia esta en memoria y controlan el funcionamiento de Oracle  El cliente utiliza Oracle NET Protocol  Tiene una zona de memoria reservada Program Global Área PGA  Estructura física : Ficheros, redo log, ficheros 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  Procesos de Oracle se encargan de relacionar las estructuras físicas y las lógicas  Cambios sobre los datafiles, nombre, ubicación puede fallar Oracle
  4. 4. Postgrado 1.1. Antecedentes Generales  Redo Logs  Registro secuencia 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
  5. 5. Postgrado 1.2. Arquitectura de una sola Instancia  Ejemplo
  6. 6.  Oracle esta formado por la entidad instancia y base de datos Postgrado 1.2. Arquitectura de una sola Instancia
  7. 7.  Oracle Postgrado 1.2. Arquitectura de una sola Instancia
  8. 8. Postgrado 1.3. Estructura de Memoria  Estructuras de memoria  La instancia de Oracle tiene un bloque de memoria compartida que se llama SQA y una serie d 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
  9. 9.  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 la 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.  Cuando copiamos datos a cache, se copian en boques  Los datafiles están formateados en bloques de tamaño fijo  La Datafile Buffer Cache también está formateada 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 tiempos de I/O de disco. Postgrado 1.3. Estructura de Memoria
  10. 10.  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*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 ahorrase el 90% de los accesos a disco.  Los datos que se modifican en la cache, luego tienen que almacenarse en disco. Existe un background processs 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 mas frecuencia.  Si no damos suficiente memoria, no caben los bloques mas accedidos y hay mas acceso a disco  Si se sobredimensiona, a la hora de arrancar la instancia tarda más, por que debe preparar una zona de memoria mayor. Postgrado 1.3. Estructura de Memoria
  11. 11.  DATABASE BUFFER CACHE….  La mayoría de base de datos operativas utilizan una database buffer cache entre 100 megas y 5 gigas.  LOG BUFFER  Zona de la SGA en la que se almacenan los cambios que se hacer sobre los datos  Los procesos de servidor que hacer cambios en los datos de la database buffer cache también lo apuntan en log buffer.  Estos cambios, se acaban almacenando en los redo logs, en disco  Existen un background process encargado de escribir a redo log: el log writer (LGWR) Postgrado 1.3. Estructura de Memoria
  12. 12.  SHARED POOL  Es la estructura de memoria mas compleja de la SGA  Esta formada por muchas subestructuras, pero las más importantes son:  Library Cache  Data Dictionary Cache  SQL query results  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 lla consulta • SELECT * FROM EMPLOYESS WHERE LAS_NAME = ‘MARTS’  Cuando Oracle recibe esta consulta debe mirar cosas como : • Existe employees • Si me dan ‘*’, que columnas debo leer • El usuario actual, tiene permiso apra acceder a esta tabla • Y además, se crea un plan de ejecución para recuperar los datos Postgrado 1.3. Estructura de Memoria
  13. 13.  SHARED POOL  SHARED POOL: Dictionary Cache  Almacena la definición de objetos que se han accdedido hace poco. Por ejemplo, la descripción de una tabla.  Supongamos que esta dos consultas se hacen seguidas • Select sum(salary) from employees; • Select * from employees where last_name = ‘SMITH’  Al realizar la 1er consulta, se debe parsear e intepretar, acceder al diccionario de datso en disco para saber la definición de tabla de employees.  La segunda consulta también se deberá parsear e interpretar, dado que es un consulta diferente, pero nos ahorraremos el acceso al diccionario de datos, dado que la definición de la tabla employees ya esta cargada en memoria. Postgrado 1.3. Estructura de Memoria
  14. 14.  SHARED POOL  SHARED POOL: SQL query results  Es una nueva característica de Oracle 11g  Una misma consulta puede ser ejecutada varias veces y obtener los mismo resultados  En esta zona de memoria, se almancenan los resultado para una consulta, de manera que no es necesario volverla a hacer.  El mecanismo es lo suficientemente inteligente como para invalidar los resultado si los datos han sufrido cambios.  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) Postgrado 1.4. Estructuras de Procesos
  15. 15.  Estructuras de procesos……  Otros vienen de versiones más recientes  Manageability Monitor (MMON)  Memory Manager (MMAN)  Otros, se utilizan a veces  Archiver (ARCn)  Recoverer (RECO) Postgrado 1.4. Estructuras de Procesos
  16. 16.  Estructuras de procesos: System Monitor (SMON)  Tiene asignada la tarea de abrir la base de datos  Valida que los datos que se dan en la controlfile sean correctos  Se encarga de localizar espacio libre en los datafiles para guardar más datos  Estrcuturas de procesos : 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 Postgrado 1.4. Estructuras de Procesos
  17. 17.  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 Write el encargado de escribir a disco estos datos  Una instancia puede tener mas de un DBWn funcionando. A cada uno se les llama: DBW0, DBW1,…  Con DBW nos referimos a todos lo Database Writer que hayan.  El n  El número de DBWn que suelen haber es 1 por cada 8 CPUs Postgrado 1.4. Estructuras de Procesos
  18. 18.  Estructuras de procesos: Log Writer (LGWR)  Este procesos 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, la memoria puede borrarse, el objetivo es que el LGWR escriba estos datos en los log files lo antes posible. Postgrado 1.4. Estructuras de Procesos
  19. 19.  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 para ayuda al MMON  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. Postgrado 1.4. Estructuras de Procesos
  20. 20. Postgrado 1.5. Estructura de Almacenamiento  Estructuras Físicas  Controlfile  Una instancia de Oracle tiene un único controlfile  El DBA que administra requiere varias copias 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  Data Files  Desde la versión 10g, se necesitan 2 datafiles como mínimo  1 almacena el diccionario de datos y el otro para el resto
  21. 21.  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.  Un tabla tiene asociado:  Filas con información  Indices, que son un mecanismo para acceder mas 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 guarda en los segmentos Postgrado 1.5. Estructura de Almacenamiento
  22. 22.  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 mas datafiles  Una tabla puede estar distribuida en uno o mas 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 Postgrado 1.5. Estructura de Almacenamiento
  23. 23.  Estructuras Lógicas….  Un segmento, a su vez, esta formado por una serie de bloques  Los datafiles tiene un formato basado en bloques  Los segmentos tiene una serie de bloques asignados  Como gestionar el espacio de bloque en bloque puede ser muy costoso, los bloques en van seguidos se agrupan en extents Postgrado 1.5. Estructura de Almacenamiento
  24. 24.  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ísico y lógicos que tiene la base de datos:  Definición de usuarios  Información de seguridad  Restricciones de integridad…..  No podemos acceder al diccionario de datos directamente, a no ser que nos conectemos como usuario DBA  Si hacemos modificaciones de forma irreparable la base de datos y Oracle no nos daría soporte.  Oracle, sin embargo, nos proporciona una serie de vistas con las que podemos consultar alguna información : DBA_, ALL_, USER_...  Ejemplo si nos conectamos como HR y hacemos select * from users_tables, tendremos todas las tablas que son propiedad de este usuario Postgrado 1.5. Estructura de Almacenamiento
  25. 25. Postgrado GRACIAS

×